Universal ACCST Firmware (UNI)

[Wayne]

TESTERS- Hey folks I have not reached out to any of you yet as we are waiting for some receivers to come from FrSky that we can send out to you. We are currently limited to the X4R, X6R and X8R receivers for right now. The goal is to focus on these 3 receivers as they all run pretty much the identical hardware, the rest of the receivers have a little different hardware and will require some code changes and another round of testing.

 

[Landru]

I'll take a crack at this, but Mike can do a better and more technical response.

The V1 USM (uncommanded servo movement) is a error that occurs when some bad data is accepted by the receiver. This can happen as the receiver is not fully checking the quality of the data in the entire packet. So a bad packet has a small chance to be accepted by the receiver. The packet data is basically arrives in a given order. For example, the first number would be channel one, the second number channel two, etc. There is nothing that states, channel one equals 1500, it just says 1500 in the correct place. This all works fine as long as the data is correct. If the receiver approves a bad packet of data, then you get random servo movements. With the Universal firmware there are additional checks in place to catch this bad data and reject, thus the issue that was already VERY rare is almost completely eliminated. But just in case a further measure was added that should a bad packet manage to pass both quality checks, the USM would only last 18ms as the firmware no longer accepts any data from the previous packet as being valid. (something V1 did to save on workload..?) So the next packet of data comes in, gets checked twice, etc.. With V1 I forget how long the USM could last, but it was a much longer time frame, and the risks of more bad packets being accepted was much higher.

I've probably done a horrible job and may not have the details fully correct here, but this is my understanding based on my memory. Sure mike will correct any major flaws.

The takeaway is that Universal has multiple improvements to fight USM making it the better choice. The other major addition is the AutoTune feature, for some receiver transmitter combinations will net noticeable range & packet performance. Basically AutoTune does a series of tests of the RF connection and adjusts the tune slightly and checks to see if the connection is better or worse, and it does this until it finds the sweet spot. Since all radio gear has some tolerances due to the components used, the frequencies can shift up or down slightly. The AutoTune adjusts for this to get the best signal from the transmitter. Just like tuning an old stereo system to remove the static from a music broadcast. (Younger people may not know what that was like, LOL.) To me this is possibly the most exciting improvement in this firmware.

Hey Wayne,

Thanks for the good info.

My recollection is that USM in the unfixed version of v1 lasted about a second. I'm sure Mike would know offhand. At any rate, it must have been long enough for a servo to respond to the uncommanded input. If the max duration of any USM in the universal firmware can never be long enough for a servo to respond--or if the uncommanded response is infinitesimally brief--I should be safe regardless of what severity of interference I run into.

The AutoTune feature you mentioned is welcome news.

Tuning wasn't a big topic in the public discussion of USM that I recall. However, at least a few of us have some personal history with the issue. Starting before the USM problem became widely publicized, a fellow in Germany and I worked more or less privately to understand how it could be reproduced. No information on reproducing the problem intentionally had been published at that point. One of the methods we tried was a purposely de-tuned MPM. Eventually we succeeded with it. Still, as I recall, a source of external RF interference was also likely required. My takeaway was that less than optimal tuning increased vulnerability to USM. Credit for the method goes to my partner in the exercise, not me.

Best,
Andrew

 

[Landru]

P.S. I'd be happy to have a go at testing the universal firmware if you see any possible benefit. I'd start with ground testing before committing to flying. That's SOP for me now with any new firmware or hardware. My flying locations seem to make for good stress testing.

 

[Wayne]

Yes, anytime the RF link is stressed, that is when the USM can occur. There is zero percent chance of a USM with a good link as the packets will arrive in perfect condition.

Want the screw up your telemetry feed? Just leave a transmitter turned on at your feet while you fly with another radio. This creates the stress on the RF link that can allow the telemetry error to occur. Basically the same as the USM.

 

[JEngel]

If it helps any on that decision, the goal was to breath new life into the older gear and help to maintain ACCST into the future, and also cut down on the confusion for our customers. Prior to ACCST V2 we hardly ever had anyone asking us "how do I bind this?" These days we get that question a lot and we have frustrated customers, and heck, I run one ACCESS radio and one ACCST radio and am constantly running into this issue. This new firmware makes that whole mess go away. For me with both new and old transmitters in use, I can have a single firmware and use either radio without having to change the firmware on the receiver. Even better, with the dual bind, I can use either or BOTH transmitters with the same plane. I think that is a win, win, win.

But for us, the best thing is we can sell receivers with Universal installed and they will work for ALL of our customers. Cuts down on the technical service and customer frustration. This should be the most trouble free protocol for FrSky radios. Thanks to the extra work Mike and the team put into this firmware these receivers should enjoy better range and a more reliable connection with Universal installed.

Thanks it does help.
I do have a question, you said its the x4r, x6r, and x8r receivers are the ones you are working on for the moment.
Does this include
the x8r pro ?

 

[MikeB]

The cause of the USM problem is interference that causes corruption of a Tx packet. The receiver uses a software calculated CRC code to check packets are valid. It is possible that some corrupted packets still produce a valid CRC so a packet is accepted when in error.
Each packet contains:
Tx ID
Rx Number
next hopping channel
8 channels of servo data
telemetry data

Some or all of these may then be incorrect.
If the Tx Id or Rx Number are wrong the packet is discarded.
If the servo data is wrong, then incorrect servo outputs will be produced. Note that in 16 channels mode, either channels 1-8 are affected or channels 9-16.
If the telemetry data is wrong, then incorrect telemetry data may be output on the SPort.
If the "next hopping channel" is incorrect, FrSky firmware loses synchronisation as it goes off looking at the wrong hopping frequency. Often this then takes nearly a second to detect loss of data and re-synchronise, although (for complex reasons) a valid packet may be received before that time.

This firmware checks for the required hopping sequence using the first few packets received, then locks to that. It then checks the hopping data in all received packets and discards packets where this is incorrect. It then goes to the correct next hopping frequency for the next packet, so synchronisation is not lost.
So an incorrectly accepted packet may have incorrect servo data, causing servo(s) to move incorrectly, but as soon as a valid packet is received (for those servos) they will be corrected. Unless the interference persists for a long time, this will happen within a few 10s of milliseconds.

Mike

 

[Wayne]

Thanks it does help.
I do have a question, you said its the x4r, x6r, and x8r receivers are the ones you are working on for the moment.
Does this include
the x8r pro ?

Not yet, the Pro is a little different animal, but it will be getting Universal pretty soon.

 

[Landru]

The cause of the USM problem is interference that causes corruption of a Tx packet. The receiver uses a software calculated CRC code to check packets are valid. It is possible that some corrupted packets still produce a valid CRC so a packet is accepted when in error.
Each packet contains:
Tx ID
Rx Number
next hopping channel
8 channels of servo data
telemetry data

Some or all of these may then be incorrect.
If the Tx Id or Rx Number are wrong the packet is discarded.
If the servo data is wrong, then incorrect servo outputs will be produced. Note that in 16 channels mode, either channels 1-8 are affected or channels 9-16.
If the telemetry data is wrong, then incorrect telemetry data may be output on the SPort.
If the "next hopping channel" is incorrect, FrSky firmware loses synchronisation as it goes off looking at the wrong hopping frequency. Often this then takes nearly a second to detect loss of data and re-synchronise, although (for complex reasons) a valid packet may be received before that time.

This firmware checks for the required hopping sequence using the first few packets received, then locks to that. It then checks the hopping data in all received packets and discards packets where this is incorrect. It then goes to the correct next hopping frequency for the next packet, so synchronisation is not lost.
So an incorrectly accepted packet may have incorrect servo data, causing servo(s) to move incorrectly, but as soon as a valid packet is received (for those servos) they will be corrected. Unless the interference persists for a long time, this will happen within a few 10s of milliseconds.

Mike

Excellent summary. Very helpful. Thank you.

On a related note, does the universal firmware happen to include the 'beautification' of the lost frame data that FrSky added to their firmware starting with late versions of v1?

Before it was obfuscated, the LF data was used by some of us for a link quality sensor (the Tadango LQ sensor). Taking it a step further, on RCG, there was speculation about whether the universal firmware might be able to include its own LQ sensor.

I bet you have plenty of work on your plate. Please take the above as the curiosity of someone who's already delighted with the current direction.

 

[JEngel]

Not yet, the Pro is a little different animal, but it will be getting Universal pretty soon.

Ok thanks
I was hoping lol.
I started using X8R Pro when I started flying gas engines.
I never had a problem with my FrSky receivers until I started flying gasoline engines I assume because of the electronic ignition. I started buying thex8r pro with a mx+ for a satellite and never had a problem after.
Do you think that the universal x8r's are going to be as good as the x8r pros ? or hopefully even better.

 

[MikeB]

A telemetry value of the VFR is returned, and the SBUS frames contain correct frame loss data. By using a script on the Tx, you may even see the valid frame rate for each of the hopping frequencies.

I have a build for the RX8R-PRO, but it is not complete yet, it doesn't handle the SBUS in.

Mike

 

[Landru]

Wow! That is very, very cool.

Now I really want the universal firmware.

We know that FrSky has hired Bertrand S. of OpenTx to help write their OS code. I think they need you to help with their firmware.

Many thanks,
Andrew

 

[Wayne]

We know that FrSky has hired Bertrand S. of OpenTx to help write their OS code. I think they need you to help with their firmware.

Trust me, that is where I started on this project. I twisted their arms as hard as I dared to get them to hire Mike. In the end they gave me permission to move forward with this ACCST project. So we do have their blessing.

It is very important to frsky to keep RF development in house. I have been VERY frank with FrSky on this matter and it has been discussed in great detail. It will be a topic I discuss with them in the future as I would love to see ACCESS do more than then it already does.

 

[Landru]

Seems to me you're a very good influence on FrSky, Wayne. Certainly, the more I learn about the universal firmware, the more I like.

I take it the reference to in-house RF development has everything to do securing IP from cloning. By this point, I would have thought FrSky was sensitive to the issues at stake. Of course, I don't know the ins and outs like you must. Nor do I need to. But even from an outsider's viewpoint, it does seem an important topic for the company.

You mentioned ACCESS. Having flown with it, I say there's plenty to like. That's for sure. However, like you, I have my own wish list for improvements. Top of my list would be the issue of range and vulnerability to RF interference. It's just not as good as ACCST D16 based on my experience. Let me quickly add that the issue is likely of little to no concern for most pilots. The sky is definitely not falling.

In fairness, let me add that other brands may not cope well with interference. I learned that lesson the hard way recently when I had a model fly away from relatively close range. Discussions with the manufacturer--the name of which I won't mention here--revealed a bug in the RF software. While significant, the bug itself wasn't the most interesting revelation for me. Rather, what caught my attention was the fact that the manufacturer implemented a rigorous interference stress-testing protocol for all their hardware and firmware as a result of the bug. The investment in time and equipment impressed me. Whether FrSky's testing program includes anything similar, I have no idea. If it doesn't, it might be something for them to consider.

In any case, I love where things are headed. Keep up your great work.

 

[MikeB]

What we have is you are not able to download the firmware initially, but later updates will be downloadable (your on-going basis).

Mike

 

[Konrad]

This is fantastic tech! This is what was needed from the start, customer focused software. Too bad FrSky didn't/doesn't have the customer experience as the paramount driver for their product release. This should have been available 2 years ago with the ACCST V1/V2 debacle and the introduction of ACCeSS.

But as of this date going forward this should be the answer to the maiden's prayers, as far as ease of binding. If the developers and the dealers can keep control of the code it will be the true backbreaker for the clones. This is one of the few software schemes that looks to be both pro FrSky marketing and pro consumer interface. As has been mentioned future purchases with the new code will still allow the end user to update as the need develops. I see no down side to this other than the code will need to be vigorously protected (physically not just legally). This forces the initial loading to be done by reputable characters. It is my experience that this means the dealers. (History has shown that the OEM has some holes in their security).

If I didn't hate code and being an unpaid beta tester I'd jump on to this code. So I for one would like to thank the developers for this and the beta testers a head of time. I'd also like to learn what testing protocols and reporting criteria are to be used for the beta testers. I think the only folks that would NOT like to see this code in the market place are the cloners. I think the developers have hit the 90/10 mark in favor of the wider customer base!

Frsky should buy this as it is their primary hope to destroy the clones. Ethos is looking to be great and has community support. But the RX side is still an ACCeSS/ACCSTV2 world. While the dealers see this I'm not sure Frsky the corporation sees or understands this.

Also can somebody explain how the RF {sensitivity (range)} is improved by code. I thought that RF and data packet performance are separate issues.

Back to your regular scheduled programing.

 

[MPJF01]

I, for one, completely support that approach.

I'm sure that all of the dealers involved, as well as Mike, are well aware of the issues associated with the need to return receivers to dealers for the firmware update and if there was any easier option it would have been used.

In the end it's to our (end users) benefit.

 

[nhedler]

When firmware becomes available for the G-RX8 and/or RX4R, I'd be interested to help with testing, especially if it's possible that the onboard vario latency can be improved.

 

[Landru]

Also can somebody explain how the RF {sensitivity (range)} is improved by code. I thought that RF and data packet performance are separate issues.

Really good question.

I don't have the expertise to attempt a good answer. Plus, the topic likely falls outside the scope of this thread and many readers' interest. To keep things brief, I'll just mention that my layman's understanding is that receiver sensitivity can be affected by bandwidth (to mention but one software-dependent factor). The ExpressLRS range vs packet rate chart gives a concrete example.

Whether the differences in range I've run into with various protocols on the same receiver, in the same model, with the same transmitter, at the same location come down to bandwidth, is something I don't know.

 

[Konrad]

Post#57 states improved range, so I think the question is valid for this thread.
What I think you post is showing how the data rate will require that the sensitivity be widened to accept the large modulated side band. This is why RX's like the L9R don't have telemetry. The RF carrier frequency can be much narrower (more sensitive) if it only had to deal with narrower side bands. So the RX can be tuned for greater sensitivity at the cost of data transfer (baud rate). This is to my way of thinking just classic RF. Now what I think is being said in that post is that the code can effectively deal with noise that is inside the capture range of the RF circuit. This can make it appear that there is an improvement in RF range By being able to filter the corrupted data packets (lost data). But I don't see this post RF modulated data (code) actually improving RF performance.

Or put another way the more data an RX has to deal with the less selective the RF section has to be. (the more data the wider the sideband needs to be). This is why single sideband morse code was so efficient.

I haven't had any RF theroy in over 50 years so i'm sure I'm way out of date and maybe flat out in error. This is why I asked why or how does this code extent the range? To my way of thinking this is the provenance of the RF hardware (Chip set here).

 

[Landru]

What I think you post is showing how the data rate will require that the sensitivity be widened to accept the large modulated side band. This is why RX's like the L9R don't have telemetry. The RF carrier frequency can be much narrower (more sensitive) if it only had to deal with narrower side bands. So the RX can be tuned for greater sensitivity at the cost of data transfer (baud rate). This is to my way of thinking just classic RF. Now what I think is being said in that post is that the code can effectively deal with noise that is inside the capture range of the RF circuit. This can make it appear that there is an improvement in RF range By being able to filter the corrupted data packets (lost data). But I don't see this post RF modulated data (code) actually improving RF performance.

Or put another way the more data an RX has to deal with the less selective the RF section has to be. (the more data the wider the sideband needs to be). This is why single sideband morse code was so efficient.

I haven't had any RF theroy in over 50 years so i'm sure I'm way out of date and maybe flat out in error. This is why I asked why or how does this code extent the range? To my way of thinking this is the provenance of the RF hardware (Chip set here).

Ok, I think I'm following your train of thought better now.

If I understand correctly, you're distinguishing between what you're referring to as a 'classic RF' bandwidth-sensitivity relationship and any noise filtering added via software.

Much as I wish I could, I can't add any authoritative comment on any of that. It's outside my wheelhouse.

What I can say is that VFR data suggested a significant difference in range between ACCST and ACCESS when the two protocols were tested under conditions as equal as I could achieve. My results seemed quite extreme to me at the time. Since then, I've have come across other reports of ACCESS having less range than ACCST. And of increased vulnerability to noise. Still, I think all this--even my own experience--needs to be treated as anecdotal until better substantiated.

I think you're right to be curious about the subject. I am too.