Add HyperGo protocol (110) for MJX T3A/R30

[sqall123]

XN297 scrambled surface protocol with forced TX ID (Only 1 ID). Validated on H16BM: steering, throttle, LED, trim, and 70% rate. Refs #1124

[pascallanger]

Looking at the code, I think you are missing the bind phase. It probably works on your car since it's already bound. Not sure how the bind is achieved on this set of TX/RX, you might have to look for a small burst of packets at power up by scanning all frequencies (select a rf freq, then power on a few times the TX to see if you get different packets than control, and repeat for each freq).
packet[7] and packet[8] "companions" look to me like unconnected additional channels for future expansion. Usually unconnected channels just follow the values of adjacent connected ones with slight differences. I think it will be better just to assign them extra channels.

[sqall123]

Thanks for the review.

1. Bind is implemented. Stock T3A advertises on CH79 with address 6D 6A 58 52 43 (~29.57 ms). When the R30 powers on there is a short handshake on the same channel, then it switches to data address B4 46 F2 25 D7 and hops 62 → 49 → 75 @ ~9.87 ms. The earlier “[4]=[5]=00 for ~300 ms” was only the start of the control stream, not the bind.

2. Unused payload bytes [7] and [8] are now mapped to CH3 and CH4 (s8b).

PR updated. Currently using a forced “Only 1 ID” from the captured T3A/R30 pair (PCB T3A V01, RF IC 2427CTb). Bind + control re-validated on the vehicle after these changes.

[pascallanger]

Correct me if I'm wrong but from what I see in your description at the bottom, the car sends data back. From what I see

• the TX sends bind packets
• the RX sends its RX ID
• the TX replies with the payload containing the RX ID
• the RX ack but I don't think it's needed to check them for the bind to complete if you send enough packets but I might be wrong, to be tested
• then the TX switches to an address made out of the RX ID and sends control packet

I'm wondering what the 3 first bytes of the payload are for? RF frequencies?
Not sure how the normal address is created. It might be constants inserted in between the RX ID or something calculated.
I don't have access to my computer to do more analysis...

[pascallanger]

I think the bind still doesn't work with your code. Control still works on your car since it is already bound...

[sqall123]

You’re right to correct that — thanks.

What we validated:

• Control works on my already-bound R30 with forced ID B4 46 F2 25 D7 / hop 62-49-75.
• Stock reconnect on CH79 shows the open-loop sequence we replay (beacon 6D… with 00 00 00 → echo B4 F2 D7 → flag 0x50 → short packets → leave CH79). That matches a reconnect of a pair that already shares that ID, not a proven virgin bind.

What we tried for an RX→TX ID frame:

• R30 alone, scan 0..84: no valid packets (RX does not advertise by itself).
• Reconnect capture on Option 79: only the T3A-format packets above; the ~2.7 ms P(4)/P(5) shorts also appear during normal control, so they look TX-side.
• Option -1 during power-on misses the ~60 ms window.
• R30 PCB is R30 V02 LT, single SOIC-16 2444CYa + 16 MHz crystal, conformal coat — no external MCU/SPI to sniff.

So I agree: with the current code, “bind” is an Only-1-ID open-loop replay. It should not be expected to bind a different car. I’ll update Protocols_Details to state that clearly.

Happy to collect dumps from others on #1124 (especially their data address after stock bind) or a virgin-R30 first-bind capture if someone can do that. Until then Only 1 ID is the honest status.