Excited to share that the first small addition to the FreeSK8 family is now available & shippingthe FreeSK8 NRF52 BLE Module:
Schematic:
Here are the full design source files (KiCAD) for the FreeSK8 NRF52 BLE Module. Further documentation, Bill of Materials, & firmware will follow.
What’s FreeSK8? FreeSK8 is an open source system of hardware components that we will be releasing over the next few months, including the FreeSK8 Remote (OSRR 1.0), a Smart BMS, AS Switch, Robogotchi Datalogger NRF/BLE Module, LightShow Module, and NavCom GPS Module. We will be continuing to flesh out documentation & tutorials for these as we stage for beta testing.
Stay tuned to this thread for future dev & beta announcements.
First half of this batch of NRF52 Modules are assembled and being tested!
These will be shipping out in the next 1-2 days. Approximately 25 units available in Part A, Part B is of similar size and will be ready by next week.
As a reminder, the NRF52 BLE Module does not have any sort of integrated flash logging features but does provide a BLE connection for the FreeSK8 App, VESC-Tool, and NRF connection for the Trampa Wand & future NRF52 based remotes.
This module functions as a Bluetooth connection + NRF
I assume this means not at the same time? ie only does BLE or NRF but not both at the same time otherwise the two things would be competing for uart and something would have to do uart multiplexing like the usplit. Is that a correct assumption?
hope this question doesn’t bring down the forums
Is the upper 4 pin JST connector left on to be able to SWD program the thing if needed?
It does both simultaneously, but is nothing like a multiplexer such as the usplit. The BLE connection (board-mobile app) and the NRF-ESB connection (board-remote) are different radio protocols entirely, the NRF module is just fast enough to rapidly switch back and forth using what is known a Timeslots API. There’s a great article on the features here, but fair warning, NRF development tends to be a pretty thick read:
Important to note that this feature is still not what we consider 100% stable, and as a result we disabled the NRF-ESB connection on the Robogotchi to prioritize stability of the datalogger. There’s more information about this in the latest FreeSK8/OSRR update thread.
That is a 4-pin UART JST connection that you’ve pictured here.
There is a 5-pin SWD programming port positioned in the lower corner of the PCB:
fair. I understand being able to do two radio protocols at the same time.
but there’s only one uart connection to the VESC. suppose something on BLE and something on NRF send messages at the same time what prevents them from conflicting with one another and sending garbled message across the uart?
All of this is handled within the NRF52 firmware, originally written by Vedder and only slightly modified for use on our modules (this will get pushed up this weekend as part of a larger documentation/content push).
The MCU on the NRF52 radio module is actually a lot more powerful than you might imagine, so it’s capable of running multiple threads, interrupts, and has event handlers in place to multi-task. All 3 communication methods (UART, BLE, NRF-ESB) are instantiated within the firmware as their own objects with their own interrupts/setup/services, with the radio comms timing being managed by the Timeslots API referenced above.
Does that make sense? I’m trying to keep the explanation light on tech-jargon but it’s difficult given the nature of the topic.
yeah I think so. In short the MCU supports multiplexing the comms, vedder intended it that way. I assume it’s acting in a non protocol agnostic way. Ie it knows the data formats of the VESC messages and properly routes and multiplexes them. Pretty much what I Imagine the usplit was required to do.
and that’s awesome. I didn’t know vedder’s upstream NRF stuff had considered that at all.
So are people you know running NRF remotes + BLE app same times on this thing? that’s cool.
This exact testing scenario is what was causing issues for some folks until Vedder patched the firmware some months back. We have made our own minor firmware adjustments to optimize on our hardware, and one of our QA/QC processes is testing BLE + NRF concurrent connection on each NRF module made (success rate is 100% once the gat timing windows were adjusted), this is considered ‘high CPU usage’ for the NRF though.
This testing + our performance testing on ESB link budget was also what lead us to shift gears in our own FreeSK8/OSRR1.0 Remote design, going back to our original design which used a dedicated DSSS radio module instead of NRF.
It really does provide a great starting point. Really, our reasons for shifting gears away from NRF for our remote radios has more to do with the moving target/unstable nature of the NRF SDK + limitations of ESB than anything else.
The new metr pro can uses a Skylab nrf52840 as well he has 2 canbus (via external canbus bridge. They have finally added a external crystal in in build oscillator isn’t great. Ublok GPS and card reader. No swd header so you can’t use it to flash ESC bootloader. But I will my money is going towards freesk8 open source for the win. I can upgrade fix update myself.
Took a few attempts with hot air but I managed attach the fanstel module. Still waiting on the LED. Firmware flashed via stlinkv2. Definitely my best designed ble module.
I’ll get our slightly modified firmware updated to our repo tonight, the stock firmware does some… “interesting” things if you run a Wand connected + BLE at the same time. The firmware we’re shipping these with has that fixed.
Yeah these Fanstel modules make me want to die. Hand placing them is not fun, and I’ve placed modules on every NRF52 module we’ve shipped so far.
I figured as much I made sure the crystal pin was correct. Led code is obviously different. I really like the design it would have been cheaper and easier to just buy one but I really wanted to give open source a shot.
I have a few PCBs left over if you would like one pm me and I will post it to you. No charge.
