Smartport telemetry

[VA3WK]

If your issue looks like a hardware fault or a configuration problem please don't raise an issue here.

Please consider using other user support options such as asking the manufacturer of the hardware you are using, RCGroups, Slack or other user support forums & groups (e.g. facebook).

Board and Version

_Board name goes here. If you have a link where you've purchased the board - please include it Matek fc F405-wing Version of INAV used goes here 1.9.1 Use CLI command version and put its output here INAV/MATEKF405SE 1.9.1 APR 21 2018 /13:46:07 (03a5c1922) If it's a custom-compiled firmware please mention this

Behavior

• Describe the problem Smartport telemetry stops working anytime after 10-30min. (does not do it with 1.9.0).It also does it with a Spracing F3 FC again 1.9.0 works fine.

• Steps needed to reproduce the problem just let it run

• Expected Results

• Actual Results

Is this a new feature request? No

Blackbox logs/Config (.ZIP) where problem occurs

_Go to CLI, execute dump command copy its output to PasteBin and provide a link to a paste here.

Upload a zipped blackbox log (if available)

[teckel12]

@VA3WK I've had this problem due to heat. When my receiver gets too hot, it stops sending telemetry. My VTx was generating too much heat and too close to my Rx, which caused the problem on hot days. I've had this happen on a couple different receivers and different versions of INAV.

I could get telemetry to start working again by simply blowing on the Rx, moving it away from the VTX, or pointing a fan towards my quad. It's never happened when flying, as with a quad there's lots of natural cooling when flying.

I'd seriously look into an overheating issue, as what you're describing sounds exactly like what I've experienced.

[VA3WK]

It works fine with 1.9.0 ,so i don't think its the problem. I tried several boards spracing F3, matek f4-wing Thank for your reply.

[teckel12]

@VA3WK Meh. It's warmer now, so... I thought this was a problem with last summer's version, till I realized it was just summer causing it. I'm having no lost telemetry issues with 1.9.1, even when on the bench for a very long time.

[VA3WK]

well you are lucky then, i just tested a omnibus f4 pro and after about 10min plus it stops responding to telemetry request from the receiver.(a brand new X8R.) on 1.9.1, re flashed with 1.9.0 and it works fine.

[teckel12]

@VA3WK I'll try it with an Omnibus F4 Pro today and get back with you. I'l running a 2.0 development build, so there could be some differences.

Oh, do all the FC/based telemetry stop at the same time, or is it a few, then worsens till they all stop? Also, does the X8R telemetry still send when they stop from the FC? Like is RSSI still sending?

[teckel12]

@VA3WK I did get it to fail eventually after over 30 minutes. I also couldn't get it to recover (ever after putting the quad in the freezer).

I'll need to test this again on a couple different quads and see if I can duplicate it and if there's any similarities to try and isolate the problem.

[VA3WK]

Yes sometimes is goes faster i have seen it as short as 9min . I don't think temp makes a difference. i don't know yet why and under what circumstances it stops' if you put a scope to it you see that the receiver is still trying to communicate. My feeling is that there is some kind of a buffer overrun ,but i am not a programmer so i have to leave that up to the experts. i can see that the telemetry gets slower and slower and the horus first reports "sensor last" and then more and more sensors quit and eventually it reports "telemetry last".

[VA3WK]

The RSSI and receiver voltage still work after that.

[kd2eat]

Just a "me too" for this problem. Inav 1.9.1. I have smartport telemetry coming out of an Omnibus F4 Pro V3 into my Taranis radio via an X8R receiver. My flight began at 19:14:07. At 19:26:02 the smartport telemetry in my logs all froze at the same values. All of the other things - switch positions, sticks, RSSI continued to update. I was just looking into this and ran into this bug report.

I can't imagine heat is an issue. My receiver is on out on one wing, the VTX is on the other, FC is in the middle. This is on a FX-79 Buffalo, so there is about 2 1/2 feet of separation between components.

[teckel12]

@kd2eat I've been able to simulate it too, and it's not the issue I've had with an overheating TX like I've had in the past. The overheating symptoms are different, the sensors go in and out one by one, not all totally off at the same time like this problem.

This is a bug, not sure what's causing it though.

[VA3WK]

Just tried Inav 2.0.rc1 on a matek F405-wing and still the same problem i had hoped they would have fixed it but no luck.

[kd2eat]

Ya this one is driving me nuts, too. I may go onto github and do some "diffs" between 1.9.0 and 1.9.1 to see if I see what they wiggled. Thanks for the heads-up on the 2.0.rc1.

[fiam]

I've spotted a couple of places in the smartport driver that could be problematic. I'll post some binaries here to make it easier. Which targets would you guys need to test?

[kd2eat]

Alberto, I'm running OMNIBUSF4PRO_LEDSTRIPM5. I'd be happy to test a build for you.

Mike

[fiam]

@kd2eat Please, use the hex attached to this message. @VA3WK You mentioned you have a MATEK F405-WING so I also added a build for you just in case.

inav_2.0.0_MATEKF405SE_FIX_3282.hex.zip inav_2.0.0_OMNIBUSF4PRO_LEDSTRIPM5_FIX_3282.hex.zip

[VA3WK]

ok thanks i will try it and let you know.

[davidngrc]

I am on iNave 1.9.1 + matek f405 wing + R9 slim plus (upgraded fw to non-eu v180329) I also try R9 min, same problem.

test at home, I put the plane near the window, it got 9 satellite, the temperature is about 30 degree c. I can see all 18 sensor on my x9d plus, rssi is 100 after 6 minute, I get it back to the air con room 25 degree c, the gps sensor lost. 10 min pass, "inactivity alarm" 26 min, I put it back to the window, gps found again. go do sth, 43 min pass, and now all sensor in the telemetry screen lost (leaving only first 2 rssi and rxbat)

I am not sure this is problem or not. I recently try to get the gps show on the map, so I use opentx 2.2.1, enable smart port mirror in serial port x9d+ battery bay. I then connect the x9d serial port tx to a smart port inverter (IN), then (OUT) to bluetooth hc-06 rx (57600 baud rate) I then use EZ-GUI, and in android cat log, search keyword: frsky I can see many decode frsky crc error.

according to this https://www.jochen-scheib.de/understanding-the-frsky-smartport-protocol/ the telemetry frame is 10 Byte. and in the cat log, the crc error shows the frame only contain 2 Byte like 7E 16 or 7E B7 or 7E 39 or 7E xx always start with 7E the correct frame show on cat log are like 10 7E 1B , they are start with 10

after the telemetry sensor gone, I go back to the cat log, only the rssi and rx bat is parser correctly. other are all 2 Byte crc checksum error like before.

will test @fiam build now, report back later.

[VA3WK]

@fiam sorry to report but it failed after 19 min , again all telemetry gone except A2,rssi and rxbat. i think these come from the receiver directly.

[fiam]

@VA3WK Thanks for testing it. I’ll take another look at the code and see if I can spot anything else.

[davidngrc]

I am still testing, so far so good, plane near window, 30 degree c. x9d inside air con, 25 degree c. btw, I can not change the plane to "flying wing" using @fiam 's build, no matter what I change, it always show quadcopter.

[davidngrc]

result, all sensor lost after about 30min. only showing rssi and rxbat.

[fiam]

@kd2eat @VA3WK @davidngrc I've made another build with a few more changes. This time I haven't been so optimistic and I've added some debug info, so if it fails it will help us see exactly where.

Once the FC starts, go to the sensors tab and check the debug graph (you might need to enable it). Debug 0, Debug 1 and Debug 2 should be all increasing at least once a second. Once the telemetry stops working, please check back the debug graph and see which Debug values have stopped increasing. Thanks!

inav_2.0.0_MATEKF405SE_FIX_3282_2.hex.zip inav_2.0.0_OMNIBUSF4PRO_LEDSTRIPM5_FIX_3282_2.hex.zip

[VA3WK]

Ok will do

[kd2eat]

Wow, thanks for all the builds. If someone hasn't reported back before I get to it, I'll try it this evening.

[VA3WK]

@fiam Ok i flashed the file result: i get no telemetry on the radio at all (except the usually 3) i enabled debug in the sensor tab and i only see debug 0 increasing. if i open the debug graph its empty. What am i doing wrong?

[fiam]

@VA3WK Probably my fault. I don't have a setup with SmartPort here, so I can't test these builds. I've relaxed some checks and made a new one. Please, give it a try when you have time.

inav_2.0.0_MATEKF405SE_FIX_3282_3.hex.zip inav_2.0.0_OMNIBUSF4PRO_LEDSTRIPM5_FIX_3282_3.hex.zip

[VA3WK]

ok no problem

[VA3WK]

ok result : telemetry stopped working , debug 0 is still counting , debug 1 + 2 stopped. How can i activate the "open debug trace" so that it shows something ?

[VA3WK]

BTW. all three sensors ( baro, gyro, accel) are still active.

[VA3WK]

@fiam Ok this is weird i forgot to turn the unit off after it stopped the telemetry and when i got back to it after about 20min the telemetry was working again but at a very slow refresh rate actually so slow that opentx reported sensor loss. Random sensors would time out and the next time around they would read again. Debug 1 and 2 also counted very slowly.

[VA3WK]

@fiam now it stopped again. now also debug 0 counts very slowly like 2 counts the second , debug 1 and 2 stopped again. i don't know if these observations are of any help or if they confuse the issue more.

[teckel12]

@fiam BTW, at least with 1.9.1 I was able to reproduce S.Port telemetry failing after 30+ minutes. I've only been able to duplicate this on the bench, as none of my quads can fly anywhere near 30 minutes. But, I did duplicate the issue.

[davidngrc]

@VA3WK @fiam I encounter the same thing last weekend on the bench. after 30 min, telemetry stop. then wait for a while. I am not sure how long, but at least 20 min, telemetry will come back again. I thought it was the R9M, R9 slim and R9 mini problem...

[fiam]

@VA3WK That's valuable information. Debug[0] was set up to increase whenever a telemetry request from the RX was received, debug[1] wether the driver decided it was time to try to service a request and debug[2] whenever a sensor frame was sent from FC to RX. If only debug[1] and debug[2] stopped, it means there's a bug between the point where the driver gets the request and when it decides to service it.

Please, give these new builds a try.

inav_2.0.0_MATEKF405SE_FIX_3282_4.hex.zip inav_2.0.0_OMNIBUSF4PRO_LEDSTRIPM5_FIX_3282_4.hex.zip

[davidngrc]

@fiam I only get first 2 telemetry in this build inav_2.0.0_MATEKF405SE_FIX_3282_4.hex.zip debug 0 always go up (about 1 second +1), debug 1&2 keep at 0.

btw, why can't I change to flying wing in your build? I refresh your first zip, the telemetry came back. (and get sensor lose in about 3 min) I then refresh the inav_2.0.0-rc1_MATEKF405SE.hex I could not change to flying wing either...

[VA3WK]

I am back had to have a little sleep. flashed #4 and get no telemetry but debug 0 is counting up.

[kd2eat]

@VA3WK Nice job on all the testing! Thanks from a fellow sufferer. I had intended to do some testing last night, but some honey-do's chewed up my spare time. I'm glad someone was able to do it for @fiam.

[davidngrc]

@fiam , is it possible make a special build base on v2.0 but just roll back the smart port telemetry to v1.9.0?

[davidngrc]

or... the matek F405-wing has a onboard Blackbox: MicroSD card slot which can store logs. how about you make a build, write detail log to the sd card? (like function call with parameter value and inside the function call capture each line) (I got 32G and 64G card here) I am sure other tester here has the same setup, after compare the log, I think we (I meant you ^-^) can find the problem.

[VA3WK]

@fiam did some more testing , reloaded the org hex file and noted all the values like cpu load , msp load etc. and waited till the telemetry quit . there were no changes in those values.

[VA3WK]

@fiam another interesting finding: on the distribution build the telemetry will not come back as it did with your #3 build.

[davidngrc]

@fiam I just did another test on the inav_2.0.0-rc1_MATEKF405SE.hex 00:00:00 start test 00:35:00 lost all sensors except rssi and rxbat 01:11:00 all came back.

the result is not the same as @VA3WK

[davidngrc]

just compare the RC1 and RC2 code, only 1 line of GPS code was changed in the telemetry relate files. so I guest no need to do the RC2 test.

[fiam]

No need to redo any tests. There are no changes in RC2 that could fix this.

[VA3WK]

@davidngrc just let it run it will quit again. the timing of this varies greatly.

[davidngrc]

I was thinking use try and catch the error and found no such thing in C 😅

I saw many *clearToSend in the smartport.c file. maybe there is a bug in some loop, and this value is always set to false for about x minute, so all sensor lost.

[VA3WK]

@fiam Is it possible that the inclusion of Fport in march has something to do with this ? The timing is about right .

[fiam]

@VA3WK It definitely has, since a lot of smartport.c was changed to accommodate for the shared telemetry code (FPort is kinda SBUS+S.Port in a single stream).

[davidngrc]

I modify some code, and testing for 1 hour without telemetry lost (outside, 36 degree c, in a shade)

note 1, the build I am testing is without Tmp2 sensor, because in my previous test, the Tmp2 sensor lost way before all sensor lost. I suggest you test the normal version first, if fail, then test the without Tmp2 sensor version.

note 2, please only test sbus+sport, not fport.

inav_2.0.0RC2_david_1_without_tmp2_MATEKF405SE.zip inav_2.0.0RC2_david_1_without_tmp2_OMNIBUSF4PRO_LEDSTRIPM5.zip

inav_2.0.0RC2_david_1_MATEKF405SE.zip inav_2.0.0RC2_david_1_OMNIBUSF4PRO_LEDSTRIPM5.zip

[VA3WK]

@fiam yes i know what fport is ,its a nice idea but i think it did not catch on very much , its need pretty well new equipment. I know a lot of people who have X8R etc. receivers which won't work. i wonder if it possible to create a build without fport.