Frsky compatibility

If the module is controlled via PPM the telemetry infos can't go back to the tx. This will work only with a bidirectional communication (like RS232, SPI) and will need a module integrated in the tx.

I did not know that module was for ppm.

Having native support for a fullrange module in the tx with telemetry would be the best alternative. But i can see myself connecting over ppm and getting the telemetry module if i go full fpv.

Spectrum protocols are somewhat questionable when it comes to long range. No clue on how well the devo protocol handles interference though. Lacks much of the telemetry though.

Just got a Taranis which can do quite a bit, but I sure like the feel of my Devo8s better. The gimbals are certainly better. Anyway, thanks for trying! I bought the tx module you're using just in case it works out.

Hi All.
This is My first post on this forum.
Firstly I'd like thank PhracturedBlue for his work on this and other protocols. I'm really in awe of His reverse engineering skills.

I have got the frsky v8 (1way) protocol working, albeit after a bit of analysis and changing some things.
However ... the code will only work for the one Tx Id in the code (0x1257 ?).
It appears that the channel selection varies depending on Tx Id (I think i know how it works though).
But ... (there's always a but) the data packet crc start value changes with the Tx Id aswell !, and i cannot work out the mechanism (yet).
Any ideas ?.

It appears as though the developer of the V8 protocol had some good and some not so good ideas. I'm surprised the sync word does not change between the two Tx Id's i have working.

Anyway, how many pairs of Tx Id's and crc start values would i need to crack this part of the protocol ?

Cheers.

Can you also describe the problem in more details? How long is the CRC?

The usual trick is to watch the receiver - it contains the knowledge about every possible combination of id/CRC or id/frequency hopping sequence, and fake the transmitter in enough details so that the receiver starts producing sensible results. Then you switch TX to the new id, signal receiver to bind and watch its behavior again.

I did this twice, one case was pretty simple - V202 - as the receiver started follow the sequence after just getting a bind packet with new id. So you just set the id, reset the receiver and record its SPI. Another case, Tactic SLT, was not so simple - the receiver waited for the first valid packet on right channel. It required a feedback to TX, but otherwise the schema was similar.

In your case you need to produce stimulus pairs id/CRC until the receiver starts interpreting your input correctly. It depends on the length of CRC then. If it's CRC-32, then it's hopeless. 8 - you're lucky. 16 - something inbetween, you'll need some time to gather the data.

Then the algorithm connecting id to CRC seed needs to be figured, but until you have many data points it is pointless to ponder about it's hardness.

Thanks for the reply PhracturedBlue.
>"You have it working with which transceiver module?"
I'm using the RF board from an early FrSky V8 hack module.
I have another module without PA, but that did not work when transplanted back into the V8 TX module. In the next few days i'm going to get an accurate frequency counter to see what's going on with the Xtal's in these modules.

As my development is not using Deviation but an AVR to interface to the CC2500 module, i made two changes to the one way code.

1. The reset command has a delay of > 50us after being sent. ... On RC groups people have come across problems with the reset but not realised what was happening. If in doubt, read some known data out of the cc2500 before continuing.

2. The seed should be a "u32".

I'm probably going to have a go at automating the process of finding the connection between crc start value and Tx ID for the data packets.
Listening to the spi on the rx side wont work because the crc is generated and checked in software.

So far i think the relationship between Tx ID and the hopping table channels is simply the TX ID modulo division 5. The 50 channels in the hopping table being spaced apart by 5 with the remainder added as an offset. I'm guessing that any selection 50 channels could be used.

That's all for now and when i get some more info i'll be back.

Cheers.

Apologies in advance for may be a stupid question:

I am aware Frsky have introduced a few protocols over the years, most not compatible. The ones we try to support in Deviation is the Frsky1Way and Frsky2Way.

Does the OpenTX Taranis version not support these protocols? If not, does it mean the standard Taranis only supports ACCST and no other FrSKY or 3rd party protocol, except if you add a PPM driven module to its back?

RandMental wrote: Apologies in advance for may be a stupid question:

I am aware Frsky have introduced a few protocols over the years, most not compatible. The ones we try to support in Deviation is the Frsky1Way and Frsky2Way.

Does the OpenTX Taranis version not support these protocols? If not, does it mean the standard Taranis only supports ACCST and no other FrSKY or 3rd party protocol, except if you add a PPM driven module to its back?

I think even the internal module is still fed PPM.

Hi.
For the V8 One way protocol, here are some Tx Id's and the related crc start values for the data packets.

To get more values i need to fully automate the process. So far i have been binding an rx by hand and then waiting for my code to find a match (i wired the green (signal) led on the rx to an input on my emulated tx module !!).

// ID crc start value
// 0x0000 0x0E
// 0x0001 0xD7
// 0x0002 0xBB
// 0x0003 0x62
// 0x1257 0xA6
// 0x1258 0x7D
// 0x1259 0xA4
// 0x1E2D 0x89
// 0x1E2E 0xE5
// 0x1E2F 0x3C
// 0x3210 0x1F
// 0x3FFF 0x45

Does this look like a crc thing.

I might take back what i said earlier about the sync word not changing as i could not get tx id ffff or fffe to work. Obviously i'll have to watch the spi on the rx side to prove this.

Bye for now.

I take it by this post : www.deviationtx.com/forum/7-development/...dule?start=140#18881

the CC2500 modules available apparently don't support the FrSky protocol (I never figured out why, but it seems to be related to frequency deltas, and I think the frsky chips may use a skewed oscillator).

If one would use a Frsky original SPI transceivers module, the Frsky protocol, one or two ways, would work as expected.

Am I correct to assume this ?

Actually they have in one of their older RX the V8FR. It has a daughter board that is the transceiver.

And it looks it has the PA/LNA chip. I found it on rcg while reading this thread about a diy tx: www.rcgroups.com/forums/showthread.php?t=1587188

Post : www.rcgroups.com/forums/showpost.php?p=24544189&postcount=32

Only thing it's a older version of the V8FR , the newer one V8FR-II its a one board only rx.

But I did find a ebay vendor that has some in stock, a little pricey but if it would work, I think I would go for it on my devo 10.

Edit: the board has rf switches, would this broke compatibility with deviation ? Scrap that, it's just a question of wiring the the switches command pins to VCC or GND.

www.rcgroups.com/forums/showpost.php?p=22260634&postcount=28

static.rcgroups.net/forums/attachments/3...503-227-DSC04348.jpg

Yes I was wondering that to, I'll ask the seller.

Anyway this could be nice for those who already have that receiver and if it works of course.

I asked the vendor to confirm, I'll keep you posted.

@Pb
so the chip with pa is not working???
I managed to make the 2-way code work on avr 328 using a cheap 3USD cc2500 chip...binding with vd5m.I used bitbang spi.Still in testing