Spark Switch Pro JETI Telemetry

  • Hi there,


    I have a Spark Switch Pro running firmware 0.5, and the switching aspect of it appears to be working fine. I can successfully connect it to Powerbox terminal using a JETI adaptor and set the telemetry to JETI.


    I am trying to integrate the Spark Switch Pro with some autopilot software running on a Raspberry Pi through the JETI USB adapter. I set my serial driver to 8 data bits, ignore parity (so that I get the nine data bit framing JETI sends but can't see bit 8 for message separators so I just use the message separator and checksum information in bits 0-7) and 1 stop bit.


    I've reached the point where all my unit tests based on the examples on page 7 of the JETI protocol spec here are passing. But none of the messages I'm receiving from the actual hardware are passing the checksum test. From the headers they seem to be a mix of JETI packet types 0, 1 and 2, all 34 bytes long which doesn't seem right (34 is the length of simple text messages but the headers are for ex data and ex text).


    There are three main possibilities I can think of:

    1. My 9600 baud 8/ignore/1 serial parameters don't work and I'm getting garbage which just happens to contain stuff looking like JETI message headers (0x7E, 0xNF, ...)
    2. The JETI protocol document I'm using is out of date (it has a few typos too, e.g. spelling of length in the checksum example code and the first message type/length breakdown on page 7 has 9 bits which was very confusing)
    3. When the Spark Switch detects power on the telemetry line it goes into some sort of programming mode to work with Powerbox Terminal and isn't sending JETI at all

    To help with (1) can you tell me the serial parameters used by Powerbox Terminal so that I can duplicate them? For (2) can you confirm if that protocol document matches the EX Data/EX Text/Simple Text JETI protocol your code uses and tell me what sort of messages I should expect to see coming through? And for (3) let me know what conditions need to be in place for JETI telemetry to be sent.


    Thanks in advance for your help.

    Robin

  • Hello,


    we are using the JetiBox (or EX-Telemetry) protocoll. As you know it is 9600-9800 Baud. 9Bit, Parity, 2 Stop bits. We make it with a software UART as our controllers don´t support this strange settings

    After 10 seconds the SparkSwitch goes into the programming mode.

  • Hi Richard,


    I may have misunderstood about programming mode but I cut the power wire on the USB adapter in case it was triggering programming mode. It does not seem to have affected the output I am receiving from the hardware.


    I reliably receive these three regular sequences of 34 bytes (coincidentally the same length as the JETI simple text protocol):



    Parts of this make sense, for example the EX headers 7eNf and the type and length fields (even though the length is too long it does match the length of what is being sent). The first two sequences contains the text "POWERBOX" and the third "SPARK SWITCH PRO" although all of them with some apparent noise or encoding errors.


    It's confusing to get perfectly correct JETI EX headers but have the rest of the message apparently depart from the protocol (or mixed with the JETI simple text protocol). Of course this could still be a serial decoding issue but a lot of it is right.


    I'm hoping the text embedded in the messages may be a helpful clue for you - my questions are:


    1. What messages does the box emit with this text in it?
    2. Are they JETI messages, or does it indicate that there is another protocol of some kind active (unlikely as there are valid EX headers preceding the text).
    3. If they're JETI messages do they work with other JETI equipment (if they do, maybe the protocol document is wrong)?


    Thanks again,

    Robin

  • Hi Richard,


    Ok, so it's slightly different to the JETI protocol document I've been working from.


    If I want to read Voltage, RPM and Temperature information, where could I find it in the packages I'm receiving? Presumably it's in sequence 2 (the EX Data message) bytes 10-22. As telemetry type 13 is not part of the standard, could you tell me how this information is encoded? Since it's 12 bytes and 3 values I guess it's 4 bytes per value, are they JETI int30s?


    Thanks,

    Robin

  • Hello Robin,


    i assume you want to read telemetry data out of the spark switch Right?


    If yes then I would use the Multiplex MSB protocol inside /outside the spark switch.


    That is much easier to implement then Jeti.


    The MSB protocol discription you will find under the follwing link.


    Sensor Bus V2


    https://www.multiplex-rc.de/se…tellenbeschreibungen.html


    Of Course you must set the spark switch to Multiplex MSB and sent him the commands.


    BR


    Dirk

  • Thanks Dirk I'll take a look at the Multiplex protocol.


    Richard I just said that it's different to the JETI protocol document from the JETI website that I shared with you in the thread above - there is no mention in the document of combining EX and Simple Text for instance. I allowed for the fact that the document may be incorrect, incomplete or out of date, and that's why I asked about JETI radios working with it - if they do, then the document must be wrong.


    I am still curious after all the work I've put into decoding JETI to find out where the voltage, rpm and temperature information is located in the messages. I don't think it's at all unreasonable to ask this - I paid for a Spark Switch Pro for the telemetry feature, and it lists JETI as one of the supported protocols.


    Even if I'm still experiencing serial decoding issues you should be able to tell me what message contains this information. You have access to your device firmware's source code, I don't.


    Thanks,

    Robin

  • Hello,

    yes - I didn´t see what you want to do - of course just to get the data: M-LINK is better and easier!

    The Jeti document is very incomplete - it costs me days to get it work some years ago!


    It´s not unreasonable to ask, but it´s a support for our products not for backengineering - would blow my time frame. Sorry