Page 6 of 8

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 4:24 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 4:37 pm
by Hertz
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 5:01 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 5:02 pm
by Hertz
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.

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 6:23 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 6:56 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 7:05 pm
by Hertz
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"

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 7:27 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 7:34 pm
by jhsa
As far as I remember the AO3407A has a higher gate voltage than the 3401, which I believe is only of 12V..

João




Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 7:44 pm
by Hertz
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.

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 9:04 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 9:13 pm
by Hertz
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!

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 10:07 pm
by MikeB
crossfirereceive( length, command, data ) is the order the values are in.

Mike

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 10:16 pm
by Hertz
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?

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 10:26 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Apr 08, 2018 10:54 pm
by Hertz
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

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 2:55 pm
by Hertz
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 :-)

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 5:35 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 5:37 pm
by Hertz
Please allow bigger than 100 byte arrays as well.:)

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 8:26 pm
by Hertz
Is there an easier way to debug the scripts than constantly reflashing my radio? :-(
IMG_20180409_232452_HDR.jpg

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 10:09 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Mon Apr 09, 2018 10:34 pm
by Hertz
I really miss structs/records and the ability to pass them by value/reference :)

Re: CRSF protocol for TBS Crossfire?

Posted: Fri Apr 13, 2018 11:34 pm
by xfapv
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.

Re: CRSF protocol for TBS Crossfire?

Posted: Sat Apr 14, 2018 10:02 am
by Hertz
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.

Re: CRSF protocol for TBS Crossfire?

Posted: Sat Apr 14, 2018 10:52 am
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Wed May 16, 2018 6:53 pm
by LoafFPV
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?

Re: CRSF protocol for TBS Crossfire?

Posted: Wed May 16, 2018 10:11 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Jul 15, 2018 11:55 am
by prohfesor
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?

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Jul 15, 2018 12:32 pm
by MikeB
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

Re: CRSF protocol for TBS Crossfire?

Posted: Sun Jul 15, 2018 9:12 pm
by MikeB
222b4 now posted.

Mike