Mikey Strauss

Inclusive Hacking Ride-On Cars to Empower Children with Disabilities

September 29, 2025 reverse-engineeringmobilitydisabilityhackingopen-hardware

GoBabyGo IL Investigates Full-Control Wireless Adaptations for Children with Disabilities

GitHub Repository: https://github.com/houdini91/go-baby-go-remote
Special Thanks: Yitzhak Gershon for their guidance and Ouri Lipner for providing a HackRF.

At GoBabyGo, we believe that mobility is a right — not a luxury. Over the past decade, our 100% volunteer-driven Israeli chapter has worked to bring freedom, joy, and independence to children with disabilities. Through creativity, thoughtful design, and hands-on dedication, we’ve customized over 800 electric ride-on cars, transforming them into adaptive mobility tools for families across Israel.

One of the most approachable ways to adapt ride-on cars is by replacing the stock foot pedal with a large, easy-to-use activation switch. To make that safer and easier for volunteers, I created a Pedal Drop-In Adapter and documented the process in the GoBabyGo Core Kit post (Core Kit + Pedal Drop-In Adapter). See full build details here: https://medium.com/@mikeystrauss/adapting-cars-for-children-with-disabilities-the-gobabygo-core-build-kit-08175c2a7b7c.

Those wired adaptations are practical and reliable, but they require opening the car and modifying wiring — which can be intrusive and tied to a single physical trigger. The question we’re now researching is: What’s possible if we can add a non-intrusive, wireless control that works seamlessly alongside the stock remote?

This approach has the potential to provide a seamless adaptive solution. Unlike the hard-coded pedal trigger, wireless control allows full directional control — forward, backward, left, and right — without modifying the car’s wiring. Additionally, it enables flexible push-button placement, so families can position controls wherever they are most accessible and comfortable for the child.

Systems under investigation

So far, we’re analyzing several commonly used receivers found in retail ride-on cars, especially:

These are often paired with inexpensive 2.4 GHz remotes that use integrated RF chips (frequently the XN297 family or clones).

RF analysis — what we’ve observed so far

Both the RX23 and RX7 systems use a nearly identical packet protocol. Once paired, they behave the same from the car’s perspective — only the bitrate, packet length, and pairing handshake differ.

At a high level, the protocol can be described as:

**Preamble + Sync Word
**Used by the receiver to lock onto the bitstream.
Likely XN297-based framing (e.g., observed sync word 7 10 F5 5).

**Device ID / Address
**Prevents cross-control when multiple cars are nearby.

Opcode (OP Byte)
Encodes directional intent (forward, back, left, right).
Includes redundancy bits and speed tier flags.

**Command (CMD Byte)
**Redundant directional encoding and/or mirrored speed values.
Cross-checks OP byte to reject malformed packets.

CRC
Provides final validation before motion.

URH packet view
Burst catpure

Packet Cadence & Behavior

While a button is held → the remote continuously sends “drive” packets at this fixed rhythm. When the button is released → the system doesn’t go silent. Instead, the RX receives “PARK” packets at the same cadence for a short dwell period.
If cadence is lost (e.g., remote out of range, battery dies) → the RX watchdog halts motion in ~100 ms, ensuring the car stops safely.

This means:

[drive][drive][drive] … (release) → [PARK][PARK] … [stop]

Conclusion & How You Can Help

This project is just the beginning. To turn this research into a complete adaptive car solution for families at home, we’re seeking help in several key areas:

🔗 Connect with GoBabyGo IL:

🔗 Connect with Me:

Originally published on Medium.