[Feature request] - Update the ELRS telemetry RFMD list to include expanded ELRS v3 RF modes
rmaia3d opened this issue · 18 comments
Is your feature request related to a problem? Please describe
ELRS v3 introduced several new RF modes, leading to inaccurate RF mode display on widget top bar if using ELRS v3. As is, it works fine for those using ELRS v2, though.
Describe the solution you'd like
A new list should be added in funcs_h.lua file (in the title() function), which includes the 13 different RF modes from ELRS v3 for correct displaying. However, to keep backwards compatibility with ELRS v2, the current list (same file, line 64) should be kept. The script should then detect if the user is using ELRS v2 or v3 and choose the list accordingly.
Describe alternatives you've considered
If it was just a matter of expanding the current list, I'd gladly to do it myself and contribute, but the detection between ELRS v2 and v3 is above my Lua scripting skills...
Additional context
Reference for all RF modes implemented in v3:
https://www.expresslrs.org/3.0/info/signal-health/#rf-mode-indexes-rfmd
Can you please record a EdgeTX (OpenTX) CSV log with ELRS v3 telemetry for testing?
We already use crossfireTelemetryPush() / crossfireTelemetryPop() to identify ELRS (vice 'plain' CRSF), so perhaps that will give a route to differentiating v2 / v3.
Would it be this log? I've set it to start logging at each 0.1s as soon as the first telemetry packet is received.
This was recorded using ELRS v3.1.2 at 150Hz rate (RFMD 5).
If you need other data, or a different log, please just let me know I'll try to provide it!
Log is perfect thanks.
Tested both the pre-compiled and the source only zips, and they have the same behavior. The top bar always shows 50Hz, regardless of the active RFMD. I tried switching to different RFMD and all of them show as 50Hz on the widget, so maybe there's a problem in the RFMD parsing routines...
The problem is (inter alia) in the ELRS version detection. I'll post some more diagnostics later.
If it is of any help, I hooked up a logic analyzer to the TX/RX lines at the FC side, sniffing the data coming from the ELRS receiver for the first 10 seconds since power up. You can open it with DSView, which is a free download from here:
https://www.dreamsourcelab.com/download/
This file is supposed to have the UART protocol decoders already setup (it shows each byte in hex format), but I'm not sure if I got the baud rate correct (I assumed 420k baud). Let me know if you need anything else!
Oh, and here is a short description of the CRSF protocol. I'm using this page as a reference to try and make some sense from the decoded data... :)
https://github.com/ExpressLRS/ExpressLRS/wiki/CRSF-Protocol
Edit: I've made a second capture at a higher resolution, which I believe is much more accurate than the first capture above. Here it is:
The problem will be with the new detection of ELRS version. Without access to the hardware, this is somewhat difficult.
Please can you do the following:
- Decompress the attached elrs.lua.zip and install its
SCRIPTS/TELEMETRY/iNav/*.lua; delete any*.luacfor the four new files (i.e. just replace the*.lua) - Run the INAV lua widget again.
- There should be log file(s) LOGS/E_nnnnnnnn.txt where nnnnnnnn is a large number (
time_tfrom the RTC). - Post the log file(s) here and I can see what the crossfireTelemetryPop() looks like.
Note this may not fix anything, hopefully gets the required data.
I have just tried the zip file, and when I try opening the INAV widget, I get this error message (on the radio screen):
ERROR in background(): bad argument #2 to 'write' (string expected, got table
It did create the log files on the SD card, though. But the files are all empty (zero bytes).
I imagine the challenge will be detecting between v2 and v3. Perhaps the logic analyzer I posted above is of any help?
Thanks, I'll fix the debug.
Unfortunately, me learning to understand the logic analyser output is unlikely to happen.
Can you try this update please
elrs.lua.zip
Probably won't display the correct RFMD, but it might just show the data returned from the API. We are looking at
https://github.com/ExpressLRS/ExpressLRS/wiki/CRSF-Protocol#device-info--device-ping-response-0x29
A hex dump from that would be useful.
Ok, now the scripts worked! Tried three Rx power ups, I noticed it only generated a log file on the two power ups I did with the widget open on the radio. The third power up, with the radio on the main screen, didn't generate a log. Probably normal, but just thought I'd report. And here are the logs I got:
E_1673781737.txt
E_1673781882.txt
Looks like it does report 3 1 2 on fields 26 to 28, and I'm in fact running ELRS v3.1.2. :)
Regarding the logic analyzer data, yeah, it can be a bit daunting if not used to it. No problems there! Hopefully these logs provide the needed data.
Cool. We're almost there. First of all the data:
{
[1] = 234,
[2] = 238,
[3] = 72,
[4] = 77,
[5] = 32,
[6] = 69,
[7] = 83,
[8] = 50,
[9] = 52,
[10] = 84,
[11] = 88,
[12] = 32,
[13] = 80,
[14] = 114,
[15] = 111,
[16] = 0,
[17] = 69, // 4
[18] = 76, // 5
[19] = 82, // 6
[20] = 83, // 7
[21] = 0, // 8
[22] = 0, // 9
[23] = 0, // 10
[24] = 0, // 11
[25] = 0, // 12
[26] = 3, // 13
[27] = 1,
[28] = 2,
[29] = 27,
[30] = 0,
}
(// comments are mine)
I think the solution will now be easy; and easiest if I ask you to alter elrs.lua.
First: line 65
majId = data[offset+8] - 0x30
Is wrong from two counts (well three really, the 3rd being I'm a idiot, but we'll overlook that for now).
- The value is binary, not ASCII
- The offset from
offsetshould be 13, not 8.
So something like:
majId = data[offset+13]
May just fix it all. Please give it a try.
We are getting somewhere!! I changed line 65 as you suggested, but still no change to the parsed rate in the widget top bar. I then copied part of your code so majId would also be dumped to the log file. With [offset+13], it was writing 0 to the end of the log file. Also, I started getting multiple log files (up to 15) per initial Rx startup.
I then started varying the offset number, one at a time, and checking the log output. With [offset+9] the output majId was 3 and then the parsed rate was correct. Even changing the ELRS setup to other rates, the top bar changed accordingly. Yay!! :)
Here's how my erls.lua looks like, from lines 58 to 68:
if deviceId == id then
local ut = getRtcTime()
local s = string.format("/LOGS/E_%d.txt", ut)
local fh = io.open(s,"wb")
dbg_serialize(fh, data)
if ((fieldGetValue(data,offset,4) == 0x454C5253) and (deviceId == 0xEE)) then
majId = data[offset+9]
dbg_serialize(fh, majId)
end
io.close(fh)
end
Excellent, we're there. Doing this without h/w is painful.
I'll update the PR, disabling the debug.
For future reference, annotated DevInfo return:
{
[1] = 234,
[2] = 238,
[3] = 72,
[4] = 77,
[5] = 32,
[6] = 69,
[7] = 83,
[8] = 50,
[9] = 52,
[10] = 84,
[11] = 88,
[12] = 32,
[13] = 80,
[14] = 114,
[15] = 111,
[16] = 0,
[17] = 69, // 0 'E'
[18] = 76, // 1 'L'
[19] = 82, // 2 'R'
[20] = 83, // 3 'S'
[21] = 0, // 4
[22] = 0, // 5
[23] = 0, // 6
[24] = 0, // 7
[25] = 0, // 8
[26] = 3, // 9 <- major
[27] = 1, // 10 <- minor
[28] = 2, // 11 <- patch
[29] = 27,
[30] = 0,
}
Updated Zips.
LuaTelemetry_v2.2.0+e3_lua.zip
LuaTelemetry_v2.2.0+e3.zip