I previously (https://github.com/j-e-f-f-williams/TrackDAQ/wiki
) had a 2009 ZX-6r track bike and I created a DYI connected to ECU wiring for throttle position etc. I used different MCUs with BT Serial RC3 (at 50hz) and GPS (at 25hz). Now I have a S1000RR and its time for a new DYI config based on CAN. New version I am looking at ESP32 base and wont need a custom board this time (for now), I have the CAN working to the MCU so back to sorting out comm channel.
So what is the recommended comm channel for DYI now? (Connecting to Android)
- BLE seems to have better channel controls but seems to limit the message rate?
- BT Serial seemed OK for previous and still seems to be the easiest to setup though I always found it a pain that I had to remember which field was which since you cant name them
- WiFi is an option which gives more bandwidth vs BT Serial but also takes more power etc
Is there a reason to do something other than BT Serial?
With the new bike I am not sure I want the phone on the top of the tank like I had on my Ninja but would still be nice to peek at lap times on the front straight. Is there any way to get a signal back from RaceChrono each lap at start/finish? I could wire it to the dash signal to show lap time (close enough for in-session). I thought I saw the option for BLE at one time but I cant find the forum message about it.
First, all the things that didn't work for me:
1. BLE: Tried nRF52840 code (from Anitti, Timur and my own), ESP32-S3 dual core code by Joe, my own custom ESP32 code on a resjacan, and many other iterations. All had message rates which were too low and variable. 35-50 Hz max achieved.
2. ELM327 (canbus via an OBDLink MX dongle) doesn't have developer support for high rates / dataloss due to protocol handling. I also found starting sessions hit or miss and frequent dropouts.
3. Wifi: plenty fast for ELM327 or RC2 / RC3, but I've had issues with it dropping mid session. I don't think Racechrono tries to reconnect to wifi unlike bluetooth.
Overall, the bluetooth implementation in Racechono seems to be the most tolerant to disconnects (will attempt to reconnect) and is trivial to initially pair and connect for sessions.
So, after all that experimentation, I stuck with using an ublox NEO-M9N @ 25 Hz and an Arduino DUE that was acting like a canbus aggregator / bridge to an OBDLink LX. The DUE would hardware filter for the PIDs I was interested in on CAN0 (bike side), then combine the interesting bytes into a single fake "master" PID on CAN1 so the OBDLink could just look for that single PID and spit them out as fast as possible. It worked ok, nearly 75 Hz, but there was still dataloss when the OBDLink would get stopped by racechrono and also many packets would make their way to racechrono but not get parsed. The reason I stuck with it was the OBDLink would enable videos to render with the correct channel name label and gauge types in Racechrono (and not with analog channels on a DIY device).
But now, with the release of the v8.0 beta, you can now assign arbitrary analog channels to various visualizations. I went back to my code base to hack together "native" esp32 BT RFCOMM Serial RC2 proof of concept and it seems to working well and sending data at nearly 100hz. Not track tested yet but it has worked well on the canbus emulator on the test bench and also on the bike. An Esp32 (either a resjacan or T-CAN485) is plugged into the bike's canbus and uses interrupts for the 4 PIDs I care about. It parses, calculates and stores channel values and fires off a RC2 message each time a 100Hz PID is parsed.
Some closing items:
I second Anitti's mention of the Monitor API. Magnus has a quick demo of it on his youtube (www.youtube.com/watch?v=f61Pw1ZjPyw). I've also made 2 modules that I'm testing with: 1. A bluetooth audio module that will verbally tell me if I'm slower or faster during the lap via the helmet comm so I don't have to look at the phone (both time and speed). 2. A strip of 8 neopixels that tell me if my speed is higher or lower than my reference lap.
Check out https://github.com/MagnusThome/RejsaRubberTrac for suspension / IR tire temperature logging if you haven't seen the project yet. Since its BLE (and thus slow), i'm thinking about folding some of the suspension travel stuff into the high rate BT RFCOMM link as an analog channel. However there is no incentive right now other than datalogging as the visualization won't reflect the additional data.
I'm guessing that you already have some PIDs and their equations for the S1000RR. If you don't, here is the fork of the big S1000 spreadsheet with some of my observations, racechrono specific items and notes:
I've also yet to test a racechono DIY device on a wired ethernet network. Something like:
Bike ---Canbus---> Raspberry Pi / esp32 ---USB OTG Ethernet---> Phone (Racechrono as TCP DIY device).
Should be the fastest / most reliable. It looks like you already have a pi / code and care about high rate data unlike most . Let me know if you head near that direction, I would be interested in the results.
@cohberg you comments about BLE and other comm channels is what I was wondering about when I posted here. The RF COMM worked well on my old setup. I have 10 CAN IDs I am going to monitor at the moment.
I had a set of IR temp sensors like RejsaRubberTrac project on my previous bike but never found a mounting point that I liked and I have pretty good tire pressure settings for the few tracks I visit. I am deciding to re-try a distance sensor setup but I also tried that in the past with mixed results. I am considering just getting a proper set of linear potentiometers.
Yes, aware of the google sheet with S1000RR (and other BMW bike) CAN details.
I am leaning to using RF COMM for the initial attempt to get me some stats for the new bike since I know how it goes. Then I can play with BLE and WiFi etc as options. I don't see playing with a OTG Ethernet being something I would use as number of cables etc. The issue I had in history with RaspPi was that they are OS based generally and I had corruption when powering off. I tried to do some bare metal programing on the RPi but the MCUs seem to be better for my needs.