Protocol for Zero-X swift+ and polaris drones

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

Do you know about this Work?
github.com/pascallanger/DIY-Multiprotoco...Protocols_Details.md

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.