Dyno daq advice

Status
Not open for further replies.
L

Lorleans

New member
Hi everybody,

With a friend, we've built a dyno for GoKart engines. Engines are mounted on a frame and linked to a big roller inertia. We measure roller speed thanks to a hall sensor in front of a toothed wheel, that gives a square wave. For the moment, this square wave is read by a National Instrument PCI-6010 card. Thanks to its 32bit/80Mhz counter, we have duration between each tooth. We do calculations after on PC to have torque/power curves.

The NI PCI card is very powerful for us because we can easily acquire each tooth period during 2 or 3 min (short acceleration + long deceleration) from a roller rotating at up to 3600rpm (up to 3.6khz square wave frequency with a 60 toothed wheel) without any loss of data.

I'm a little familiar with arduino because I've done classic noob stuff like playing with lcds, sd card, RTC, timers, interrupts, 7segments... I've never played with teensy (but a 3.6 is travelling to home ;) ). I have in my mind that it would be possible to transform our expensive NI card into an arduino or a teensy.

Can you give me some advices before attempting the impossible for a man who can learn, but who plays electronic just at home, my knowledge are limited.

2 philosophy :
- serial/usb is fast enough to transmit data in live, and the save is done on pc directly. but i've read here and there that pc software could limit performances?
- Or, I log in the microSD card of the teensy/arduino board, and at the end of the test, i transfer the log (automatically would be welcome) to do calculations.

Specifications of the daq :
- Tooth period measurement : as i said, worst case = 3.6khz during 3min of a 16Mhz/16bits counter value, 20 or 24bits would be better to measure low speed/high tooth period. Can I easily extend the 16bit embedded counter with the overflow information?
- Also, but less sensitive, log of 5 analog voltages at 20hz around. It's usefull to record temperature sensor (for exhaust and water, and others),
- In parallel, if microSD card option, transmit via usb/serial at 20hz, the roller speed (or tooth period) + 5 analog voltages to have a look, in live on PC screen, on the state of the dyno.
-of course there will be an input by button and serial command, to start and stop the recording.

Bonus :
-lcd/oled auxiliary screen on the dyno to display rpms/temperatures to the operator,
-PID output to drive an eddy current brake (we don't have it for the moment), with it's force sensor measuring associated.

Is this doable on teensy, or arduino? I think yes because I've seen different threads on usd card logger with very high frequency, but less results on serial fast transmission.

Thanks in advance.

Loic
 
Starting with the code at
https://www.pjrc.com/teensy/td_libs_FreqCount.html
might be a reasonable idea of what can be done. Simple option that doesn't get every tooth is to drop the time interval down to say 10ms and let the teensy process the data on the fly.
See here for notes on bandwidth of USB serial
https://forum.pjrc.com/threads/31986-Data-dropouts-in-serial-transfer-over-USB
at 1Mbit.
A recent speed test of SD cards
https://softsolder.com/2017/08/09/sandisk-64-gb-high-endurance-video-monitoring-card-verification/
Though actually achieving that performance on a micro controller is still a constraint.

Certainly a doable project, question would be looking at what gets done at each stage of the data collection to make the bandwidth/CPU load manageable along the entire path.
 
Thanks for your reply.

The principal goal of tooth period measurement is to get acceleration shape of the roller in order to calculate the torque (directly proportional to the acceleration). Acceleration is obtained by double derivative of the tooth period curve. That's why, in order to have a detailed acceleration curve, we have to get all informations possible of the roller position=f(time). That's why we want to be as close as possible to the NI measurement principle.

Problem in FreqCount is that it counts number of tooth during an elapsed time, so we lose information of the speed shape. Moreover, the resolution seems poor. Example at 3600rpm : freqcount will see only 5 teeth (with 60 toothed wheel), so it gives a results of 3142rpm. I can increase time window, but in proportions that is not acceptable to have good resolution.

I've this principle of measure in my mind :
Code: 
ISR (Rising Edge) { // of the square wave of hall sensor
     time = counter_value;
     flag = 1;
}  

void loop()
{
     if (flag == 1) {
       Serial.print(time); or SD.print(time);
       flag = 0;
     }
}
I think i will have to play with buffers to not print at each tooth.

See here for notes on bandwidth of USB serial
https://forum.pjrc.com/threads/31986...nsfer-over-USB
at 1Mbit.
Click to expand...
Hmmm, I will read deeper, but it seems difficult to not have data loss...

I will do some little tests when I will receive my teensy, and I will come back to you.

Regards.

Loic
 
Suspecting if you want to sample every tooth event you will need to do some form of preprocessing of your data. ~600k data points will be an interesting feed as bytes or 32 bit values. Suspect it's the not the right hammer for this job but one option for very high data rate events would be to poll the input and stream the one bit data resulting. For a 10* over sampling that's 36k bit/sec which would fit over USB. Better when you have a stead state high pulse rate signal though rather than a ramping Dyno output, so storing a timer value for each interrupt does seem more sensible. Just need somewhere to put them all.
 
Maybe I completly misunderstood something, but assuming a 32bit value for the time between two tooth events I get: 3600 events/sec * 4 byte /event * 8bit/byte = 115200 bit/sec = 115 kBaud. That should be no problem at all? Measuring the time between the events should be possible with the FTM timers.
A search for FTM on the forum and reading the FTM chapter in the manual will give you a good starting point.
 
Status
Not open for further replies.
Back
Top