MultiWii OSD - MWOSD

[shikra]

Is it possible to add all the pid configurations in MWOSDrev 1.4?

PLEASEEEEEE

Its possible and I would like to do it

[rubadub]

@shikra or anyone else.
I just discovered the "SHIFTDOWN" define option to push the first three lines down, as I was running into the problem of the GPS coords being cut off on the top line (NTSC). The MWOSD code appears to be primarily based on the KV-OSD stuff, which didn't have this issue. The top lines were correctly adjusted/shifted for both PAL and NTSC.

Anyway, a couple of quick questions:
1) why is this happening? Did you make some changes to the way the characters are laid out vs. how it was done in the old KV-OSD code?
2) does this effectively mean that one must make mental adjustments when creating custom layouts (i.e., you have to remember that the top three lines will be shifted down, so you have to move stuff around or risk having some OSD items placed on top of others ) ??

[shikra]

KVOSD didn't use the very top line.

The issue is for some reason some monitors cut off outer parts of the screen (not just osd - also the cam display. My fatshark goggles all display the full screen, but my groundstation does cut off part. I vaguely recall some monitors have an option in the menu to assist.

The shift down is a bit of a legacy hangover from when the screen layout wasn't configurable. A quick "fix" for guys who monitor doesn't display or partially display the top line.

It doesn't actually change the layout positions saved or displayed in the gui - it makes a line downshift on the fly - so hopefully no need to remember any changes.

[bulesz]

Hey guys,

I have a strange issue:

Using MW OSD 1.3 with full Naze32 + Baseflight.

Everything seems to be fine when disarmed, the voltages, timer, horizon, altitude is working etc...but when armed the hud is frozen! When disarm again, it is working again.


Any idea?

Many thanks,
B

[shikra]

Probably telemetry

Check #11 in faq
https://github.com/ShikOfTheRa/scarab-o ... ION/FAQ.md

[bulesz]

Thanks bro! I'm checkin out!

Another question, I'm not sure, does the MW OSD 1.3 support the latest Cleanflight 1.8.0 where there are separated ROLL and PITCH rates?

Many thanks,
B

[shikra]

It only supports combined pitch/roll

I have to idea how that works with new cleanflight. Hopefully it just means that feature is not there.
Realistically its never going to keep up with all option for multiwii/ baseflight / cleanflight and APM when thats released. Not enough memory - or time to do it. I wish...

[bulesz]

It only supports combined pitch/roll

I have to idea how that works with new cleanflight. Hopefully it just means that feature is not there.
Realistically its never going to keep up with all option for multiwii/ baseflight / cleanflight and APM when thats released. Not enough memory - or time to do it. I wish...

I know mate! and the PID's of the new and fixed PID Controller 2 (LuxFloat) make it even more difficult because they are stored in different value than the rest of the PID Controllers...ehhe...

Thanks for your hard work amigo!

[Leo]

I thought I'd post a short video of a flight using MultiWii OSD. I mounted a secondary camera on my QC for FPV duty and to display OSD information. However I have yet to fly FPV style. Too chicken ATM....



I would really like to see other video examples using MultiWii OSD so that I can compare them to mine.

Leo

[Benik3]

Hello.
I just downloaded R1.3 MW OSD, but there is an error in code for UBLOX GPS

Code: Select all

Arduino: 1.6.3 (Windows 8.1), Vývojová deska: "Arduino Nano, ATmega328"

GPS.ino: In function 'void SerialGpsPrint(char)':

GPS.ino:38:11: error: 'str' was not declared in this scope

GPS.ino: At global scope:

GPS.ino:48:4: error: 'prog_char' does not name a type

In file included from D:\arduino-1.0.5-windows\arduino-1.6.3\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from MW_OSD.ino:27:

GPS.ino: In function 'void GPS_SerialInit()':

GPS.ino:80:26: error: invalid conversion from 'const char*' to 'char' [-fpermissive]

GPS.ino:36:8: error:   initializing argument 1 of 'void SerialGpsPrint(char)' [-fpermissive]

GPS.ino:86:33: error: 'UBLOX_INIT' was not declared in this scope

Chyba kompilace.

The error exist also in latest source which I downloaded from code.google.com
Can you fix it please?
Thanks

[theailer]

Either install older version of arduino or download the beta version of mwosd.
FYI Google code is deprecated and I think you mean github.

[rubadub]

Hello.
I just downloaded R1.3 MW OSD, but there is an error in code for UBLOX GPS

Code: Select all

Arduino: 1.6.3 (Windows 8.1), Vývojová deska: "Arduino Nano, ATmega328"

GPS.ino: In function 'void SerialGpsPrint(char)':

GPS.ino:38:11: error: 'str' was not declared in this scope

GPS.ino: At global scope:

GPS.ino:48:4: error: 'prog_char' does not name a type

In file included from D:\arduino-1.0.5-windows\arduino-1.6.3\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from MW_OSD.ino:27:

GPS.ino: In function 'void GPS_SerialInit()':

GPS.ino:80:26: error: invalid conversion from 'const char*' to 'char' [-fpermissive]

GPS.ino:36:8: error:   initializing argument 1 of 'void SerialGpsPrint(char)' [-fpermissive]

GPS.ino:86:33: error: 'UBLOX_INIT' was not declared in this scope

Chyba kompilace.

The error exist also in latest source which I downloaded from code.google.com
Can you fix it please?
Thanks

I'm assuming that you're trying to set this up in 'GPS only' mode?

for the UBLOX_INIT problem, try changing prog_char to 'const char'

Code: Select all

const char UBLOX_INIT[] PROGMEM = { 

that worked for me.

the other two look like bugs.
the first is because that GPS_ground_speed variable is defined twice in GlobalVariables.h, it's first defined as int16_t and then re-defined in the #ifdef GPSOSD section further below as uint16_t. Shikra would have to take a look at this and fix it.

the second is because of this within GPS.ino

Code: Select all

#if defined(INIT_MTK_GPS) || defined(UBLOX)
  uint32_t init_speed[5] = {9600,19200,38400,57600,115200};
  //void SerialGpsPrint(prog_char* str) {
  void SerialGpsPrint(char) {
    char b;
    while(str && (b = pgm_read_byte(str++))) {
      Serial.write(b); 
      #if defined(UBLOX)
        delay(5);
      #endif      
    }
  }
#endif

the correct one looks like the commented out line.
not sure what shikra's intentions were here, perhaps he was messing around with it and forgot to go back and clean it up.
again, he'd have to take a look at it.

[Benik3]

I tried older Arduino IDE 1.0.5. There was still the error (It's true, that R1.3 pre4 wasn't able to compile with newer IDE then 1.0.5).

I didn't noticed, that it was migrated to github. I will try to download the latest trunk

I don't know what you mean with "GPS only mode", but I don't have anything external connected into the OSD. Whole data are taken from CleanFlight...
EDIT: Oh, now I see, that the GPS definitons are for standalone GPS without FC.
So when I have GPS connected into Flip32+, I don't need to declared it...
EDIT2: Anyway it's fixed in beta. Compilation works also with latest Arduino IDE 1.6.3

[mbeerer]

After a few headaches, I've finished setting up my MW OSD. I overcame a few things that I thought I'd pass along. I spent a lot of time reading here and watching the YouTube videos which were a lot of help. But I found a few solutions on my own that I didn't see anywhere else and I hope will be useful for others.

Setup:
Witespy MultiWii pro v3 black edition with MW2.4 firmware
Witespy minimosd with teamKV mod with MWOSD 1.3 firmware
Witespy power sensor (http://www.readytoflyquads.com/readytof ... wer-module)
Futuba R617 RX with RCexplorer RSSI mod (http://rcexplorer.se/diy/2011/01/lost-packet-indicator/)
Setup on a Mac

By far the largest headache was that I ran into the issue where the config GUI settings would not stick when I clicked the "write" button. I tried all the standard troubleshooting including checking RX/TX, firmware and GUI versions matched, and ensuring the FTDI was powered by a full 5V. Despite this, the settings would only write to the eeprom if the minimosd had just been flashed with the firmware (eeprom clear + MW OSD firmware). After that initial "write," no new settings would stick. Having to reflash the board before making a small setting tweak was very annoying. Then, I discovered that the settings would write if you first click the "default" button. I have no idea why this works but it does. So my workaround is to: click the "default" button, load a saved settings file, make changes, save settings, click "write" button, repeat.

I set up MW OSD config.h per the instructions including selecting the "witespy" board option. The minim board communicated with the MW board as expected. Although, I had to switch to a 2nd MW board because the first one I bought from witespy apparently had an issue with serial ports 0,1 and 3 which would not talk to the minim.

Next I worked on the voltage, current and rssi. One issue I ran into was that the bat1 (normally video) and bat2 (normally flight battery) were swapped. This was the case for both witespy minims I tested. This was fixed by switching the A0 and A2 pin labels in config.h in an if statement specifying settings for the witespy board. Next, I plugged in the flight battery to the witespy voltage/current sensor and wired it up the the minim. The voltage was way off (1.7V vs 12.4V with multimeter). I was not able to adjust the voltage using the config GUI parameters alone. I had to change the "5V voltage divider" in the firmware config.h. This is also found in the if statement with settings for witespy. I changed this value from 0.0008 to 0.0065. With this update, I was able to fine tune the voltage parameters in the config GUI to get the OSD voltage correct. Also note that I enabled the "5V Ref" option in the config GUI.

For the current sensor, I had to change the "Ampmax" parameter in config.h from 500 to 700. The current sensor is supposed to be 90A max, which implies the Ampmax parameter should be set to 900, but for some reason 700 worked. In the config GUI, I set the "amp offset" to 0, and "amp adjust" to the max value of 1023. This got the OSD current sensor to agree with my current guage.

Another quick tip is that when updating voltage and current adjustments in the config GUI, I had to restart the minim ("restart" button) and sometimes recycle power to get the update to show on the OSD. When I tweaked voltage settings, the OSD would first show a wacky value like 63V, but after restarting the correct value was shown.

If you're still reading, my last bit of information about the rssi. I knew getting this to work was a long shot because I hadn't seen this setup work anywhere else but I thought I'd give it a try. It seems to have worked! I was inspired my the RCexplorer Fatuba RX lost packet indicator (link above). I soldered a wire into RX LED as shown in the RCexplorer mod. However, I did NOT add the RC filter that RCexplorer shows. My reasoning was that it sounded like the LED was fed a PWM signal and the RC filter was used to convert PWM to a linear voltage. BTW, I'm not an electrical engineer so this may be have been a wrong assumption. I knew that the MW OSD could read a PWM RSSI, so I thought maybe I could connect the LED wire directly to the minim RSSI pin. In my first attempt, I enabled the "PWM RSSI" option in the config GUI. This did not work, I also tried enabling the "FASTPWM" option in config.h and that didn't help. Then I tried disabling the "PWM RSSI" and it worked! I'm not sure why this works if my understanding of the LED wire is correct, but it works. As the signal represents lost packets and not true RSSI, I had to switch the min and max RSSI adjustments in the config GUI. I set "RSSI MAX" to 2 and "RSSI MIN" to 90. I tested this by turning my TX on and off and also using the TX range test mode and walking away from the RX. The OSD RSSI seems to work perfectly varying between 100% and 0% as I moved away during the range test.

Sorry for the exhaustive data dump, but I felt some of these things could not be found elsewhere on the forums. Also, if you know why my RSSI work (or doesn't) I'd love to hear it.

[shikra]

Issues with writing config:

OK many had this issue but I could never replicate this.
Have release an updated release which addresses this and all other bugs raised. Its labelled as beta - but consider it as 1.3 with fixes !

https://drive.google.com/a/mitel.com/fo ... p=sharing#


Issues with Witespy boards:
At some point Witespy released a board with bat1/2 connections reversed. Also different resistor dividers for voltage.
I think since then the newer boards have bat 1/2 marked correct but still have different resistors.
I am in truth not sure which ones are which! - so basically try with / without it enabled in config.h!!

Voltages way off - normally this is when the vref has been changed, but osd noty reset. There is a note in the user guide to reflect this.

Current sensor:
Try using this to work out:
https://docs.google.com/a/mitel.com/spr ... edit#gid=0

RSSI:
I suspect its at a frequency which doesn't suit either normal or fastpwm. Probably the filtering in analogue mode is working out an average. I'd expect it to move around a little.
I may look to implement an "auto" PWMRSSI in future that will work across a very wide range of PWM frequencies.

Good for you hanging in there

[Benik3]

Thanks!
BTW I saw, that you changed description of Cleanflight definition to: // Undefine this if you are using CLEANFLIGHT versions prior to 7/3/2015
So what should I use, if i have newer version of CF (1.8.1 2/4/2015)?

Thank you

[rubadub]

anyone here running MWOSD on cleanflight over softserial/19200? If so, how's the performance?
I'm considering doing this, as I'm sick of unplugging the OSD serial link each time that I want to get into the GUI.
However, I was hoping that I could get some feedback before tearing up my miniquad in order to add the new softserial connections.

[shikra]

@benik3 - an update to support is being worked on.

For now... can still use //CLEANFLIGHT, but avoid using the page with RCrates etc....
Edit : I have hidden that page and clarified in config.h as an interim in master


@rubadub - I have seen people say they use it. not tried myself.
The horizon might be noticeably slower, but I doubt if you'll notice any difference for the rest!

Actually this bit of the code can be optimised... some requests are sent even if not used.
And we could choose to not take some data such as the horizon...
I'll put on the roadmap requests to do something here in the future.

Suggest to try and see...
In theory 6 times slower. In reality I think far less noticeable...

[Benik3]

Thanks for reply

Rubadub: I had it connected. It worked but I didn't flight with it. Now i use also Usart so i dont have to use second softserial...

[rubadub]

@benik3 - an update to support is being worked on.

For now... can still use //CLEANFLIGHT, but avoid using the page with RCrates etc....
Edit : I have hidden that page and clarified in config.h as an interim in master


@rubadub - I have seen people say they use it. not tried myself.
The horizon might be noticeably slower, but I doubt if you'll notice any difference for the rest!

Actually this bit of the code can be optimised... some requests are sent even if not used.
And we could choose to not take some data such as the horizon...
I'll put on the roadmap requests to do something here in the future.

Suggest to try and see...
In theory 6 times slower. In reality I think far less noticeable...

interesting, you might be on to something.
in my particular case (which I'm assuming is a popular one) of naze32+softser+miniquad, there's no real need for horizon/gps/etc., as only minimal stats are required (RSSI, voltage, flight time, arm/disarm status, and access to config menu). If you have an idea in mind on how to cut down the MSP traffic to a bare minimum for a slower baud on naze+softser, that would be great.

[shikra]

quick and dirty


#1 - find and remove:
if(!fontMode)
blankserialRequest(MSP_ATTITUDE);

#2 - find and add // like following:
modeMSPRequests =
REQ_MSP_IDENT|
REQ_MSP_STATUS|
// REQ_MSP_RAW_GPS|
// REQ_MSP_COMP_GPS|
// REQ_MSP_ATTITUDE|
#ifdef DEBUGMW
// REQ_MSP_DEBUG|
#endif
#ifdef SPORT
// REQ_MSP_CELLS|
#endif
// REQ_MSP_ALTITUDE;

NOTE.. need to add ";" if remove this last one.

#3 if using rssi or voltages from the FC, consider putting them direct to OSD and disabling "Use MWII" for RSSI and volts. This saves more comms !

[mbeerer]

@shikra Thanks! 1.3 SP2 works great and fixed the problem I was having.

Thanks for all your good work. I get headaches sometimes, but it's worth it when I figure out the solution.

[rubadub]

I just realized that there's a problem/bug with the serial protocol & compatibility with cleanflight.
Cleanflight splits pitch/roll rate into two separate values, whereas BF/MW uses a single value for both.
I tried changing these today via the OSD and discovered that it was broken. Seems like an easy fix though.

[shikra]

Its being worked on... avoid using the rc settings page. First two options are OK.

[fnurgel]

Hi,
For Arduino noobs like me, is there any information available on how to set up the MW_OSD_GUI to actually compile from the Arduino IDE?
The firmware was easy enough, but the gui seems to be missing libraries and whatnot.
I'd like to run from the git checked out code, but it's even complaining it doesn't have the correct dir structure?

[rubadub]

@shikra...
would it be possible to set something up where the OSD code can 'sniff' the serial line before attempting to transmit MSP commands in order to see if it's already in use? For example, if the line is free, go ahead and start transmitting. However If there's unrecognized traffic on the line, then wait for a timeout period to expire before re-checking and re-attempting to transmit. Could something like this be setup?

My idea is to find a way to allow for simultaneous connections to a single hardware serial port (UART1 on a naze) so that it can be used by both the OSD and the USB/GUI; i.e., the GUI can be used over USB without having to disconnect the OSD connection, and the OSD will automatically recover the link once the USB/GUI connection is disabled. Thoughts?

[Deet]

fnurgel, you shouldn't need to compile the GUI, it just runs under java

[Benik3]

Hi,
For Arduino noobs like me, is there any information available on how to set up the MW_OSD_GUI to actually compile from the Arduino IDE?
The firmware was easy enough, but the gui seems to be missing libraries and whatnot.
I'd like to run from the git checked out code, but it's even complaining it doesn't have the correct dir structure?

Download the 1.3 SP2 package. It contains the libraries
Then add them in the Processing through sketch->import library->Add Library...

BTW I tried to compile latest GUI few days ago and button for changing layout didn't work...

But yes, can you, shikra, add the latest libraries on github pls?

[fnurgel]

Doh, I was trying to use Arduino IDE, but it has to be the Processing IDE.
Works great now!

[shikra]

@rubadub - sorry its not possible it to operate how you would like. Its a physical hardware limitation.

What it can support is to have passthrough comms to the OSD.
This means the GUI can talk through the FC to the OSD.

The limitations are:
1 FC must support the functionality - haydent has a working version of multiwii
2 OSD must be on a different FC serial port to the GUI

The GUI has this support in today - although has to be enabled in cfg file.

Am not aware any plans for baseflight / cleanflight.

[shikra]

@ Benik3 - yes if they cause no other detriment. Assume you are talking mac / linux? I have put a compiled version of gui in beta for testing. Only change is serial lib...

[Leo]

I have a question:

Is it possible to have a colored background (e.g. pink) instead of a video picture coming from the camera?

[shikra]

pink card in front of camera??
or some sort of video generator.

[Leo]

So I guess your answer is no.

I thought maybe MWOSD can place an overlay or something similar behind the text.

[shikra]

fraid so - black / white or transparent are the only options

[Benik3]

I have windows

[therippa]

Is anyone else having a problem with the flight timer? Mine ticks too slowly... a 5 minute flight will only show 2 minutes on the timer. Any ideas what could be causing it?

[waltr]

Do the Baud rates on the OSD and FC match? If they are different but communications work then the OSD's oscillator is wrong.

Ensure the XTAL oscillator is running at the correct frequency.
If it is Check that the 'fuse' bits are properly set to use the external oscillator and not the internal RC one.

If you can't do this then return the board to the seller.

[Arakon]

It's a known issue in mwosd and should be fixed soon according to the github.

[pki]

As some other users has problems to connect the gui after update to 1.3 i like to post my experience here.

I loaded the official 1.3SP2 and got the same problem. Sketch uploaded sucessfully. GUI not connecting. OSD not sending data out. Tried even the 1.6.x arduino, then go back to 1.0.6, no difference.

After this i loaded 1.4pre - and seem it works out of the box. I think there is some bug in the 1.3SP2.

[cholo]

hi, I think many users is using receivers without standard rssi signal but with green led blinking with each properly received frame (frsky etc.).
I've one also so I've connected green led positive (via resistor) to the minimosd (MWOSD) and added simple code to count pulses and update rssi variable each second.
it will be great to integrate this functionality to sources and add additional mode to RSSI (e.g. MWii/PWM/LED).

Code: Select all

    // declare rssi led counter
    volatile int rssiCounter;
    ----
    // setup interrupt on rssi pin
    *digitalPinToPCMSK(PWMRSSIPIN) |= bit(digitalPinToPCMSKbit(PWMRSSIPIN));
    PCIFR |= bit (digitalPinToPCICRbit(PWMRSSIPIN));
    PCICR |= bit (digitalPinToPCICRbit(PWMRSSIPIN));   
    ----
    // calculate rssi each second (or 500ms)
    rssi = map(rssiCounter, Settings[S_RSSIMIN], Settings[S_RSSIMAX], 0, 100);
    rssiCounter = 0;
    ----
    // interrupt routine to count rssi led pulses
    ISR (PCINT1_vect) {
        rssiCounter++;
    }

[shikra]

@pki - am pleased to hear 1.4 pre is working well for you. For 1.3 - most likely issue if not connecting is lack of a suitable vsync signal. Disabling VSYNC in config may solve.
That said - stick with 1.4


@cholo
I see no reason not to include... thanks for contribution
Will be for 1.5 though as OSD features updates now frozen for 1.4
If you use github, submit a pullr equest if not let me know and I'll add to todo list

[shikra]

For those who don't follow FPVLAB forum...

R1.4 pre-release candidate #4 is available for beta testers ....
Below is a summary of bug fixes and new features.
As ever - test carefully. After feedback on:

Files in beta section of downloads
https://github.com/ShikOfTheRa/scara...N/Downloads.md


## Fixed issues since last full release R1.3: ##
BUG! "Use MW" options not saving backup file (single entry key)....
BUG! When set the "Time Zone Offset" to say 2.0 and then do a "WRITE" the value will change (display) to 0.2
BUG! Compass OK, but home arrow is inconsistent in fixedwing mode
BUG! compile errors for GPS in some Arduino versions
BUG! PID menu options after row 5 are incorrect. e.g. level does not show level settings
BUG! All versions - timer clock drifts over time
BUG! GPS OSD mode MTK - missing option to set 5hz update

## Improvements since last full release R1.3: ##
Fixedwing - Heading / compass support for controllers without MAG. Default assumes no MAG.
Fixedwing - Altitude support for controllers without BARO. Default assumes no BARO.
Fixedwing - Vario support for controllers without BARO. Default assumes no BARO.
Fixedwing - glidescope ILS
Fixedwing - reset altitude at arm option for height above ground level vs sea level
Support for newer Cleanflight releases
Horizon bar set behind other screen items as they have higher priority.
AUTOCAM now default option (Auto sense PAL / NTSC cam at startup) to help with incorrectly marked cams / user error.
VSYNC now default option as most boards now support this. Clearer display.
Added max Amps to flight summary
Decimalise GUI value for min battery voltage etc.
GUI support for FC passthrough configuration settings (access OSD config via FC).
Amended 00 font to be blank character - recommended to reduce sparklies
Provide optimisation and option for serial data requests for slower baud rates
3 OSD layouts for use with 3 way tx switch
Autodetect PAL/NTSC or timeout to last known settings (fix blank screen for incorrect labelled cams)

[Hifly]

Shikra,
Two issues I noticed in 1.4 (actually the second one is not related to 1.4, but has been there before):
1) in the GUI when changing the HUD in the layout editor, the all three HUD presets in the right upper corner will also change
2) when arming with switch the timer will start immediately even though the throttle is on min and motor not spinning. (for the time being I fixed it in the sketch by an additonal if-statement checking for throttle being greater than lowthrottle (plus 10))

Additionally, on the layout editor I'm missing the possibility to delete a HUD (mistakenly, I added a HUD but couldn't remove it again; at least I did not find a way how to do it)

[shikra]

@HiFly:

For 1 -
this is not ideal, but functions as planned. Because of way sim works and 2 or three position switches it was a quick and dirty way to change the screens. Its a little annoying and may get changed one day.

For 2 -
This is how it is planned to function. Have to also consider fixedwing where can be on low throttle for a long time.
I would be happy to include this as an option in config.h if you want to create a pull request on github - or propose code change

Deleting HUD - yeah thats not in there yet. Again GUI dev is very low on the agenda. Just have to ignore the extra layout for moment!


One bug to track down in 1.4 pre and hopefully can release the full one

[genivos]

Firmware used for the Naze32:
CleanFlight 1.7.2
CleanFlight 1.8.0
CleanFlight 1.8.1
BaseFlight latest

Firmware used for the Minim:
MWOSD R1.3
MWOSD R1.3SP2

Two different Minim boards used to test with.
NOTE that BOTH those boards worked fine with a Flip32+, CleanFlight 1.8.0 installed and running MWOSD R1.3.

As test, I installed a bluetooth module on the RX/TX pins on the Naze32. This works. I can read/write settings
on the Naze32 board from my phone through bluetooth. This to confirm the port is working well.

I'm using a 2.4ghz PWM receiver so I have only uart1 available. As test I connected an UHF PPM receiver to free
up UART2 to test with. Also this did not work.

I tested MWOSD with #define MULTIWII_V24 OR #define CLEANFLIGHT (not at the same time defined of course).
Baudrate set at 115200 on the Naze32 and MWOSD side.

In the MWGUI I configured everything as it was working on the Flip32+ (MWII or FC board settings (for 1.3 SP2) etc).

In cleanflight:
Feature -telemetry was set all the time (tried with telemetry enabled also).
MSP was set at Uart1 (standard) for the rest nothing.

Only the Minim is connected to RX/TX pins on the Naze32, nothing else.

In all scenarios the Minim does not get data (no volt reading, no horizon bar, no arm status, nothing).
At startup after connecting a battery I can already see it is not working correctly because the version
numbers are showing all zeros.

I did look in the faq (#11) from MWOSD to make sure I did not forget anything.

I don't know what to do anymore. I've been searching and trying for two days straight now.
I watched tons of movies of people configuring. I really hope somebody can tell me in steps what to configure:

- which version to use for CleanFlight 1.8.1 (or even 1.8.0 for now, I don't mind to go one step back as long as it works)
- MWOSD config.h
- MWOSD GUI, something specific?
- Naze32 / CleanFlight, what to think of to configure? AFAIK only MSP on UART1 and feature -TELEMETRY

Thanks so much for reading and if possible, helping

UPDATE1: tested a third type of minim (tested now green board, purple board and blue board) which has the same result, receiving no data and FW version at startup is 0.00.
UPDATE2: In the meanwhile, I also tested 1.4pre release of MWOSD, no result .. no data

[genivos]

Reply to myself, I found the culprit. Today I was lucky to receive another Naze32 from another order. I placed this one and voila, problem solved.
What bothers me is why the BT adapter was working on the port of the faulty Naze and the Minim refused to work. But OK, I will send it back as DOA or something.
It was already not working from the beginning.

[vadimr]

I have flip32+ and witespy kv modded OSD. I'm running cleanflight, everything seems to be connecting just fine, however the virtual horizon is working in the opposite direction. When the quad is tilted to the right, the virtual horizon displays the bar from top left corner to bottom right corner and vice versa. Also when I point the nose up, the bar goes all the way down. I've searched and searched but didn't find anything. I'm running the latest 1.4 Pre 1.3 build with cleanflight 1.8.1

[shikra]

Vadimr

That is correct operation.

It is opposite way to some of the Russian stuff I have flown if you are from that part of the world.

[vadimr]

Vadimr

That is correct operation.

It is opposite way to some of the Russian stuff I have flown if you are from that part of the world.

Thanks for the reply. No I'm from US, I'm comparing it to DJI mini OSD. On my DJI mini OSD the virtual horizon bar moves with the direction of the machine. For example if I tilt the multirotor to the right side the virtual horizon also tilts in the same direction (left rises, right lowers). I'm reading my post from last night and realizing that I was so tired that I actually wrote it in reverse. Right now when I tilt the quad to the right my virtual horizon doesn't go from top left to bottom right but instead goes from top right to bottom left. If it's by design, is there a way to reverse it? It's going to make switching between my DJI AP machine and this a bit less difficult

Thanks,
Vadim