Open davidrattvik opened 1 year ago
attached below is a protocol dump made via visual studio code. it should simplify the process i hope. i also sniffed the receiver in an attempt to see if there was anything coming from it. nothing was detected from the receiver during its startup, search or pairing.
Thanks, I'll have a look soon and let you know
There are multiple issues:
Right now, I'm just unsure how it all works. I have the impression it is like the Turbo Racing with RF frequencies going all over the place without any specific pattern. But I can't see if the RF frequencies loop since the dumps are not long enough.
Also if you could use logic v1 instead since they've never fixed the export bug in the SPI analyzer of the V2 despite many requests...
More I look at it, more it looks like the Turbo racing protocol that I haven't been able to reverse on a different RF chip... I'm saying that from memory, I'll check my old dumps.
Chip: XN297L Bitrate: 250K Scramble: Yes
Address from dumps: 45 8B 5A 00 Address from over the air: 45 1A 5A 3D (the over the air dump as been done with a 5 bytes address instead of 4 on another TX)
The dumps look to have been done from 2 different TXs. I would need a good over the air dump from the 2 TXs over a long period of time using a bitrate of 250K using a 4 bytes TX address on channels 0x0F=15d, 0x23=35d, 0x4E=78d and any other channels with a good flow of packets starting by 0xF4. This might give some clues to figure out F3 and FC types.
Packets:
F4 | 96 | 96 | 64 | C8 | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type F4 = channels
P1=STR,P2=THR,P3=CH3,P4=CH4: 0x64..0x96..0xC8 100..150..200 ->small amplitude... P5 = 0x00
F3 | 01 | 83 | 0B | E4 | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type F3 = ?? P1 = 0x01 P2,P3,P4 = ?? P5 = 0x00 or 0x14 at least in the small dumps
Address: 55 45 05 08
FC | 4D | 76 | E0 | 8B | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type FC = bind P1,P2,P3 = ?? P4= 0x8B at least in the small dumps P5 = 0x00 at least in the small dumps
At this stage I need an extra long SPI dump from power on, over the air from the TXs you have like indicated previously and an extra dose of luck.
Thanks for the feedback. Tonight i'll try and get all the information that you require. I thought that a couple of data bursts would be enough since we are talking about 2.4 ghz. So to sum it up, you need more data and a slight tuning of my measuring method. I am learning as I do this so I have a bit of homework cut out for me.
Also yes. You are correct pascallanger. As I remember I used different transmitters.
So to sum it up, you need more data and a slight tuning of my measuring method.
Yes, faster sample time on your logic analyzer and let it run for a LONG time
As I remember I used different transmitters.
Please dump all the transmitters you have over the air as indicated previously
i don´t know if i will find the time to do all that you asked of me this weekend but i managed to connect each of my 4 TX´s to the analyzer and make a start and bind. i captured 1 minute of data for each controller at 8 MS/s (whatever MS/s means) whitch for some reason was the highest speed at whitch my analyzer was able to work in logic1. i spent last evening trying to figure out what you meant with the 5 channel to 4 channel change in over the air read. I was not able to figure out exactly what you meant. i tried to change the settings during the debug session but could not see that the feed displaying 5 channels changed. I appreciate the time you take out of your day to support the community and i am sorry that i could not deliver all that you asked for.
i have attached the new dumps made with LOGIC 1 this time.
I will check if 8 million samples per second are enough but the dumps look ok.
They give us some clues:
TX1 address: 45 45 5A 18 TX2 address: 45 8B 5A 00 TX3 address: 45 1A 5A 3D TX4 address: 45 9F 5A 03
Packets FC = bind sent on the bind address 55 45 05 08 :
FC | 4D | 76 | E0 | 8B | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type FC = bind P1,P2,P3 = values change every packets but they are the same on the 4 TXs: same bytes sequence and no loop over 120 packets. P4= TX_ADDR[1] P5 = TX_ADDR[3]
Packets F3 ?sync?
F3 | 01 | 83 | 0B | E4 | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type F3 = ?sync RF frequency? P1 = 0x01 P2,P3,P4 = values change every packets but they are the same on the 4 TXs: same bytes sequence and no loop over 120 P5 = flip between 0x00 and 0x14 every other packet
Packets F4 are common to all 4 TXs:
F4 | 96 | 96 | 64 | C8 | 00 |
---|---|---|---|---|---|
Type | P1 | P2 | P3 | P4 | P5 |
Type F4 = channels
P1=STR,P2=THR,P3=CH3,P4=CH4: 0x64..0x96..0xC8 100..150..200 ->small amplitude... P5 = 0x00
======================== F4 are sent on the same RF channels with no loop on the 4 TXs F3 are sent on two RF channels which are different on the 4 TXs. The 2 RF channels alternate every packet. FC are sent on one RF channel 0x4E=78 on the bind address 55 45 05 08
Great! Do you still want me to perform the airdumps as well? If you could guide me towards a site where i can learn to change the 5byte to 4 byte. The problem i am refering to:
"The dumps look to have been done from 2 different TXs. I would need a good over the air dump from the 2 TXs over a long period of time using a bitrate of 250K using a 4 bytes TX address on channels 0x0F=15d, 0x23=35d, 0x4E=78d and any other channels with a good flow of packets starting by 0xF4. This might give some clues to figure out F3 and FC types."
Or did i just circumvent that with the logic analyzer?
I think I have enough with the logic analyzer dumps you provided. If you could do one extra on any of the 4 TXs but really long, the longest the software allows you to do from startup.
Ok. I'll give it a go later tonight. I assume that it just needs to stand idle during the sampling. Also something that might be interresting is that button 3 is toggle and Button 4 returns automatically. I assume though that the receivers channels 3 and 4 dont care about that and will modulate a ppm signal either way.
Yes just let it still during the capture. Ch3 and ch4 are normal channels from a protocol perspective. You have to understand that there is a chance that we won't be able to reverse this protocol...
the program limits me to a maximum of approximately 500 seconds. The analyzer is limited to this at 2MS/s. The program also limits me from lowering the sampling rate lower than 2MS/s. so the largest capture will be 500 seconds at 2MS/s. Yes i understand that it might not be possible to create a protocol from this. At least we, the community might learn something from this.
if i manage to increase the sample time i will post another zip-file.
i managed to sample 1800 seconds. the file is too large to upload to this chat.
RF covers all the frequencies from 0x05 to 0x4E at the exception of 0x10, 0x20, 0x30, 0x40, 0x4D 0x4E is only used for FC, so we could assume that all other RFs are between 0x05 to 0x4C at the exception of 0x10, 0x20, 0x30, 0x40. It could be a final calculation like RF=(value % 0x48) + 5 . Types F3 and F4 can use the same RF channels. F4 are being replaced by F3 and FC. By this I mean that the system switch to the next F4 frequency even if it has not been sent since a F3 or FC has been sent instead.
F4 frequencies follows a pattern ABCD EFGH ABCD EFGH ABC ???? IJKL MNOP IJKL MNOP IJK ???? ...
I confirm that this is nearly the same as the Turbo racing protocol (types F3,F4,FC) which is using a different RF chip but the payload looks the same. For sure the same manufacturer.
F3 RF frequencies are calculated based on TX_ADDR[1] TX_ADDR[3]: RF0=( ( ( TX_ADDR[1] + TX_ADDR[3] ) & 7F ) % 48 ) + 5 RF1=RF0 + 13 if RF0==10 or 20 or 30 or 40 then RF0-- if RF1==10 or 20 or 30 or 40 then RF1-- //guess
The calculation of RF0 can't be 100% sure with the data we have, it could be one of these 3 solutions:
I'm not sure if 1 and 2 are equivalent or not...
TX1: 45 45 5A 18 , F3:1A,2D -> RF0=1A , RF1=RF0+13=2D TX2: 45 8B 5A 00 , F3:0F,23 -> RF0=10 , RF1=RF0+13=23 => RF0=10 is not allowed RF0=RF0-1=0F TX3: 45 1A 5A 3D , F3:14,27 -> RF0=14 , RF1=RF0+13=27 TX4: 45 9F 5A 03, F3:27,3A -> RF0=27 , RF1=RF0+13=3A
At this stage:
That's still a lot of unknowns...
@davidrattvik Can you see if you can connect your logic analyzer on the RX? If you can that would allow us to send stuff to it and see how it will react.
Absolutely! I will give it a try after work. I guess that we will send known data via the multi protocol module and analyse what the receiver spits out.
Yep 👍
Done. i will await further instructions.
@davidrattvik Can you launch a dump of this receiver from power on, bind with an "unknown" TX (not the one it was bound to), let it run for a couple of seconds and finally turn off the TX?
I've purchased a 5€ receiver on ebay but it might take a month or two to get here... So I rely on you for the dumps for the time being. Do you know how to compile the multi code and upload it to your module?
sorry for the delay. Life got in the way. that is kind of you to purchase a receiver. i will send you a donation for it. you are already investing enough in this as it already is. i will try to get the dumps done tonight. i got halted yesterday because of the max upload size to github. unless i can get the files to a maximum 25mb size, i will need some other way to upload them. I have done alot of coding in arduino IDE so i believe i will be able to upload some custom firmware. from what i have seen, the module is based on the Arduino nano so it shouldn´t be a problem. i´ll get back to you soon.
The files you uploaded so far are good. I don't think we need larger dumps. Take your time, we are not in a hurry. Old modules are based on an Atmega328 (pro mini) but the modules are now using a STM32 for some time. There is a big chance that you have the STM32 version, correct? Thanks to @benlye , we have our own dedicated Multi boards for the Arduino IDE. Follow these instructions to compile: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/docs/Compiling_STM32.md#option-3---compiling-and-updating-firmware
here are 4 more dumps. the amount of data that is saved in the idle unbound mode is very high. therefore i cannot sample more than a minute or so until the filesize gets too big.
2 MHz, 3 B Samples rx start, bindmode.zip
2 MHz, 3 B Samples. bind mode, tx start, bind.zip
2 MHz, 3 B Samples rx start. searching for bound tx.zip
2 MHz, 3 B Samples rx start, search, bindmode, tx start,.zip
@davidrattvik Can you launch a dump of this receiver from power on, bind with an "unknown" TX (not the one it was bound to), let it run for a couple of seconds and finally turn off the TX?
I missread this. I'll make another dump with binding to unknown and turning of tx.
here is the one you requested. start, bind and tx turn off.
You have a STM32 module has you can see on the big chip. You've never updated it as I understand, is it correct? If that's the case use flash-multi to install the drivers, install the latest bootloader and write an existing firmware first: https://github.com/benlye/flash-multi Then if you could try to compile the latest version of the code in arduino. Here is my Arduino's config with the same module you have: Debug will only be used if we want to get data out from the module. From there, I can start to code the "GA-4H" protocol and you'll be able to play with it and dump the RX to see how it behaves.
Just looked at the RX dumps. The Data (=MOSI&MISO) pin is not connected to the logic analyzer... Basically you should see 3 signals on the dumps and there are only 2 right now. Here is the pin causing issue: Could you check that your connections and soldering are correct? Or may be the Data pin is not routed on the other side as I thought... The Clock and Enable signals are fine. I can see that there are some packets received but not the content which is on Data...
There is a connection at that pin. I measured it with my multimeter. I'll hockey my oscilloscope to it to see where to connect
i must have had a bad connection. now there is 3 data streams. i.ll try the firmware updates tomorrow evening i think. i believe that i did an update on both the bootloader and firmware since i managed to get the Serial debug function running. we´ll see tomorrow how it goes.
I'm puzzled by the RX dump. When the RX starts, it looks for the F3 packet on the recorded ID which is ok. When it switches to bind, it listens on the FC packet on channel 0x4E using the address 55 45 05 08 which is ok. But it gets strange when it receives a unknown packet change the ID then reads the packet and get the FC which has the ID in it?!?. From there all the packets have an offset with what it is supposed to get on the RF channel it is looking for... For example it switches to the F3 RF channel, it gets a F4, it changes the RF channel to a F4 and gets the F3... Totally weird and totally puzzled... When the RX loses connectivity, it continues to hop 30 times then only look for F3 packets.
Anyway, I think we could do something which is not great but:
If the RX receives the F3, I guess it will start to hop using that sync. Where it goes bad is if it doesn't receive the F3, it will continue hop but we can catch it on the next F3 and resync it. In this case it could lose a maximum of 19 packets -> (19+1)*14ms=280ms. There might be a trick to prevent this loss which is to send 2 x F4s, 1 F4 using the sync packet hopping and another F4 like if it has not received the F3 and we do that back to back. This way we should catch it whatever turns it took and send it back where we want it to be. That's something to try since I don't think we will be able to get to the bottom of the pseudo random generator... I'm even wondering how the RX will react if we send a F3 instead of a F4.
ok so the module is ready to receive a custom protocol. i did the updates to the bootloader and deselected the one i used to "sniff" the transmitter. arduino stops the compilation because of too many protocols otherwise all seems ready to go.
Any luck with this? It would be cool to be able to emulate the turbo racing protocol, their cars are quickly gaining in popularity.
Pascal got pretty far as I can see and I believe that he is taking some well deserved time of until the receiver that he ordered arrives. He is way ahead of me in understanding what is happening, but as far as I can tell, most of the protocol is understood and there are still some channel-switching that needs to be solved. Also pascal: no stress! Take your time and let me know if there is anything we/i can do to help you along.
Something that just struck me regarding these receivers: if you start the transmitter first and then press bind on several receivers, all receivers will bind to the same transmitter equally . So their is no real "pairing" here. Just a receiver listening to the first signal it hears. What if we were to send ch1234 under the first ID. And then transmit ch5678 under another ID. If the transmitter switched between these 2 IDs every other data burst, it would then be possible to use the receivers together to form a 8ch receiver.
@davidrattvik The receiver has been lost and I finally got a refund... Are you still available to test? I can try to code the protocol and see what we will end up with.
Yes I am definitely available. Would you like me to purchase a new receiver for you? In that case i would need your info. If there is anything else that I can help you with, let me know!
Hi and thank you for the work that you guys have done!
I have a bunch of common receivers that i believe would be nice to add to the protocol list. I have captured a data stream from each of the pins on the transmitter chip (XN297L) ( it is connected to the common nRF24L01. The controller does not seem to be smart in any way as you can connect multiple receivers to the same controller. you can also bind a receiver long after you started the controller. i tested this by running a couple receivers at the same time. during this time i connected another receiver and pressed the bind button on the reciever which connected directly and started to copy whart the other receivers where doing. therefore i don´t believe that there is any 2 way communication and that the controller sends its adress out at every data burst. the first adress that the reciever sees will be the one that it takes its commands from. also there is no bind button on the transmitter.
each stream was captured with the controller in a different position. Start no bind Start bind Full left Full right full throttle full break ch3 toggle ch4 toggle. I hope that i have collected enough data for you to be able to make a protocol from this.
captured with logic2
GA-4H.zip