Hello, we at Enertion Boards wanted to give you guys an early look at the remote we have been developing over the past year. Feel free to skim through this lengthy write up and give some feedback!
Please forgive the rough print quality of our prototype, we’ve been rapidly iterating and are waiting on higher resolution prints to arrive before getting molds made. Please also note this is a prototype, we will continue sharing updates as the design is finalized. Here’s a few renders to give you an idea where we are headed aesthetically:
Throttle Design
A remote is first and foremost the control of that (hopefully) powerful beast sitting under your feet. A bad throttle can make it seem challenging to tame that power, and at it’s worse can create dangerous situations during an accidental slip of the finger. Even more dangerous can be situations where electromechanical interfaces break down such as the oft-used but sometimes fragile potentiometer. Just this week in Denver we were unfortunate enough to witness a potentiometer failure that caused the throttle to lock up; launching a board uncontrolled into a curb damaging itself and (fortunately) nothing else.
We did a complete overhaul of the design to increase the tactile feedback and throw of the throttle. Strong neodymium magnets are used to provide ramping force feedback as you lay into the throttle. The changing magnetic field is also used as the sensing element for throttle position, which means the electronics are completely solid state. Because the magnets are strong enough to provide the spring force for the throttle they are also quite robust to incidental magnetic interference. Additionally, multiple embedded 3-axis hall senors combined with intelligent filtering ensure reliable and high-precision feedback of throttle angle.
This all adds up to a premium throttle feel that meets the demanding requirements of even the most powerful high-end builds.
Telemetry & Durability, can we have both?
We had many long discussions on what form of telemetry was best for our remote. Most remotes seem to be using OLEDs which can be difficult to see in sunlight, and testing showed them to be fragile when dropped. We also investigated E-ink displays and found similar problems with fragility. The most robust remotes seem to use the ever-reliable LED, which can be great for at-a-glance information on current battery levels etc. but the flexibility of what data can be displayed is limited and often not intuitive.
Ultimately we decided to for a more retro-style 0402 LED matrix, this allows for the display of numerical and text-based telemetry and is significantly more durable than any OLED screen we have tested thus far. It’s shockingly bright when you crank up the brightness to max. It also has the advantage of looking pretty cool when you scroll logos across it:
To augment the telemetry data and offer more stylized output of data (battery, speed, throttle, current etc.) we included a remap-able and customizable RGB bar. It has been suggested by leading experts that the RGB can improve performance of your board by 236%
Additionally there is a vibration motor for some tactile feedback.
Battery
Nobody wants a remote that has to be recharged after every ride, or to use disposable batteries which generate harmful e-waste that is tedious to dispose of properly. The remote is slated to contain a 2Ah rechargeable lithium battery. Testing has shown the battery lasts over 30 hours with radio on full power and screens displaying at medium brightness. We’ll continue testing as the firmware matures to get a more true-to-final estimate of battery life. Additionally we are upgrading to the durable USB C so no more torn off charge ports (unless you are really strong).
Wireless Stuff
If you look around it seems a portion of remotes are moving to BLE modules, and leveraging the ESB (shockburst) protocol from Nordic. Many here on the forums have reported back mixed results with this protocol (it’s what nrf24s use as well, think nunchuck remotes). Investigating further I realized it takes someone extremely well-versed in RF implementations to create a robust and reliable connection in interference ridden environments with this technology, and I’m fairly certain that is why results are such a mixed bag.
Let’s get into some nerdy bits so I don’t just sound like I’m pulling this from thin air. The shockburst protocol leverages GFSK modulation, or Gaussian Frequency Shift Keying. This means it uses a fairly narrow band of frequencies to transmit data. If a strong interference shows up within the same bandwidth it can corrupt the signal, and in cities this can happen all too often. The common way to improve performance is to do Frequency-Hopping to spread the transmission spectrum randomly across a pre-set number of independent frequencies. This can get pretty complicated and from my exploration it seems easy to implement incorrectly.
We chose instead to go with a newer chip, namely the SX1280 . It was specifically designed for low-data rate and long range wireless links. The SX1280 contains some integrated proprietary protocols that handle some of the heavy lifting for robust spread-spectrum transmission. These protocols should be less susceptible to the narrow-band interference you can encounter skating around big cities. As an illustration, with FLRC protocol on the sx1280 at an effective data-rate of 130 kbs you get a frequency spread of 300 kHz , by contrast GFSK is spread across 0.3 kHz.
Let’s look at a couple specs to see how it stacks up vs the newest NRF52840 from Nordic. The easiest of these specs to understand are transmit-power, and receiver-sensitivity, both of which contribute to the robustness of the wireless link. You want a large dBm number for transmitting and small dBm for receiving. The transmit-power of the sx1280 is 12.5 dBm vs the 8 dBm of the NRF52840. Decibels can be a bit confusing but in simple terms this means the sx1280 transmits a signal that’s about 2.8 times more powerful than the latest NRF module (if its an NRF52832 that number is much higher still). Reciever-sensitivity is a bit more involved as varies depending on which protocol you implement with the sx1280, but using a handy calculator tool a 10ms on air 20 byte LoRa packet has a sensitivity around -109 dBm, and if you instead go for the FLRC protocol you can achieve a sensitivity of around -106 dBm. The NRF falls short here as well, the highest listed sensitivity in the datasheet is BLE long-range with a sensitivity of -103 dBm. But even with that best case scenario the receiver should detect signals that are 4x weaker in LoRa mode and half as strong in FLRC. In terms of range since we don’t use a directional antenna, if we use LoRa we can say the module is:
sqrt(2.8*4) = ~3.3 times the range
And in FLRC
sqrt(2.8*2) = ~2.3 times the range
Now you’re probably thinking “I’m standing right on top of the skateboard why do I want more range?”, the answer is pretty straightforward. The difference between the transmit-power and receiver-sensitivity is called link-budget, and increasing distance is only one of many things that can negatively impact this value. Every bit of carbon-fiber in you’re enclosure, every 2.4 Ghz network in your surroundings, even the sunlight or EMI thrown off by nearby electronics subtracts away from this number. With all of these negative factors you want to be sure that your remote is as reliable as possible to ensure your own safety. This isn’t the whole story, and many other factors come into play to get more true to real-world range comparisons but I think we can all agree this section is already too long.
The combination of spread-spectrum transmission, increased transmission-power, and receiver-sensitivity should yield a remote that never drops out on you while riding. Early testing has shown these modules seem to live up to the hype, but we are in the process of finalizing the design to prepare for beta-testing to ensure the connection holds in even the most interference ridden environments. Including those with many co-located remotes.
Mechanical Bits
In terms of ergonomics, we wanted a design that could be held comfortably in either hand and would allow all buttons to remain accessible. We also wanted the design to be resistant to dust and contaminants. To achieve this, the remote will feature a semi-transparent silicone gasket running the entire perimeter of the shell which seals in the electronics. We will also be adding a loop for a wrist lanyard.
For the receiver side we will have a small module with an integrated CAN interface alongside PPM. You will be able to connect to the FOCBOX app and customize the remote through CAN forwarding or connect to the computer through USB. We’ll share more information here as the firmware evolves.
Open-Source Firmware
We’ve talked at length about customization, because everyone has different ideas on what the perfect remote looks like. One of the reasons Vedder’s work has been so popular in the community is the breadth of customization he allowed. The open source nature of his work enabled others to contribute their own designs, tweaks, and customization. The FOCBOX Unity further built upon this by simplifying the setup and ease-of-use of some of these tools and we intend to continue pushing forward these efforts with continued support and contributions from the community.
We are excited to say we will be releasing the FOCBOX Pilot firmware open-source to allow the community to add their own customization and tweaks. I also had the pleasure of meeting up with @DerelictRobot and @Jonner while in Colorado, who are both doing a lot of cool and diverse work in the e-skate remote space. We talked at length on the topics of remote safety and reliability, and we all agreed having more collaboration to review the designs, architecture and code of this critical system would be a win for everyone involved.
We have begun working together to develop a small low-cost open-source development board consisting of the radio, micro-controller, and power regulation architecture including a single cell li-ion/lipo charge/discharge. This will be available for anyone seeking to develop their own remote and leverage the existing drivers and routines integrated within the firmware. While other developer platforms (like the adafruit feather) exist, they are not targeted specifically at e-skate remotes and the provided examples aren’t intended for use within a system controlling a rocket under your feet. We hope together to develop a powerful codebase for other experienced developers looking to design a custom remote implementation while keeping the system simple enoguh that this platform can also be leveraged by hobbyists to build unique mechanical remote designs leveraging standard supported components.
