Design and Construction of a Data Logging System

[Caito]

Hi guys, as you may already know from another post, together with a friend I'll be designing and building a data logging system as a final thesis for my degree in electronics engineering.

The idea is to detail (or at least try to) the design and construcion process in this thread. The whole process is at least a year in length as it goes hand in hand with a year-long subject.

At the moment we're defining the basic specifications. Is in this part that I think the forum can be more useful since there's a lot of people who have actual experience working with data logging systems.

We're trying to develop a data logging system with a similar to entry level price(1000usd?) but with good characteristics.. not just 4 inputs.

The specifications can be divided in two parts:
Hardware, all the inputs and connectivity
Software, all the data analysis and nice looking program


Hardware wise, this is what we're thinking of at the moment:
Inputs:
At least 8 analog voltage inputs.
4 digital input.
2 thermocouple inputs
Lambda sensor input
Plausible:
Can connection
Other temperature input(resistive sensors)

Outputs:
2 programmable digital ouputs
5v stabilized ouput for pots and such.

The system will have integrated GPS(looking for at least 10Hz), 3 axis gyro and 3 axis accel. This are integrated because you can get a good 3axis gyro+accel for less than 10usd and it adds a lot of value, whereas if you go and buy that it will cost a fortune. Same applies to the gps.

Sampling frequency up to 1Khz. We're debating over SD card or integrated memory. Possibility of bluetooth download of data.


What do you think? Is there something you would add? Is there something that you don't think will be as useful? For example the CAN connectivity.

What's your regulat data logging set-up, how many sensors (and which) do you normally use?


Thanks!

Caito.-

[netoperek]

Since You'll make it on at least one uC, add much more digital inputs, as they cost You almost nothing, You want to aim for accuracy, so use good, dedicated ADC chips with temperature compensation for analog inputs. Obviously, You'll need a decent power supply design also. 1 kHz isn't much for such system, try making configurable data sampling for each channel (group of channels), preferably on a same, multiplied time base (easier to implement efficiently).
Such devices aren't usually used in strictly laboratory conditions, so apply as many safety features (e.g. optocoupling on digital inputs, short circuit protection) and noise protection as possible. Precise timing is also top priority.
First concentrate on all data logging essentials, before adding features like GPS or Bluetooth, as You may have problems locating noise sources if You build it all at once. Making it a modular design is also a good way to go.

Anyway, good luck

[Jersey Tom]

CAN is quite nice.. but if you're aiming this as an "entry level" type thing for a club racer, I would guess they would be more inclined to do a simple wiring harness with conventional inputs.

Is this just going to be a data logger or dash / display as well? If the latter, might be worth having the IMU (tri-ax accel, etc) as a separate unit so you can place it in a good spot, and then have the display in a high visibility area.

I'll admit Bluetooth download would be pretty tight. More "average Joe" laptops these days probably have that integrated, more so than SD card readers anyway.

Ultimately the thing to do is just be careful not to bite off more than you can chew. Maybe you could take a decision matrix approach in the initial spec and find the best compromise of features.

[andylaurence]

Entry level might be about to drop in price again thanks to Race Capture Pro. For me, the following is the sensors that I find most important:

Critical
GPS (Speed/position)
RPM
Lateral/longitudinal G

Really Useful
Wheel speeds
Steering angle
Brake pedal pressure
Throttle position
Gear (can be derived from RPM/wheel speed)

Handy
ECU interface (mine's TTL serial and needs initialising)
Damper position

There's other things that'd be useful like Bluetooth download and/or telemetry. Above all, the software for analysis must be robust and easy to use. Maths channels must be easy to create and graphs easy to manipulate. The UI is king here.

[marcush.]

I´m by no means an electronics guy but isn´t it just reality every car todays uses a myriad of sensors can ,flexray,lin and what have you bus systems and basically all the data is there and you´d be dumb not to make use of all the pressures ,steering angles and what have you if it´s already available on a data bus ready to be used by your DA system?
to me a single CAN input seems not enough considering the average car already has powertrain on a separate bus.Sure it is some effort to decipher all the signals but it saves a whole lot of hassle in terms of wire,connectors and sensors as you can use what´s already there.The basic idea will readily transfer to a dedicated race car system -I´d think not many sensors are routed directly to the logger these days ....and such a decentral system does make it a very scaleable solution as well .you can start small and add boxes as your demands grow and recources allow without throwing away anything you have bought on your way .

[Jersey Tom]

I´m by no means an electronics guy but isn´t it just reality every car todays uses a myriad of sensors can ,flexray,lin and what have you bus systems and basically all the data is there and you´d be dumb not to make use of all the pressures ,steering angles and what have you if it´s already available on a data bus ready to be used by your DA system?

On a road car? Yeah there are sensors galore. On a purpose built racecar (even an open wheel SCCA car or something)? Not so much. Besides that.. to make use of CAN sensors in a road car I think you need to know some specific information from the OEM to get at the data and know what it is.

But I'm not much of an electronics guy either

[Tim.Wright]

If you dont have the can protocol of a specific car then you cant read anything. Also the onboard sensors are often not so great and are often lower resolution than what you would read on a normal data acquisition system. Ive seen one car which had the can steering sensor with an offet of 12 deg.

[marcush.]

All cars have OBD todays and you get the connectors and software for it for small money with all readouts and analysing capability-
VCDS is one of the better and more expensive ones..I connot imagine the can protocol information is too hard to get ...
As far as I understand a lot of sensors in use on todays cars are not only cheap but also very robust and precise as they have to be .

as for dedicated race cars -not so many around I imagine ,compared to logger suppliers - the CAN also approach will allow you to integrate the system cheaply into a road car (many potential customers!) but it will not be a drawback to have on a race only car.

if interested look this up:

http://www.kvaser.com/zh/about-can/the- ... tocol.html

[Caito]

Thank you for all your answers.

Since You'll make it on at least one uC....

Neo, you have to see how the industry works.. they charge you hundreds for absolutely everything, you can get charged 100, 200usd for a couple more inputs. Just because you have them, doesn't mean you have to provide them just for the sake of it. GPS is something that is really needed(almost exluding) which I can provide for the fraction of the cost. We are also doing this as a subject so if we say we'll add a lot of digital inputs, then we actually have to do it to pass the subject.. so we're trying not to overload it with things we will not be able to do, when other things are mor important.

We are aiming for multichannel ADC chips.. 8(or more) channels, 10bit. We'll see how many of this we use. 1Khz is not much for electronics system.. but it's already a lot for the frequencies involved in a car. Remember I only need to sample( ideally) at twice the maximum frequency.
Safety features is something we will definitely work on to avoid "one error, no more data logger" type of situations.

As for testing.. we'll work our way up. Most probably we will buy the ADC and test the anti-alias and sampling frequency required (we'll probably need some digital filter). A 10 bit system has a 62dB noise floor.. we are definitely not making 62dB filters. So we'll have to do a simple analog filter, over sample and then apply a digital filter. This is a very critical problem since it defines the quality of all analog inputs. I'm not sure how it's done in other loggers, but probably it's something similar, I have read some Motec just have 150Hz 1st order filters which is definitely not enough.. but don't know how noisy the environment is(maybe it's just high frequency noise). Once that problem is solved, we'll focus on the next one and so on.

CAN is quite nice.. but if you're ...

We'll probably dismiss CAN to focus on other stuff we could improve. Though it's a nice feature to have, it's not paramount (but it avoids some repeated sensors). It will have no display at all.
The bluetooth would be something that would seperate us from the rest, and it could be quite simple, we're researching about that.

This post is in part to know the weights of features for a decision matrix. But since we have no actual experience using this (excluding rfactor) we need to talk to people who use it.

<span>Entry level might be about to..

Though race capture pro seems like a nice entry level option, there are several things I don't like. It's not simple enough for the guy who knows no electronics at all. You need to build your own pull up resistor for resistive temperature sensors. It has no thermocouple inputs. The input/output connector is really bad. If you need to take the logger and put it in another car you have to unscrew every single wire and then who know which one is which. I'd prefer one big large connector.
Calibration is vague.. only 5 point curves, which you can't acquire online. I'd like to say "get current data" that's 5mm... "get current data" that's 10 mm and so on.

As for the inputs, I agree with you. ECU interface is CAN, and the inputs you have listed are analog or digital, bar the gps and accelerometers.
Telemetry is exluded from the project. Mixing something that's not top level with telemetry doesn't seem like a good idea at the beginning and it's mostly prohibited.

Totally agree with you with the software stuff. It's what makes the whole data useful. We'll try to build something modular (drag and drop graph, bars, dials, etc) but it's something we'll focus on later on.

Our basic approach is to have something simple, basically plug and play, get the sensors connect them and use it. If you need to be an engineer to use it, we have done something wrong.

I´m by no means an electronics guy bu...

Racing cars of people who work with lower budgets don't have all that technology and sensors. Even lot's of categories here still use careburetor. Though if you have fuel injection having to get another crank sensor for RPM is annoying when you already have one and could be provided via CAN. We're focusing on race cars for the moment, but it would be essential if we weren't.

Thinkg of the average joe racer who wants to improve his car/driving. You'd get the system get the most important sensors( gps, accel, steer, throttle, brake, rpm) and you could already do a lot with that.. that means buying the logger and a crank sensor, two linear pots, and one rotary pot for the steering. Of course you can get into more complicated stuff getting damper position, wheel speeds, etc etc. Thermocouples go around for a couple of usd.. so you could add some into the engine (thermal protection) or brake discs.

The possibilities are endless.

Caito.-

[andylaurence]

This sounds interesting. Will you actually market this device or is it just for the thesis? At the price point you're looking at, I'd buy a DL1 from Race Technology.

[Caito]

This sounds interesting. Will you actually market this device or is it just for the thesis? At the price point you're looking at, I'd buy a DL1 from Race Technology.

It's for a thesis but we're aiming on making it available. That is, all the design process will be made as if it were to be sold, which is the idea. If we eventually sell it, It's too early to tell.

Good to know about the DL1. We'll probably be offering something similar, much higher sample frequency, similar amount of inputs but with added temperature inputs. Probably a little bit better, at least hardware-wise.

[netoperek]

you have to see how the industry works.. they charge you hundreds for absolutely everything, you can get charged 100, 200usd for a couple more inputs.

That was exactly my point.

I don't really know how racing enviroment works in that matters, but I guess 10 bits ain't that much for a logger, as it isn't in industry. Especially if it isn't true 10 bit ADC, e.g. oversampled few bits sigma delta ADC, but I suspect You were not planning to use those anyway
Proper data aquisition, especially analog data can be really challenging, that's why I suggested, to start at this point, evaluate it and start adding features after that.
But filtering the signal isn't Your only concern here. Scaling of signals is another tricky thing, so I guess it should be considered during developing feature list.
And don't be so enthusiastic about thermocouple price tags... Cheapest one's are slow and quite innacurate and You should always use compensation cable for them, which isn't that cheap either.

[andylaurence]

This sounds interesting. Will you actually market this device or is it just for the thesis? At the price point you're looking at, I'd buy a DL1 from Race Technology.

It's for a thesis but we're aiming on making it available. That is, all the design process will be made as if it were to be sold, which is the idea. If we eventually sell it, It's too early to tell.

Good to know about the DL1. We'll probably be offering something similar, much higher sample frequency, similar amount of inputs but with added temperature inputs. Probably a little bit better, at least hardware-wise.

Keep us posted. My data logger failed to log any data on Sunday, so I'm looking at bringing my upgrade forwards. My next logger will have all the inputs I've noted as Critical and Really Useful, plus more analogue inputs for other uses as I see fit. The RaceCapture Pro seems to fit my needs nicely and being really cheap is a bonus. If they were available to purchase now, I'd have one on order.

[Caito]

you have to see how the industry works.. they charge you hundreds for absolutely everything, you can get charged 100, 200usd for a couple more inputs.

That was exactly my point.

I don't really know how racing enviroment works in that matters, but I guess 10 bits ain't that much for a logger, as it isn't in industry. Especially if it isn't true 10 bit ADC, e.g. oversampled few bits sigma delta ADC, but I suspect You were not planning to use those anyway
Proper data aquisition, especially analog data can be really challenging, that's why I suggested, to start at this point, evaluate it and start adding features after that.
But filtering the signal isn't Your only concern here. Scaling of signals is another tricky thing, so I guess it should be considered during developing feature list.
And don't be so enthusiastic about thermocouple price tags... Cheapest one's are slow and quite innacurate and You should always use compensation cable for them, which isn't that cheap either.

Most sensors have a 5v output, or have already an amplifier, or are potentiometric. Given the market signal scaling is not the biggest of problems as to justify having programmable gain amplifiers and that kind of stuff.

Thermocouples are cheap compared to a 150usd accelerometer.. or 250usd to upgrade a gps from 10 to 20hz. They even charge you 50usd for a water temp sensor which is a simple variable resistor.

[Caito]

Long time no see! But I'm back. Truth is this was abandoned for a while but was refreshed a month ago. I was busy with all the coursework, which is now finished. I only need to finish this thesis to become an electronic engineer . While I do this with a couple of friends I'm also working with power inverters and FPGA control.
Completion date is for early august, late july.

We've chosen ATMEL for the project. In the university we always worked with freescale and wanted to change. Atmel Studio seemed nice plus they also give you lots of drivers (which work after some fight), documentation is good on the hardware, but not on the software they give you. The elected one is a SAM4S(Cortex M4). We're developing on a SAM4S Xplained Pro board (http://www.atmel.com/tools/atsam4s-xpro.aspx). One of the reasons is it has a nice amount of 12bit ADC's, SD card interface, it's fast, lots of GPIO, UART,SPI,TWI, etc.

Final specs are more or less as follow:
-20Hz GPS (working over UART)
-100Hz Z axis gyro (TWI)
-100Hz X and Y axis accel (TWI)
-8 analog channels at 1kHz
-4 digital channels at 100Hz (they're mostly switches and so on.)
-2 programmable digitable outputs, current limited (5A), overtemp limited, shortcut protected, etc. It's a lowside switch.
-SD Card interface with FAT File System.

Currently the digital inputs are not suited for Frequency/Period measurement. That's something we will be missing. As it's still an "entry-level 1000usd-ish" datalogger, getting speed from the GPS should be enough. Logging RPM would be nice, though. There are still lots of RPM to Voltage and one can use an analog channel.

Everything is working at 3.3V so we might use 3.3V as a regulated output or go with a more standard 5V and then adjust levels to 3.3V for the adc.

At the moment we have all the drivers for the GPS, Accel, Gyro, ADC, FAT and SD working.

One of the ADC channels will have a resistor divider as it's used specifically to measure battery voltage.
Probably two of the ADC channel will have a pullup resistor for usage with a Pt1000 RTD.


More to come as we keep on making progress with the project.

Of course, any suggestion is welcomed. Bear in mind this is a prototype and we're limiting lots of stuff.


Bye,

Caito.-