Advanced Search

Hi there,

Glad to find some hints to make my Devo12s connect to USB.

I have the UP02 walkera USB cable, and the Phoenix RC dongle, none of them show my controller over mac os Monterey

I'm trying to play Aerofly RC9 using my Devo12s with no much joy until now, it doesn't even see the controller on MacOS, USBHID on on the transmitter...

If anyone can help, I would be grateful !
Many thanks !

I just try t8sg v2 plus with ELRS but nothing seems to work.

Just to check I use a fs-i6x and all works fine.

I documented all here: github.com/DeviationTX/deviation/issues/1038

Is it possible that ELRS 3.2 is not supported? Should I downgrade to ELRS 2?

Do latest nightly builds for t8sg works with CRSF?

You're welcome. Thanks for the update!

I finally found what I was doing wrong. I was connecting signal from Devo 7E to PPM pin of ELRS TX module instead of SPort pin which is next to GND.

It works now, so I can also confirm that Devo 7E works with ELRS modules.

Thank you very much Hexfet for your development which keeps our beloved Deviation TXs alive.

Yes, that's correct. None of the limited memory transmitters support CRSF telemetry.

hexfet wrote: You have not done anything wrong. The Devo 7E does not have enough program memory in its processor to hold the CRSF telemetry or parameter code. These features are not available on the 7E.

Fun to hear someone is using CRSF through the trainer port.

Hi Hexfet,
I got same problem on my Devo F7 & Devo 8S , is that mean both TX have not enough memory for CRSF telemetry?
Thanks

Hi All.
Before the days of 2.4GHz, Transmitters used to talk PPM, PCM or serial to the RF modules.

Does anyone know how the error detection mechanism works on this protocol ?. e.g. CRC etc.

If you have an old JR transmitter laying around in your junk pile how about some reverse engineering.

The protocol basics are detailed in the attached .pdf.

Cheers.

Hello, you intend to add the KF606 protocol, it is the protocol on which a number of mini RC planes fly (eg the Z51 Predator, whose receiver can control two coreless motors with automatic assistance - leveling). This very cheap receiver fits many RC Scratchbuilt Indoor and Micro Models
Radiomaster TX16S has this protocol.

Off topic mini rant.

I installed Docker etc and did a partial port of the GD00xx GD_V2 code from MPM - there has been a big change in coding style.

Deviation is an important step to where we are now but I have decided that the T8SG is pretty much dead. As for Docker it is just part of the continuing Tower of Babel tendency - entropy! Fortunately MPM elected to go with the contained chaos of Arduino where you can grab a local clone make some changes and you are done.

I have convinced my friend to go with MPM and probably a Tx16S or similar.

Thanks goebish - yep still "alive and kicking" here. I will grab the latest source and adapt the MPM code I get Docker running with a local copy. I need to add an A120 V2 variant to MT9xxx or whatever as well. One of my mates has an ancient Jumper and would like to try that before just buying something sensible. Like many I am running MPM along with EdgeTx.

Hi gke, long time no see!

I had a quick look at the source code, looks like V2 has never made its way onto Deviation, shouldn't be hard to port from MPM tho.

Very quick question. Did GD00X V1&V2 make it into the T8SGV2Plus builds? Thanks

@hexfet Thank you!

Installed on both of my transmitters, everything works as expected.

billmester wrote: Now 6 years of heavy use are starting to show on gimbal precision... So maybe it is time for a change.

You can actually install new (full) Devo 7 gimbals in your Devo 10.
Plug and Play unscrewing the old ones, putting new gimbals into the chassis and rescrewing all screws.

Had to do it myself when the TX fell out of an aluminium box and crashed onto the hard floor with the top side (sticks) first.

I don't have any problems after recalibration of the sticks.


So my advise: Look for a cheap / never used Devo 7 or find a dealer which may has a corrupted Devo 7 (doesn't turn on, board SMD issues) but can make you a good offer to sell you all the rest (which is still brand new like gimbals).

Thank you! It turns out if I receive data from the transmitter, then the binding has occurred. And the data that I can read is the payload? I have a 2-channel remote control, which means I should get only 2 values, for gas and steering. Values must be between 0 and 255, or can it be any number?

As far as I understand, the data I receive can also contain the channel number, right? Either the microcontroller already has an array of channels that it enumerates. Then either the channel change occurs when the data is acknowledged, or the channel number is transmitted in the data.

In the data that I receive
0x32 0x06 0x24 0x0B 0xDE 0x6A 0x45 0x05

The value 0x0B = 11, the next series of channels increases exactly by that much, that is, it started from 10, 30, 50, 70, the next series 21, 41, 61, 81. But this is not accurate.

Seems like there's some confusion between "layers of abstraction" here. The link settings for PREAMBLE_LEN, SYNCWORD_LEN, TRAILER_LEN, CRC, etc. are part of the initial chip setup. The tx and rx must both initialize their radio chips with compatible values so they can exchange data. If those are correct then data bytes can be transferred between tx and rx. Since you're able to receive data from the tx the initialization seems to be correct.

The code for these protocols generally has three segments. Initialization is first - various LT89xx registers are set to the values chosen for the radio link. Next a binding section of code establishes the data protocol link. Generally this involves the tx sending data on well-known channels and the rx responding with data that confirms it received the bind information. (In some protocols the rx does not respond at all, the bind phase just ends after a certain amount of time).

During the bind phase usually a tx specific identifier is exchanged, so the rx only binds to the given tx. Figuring out the algorithm of how this identifier is created is part of reverse-engineering the protocol.

Once bind is complete the data phase starts. The packets generally contain the bind identifier, the channel data, and a crc of some sort. Figuring out those things is the other part of being able to implement the protocol.

I did various experiments with the XY WB modules that have the LT8920 chip installed, using one board as a receiver and the other as a transmitter. The values of the registers used are the same as the control panel, including the length of the preamble and the sync word. The first byte written to Register 50 (FIFO) indicates the length of the payload, in my case it is 6 bytes. Data is transferred without problems, in both directions.

My transmitter is constantly cycling through channels. And in the last captures, it seemed to me that even the synchro word was changing.

I also can’t figure out the payload, according to the structure of the packet and the data written to the register, I should have this:
PREAMBLE_LEN - 3 bytes
SYNCWORD_LEN - 32 bits
TRAILER_LEN - 4 bits
CRC - 16 bits

The package looks like this:
50 6 36 11 222 106 69 5
0x32 0x06 0x24 0x0B 0xDE 0x6A 0x45 0x05

1 byte 0x32 is register address 50
2 bytes 0x06 is the payload length of 6 bytes
3,4,5 bytes 0x24 0x0B 0xDE is PREAMBLE (3 bytes)
Next, there should be a sync word consisting of 32 bits, and this, in turn, is 4 bytes, which is already not enough.

Register 50 is accessed byte by byte.


Also, after each packet sending cycle, the transmitter changes the channel by adding 20 units to the channel number, for example, it was channel 10, it became 30. And so on until it receives a packet from the receiver. After accepting the package, the channel numbers change, there was channel 10, and it became channel 21, and then there are numbers 41, 61, etc. The channel change consists of 4 cycles, then the channel numbers are repeated (10,30,50,70). I suppose that the package should contain data about changing channels to new cycles, for example, 4 bytes in the 0x0B package means 11, and the channel cycles are shifted by 11, it was 10 became 21. Also in one of the captures, I noticed changes to the register with a sync word, perhaps just a failure, or perhaps the sync word changes after each successfully delivered packet.

I couldn't get past the second batch. The transmitter stops flashing LEDs, indicating that it has bound to the receiver, but the receiver can no longer receive data from the transmitter. I added a channel change to the sketch, but this did not bring any result.

I want to try to tune the second receiver to a new package and a new channel, and play with the sync word, perhaps something will work out.

Don't have much time to dig into this. I've attached a screenshot of the script output loaded into a spreasheet. Makes it easier to look through.

Keep in mind that SPI is bi-directiional. Every byte out also reads a byte in. Since you're monitoring the transmitter MOSI is sending through the LT8900 to the rx, and MISO is data from the RX.

Like many other protocols this one first sends initialization data to the LT8900, then has a bind phase to establish a connection to the receiver, followed by a data phase if the bind is successful. You may want to look at some Deviation protocols to get the general idea. I've attached a screenshot of the script output just to give you an idea of what to look for.

This is at what seems to be the start of the data phase, at 1.933186 seconds into the trace. Usually the bytes in the middle of the packet are the channel data, with a checksum in the last byte. You'll need to reverse-engineer what all these mean if you want to make your own tx or rx.

I executed your script and received the file, but unfortunately I did not understand anything, I only saw that the time frames for transferring data are different.

During initialization, each register is written every 0.287 milliseconds
Next comes the entry in register 52 0.384,38,34 80 80
Next comes the entry in register 50 1.084,39,32 06 24 0B DE 6A 45 05

As far as I understand, 0.700 milliseconds pass between them

Next is the installation of the channel by entering the channel number in register 7 1.527,40,07 01 1E

And then there are empty zeros in B0 with an interval of 0.325 milliseconds and everything repeats over again.

0.271.41.B0 00 00 .02 3B 1C .3,
0.324.42.B0 00 00 .04 04 1C .3,
0.328.43.B0 00 00 .05 0E 1C .3,
0.326.44.B0 00 00 .0D 0D 1C .3
0.326.45.B0 00 00 .05 05 1C .3,
0.326.46.B0 00 00 .0F 0F 9E .3
0.325.47.B0 00 00 .00 01 00 .3,
0.355.48.34 80 80 .00 01 00 .3,

What do I need to do next?

I did not find the following changes in the file, the screenshot shows changes in register 50 between 1.933 ms and 1.934 ms, I did not find this data in the file.

I captured and saved in multiple formats. After approximately 1 sec 890 ms, there is a change in register 50


I saved the session just in case