Ah, it’s nice to see this progress. I got ACCESS vanilla working on the Taranis X9 Lite / R-XSR combination. Not ready to test LuaGCS yet though.
Alex, what does this error mean?
Which message: CRT not calibrated? no idea it comes from ardupilot, I’d say is a “compass not calibrated” truncated because the r-xsr is too close to the TX and is dropping packets
Lol. No, on Yaapu GCS, right hand side, 5th line from the top 
I looked in mavlite.lua and GCS.lua, and see msgRequestStatus == 4, but what causes it?
ROFL oops 
err_exp means timed out waiting for a response, each time I send a mavlite message I start a 5 seconds timer
Thanks Alex. Ok, I’m pushing ahead with the other transactions. Shouldn’t take took long.
1 Like
OH wow that is amazing
thanks Barry, need testers so if you try it report back plaese!
This should work on any OpenTX based system right?
Yes, what we have found out is that it’s very dependent on the frisky Tx Rx firmware combo
Hi Alex, what is the best way to test the other transactions?
Param Set, Command Long + Ack.
Hi Eric,
if param get is working, let my script run in a page with just a couple parameters , once the values have been retrieved, try a param update by pressing enter on a param (it will flash) and send it to the backend by another enter press, saem thing for a command, try pressure calibrate, if you can’t work this way I need to create more test scripts that send the same param set or command over and over, let me know if you need such test scripts!
Thank you Alex. I did try to figure out the LUA but your explanation makes it much easier.
Alex, I need some help. When you get a chance could you flash and run v2.61.6 with Mavlite_Support. I’m still getting the timeout error, which suggests you are not receiving #22 Param_Value, yet I appear to send it.
The other message types are ready for testing, but I don’t want to move ahead while I have this basic problem.
I’m testing in Air mode into an R-XSR receiver, and all that part seems ok. the DIY range of messages are working fine.
#define Support_MavLite
and maybe
#define Debug_MavLite
#define Frs_Debug_Payload
The routines are in the S.Port class, in SPort.h.
Hi Eric, you receive the param get, process it and send a param value which does not work?
Sounds like we might have a problem with the mavlite encoder?
Yes its possible, but debugging shows the exact same byte stream as you had in your crc table the other day. If I could get sight of the bytes entering lua, and why the lua error occurs it would pinpoint the failure.
ok, I’ll compile a version that dumps all sport traffic to a file
Or perhaps I could send you a file of the bytes being sent to the receiver and on to the Taranis and LUA?
Good afternoon Alex.
Please can you give me some help debugging my mavlite byte stream into the R-XSR and ultimately the Taranis and your yaapuGCS.
My SPort out file is here, but …
in preparing my sport file for you, I realised I’m sending the 0x32 for every chunk, like this:
32 00 11 16 71 3D 0A
32 01 3E 41 54 43 5F
32 02 52 41 54 5F 52
32 03 4C 4C 5F 50 3E
32 00 0C 16 00 00 00
32 01 00 54 55 4E 45
32 02 5F 4D 49 4E A6
32 00 11 16 71 3D 0A
32 01 3E 41 54 43 5F
32 02 52 41 54 5F 50
32 03 49 54 5F 49 3A
32 00 11 16 CD CC CC
32 01 3D 41 55 54 4F
32 02 54 55 4E 45 5F
32 03 41 47 47 52 CA
32 00 11 16 00 00 00
32 01 00 41 54 43 5F
32 02 52 41 54 5F 59
Is this correct?
Here is your previous post for reference
1 Like
Eric sorry but I won’t be able to dive into this for a couple days 
Regarding the 0x32, yes each frame should have a 1byte sensor_id (0x1B), 1 byte frame type (0x32), 2 bytes appid (0xAABB) and 4 bytes data 0xAABBCCDD