Adafruit Clue BLE + Sparkfun NBlox GPS + GoPro + Chrono DIY

JmQ

Hi,

I have my DIY project together and basically working:

Shopping List

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.

aol_of_RaceChrono

Try sending the IMU data over the CAN-Bus API and define the IMU "CAN-Bus" channels at the vehicle profile. I will do a dedicated IMU characteristic later.

JmQ

yep looking into it now I was going to have to anyways for some of my other vehicle data and for any bikes that support can bus native, thanks

JmQ

Hi @aol

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?

JmQ

hey

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.

JmQ

I'm still having trouble correctly getting data into the channel though is there a way to debug the can bus data the app received or discarded, I'm pretty sure I'm constructing the structure correctly although I'm pretty new to canbus so I'm not 100%,

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?

aol_of_RaceChrono

@JmQ

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.

JmQ

in the documentation it states

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?

aol_of_RaceChrono

The payload can be anything. It is translated to channels by equations. See equations reference: https://racechrono.com/support/equations/

JmQ

alright @aol thank you for being patient with me I get it now, the filtering sets up the time interval and id to respond too, then I just wait for my next slot and send the packed data for the next id its expecting.

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.

JmQ

and now the live data feed works that is such a good feature..

aol_of_RaceChrono

Probably RaceChrono's state machine just gets confused if you try to push data before filters are set.

JmQ

hey

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.

aol_of_RaceChrono

Weird. Try with the GPS characteristics only separately. Cannot really help much without building your device, and testing it myself.

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.

GiuseppeBinomi

@JmQ I think I had the same problem, I wrote about it somewhere in here:
https://racechrono.com/forum/discussion/1746/my-first-build-can-bus-and-gps-through-bluetooth-le
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.

JmQ

Adafruit is hard at work making PPE right now DigiKey generally have a few bits of theirs in stock, I choose this board because its ble, arduino compatible, a full 9 axis imu, plus local weather sensors. such a small package plus Qwiic connectors for I2C expansion. It's a phenomenal board really.

JmQ

@GiuseppeBinomi I'll give that a shot, I am waiting for the filter before sending the can bus packet data but I think the gps is just sending immediately should be an easy change and might be why gps was working earlier since I refactored everything after I got my can bus data working.

JmQ

Alright its all working now.

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.

aol_of_RaceChrono

@JmQ great to hear you're making progress. And yes, I love the spec sheet on that board, the display, 9DoF IMU etc. If it comes available again soon, I will use it to build the next device.

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.

JmQ

@aol I'm seeing varying update rates with both gps and canbus enabled, what determines the update rate I see in racechrono, I'm thinking about doing some caching so that the time spent doing calculation before notifying the characteristic changed are reduced. Is it better to have more ids that send smaller data packets or max out each packet and have a smaller number of individual ids?

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

aol_of_RaceChrono

You should fit as many channels to each 20 byte message (16 bytes payload in CAN-Bus API) as possible, to achieve best possible refresh rate. Also weirdly each new characteristic in "notify" state on my nRF boards seem to reduce the bandwidth on all other characteristics. This is why the second GPS characteristic is not "notify" on the current API. I wonder if it would work better to have everything on one characteristic...

JmQ

awesome I'll continue packing everything down, once I've done some test runs I can figure out exactly what data is important to me and optimize even more,

JmQ

I wonder what the max payload size is on the nRF per characteristic. quite probably struggle to encode and compress everything if its not much more than the size we already have.

I got the wiring loom all made up last night and started mounting the enclosure and ports.

aol_of_RaceChrono

RaceChrono supports 16 byte payload only, as the standard MTU size is 20 bytes. The MTU size _could_ be increased, but it would require some app side changes, and not all phones would support it.

JmQ

Additionally can we support multiple ble devices, I could make one for sending just the imu data and one for sending the gps and one for sending the bike data. Not sure of the limitations of multiple devices versus data transmission of one device.

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.

JmQ

https://github.com/johnmichaelquinlan/datalogger/tree/master/code/clue/datalogger-1.7

JmQ

@aol adafruit have clue's back in stock

aol_of_RaceChrono

@JmQ already ordered them last month, and now I'm wondering where my Digi-Key packet is as it shows already shipped month ago...

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

JmQ

yeah I was considering the Time Of Flight sensors, optical and sonar, I have an optical one I used for my custom quadrocoptor to give me landing and take off distance from ground, they even do a really nice lidar sensor now, but I can also probably use linear pots, the nice ones are expensive, but not so nice ones are cheap and I could probably hack them into a better form factor and they would also just plug right in to the HRC loom I have.

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.

JmQ

to clarify I meant tell it to start a logging session. Then I could even do mini sub sessions like if I'm with an instructor I can just start logging for my laps to save space ect?

aol_of_RaceChrono

No way currently, but if you have ideas how to do this please tell. Preferably way that works on both iOS and Android.