TD R18 Reboot?

[DaveWave]

I have a TD R18 with about 15 flights on it. The 2.4 VFR hovers around 75 or so. The 900 MHZ VFR is usually around 95 or so. So far I had not had any issues issues.

However, I just had a flight that had "sensor conflict", then about 30 seconds later, telemetry lost/telemetry recovered. After landing, I pulled the log files and at one point in the flight, both 2.4 and 900 VFRs went from normal to zero and right back up their normal values. The loss occurred simultaneously.

Battery voltage was steady and within limits.

What would cause this rather disconcerting event?

Thanks!

 

[HENNY]

I have a TD R18 with about 15 flights on it. The 2.4 VFR hovers around 75 or so. The 900 MHZ VFR is usually around 95 or so. So far I had not had any issues issues.

However, I just had a flight that had "sensor conflict", then about 30 seconds later, telemetry lost/telemetry recovered. After landing, I pulled the log files and at one point in the flight, both 2.4 and 900 VFRs went from normal to zero and right back up their normal values. The loss occurred simultaneously.

Battery voltage was steady and within limits.

What would cause this rather disconcerting event?

Thanks!

What version of firmware is your TD R18 currently at. There are some important updates available. here. https://www.frsky-rc.com/td-r18/

 

[Wayne]

Hey Dave,

It is hard to say. The VFR you reported is still in the green, no worried there.

When your radio says "telemetry lost/telemetry recovered", that is just the transmitter loosing the data stream, it is not the receiver breaking contact with the transmitter. So the outage on the log is simple the transmitter letting you know it is not able to get any data out of the model. This can be caused by many things. MANY. Simple things like antenna placement in the model, or RF interference. Let's talk about that a bit more.

The thought crossed my mind that your VFR may have been dropping over time and that is why to shared that info. This may well be a sign that all is not well in this model. If you have seen the VFR slowly dropping over time, then I start to wonder if something is making RF noise inthe model. Some items to check will be ESCs (especially any with those ceramic donuts on the servo wires, good ESCs do not need or have these!), a MAJOR RF noise source is combustion engines with ignition systems. If you have one, always suspect it first. Check your spark plug, etc. And cheap BECs can also cause a fair amount of noise. The big problem with these sorts of noise makers is they are very close to the receivers in our planes. This can wipe out ANY radio links very easily. We have seen this time and time again with some of the Castle Creations ESCs and especially ignition systems. One customer with major issues found the brand new spark plug he put into his engine was the issue, seemed they miss labeled a bunch of plugs. Took him a while to figure that one out.

Hope this might shed some light on things. When it doubt, test it out.

 

[Landru]

I believe Dave and I exchanged a few messages on RCGroups about this issue recently.

To my mind, the incident includes some hallmarks of the NFL bug identified in many (possibly all?) FrSky protocols in 2023.

That bug was found to be caused by anomalies in the handling of sensors. And, in one case I encountered, when the model miraculously survived an extended loss of control, the bug resolved on its own after about 27 seconds. Tellingly, that resolution was preceded by an unexpected loss and regain of telemetry in quick succession.

Clearly Dave's model did not suffer loss of control. Thank goodness fort that. That happy result is not entirely unexpected; the NFL bug is believed to have been eradicated in most if not all cases. That said, I wonder if the underlying cause of the sensor conflict which formerly lead to loss of control now still persists but with mitigated impact. To put it another way, could the fix have removed the symptom but not the cause?

It's worth noting that there is no published information on what causes the sensor conflict in the first place. In my direct communications with FrSky on the NFL bug, they didn't share any info on the topic. In fact, until a bright FrSky user stumbled upon a reliable but rather contrived means to reproduce the problem by intentionally inducing a sensor conflict, FrSky was at a total loss to explain or fix the problem. Perhaps the mechanism by which the sensor conflict occurs may still remain a mystery.

It may also be worth noting that the NFL loss of control problem was still reproducible with the supposedly fixed firmware under some conditions.

P.S. I'd be curious to have a peek at your log file, Dave.

 

[Wayne]

It is tough to make a fix when a problem is random and has not yet been identified. It was great fun watching the UNI beta testers working with Mike as they developed UNI. There were many little things that can creep up, and often times it is the community feedback that is critical to tracking down the issue.

 

[Landru]

Yes, there was definitely some good sleuthing during the beta testing of UNI. I remember that the NFL bug appeared in beta versions of UNI, too. Mike put in a big effort to get to the bottom of it. Perhaps the outcome would have been different if the source code had been accessible.

Taking a wider view, I think it's fair to say that all software has bugs. That's just a fact of life. What particularly galls me about FrSky's response to the NFL bug was that they had been given explicit instructions to reliably reproduce the problem, but sat on the info for about a year. The fellow who discovered the method even supplied a video to FrSky. Only after those facts emerged publicly on RCG did FrSky take action. Meanwhile, I and other pilots lost models to what was by that time a preventable problem.

It strikes me as significant, too, that the fix did not prevent the problem in all test cases. Nor has revised firmware been released for all affected receivers.

Regarding Dave's issue, it would be possible to try to reproduce it with the method documented in the RCG thread on the NFL bug. That might shake something loose. Chances are it would take someone from the community to champion the cause.

 

[DaveWave]

So here is a screen shot of the issue at hand. Any ideas what would cause something like this?

 

[Landru]

So here is a screen shot of the issue at hand. Any ideas what would cause something like this?

Judging from the plot, it seems to me that at the very least the telemetry link represented by the red VFR cut out entirely several times. It's hard to tell more than that from the graph. Can you share the original unmodified log file? I wouldn't mind taking a closer look.

My hunch is that the control link also cut out during the telemetry outages. In many hundreds of hours flying with FrSky gear, I never encountered a case where telemetry was lost but control persisted. That's not to say it couldn't happen, just as Wayne mentioned. On the other hand, I have come across the converse i.e. cases where telemetry persisted while control was lost.

P.S. Sorry for the slow response. For some reason, the email alert for your post went to my spam folder.

 

[DaveWave]

The one on the right is when I shutoff the TX. The one at the 21:21 mark is the issue. I'll upload the log file shortly.

 

[Landru]

Sounds good. I'll check out the log asap. The way tomorrow is looking, that may take me into the weekend.

 

[DaveWave]

Sorry I got distracted.....

Anyhow... here is the log file....Any ideas?

Thanks for the help!

 

[Landru]

Hey Dave,

The log data shows that between 12:21:31.230 and 12:21:34.400, there were missing entries for both 2.4GHz and 900MHz RSSI and VFR. There was no interruption in the data for other fields e.g. GPS Speed. See the blank cells for RSSI and VFR in the highlighted rows below:



What I take away is that there was no general interruption in telemetry. And, since you didn't report any loss of control or failsafe (which surely you would have), I conclude the control link was unaffected. Or am I wrong about that?

Perhaps the "Sensor conflict" warning you heard accurately reflected a temporary and non-critical error condition in the RSSI and VFR sensors. It seems worth noting that those two sensors exist for both the 2.4GHz and 900MHz links in Tandem.

To the best of my memory, I've never heard the sensor conflict alert in many hundreds of hours flying with FrSky gear (albeit none with Tandem or EthOS). I'm not sure I can shed any further light on what you encountered.

 

[DaveWave]

That's a good observation. It does show the receiver was active during the dip in RSSI and that the transmitter could hear the receiver and I would assume vice versa.

The question is what would cause just a few channels to cut out like that? Have anybody ever seen something like this ? I wonder if the receiver load sheds when heavily loaded, and it dumped the telemetry when a higher level task was taking too much time....

 

[Landru]

A quick Google search turned up a number of EthOS bug reports related to the sensor conflict message, including this one which seems similar to what you experienced:

Ethos 1.6.2 - Random "sensor conflict" message · Issue #135 · FrSkyRC/RF_Feedback_Group

Since 1.6.2 (not sure 1.6.1), I get random "sensor conflict" message during a flight. I get only one message during the flight. Nothing changed since 1.6.0 on the aircraft side (rx, servos, sensors...

github.com

In that ticket, this post describes missing telemetry values along the same lines as in your log file.

The ticket is currently open so I suppose we can conclude that the devs haven't been able to understand and correct the underlying problem. Another bug report I came across suggested checking for duplicate sensor appID in the model programming. I didn't do a thorough search. There may be other relevant bug reports.

The telemetry lost / recovered messages you heard about 30s after the sensor conflict may (or may not) be an important clue. I didn't see any evidence of a loss of telemetry in the log file to explain the messages. If there was an outage, it may have been shorter than the telemetry recording interval. Going forward, I'd recommend you reduce the interval to its minimum. Currently, it's about 0.25s. I think you can set it as low as 0.1s.