99 replies to this topic

[Favs]

Break 4 

[dapleb]

Crazy Frenchman
🤣

[JBX]

Very simple program, but may be hard to understand for some mint-jelly eaters around...

[JBX]

Arduino Mega2560 arrived along with the Nikia LCD screen :

 

 

Both shipped inside a special mint-jelly protection shield...

Edited by JBX, 23 February 2018 - 01:36 am.

[Coxylaad]

great.  I am currently looking at building a unit to feed sensor data into Race Chrono for a complete android based datalogger. 

 

Using Race Chrono is great because I get to have all the polished functionality of a professional datalogger with track recognition and data analysis, all I have to do is punt a bunch of strings through the serial port to a bluetooth interface. 

 

In theory, it sounds easy!

[JBX]

Most (if not all) Android internal GPS receiver will deliver data at a 1Hz refresh rate, which is totally useless for a race track software even with a sexy display. They are also poor on precision, and not very stable.

 

You should use an external GPS receiver - designed to deliver NMEA sentences on a serial port (for Arduino, Pi, any computers with serial port). They can deliver data at up to 10Hz and are cheap too.

[fixitsan]

And you'll need to consider data parsing methods. Does Race Chrono expect all data to arrive as one packet, or can you literally send a data string at a time, randomly, , (with line breaks etc)

[James]

I thought I’d have a quick look at this thread, I keep seeing it pop up...

WTF are you guys on?

[fixitsan]

I thought I’d have a quick look at this thread, I keep seeing it pop up...

WTF are you guys on?

 

Nothing but flux fumes and silicon, officer

[JBX]

Here is a sample of a track recorded with an Android GPS at its best : speed and altitude are smooth ok, but there is not enough points to get a correct curve speed analysis, an hairpin is described with three points even at a slow, touring speed. There is also a lack of precision for the position which lead to some distance shift.

 

 

Here is a more detailed speed & altitude diagram of the same track - smooth enough : 

 

 

And here is a sample of a poor implemented Android GPS sensor : positioning precision is a mess, speed & altitude data is almost unreadable !

 

Edited by JBX, 24 February 2018 - 12:18 am.

[Coxylaad]

yes i have that in hand. I have an adafruit ultimate gps breakout board. 

my racedac will be providing that information also!

 

from the race chrono FAQ:

 

"I want to connect my DIY sensor or data source to RaceChrono, is that possible?

• Yes you can connect your DIY-devices through Bluetooth RFCOMM, with special $RC2 and $RC3 data formats. The device you need to select in RaceChrono settings is “RaceDAC” or “RaceDAC with GPS” depending if you mix $GPxxx sentences in the data stream or not. This protocol is currently supported in RaceChrono Pro for Android only, unfortunately not in iOS. This is because iOS does not support Bluetooth RFCOMM.

  Data format description (pick either $RC2 or $RC3 format, not both):
  $RC2,[time],[count],[xacc],[yacc],[zacc],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8]*checksum
  $RC3,[time],[count],[xacc],[yacc],[zacc],[gyrox],[gyroy],[gyroz],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8],[a9],[a10],[a11],[a12],[a13],[a14],[a15]*checksum

  1. $ is message start character
  2. RC2 and RC3 are message identifiers
  3a. Timestamp field is not used (empty), if your device doesn’t have GPS and does not output $GPxxx sentenced mixed with $RCx sentences
  3b. Timestamp in NMEA 0183 format if mixed output with $GPxxx sentences
  3a. Count is an overflowing line counter 0-65535
  3b. Count field is empty if if mixed output with $GPxxx sentences
  4. acc fields: -1.000 = -1G, 1.000 = +1G
  5. gyro fields: degrees per second, -1.000 = -1 deg/s, 1.000 = +1 deg/s
  6. dx are digital channel fields, range -2000000.000 – 2000000.000
  7. ax are analog channel fields, range -2000000.000 – 2000000.000
  8. * is message separator character
  9. NMEA 0183 type checksum, with two uppercase hexadecimal digits (one byte)
  10. each line is terminated with CR plus LF

  Notice: If you’re not using mixed $GPxxx sentenced, a steady update rate is needed for this format due to the algorithm that RaceChrono uses to synchronize with GPS time. So pick update rate that is close as possible to 1/5/10/20/30/40/50/100 Hz. If you have to skip an update due to data overflow, make sure you add the ‘count’ field even for the skipped updates."

[fixitsan]

 

yes i have that in hand. I have an adafruit ultimate gps breakout board. 

my racedac will be providing that information also!

 

from the race chrono FAQ:

 

"I want to connect my DIY sensor or data source to RaceChrono, is that possible?

• Yes you can connect your DIY-devices through Bluetooth RFCOMM, with special $RC2 and $RC3 data formats. The device you need to select in RaceChrono settings is “RaceDAC” or “RaceDAC with GPS” depending if you mix $GPxxx sentences in the data stream or not. This protocol is currently supported in RaceChrono Pro for Android only, unfortunately not in iOS. This is because iOS does not support Bluetooth RFCOMM.

  Data format description (pick either $RC2 or $RC3 format, not both):
  $RC2,[time],[count],[xacc],[yacc],[zacc],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8]*checksum
  $RC3,[time],[count],[xacc],[yacc],[zacc],[gyrox],[gyroy],[gyroz],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8],[a9],[a10],[a11],[a12],[a13],[a14],[a15]*checksum

  1. $ is message start character
  2. RC2 and RC3 are message identifiers
  3a. Timestamp field is not used (empty), if your device doesn’t have GPS and does not output $GPxxx sentenced mixed with $RCx sentences
  3b. Timestamp in NMEA 0183 format if mixed output with $GPxxx sentences
  3a. Count is an overflowing line counter 0-65535
  3b. Count field is empty if if mixed output with $GPxxx sentences
  4. acc fields: -1.000 = -1G, 1.000 = +1G
  5. gyro fields: degrees per second, -1.000 = -1 deg/s, 1.000 = +1 deg/s
  6. dx are digital channel fields, range -2000000.000 – 2000000.000
  7. ax are analog channel fields, range -2000000.000 – 2000000.000
  8. * is message separator character
  9. NMEA 0183 type checksum, with two uppercase hexadecimal digits (one byte)
  10. each line is terminated with CR plus LF

  Notice: If you’re not using mixed $GPxxx sentenced, a steady update rate is needed for this format due to the algorithm that RaceChrono uses to synchronize with GPS time. So pick update rate that is close as possible to 1/5/10/20/30/40/50/100 Hz. If you have to skip an update due to data overflow, make sure you add the ‘count’ field even for the skipped updates."

 

 

 

Looks fairly easy. I've got NMEA experience, the $GP sentences are bog standard, usually fixed width data fields, with padding 0's where required (almost always)

 

NMEA checksum off the top of my head was just all previous data bytes XORed together (or similar logical operator)

 

It's good that it lets you use 10Hz data rate   nice to have

 

So it looks like you need to parse the data, which in a high level language means adding data to a string (including commas), or sequentially reading data from a data structure, a simple array should do it....

 

It makes sense to synchronise everything with the arrival of GPS NMEA data....or another way is to gather all other variables before the NMEA data is passed from the GPS, and use the arrival of NMEA as the start of the transmit. (second method means that the data is 'older' but in this application it probably doesn't matter)

 

Initialise variables (array data) to nominal values

Collect data byte 1, store in array

Collect data byte 2, store in array

etc etc

etc etc

etc etc

 

Start send process:

Check  that previous data has left and line is clear to send

checksum = 0

Send header, "$"

Send "R"

Send "C", checksum = "R" XOR "C"

Send "2", checksum = checksum XOR "2"

***Start loop (for n = 0 to x?

- output array[n]

checksum = checksum XOR array[n]

- output comma

***end loop

- output checksum

- output CRLF

enter state 'wait for data'

 

 

Might work, with a wing and a prayer

Edited by fixitsan, 25 February 2018 - 05:24 pm.

[JBX]

 

Nothing but flux fumes and silicon, officer

 

Always protect your eyes from flux fumes !

 

 

 

Looks fairly easy. I've got NMEA experience, the $GP sentences are bog standard, usually fixed width data fields, with padding 0's where required (almost always)

 

NMEA checksum off the top of my head was just all previous data bytes XORed together (or similar logical operator)

 

It's good that it lets you use 10Hz data rate   nice to have

 

So it looks like you need to parse the data, which in a high level language means adding data to a string (including commas), or sequentially reading data from a data structure, a simple array should do it....

 

It makes sense to synchronise everything with the arrival of GPS NMEA data....or another way is to gather all other variables before the NMEA data is passed from the GPS, and use the arrival of NMEA as the start of the transmit. (second method means that the data is 'older' but in this application it probably doesn't matter)

 

Initialise variables (array data) to nominal values

Collect data byte 1, store in array

Collect data byte 2, store in array

etc etc

etc etc

etc etc

 

Start send process:

Check  that previous data has left and line is clear to send

checksum = 0

Send header, "$"

Send "R"

Send "C", checksum = "R" XOR "C"

Send "2", checksum = checksum XOR "2"

***Start loop (for n = 0 to x?

- output array[n]

checksum = checksum XOR array[n]

- output comma

***end loop

- output checksum

- output CRLF

enter state 'wait for data'

 

 

Might work, with a wing and a prayer

 

Complete NMEA library :

 

https://github.com/jacketizer/libnmea

... or just checksum :

 

#include <stdio.h>
#include <string.h>
int nmea0183_checksum(char *nmea_data) {
    int crc = 0;
    int i;
    // the first $ sign and the last two bytes of original CRC + the * sign
    for (i = 1; i < strlen(nmea_data) - 3; i ++) {
        crc ^= nmea_data[i];
    }
    return crc;
}
     

 

 

 

 

 

 

 

We're slightly off-topic gentlemen !

What about opening another one ?

Edited by JBX, 25 February 2018 - 07:18 pm.

[fixitsan]

 

Always protect your eyes from flux fumes !

 

 

 

That is hilarious !

 

We're a bit of topic, but we're also in danger of reinventing the wheel. I would be tempted to stop right here and scour the message boards and Arduino project forums because this stuff has almost certainly been done before.

 

On the other hand - for a cheap accelerometer and gyro I can recommend the MPU6050. Dirt cheap and with inbuilt low pass filtering, no need to worry too much about jitter because it isn't being used for dead reckoning in this application. The downside is the need for a second serial port because the interface is  I2C flavoured

[Rallyist]

Ouch

[Nog]

I was thinking of an Arduino project some time ago so was watching this closely but I've actually been wondering if it's possible to wire in an OBD dongle that can be used with my Torque App on my phone?

 

Recently seeing the Hollywood update on the ECU reader, it taps into the data ports on the ECU wired through the K-link ODB plug.  So I'm wondering if all this data could be got via a phone and no need for the Arduino?

 

Still good too see the Arduino taking shape though, would be good to have a dedicated fitted readout regardless.

[fixitsan]

I was thinking of an Arduino project some time ago so was watching this closely but I've actually been wondering if it's possible to wire in an OBD dongle that can be used with my Torque App on my phone?

 

Recently seeing the Hollywood update on the ECU reader, it taps into the data ports on the ECU wired through the K-link ODB plug.  So I'm wondering if all this data could be got via a phone and no need for the Arduino?

 

Still good too see the Arduino taking shape though, would be good to have a dedicated fitted readout regardless.

 

I have read that the Yamaha FI software (dealerships only) can read OBD parameters, live.

 

I haven't looked into it further, the very least we would need to do is bribe a trained Yamaha tech !

[JBX]

Just a reminder, OBD standard includes :

- hardware specification : the OBD plug

- electrical specification : the voltage for 0 & 1 logical levels

- protocol specification (the language) : CAN bus / ISO 9141, etc...

 

Yamaha's bikes don't use OBD hardware, electrical nor protocol specifications :

- no plug

- voltage is 0V for 0 and +5V for 1

- protocol is manufacturer's specific.

 

The problem with using (after deciphering) the Yamaha protocol is that you can't have the DIAG mode (reading the sensors and activating the actuators) and the engine running at the same time, because it interfere at the actuators functions.

Only the CO mode allows the engine to run.

 

That's why I found easier to get the data directly from the sensor, and also compute the fuel consumption from the injector pulse frequency & width

 

The fuel consumption data is not present on the Yamaha's line, neither is it on the standard OBD data. Therefore the fuel consumption on OBD softwares and oem dash computers is derived from various other sensor data and very very rarely correct !

Edited by JBX, 28 February 2018 - 01:03 am.

[JBX]

 

I have read that the Yamaha FI software (dealerships only) can read OBD parameters, live.

 

I haven't looked into it further, the very least we would need to do is bribe a trained Yamaha tech !

 

This tool works on some fuel injection Yamaha's bike (WR450 / ybr-ys250 / xtz250 / XT660, etc and some ATV) that don't have the DIAG & CO modes available on the dash like our beloved 9er.

 

It needs to be connected on a special plug on the bike and then provides the DIAG & CO modes and the rpm on the tool screen.

 

Edited by JBX, 28 February 2018 - 08:33 am.

[fixitsan]

 

This tool works on some fuel injection Yamaha's bike (WR450 / ybr-ys250 / xtz250 / XT660, etc and some ATV) that don't have the DIAG & CO modes available on the dash like our beloved 9er.

 

It needs to be connected on a special plug on the bike and then provides the DIAG & CO modes and the rpm on the tool screen.

 

 

Just another method for adjusting and monitoring DIAG and CO parameters then

Edited by fixitsan, 28 February 2018 - 09:09 am.