Powerboat racing telemetry. First steps taken, many to go. Support appreciated.

The project is an attempt to build a low-cost, high learning curve, open source, many involved, great exposure of an idea to reality by self development rather than buy off the shelf. The team (powerboat youth racing team) races and is succesful in doing so. Most sponsor funds go into the hardware, travel and such cost. Little left for R&D (as usual). Yet, the step to a higher class requires more data acquisition and analyzing to allow for a smart development to go faster.

Some information: speeds exceed 100KMH, distance to shore up to 5000m, boat bounces 3D, Engine can be trimmed, steering wheel angles the whole engine (outboard) and the pilot is in a somehwat closed cabin.

The project steps:

basis: Arduino Mega (got it)
first step: GPS data logger to SD card (got it, GPS shield from iteadstudio)
next step: add sensors such as:
axis, angle of the boat
accelleration in various directions
position of engine trimmer
position of steering wheel
and then: send the whole data everytime the boat gets in range of the base (pitlane)

Status:
Got the GPS data logger working. Data also used for plotting on a map.
Combination of GPS data and a temp/humid sensor also worked. Though not in the way I want:

Wants/needs:
Early in the project I'd like to have a datalog file that starts with the timestamp and then a lot of columns with sensor data. Simply because I think that's the easiest to analyse in various common software like excel and to convert to anything needed for other software.
My thought is that when a sensor is added, the datalog simply gets an additional column.

That requires a smart way to construct the sketch and there I haven't started yet.

What I'd like is to build a prototype with simple software that does the above. With this proof of concept I can ask the sponsors for funds to have a professional programmer redo the software to make it smaller, faster, more reliable and so on.

My question to you: any thoughts, tips, links, or even programming skills to help out. In return of course you'll feel as proud as I am to get it all to work and to support this program to bring up young people to higher levels. And your name on the boat, if you like

and then: send the whole data everytime the boat gets in range of the base (pitlane)

You can certainly do this, but do you really have any use for the data (with the possible exception of the engine trimmer) during the race?

yes, the pilot is experienced but can (and is allowed) to be coached over the radio.

it helps if the pitlane can start analyzing during the preparation for the race and the race itself. Now the pilot has to scream a lot of basic info over the radio, have that data already there helps as the talks can be focused on what both parties know.

Also the boat can turn upside down (not intentionally of course) and having the data safely off the boat can be useful (esp. axis, leveling, what happened just before....)

And finally, an idea is to filter some data and put it on the team's website for increasing it's news value

Theoretically it is allowed to adjust the trim automatically during the race. This is not the aim of this project though. But perhaps it's good to mention here if this has certain impact on the structure of the software.

Here some thoughts of logging and adding sensors. First, a more common file type that works with Excel is called CSV and it is easily done with the SDFat library. If I knew for example that in the future I wanted to have 10 sensors but, I only have 3 and a time stamp, I would print to my file like this 10.00.03AM,S1,S2,S3,0,0,0,0,0,0,0;. The next sensor S4, would replace an saved "0" and your download would always contain the same number of values.

If you are having trouble with your GPS data, post what you have so far and we will try to help.

Good plan. that would make a future proof excel script (or other analysis tools) much more worthwile.
So there needs to be some logic to putting the datafile together.

The GPS datas now contains a lot of ....errr... data. The NMEA string seems too much for our purpose.
Not all is needed (like how many satellites there are/are used and such). It does contain (calculated) speed and we may have to go with that as a boat does not have another type of speed measuring (we also need something for lap times).

Question is then, where/when to process the data: before writing the log file (reduce the gps nmea data to only the needed) or just write it all and have the laptop filter it later. My preference would be to have it done at the source by a smart schetch rather than having to work too much with excel scripts.
On the other hand: collect all and disregard later may be smarter for later analysis data needs. But will this slow down the program too much?

So the structure would be:
[timestamp (can this be picked off the GPS datastream?)][location data][sensor1][sensor2] etc.

question:
currently the gps data is written every second or so. (sketch that does that at bottom of this post)

Is my understanding correct that the (final, to be made) sktech will get-process-write (add to) the datalog file and then do the same for the next sensor and then for the next sensor and so on? Or does it gather all data at timestamp x and then write the whole line to the file?
Reason for the question: will the GPS location log frequency become lower as we add sensors.

If it does, the sketch should give some priority to the various sensors. For example: engine temperature does not need to be measured every time, trim position similar.

In the end the more dense the location records, the better.

Oh, something I learned from the first walkabout with the unit in hand: when the GPS data is writen very often but the unit is stationary: this may bloat the datafile. Should a mechanism that checks for changes (and if none, don't write) be included? If the only thing that changes is the timestamp, there's no point in filling the datafile. Might enable us to leave the unit on the whole time (before and after the actual run there's always a lot of waiting) and not have to add a startlog/stoplog button or so in the cockpit.

Sketch that came with the GPS logger:

#include <SD.h>
const int chipSelect = 10;
void setup()
{
Serial.begin(9600);

pinMode(10, OUTPUT);
if (!SD.begin(chipSelect)) {

return;
}

}

void loop()
{
// make a string for assembling the data to log:
char index = 0;
char temp = 0;
String dataString = "";
// open the file. note that only one file can be open at a time,
// so you have to close this one before opening another.
/*
while(Serial.available())
{
File dataFile = SD.open("datalog.txt", FILE_WRITE);
if(dataFile)
{
temp = Serial.read();
dataString += String(temp);
dataFile.print(dataString);
dataString = "";
dataFile.close();
}
}
*/
File dataFile = SD.open("datalog.txt", FILE_WRITE);
if(dataFile)
{
while(Serial.available())
{
temp = Serial.read();
dataString += String(temp);
index++;
if(index>200)
break;
}
dataFile.print(dataString);
dataFile.close();
}
}

END of Sketch.

I recommend the TinyGPS library. I think it can be found at Adafruit's site. I am sure google will find it also.
With that library and some work you can narrow down the GPS info to what you find useful and it will be in easy to understand units.

I would recommend a RTC real time clock for your time stamp. It will be accurate an reliable.

Some of the better affordable GPS modules only refresh at 10Hz. Your Arduino can do a lot of things while it waits for more GPS data. There is nothing wrong with storing unchanged values in a string if some of the values are new. Such as, the GPS might be unchanged but, sensor 1 and 5 may have new data. If you have a decent memory card, the storage is free. Kind of like a digital camera, take lots of photos keep only the ones you want, costs the same.

Another note, the GPS module will show some movement even when sitting still it is the nature of the beast.

http://arduino.cc/forum/index.php/topic,91046.0.html

New TinyGPS release

found it, thanks! That should simplify things.

I'll try to figure out what rate the GPS is capable of logging.

Thanks for all info till now. Still labouring on getting things together. Learning about interrupts, delays and such to find the way to prioritise the data gathering.

Current challenge is how to set a couple of variables from hardware settings that cannot be read automatically.

There are 4 variables that remain constant during the period the logging will take place. But these can only be given through a button or knob. Easy if it were only one but there are up to 10 possibles per variable.

Ideal would be four multi-position rotary knobs that click into each position. Each position being read at the start of the logging (they remain constant anyway) or the other way round: they are all read once when they change or a button is pressed.

Practically this is the situation:
engine mount position (one of the 5 slots)
fuel tank position (one of ten slots)
propeller type chosen (one of 10 types)
more..

All this is set at the back of the hull. Position everything, set the knobs in the corresponding positions and off we go for the next round.
come back, change a (or more) positions, set the knobs (perhaps kick a switch (interrupt, no reason to wait for this button all the time) to tell the program to read the settings), off again for a next round.
Log the values at the beginning of the next log or better, in the CSV format.

measuring the positions automatically is almost impossible within reason. So I'm looking for a way to get these settings into the log-file because the other option is to add it later to the log file and that is a big room for errors.

Ideal would be to start it up in the morning and extract the logs of all runs at the end of the day.

If one has GPS, why would an RTC be needed?

Take time from GPS at the start to set it throughout the sketch. If GPS is out (malfunction) the rest should keep on logging happily untill it drowns (literally)

I need a pot meter that clicks in positions. Every position a different resistance value that arduino corresponds to a setting. Like this one used for audio. What is this called in electronic speak so i can search for a cheap version?

Oh, something I learned from the first walkabout with the unit in hand: when the GPS data is writen very often but the unit is stationary: this may bloat the datafile. Should a mechanism that checks for changes (and if none, don't write) be included? If the only thing that changes is the timestamp, there's no point in filling the datafile. Might enable us to leave the unit on the whole time (before and after the actual run there's always a lot of waiting) and not have to add a startlog/stoplog button or so in the cockpit.

Can you use speed from the GPS for this? If speed rises above some limit for a few seconds, start recording. If it falls below another (lower?) limit for a minute or so, stop recording.

I don't know anything about power boat racing except that it sounds fun, and expensive. But in some respects it seems similar to motorsport. There are some data logging solutions there that have a significant cost, but you're talking hundreds rather than thousands of quid. The ones we use are from Racetech. We use them to police power levels by monitoring each vehicles acceleration performance through each race, and they also support a considerable amount of post-race analysis. The software is quite cute and will work out the shape of a closed course and calculate arbitrary split times for you based on the GPS positioning, and it can take inputs for throttle, steering, perhaps trims and so on so that if you wanted, you can work out what you did right and wrong. The positioning works very well on cars and can, for example, pick up a lane change type manoeuvre. I don't know how well the GPS would work on a vehicle that was pitching and rolling violently, but I suspect that a call to Racetech or similar would tell you.

I do my videos separately, but Racetech do also provide video logging so that you can automatically record various video streams and edit them up with data logging overlays and picture-in-picture type of effect to produce a very interesting video. This sort of thing might be invaluable to get potential sponsors interested, and as well as entertaining them you can show them how professional you are and how serious you are about performance analysis and self improvement.

Pot with discrete stops is called Detent or Detents.

Here's an example

Remarkable how difficult simple things can get. I'm trying to translate the product I need to something that shops use to describe it

If found two things:

Turning knob with a lot of pins, a pin selector. This plus a bucket of resistors and I can make every selection give a different voltage. Thus letting one Arduino pin listen to that and decide what variable to use.
Put that into one housing and it's called a.... detented potentiometer. (correct?)
Or perhaps better said: take a potentiometer, add a bunch of notches to the axis/knob and it will have a certain resistance at every position. Where the detent are the notches that you feel when you turn. and it should have those positions numbered around the knob.
Bloody simple, used in handsfull in every cockpit but I just haven't found a low-cost, simple product from a shop that will not take weeks to get it to me.

I'll call some shops in the region to get the Dutch name for it. And perhaps even the whole item.

The idea is to have four selectors that each use one pin on the Arduino.

However.. I found something called 'digital potentiometer' Could that be a way to connect them all to ONE pin? Sounds like lots of code to decipher the digital signal but perhaps I'm wrong with that fear?

@PeterH thanks for the information. I've found a company (link) that you probably mean. Adding up a few items brings me to 1000 pounds in a second. That's way too much for our current situation. Also, it would take out a lot of tinkering and thinking for the team to learn from why, what and how of telemetry and using it to go faster. Pay, plug and play is not quite the aim of this game.

@WildBill: yes, that is a good idea. Perhaps it's possible to create a small circle the GPS can move in without triggering the logging. Perhaps add input from the gyro or engine start. The boat is lifted out of the water after almost every run. The engine is started at the beginning of every run. But also shut down before the actual race runs. So perhaps engine start, starts the logging. Engine stop does not stop it immediately.
A switch in the cockpit would be possible but a possible source of error: stressfull times at the start so forgetting to flip it is easy.

I think you are referring to a stepped attenuator, which is a switchable resistor ladder, often used in high-end audio systems.

Frank,

Dutch word is "draai schakelaar 1/12"
Conrad.nl search on it! 3 Euro and on stock.
Use one of the analog ports for these selectors. With 10 differrent resistors you make a ladder and each step will give a analog value.
There are even resistor ladders ready to go.
With the skech you determen which step of the analog selector step is which setting 1 to 10.

If I can assist let me know by PM in Dutch.

Also make an update list which ports and functions of the UNO you currently use.

A switch in the cockpit would be possible but a possible source of error: stressfull times at the start so forgetting to flip it is easy.

Make an optical beam sensor. No driver is no data recording. In case the boat flips and he is thrown out then data recording also stops that is a downside of it.

Paco

I have done some more thinking on this project.

For the 5 or more fixed values.
Use an I2C 4 x20 display with 5 pushbuttons (joystick).
This will take 3 analog ports (if you have them left over)
Display and button at the rear of the boat where the engineer does his adjustments.
When finished it, is his duty to set the correct settings with the buttons and display.
As soon as recording is started by the driver going into his seat this data is recorded too.
Display info:
prop 09 fuelmix 10
tilt 07 optional 00
camber 03 optional 00
caster 01 optional 00

Does the engine has and ECU output?
In that case engine data could be stored by OBD to the SD card too like RPM.
I would not mind start and stop for fixed data.
Just record all of it with a 20 ms timestamp, it are all just bits and bytes and to fill up 32 Gb with a refreshrate of 20 ms would be no problem to record a race if I am not mistaken.
After the race like you said work over the data in excel or an other purposed written program.

Paco

Thanks for the thinking and sharing.

The 12 position switch plus bunch of resistors (or stepped array, even better) is indeed the functionality that I am considering as the best solution. I understand that this may be used in electric guitars.

For the prototype we can probably get acceptable results with simple potmeters with a button that has an arrow plus a dial with some numbers. Set them to the value needed, push a button for the intterrupt and changes untill the next push on the button are not used anyway. Check and set each pot after every change is a simple procedure. As long as the button does not cause an interrupt by itself it should be allright. In the actual situation, all settings can be visually checked quickly anyway. There are no changes made that are hidden under covers of the hull.

Thanks for the name dwx00d, I'll continue my search with those terms. Bit big first find even diy kits (wow

here's a smarter solution using a pcb:

bottom of the page, so audio business is where they are

The engine does have some ECU output but we don't know much about it. It is not sure yet if it is standard (somewhat) OBD or something proprietary. The small display that comes with it shows various data and steps through them, don't know yet what is done to decipher the incoming data to those values. Will take some time and equipment to figure that out.

Start/stop is indeed no big issue, but it may be usefull to avoid filling a datafile with loads and loads of almost identical data (GPS always changes somewhat). Instead of having to chop it up later.

I like the idea of a display and such. I also know the mechanics though...... analog, arrows, button = their world displays, cursor, push up/down = ouch!