I’ve been working on a custom remote myself - but from a different angle so far. I have focused on the schematics and electric side. I am looking for other people that might be interested in teaming up and working together on the remote.
On my side, the main schematics (with charging circuit, usb2mc connection and other things) is done, but I haven’t had the time (and skill) to start with a case. I’d like to have the case first, in order to fit in the pcb (and create a layout on top of it)
Anyhow - if you are interested let me know.
Per your design - some suggestions from what I have gathered myself:
dead man`s switch (from what you already noted)
some menu button(s) to navigate and change settings
you might think of moving the display further down / towards the bottom. Most oled display have a fairly large pcb themself (usually around 3x3cm) and thus your display would most likely be taking space from the throttle system
@flatsp0t @Stevemk14ebr @Mrmoonlight @Pantologist
All your solutions mentioned work in the 2.4 ghz spectrum (actually 2400Mhz - 25xx Mhz) and they would all be prone to the same problems in urban areas. Just because you name it differently and have a different specification, doesn`t mean that there is suddenly more “space” in the medium. They all have to share the 2.4Ghz band (see wiki). So even if you include a second radio, you will need to deal with interferences. Your everyday 2.4 GHZ hobby remote is not built to be used in highly con-quested areas - and on top of that - the protocols are fairly simple and will not deal with packet loss / re-transmissions (/ encryption).
So where to go from here?
choose a different frequency band: go for 433MHZ or 868/933MHZ ISM bands. Even though you will have lower bandwith - it is vastly sufficient for realtime data from the vesc and from the remote. (100hz for controls and 10hz or less for displaying information is more than sufficient - assuming that control data is ~10 bytes (one axis, 1 button) and vesc information ~300 byte - we would need less than 5kb/s constant data connection ;-))
The benefits are, that these frequencies are less common and used - so less prone to con-question and other problems
choose a specification that handles packet collisions, re-transmissions, con-question, channel/frequency switching reasonably well (from all mentioned actually wifi has the best specifications - highest transmision power (compared to bluetooth), low latency transmissions, encryption with wpa(2) etc.)
write your own protocol on top of a low level protocol (i.e. most 2.4 GHZ transceivers) to deal with mentioned issues
write your application to actually account for packet loss, re-transmissions and include proper safeguards.
Whatever you do, I can only recommend not to neglect the security issue with transmitting unencrypted data for your boards. Even if your data is encrypted, you should also account for packet replay attacks and other malicious attacks - it is your life you are dealing with here. And creating a harmful device is fairly easy. (Even if it is just to jam signals … )