I have my DIY project together and basically working:
Adafruit Clue - https://www.adafruit.com/product/4500
- Accel, Gyro, Magneto, Temp, Pressure, BLE
GoPro Hero 8
Sparkfun GPS - https://www.sparkfun.com/products/15712
- 1.5m accuracy, 25Hz - GPS
Sparkfun Antenna adaptor - https://www.sparkfun.com/products/9145
Qwiic cable - https://www.sparkfun.com/products/14426
GPS magnetic active antenna - https://www.sparkfun.com/products/14986
Adafruit LIPO charger - https://www.adafruit.com/product/1904
- charges battery from usb
Adafruit Lipo Battery - https://www.adafruit.com/product/2011
- 3.7v 2000 mAh
Handle bar switches for motorcycle - https://www.amazon.com/Grow0606-Handlebar-Switches-Assembly-Motorcycle/dp/B07BT4P8G6
Arduino sketch - https://github.com/johnmichaelquinlan/datalogger/blob/master/code/clue/datalogger-1.6/datalogger-1.6.ino
Handle bar switches are used to turn the power to the Clue and GPS, as well as to enable the gathering and transmission of data to racechrono, I may use one or two to indicate when I'm.
All I'm waiting for is the expansion of the BLE characteristics or support for BLEuart so that I can send RC sentences to include the Clues IMU and Analog / vehicle sensor data.
The clue also has 6 ADC input channels I'm going to use two for brake pressure sensors, one for throttle position this will just be a relatively simple voltage divider, one for the rpm ( this will use an opto coupler to pass the pulses into the Clue at logic level then run an interrupt based pulse counter, I might use a second device for this and pass the data back to the master Clue to send to racechrono ).
I'll be making a youtube video soon showing assembly and setup on the vehicle.
I've been playing around with attempting to send data via the can-bus characteristic, I'm following the exmaple you posted which just seems to send the PID and then some bytes based of what it received.
I'm assuming its following the standard can-bus data packet format.
So I'm attempting to construct that data stream manually, however, when I test the connection in the vehicle editor so that I can build the channel essentially I get a connection via ble immediately followed by a disconnection, my arduino is giving me the reason is that the user terminated the connection suggesting the application disconnected?
Any idea what might cause that behavior?
So I figured this out, I had removed the filter characteristic when I simplified my sketch for testing and if I do that the bluetooth connection wont stay connected.
When setting up the channel I found the byte index order confusing at first since it appears to be LS to MS in terms of the byte index at least 0x20FF with R2 would return 0x20. I'm kinda use to working the other way around.
Does this mean I need to be sending my bytes for my data in this fashion?
Endianness is defined in the API documentation. There's only one case where it's little-endian, it was originally a mistake which I just fixed in the documentation https://github.com/aollin/racechrono-ble-diy-device
Make sure your device starts sending data only after RaceChrono has set the filters. You can ignore what's in the filters, but you need to wait for RaceChrono is done with it.
The filter characteristic needs to be there, as RaceChrono will disconnect if it's not. So both UUID 1 and UUID 2 is needed for working "CAN-Bus" API.
This characteristic is read and notify only.
byte index description
0-3 32-bit packet ID (Notice: this value is a little-endian integer, unlike other values in this API)
4-19 packet payload, variable length of 1-16 bytes
my question previous kind of related to the contents of the bytes 4 - 19 packet payload.
can that be any arbitrary data in the bytes or is the format within that block specific to a particular can bus structure / format?
I guess I was just hammering 'random' data to the app that it wasn't expecting so was reporting no data.
Its now at least correctly seeing the device and giving a time and update rate.
I'm getting one or two odd behaviors when using both the canbus characteristic and gps at the same times, essentially something similar to before is happening where it just sits saying waiting for data.
If I disable sending gps characteristic notifications everything seems to work fine.
I'd order the parts but Adafruit CLUE is out of stock on their site, and it's too new to be available elsewhere. It's an interesting hardware I might base on my new projects on it, so no problem buying them! Let's hope they get next batch soon.
You must not send CAN Bus characteristics before RaceChrono has written the filter characteristic.
CAN alone seems to work even when you don´t care about the filter, but if you want to use it together with GPS you need to wait for the filter to be written.
So in the end there were some things that I had done wrong with the gps data, that seemed to be screwing it up where the two gps characteristics were not agreeing on time, I fat fingered it during refactoring and cleanup.
Secondly my I2C bus was becoming over subscribed and the gps was not responding correctly, this breakout board has some pads on the back to add additional external pull-ups and adding one of those fixed this.
It's all syncing data very nicely now. All my motorcycle channels and the IMU data along with the gps.
I'm getting close to putting it in a box and calling it done.
I'll update my code on git hub and do a project build / over view along with the vehicle feeds.
Tomorrow is attempting to get a face plate with the relevant connectors profiles cut into it and get the whole thing in a box and mounted on the motorcycle with the go pro.
I also have one more feed from the bike to fix up, going to have to make a cable that goes from the data logger port on the HRC kit loom to my 15 pin port as well as mount the handle bar switch gear and combine that in with the loom additions.
It's a back order from DigiKey and not available from Mouser at all. I did order a couple in hopes they get back in stock soon.
Sending the 9 axis IMU data is probably the largest chunk if I don't encode and bit pack the crap out of it, I was thinking of dropping the 4 bytes and encode the accelerometer data into 2 bytes per axis.
I need to look at the range for the gyro and magneto to figure out what I can do there. In theory I can scalar and convert to int, possibly loose some small amount of fidelity but save on total bytes sent. I was wondering if it would be better to computer absolute Euler angles from a calibration base and just send those, I could effectively get the integrated Gyro and Accel data for just 6 bytes.
although I'm kinda fishing in the dark a little trying to see what lets me get faster update rates, Ideally I would like the GPS, BPS, RPM, Throttle PS, Accel and Gyro ( or absolute rotations ) to be at least 10 times a second if not closer to 20.
AirTemp, Humidity and Pressure and magnetos can all go and update at 1 hz for all I care really.
I'm also going to implement the adafruit calibration storage for the flash memory on the clue, it should be able to store a calibration offset for each sensor type for loading at setup. This will really help.
I got the interface board manufactured tonight so its not breadboard anymore, last steps I need to get it fully integrate are:
Motorcycle datalogger port and handle bar switches sub loom
Manufacture the armature and mounting brackets for the Brake Position Sensor
Mount all the external ports for the logger into the case
I got the wiring loom all made up last night and started mounting the enclosure and ports.
anyways, just thinking out loud.
I've got everything test mounted on the bike and I'm just building my own brake position sensor out of an xbox pad I pulled apart, taking the trigger pots, made an armature that is spring connected to my brake lever, the board holding the pot is bolted to the master cylinder, so when pull the lever it pushes the armature out turning the pot giving me an analogue voltage level at the pin on the clue.
Found a couple of bugs in my code I've uploaded a new version to git hub, I'm working on a video showing the construction of the device and wiring loom.
The only other things I might quite like to do is get a linear travel pot for the suspension travel on the front and rear which should be only a couple more pins. But the linear pots are expensive, I did see a guy using multiple turn pots with a kind of return spring system then just a wire wound up connected to the suspension button. So when the suspension compresses the return spring winds in the cable turning the pot along with it. very lofi but cheap and effective.
The RejsaRubber project uses a distance sensor for the suspension travel. Problem is ofcourse how to protect this sensor from the elements. https://github.com/MagnusThome/RejsaRubberTrac
I would need to add feeds back to pins on the clue, via additional voltage dividers. but I have plenty or room to expand, front and rear suspension travel would be nice.
I really wanna see if the magnetos will detect the timing loop antennas magnetic field on the track, it likely wont but if it did get a blip would be a good way to detect the start finish line for lap tracking along with gps.
I was wondering if there is a way to tell race chrono app to start from my handle bar buttons, I previously had this with my raspberry pi custom stuff. it means I dont have to keep grabbing my phone and messing with it before going out, I can just start the bike turn on the data logger, hit the start button. Assuming I already had race chrono open.