TARANIX X9D: New hardware platform for Deviation?

I've seen some receivers (SLT, for example) to transmit strange sequence just after the start, which is not expected by anyone else - other receivers or transmitters. It is just like signature in the air.

What's a pity that the transfert speed can't be defined during the binding process. For example, during binding start first with the lowest speed and then update all parameters of the radio channel given by the TX.

Actually, in your V2x2 port, if I understand, you fixed the speed ? which one is it ? (250kbits,1Mbits or 2Mits?)

It's not that I did it - it is defined by the protocol. For V2x2 it is 1Mbps.

Victch,

Can you post a photo and give me reference of the material you are using to read SPIout ?. I am curious to see how it's working. Maybe if it's not too expensive, I will be this material to read my other V212 and V262 quads

PhracturedBlue wrote: I have the protocol ported...It just doesn't work My guess is that there is something specific about the Tx modules they use (xtal tuning/something) since my code works fine with un-amplified modules but not with the amplified ones.


Vlad: Now I got FrSky Taranis X9D, just in case.

Hi Vlad,

Perhaps you can have a look inside and see if there are any obvious differences compared to the modules we use in the Devo. As PB suggested, maybe using a non-standard xtal, or anything that is not obvious from analyzing their FrSky firmware source code.

Could have a look at FCC some useful info

And this give some more if you use 'Frsky' for Applicant Name
HERE

It is probably PI (C-L-C) filter/matching network. It is difficult to judge exactly from the photo, but the center antenna track seems to be a 1/4 wave length. It would be interesting to see what is on the other side.

My guess was that some PA chips interpret both RXEN and TXEN on as a forbidden state, so for bidirectional protocol (and as far as I understand, FrSky is such a protocol) we need extra control over the PA/LNA state. That is why the RF board without PA works fine.

The board on your photo is apparently multifunctional, so majority of these pins are probably just GND, or not connected - they are there for physical support.

Has anyone tried to read their code? It should be explicit control of PA/LNA there.

Taking this all back. It seems that this module in "intelligent", that is it has some processing power. If you look at its front, you can see two quartz crystals there, one for CC2500, and another for something on the back side of the board.

vlad_vy, is it easily detachable? Can you look at its back side?

I checked the code - nothing drives RF chips through SPI. They use some other serial protocol to communicate with RF board, meaning there is MCU on the board.

@SeByDocKy sorry for ignoring your question about reverse engineering setup - I have not seen it. The setup varies for the board I deal with. The main step is to find an attachment place for SPI. For some boards it's trivial - the RF chip is broken to easily solderable pads. For some it takes literally hours to solder to. HiSky board (Q-BOT) has two leadless chips on it and 2-3 mm distance between chips. It took me very thin magnetic wire and 2 hours per attempt (I made several) to solder to the chip.

I prefer to solder to receivers (at least first) because they expect stuff on air and can give you info on frequency hopping for various simulated TX ids, while transmitter as a rule has only on TX id and knows only one frequency hopping sequence.

Then I use logic analyzer to listen to the traffic on various conditions - startup, unbound, binding, stick movement etc. Then I stare at it for a long time trying to make sense of packets I see. There are several layers - CRC algorithm, packet structure, frequency hopping algorithm. They all can be trivial or real puzzles.

I use Devo 7 shell with Arduino to try transmitter code first - it is faster to compile/flash/check than for Devo.

I wrote several scripts to decode protocol from SPI level to RF chip commands, extract and analyze frequency hopping patterns etc. They are specific for the protocol.

I put all the code I use on the bitbucket under bitbucket.com/rivig . I doubt it is useful without extensive instructions, but I plan to write up the TacticSLT effort. It takes time though