- Posts: 2
Protocol for Zero-X swift+ and polaris drones
- DazzaBiggs
- Topic Author
- Offline
Less
More
01 May 2023 00:29 #78252
by DazzaBiggs
Protocol for Zero-X swift+ and polaris drones was created by DazzaBiggs
Hi all - I am posting this here as this appears to be the Internet's centre of excellence on protocol reverse engineering... so hopefully someone can help (this is my first post ever on a forum of this type)...
I am looking to decode/find the protocol for the Zero-X swift+ and/or polaris basic drones. These drones use the XN297 chip, so it should be reasonably doable...
I have used the iRangeX irx4+ Multi-Protocol Module in packet-sniffing mode to decode the basic structure of the packets.
The structure of the packets that I have found is VERY similar to the DM002 protocol, which is promising. But it is not exactly the same.
The packets all have exactly 11 bytes, including the checksum (DM002 uses 12 bytes per packet - the one that is missing is just the packet counter).
Before binding the first byte is always AA followed by 9 bytes followed by the checksum (checksum seems to be literally just the sum).
After binding the first byte is 55 followed by 4 channels of AETR data followed by a few flags etc followed by the checksum.
That is all good - and I believe that I will have no trouble modifying the DM002 code in the Multiprotocol Module arduino sketch accordingly.
My problem is mimicking/decoding the binding process. I am not clear what is occurring in the binding process. The Tx seems to choose different frequencies every time. The "binding" process in the drone manual is to raise the left stick for one second, then lower it for one second. You can do this without the drone turned on, and the Tx still converts from binding "AA packets" to data "55 packets" by itself, so it doesn't seem to need any response from the drone.
When the drone is first turned on it flashes its lights. When it is synced/bound (by the process of raising and lowering the left stick) the lights become solid. I have not been able to replicate that through my own Tx (using the Multiprotocol Module) yet.
Is there some kind of guide as to what to look for when decoding the binding process? It can't be complex because the Tx will "bind" with no drone present - but then, what is the drone looking for? I am hoping that the brains on this forum can help me
Cheers
I am looking to decode/find the protocol for the Zero-X swift+ and/or polaris basic drones. These drones use the XN297 chip, so it should be reasonably doable...
I have used the iRangeX irx4+ Multi-Protocol Module in packet-sniffing mode to decode the basic structure of the packets.
The structure of the packets that I have found is VERY similar to the DM002 protocol, which is promising. But it is not exactly the same.
The packets all have exactly 11 bytes, including the checksum (DM002 uses 12 bytes per packet - the one that is missing is just the packet counter).
Before binding the first byte is always AA followed by 9 bytes followed by the checksum (checksum seems to be literally just the sum).
After binding the first byte is 55 followed by 4 channels of AETR data followed by a few flags etc followed by the checksum.
That is all good - and I believe that I will have no trouble modifying the DM002 code in the Multiprotocol Module arduino sketch accordingly.
My problem is mimicking/decoding the binding process. I am not clear what is occurring in the binding process. The Tx seems to choose different frequencies every time. The "binding" process in the drone manual is to raise the left stick for one second, then lower it for one second. You can do this without the drone turned on, and the Tx still converts from binding "AA packets" to data "55 packets" by itself, so it doesn't seem to need any response from the drone.
When the drone is first turned on it flashes its lights. When it is synced/bound (by the process of raising and lowering the left stick) the lights become solid. I have not been able to replicate that through my own Tx (using the Multiprotocol Module) yet.
Is there some kind of guide as to what to look for when decoding the binding process? It can't be complex because the Tx will "bind" with no drone present - but then, what is the drone looking for? I am hoping that the brains on this forum can help me
Cheers
Please Log in or Create an account to join the conversation.
- -=Hubi-Dirk=-
- Offline
Less
More
- Posts: 209
02 May 2023 11:30 #78254
by -=Hubi-Dirk=-
Replied by -=Hubi-Dirk=- on topic Protocol for Zero-X swift+ and polaris drones
Do you know about this Work?
github.com/pascallanger/DIY-Multiprotoco...Protocols_Details.md
github.com/pascallanger/DIY-Multiprotoco...Protocols_Details.md
Please Log in or Create an account to join the conversation.
- DazzaBiggs
- Topic Author
- Offline
Less
More
- Posts: 2
08 May 2023 11:55 - 08 May 2023 11:57 #78255
by DazzaBiggs
Replied by DazzaBiggs on topic Protocol for Zero-X swift+ and polaris drones
Just following up here (and thanks to Hubi-Dirk for the response)...
I managed to decode the protocol completely and now have the two drones (Zero-X Swift+ and Zero-X Polaris) flying with the Multiprotocol Module (MPM).
My problem was that I didn't have the Rx Addr set correctly. That information can be obtained through the XN297Dump protocol (which places the Multiprotocol Module in packet sniffing mode and reports a lot of information). In my case the protocol used a five-byte address and all five bytes must be correct.
I can offer some guidance for those who are attempting something similar. Basically, if the drone uses the XN297 chip it should be possible to decode the protocol. In my case the protocol had a packet with 11 bytes. Figuring out what each of those 11 bytes does is reasonably straightforward.
One trap was that if the original transmitter is too close it swamps the MPM, and the signal appears on more channels than it really is. When trying to decode, it's best if the original Transmitter is some distance away (e.g.,in the next room). With that sorted, the Zero-X Swift+ uses four frequencies, and the Zero-X Polaris uses five frequencies (why, I don't know). But once you have the frequencies/channels recorded, it was a fairly straightforward task to modify an existing protocol (in my case DM002) to mimic the original transmitter. Once that is done, the drone flies nicely with my Taranis running OpenTX (in mode 1, compared to the original transmitter which was mode 2, and the reason for the decoding project).
Thanks for reading.
I managed to decode the protocol completely and now have the two drones (Zero-X Swift+ and Zero-X Polaris) flying with the Multiprotocol Module (MPM).
My problem was that I didn't have the Rx Addr set correctly. That information can be obtained through the XN297Dump protocol (which places the Multiprotocol Module in packet sniffing mode and reports a lot of information). In my case the protocol used a five-byte address and all five bytes must be correct.
I can offer some guidance for those who are attempting something similar. Basically, if the drone uses the XN297 chip it should be possible to decode the protocol. In my case the protocol had a packet with 11 bytes. Figuring out what each of those 11 bytes does is reasonably straightforward.
One trap was that if the original transmitter is too close it swamps the MPM, and the signal appears on more channels than it really is. When trying to decode, it's best if the original Transmitter is some distance away (e.g.,in the next room). With that sorted, the Zero-X Swift+ uses four frequencies, and the Zero-X Polaris uses five frequencies (why, I don't know). But once you have the frequencies/channels recorded, it was a fairly straightforward task to modify an existing protocol (in my case DM002) to mimic the original transmitter. Once that is done, the drone flies nicely with my Taranis running OpenTX (in mode 1, compared to the original transmitter which was mode 2, and the reason for the decoding project).
Thanks for reading.
Last edit: 08 May 2023 11:57 by DazzaBiggs.
Please Log in or Create an account to join the conversation.
Time to create page: 0.026 seconds
- Home
- Forum
- Development
- Protocol Development
- Protocol for Zero-X swift+ and polaris drones