Accelerometers - measuring 1/4 mile time and interfacing to PC

[blahblah99]

I would like to use an accelerometer to measure the 1/4 mile time of a car using a micro-controller to measure the outputs of the accelerometer, similar to what G-Tech is doing.

Now here's the problem:

1) I can either do all the calculations on the micro-controller and send out the total time on a few 8-segment displays.
The problem with doing it this way is the mcu is only 8-bit (can't afford the 16-bit development kit for other mcu's) so computation is going to be intensive, plus the mcu doesn't have much ram to hold the data... and that means I'd have to integrate each data point as it is being received. Doing it this way means no bulky laptop in the car = standalone system.


2) Send the data to the PC and let the PC (via serial port or parallel port) and let the PC do the processing.

If I choose this approach, I have to send both the sample data and the sample count to the PC via the parallel (serial is just too slow unless I sample data at a slower rate), and parallel ports arepain in the arse to work with! However the payoff is that you can store all the data into memory and process it later, get nice graphs of your acceleration, velocity, and time. Basically, unlimited computing power.

3) Any other ideas?

Also, the accelerometer I am using is the ADXL202 from Analog Devices and that outputs the g in PWM format, so timing is a critical issue. Are there other accelerometers out there that are available in a kit?

 

[Moohooya]

Just questions, no answers yet

How many data points are you talking about?
I'm surprised that you think a 16 bit micro controller is too expensive, what price range do you have here?
The serial port too slow? What speed do you need?

 

[Mark R]

This calculation should be well within the capabilities of a low-end microcontroller like a PIC16 - you will need some clever algorithms, such a device lacks the brute force to make up for poorly developed and inefficient algorithms.

For example, I wouldn't have thought it necessary to sample the acceleration more frequently than every 10-20 ms. There is no need to store the data points, you can integrate the data as you go along; If you calibrate the device by driving, then you have no need to use recognised units internally - therefore there is no need for any data conversion.

An alternative option, is to use the MCU to sample the data from the accelerometer, and output it in byte format to a serial port - 2400 bps will be quite sufficient.

 

[blahblah99]

Originally posted by: Moohooya
Just questions, no answers yet

How many data points are you talking about?
I'm surprised that you think a 16 bit micro controller is too expensive, what price range do you have here?
The serial port too slow? What speed do you need?

Data points: Depends on what my sampling rate is... If I sample every 5 ms, and assuming that the car takes less than 30 seconds to go 1/4 mile, then I'd have 5*200*30 = 30,000 data points.

16bit microcontrollers: Which microcontrollers and its development kit are cheap? I'm looking at less than $100 for the development kit and less than $6 for each microcontroller. What I mean by 16bit is it needs to have a 16-bit timer. It also has to be in a DIP package. I hate dealing with SMT

Serial port: Even if I send data through serial port at 57600bps, that means it'll take 0.173ms per byte. If I send out a 16bits, that takes 0.347ms. I'll probably need to be sending at least 4-6 bytes of data per sample.

Also, I will need to make sure I do all the data processing within a period of time as I don't want to miss the next cycle of data the accelerometer outputs.

 

[Moohooya]

30,000 data points is alot. I don't believe you'll find a cheap microcontroller that will handle that volume of information. You said 5*200*30. Where did the 5 come from? If you cat this down to 200*30, 6000 samples, you can now fit it in a number of different microcontrollers. Typically they come with 4K-16K. As much as 64 is available, but to address more than that you'll need more than 16 address bits and now you are in a new price range I believe.

I'm confussed. You talk about less than $6 per microcontroller, so I assume many. However, you also talk about a PC, so I initially thought just a single custom board. Is this for 1 car, or are you going to build a bunch?

If you do use a serial port, you should be able to do MUCH better than 4-6 bytes of data per sample. I'm not sure what you are sending, but I bet there is some simple way to compress it. Compression does not have to be hard, especially as you fully understand you domain. I'd imagine the acceleration between one sample and the next will be very similar. So send an 8 bit signed difference from the last sample if your samples are 16 bits. I'd bet with such a high sample rate, you could cut it down from that even, maybe down to 2 4 bit differences in 1 byte. If you exceede the 8 bits, send 80h, or some predefined number, that means a 16 bit value follows. Some calculations should tell you how frequently you'll be sending 16 bit values and if you can handle it.

If you send it down to a PC, you shouldn't have a problem with processing time. I don't know what processing you want to do, so how easy it is to do on the microcontroller, but many these days run as fast as 40MHz which if you think about it, rocks.

 

[blahblah99]

I'm not sure if you took a look at the data sheet yet, but the sampling rate of the accelerometer can be adjusted via an external resistor. The output of the accelerometer is in PWM format and the duty cycle changes according to the gravitational pull.

So in essence, I can sample the data every 100ms and just have 10 samples per second, but it wouldn't be as accurate as sampling it every 10ms or 5ms.

I also have to take into account that if I sample at 100ms, then I have at MOST 25% of that 100ms (which is 25ms in this case) to do the processing of data on the microcontroller, or sending out the data to a pc to do the processing. Either way, I have to make sure that everything gets done within that 25ms to ensure that it'll catch the rising edge of the PWM output.

If I sample every 5ms, then i have 25% of 5ms, which is 1.25ms to do the processing or sending out data. And the speed at which the serial port operates is slow compared to my sampling rate and timing requirements.

 

[Mark R]

The calculations needed are not difficult, and could easily be done within 1 ms with a lowish end MCU (don't forget that even a $3 MCU like a PIC16F627 can perform instructions in 200 ns).

Your algorithm only needs to do the following calculations on the fly:

a = Count time that input is high
a = a-a0
x=x+v+a/2
v=v+a
if x> xcal then stop

x probably should be a 32 bit number, v and x 16 bit - although these can't natively be handled by the MCU, emulating 16 and 32 bit additions is not hard.

All the other more complex things can wait. If you calibrate the device by driving a known 1/4 mile, then you only need to use 1 axis, and you don't even need to bother with unit conversions.

Alternatively, you could just output the duty cycle counts via the serial port - don't forget that many MCUs these days have USARTs - just set the baud rate on initialisation, and output a byte at a time to the USART - the USART will buffer the data and send it under its own control, your program can carry on executing.

 

[Moohooya]

As it uses PWM, you can sample as fast as you like, but you do not need to send all that data to the PC. For eample you could take 10 readings at the fastest rate you can read them, thow out the highest and lowest 2 incase of errors (may not be necessary), and then send the average of the remaining samples to the PC.