expressLRS

So you are saying that the packet rate is the stick sample rate?

mooiweertje wrote: So you are saying that the packet rate is the stick sample rate?

Yes, that is correct. Packet rate is the rate you are choosing to send updates over the air from TX to RX, and it is therefore also the rate at which the TX module reads stick data each second from DeviationTX.

A few things to comment on here. I believe I know what's happening but want to dig into ELRS code to be sure. I've got some changes that work better but not ready to test yet.

PR #1018 from phobos- added adaptive packet rate for CRSF, so at 500Hz Deviation is running the mixer and sending a radio packet every 2ms. Deviation serial data rate is 400000bps (CRSFV3 rate negotiation is on my list). When packet send time comes around, if a CRSF data command is waiting to be sent then the command is sent instead of an rc packet. I believe that's also how opentx does it though it's been quite some time since I looked. With the numbers above that leaves barely enough time for the module to send a response to the command before the next packet send time comes around.

It appears to me the module doesn't try to sync command responses with the packet send time. The module sends the response when it's ready and if that overlaps with Deviation sending the next rc packet then both messages get clobbered. With some debug code I see evidence of this in uart framing errors and unexpected data. It also happens with my Crossfire module but less often due to the lower packet rate, and Deviation has some retry code that's hidden the problem till now. The shorter names give just enough time for the device info to be received before Deviation starts the next packet send.

Deviation is listening whenever it's not sending so if the module was pausing it's response when expecting an rc packet then Deviation would receive the rest of the data when the module resumes sending. I don't think the modules make a pause but that's why I want to dig in the ELRS code a bit. It's also possible that there's some hardware or timing difference in the T8 when switching from sending to receiving that puts bad data in the uart receive register.

The approach I'm taking is to pause sending whenever expecting a command response from the module.

Thanks for the testing and discussion!

From the ELRS pages maybe something new here:
www.expresslrs.org/2.0/faq/
www.expresslrs.org/2.0/quick-start/transmitters/tx-prep/

ExpressLRS needs your radio to support crsfshot (a.k.a. Mixersync) to work properly. This will give you the lowest possible latency and optimal consistency of the RC link. When your radio does not have crsfshot working, this often shows in your ExpressLRS Lua script. The Lua script top bar will show inconsistent numbers like 0:63 or is stuck at 0:250 at every packet rate rate you select.

The Lua script top bar should always show a stable 0/[user selected packet rate]

For example: 0/50, 0/150, 0/250, 0/500, ...

When that is the case your radio has crsfshot working and you're good to go. Click here to read more on OpenTX.

Sometimes reading/listening some chit chat that is 90% nonsense can activate that one brain-cell that comes with the answer you look for.

If I understand correctly crsfshot (a.k.a. Mixersync) is the protocol to make it possible to get the packets in sync with very little overhead so packetrates of 250Hz and with ELRS even 500Hz can be achieved? The sync goes all the way from the sticks to the flight controller.
And this crfshot/Mixersync is implemented in Deviation but on 500Hz there is only this tiny hickup with the name length to put in the menu?

mooiweertje wrote: If I understand correctly crsfshot (a.k.a. Mixersync) is the protocol to make it possible to get the packets in sync with very little overhead so packetrates of 250Hz and with ELRS even 500Hz can be achieved? The sync goes all the way from the sticks to the flight controller.
And this crfshot/Mixersync is implemented in Deviation but on 500Hz there is only this tiny hickup with the name length to put in the menu?

MixerSync/crsfshot, a patch-set for OpenTX from TBS, was initially targetted at reducing jitter - making sure stick updates were sent at exactly X ms and not early/late due to lack of co-ordination between radio and module. With lower packet rates this jitter was less noticeable but at higher rates it was statistically more obvious.

Something about an ADC filter in opentx but no idea if Deviation has something of the sort.
ADC Filter¶
The ADC filter is enabled by default in OpenTX and is known to cause issues with RC Command data. This can result in "jagged" RC command responses in black box logs, caused by sequential RC packets that have the same command value (which were "smoothed" by the ADC filter). We recommend turning the ADC filter OFF in OpenTX.

mooiweertje wrote: Something about an ADC filter in opentx but no idea if Deviation has something of the sort.
ADC Filter¶
The ADC filter is enabled by default in OpenTX and is known to cause issues with RC Command data. This can result in "jagged" RC command responses in black box logs, caused by sequential RC packets that have the same command value (which were "smoothed" by the ADC filter). We recommend turning the ADC filter OFF in OpenTX.

Wouldn't cause this immediate issue if that were the case, but would give rougher input to the FC. Filtering inputs like this would not affect the CRSF menu data transfer.

What I wonder about now.. Is 500Hz really 500Hz now when I am flying around or does it sync up on 250Hz?

Asked about this on eLRS discord - eLRS sends a packet with the sync info to the radio, then waits for a stick update and only then sends the menu data immediately after receiving the stick data.

mooiweertje wrote: What I wonder about now.. Is 500Hz really 500Hz now when I am flying around or does it sync up on 250Hz?

hexfet said that 500Hz mixer was supported, so sounds like yes 500Hz is what you have, bugs notwithstanding.

Crsfshot came into Deviation with PR #1019. With this change the RC Input on my Crossfire TX now shows "CRSFshot".

ADC filtering is a tradeoff between noise reduction and latency. I played with it in Deviation long ago but shortening the filter time much at all increased the noise quite a bit. Maybe something to revisit. I recently saw a mention somewhere about a radio with a "mixer bypass". For aircraft with a flight controller handling the rc rates the ADC values could just be minimally scaled and sent on. Might save a few cycles over running the mixer code with even a simple 1-to-1 mix.

Asked about this on eLRS discord - eLRS sends a packet with the sync info to the radio, then waits for a stick update and only then sends the menu data immediately after receiving the stick data.

This makes sense, but I think whether a problem will occur depends on how quick is "immediately". At 500Hz and 400kbps I think it may overlap with the next stick update. Below are notes from just thinking through it yesterday. I guessed ELRS would turn the link around in 250us but it might be longer. Looking at my Crossfire module today it takes about 425us.


Serial data rate is 400000bps, which works out to 25us/byte. The rc packet is 26 bytes which takes 650us. Device ping packet is 6 bytes, 150us.

Deviation sends a packet every 2000us and is synced (crsfshot) with the tx module. When packet send time comes around a device/param command is sent if available, otherwise an rc packet is sent. Call the start of send T0. In the case that an rc packet is sent when the tx module is wanting to send a device info packet. Deviation finishes sending at T0+650. The module completes it's receive, enables serial transmit, and starts sending at say T0+900. The full device info packet is 16+name length, so say 32bytes. That takes 800us, so up to T0+1700. That leaves Deviation 300us to handle the received message before the next packet send time comes around.

Does deviation have multi threading/processing or is the complete process handled in one thread?

Regarding "how quick is immediately" I asked the eLRS Dev channel and capnbry helpfully timed the turnaround for a ESP32 based TX between recieving a stick update and sending data back on s.port, he measures 4-6us.

hexfet wrote: Crsfshot came into Deviation with PR #1019. With this change the RC Input on my Crossfire TX now shows "CRSFshot".

ADC filtering is a tradeoff between noise reduction and latency. I played with it in Deviation long ago but shortening the filter time much at all increased the noise quite a bit. Maybe something to revisit. I recently saw a mention somewhere about a radio with a "mixer bypass". For aircraft with a flight controller handling the rc rates the ADC values could just be minimally scaled and sent on. Might save a few cycles over running the mixer code with even a simple 1-to-1 mix.

Asked about this on eLRS discord - eLRS sends a packet with the sync info to the radio, then waits for a stick update and only then sends the menu data immediately after receiving the stick data.

This makes sense, but I think whether a problem will occur depends on how quick is "immediately". At 500Hz and 400kbps I think it may overlap with the next stick update. Below are notes from just thinking through it yesterday. I guessed ELRS would turn the link around in 250us but it might be longer. Looking at my Crossfire module today it takes about 425us.


Serial data rate is 400000bps, which works out to 25us/byte. The rc packet is 26 bytes which takes 650us. Device ping packet is 6 bytes, 150us.

Deviation sends a packet every 2000us and is synced (crsfshot) with the tx module. When packet send time comes around a device/param command is sent if available, otherwise an rc packet is sent. Call the start of send T0. In the case that an rc packet is sent when the tx module is wanting to send a device info packet. Deviation finishes sending at T0+650. The module completes it's receive, enables serial transmit, and starts sending at say T0+900. The full device info packet is 16+name length, so say 32bytes. That takes 800us, so up to T0+1700. That leaves Deviation 300us to handle the received message before the next packet send time comes around.

It's multi-threaded in the sense that menus, mixer/packet send, and serial receive all have their own execution contexts. Menu updates are in the main loop, while the others are interrupt driven.

That's quick turnaround. Deviation is the slow one.

Please try test build 504c1fd . This is mainly to gather some data. I found another issue on my tx and want to check if it's on others as well.

This build does add a extra delay after sending a command to give time to get a response. This is just a test but may change the behavior of the long name problem.

This build also replaces some telemetry value with debugging information. What I see on my tx is a large amount of "bad" data being received. When I put a logic analyzer on the data pin I don't see any collisions or frame errors in the captured data. That sent me looking elsewhere. Turns out the uart in the T8 is producing received data with frame errors and sometimes noise errors. The signal looks clean on an oscilloscope so I'm not sure what's going on. I've tried several i/o pin configurations, including opendrain with an external pull-up resistor. The data again looks good on o'scope and logic analyzer, but the Crossfire module doesn't recognize the data unless the pushpull output is used. Strange.

Here's what the debug telemetry data means. Please let me know what you see, and if there's any change in the long name problem.

Voltage (upper right on telemetry monitor) is a bit field that accumulates statuses from received data and a few flags indicating reasons a packet was dropped. It can be reset to zero by going to the CRSF config page. 128 is the desired value, I mostly see 192.
bit 7 - rx data ready
bit 6 - frame error
bit 5 - noise error
bit 4 - overrun error
bit 3 - invalid packet size
bit 1 - too much received data
bit 0 - CRC error

Current (below voltage) is a counter that increments on frame, noise, or overrun error
Capacity (below current) is a counter that increments when an invalid packet start byte is found (valid byte that is not ADDR_RADIO)

The counters are 8 bit and just wrap on overflow.

Thanks for the help!

Found the serial data problem which has been there since I put in the DMA code a few years back. Was changing from tx to rx before the last byte finished sending.

I don't know if this will fix the long name issue, but please try test build 458a87e . The serial bug is fixed and telemetry is back to normal.

I've ordered an ELRS module

I've got testing time today. The 458a87e is still the one to test?

The long name bug seems to be fixed. I have a menu with HappyModel ES24TX Pro on 500Hz.
Thnx

Anything special you'd like me to test?

Long name issue is fixed, at 500Hz the device page comes up quickly and accurately.

Seems that the CRSF menu is a lot faster to load now as well!

EDIT - testing was done on the latest 458a87e build