Packet Captures from a 88RC drift car - any suggestions on what I should do next

I recently picked a few 1 43 RC drift cars with gyro - similar to Jiabaile which is already implemented in MPM
These are HSTAR D43 and 88RC drift

In order to try and build support for these on my Radiomaster MT12 4-in-1, I tried to perform a packet capture using a ESP8266 + nrf24L01 using the XN297 dump algorithm from the current github repository.

While I would have preferred a direct wired capture but the remote for both seem to have integrated chips with no means to tap into the serial data

I was able to capture the full OTA dump for the 88RC car - which appears to be an implementation similar to Jiabaile
For the hstar d43, I had no luck capturing any packets - which is odd since the remote is working almost certainly on 2.4g

I am attaching the captures here (binding/ steering sweep/ throttle sweep/ gyro sweep) - but would really appreciate if someone could advise on the next steps to create a working prototype ino from this

Also, any guidelines on what to try for the D43 would also be very helpful

Archive.zip

Hi,

You need to use a small 8 ch Saleae analyzer and the Logic software v1.2.14 to capture MOSI, CLK, MISO, CSN and GND.

Capture files for:

power on
power on + bind
throttle mid->low->mid->high-mid
steering mid->low->mid->high-mid
same for any other channels

Regards
M

You need to improve your dumps by using the full xn297dump code since there are too many details missing currently like bitrate, timing, rf channels order... Timing is the mot important of all. The NRF is going to detect packets on ghost rf channels, we need to be able to filter those out.
For the bind, you need to capture the bind packets during the binding process not just before and after.
For the sweeps, you need to set the RF channel where you get the most packets per second and record from there. The sweeps should be slow enough so we can see all the values on the dumps (not the case currently).

@pascallanger

Hi @pascallanger
I have captured a test sweep with scanner locked to Ch45 (which is what the bind packets seem to be riding) and added timestamps.

The command (Fwd/Rev etc) seem to be on a different channel - but before doing a full capture, just wanted to check if this kind of capture would suffice - or if something more is needed

The Car receiver is powered on around the 30 second mark after which it pairs and connects

bind_attempt_from_original_remote_CH45.txt

@M-i-c-h-a-e-l1 Unfortunately neither the Remote nor the car board have any solder pad to obtain serial data - they appear to have an integrated RF+MCU chip so a clean logic analyzer capture is not possible

Timing of ms is not good enough, you need to go down to µs.

Below is my understanding so far from what I've seen with some assumptions.

XN297: 1Mb, Enhanced, Scrambled

Bind

Addr: CC CC CC CC CC
RF Ch: 45
Timing: 11ms

TX
P[12]: D0 01 55 55 03 55 55 00 7C 80 00 2E
P[0] = D0 -> TX ID
P[1] = 01 -> TX ID
P[2] = 55 -> waiting for RX ID
P[3] = 55 -> waiting for RX ID
P[4] = 03 -> bind phase
P[5] = 55 -> bind
P[6] = 55 -> bind
P[7] = 00 -> constant?
P[8] = 7C -> ???
P[9] = 80 -> ???
P[10] = 00 -> constant?
P[11] = 2E -> payload check XOR(P[00..10])

P[8] and P[9] are taking different values between the dumps 7C 80, 7C 81, 7D 81, 7E 80, 7F 81, 7F 7F, 80 7F. But on all dumps, the normal RF frequencies are always 0E/33 so they seem unrelated.

RX
P[12]: D0 01 6C 12 0F 55 55 55 55 55 55 A0
P[0] = D0 -> TX ID
P[1] = 01 -> TX ID
P[2] = 6C -> RX ID
P[3] = 12 -> RX ID
P[4] = 0F -> bind phase = RX bound
P[5] = 55 -> bind
P[6] = 55 -> bind
P[7] = 55 -> bind
P[8] = 55 -> bind
P[9] = 55 -> bind
P[10] = 55 -> bind
P[11] = A0 -> payload check XOR(P[00..10])

TX
???Is this packet sent on 45 or 14/51? I have the impression that it is sent on 14/51...???
P[12]: D0 01 6C 12 0F 20 20 33 33 00 00 A0
P[0] = D0 -> TX ID
P[1] = 01 -> TX ID
P[2] = 6C -> RX ID
P[3] = 12 -> RX ID
P[4] = 0F -> bind phase
P[5] = 20 -> Throttle 00..20..3F
P[6] = 20 -> Steering 00..20..3F
P[7] = 33 -> St trim 00..20..3F
P[8] = 33/0E -> current RF freq -> why current and not next?
P[9] = 00 -> Gyro 00..1F
P[10] = 00 -> constant?
P[11] = A0 -> payload check XOR(P[00..10])

Normal

Addr: CC CC CC CC CC
RF Ch: 0E=14,33=51 -> how are these frequencies calculated???
Timing: It looks like the packets are sent three times on each RF channel. The timing between each packet is 1550µs and 1950µs when going from one RF channel to the next. It switches from one RF channel to the next every 8150µs (around).

TX
P[12]: D0 01 6C 12 0F 20 20 33 33 00 00 A0
P[0] = D0 -> TX ID
P[1] = 01 -> TX ID
P[2] = 6C -> RX ID
P[3] = 12 -> RX ID
P[4] = 0F -> bind phase
P[5] = 20 -> Throttle 00..20..3F
P[6] = 20 -> Steering 00..20..3F
P[7] = 33 -> St trim 00..20..3F
P[8] = 33/0E -> current RF freq -> why current and not next?
P[9] = 00 -> Gyro 00..1F
P[10] = 00 -> constant?
P[11] = A0 -> payload check XOR(P[00..10])

I have #1177, how can I help?
If DLA is not possible due to lack of connection points, could I use my very old NRF board for OTA sniff? If yes I could use some pointers ..
ty

@pascallanger

@pascallanger I tried using the XN297 sniffer code from the repository ported to a ESP8266/nrf24 rather than trying to reinvent the wheel

It does show that the bitrate is 1M but I was not able to decipher the answer to your other questions
I am attaching the capture - the sequence followed, after the sketch moves to the "Identifying sticks..." stage was:

Steering sweep - full left to full right for a few cycles
Throttle sweep - Full fwd to full reverse for a few cycles
Steering trim knowb sweep
EPS/Gyro knob sweep

I am hoping this capture did get what needs to be found - but more than happy to provide any specific captures you may want

@mozgy : I tried OTA sniff for the D43 with the same setup but couldnt get anything - its unusual in that most such devices/ toys build on the same base design and thus this unit too should have been using at least the same radio hardware - but its possible it may be using a different protocol altogether

repository_sniffer.txt

I've updated my description of the protocol above. There are less "???" now but still the timing of normal packets is a question mark to implement this protocol.
Can you redo a couple of times the same dump as what you've already done in auto mode? I'm not interested by the "Identifying Sticks and features." section anymore just the timing part. Can you also turn off the car during these dumps? I think the TX will happily continue to send packets. That will be one less source of noise.
Can you try this: bind the TX and car, make sure you have control, turn off the car, wait for a bit, turn on the car, are you able to control it?

I have #1177, how can I help? If DLA is not possible due to lack of connection points, could I use my very old NRF board for OTA sniff? If yes I could use some pointers .. ty

You can try to use your NRF board and listen for XN297 packets (since they have a signature). The XN297Dump code is available on this repo.
But the easiest would be to connect the serial port of the multi module to a Serial to USB converter (3.3V) and check the result on a terminal on your computer. If you have access to an external multi module then the Serial to USB is built in.

I was able to capture the full OTA dump for the 88RC car - which appears to be an implementation similar to Jiabaile For the hstar d43, I had no luck capturing any packets - which is odd since the remote is working almost certainly on 2.4g

They are not all using the same RF chip. XN297 is quite popular but there are others... Have you opened the TX to see the markings?

@pascallanger

remote_only_captures2.zip

@pascallanger

Can you redo a couple of times the same dump as what you've already done in auto mode?

Attached multiple captures. Each one is taken with only the Remote transmitting and the car switched off. The last 2 (7 and 8) are without a power cycle on the remote

Can you try this: bind the TX and car, make sure you have control, turn off the car, wait for a bit, turn on the car, are you able to control it?

It remains paired and controllable after restart. (Binding done -> Car turned off / remote stays on -> Car turned back on after 4-5 seconds -> Car rebinds to TX within 2-3 seconds) - I am assuming this means there is no ACK involved in the binding process?

From your earlier post:

The timing is quite erratic on the dumps, not sure if this is real or because of the ESP doing some multitasking behind the scene ???

It is unlikely to be the ESP as the sketch is minimal (attached it along as well)
For what its worth, once the car is paired , the steering servo exhibits constant jitter. This jitter remains even if I disconnect the Steering pot from the TX board.

Having said that, I am also attaching a file capture of the existing Jiabaile Gyro protocol being transmitted from a Radiomaster MT12 radio if this helps compare against an existing baseline
The remote is already bound to a car and the car is off during the capture

Regarding the HSTAR D43

Have you opened the TX to see the markings?

Single chip + crystal setup. chip marking says 2522-217B. Google doesnt seem to have anything relevant regarding this chip label

jiabaile.zip

remote_only_captures2.zip

(HSTAR D43 TX board)

Will look into the dumps tomorrow.

If the car stays bound after a power cycle, it means that it saves the TX ID and can reconnect to it without the need of a bind.

It also means that we can get the control to work and then try to see if we can bind it to another TX ID. But with only one example I think we won't know if the bind process works and how the RF frequencies are calculated, hopefully they are based on the TX ID and not on the RX ID... There is still a lot of guess work and without access to the hardware, it's going to be complicated...

For the other car, have you tried a dump with my xn297dump in auto mode ?

For the other car, have you tried a dump with my xn297dump in auto mode ?

Tried a few times but couldn't get anything.
If it isnt XN297, happy to try out any other protocols with additional hardware.

Apologies, 2.4 RF comms is an area I am not at all familiar with so kind of learning along the way

Ok the dumps you've made were not what I was expecting... So the dumps are showing that the TX is trying to bind the RX. Did you bind the RX first and control it before turning the RX off and recording?
But it also shows that:

bind might happen on multiple channels (45/49)? The timing is still going crazy...
P[8] and P[9] from the initial bind packets take different values between the dumps 7C 80, 7C 81, 7D 81, 7E 80, 7F 81. I assume you've rebooted the TX between each dumps, correct? It brings me to another question since the purpose of these 2 values is currently unknown, could it be that they are linked to the RF frequencies to be used in normal mode and that they change between reboots too? Can you do more dumps of the binding sequence with the car to see if the frequencies used are different? This is how DSM2 works, at each startup they find 2 free channels and then use them to communicate.

Can you also try to put some distance between the TX/RX and the NRF24L01 to see if we can reduce the ghost channels?

Let me perform multiple captures later today.
I will:
A) keep the sniffer about 5 meters away
B) Take 5 captures of Remote in fully unbound state (i.e. power cycle remote with car off and immediately start capture)
C) Take 5 captures of remote in bound state (i.e. power cycle both remote and car - and then start capture as soon as they bind)

But you haven't answered the question: was the car bound, working and then powered off before taking the dumps?

Ok, I've updated my previous message with my notes.
I should be able to implement the protocol for your TX/RX ID set. But there will be more research to be done to open it for other IDs. For example I have no idea if the RX ID is part of the calculation of the RF frequencies or only the TX ID is used and how it is used...

Managed to get required setup (old 9xRPro with DIY STM) and even got some output -

Protocol selected: 63, sub proto 0, rxnum 13, option 0
XN297 dump, address length=5, bitrate=250K
Proto=XN297DP, nbr_sub=7, Sub=250Kbps, Opt=8, FS=0, CHMap=0, rfSw=2
Channel=0,0x00
Protocol selected: 63, sub proto 1, rxnum 13, option 0
XN297 dump, address length=5, bitrate=1M
Proto=XN297DP, nbr_sub=7, Sub=1Mbps , Opt=8, FS=0, CHMap=0, rfSw=2
Channel=0,0x00
Protocol selected: 63, sub proto 2, rxnum 13, option 0
XN297 dump, address length=5, bitrate=2M
Proto=XN297DP, nbr_sub=7, Sub=2Mbps , Opt=8, FS=0, CHMap=0, rfSw=2
Channel=0,0x00

TX board is exactly the same as pictured here before but I cannot get anything else displayed,
what am I still missing here?

ty

Regarding Star D43-01Q

I have a similar car, bought on Amazon. I am attaching the pictures of sender and receiver, both feature 32Mhz crystals. The number on the sender IC could be a production date / version. The screen-printing says 0.2 on TX and V103 on RX. I could not get any capture so far.
Best regards

Some data on the HSTAR D43 (TX chip 2523-217B, 32 MHz xtal), :

PHY: 1 Mbps 2-GFSK, deviation ~259 kHz, BT ~0.39, MSB first. On air: AA 55 CF CF CF CF CF F8 6F 70 <ID 6 bytes> ...
Frame = 46 bytes over the air (317 data bits after the sync), last 53 bits are a check/FEC field (not a standard CRC-16/24).
Channels: unbound TX idles on 2440 MHz; linked TX alternates 2415 / 2453 MHz, one frame every 7.68/7.68/4.60 ms;
the car answers ~0.5 ms later on TX+0.75 MHz. The 2453 frame = 2415 frame XOR a fixed mask on the last 9 bytes.
Status: an MG24 emulating the TX drives the car (steering/throttle, generated frames, cold car links without the original TX).

4-in-1: XN297Dump cannot see it (not XN297, frame too long for nRF24's 32-byte payload).
CC2500/A7105 are too slow (500 kbps max). The nRF24 cannot send the 40-byte payload.
CYRF6936 is the only candidate (1 Mbps GFSK, arbitrary length); its fixed deviation (~270-323 kHz)
is close to D43's, but it has not been verified against the car yet.

Car's chip is probably XL2417D in SSOP24, and TX could have WS8000 ish chip

Some substantial progress on the HSTAR D43 since my previous post.

The PHY/protocol is now understood well enough that an EFR32MG24 can emulate the original transmitter and drive the car, including starting from a cold car without the original TX.

All final PHY/protocol measurements below are based on EFR32MG24 captures. The earlier 4-in-1/nRF24 experiments were useful during exploration, but I have not yet revalidated that path against the final complete 317-bit frame format.

PHY

1 Mbps 2-GFSK, MSB first
Original TX deviation about +/-259 kHz
Gaussian BT about 0.39
Car reply deviation about +/-254 kHz, BT about 0.47
Linked TX alternates 2415 and 2453 MHz
Frame-start cadence repeats approximately 7.68 / 7.68 / 4.60 ms
Car replies about 0.52 ms after TX frame start, on TX frequency +0.75 MHz
Unlinked/idle TX uses 2440 MHz

The stock XN297Dump does not see this protocol. It is not XN297, and the framing is substantially different from what XN297Dump expects.

Frame format

After the preamble/sync portion, the useful frame is:

P0..P39 = 40 bytes

317 bits are meaningful; the final 3 bits of P39 are outside the coded frame.

A TX frame starts:

CF F8 6F 70 <6-byte TX ID> 44 ...

Current layout:

P0..P3 = CF F8 6F 70
P4..P9 = 48-bit transmitter ID
P10 = 44
P11..P32 = controls / command data
P33..P39 = 53 transmitted check/FEC bits

The final 53 bits are not a normal CRC.

They are an affine GF(2) function of the preceding bits:

Y = M*X XOR C

where X is the first 264 frame bits and Y is the 53-bit redundancy field.

This has been verified over a large control corpus with exact held-out prediction.

There is also real error correction in the car.

For example:

flipping one TX-ID bit can still bind, and the car replies with the corrected original ID
several suitably spread errors can still be corrected
sufficiently large or bursty errors are rejected

So the final field appears to be part of a small linear error-correcting code, not merely a checksum.

The two linked RF-channel packets are also simply related.

For every tested state and multiple transmitters:

2453 frame = 2415 frame XOR a fixed mask

The over-air mask affecting P31..P39 is:

03 20 B7 60 B5 6F 46 0B B0

Protocol generation is already working

I can generate control frames which were never transmitted by the original TX.

For example, starting from independently captured steering and throttle states, I can XOR-compose a new steering+throttle command, regenerate the 53 redundancy bits, derive the 2453 packet using the fixed mask, and the car executes the generated command.

So this is no longer just packet replay.

The remaining interesting problem is the TX-ID -> FEC/check relationship.

I currently have three physical D43 transmitters:

TX1 = BA F9 EB D0 96 DA
TX2 = 32 F2 2B D4 92 9A
TX3 = A1 DB 0A 84 92 9A

The code remains affine across transmitter IDs as well.

Using the three genuine TX codewords I generated:

NEW = TX1 XOR TX2 XOR TX3

with the control portion normalized and the check field adjusted using the already-known affine control transform.

This creates a transmitter ID which has never existed in any of the physical remotes:

29 D0 CA 80 96 DA

A cold car accepted this generated transmitter immediately and its reply echoed the new ID.

Therefore the transmitter ID is genuinely part of the same affine code.

Why additional physical transmitters could help

The TX ID is 48 bits.

With three physical transmitters I currently have only two independent ID-difference directions.

That is enough to prove that the code is affine across IDs, but not enough by itself to recover the complete mapping:

48-bit TX ID -> 53 redundancy bits

for arbitrary IDs.

Every additional physical D43 transmitter provides another genuine:

48-bit TX ID + corresponding 53-bit redundancy field

and therefore potentially another independent direction of the code.

In the worst case, a completely arbitrary affine mapping across all 48 ID bits would require many independent transmitter examples.

In practice, fewer examples may be enough if they reveal the structure of the underlying FEC/parity generator.

So captures from DIFFERENT physical D43 transmitters could now be particularly valuable.

Possible help from 4-in-1 owners

There may also be a useful capture path for people who only have a RadioMaster/DIY multiprotocol 4-in-1 module.

Earlier in this investigation I used a modified nRF24/4-in-1 promiscuous/raw receiver and was able to recover D43 packet data.

However, my final packet reconstruction, PHY measurements, FEC work, and emulator validation were done using EFR32MG24 hardware.

I therefore do NOT yet want to claim that an ordinary 4-in-1 plus custom firmware can reliably recover the complete 317-bit D43 frame.

In particular, for the current TX-ID problem I need the final 53 redundancy bits to be captured correctly. Recovering only the beginning of the packet or the transmitter ID would not be sufficient.

The next step is to compare the old 4-in-1 raw-sniffer path directly against the known EFR32MG24 capture and verify that it reproduces the complete 317 meaningful bits, bit for bit.

If that works, then a useful community capture procedure may be possible:

Load a small D43-specific raw-sniffer build on a 4-in-1.
Listen on 2415 MHz at 1 Mbps.
Power/link a physical D43 transmitter.
Record a few seconds of packets.
Send the untouched capture.

For the ID/FEC problem, no long control sweeps would be necessary. A few stable packets from each distinct physical transmitter should be enough to provide another TX-ID/codeword example.

So if anyone owns another HSTAR/Star D43 transmitter and would be willing to try such a capture, please let me know.

I first need to verify that the 4-in-1 raw path reproduces the complete frame correctly. If it does, I can package the firmware/tooling so the capture should be fairly simple.

Software/protocol help is also welcome

If anyone recognizes this 317-bit systematic-looking linear/FEC structure, that may be even more useful than additional captures.

Known facts:

264 input/systematic bits
53 transmitted redundancy bits
redundancy is affine over GF(2)
control changes predict all 53 bits exactly
the car corrects some bit errors, including errors inside the 48-bit TX ID
correction tolerance depends strongly on error positions/burst pattern
a simple packet CRC does not fit
a simple single cyclic-code interpretation has not fit so far

I am also interested in identifying the actual FEC implementation or chipset family if this pattern is familiar.

4-in-1 transmission

For an eventual MULTI implementation, CYRF6936 still looks like the most interesting radio in the standard 4-in-1 for TX.

The final measured D43 PHY is approximately:

1 Mbps GFSK
deviation about +/-259 kHz
BT about 0.39

CYRF6936 can produce 1 Mbps GFSK and supports streaming beyond the normal short-packet limits.

My old CYRF replay test was done before the PHY, timing and per-channel frame relationship were understood correctly, so I do not consider that old failure conclusive.

A new CYRF test using the now-known PHY/cadence/frame data is still on the list.

At this point the main protocol blocker is no longer RF discovery.

It is recovering the remaining TX-ID -> 53-bit FEC mapping well enough to generate arbitrary valid transmitter IDs cleanly.

Additional independent physical transmitters, recognition of the FEC structure, or potentially a validated 4-in-1 raw capture path could all help with that.

I have D24 but the very same TX board and can help
got SDR running just yesterday and have DIY 4in1 STM32 ready.

The protocol is now much further decoded than when I first asked for captures.

What is known now:

1 Mbps 2GFSK

linked TX uses 2415 / 2453 MHz

car replies at TX frequency +0.75 MHz

317 meaningful bits per frame

bits 13..316 are 19 source bytes encoded with a rate-1/2 K=3 convolutional code, generators (7,5), followed by a 4x4 transpose/interleave

source fields for throttle, steering, gyro, trim, buttons and RF channel are identified

byte16 is XOR of bytes 0..15

bytes17-18 are CRC-16/0x1021

bind traffic on 2440 is also being decoded

Most importantly, transmitter IDs are no longer a blocker.

I can now generate completely new IDs, build the corresponding valid encoded frames/check fields, and those never-seen IDs successfully bind a cold real car. Several independently generated IDs have already been tested on air.

So another physical transmitter is no longer particularly useful. Earlier, additional TXes were valuable because each one provided another independent ID/codeword example. Now that the actual coding structure is understood and arbitrary valid IDs can be synthesized, another natural ID does not add much information.

Thanks for offering the D24 TX. If we later need a cross-model comparison for bind/configuration behavior, it may still be useful, but we no longer need another transmitter simply to expand the ID set.

_There is still one important unresolved coding detail:

AIR = W XOR encoded(DATA)

where W is a fixed 304-bit mask/coset.

Because W cancels when packets are XORed, the source-byte structure and encoder could be recovered from packet differences, but the manufacturer's absolute DATA values and the exact origin of W are still unknown.

Searches for a simple whitening generator have so far been negative: no short LFSR/PN sequence or short periodic mask found.

This does NOT currently block packet generation. Using a known real frame as the reference, valid new packets can be generated from source-data deltas without knowing the vendor's absolute W._

@pascallanger

on the questions for 88RC @pascallanger

TX
???Is this packet sent on 45 or 14/51? I have the impression that it is sent on 14/51...???

in both “car on” captures the sniffer, parked on ch 51, sees it interleaved with TX packets (B-1 and B-2 “sticks” section). It never appears on ch 45 in any dump. It also keeps being sent long after bind, so it is not a one-off bind acknowledgement — it’s a continuous heartbeat/ack from the car, roughly 0.6 ms after a TX packet, one or two per three-packet group.

P[8] = 33/0E -> current RF freq -> why current and not next?

Addr: CC CC CC CC CC
RF Ch: 0E=14,33=51 -> how are these frequencies calculated???
Timing: It looks like the packets are sent three times on each RF channel. The timing between each packet is 1550µs and 1950µs when going from one RF channel to the next. It switches from one RF channel to the next every 8150µs (around).

perhaps hard code 14/51 for the initial test to see if it works ?

P[8] = 33/0E -> current RF freq -> why current and not next?
Perhaps for resync after a drop?
every ch 14 packet carries 0E, every ch 51 packet carries 33.

D43 update since my previous posts:

I can synthesize all 317 transmitted bits from source/control data using a captured reference. This is packet generation, not frame replay.
Steering and throttle source fields, neutral, and a reversible codec for observed valid control states are understood.
2415 generation is verified against captures; 2453 composition is supported by paired captures and real-car replies.
The real car accepts synthesized packets on both channels and replies roughly 0.5 ms after TX.
I reproduced the 7.68 / 7.68 / 4.60 ms TX cadence.
I also tested generated IDs: they bind a cold car and produce the predicted ID replies.

@ftp19601960

Got my HStar D43 working from the internal 4-in-1 of a Radiomaster MT12, so the CYRF6936 does the job. I used the existing GFSK 1M raw mode (like the HS6200 emulation): preamble plus 45 raw bytes, bit reversed. Frames are bit-identical to my original TX (checked with an EFR32 sniffer) and the car steers, drives, and does lights, speed and gyro.

Thanks @ftp19601960, your notes made this possible. I don’t need W: I take a recorded neutral frame and XOR in the encoded difference of the controls. Source bytes as far as I can tell: 6/7 throttle and 8/9 steering (11 bit, sign + magnitude), 10 gyro, 11 + 14 trim, 13 light/speed button bits, 15 RF channel. My TX links on 2421/2459, not 2415/2453.

Binding turned out simple: the TX sends search frames on 2440, the car answers on +0.75 MHz and follows the TX to the pair. The TX doesn’t even need to hear the answer, a short burst of search frames every second is enough to get a blinking car back.

@pascallanger would you take a PR for a protocol “HStar” with sub protocol “D43”? Which number should it get? I used 125 locally. Right now every module would send my TX’s ID, per-model IDs would be the next step.

@akatecker

@akatecker please post PR, I have HStar D24 with the very same TX board and would like to test it, ty

@mozgy

@mozgy
Pushed it to my fork, branch hstar-d43: https://github.com/akatecker/DIY-Multiprotocol-TX-Module/tree/hstar-d43
It’s protocol 125 for now, I’ll open the PR once Pascal confirms a number. Every module sends my TX’s ID at the moment. Curious whether your D24 works same as D43, I just ordered one myself. Enjoy!

Add HStar protocol (125), sub protocol D43

@mozgy

@mozgy update with a real breakthrough, same branch (force-pushed): https://github.com/akatecker/DIY-Multiprotocol-TX-Module/tree/hstar-d43

Turns out the 5 ID bytes are two parts: 2 bytes TX ID and 3 bytes car ID. The car only drives if its own car ID is in the frames, so the old build could never have steered your car. Now the module learns the car ID on bind, the NRF24L01 of the 4-in-1 listens for the car’s answer.

To bind: select HStar/D43, press Bind, then switch the car on within 10 s. Bind stops by itself once it has the ID, after that the car links on power up. Each receiver number keeps its own car.

If it doesn’t steer after bind, tell me what the car’s light does. So far it’s only tested with my one D43, so it would be great if you, and anyone else reading this, could give it a try with other cars, D24 or D43.

Navigation Menu

Repository navigation

Packet Captures from a 88RC drift car - any suggestions on what I should do next #1194

Below is my understanding so far from what I've seen with some assumptions.

Bind

Normal

1 remaining item

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Packet Captures from a 88RC drift car - any suggestions on what I should do next #1194

Description

Activity

M-i-c-h-a-e-l1 commented on Sep 28, 2026

pascallanger commented on Sep 28, 2026

superczar commented on Sep 28, 2026

pascallanger commented on Sep 28, 2026

Below is my understanding so far from what I've seen with some assumptions.

Bind

Normal

mozgy commented on Sep 28, 2026

superczar commented on Sep 29, 2026

pascallanger commented on Sep 29, 2026

pascallanger commented on Sep 29, 2026

pascallanger commented on Sep 29, 2026

superczar commented on Sep 29, 2026

pascallanger commented on Sep 29, 2026

superczar commented on Sep 30, 2026

pascallanger commented on Sep 30, 2026

superczar commented on Oct 1, 2026

pascallanger commented on Oct 1, 2026

1 remaining item

pascallanger commented on Oct 2, 2026

mozgy commented on Oct 7, 2026

akatecker commented on Oct 11, 2026

ftp19601960 commented on Oct 11, 2026

ftp19601960 commented on Oct 12, 2026

mozgy commented on Oct 12, 2026

ftp19601960 commented on Oct 13, 2026

superczar commented on Oct 13, 2026

ftp19601960 commented on Oct 18, 2026

akatecker commented on Oct 18, 2026

mozgy commented on Oct 18, 2026

akatecker commented on Oct 18, 2026

akatecker commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions