expressLRS

More
13 Jan 2022 12:56 - 13 Jan 2022 12:58 #77674 by belrik
Replied by belrik on topic expressLRS
Are you building master branch on eLRS?

Using configurator 1 3.3, updated when I started this testing.
Last edit: 13 Jan 2022 12:58 by belrik.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 13:13 - 13 Jan 2022 13:14 #77675 by belrik
Replied by belrik on topic expressLRS

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.
Last edit: 13 Jan 2022 13:14 by belrik.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 13:47 - 13 Jan 2022 13:50 #77676 by belrik
Replied by belrik on topic expressLRS
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?
Last edit: 13 Jan 2022 13:50 by belrik.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 13:50 #77677 by mooiweertje
Replied by mooiweertje on topic expressLRS
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.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 14:08 #77678 by belrik
Replied by belrik on topic expressLRS

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.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 14:14 - 13 Jan 2022 14:30 #77679 by belrik
Replied by belrik on topic expressLRS
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.
name=CRSF
mixermode=Advanced
type=multi
[radio]
protocol=CRSF
num_channels=16
fixed_id=123456
tx_power=

[channel1]
reverse=1
template=simple
[mixer]
src=AIL
dest=Ch1

[channel2]
template=simple
[mixer]
src=ELE
dest=Ch2

[channel3]
scalar-=100
template=simple
[mixer]
src=THR
dest=Ch3

[channel4]
reverse=1
template=simple
[mixer]
src=RUD
dest=Ch4

[channel5]
template=expo_dr
[mixer]
src=SW H1
dest=Ch5
curvetype=fixed
[mixer]
src=SW H1
dest=Ch5
switch=SW H1
scalar=-100
curvetype=fixed
[mixer]
src=SW H1
dest=Ch5
switch=SW H0
curvetype=fixed

[channel6]
template=expo_dr
[mixer]
src=AIL
dest=Ch6
scalar=-100
curvetype=fixed
[mixer]
src=AIL
dest=Ch6
switch=SW B1
scalar=0
curvetype=fixed
[mixer]
src=AIL
dest=Ch6
switch=SW B0
curvetype=fixed

[channel7]
template=expo_dr
[mixer]
src=AIL
dest=Ch7
curvetype=fixed
[mixer]
src=AIL
dest=Ch7
switch=SW G1
scalar=-100
curvetype=fixed
[mixer]
src=AIL
dest=Ch7
switch=SW G0
curvetype=fixed

[channel8]
template=expo_dr
[mixer]
src=AIL
dest=Ch8
scalar=-100
curvetype=fixed
[mixer]
src=AIL
dest=Ch8
switch=SW D1
scalar=0
curvetype=fixed
[mixer]
src=AIL
dest=Ch8
switch=SW D0
curvetype=fixed

[channel9]
template=expo_dr
[mixer]
src=AIL
dest=Ch9
scalar=-100
curvetype=fixed
[mixer]
src=AIL
dest=Ch9
switch=SW C1
scalar=0
curvetype=fixed
[mixer]
src=AIL
dest=Ch9
switch=SW C0
curvetype=fixed

[channel10]
template=expo_dr
[mixer]
src=AIL
dest=Ch10
scalar=-100
curvetype=fixed
[mixer]
src=AIL
dest=Ch10
switch=SW A1
scalar=0
curvetype=fixed
[mixer]
src=AIL
dest=Ch10
switch=SW A0
curvetype=fixed

[channel11]
template=expo_dr
[mixer]
src=Virt1
dest=Ch11
scalar=0
curvetype=fixed
[mixer]
src=Virt1
dest=Ch11
switch=Virt1
curvetype=fixed

[channel12]
template=expo_dr
[mixer]
src=Virt2
dest=Ch12
scalar=0
curvetype=fixed
[mixer]
src=Virt2
dest=Ch12
switch=Virt2
curvetype=fixed

[channel13]
template=expo_dr
[mixer]
src=Virt3
dest=Ch13
scalar=0
curvetype=fixed
[mixer]
src=Virt3
dest=Ch13
switch=Virt3
curvetype=fixed

[channel14]
template=expo_dr
[mixer]
src=Virt4
dest=Ch14
scalar=0
curvetype=fixed
[mixer]
src=Virt4
dest=Ch14
switch=Virt4
curvetype=fixed

[trim1]
src=Virt1
pos=TRIMLV+
neg=TRIMLV-
step=194
[trim2]
src=Virt2
pos=TRIMRV+
neg=TRIMRV-
step=194
[trim3]
src=Virt3
pos=TRIMLH+
neg=TRIMLH-
step=194
[trim4]
src=Virt4
pos=TRIMRH+
neg=TRIMRH-
step=194
[timer2]
type=countdown
time=10
[datalog]
switch=None
rate=1 sec
[safety]
Auto=min
[gui-128x64]
V-trim=59,10,1
H-trim=5,59,3
V-trim=65,10,2
H-trim=74,59,4
Small-box=2,22,tx Quality
Small-box=2,31,rx Quality
Small-box=2,40,Power
Model=75,20
Battery=102,1
Toggle=4,10,0,3,0,None
Toggle=13,10,0,5,0,None
Toggle=22,10,0,4,0,None
Toggle=31,10,0,0,0,None
Toggle=40,10,0,0,0,None
TxPower=102,7
Small-box=2,12,Volt
quickpage1=Telemetry monitor
[voice]
(binary data)
Last edit: 13 Jan 2022 14:30 by belrik.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 15:35 - 13 Jan 2022 15:39 #77682 by belrik
Replied by belrik on topic expressLRS

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!
Attachments:
Last edit: 13 Jan 2022 15:39 by belrik.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 15:36 #77683 by mooiweertje
Replied by mooiweertje on topic expressLRS
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.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 19:16 - 13 Jan 2022 19:56 #77684 by hexfet
Replied by hexfet on topic expressLRS
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.
Last edit: 13 Jan 2022 19:56 by hexfet.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 19:29 #77685 by mooiweertje
Replied by mooiweertje on topic expressLRS
Can I wait for a fix for 500hz to continue testing or do you want me to test 8c7d9f78c7d9f7?

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 20:08 #77686 by hexfet
Replied by hexfet on topic expressLRS
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.

Please Log in or Create an account to join the conversation.

More
13 Jan 2022 22:15 - 14 Jan 2022 01:23 #77687 by belrik
Replied by belrik on topic expressLRS

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.
Last edit: 14 Jan 2022 01:23 by belrik.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 12:11 #77688 by mooiweertje
Replied by mooiweertje on topic expressLRS
I saw some commits come by on github showing clearance of a buffer. Is this the buffer causing the 500hz long name issue?

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 12:18 #77689 by belrik
Replied by belrik on topic expressLRS

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.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 12:43 #77690 by mooiweertje
Replied by mooiweertje on topic expressLRS
if the sampling rate of the sticks is lower than the packet rate 500Hz doesn't make much sense maybe?

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 13:00 #77691 by belrik
Replied by belrik on topic expressLRS

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.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 13:21 #77693 by mooiweertje
Replied by mooiweertje on topic expressLRS
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.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 13:30 - 14 Jan 2022 13:32 #77694 by mooiweertje
Replied by mooiweertje on topic expressLRS
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.

Last edit: 14 Jan 2022 13:32 by mooiweertje.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 14:19 #77696 by mooiweertje
Replied by mooiweertje on topic expressLRS
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.

Please Log in or Create an account to join the conversation.

More
14 Jan 2022 14:32 - 14 Jan 2022 14:40 #77697 by belrik
Replied by belrik on topic expressLRS
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.

Last edit: 14 Jan 2022 14:40 by belrik.

Please Log in or Create an account to join the conversation.

Time to create page: 0.092 seconds
Powered by Kunena Forum