FrSky S.Port Data into MultiWii, MSP & OSD (inc. cell graph)

[haydent]

ok, simple fix, my patch mvc patch needs updating. mw changed cells data to 130 to in protocol.cpp make it:
#define MSP_CELLS 130 //out message Battery Cell Voltages

[mikez104]

Whoo Hoo, it worked. Thank you. Looks good just like the picture. All the data is accurate and matches the lipo sensor. Do you think the current sensor could be the same sort of issue? I looked through the other MSP_ entries and didn't see one that really said anything about current or amps.

[haydent]

no, that is likely another problem. as it uses the existing msp current variable. have you checked if you get a current reading in mw gui ?

[mikez104]

Nope, just checked and it's 0.

[haydent]

so i just checked mine and it is working. can you try only using SPORT_FCS in config.h then you should see the voltage measurement from the current sensor as well. as currently if SPORT_FLVSS is enabled you dont, only using current from FCS . also silly question, but you actually do have a load plugged in pulling some current no ?

[mikez104]

So I did what you said and got the voltage from the SPORT_FCS which told be that the unit is working and the data is getting through. I have a watt meter before the battery and that measures .5 amps but I was still getting 0A on the OSD. I put a bigger load on the FCS and I got a reading although it is incorrect. The FCS unit is measuring about half of the current that my watt meter said is going through the unit. Not sure why it reads low. Wonder if there is some way to calibrate it.

But the good news is that it works just fine. Thanks again for all your help!

[haydent]

yeah i have that problem too, not sure what it is, frsky reads .7 amp when watt meter says about 1.1 ... this will throw out the mah reading too... there is this firmware here but it mentions nothing of accuracy... http://www.frsky-rc.com/download/view.p ... re-FCS-40A

with some googling i see this here: http://openrcforums.com/forum/viewtopic ... 369#p76657

so sure it would be easy enough to add a constant amount to the reading if was constant accross the range which it may not. you would have to test its accuracy at different amperages to find out....

it may just be its tolerance at low amps...

[mikez104]

Yeah, it isn't much good if it is not accurate. I made a post on the frsky forum. Maybe we'll get an answer?

http://www.frsky-rc.com/BBS/viewtopic.php?f=5&t=6786&sid=2b0a63bd8e0f2517b42ccd9b1b1896d2

[haydent]

thanks. can you compare the readings in your tx and that on the osd, compared with your watt meter, are osd and tx same ?

[haydent]

here's up to date version (no real changes to features) of the sport code as a patch against r1745, in the hope of getting it merged into the shared trunk and hopefully eventually a full release. please critique my code and suggest any improvements. i modelled the integration on the way gps has been.

[TheBum]

My main criticism right off the bat is adding all that code to Protocol.cpp. It adds a lot of clutter and makes the file more difficult to wade through, especially for a capability with such a small audience. I'd prefer the code of that magnitude be in its own source file with calls into it from Protocol.cpp, MultiWii.cpp, etc.

[haydent]

fair point, and thank you for your feedback, originally in 2.3 that's how i did it with sport.h and sport.cpp files see: (https://code.google.com/p/multiwii-osd/ ... rsky_sport) but before making this latest patch and submission i asked where was the best place for it as had been previously been advised multiwii did not want any new files, and alex suggested in protocol.

[TheBum]

Then I would suggest you add prevalent banners at the beginning and end of the S.Port code (and that suggestion applies to any other device-specific code that comes later from whomever). That way, sections of contiguous device-specific code can easily be found or skipped while doing a quick scan of the file.

Sorry, I realize these seem like nits, but I've been programming professionally for 23 years and have had to modify my fair share of run-on code. Anything that eases the process is a big plus in my book. Another reason I'm being nit-picky is because I'll likely be adding my own code for Graupner HoTT telemetry. I do like your idea for checking for the existence of the S.Port sensor on Serial0 at startup and falling back to MSP; I'll do the same for detecting whether the telemetry line is connected between the receiver and the MW board. I use a Mega board so it's not an issue for me (no shortage of serial ports), but I want this code to be usable for any board that MWC supports.

[haydent]

thanks,i will add that. you may think mega has plenty but not really, you just osd, gps, s.bus, and s.port and all 4 are taken up meaning you have to share #0 between gui and something else, thus the fallback, to msp when you have the s.port unplugged, i actually got the idea from the gps code that used to do it for mini's, but i cant find it in latest so curious why they scrapped it...

[mikez104]

thanks. can you compare the readings in your tx and that on the osd, compared with your watt meter, are osd and tx same ?

Well, it took me a little while to test that as I have had other things going on but here is what I found.
Equipment used
Frsky smart port 40A current sensor
Hobby King HK-010 watt meter
Fluke 115 multimeter
RTFQ - EZ3.0 flight controller
RTFQ - minum OSD
3S battery
resistive load (couple of 20W 12V light bulbs)
Taranis

The order of equipment hookup was
Battery > Fluke MM > HK-101 - Load

Test #1
Fluke - .34A
HK-010 - .24A
Radio - 0A
OSD - 0A

Test #2
Fluke - 2.0A
HK-010 - 1.9A
Radio - 1.4A
OSD - 1.4A

Test #3
Fluke - 3.6A
HK-010 - 3.5A
Radio - 3.0A
OSD - 3.0A

Looks like the sensor is consistently off by .5~.6 amps. When I posted that it was off on the Frsky forum, they replied and said that there is an offset in the Taranis. I asked if there was a way to adjust this or calibrate in the firmware and their reply was no. The Taranis adjustment seems to work pretty well. Perhaps you can add an offset to fix this for the OSD in the config.h when you enable the sensor?

[haydent]

thanks for this, i can add an offset easy enough. "The Taranis adjustment seems to work pretty well" do you mean by this there is an offset setting in taranis or not ?

[mikez104]

Yes, in the telemetry section of the model setup, you can supply an offset. It is on page 12 and is called FAS offset. You can enter from -12A to +12A in .1A increments. The .6V value I entered corrected the radio across the several current tests. I found a few more lights and I put them in parallel to increased the load to 6.5A and the reading was still correct on the radio but the OSD was still .6A low so the error does not increase as the current increases. Well, at least not up to my test of 6.5A...

[haydent]

thats good to know. actually the offset will have to be set in multiwii, as it calculates the mah and puts that in the msp too. so in sport.cpp:

change

Code: Select all

current *= 100;// convert 10ths amp to milliamps

to

Code: Select all

current *= 100;// convert 10ths amp to milliamps
current += 600;//increase current reading by offset for accuracy

[mikez104]

Yep, that made it match the reading on my transmitter. I think you said yours was off also I'm wondering if it is off the same .6A.

[mikez104]

Hi. So the parts I was waiting for finally came in. I find that I will need com 0. I have a USB asp that I flash my ESCs with so I guess that will work. And I see the time I need to flash but I've not done that before. Is there a one sheeter on how to do that? Can I just use the arduino software?

[haydent]

are you talking about loading the bootloader i put up that lets you use com0 ? if so yeah usbasp and ide will work. you will need to load the boot loader file into the ide as a new board profile, or replace the bootloader file of an existing profile

[mikez104]

Yep, that's what I mean. I'm not real sure what you are saying but I'm sure it will be more clear when I get the ISP in front of me. Traveling again this week . can't wait to get this all going. Thanks again for your support as I fumble through this.

[haydent]

so it will work with flashing the bootloader, you just cant have it connected to port 0 during startup. so once your fc is powered up, you can connect it then

[mikez104]

Hi! It's been a while since I have touched any of this stuff and I decided to try and burn that bootloader this evening. So what I did was edit the profile in the boards.txt file for the Mega2560 profile. I just changed the name of the bootloader and dropped your hex file into the bootloader directory. I chose USBASP and did burn bootloader under tools. It no worky. Here is what I got for an error. Any clue what I'm doing wrong?

Code: Select all

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: WARNING: no end of file record found for Intel Hex file "C:\Program Files (x86)\Arduino\hardware\arduino\bootloaders\stk500v2\stk500boot_v3_mega2560-uart0_boot_fix.hex"
avrdude: WARNING: no end of file record found for Intel Hex file "C:\Program Files (x86)\Arduino\hardware\arduino\bootloaders\stk500v2\stk500boot_v3_mega2560-uart0_boot_fix.hex"

[haydent]

have not heard of that error, maybe try googling it

[mikez104]

Yeah, I have. One guy said he bought a 10 pin to 6 pin adapter and that solved his problem. I think in my case though, the error means "hey, you just bricked your flight controller." Yeah, I can't communicate with it at all now. Wonderful.

[haydent]

sorry to hear that you my have done that. maybe silly question, but have you tried flashing with stock arduino bootloader ? or burning the blink sketch via programmer ?

[mikez104]

Yeah, tried that. I get the same error when trying to flash the stock bootloader. I can't flash via the USB either. I just have two solid lights on my FC.

[haydent]

an incomplete burn can mean you end up with no working bootloader that is needed for usb, what if you try burning the blink example sketch via programmer ?