Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

My data collector project

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/datathing

Here'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

  • Will follow your project with interest as I'm on the lookout for similar. Subscribed to your blog.
  • Cool, thanks.

    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.
  • I am interested in such a device and will follow the development. Although my current bike (Honda SC59) does not have CAN, only K-Line...
  • I've started researching OBDII more intently. I'm going to try to implement support for at least the CAN bus versions, but I may also try to add support for ISO14230-4, which uses the K-line. One of the biggest problems I'll have adding all this stuff is finding a way to test it. I may have to pick up a OBD emulator or something.
  • aolaol
    edited September 2016
    Get a chip that does all the OBD-II protocols, if you already don't have one, possibly STN1110 for best performance? Obviously you need to test everything too.
  • That's an interesting idea. I was planning on doing it all myself on the MCU since it already has built-in CAN bus and plenty of resources. Adding the protocols is really just some coding (and testing, of course). I was shying away from adding yet another chip to the project as I was also originally shying away from adding ODBII support, but alas, ODBII certainly opens up a market if I decide to go commercial. I'll have to do more research into OBD dedicated chips. Thanks for the reference.
  • aolaol
    edited September 2016
    There's also the ELM327, but the STN1110 is cheaper, faster and better. I'm pretty sure it takes quite a lot of time to develop it by yourself! Maybe that time is away from the actual development?
  • Looking forward to the update of this project,
  • @frdfsnlght any progress?
  • @frdfsnlght I'm interested. Do you have a target date to get a step beyond prototyping. Eg. Beta testing ;-)
  • @frdfsnlght other than CAN many of your specs look like my internal project. Will pop over to your blog and do some reading. Is this going to be something you work on alone? Or is it going to be publicly available code etc?

    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
  • @J_D_W Wish to receive the continuous update of your product
  • racechrono.com/forum/profile/frdfsnlght
    Username: frdfsnlght
    Joined: July 2016
    Visits:4
    Last Active: August 2016
  • @J_D_W

    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
  • I have RFCOMM/SPP working in IDF already. I found the Arduino IDE a bit lacking and like some of the freedom of IDF (and Eclipse) vs Arduino. I was using Arduino as a component in IDF for a while but have removed that after some i2c adjustments.

    Jeff
  • Hi 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?
  • Sorry for late reply but @coxylaad I found that an Andruino Mega was not up to doing fast updates as well as GPS and BT. I got to 10/s readings of TPS plus the GPS. But trying to add more sensors I started to get into issues timing wise.

    Also I am finding RTOS much better to organize the data gathering vs the loop mechanism of Arduino

    Jeff
  • Hi,
    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
  • @TriB how fast can you get updates with KDS? If all goes well cfor next season I want to update my track bike to a bike with KDS. I read somewhere that there is a limit to how fast you can request KDS data per second. I have started to do some reading on KDS and will take a look at your GitHub

    Thanks, jeff
  • Hi 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 :D

    There are some recordings with overlay:
  • @TriB - I now have a 2009 ZX-6R track bike so I am looking into KDS and other alternatives. I wish I could get data faster than ~7 Hz. I am considering using a microcontroller and counting the signals for TPS, RPM and Gear position directly.

    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
  • Hi 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
  • @TriB I agree with the no CAN, I did some poking around as well on lines.

    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
  • Are you using ESP32 for bluetooth? With the libraries I've tried for BLE with it it's been very unstable compared to rock solid BLE with nRF52832-based boards. Interested if you have found ways to get BLE with ESP32 stable!
  • @MagnusThome I have not done anything with BLE. I was using the ESP32 BT Classic for an RFCOMM connection to RaceChrono. What are you trying to connect to with BLE? Are you using it for the RFCOMM connection to RaceChrono as well? (ie BLE and Classic BT concurrently)

    Jeff
  • I‘m fiddling with some BLE only stuff and I'm just dissapointed in the ESP32's lack of stability there. The nRF52-boards are quite a bit more expensive so if someone got BLE stable with ESP32 it would be very very interesting :-)
Sign In or Register to comment.