CRSF protocol for TBS Crossfire?

ersky9xr is the port of the er9x firmware to the 9XRPRO radio.
User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 4:24 pm

New test version posted. I've removed the #ifdef REVX in frsky.cpp.
I've moved the debug so it provides information if/when you get a 111 error.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 4:37 pm

I'm getting a syntax error for these lines, seemingly drawtext doesn't accept a byte array:
array byte device1Name[32]
rem -- later on
drawtext(0, i * 8 + 9, device1Name[0], INVERS)
I've also tried without subscript `[0]` with the same result.
when drawtext is passed a byte array, it doesn't accept 4th parameter for attribute
Trying the new version for crossfirereceive overflow.

Tried the debug version, triggering an error on `crossfirereceive`:
0018 0000 0052 0040
0020 0054 0058 0000
0000 0000 000c 0084
TelRxCount counting up quickly as usual, static value next to it says 0904

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 5:01 pm

The debug is showing a length of 0x52 (82), which doesn't fit in the array of size 0x40 (64).
May be a problem with the passing of the data to the script, or maybe the packet really is that long!

I'll check drawtest works with an array.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 5:02 pm

I've made a typo when entering the message :)
Seems like drawtext with a byte array argument doesn't accept 4th argument. Without 4th argument it works.

I really miss some kind of indirection to not write code like this:
if i = 0
drawtext(0, i * 8 + 9, device1Name)
elseif i = 1
drawtext(0, i * 8 + 9, device2Name)
elseif i = 2
drawtext(0, i * 8 + 9, device3Name)
end
According to my logic analyzer there are no such big packets arriving, and they're out of CRSF spec. It seems like CRSF buffer gets clogged because of not being cleared properly. I've increased by Rx&Tx buffer sizes in script to 80 and now I get no error, but I only see the first device (XF Micro TX) and not the Micro Rx.

Here, with 80-byte buffer, I go into script for the first time and get this:
IMG_20180408_201518.jpg
If I then go to debug:
IMG_20180408_201529.jpg
Going into script again I never get any data from `crossfirereceive` until a power cycle.

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 6:23 pm

I have the fix (just needs testing) for the drawtext problem missing the 4th parameter. In passing, drawtext can handle a 5th parameter which is a length parameter for strings that are not 0 (zero) terminated. I need to document this!

I'm looking to see why later messages seem to be wrong. If a packet arrives and there is not sufficient space in the fifo, it is discarded.
I think I may be putting the CRC into the fifo and not removing it.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 6:56 pm

I've just posted another test version.
I didn't quite get the packet passing to the script correct. It should now be OK (as well as the fix, untested, for the 4th parameter to drawtext).
When you receive a crossfire packet, you get 3 values, length, command and data. The value of length is the number of bytes of data, not including the command byte.

I haven't included indirection as I'm concerned it might allow a write to somewhere that causes a fault that might stop the radio controlling the model properly.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 7:05 pm

I understand, safety first.
Would be nice to find another way of handling arrays of strings rather than having a huge `if idx = 0 then array0`.
Maybe you could allow longer arrays then, and I'll flatten a two-dimensional array into one-dimensional?

On a sidenote, am I putting something at risk by using AO3401 instead of 3407A? :)

Is this the newest version? "08-Apr-2018 19:49"
Last edited by Hertz on Sun Apr 08, 2018 7:28 pm, edited 1 time in total.

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 7:27 pm

Looks to have about the same spec so should be OK.

I'll allow byte arrays to be up to 252 long (instead of 100). I have a limitation at present where the dimension size is sometimes stored in a byte, so I cannot allow it to exceed 255. Since I also need alignment to a 4-byte boundary, I've picked 252 as the maximum.

Maybe I can allow some form of pointer for read only operations.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
jhsa
Posts: 18129
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: CRSF protocol for TBS Crossfire?

Post by jhsa » Sun Apr 08, 2018 7:34 pm

As far as I remember the AO3407A has a higher gate voltage than the 3401, which I believe is only of 12V..

João



My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 7:44 pm

jhsa I've noticed that indeed, thank you. Looks like it may be on the edge of usability with a fully-charged 3S battery then? I'll replace it ASAP once I get the AO3407A.

With the latest binary I've found in ersky9x test versions thread I no longer get a return value different from 0 from `crossfirereceive()`. Only first `crossfiresend()` succeeds, subsequent ones return 0. Fifo space shows 0x7f.

Output of the logic analyzer looks nonsensical as well, not like 400k baud serial at all. Receiver outputs no pulses as if transmitter wasn't sending anything. Weird.

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 9:04 pm

Not sure why you have that, I just flashed that version to my 9Xtreme and I get a correct output, and packets are sent OK from a script.

Check the protocol settings are still correct.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 9:13 pm

Wow, I had both modules active and set to PPM, no idea why it happened.
I now get continuous messages, but seems like crossfirereceive has command and count out arguments swapped.
I'm finishing for today, it seems like I have enough working functions to finish a good part of the script now. Thank you Mike!

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 10:07 pm

crossfirereceive( length, command, data ) is the order the values are in.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 10:16 pm

Good to know, I suspected that after reading parser.cpp, but on the page 5 you listed another order of arguments, now it makes sense.
So what is returned in payload now, data immediately following `length`, e.g. `&packet[2]` and so on? CRSF specification says `length` includes 1 byte for length itself, do you subtract it?

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Apr 08, 2018 10:26 pm

I understood the length value included the command, data and crc, but not the length itself, and this is what I'm sending in the control packets.
A received packet is ID, length, command, payload, crc.
crossfirereceive sets the length value to the number of bytes in the payload. The crc is not included in the payload.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sun Apr 08, 2018 10:54 pm

Good, in case you didn't see this before, I attach this document.
I'm not sure where I took the info about length value including itself, maybe while reading OpenTX code. Looks like it includes CRC instead, and first byte (sync or device address) plus second byte (frame length) constitute a 2-byte header.

Btw, 252-byte max array length will be really helpful
Attachments
CRSF Rev07 (1).pdf
(228.58 KiB) Downloaded 60 times

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Mon Apr 09, 2018 2:55 pm

Mike, I'm looking at what will be necessary for full implementation of crossfire script, and I noticed there are popup functions to ask user for confirmation: `popupConfirmation`, `popupWarning`
Would it be possible to implement something like it to ask user for confirmation? I could implement in inside my script, but it will be cumbersome :-)

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Mon Apr 09, 2018 5:35 pm

That might be possible since I have a popup() routine for the radio to use. I've noted it so I'll look into it over the next few days.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Mon Apr 09, 2018 5:37 pm

Please allow bigger than 100 byte arrays as well.:)

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Mon Apr 09, 2018 8:26 pm

Is there an easier way to debug the scripts than constantly reflashing my radio? :-(
IMG_20180409_232452_HDR.jpg

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Mon Apr 09, 2018 10:09 pm

I've got the change in to allow 252 byte arrays, and I've put in some code that might do a popup, but it will be unlikely I'll be able to test these tomorrow.

I can't think of an easy way to test a script other than putting it on the SD card. I do have a program that runs in QtCreator that I use to debug the actual interpreter. It does process a script, but doesn't simulate the radio, just displays lots of information about what happened. It can detect some errors (syntax mainly) in a script.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Mon Apr 09, 2018 10:34 pm

I really miss structs/records and the ability to pass them by value/reference :)

xfapv
Posts: 1
Joined: Fri Apr 13, 2018 11:29 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by xfapv » Fri Apr 13, 2018 11:34 pm

Is CRSF supported in er9X?

If not, is there any way to run CRSF on the original TH9X (without the sky board)?

Telemetry and bidirectional communication is not really important. Just a more stable and faster control than PPM.

Hertz
Posts: 72
Joined: Wed Sep 30, 2015 2:14 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by Hertz » Sat Apr 14, 2018 10:02 am

There's no support in Er9x, only ErSky9x AFAIK.

Old-fashioned TH-9X with an Atmega64?
If you did the telemetry mod for pin-5 of JR module bay, then there is a chance that it could work at least in theory (given firmware support), but I'm not sure if Atmega can cope with 400k baud bidir serial. CRSF uses telemetry-pin for both RC-channels and "telemetry", in fact both telemetry and RC-channels are just a special packet type in CRSF terms, that's why you need the telemetry mod.

Mike likely knows more.

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sat Apr 14, 2018 10:52 am

The M64 doesn't have enough flash space to add another protocol, there is no hardware for driving the SPort (telemetry) signal at 400kHz, and the processor isn't really capable of handling 400kHz serial either.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

LoafFPV
Posts: 16
Joined: Fri Apr 06, 2018 4:51 am
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by LoafFPV » Wed May 16, 2018 6:53 pm

I know hertz is working on the crossfire script, but I wanted to ask if the crossfire configuration is something that would be included in future releases or the script just a separate part as a SD card content download?
Is the new script language used for the crossfire script that is being worked on?

On The OpenTX Taranis version someone said that it was part of the menus in openTX and not a separate script?

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Wed May 16, 2018 10:11 pm

If it is part of the menus in openTx, I can't see it in Companion, so I think it is still a LUA script there.

The script that Hertz is working on is in the script language used in ersky9x. It will be posted as a download for the SD card.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

prohfesor
Posts: 2
Joined: Wed Jul 26, 2017 5:04 pm
Country: -

Re: CRSF protocol for TBS Crossfire?

Post by prohfesor » Sun Jul 15, 2018 11:55 am

Sorry guys,
I'm trying to run crossfire script on 9XRpro with latest 222b3, but keep getting:
"Script error, error 9 at line 68"

This seems to mean that function "crossfiresend()" is unknown.
Can something be done to make crossfire work on 9xrpro?

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Jul 15, 2018 12:32 pm

Oops! I've missed adding it to the table of known functions, all the rest of the code is in. I don't have any crossfire hardware so haven't been able to test anything.

I'm just sorting a couple of other things in scripting and intend to post 222b4 shortly. I've added the function to the table so b4 should work.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
MikeB
9x Developer
Posts: 15805
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: CRSF protocol for TBS Crossfire?

Post by MikeB » Sun Jul 15, 2018 9:12 pm

222b4 now posted.

Mike
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

Post Reply

Return to “ersky9xr”