Developer
Since i got my new 2.4ghz spektrum radio (I FALL IN LOVE) i always wonder how the daughter receiver send data to the mother, maybe PPM? mmhh not! With a little help of an oscilloscope i started to reverse engineer the protocol used, well i saw only steady digital signal with lows of 8.6 useconds, that responded to the movements of my radio, so i quickly realize that is some kind of serial communication, and i did the calculations (1000000us/8.6us=116279bps) and i thought that maybe the serial speed was 115200bps. So i attached my FTDI cable and start analyzing the data, and i got this:Spektrum daughter board is sending 16 bytes of information using a serial com. running at 115200bps. As you see in the picture above, the two first bytes are the preamble or sync bytes (0x03, 0x01). The data comes in integers that response precisely in the order is labeled in the picture...So Paparazzi users this is a way to switch 2.4ghz (only in American), the back of my Specktrum radio says: "NOT FOR USE IN EU", uuh!I hope somebody can do something usefully with it, enjoy!
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Jordi must have fallen out of love since there is NO support for Spektrum serial in APM 2.5 instead we have PWM to PPM converter and back to numbers when S.BUS OR Spektrum would be far more reliable than PPM, not kidding, why has that not been addressed ?

    If the code exists for PX4 why isn't it available for APM 2.5 ?

  • Hi ! this is more a question than a comment.

    Some one uses the Spektrum satellite receiver on the APM2 ?

    The channels are not active in Mission Planner.

  • My personal opinion is that the orange DSM RX'es are only good for foamy parkflyers. Most of the rangetest I have compared the range and diversity of the AR500 AR6100 AR6200 AR7010 AR8000 4CH orange 6CH orange and 6CH orange with sat. Range of the orange was allmost as good as the spektrums but they recovered very slowly from signal losses. They all froze for about 10 seconds when experiencing first range issues.... I have reserved the oranges for indoor and shockflyer use only.
  • I have managed to decode a AR8000 satellite receiver (DX8 into Arduino mega 2560). I am thinking to use an inversed version of the same protocol and send serial data into the master receiver and use it as a 8ch servo controller. By binding the master on a diffrent channel and not use that channel....Thanks Jordi for the great idea!
  • Well reports are that the Spektrum satellite rxs bind and function with the orange main rxs, so it follows that it would be the same. These must be kind of new. If I had seen them when I ordered my orange rxs last year, I would have bought some to try.
  • Does anyone know if the "Orange" satellite receiver (http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=...) is a drop-in replacement?  I have one on order.
  • % order in radio, order in which they were tested:
    % thr ail ele rud ger ax1 ax2

    figure
    plot(ch1_tot,'r*-')
    hold
    plot(ch2_tot,'b*-')
    plot(ch3_tot,'k*-')
    plot(ch4_tot,'g*-')
    plot(ch5_tot,'m*-')
    plot(ch6_tot,'y*-')
    plot(ch7_tot,'c*-')
    plot(ch8_tot,'k--')

    legend('Ch1 - Aileron', 'Ch2 - AUX1', 'Ch3 - Elevator', 'Ch4 - Rudder', ...
        'Ch5 - AUX2','Ch6 - Gear', 'Ch7 - Throttle', 'Ch8 - AUX3')
    set(gca,'FontSize',20)
    grid on

     

    3692167703?profile=original

  • The below matlab/octave code should get somebody started who want to use the DX8.

     

    % notes about data stream:
    % - nominally 32 bytes.
    % - sync bytes 00 and ?? (changes every time)
    % sync byte pair appears twice in the stream, after each set of FF pads,
    % which is essentially part of the sync.

    % The FF and 00 pads are constant - always the same length, and in the same
    % place, relatively speaking.

    fname = 'putty8.log';
    fid = fopen(fname);
    data = fread(fid,  'uint8');

    % counter for packets (channel sets) read
    k = 0;
    % place in data file
    c = 8;

    while (c < length(data)-30)
        if (data(c) == 255 && data(c-1) == 255 && data(c-2) == 255 && data(c-3) == 255 && ...
                data(c-4) == 255 && data(c-5) == 255 && data(c-6) == 255 && data(c-7) == 255)
          
            % packet is starting - this is where a bit mask will go on the
            % embedded system
            c = c + 3; % advance 2 posiitons through the sync bytes, and into the first channel
            k = k + 1;
            ch1_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch2_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch3_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch4_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch5_tot(k) = data(c)*256 + data(c+1);
            c = c + 8;
            ch6_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch7_tot(k) = data(c)*256 + data(c+1);
            c = c + 2;
            ch8_tot(k) = data(c)*256 + data(c+1);
           
           
        else
           
            c = c+ 1;
           
        end
       
           
    end

    % order in radio, order in which they were tested:
    % thr ail ele rud ger ax1 ax2

  • OK, got it working on the micro, and learned a little more in the process. There are two messages. Each one has the same 2 sync bytes, which change every boot, and the first one is not always 0 as thought before. When the radio is shut off (i.e. loss of signal), the satellite blasts out one last message. In that message, during my 20-30 or so observations, the second sync byte increases by 2 or 3. It looks like if it was +2, then it means that the final outage occurred such that it is sending a (partially out of date?) message (1 or 2) where it was meant to be sent, (i.e. Mess#1, Mess#2, Mess#1 order is preserved). If it was a +3, then it is (resending?) a (maybe not out of date, or duplicate?) message such that the final two blasts will be Mess#1, Mess#1 -or- Mess#2, Mess#2.

     

    Presumably some of the FF pads will be overwritten with the higher channel radios. Even at 12 channels, there should still be 4 pads. If you have enough overhead on your micro, and you are running the UART on an interrupt like I am, you shouldn't have to worry about that. Just some sanity checks on the message to see if it's good, while knowing it is in  a known order. My current code is sucking in the pads and then discarding them. I don't really want to sit on a UART and spool taking in useless data. I'll probably work on making it more efficient later.

     

    Mess#1:

    02 EE 0B F8 2E AA 13 F0 1C 1B 31 56 FF FF FF FF

    sync1 sync2 ail_msb ail_lsb aux1_msb aux1_lsb elev_msb elev_lsb rudd_msb rudd_lsb aux2_msb aux2_lsb pad pad pad pad

     

    Mess#2

    02 EE A1 56 01 56 3E AA FF FF FF FF FF FF FF FF

    sync1 sync2 gear_msb gear_lsb throt_msb throt_lsb aux3_msb aux3_lsb pad pad pad pad pad pad pad pad

  • Hi guys, in case anyone needs this, here's a sketch I wrote for the Arduino Mega to bind directly with a Spektrum satellite. I didn't do much with the channel data, it just prints the byte values, but there are comments explaining what the different binding modes are.

    This sketch was written to work with the DIY Drones Spektrum adapter board (bidirectional 5 to 3.3V level conversion), basically a modified i2c translator board the following connections:

    Arduino RX1 <-> SDA <-> sat data line

    Arduino TX1 <-> SCL <-> 3.3V reg enable

    I don't know when the Spektrum Adapter board will be available or if this will the official configuration, but it worked in my tests and hopefully this info is useful to someone.

    http://pastie.org/1550659

This reply was deleted.