expressLRS

Are you building master branch on eLRS?

Using configurator 1 3.3, updated when I started this testing.

mooiweertje wrote: I've tested "BETAFPV 2G4MICRO" in my local ELRS build and what shows up in the menu is one digit shorter "BETAFPV 2G4MICR" using 99811b4.
Suggesting the problem with the BETAFPV 2G4MICRO is not the name length or you are not using the 1.3.3 ExpressLRS configurator which is only 4 days old.

Sorry if I am in fact being an idiot - I am checking everything carefully on my side and the error is still there. If I build the eLRS BETAFPV 2400 TX Micro firmware either using 2.0.1, or the master branch (which I use to enable the module's joystick and screen) then I get no entry on the DEVICE page.
I have flashed the DeviationTX 99811b4 and d0ca763 builds posted here as well as having built several from source and flashed them. Nothing is changing this from what I can see. The only way I can get that entry to appear is manually shortening DEVICE_NAME.
At this point I must be doing something wrong, but there are not many things that can be different between our two setups. I have a HappyModel ES24TX on OpenTX, my only choice now is to add the inverted UART option to that module and see if it behaves differently to the BETAFPV Micro TX. It shouldn't do, but maybe the OLED screen code is somehow causing problems in eLRS.

I took the HM ES24TX and flashed it for DeviationTX. On 2.0.1 it works fine. I moved to master branch and changed the DEVICE_NAME to "HM ES24TX1234567890" and the entry on devices page is now blank. I changed the name back to "HM ES24TX" and the entry on CRSF Devices page appears again.

I am flashing the DFU file from these DeviationTX builds and I can see the new version string on boot - could I be missing something else?

I use tag 2.0.1 on the local build for testing the "BETAFPV 2G4MICRO" name.
Now myself I use the official release 2.0.1. and I have seen no problems so far.
UART inverted has to be off for Deviation.

mooiweertje wrote: I use tag 2.0.1 on the local build for testing the "BETAFPV 2G4MICRO" name.
Now myself I use the official release 2.0.1. and I have seen no problems so far.
UART inverted has to be off for Deviation.

I checked out 2.0.1 and see the same problem. I am using your build on the T8Sgv2plus. Wish I knew what was different about our setups. I have used "HM ES24TX1234567" for 16 characters and my screen is blank.

Of course I am aware of the DeviationTX settings - I have openTX sync disabled and UART inverted disabled. With the shorter name it works fine on DeviationTX.

Does the fixed ID or # channels make any difference? Mine are set to default. - 8 channels (upped to 16 just now) and 123456. Nothing else special I can see about this model entry.

mooiweertje wrote: My menu disappears when I set packet rate to 500. I set it to 250 yesterday evening which is what accidentally solved the problem.
So it seems that a packetrate of 500 only works when the device name is shorter than 15 characters.

Progress! Yes, I have packetrate set to 500Hz all the time.

At 250Hz it's working!

My menu disappears when I set packet rate to 500. I set it to 250 yesterday evening which is what accidentally solved the problem.
So it seems that the menu only shows when the device name is shorter than 15 or when longer and the packetrate is below 500.

Thanks for all the testing. Looks like progress Apologies for the confusion on the test build. A new build is available ( 8c7d9f7 ). The behavior is same as previous but a simpler implementation.

To recap, two bugs have been fixed so far:
- Names longer than 15 characters are properly truncated to 15.
- Handling of device info messages that have parameter count of zero.

The zero param count seems to be unique to ELRS. it's not in my (old) CRSF spec nor does Crossfire TX behave that way. But it does look like the Crossfire.lua opentx script would handle it, so maybe ELRS reverse-engineered CRSF configuration from there. To help clarify things:
- Can you confirm you use the ELRS file "elrsv2.lua" on opentx to configure ELRS?
- Can you successfully use the Crossfire.lua opentx script to configure the ELRS module?
- On Deviation with 250Hz packet rate does clicking on the module name bring up a screen of configuration parameters?

Not sure what to make of the problem when packet rate is 500Hz. Need to think of something to test.

Can I wait for a fix for 500hz to continue testing or do you want me to test 8c7d9f78c7d9f7?

LOL didn't notice the doubled commit number. It's 8c7d9f7c.

I don't expect the next test build to have a fix, but I'll probably put something up soon with some debug code to check some things. Fine to wait for that. Appreciate the testing.

hexfet wrote: Thanks for all the testing. Looks like progress Apologies for the confusion on the test build. A new build is available ( 8c7d9f7 ). The behavior is same as previous but a simpler implementation.

To recap, two bugs have been fixed so far:
- Names longer than 15 characters are properly truncated to 15.
- Handling of device info messages that have parameter count of zero.

The zero param count seems to be unique to ELRS. it's not in my (old) CRSF spec nor does Crossfire TX behave that way. But it does look like the Crossfire.lua opentx script would handle it, so maybe ELRS reverse-engineered CRSF configuration from there. To help clarify things:
- Can you confirm you use the ELRS file "elrsv2.lua" on opentx to configure ELRS?
- Can you successfully use the Crossfire.lua opentx script to configure the ELRS module?
- On Deviation with 250Hz packet rate does clicking on the module name bring up a screen of configuration parameters?

Not sure what to make of the problem when packet rate is 500Hz. Need to think of something to test.

- elrsv2.lua is the current elrs OpenTX configuration script, designed to mimic the crossfire lua behaviour. I worked with the Dev to test this prior to V2, it was my hope that this would suit other radios such as deviationTX better than a one-off configuration script specific to eLRS. This script is used by all eLRS users on the current release.
- yes, both the original crossfire script and the more recent "TBS agent lite" lua scripts work with the eLRS TX modules.
- yes, on 250hz it works as expected. I asked and apparently at 500hz there's not enough time to send the entire >14 character device name before another stick update, so the transfer of device name is interrupted by a stick update on OpenTX (device info cannot be chunked unlike other crsf types). On OpenTX this brief pause doesn't break the transfer and the buffer can still be read, whereas on deviationTX the same behaviour appears to clear the buffer.

I saw some commits come by on github showing clearance of a buffer. Is this the buffer causing the 500hz long name issue?

mooiweertje wrote: I saw some commits come by on github showing clearance of a buffer. Is this the buffer causing the 500hz long name issue?

Check the last post, it is indeed the problem. I checked with the dev who wrote the menu code and OpenTX can tolerate stick updates mid-way through the device-info page data, seems DeviationTX is not able to read that buffer when the same thing happens.

if the sampling rate of the sticks is lower than the packet rate 500Hz doesn't make much sense maybe?

mooiweertje wrote: if the sampling rate of the sticks is lower than the packet rate 500Hz doesn't make much sense maybe?

True, is deviationTX still using a 4ms hard-coded mixer interval? I was using 500Hz because I had that as a default across my eLRS kit, didn't give it much thought. My other radios are EdgeTX which can do 500Hz sampling.

Having a faster sample rate on the sticks could "magicaly" solve the issue.

belrik wrote:

mooiweertje wrote: if the sampling rate of the sticks is lower than the packet rate 500Hz doesn't make much sense maybe?

True, is deviationTX still using a 4ms hard-coded mixer interval? I was using 500Hz because I had that as a default across my eLRS kit, didn't give it much thought. My other radios are EdgeTX which can do 500Hz sampling.

Below logic sounds flawed to me. But there does seem to be some type of race condition. Very rarely the menu does show on 500Hz packet rate.

Below logic sounds flawed because because on 500Hz more data is sent so needs less time to send the 14 characters. There is something more going on.

Sound logic would be that the buffer is cleared while the buffer is being filled. There is a race condition on some flag that monitors that the buffer is being filled or ready to be cleared. Something like, the filing is so fast that the busy filling flag is not even set when the stick sample is about to clear the buffer. When the data is small enough the filling and collecting (produce and consume) process is so fast it is finished already before any flag is set and the next stick sample is clearing the buffer. The filling flag is set at a wrong moment. The code is optimized in such a way that it only works well when the the stick sample rate is higher than the packet rate. I hope my terminology is correct and I don't know the code so I can't say what is exactly going on.

belrik wrote:

hexfet wrote: - yes, on 250hz it works as expected. I asked and apparently at 500hz there's not enough time to send the entire >14 character device name before another stick update, so the transfer of device name is interrupted by a stick update on OpenTX (device info cannot be chunked unlike other crsf types). On OpenTX this brief pause doesn't break the transfer and the buffer can still be read, whereas on deviationTX the same behaviour appears to clear the buffer.

Here is a complex 'flag' ready to clear.
if (telemetryRxBufferCount == 1 && (data < 2 || data > TELEMETRY_RX_PACKET_SIZE-2)) {
telemetryRxBufferCount = 0;
memset(telemetryRxBuffer, 0, TELEMETRY_RX_PACKET_SIZE); // clear buff for device ping data detection
return;
}

Here a buffer is not full/filling flag
if (telemetryRxBufferCount < TELEMETRY_RX_PACKET_SIZE) {
telemetryRxBuffer[telemetryRxBufferCount++] = data;
} else {
telemetryRxBufferCount = 0;
memset(telemetryRxBuffer, 0, TELEMETRY_RX_PACKET_SIZE); // clear buff for device ping data detection
return;
}

in the clear flag I see some substractions of 2 which I don't see in the filling flag. When the 'filing flag' is false the buffer is also cleared..
I don't see when the buffer is being read.

Consider 250Hz vs 500Hz packet rate. Baud rate doesn't change. The sampling rate is separate to the baud rate, the sample rate is just the number of times data is sent to the module from the radio per second. Same number of available bytes are on the wire between module and radio every second. You have twice as many stick updates from the radio to the module. So this results in half as much time between every stick update. Text fields being sent from the module to the radio now have half as much time to send data before being interrupted by a stick update. This is all happening over a single half-duplex wire with JR bay CRSF modules.
Normally crossfire deals with this by allowing large frames to be "chunked" and split up, but the device-info type doesn't support chunking. So it simply doesn't fit between two stick updates when longer device names are used.
Another fix would be to increase the baud rate... These eLRS modules support up to 5.25Mb/s baud rates for ESP32 based TX, and they all support 1.75Mb/s baud even STM32 based TX. Faster baud would mean that the time slice between stick updates should have more payload size. I would guess we are using the older Crossfire standard, which doesn't auto-negotiate baud rates above 400Kb/s.

mooiweertje wrote: Below logic sounds flawed to me. But there does seem to be some type of race condition. Very rarely the menu does show on 500Hz packet rate.

Below logic sounds flawed because because on 500Hz more data is sent so needs less time to send the 14 characters. There is something more going on.

Sound logic would be that the buffer is cleared while the buffer is being filled. There is a race condition on some flag that monitors that the buffer is being filled or ready to be cleared. Something like, the filing is so fast that the busy filling flag is not even set when the stick sample is about to clear the buffer. When the data is small enough the filling and collecting (produce and consume) process is so fast it is finished already before any flag is set and the next stick sample is clearing the buffer. The filling flag is set at a wrong moment. The code is optimized in such a way that it only works well when the the stick sample rate is higher than the packet rate. I hope my terminology is correct and I don't know the code so I can't say what is exactly going on.

belrik wrote:

hexfet wrote: - yes, on 250hz it works as expected. I asked and apparently at 500hz there's not enough time to send the entire >14 character device name before another stick update, so the transfer of device name is interrupted by a stick update on OpenTX (device info cannot be chunked unlike other crsf types). On OpenTX this brief pause doesn't break the transfer and the buffer can still be read, whereas on deviationTX the same behaviour appears to clear the buffer.