FreeSK8 Remote (OSRR 1.0) Updates

FreeSK8
1

Subtitle: “Dude, why are you holding out on us? We outnumber you and have knives.”

image
image1280×928 80.1 KB

image
image1216×909 80.7 KB

image
image961×925 83.1 KB

image
image1189×1050 106 KB

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.

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. :wink:

image
image1155×791 99.2 KB

28 Likes
2

Interesting that OSRR uses a less advanced frequency hopping protocol than Puck. Care to comment?

So there’s a new Puck coming. Nice!

9 Likes
3

I think you made the right choice in sticking with what works best currently. It also opens up questions to how will the others (Lacroix and Trampa, if not more, I’m assuming) deal with the NRF issues you experienced. Quite a shame we’ll be missing out on the benefits NRF would have given us, but the demand for OSRR is high enough that I don’t think it will upset too many.

Great job everyone for the work done so far! :heart:

7 Likes
4

Based on?

What works, works. There are a number of different ways FHSS & DSSS can be implemented. It’s a pretty broad term.

8 Likes
5

It’s hard to say exactly what is going wrong when the SoftDevice fails. You do not have the ability to debug anything that happens in the SoftDevice as the source is closed and controlled by Nordic. When things work it’s wonderful since you can easily (relatively) add features like Bluetooth to your project. When something goes wrong you receive a notification something went wrong with the SoftDevice and a PC code that signifies where their code was when it encountered an unrecoverable error. At this point the device must reboot itself to resume operation. We found issues across multiple versions of the Nordic SDK when working with BLE + ESB simultaneously and didn’t find this solution to be stable enough for our needs.

11 Likes
6

I’m curious what you think those benefits are that we don’t have with other options?

Also keep in mind, the Robogotchi is staying NRF based, so we’re not losing any hardware.

The choice here is to move to a dedicated radio for remote-board comms VS using NRF for both BLE + ESB.

6 Likes
7

Based on DSSS being able to do lane skipping on a highway, where FHSS can skip whole highways if needed.

5 Likes
8

Integrated receiver in many ESCs is the first thing that comes to mind. It being a standard would have allowed for easier remote switching. Also I’m assuming it would have meant less hardware in the remote itself, if it just needs the 1 thing for both control and telemetry. You’re the expert here, so I guess you know best ¯\_(ツ)_/¯

4 Likes
9

This doesn’t exist if the NRF solution isn’t viable to be used as a receiver link.

ESB does not hold up to FHSS/DSSS based solutions in all of our real world testing, and it’s enough that we don’t want to even try to support something that is potentially unstable. The preference here is to keep NRF as a stable BLE comms module for App interface.

There is a Nordic protocol called Gazelle that has freq hopping capabilities, built on top of ESB. However there’s very little documentation/support for it, even less for using it with timeslots api to enable BLE concurrently. It also has zero support in Zephyr, so we would be wiping the firmware slate clean with that route.

We’d prefer to go with a tried & true radio comms solution.

7 Likes
10

Fully agree on this one, doesn’t hold a candle.

6 Likes
11

I agree it’s the right choice, just sad it didn’t work out the other way.

5 Likes
12

We use FHSS technology in the RC world. Good stuff. Rarely any disconnects.

8 Likes
13

In an ideal world, one receiver to handle BLE comms + Remote comms would be great. Believe me, it’s not an easy choice to make here but I am firmly of the belief in not getting stuck in one path and having fall-back plans if new hardware goes wrong.

I’ve used Xbees for over a decade in a number of crazy RF noisy environments and they tend to be rock solid.

We also have the option of dropping in FHSS “Pro Series” Xbees, at the additional cost of about $20/radio. But in our own real-world testing over the last year of OSRR Beta, the DSSS implementation in the Xbee S2C/3 has worked out with strong confidence.

8 Likes
14

This right here makes me go “I know this remote will never disconnect from my board and I don’t even live in San Francisco, but if 20$ now could potentially save my life… ughhhhhh take my money”

7 Likes
15

I’m really hoping this counts with the flavour of 5G we have in Australia. The GT2B has DSSS and I still ended up in hospital.

6 Likes
16

The bad rep of DSSS probably comes from Spektrum RC radios that compared to others were less reliable signal wise.

6 Likes
17

The other thing is “DSSS” & “FHSS” are about as broad of terms as you can get.

There are dozens of implementations, using different algorithms that have vastly different realworld outcomes. Most are blackboxed within the radio firmware binaries too.

We are basing our decisions on what has worked for us already in real-world testing over 10s of thousands of miles, and the option to have upgradeable/socketed radios is one that I like quite a bit.

6 Likes
18

Also, given the above information, I take it the issues when connecting the Trampa dongle to the vesc app and recording are still unresolved.

5 Likes
19

Based on our testing so far, it’s stable on the NRF52 BLE Modules that we have been shipping.

We have not been satisfied enough with the concurrent BLE/ESB connection + Robogotchi functions enough to offer it on the Robogotchi at this point.

6 Likes
20

I’m a bit confused.

Robogotchis will still be able to have BT connection in addition to it being a receiver, correct? It will use FHSS technology instead of nrf to control the board, si?

4 Likes