Deadman switches have been discussed before and there’s a pretty mixed consensus from users on them. It’s something that the OSRR platform could potentially support; there are headers for 2 additional input buttons on the remote PCB. From there it’s a matter of updating firmware to support the option. Well within the realm of doable.
The solution that has worked extremely well for me, for the last 3 years of riding, is the throttle lock function on the Hoyt Puck; double tap the power button and the remote vibrates and locks the throttle input. It’s become second nature to lock it whenever I drop my remote (it’s on a wrist lanyard so I’ll frequently drop it so I can use my hand).
So with all that said, we’ve shamelessly heisted that exact throttle lock functionality used in the Hoyt Puck. It’s simple, effective, and adds a ton of safety.
I’ve noticed something about that recently that might be good for people to know, and at the same time, see if you improved on it.
The lock feature on the Hoyt can be deactivated by losing connection for any amount of time.
Ex.: I stop at the store, leave my board on the sidewalk infront of the store and lock my remote. Go in, lose connection and lock feature goes away. Full throttle function back up
Have you changed something to avoid this?
(I’ve sent my board flying from thinking it was locked when it wasn’t and that’s no fun)
Waterproof is a dirty word in the electronics world.
I would consider these weather resistant, and it’s something we can improve with testing & iteration.
Current design considerations made to address this:
We added a 1.5mm thick acrylic lens to the top shell that gets seated inside the round screen porthole.
The USB-C port sits recessed in the bottom shell, and has a small socket for USB-C cable to plug into. Intention here: additional cable support to prevent broken USB-C ports, less exposed to the elements, and option to drop a TPU plug to really seal it up.
The bottom shell enclosures also have a lip which extends into the top shell.
The only other openings are the thumbwheel and power button sockets, which are deep and nearly pressfit.
I’m simply stating and going off the basis that a loss of connection changes its lock status. In the infinitely small random chance it hadn’t crossed the robot mind
3D models of Bruce, Albert, and the Remote electronics have been published to GitHub. These are current to the first beta batch that’s being built out now.
Most things for a higher IP rating will add a grove with a gasket inside same for the screen. Some thing to consider if you going for better resistance to the elements. Personally I don’t use my boards in the rain.
Care to expand? What you linked isn’t relevant to the topic at hand.
As an open source project, anything is possible. Feel free, there were specific reasons (detailed above) why we chose to not use an NRF based MCU/radio solution for OSRR. It’s an abandoned development path for us.
I was attempting to do some quick google work to figure out if this change from an NRF to Xbee radio meant that different hardware was needed to have NRF remote comms. I also began to wonder if the freesk8 remote + receiver were hooked up to a robogotchi that has NRF that somehow… idk
yeah only part of me was keeping up to stack on this, happy to show I have something more than a guise of abilities to pull off some more advanced electronics work. Hopefully done by applying help from the people in the know. How hard could this be, you have only been at it for like 3 forums.
I had a friend asking me that question as well.
He checked the specs on the DRI website and couldn’t figure out which values will be shown on the remote display. @Andrew maybe that’s something you guys could add to the specs list on the DRI website?
Currently building, testing, & shipping this beta batch is our top priority.
The remotes are on the website to facilitate this beta batch, but the product pages are incomplete because the remotes are not considered a fully launched product as we’re just entering beta.
