i’ll have a manual soon on my website at gbengineering.se
is there one or two CAN bus connectors per receiver?.
1 Like
1 can bus connector per receiver
1 Like
received 17 orders, shipped 16 units so far.
would like to express my gratitude to everyone who believes in this project and has helped it by buying one unit.
All of them were hand assembled and tested by me alone.
Now i’m planning to scale and launch it on crowd supply.
those of you who received the remotes, please first thing to do is update the remote and receiver here: config tool
new major functionalities are coming like the receiver will have a soft AP when not connected to any remote so you can connect with your smartphone and configure it, bond it with other remotes and even update its firmware without having to have phisical access to it (over usb port)
remote also will have its own CLI so you can send commands to it over usb and over wifi. A lot of stuff is coming in so that’s why I dont have a Manual in place for now. But if you guys have any doubts reach me over our discord channel: discord link
11 Likes
Cant wait for mine to arrive 
I guess I am the 1 you haven’t shipped yet Got your email. Hopefully all good now.
EDIT: I would blur that address from the first box… Just in case… It’s internet after all
1 Like
Discord is not good, it’s where information goes to die. It’s like the difference between giving a hungry man a fish versus giving a hungry man a fishing pole.
5 Likes
1 Like
totally unnecessary but maybe a cool party trick
pressing 3 times while on the boot screen launches the game. it’s available on latest firmware already
12 Likes
Okay I’ll buy one right now send the link 
So now your esk8 remote can still be used while riding on the subway? You don’t need to wait until you get off the train anymore
yes the focus is to stay off the phone!
Store - GB Engineering | GB Engineering there you have it sir!
thanks for your order @jack.luis! 
Just wanted to share that I’m working on some really cool safety features. I had a special firmware running on my remote where, every few seconds, it would intentionally disrupt packets, and the receiver would respond with neutral throttle after 200ms. Turns out that if packet corruption happened while accelerating, the board would sort of kick back just a bit, and that was enough for me to lose balance. It felt pretty weird.
So I started working on a ramping curve to gently bring the board back to 0 km/h in case of repeated loss of connection or bad packets.
I have dual motors, and the receiver firmware was relying on VESC CAN forwarding, where there was a master and slave on the bus. Now the receiver can track telemetry from each VESC independently and send independent throttle/brake commands, so safety is much higher.
I mean, it’s good to think through all scenarios. For example: you’re going downhill, the remote dies or loses signal, a belt breaks on the master VESC, and since the receiver was previously talking only to the main VESC, it would think the motor was at 0 km/h while the other was actually still at 30+ km/h. That means you wouldn’t have brakes.
Now the receiver can track both motor speeds independently and send brake commands to each VESC individually to safely bring the board down to 0 km/h.
Also, ISO 26262 has become my guidance for the firmware from now on. I want to make this thing as safe and reliable as possible!
2 Likes
To me, this seems like a job the ESC should be doing, and now there are too many chefs in the kitchen. The job of the remote and receiver should be to transport the user input to the ESC. That’s it. Then, decisions are made by the ESC about throttle levels and motor conditions. Unless you want all motor decisions made by the receiver, and the ESCs just drive the commanded current only. But splitting it up seems odd to me.
What happens with 4wd setups where two dual escs are present?
How about three or 17 motor systems? What about systems that aren’t controlling motors?
I understand your concern, that’s a valid point in a different architecture, since i moved away from using nunchuck commands we are bypassing the vesc app layer only, so the receiver now behaves in a more consistent way across several different setups (different current, motor, batteries, and limits)
also the VESC always broadcast its status over the CAN bus naturally (there’s one default confit on vesc tool that’s active), so i just need to collect them and make sure they all can come to a safe speed in failsafe
i asked claude to resume the points i would like to highlight here:
VESC CAN forwarding (master/slave)
The master VESC receives your input, then forwards commands to the slave over CAN internally. Problems:
• You’re dependent on the master being healthy. If the master VESC faults or browns out, the slave gets nothing — you lose drive on one side with no warning to your receiver.
• You have no independent telemetry from the slave unless you explicitly set it up separately.
• The forwarding logic and timing is inside the VESC firmware — not under your control.
• For a skateboard with two independent motors, symmetric independent control is actually more correct anyway.
Controlling each VESC directly
• A master fault doesn’t take down the slave — your receiver talks to both independently.
• You can read status from both VESCs separately — different temperatures, different currents, different faults. Useful for diagnostics and future features.
• You have full control over how commands differ between left and right if you ever want that (torque vectoring, for example).
Bypassing the nunchuck/NRF app
• No dependency on VESC app configuration matching — a user can’t accidentally misconfigure the nunchuck app and break your remote.
• Your expo curves, deadzone, and throttle feel are defined in your receiver firmware, not split across two places.
• One less failure point and one less thing to debug in the field.