Cleanflight aka Multiwii port to STM32 F10x and F30x

RC_Adik · Post by **RC_Adik** » Wed Jan 07, 2015 12:05 am

@markus1234
Thanks, I'll give it a try.

@nebbian
Great feature requests.

sandman_br · Post by **sandman_br** » Wed Jan 07, 2015 5:12 am

I update my mini quad fw from 1.x to 1.4. To do this i use the putty to dump my config and then i use clearflight cli to restore after burn new fw.

After that my quad flown a bit unstable but still flyable. I almost crashed some times but after 4 batteries i noted thar my fly modes was not set. I flow all the time in manual mode :lol:

My fly modes shouldn't be dumped and restored as all my other settings?

I never flown fpv in manual mode with this quad and i'm surprised how stable is this fw. luckly i not try to flip or roll this time. Im not a good pilot .

Its possible to use frsky telemetry and osd at same time in acro naze? when i enable the telemetry feature my taranis receives data after armed but osd doesn't work. If i disable this feature the taranis doesn't receive anything.

strepto · Post by **strepto** » Wed Jan 07, 2015 8:36 am

Haha, I never accused anyone of whining. I said whinging - it's completely different! (and I'd know, being an expert on the latter especially)

Ability to dump via cli from old firmware would solve the issue nicely anyway.

bulesz · Post by **bulesz** » Wed Jan 07, 2015 1:12 pm

Important note for RSSI channel for OpenLRS users:

The BaseFlight value "rssi_aux_channel=4" is = "rssi_channel=8" on the CleanFlight!!!!

And the channel number is limited to 4 in the GUI!!! So you can make it work in the CLI only!

Roeland54 · Post by **Roeland54** » Wed Jan 07, 2015 1:19 pm

This should resolve some frustration : https://github.com/cleanflight/cleanflight-configurator/pull/44

sandman_br wrote:My fly modes shouldn't be dumped and restored as all my other settings?

This is related to this : https://github.com/cleanflight/cleanflight-configurator/issues/36

snakescb · Post by **snakescb** » Wed Jan 07, 2015 1:54 pm

Hi all,

impressed after moving from baseflight to cleanflight, and impressed about the professionality and the attitude of the developers, a big thank you!!!

But I have questions, don't know if this are bugs or I am not able to understand it, so probably the more experienced of you can help me, I hope. Here the situation: Cleanflight 1.4 on Naze32 acro, in an QAV250 quad. MinimOSD with MW OSD R1.2 connected to UART2. FrSKY TFR4-B connected to CH1, RSSI to CH2 with an good LP filter. Enabled RSSI_ADC feature. serial_port_1_scenario = 5 and serial_port_2_scenario = 8. (Almost) everything working like a charm with impressive stability and agility. Flying this is great. Now the problems:

Problem 1:
RSSI is not working as it should. In the configurator, I can see that RSSI is measured, but I dont understand the RSSI_SCALE parameter. When I set it to 25, the max value is about 98%, this is ok, but when I switch the RX off, it goes down to 54% (in baseflight it went to 0%). What is the RSSI_SCALE actually doing? Wouldn't it make more sense to have an RSSI_ADC_MIN and RSSI_ADC_MAX parameter? BTW, how can i see the raw adc value? Is there a possibility?

Problem 2:
On the OSD, everything is great, but RSSI is always 0%. This was taken from the FC correctly in baseflight, but with cleanflight it is just 0. However, artificial horizon, armed state and Battery voltage are displayed correctly, and I can make PID adjustments from the Transmitter. The only problem is RSSI.

Problem 3:
I thought the GPS passthrough feature would be great for OSD too. But I am unable to connect the MW OSD GUI to the MinimOSD via the USB connector on the FC. This would be great for me as it is difficult to connect an FTDI prog to the OSD, everything is shrinked together. If I set serial_port_2_scenario to 7 (gpspassthrough only) I am unable to to enter the passthrough mode, CLI tells me to enable GPS first. If I set serial_port_2_scenario to 2 (GPS only) i can enter passthrough mode, but the MW OSD GUI has no connectivity to the OSD. Any Ideas?

Any help is appreciated, thanks

Regards
Christian

Rust · Post by **Rust** » Wed Jan 07, 2015 4:05 pm

Made a GPS Hold test with the latest V1.4.0. Works GREAT! Settings in the description

https://www.youtube.com/watch?v=Y0-MWSg ... e=youtu.be

Spirre · Post by **Spirre** » Wed Jan 07, 2015 5:31 pm

Hi,

I've been trying to get my cheap HK GPS to work with Cleanflight, but no success. This is an 4800 buad GPS and what I can see is it not possible to change baud rate on it. I've another 38400 baud GPS and that works just fine, but it is a bit clumsy for my little 250 quad.
I'm using softserial.

With gpspassthrough I can see that the naze board is receiving the signal and I can read it from the RX/TX pins.
Is this even possible?

Regards
Rickard

sandman_br · Post by **sandman_br** » Thu Jan 08, 2015 12:42 am

Roeland54 wrote:This should resolve some frustration : https://github.com/cleanflight/cleanflight-configurator/pull/44

sandman_br wrote:My fly modes shouldn't be dumped and restored as all my other settings?

This is related to this : https://github.com/cleanflight/cleanflight-configurator/issues/36

thank you!

nepalien · Post by **nepalien** » Sat Jan 10, 2015 12:12 am

I just updated to the latest Cleanflight firmware and now it keeps disarming after 5 sec when the throttle is at the lowest position. Is this a new feature??

SecretSpy711 · Post by **SecretSpy711** » Sat Jan 10, 2015 2:53 am

Hi dominic,
I'm trying out cleanflight, coming from a working baseflight configuration on an afromini... I flashed the latest naze cleanflight firmware, set up for rx_ppm input but it does not register any commands from my radio. None of the bars are moving in the receiver tab of cleanflight. My taranis is set to 12 channel PPM, "22.5us 300u -". It has not changed from when it was working with baseflight. What could be wrong? Just to make sure I wasn't crazy I flashed back to baseflight and everything still works there.

edit: here's a video to more accurately show what the problem is:

SecretSpy711 · Post by **SecretSpy711** » Mon Jan 12, 2015 1:57 am

Solved.

While fiddling with this today, I realized that even though I need more than 8 channels in total, I only need 8 within the PPM stream. So I went into the DTF UHF settings and realized that I had it set to 16 channels instead of 12 or 8 , and also the option to "limit ppm output to 8 channels" set to "no." I must have done that a while back, thinking one day I might have a need for 16 channels.

Setting it to 12 channels instead of 16 solved the problem. Setting the option to "limit ppm output to 8 channels" set to "yes" also worked, when it was still set to 16-channel PPM.

HFMan · Post by **HFMan** » Mon Jan 12, 2015 7:03 am

Glad that solved it...but still have to wonder why it worked on Baseflight and not Cleanflight when it was set to 16 channels.

Frank · Post by **Frank** » Tue Jan 13, 2015 3:08 pm

Hi, just a short question. As weather is getting better now I would like to give cleanflight a shot but don´t have a proper flightcontroller available. Which one would be the best one for cleanflight (in terms of properly tested & performance) ? Naze32v5 ?

waltr · Post by **waltr** » Tue Jan 13, 2015 6:17 pm

Or any of the Clones: Flip32, Switft32, DragonFly32 all work.
I use the Flip32.

SecretSpy711 · Post by **SecretSpy711** » Tue Jan 13, 2015 6:32 pm

HFMan wrote:Glad that solved it...but still have to wonder why it worked on Baseflight and not Cleanflight when it was set to 16 channels.

Dominic posted a binary on the github issue tracker that also fixed it. It was a simple change of just writing "16" instead of "12" in 2 places.
https://github.com/cleanflight/cleanflight/issues/343

It worked in baseflight because baseflight only takes the first 8 channels and ignores the rest. Cleanflight first looks at the PPM stream, and validates the number of channels before using it.

Here's a video of how the cleanflight PPM parser is better than baseflight's:
https://www.youtube.com/watch?v=EViw4lBRa94

Frickelpiet · Post by **Frickelpiet** » Tue Jan 13, 2015 7:37 pm

Hello!

I want to connect a Jeti receiver (Rsat2) with a Naze32. I have installed CF 1.5, Port UART2 is set to Serial RX, Receiver Mode is set to RX_SERIAL, Serial Receiver Provider is set to SUMD. SOFTSERIAL is activated and the receiver is connected with Pin 1. I have also tried using Pin 4, but nothing didn’t work. Do anybody have an idea what’s wrong?

Best: Piet

uk-Pedro · Post by **uk-Pedro** » Tue Jan 13, 2015 10:23 pm

I've come up against two issues which I want to check if anyone else has them before I open an issue in github. The below is with configurator 0.59.1 and firmware 1.4.0.

Low Voltage alarm beeping when connected to USB. I have my voltage monitor settings as shown below but when connected via USB the "Battery Voltage" reported in the info part of the Cleanflight GUI is 1.1v, so below the minimum value. Is this triggering the alarm? Does anyone else have this issue and if so did you resolve it?
set vbat_scale = 110
set vbat_max_cell_voltage = 43
set vbat_warning_cell_voltage = 34
set vbat_min_cell_voltage = 33

Can't connect to Cleanflight GUI with MinimOSD + battery. If I connect via USB without the battery plugged in then everything works as expected. If I connect the battery first then it won't connect. If I remove the MinimOSD then I can connect whilst the battery is plugged in. Has anyone else seen this issue? If so did you resolve it?

Thanks in advance,
Pedro

arachnida · Post by **arachnida** » Tue Jan 13, 2015 10:37 pm

Frickelpiet wrote:Hello!

I want to connect a Jeti receiver (Rsat2) with a Naze32. I have installed CF 1.5, Port UART2 is set to Serial RX, Receiver Mode is set to RX_SERIAL, Serial Receiver Provider is set to SUMD. SOFTSERIAL is activated and the receiver is connected with Pin 1. I have also tried using Pin 4, but nothing didn’t work. Do anybody have an idea what’s wrong?

Best: Piet

Jeti Rsat2 is a PPM receiver, connect it to pin 1 and set CleanFlight to PPM. The connections next to pin 1 are GND and Vcc, so you can use a servo cable (Twisted if available).

Frickelpiet · Post by **Frickelpiet** » Wed Jan 14, 2015 4:43 pm

arachnida wrote:Jeti Rsat2 is a PPM receiver, connect it to pin 1 and set CleanFlight to PPM. The connections next to pin 1 are GND and Vcc, so you can use a servo cable (Twisted if available).

That's it! Thank you! Works perfectly!

Best: Piet

strips · Post by **strips** » Fri Jan 16, 2015 2:59 pm

Can Cleanflight use a GPS by I2C? I've got a GPS with both UART and I2C.

Regards
Stian

dominicclifton · Post by **dominicclifton** » Fri Jan 16, 2015 3:36 pm

strips wrote:Can Cleanflight use a GPS by I2C? I've got a GPS with both UART and I2C.

Regards
Stian

Not as yet. Maybe open a feature request ticket for that on github and if enough people request it we can take a look. Please provide details of the GPS RX that you want to use that has an i2c port in the ticket please.

dominicclifton · Post by **dominicclifton** » Fri Jan 16, 2015 3:39 pm

uk-Pedro wrote:I've come up against two issues which I want to check if anyone else has them before I open an issue in github. The below is with configurator 0.59.1 and firmware 1.4.0.

Low Voltage alarm beeping when connected to USB. I have my voltage monitor settings as shown below but when connected via USB the "Battery Voltage" reported in the info part of the Cleanflight GUI is 1.1v, so below the minimum value. Is this triggering the alarm? Does anyone else have this issue and if so did you resolve it?
set vbat_scale = 110
set vbat_max_cell_voltage = 43
set vbat_warning_cell_voltage = 34
set vbat_min_cell_voltage = 33

Can't connect to Cleanflight GUI with MinimOSD + battery. If I connect via USB without the battery plugged in then everything works as expected. If I connect the battery first then it won't connect. If I remove the MinimOSD then I can connect whilst the battery is plugged in. Has anyone else seen this issue? If so did you resolve it?

Thanks in advance,
Pedro

This is expected since the ADC pin on the MCU is getting a bad signal when you don't have your main flight battery connected to the VBAT header. On the Naze the RX/TX pins are shared with USB so that is also expected. It's a hardware limitation.

strips · Post by **strips** » Fri Jan 16, 2015 3:50 pm

dominicclifton wrote:Not as yet. Maybe open a feature request ticket for that on github and if enough people request it we can take a look. Please provide details of the GPS RX that you want to use that has an i2c port in the ticket please.

Done, https://github.com/cleanflight/cleanflight/issues/363

For anyone wanting to use SBUS on UART2 and still use GPS at full rate this might be the way to go (until I buy a Sparky). This would simplify the wiring. Just having four wires for GPS, mag and baro.

tungsten2k · Post by **tungsten2k** » Fri Jan 16, 2015 8:58 pm

nepalien wrote:I just updated to the latest Cleanflight firmware and now it keeps disarming after 5 sec when the throttle is at the lowest position. Is this a new feature??

It is ! It caught me off guard at first, but after thinking about it, it's a great idea that makes CF far safer by default than without. I myself have armed, then gotten distracted by something I realized wasn't ready, leaving the craft armed while I go about my business. This new default will surely save a few injuries in the long run.

auto_disarm_delay is configurable to "0" the CLI if you want to return to the previous behavior.

-=dave

uk-Pedro · Post by **uk-Pedro** » Fri Jan 16, 2015 9:37 pm

dominicclifton wrote:
This is expected since the ADC pin on the MCU is getting a bad signal when you don't have your main flight battery connected to the VBAT header. On the Naze the RX/TX pins are shared with USB so that is also expected. It's a hardware limitation.

Thanks for the explanation.

Regards,
Pedro

tungsten2k · Post by **tungsten2k** » Sat Jan 17, 2015 5:38 am

Best platform to compile from source on ? (i'm on a Mac so plan to just cut off a VM to dedicate to this)

-=dave

stronnag · Post by **stronnag** » Sat Jan 17, 2015 8:37 am

Linux or OSX, from the various discussions on IRC

strepto · Post by **strepto** » Sat Jan 17, 2015 10:45 am

Question for the gallery:

Why did the behaviour of the CLI change, so that now you have to type "save"?

I was delighted when I found out the BF configurator did this automatically, and reconnected automatically, just by clicking another tab.

Now I have to type save, wait for the board to reboot, and then disconnect/reconnect. Or am I missing something?

PokkaGold · Post by **PokkaGold** » Mon Jan 19, 2015 2:21 am

What is the command I should put in CLI so that on my Receiver tab all those Channel Numbers are as close to 1500?

Mine can't stay on 1500. Keeps on increasing & decreasing.

turdsurfer · Post by **turdsurfer** » Mon Jan 19, 2015 2:32 am

I'm confused about the GPS flight modes, that I'm setting up for the first time.
I've configured my transmitter to use all flight modes on 1 channel (horizon - acro - GPS hold - GPS home), and configured the modes in the controller accordingly using the GUI.

Now I read this in the documentation about the GPS flight modes:
"This mode should be enabled in conjunction with Angle or Horizon modes and an Altitude hold mode."

Does that mean I must use the GUI to configure the Horizon and Alt-Hold modes to be active in parallel to a GPS mode?
Isn't Cleanflight able to just pick and use the required extra modes it needs when in one of the GPS modes?

strips · Post by **strips** » Mon Jan 19, 2015 5:53 am

strepto wrote:Question for the gallery:

Why did the behaviour of the CLI change, so that now you have to type "save"?

I was delighted when I found out the BF configurator did this automatically, and reconnected automatically, just by clicking another tab.

Now I have to type save, wait for the board to reboot, and then disconnect/reconnect. Or am I missing something?

What do you mean? I have had to type save since I started using Baseflight / Cleanflight about 1 year ago.

scrat · Post by **scrat** » Mon Jan 19, 2015 2:20 pm

strips wrote:
strepto wrote:Question for the gallery:

Why did the behaviour of the CLI change, so that now you have to type "save"?

I was delighted when I found out the BF configurator did this automatically, and reconnected automatically, just by clicking another tab.

Now I have to type save, wait for the board to reboot, and then disconnect/reconnect. Or am I missing something?

What do you mean? I have had to type save since I started using Baseflight / Cleanflight about 1 year ago.

In baseflight you just hit exit and it's automatically save changes.

stronnag · Post by **stronnag** » Mon Jan 19, 2015 5:55 pm

Cleanflight was changed to avoid flash wear from unnecessary writes to the EEPROM. Save is required.

RC_Adik · Post by **RC_Adik** » Mon Jan 19, 2015 6:39 pm

Doesn't typing "exit" also save & exit CLI?

powdermnky007 · Post by **powdermnky007** » Mon Jan 19, 2015 6:51 pm

it does on baseflight, but not in cleanflight.

It has already saved me once. I accidently set a value to zero when trying to check it. I just clicked out of CLI without saving, and got back in. Boom, my previous value was still there. yay!

strepto · Post by **strepto** » Mon Jan 19, 2015 9:48 pm

Flash wear? Really? Ummm, ok.

The baseflight behaviour means you can just click out of the tab when you're done with the cli. No need to type save or exit or anything. That's what I'm referring to. It autosaves, reboots, and exits the cli tab and reconnects to the board automatically.

If you bugger up a variable you can always just disconnect the board and power cycle it surely?

Anyway I was just curious as it seemed like a step backwards to me, to force people to manually save and then reconnect the board afterwards...

IceWind · Post by **IceWind** » Mon Jan 19, 2015 9:59 pm

Hey guys, I was testing the latest RC version for the NAZE to try out the Oneshot125 feature and noticed the
following, whenever I calibrate the gyros the ESC's beep like when when start.
Seems that the code is reseting the esc signal when gyro calibration ends.
Is that expected?

strips · Post by **strips** » Mon Jan 19, 2015 10:04 pm

Don't like it. CLI is CLI. It should not do anything automatically. It should only do what you ask of it. That's what I like with CLI. Just like good old DOS 3.3 I started using in ~93.

powdermnky007 · Post by **powdermnky007** » Mon Jan 19, 2015 10:06 pm

You have to click save in every other window... seems to follow the same principle.

RC_Adik · Post by **RC_Adik** » Mon Jan 19, 2015 11:12 pm

I go along with that logic, but you don't have to re-connect after each one.

PIKE408 · Post by **PIKE408** » Tue Jan 20, 2015 9:33 pm

This is my first setup with a Naze32. I have been doing alot of reading and researching on my own. Just have some loose ends that I want to tie up before I begin.

My setup:
Naze32
Frsky D4R-II
Frsky Taranis
GPS from Witespy (uBlox 6M GPS Module V2)
Ordering OSDoge

My question is. If I configure my D4R-II in CPPM mode I will output RSSI on channel 2 for the OSDoge. Also in Cleanflight if I enter this is my CLI will this give me the proper settings to display my RSSI and telementy on my OSD and also send it back to the Taranis? My RX out of my D4R-II will be connected to pin 5 on the Naze32

Here is what I will put in CLI.

feature telemetry
feature softserial
set telemetry_provider=0
set serial_port_3_scenario = 4
set serial_port_1_scenario = 5
set telemetry_provider=0
set telemetry_inversion=1

for GPS (pins 3 and 4)
feature GPS
set serial_port_2_scenario = 2
set gps_baudgps_baudrate = 115200
gps_provider = 1
gps_sbas_mode = 2

Sorry for the long bit on info but this is all new to me and I need all the help I can get. Thanks guys !

Exidous · Post by **Exidous** » Wed Jan 21, 2015 11:50 am

I just thought I would post what I had to do to get my setup to work.

My goal was to have:
Naze32
OSDoge
BT(HC-06)
GPS(witespy 36x36 M8N)
and FrSky Telemetry

The OSDoge automatically takes up UART 1 so nothing else can be used there except the USB obviously. UART2 is left to GPS duty. This leaves BT and Telem to the SoftSerials.

I will admit I was never able to get both to work on SS simultaneously.

CF Programming
UART1=Scenario 5 (MSP,CLI,GPS Passthrough 115.2K)
UART2=Scenario 2(GPS 115.2K)
SS1=Scenario 8 (BT/MSP 19.2K default)
OR
SS1=Scenario 4 (FrSky Telemetry 9.6K default)(pin 6)

An important note about pin assignment. UART 2 is pins 3/4 TX/RX. HOWEVER softserials 1 and 2 are pins 5/6 & 7/8 but RX/TX. They are the reverse of the hardware serials! https://github.com/cleanflight/cleanflight/blob/master/docs/Board%20-%20Naze32.md See bottom of page

I tried running Scenario 4 on SS 2 but it would kill the BT connection on SS1. The Telemetry would work though. I'm now sure why this is. I had set data rate on the BT and MSP to 9.6K. Had to change the OSD to 9.6K as well making it quite sluggish.

To get the BT to communicate properly I used an FTDI and a program called HT Comm by http://www.hobbytronics.co.uk/bluetooth-module these guys. Only need 5v/3.3v(depending on board), GND,TX and RX as most boards are in command mode(LED blinking) when not connected to another BT device. Key and others are not needed.

Command: After each accepted command you will get "OK" back.
AT (check connection)

AT+BAUD5 (19.6K)
pick one
AT+BAUD8 (115.2K)

AT+ENABLEIND0(disables indicators)(important)

AT+NAMEMONKEYTOOTH(changes ID)

AT+PIN<nnnn>(where nnnn equals 4-digit code)

That's it. To test the link using a computer with BT. Connect the TX and RX of the BT dongle together. Link up to the dongle with a BT enabled computer. By connecting via BT the dongle will not start up in command mode and will not accept AT commands. Open up HT comm. Set port and data rate for whatever you set the dongle too. Anything you type should show up in the box below rather than an OK response. This verifies full operation of the BT dongle. If you get gibberish back the data rate is probably wrong somewhere.

Once the MWOSD version 1.3 release(within the next week) is out I'll update this post to include full settings and dumps that I used for everything.

strips · Post by **strips** » Wed Jan 21, 2015 12:20 pm

Exidous wrote:I just thought I would post what I had to do to get my setup to work.

My goal was to have:
Naze32
OSDoge
BT(HC-06)
GPS(witespy 36x36 M8N)
and FrSky Telemetry

The OSDoge automatically takes up UART 1 so nothing else can be used there except the USB obviously. UART2 is left to GPS duty. This leaves BT and Telem to the SoftSerials.

I will admit I was never able to get both to work on SS simultaneously.

CF Programming
UART1=Scenario 5 (MSP,CLI,GPS Passthrough 115.2K)
UART2=Scenario 2(GPS 115.2K)
SS1=Scenario 8 (BT/MSP 19.2K default)
OR
SS1=Scenario 4 (FrSky Telemetry 9.6K default)(pin 6)

An important note about pin assignment. UART 2 is pins 3/4 TX/RX. HOWEVER softserials 1 and 2 are pins 5/6 & 7/8 but RX/TX. They are the reverse of the hardware serials! https://github.com/cleanflight/cleanflight/blob/master/docs/Board%20-%20Naze32.md See bottom of page

I tried running Scenario 4 on SS 2 but it would kill the BT connection on SS1. The Telemetry would work though. I'm now sure why this is. I had set data rate on the BT and MSP to 9.6K. Had to change the OSD to 9.6K as well making it quite sluggish.

To get the BT to communicate properly I used an FTDI and a program called HT Comm by http://www.hobbytronics.co.uk/bluetooth-module these guys. Only need 5v/3.3v(depending on board), GND,TX and RX as most boards are in command mode(LED blinking) when not connected to another BT device. Key and others are not needed.

Command: After each accepted command you will get "OK" back.
AT (check connection)

AT+BAUD5 (19.6K)
pick one
AT+BAUD8 (115.2K)

AT+ENABLEIND0(disables indicators)(important)

AT+NAMEMONKEYTOOTH(changes ID)

AT+PIN<nnnn>(where nnnn equals 4-digit code)

That's it. To test the link using a computer with BT. Connect the TX and RX of the BT dongle together. Link up to the dongle with a BT enabled computer. By connecting via BT the dongle will not start up in command mode and will not accept AT commands. Open up HT comm. Set port and data rate for whatever you set the dongle too. Anything you type should show up in the box below rather than an OK response. This verifies full operation of the BT dongle. If you get gibberish back the data rate is probably wrong somewhere.

Once the MWOSD version 1.3 release(within the next week) is out I'll update this post to include full settings and dumps that I used for everything.

Do you need TX from OSD? If not couldn't you use BT (TX and RX) and OSD (RX) on UART1?

Exidous · Post by **Exidous** » Wed Jan 21, 2015 2:01 pm

I had tried that and I have certainly seen plenty of folks and pictures that say the same but my OSDoge (pretty much a KVTeam board copy operationally) would not work. This MAY be firmware based as I'm using the most recent version of MWOSD. I would certainly have preferred to have the BT on UART 1. I only need the BT while disarmed and OSD while armed.

Upon startup the OSD lists OSD FW and tries to list FC version. If the TX from the FC is not connected it says the version is 0.0 and I'm assuming is does not know which protocol to use and defaults to onboard sensors only. Will investigate further.

I think I'll try an older version of MWOSD and KVOSD to see if it will work with only the FC's TX connected.

waltr · Post by **waltr** » Wed Jan 21, 2015 3:46 pm

Exidous wrote:I had tried that and I have certainly seen plenty of folks and pictures that say the same but my OSDoge (pretty much a KVTeam board copy operationally) would not work. This MAY be firmware based as I'm using the most recent version of MWOSD. I would certainly have preferred to have the BT on UART 1. I only need the BT while disarmed and OSD while armed.

Upon startup the OSD lists OSD FW and tries to list FC version. If the TX from the FC is not connected it says the version is 0.0 and I'm assuming is does not know which protocol to use and defaults to onboard sensors only. Will investigate further.

I think I'll try an older version of MWOSD and KVOSD to see if it will work with only the FC's TX connected.

From what I understand the OSD (KV OSD & MWOSD) queries the FC for data with MSP commands. So it does not work without both TX & RX lines connected.

Exidous · Post by **Exidous** » Wed Jan 21, 2015 3:59 pm

I didn't know that information was requested. I thought the MSP simply sent out all data in a specified format and the device simply used what it needed. I'd be interested to know more about how MSP works in a Bidirectional environment.

stronnag · Post by **stronnag** » Wed Jan 21, 2015 5:59 pm

If you turn on CF telemetry it spews out data it thinks you might need, unfortunately including (big) MSP_BOXNAMES every cycle, which is not good for low bandwidth links. This is why the mission logger apps (ez-gui, mwp, wingui) poll for the data they want. I would expect OSDs to do the same.

strips · Post by **strips** » Wed Jan 21, 2015 8:19 pm

It just dawned on me. It's not possible to invert an external mag i Cleanflight is it?

I have been messing around and finished my build with a mag on the GPS board. The mag is mounted on the underside of the GPS board. So I need to give it 180 deg roll.

Crap, now I have to get in to developing!

waltr · Post by **waltr** » Wed Jan 21, 2015 10:11 pm

Exidous wrote:I didn't know that information was requested. I thought the MSP simply sent out all data in a specified format and the device simply used what it needed. I'd be interested to know more about how MSP works in a Bidirectional environment.

Read the MultiWii Wiki on MSP to learn the format and basic commands/responses. Then go into the CleanFlight source code to learn about the new CF only MSP commands.

Then look at the Source code for KV OSD or MW OSD to see the MSP commands that the OSD sends to the MWC to request data.