I'm in the process of designing/prototyping/building a new data collector for myself and thought others might be interested in what I'm doing. I've started a dev-blog:
http://frdfsnlght.wixsite.com/datathingHere's a synopsis:
I'm building this device for use on my motorcycle (Yamaha YZF-R1) for future track days. I started with the simple requirement that it must be able to tap into my bike's CAN bus, which is made readily available through a 4 pin connector under the seat. But after doing a lot more reading, realizing I'd also need some sort of GPS unit, and looking at some other available products, I added a bunch more functionality. Here's the list of features I'm targeting:
* Read/decode CAN bus regular/extended messages (needs more testing)
* Send regular/extended CAN bus messages at regular intervals (this is coming soon)
* GPS/GLONASS support, 10 Hz update rate (will be 20 Hz in the future), 167 channel, 2.5m accuracy
* 8 analog inputs with 15V/5V input range on each channel, 12 bit resolution, up to 200 Hz sample rate
* 2 digital inputs with 5V input range to measure frequency, pulse width, pulse count, etc. to microsecond accuracy
* 9DOF IMU with 3 axis accelerometer, 3 axis gyroscope, and 3 axis magnemometer
* Temperature sensor
* Lookup tables for interpolated data translation of any input
* Bluetooth and USB output of all messages (fully configurable)
* Supports naming any input and output
* Vehicle powered, including vehicle battery backed real time clock (RTC)
* Supports $RC1, $RC2, $RC3 output formats for RaceChrono use, up to 100 Hz update rate
* Desktop software for complete device configuration (Windows, Mac, Linux supported)
I'll probably add a phone app eventually for some basic configuration, control, and independent data logging.
If any of these specs look familiar, like you've seen them on other products, that's no accident. Like I've said, I've done a lot of reading and I like my home made toys to be the equivalent, or better, of existing commercial products.
I'm currently working with components on a protoboard, but most of the firmware is complete. The desktop app is also mostly complete. As I add and tweak features both firmware and software get tweaked to match. See the blog for pictures/screenshots.
I'm also in the process of finalizing a schematic and will be doing board layout soon. I'll be doing a prototype run of boards and hand assembling some units for testing and eventual personal use.
(If the mods believe any of the following to violate forum rules, feel free to remove this part; it's not my intention to piss anyone off, just share.)
It has been suggested by friends and family that I should sell this thing as a commercial product. Is there any interest in this community for such a device? Can anyone suggest other communities that might be interested? I haven't come up with a pricing model for this thing yet, or even a name, but I was hoping I could keep the retail price competitive with other products that do far less. If there's enough interest, I'd probably do a Kickstarter or something with a target of 100 units to get started. If no one wants something like this, I'll just use the prototypes for myself and keep quiet.
Comments
While subscribing to the blog gives me your email address, I don't think you automatically get notified when I post new content. I'm not sure if you're expecting that. I'm new to the blogging thing so we'll see when the next post goes out tomorrow. The main reason to subscribe is so I can send more important updates like if I ever do a kickstarter or something.
My bike doesn't have CAN as its old (2000 ZX-6R) so adding my own sensors to track things
I am working on V3 of my data logger.
V1 was simple Arduino mega based and did GPS and RC2 over BT. All I tracked in RC2 was brake on/off and throttle position (2 seasons ago) GPS was 10Hz
V2 used a Teensy 3.6. Tracked throttle, brake on/off, front suspension travel. Logged to SD card and RC3. Full IMU readings as well as yaw, pitch, roll calcs. Did GPS at 25Hz and RC3 at 50Hz because started to run out of BT bandwidth
V3 moving to FreeRTOS on ESP32 so I will have WiFi and BT capabilities. Want to add tire temp readings and add wheel speed sensors. Want to add RPM. Looking for brake pressure sensor that will fit on the bike instead of just brake on/off
GPS I use https://www.tindie.com/products/smokingresistor/venus838flpx-gps-breakout-board-50-hz-update/ with an external antenna.
Using BNO55 IMU as its onboard angle calcs removed needed processing power in my logger.
Plan to start testing soon the counter functionality of the ESP32 with the hope it will provide wheel speed and RPM capabilities. Then I want to see if I can create 3 IR sensors per module to point at the tire for IR temp readings. Better would be wireless tire pressure readings but that's on future list.
Jeff
Username: frdfsnlght
Joined: July 2016
Visits:4
Last Active: August 2016
FYI. Bluetoothserial.h library is nearly implemented in the Arduino core for ESP32. https://github.com/espressif/arduino-esp32/issues/1134
I know the Espressif IDF has advantages, but personally I'm already familiar with the Arduino IDE
Jeff
I am just starting on the same project. I was planning to use a Mega, from your experience is it not up to the job?
Also I am finding RTOS much better to organize the data gathering vs the loop mechanism of Arduino
Jeff
I´ll just link myself into this topic
For my Kawasaki Z750r (2012), I built a K-Line (KDS) compatible adapter, which "speaks" OBD II.
It was enhanced to Suzuki (SDS) for my GsxR-600 (K6), which is also ISO 14230, but a different approach to receive values like RPM, speed, gear and stuff.
This works great with RC! Custom PID´s are great to use f.e. gear, which is not available in OBD2. At first I´ve developed it to use it with my Garmin Virb XE camera, which is capable of recording GPS, G-force and OBD II. But I had to copy the videos to my pc, to see how fast/slow my turn was. Not very helpful on a racetrack
It´s not the latest version, but maybe it helps someone to create something similar:
https://github.com/HerrRiebmann/KDS2Bluetooth
Thanks, jeff
indeed you are limited by ISO 14230.
Minimum time between requests is 100ms. But there are a lot of factors involved. I reduced it to 55ms, but then the ECU will take 75ms to respond.
All in all I got it working on my Kawasaki with 120-200ms per message, which resulted overall in 7 messages per second.
The Suzuki is different, you will receive all values (RPM + Speed + Temp + Pressure + ect.) at once and you could store the request temporary. This takes longer, because the message is longer. But then you can answer the RC requests from you storage. The refresh period will remain the same, but the amount of data increases a lot.
Due to my hybrid solution (Kawa & Suzi) my µC-memory is quite at the end, but maybe I´ll optimize that further on. Winter is coming
There are some recordings with overlay:
But then was looking at the wiring diagram for the bike and there is are 2 pins of the KDS connector going to the ECU. I am wondering what the 2nd signal wire is. Also pin 17 of my dash connector is listed as "ECU Communication Pulse". No other pin is listed as gear indicator but the dash shows the gear. So I am wondering if there is a CAN or other bus happening that might provide data faster.
If all I get from KDS is 10Hz or less I think I will go directly to the signal.
Jeff
KLine always has two connectors. The other is the L-Line, which can be used for an initialization process, which I do by software (FastInit / SlowInit).
You won´t get faster over that diagnostic interface. It wasn´t made for that. Sadly
Off course it would be a possibility to "hack" to your tachometer, which receives speed, rpm, fuel, gear and stuff more or less instantly. AFAIK, you can get those signals quite easy, like 3rd party tachometers. No CAN but voltage related. I read about other Arduino projects, which cut the wires and attach a datalogger. But as far as I use my solution for the race and street legal bike, it was no option for me.
What PIN 17 does... I don´t know. I guess the error numbers have to be transferred to the dash somehow, either. Maybe there is some kind of a protocol, but not CAN.
I guess it could be a nice solution, to combine both attempts. KDS for slow things like temperature, RPM & Tacho (which let you calc the gear yourself) via tachometer.
Thomas
I don't care much about the slower stats like temp. I am more interested in RPM, Gear and TPS and I would like to get them closer to real time. I will soon be putting the bike away for winter months (so wife can have the garage when snow comes) but my current plan is to not use KDS and instead feed TPS, Gear and RPM signals into my MCU and log from the source signals.
Jeff
Jeff