Subtitle: “Dude, why are you holding out on us? We outnumber you and have knives.”
Well well well. This project sure has taken us on a weird journey.
Alright folks, you’re all murdering my inbox every day asking why we haven’t released the remote formerly known as the OSRR, the FreeSK8 Remote, to your greedy mitts.
There’s bad news, and there’s good news. But overall, Renee & I are super happy with the choices we’ve made to move this project forward to launch.
I’m going to dig into the bad news first as this is part of our efforts towards transparency in our business.
In March, right before the global pandemic was officially declared, I hopped on a train with my board to go visit Jeffro Friesen (you all might know this lovely fellow as Deodand) & Benjamin Vedder (an equally lovely fellow), who was going to be in the locale for another work engagement. So we decided to have a sit down and discuss how to best coordinate efforts on the VESC-Project, as well as our own projects (Stormcore, FreeSK8).
The discussions were great. I got to sit back, watch & learn as they worked out FW5.0 and bringing Unity/Dual ESCs into the VESC-Tool/Firmware main branch, unifying what was previously a hard-fork in the Vesc-Project. This is the kind of hands on learning & development is what I live for, and it was great to see open source collaboration in action once again.
We also decided to combine efforts on remote technology, and given that Benjamin had a nice start with NRF52 on the Wand (firmware implementation in ZephyrOS, which is great but very new/moving target), Jeff and I both signed on to building out our own remotes on NRF52/ZephyrOS as well. This means less re-invention of the wheel, in theory.
The choice to move over to NRF meant essentially scrapping the hardware & firmware that had been developed during the OSRR Beta and starting over, which is why since late march, we’ve been developing & testing out NRF based remotes in an effort to transition our progress over to a new technology stack. NRF is not an easy thing to deep dive into- the SDK is still not entirely stable on the newer NRF52 hardware and is definitely moving target.
Its important to note that the NRF modules serve two primary functions as it stands: BLE App Connectivity/Logging + ESB radio link to a remote. It is capable of running both radio protocols simultaneously.
There’s no easy way to state this, but the current NRF-ESB radio link that is used from the board to remote does not meet our expectations of performance in real-world testing. That is not to say it is dangerous, or insufficient, but with the FreeSK8 Remote/OSRR project we set out to design a best-in-class remote, and there are technical limitations of NRF that prevent us from achieving that. There is also some lack of confidence in the overall stability of the NRF5 SDK at the moment, as @skate420 can attest, one too many bugs were chased into the BlackBox that is the Nordic SoftDevice. It’s not a fun thing to debug/chase down, and is insanely time consuming.
The TLDR is that NRF-ESB is single-channel and uses only GFSK modulation for frequency interference, and did not perform as well in real-world testing compared to OSRR Beta hardware radios (DSSS) or the Hoyt Puck (FHSS).
What does that mean moving forward? Huge delays? Naw.
The development time we put into NRF yielded us the Robogotchi (integrated async ride logging w/ GPS - BLE logs sync to app) + NRF52 BLE Modules, both valuable devices to the FreeSK8 ecosystem. We will not be moving forward with using NRF-ESB for remote-board radio link however, and will not be supporting it on Robogotchis and devices moving forward. We do lose a bit of development time & costs in prototyping, but that comes with the territory in hardware development.
Instead of changing the remote over to NRF, we are sticking with our original ‘known-good’ hardware & firmware architecture choices used in the OSRR Beta. We have approximately 25 units in the wild with testing done for over a year, and had great results & feedback.
This will also keep things moving quickly, as updating our original hardware is a quick effort, and we already have a functional base of firmware to build from.
Cliffnotes on the hardware changes from Beta hardware spec vs new production hardware spec:
OSRR Beta Hardware Spec:
- Industrial Hall-Effect Thumbwheel
- 0.9" TFT LCD
- ESP8266 mcu
- 700mah battery
- Xbee S2C
FreeSK8 Remote (OSRR 1.0) Hardware Spec:
- Industrial Hall-Effect Thumbwheel
- 1.3" TFT LCD
- ESP32 mcu
- 1500mah battery
- Xbee S3
This hardware architecture worked, and it worked well. It also leaves us with options to upgrade to even higher power 868/900mhz FHSS Xbee Radios should we want to completely over-spec these.
What does this mean for hardware release timelines? This hardware choice releases us from a ‘stuck’ in that we were waiting to move forward on trigger pulling production. Realistically, we will need at least a month to update hardware, get a run of prototypes made, and then get production rolling. I can give a more accurate time estimate in about 2 weeks.
I’m gonna leave it at this since I already wrote a lot, and we’ve gotta keep moving on Remote development.
Happy to answer any questions.
Thanks so much for all of your continued support!
PS: We also have another surprise remote collaboration projects in the works, which should be arriving around the same time as the FreeSK8 remote if all goes well. We won’t say more, but let’s just say that it involves skaters helping skaters right here in Portland, Oregon.