Almost all CAN ports are 4-pin JST-PH. The only exception I can think of are Ennoid controllers which use JST-GH
3 Likes
thanks for your input, regarding safety for my device i can tell you that on the receiver side there’s a 200ms throttle timeout fail-safe. If no throttle command is received from the remote within 200ms, it resets to neutral. The timer runs separately, so it still works even if other code misbehaves. on bluetooth disconnection, it resets right away.
and lights/peripherals output is already implemented (double clicking the main button), if you scroll up a bit you will find some info on it!
and regarding durability they are pretty good but I havent run some dropping tests on them, waiting for the feedback from the community when they will be tested in the field
5 Likes
yes, but spintends use this one instead: SM04B-GHS-TB(LF)(SN) | JST | Price | In Stock | LCSC Electronics
1 Like
Yes but he provides an adaptor for jst2.0. It is a nice connector tho. Clicks in place and very minimal. Probably better than the standard imo
yeah i’m using that connector on the receiver, will ship with standard jst and provide an adapter to spintend
1 Like
Is it a big deal to soften the reset to 0? In all cases a sudden change in throttle is more dangerous than a quick ramping to neutral. If it had really obvious steps that can be felt it would be a bonus like a warning but a smooth ramping down would be amazing. Nothing like a 10 second process or anything but just a full .5 seconds or 1 second. If the throttle position had to be back at neutral to accept the next input it would help prevent sudden inputs after a signal loss or disconnection or failure.
Just a thought for what my idea failure scenario would be
1 Like
Negative ramping in vesc tool sort of does this, though if you increase it too much it does feel like the throttle runs on a bit longer than you anticipate. I run a 0.25sec negative ramping in vesc tool so if I release the throttle quickly it doesn’t jerk as much, but it’s also not too high value to bother me.
1 Like
I see what you’re saying but this is a receiver side emergency situation, or at least it’s an critical behavior if not an emergency. I would think that it would be better to control the variables for this kind of issue at the receiver and let the other vesc settings be for normal operation. You are probably right that .25 seconds is plenty though
How does vesc react to a sudden throttle change though? Without a ramp down and return to neutral in a signal loss if the throttle drops to zero but the throttle position is at 75% and signal is restored you get a big bump. Also this is only in a cutout or signal loss situation so having a known good process and mode of operation that is predictable and safer is beneficial in my opinion. Im not suggesting throttle curves built into the receiver, just a way of handling a bad situation as best as possible… in my opinion and from my limited experience 
2 Likes
I would also suggest a sound clip of a screaming goat to be played if/when there’s a signal dropout.. Just for good measure.
9 Likes
@Pecos I just kept crude signals since ramps cam be done on the vesc side, otherwise it would be an overlap of functions, just to keep it simple, and never had any issues on my rides until now with those configs.
@AlexB good idea, but the changes of having loss of signal are so tiny anyway
1 Like
Can we still get the screaming goat somehow? Maybe if remote is disconnected from the board. Haptic vibrations and goats.
5 Likes
Better yet just alex’s remote will scream like a goat every random interval of 500 seconds. Or just call it alex mode with no explanation in the github.
3 Likes
Lol this reminds me of my Bruce remote that would bleep out “FUCK YOU ALBERT” in morse code every time i turned it on
5 Likes
What if we can do what was on the Robogotchi (or something, forgot…) where it plays a tune everytime you turn it on. The one I knew had the community vote on the Mario tune.
2 Likes
Pretty easy to do that with a super cheap standalone unit and not add extra complications to the remote control system.
1 Like
I have been away for quite some time, was working on the mechanics and making everything tight, went for shoulder screws on the throttle and brake axis so they would fix 2 issues at once but didnt quite worked out the way I liked, so went back to dowel pins, snapfit joints and waterproof glue to keep everything together.
also I’m pushing later this week an important security update to both the remote and receiver firmware. Here’s what changed and why.
The Problem
Previously, the BLE connection between the remote and receiver had no authentication. This meant anyone with a generic BLE app (like nRF Connect) could:
-
Connect to the receiver
-
Send raw data to the throttle characteristic
-
Potentially cause the vehicle to accelerate
This was a serious safety issue that needed to be fixed urgently
The Solution
Both firmwares now implement BLE pairing with encryption. Think of it like adding a password to the Bluetooth connection.
How it works:
-
The remote and receiver share a secret passkey (hardcoded in the firmware)
-
When connecting, both devices must prove they know this passkey
-
Only after successful authentication can the remote send throttle commands
-
The connection is also encrypted, so data can’t be intercepted
What You’ll Experience
First connection after updating:
-
The remote and receiver will automatically pair
-
This happens in the background - no user action needed
-
A “bond” is created and stored on both devices
Subsequent connections:
-
Instant reconnection using the stored bond
-
No re-pairing needed unless you erase NVS
If someone tries to connect with nRF Connect:
-
They can see the device and connect
-
But any write attempts are rejected
-
The receiver logs: “Rejecting write from unauthenticated client!”
-
They would need to know the passkey to pair (which they don’t), this is not the safest method out there but its good enough for our application.
Additional Improvement: Device Memory
I also added a feature where the remote remembers which receiver it was connected to:
-
On boot, the remote first looks for the previously connected receiver (by MAC address)
-
It tries to reconnect for 15 seconds
-
If not found (receiver is off, out of range, etc.), it falls back to scanning for any compatible device
This helps in situations where multiple users are nearby - (like a group ride) your remote will prioritize reconnecting to YOUR receiver rather than accidentally connecting to someone else’s.
So the flow would be; you turn ON the board, then turn the remote ON, they will instantly pair.
you turn the remote ON, but your receiver is OFF; the remote will keep trying to reconnect to your receiver for 15 seconds, after that it will try to find another gb receiver and connect to it. So you dont need to trigger a “pairing mode” which i hate having to do that (like having a push button on the reciever to trigger the pair mode)
5 Likes
George @georgebenett do you think I could hook up this trigger assembly to substitute the thunbwheel on the V1 remote?
5 Likes
yes but you would need to recalibrate the throttle in order to make it work
3 Likes
I have a small demo to show you guys: https://youtu.be/pttRvK7l6Sk
4 Likes
Looking really great! Cant wait to get one and see if I can’t destroy it 
. Oh and that skateboard looks a bit off. Maybe needs a couple more wheels 
2 Likes