Slipper Clutch RPM sketch

Hello Folks,

A young genius and myself are working on making an Arduino Mega into a multi-channel data logger for an alcohol powered mud dragster. It will log exhaust gas temperatures, engine RPM and specifically to this question, slip clutch RPM. The engine RPM is simply an analog 12V square wave which is easy enough, however, the clutch is monitored by a Hall Effect sensor, said sensor being well capable of very fast switching speeds. We expect about 140 Hz maximum from this sensor. A little background on mud drag racing - it is over from a standing start (0 RPM) to max in less than 3 seconds. Therefore, to make any sense of the data recorded, it must be able to record very fast changing values in that time frame. This is important because it dictates how one would set up the "slippage" of that clutch relative to the engine RPM. Alcohol motors are high horsepower and this is how one applies that horsepower to the track conditions - if there is too much, the tires "blow out" or loose traction at the start and you loose. Therefore we want to see the ratio of slippage or clutch output speed to engine RPM in a graph of decent to high resolution. Anybody have any code for something like this?? Any help would be appreciated as race day is 2 weeks away.

How about you record micros(), the time in microseconds, and other date each time a pulse comes in. The Mega has a few interrupt pins.

The Arduino Uno is capable of time stamping events right down to 1 clock cycle resolution. That's 1/16,000,000 of a second. 62.5 nanoseconds. However, recording three seconds of that kind of resolution could be some work. What kind of resolution do you need? If it could tell you the difference between 140.00 Hz and 140.01 Hz, would that be good enough?

If you only need to record data for a short time period (say 10 seconds total?) one option might be simply to store an array of timestamps for each pulse that was received and at the end of a run upload the data to a PC for analysis.

...R

Suggest you start by working out the quantity of data you need to collect i.e. how many values, how many bytes of data needed to store each value, and the number of times you need to sample these values during a given run.

From the total data size you can work out whether it’s feasible to store it in RAM. If not, you’ll need to look for a storage mechanism capable of storing that much data that quickly.

You might save time, money, and have a better product using an inexpensive product like below.

Thanks for the input guys. I guess I should have been more specific regarding how we are trying to do this. First - we are logging all this data to a SD shield card and because the time frame is short we have plenty of room for high resolution and the higher the resolution the better (so we can see exactly what the clutch is doing). This device will also send the data wireless to a laptop through a web based protocol after which Excel will be used to chart the raw data. Second - it is a prototype and we haven’t got any data yet (hopefully tomorrow or Sunday) so how much or how fast is yet to be determined. The 140 Hz figure is based on an expected maximum clutch shaft speed of about 8 to 9,000 RPM, we have seen RPM from the engine in the 8,800 to 9,800 RPM range but again, it is a slipper clutch and does just that so we expect lower speeds there. As asked in a reply “is 140.1 Hz good enough” and I would say yes to that, again, the high res the better if possible. In regards to using off the shelf DATAQ stuff, what we are trying to do here is develop a proto that we can make into a case hardened race application, in one box, that is more reliable and much less costly than the currently available race specific apps available. We and our members are hobbyist racers and most of us do not have the funding for $5,000 systems. Any of us who do have had many issues with that stuff, i.e. it spends more time going back and forth to the manufacturer than on a race car! I did find a sketch last night for Hall Effect RPM and boy genius is going to play with it tonight.

If I were to do this, I think I would take johnwasser's suggestion and make two very short Interrupt Service Routines that simply record micros() in two circular buffers whenever they get triggered. Then the main loop() function could pull data out of the circular buffers and and store it on the SD card.