Please point newbie in right direction for project...

[PJ Adams]

This could be long, so apologies in advance...

I would like some pointers/advice/etc with regards to a project.

I need some form of 'black box' device that is positioned between a PC & an engine testing machine. The black box would measure 1 Digital & 2 Analogue mesaurements from the machine. During the time the machine is being measured (up to a max of 5 mintues), the measurements are passed to the PC at a slow rate, say twice per second - these are used to update the display on the PC. When the machine has stopped, the entire measurements in detail are then downloaded to the PC from the device's memory. The device is then reset and ready to go again.

The digital input measured the speed of a metal drum from 0 to 5000 RPM in an all weather, possible dirty, environment. Because of this, I was planning to use a hall effect sensor instead of some other method.

One analogue measurement measures the RPM of an engine up to a max of 20,000 RPM using an inductive pickup placed over the lead to the spark plug of the engine. I do not know how to get an Analogue 'spike' reading read into a device? An ADC?

One analogue measurement reads gas content of exhaust fumes, as a reading from about .25 of a volt to 2.5 volts. Again, how would you read this in, an ADC?

This is what I was thinking...

Measuring the time between the hall effect pulses would give you the RPM of the drum. Measuring the time between the engine RPM pulses would give you the RPM of the engine. I want the value of the voltage from the gas analyser.

All three readings need to be syncronised to each other somehow, (maybe with a running clock that is reset at the start of each test run?). This 'clock' reading could be saved against each measurement, thus giving each measurement a fixed point of time reference compared to the other readings.

The true value is when you can say that at 12,000 Engine rpm, the drum was turning at exactly 3,450rpm & the gas analyser was showing 1.25 volts.

Now - this may all be too complex to do with some form of PIC chip - but there is no harm in asking! :roll:

Getting fast readings, (such as 1000 readings / second), would be very welcome, as this gives good accuracy when the engine is accellerated hard & the readings change very quickly.

These readings are all currently read off manually & is frankly a pain in the backside, (& accuracy must be affected!). Capturing the data automatically would speed the process up ten fold, but we do not have the money for custom made automated testing machines.

My thanks for any advice in advance,


Regards

Paul

 

[motion]

I need some form of 'black box' device that is positioned between a PC & an engine testing machine. The black box would measure 1 Digital & 2 Analogue mesaurements from the machine. During the time the machine is being measured (up to a max of 5 mintues), the measurements are passed to the PC at a slow rate, say twice per second - these are used to update the display on the PC. When the machine has stopped, the entire measurements in detail are then downloaded to the PC from the device's memory. The device is then reset and ready to go again.

It would be better if you can transfer all the captured data right away without storing in the device because the PIC does not have on-chip memory to store 5 minutes of data. It would be limited by the serial port bandwidth. A baud rate of 115Kbaud might be enough for a sampling rate of 1000 samples/sec.

The PIC A/D converter can do a conversion in about 20usec and so 2000 samples per second (1000 samples per channel) is possible. If the drum would have 10 poles then the 3600 rpm would generate 600 pulses per second and more readings per second.

Now - this may all be too complex to do with some form of PIC chip - but there is no harm in asking!

I think a 20Mhz PIC with ADC and CCP module would be sufficient.

 

[jem]

First of all, I would recommend an ATMega8 running at 16MHz since I am biased towards AVR microcontrollers . Now, having said that, I also think you should get the PC to store the data in its memory which displaying a a slow rate. At the end, it would simply dump its entire buffer to a file. Here is some simple starting feasability calculations. You can change the parameters if they don't fit your needs.

Assumption: Signal condtioning will be taken care of (another section, maybe).

Assume 8 bit accuracy (256 levels) for the 20000 rpm max. reading. That gives you a max. resolution of about 100 rpm. You would probably need a 10 bit ADC to get true 8-bit accuracy, and discount the noise bits.

Assume 8 bits for the 5000 rpm max. reading. Max. resolution is 20 rpm.

Assume 8 bits for the 2.5V reading. Max. resolution is about 0.01V.

Data payload is 3 bytes then. When sending to the PC, you will need to frame that payload so the the PC SW can determine when a reading strats and ends, and the next reading starts. Assume three bytes for this framing (including a checksum byte). That gives a total of 6 bytes, or 48 bits per reading. In serial RS232-type communication, every byte requires about 10 bits (including start/stop bits). So you will need about 60 bits per reading. At 10000 readings per second, your bit rate is about 60000 bps.

So, you have ample safety margin if you communicate at 115KBaud to the PC. You can probably increase some of the resolutions, and still be within the limits of 115KBaud rate. However, you will then probably need external ADC's to achieve that.

Good luck,

Jem

 

[Nigel Goodwin]

I don't really see any need for 1000 readings per second, you're not going to see much on an engine in those sort of time intervals.

While you can easily get ADC readings fast enough, you can't read the speed that fast - there are basically two methods for doing it:

1) Frequency counting, count the number of pulses in a given time, the longer the time the more accurate the reading. If your gate time is 1 second 6000 RPM will read 100, giving a resolution of only 60 RPM. With a 1/10 second gate time resolution is only 600 RPM.

2) Measuring the time between two pulses, this is obviously a lot faster, but at 6000 RPM is still 10mS - 10 times longer than you want the readings to be sent in - and that's at a fairly high speed, at 600 RPM it's 100mS.

A PIC would easily do the job, as you say using an ADC for the voltage output from the gas analyser, and using frequency counting for the two revolution measurements.

Syncronisation is no problem, simply read the inputs consecutively, so read motor speed, read drum speed, read gas analyser - then send all three readings together.

Your main problems are going to be the hardware between the engine and the PIC - your best bet is probably to get each part working individually, before trying to put them all together.

 

[PJ Adams]

Thanks to all for the prompt replies...

Motion - Real time data transmission might be best...

Jem - Excellent techie post. Signal conditioning is something I am worried about with regards to the RPM from the engine. Can you recommend a book or web site with regards to this kind of thing?

Nigel - I like your second option of measuring time between pulses.

With regards to syncronising the readings together, I think I did not explain myself very well in my first post. Eventually, I am aiming for a graph, with the x-axis as time, with engine & drum rpm on it, as well as gas readings.

I have heard that serial port comms on a PC can be slightly inaccurate with regards to exact timing, so I was hoping to pass the time of the running clock out as part of the data stream from the device, something like this...

Start clock running

Start ID - time - Engine RPM reading - Drum RPM reading - Gas voltage reading - end ID

Then send another...and another...etc, until a button is pressed or time hits 5 minutes.

Reset clock, start again with a button push.

[This is all guess work as I've never done anything like this before, but have VB programming experience]


Thanks again,

Paul

 

[Nigel Goodwin]

I have heard that serial port comms on a PC can be slightly inaccurate with regards to exact timing, so I was hoping to pass the time of the running clock out as part of the data stream from the device, something like this...

Start clock running

Start ID - time - Engine RPM reading - Drum RPM reading - Gas voltage reading - end ID

The serial port on a PC is more than accurate enough, the whole point of asyncronous data transfer is that it's re-syncronised every byte.

There doesn't seem any need to send a clock signal, nor a start and end ID. As the data will be coming at regular intervals the timing is automatically known, so no need for a clock, the PC can generate that afterwards if you need it. The data itself can be sent as plain ASCII, and the PC store it accordingly - something like this:

6000,15000,2.45CRLF

So each line received consists of the engine speed, followed by a comma, the drum speed, followed by a comma, and the voltage reading, followed by CR LF to signify the end of the line.

This could be simply received by a standard comms program, and saved to a file - you could then import it into a database (comma de-limited file) or spreadsheet.

 

[bmcculla]

If you want a simple solution check out:

PMD-1208LS - $109.00
**broken link removed**

This is a simple USB based data aquisition system with libraries for easy interfacing.

Brent

 

[PJ Adams]

Thanks bmcculla,

Unfortunetly, it seems the software is almost $500 for this - but it is an interesting neat package.

I have several things to think about now. Again - thanks to all - what a great forum...

Paul 8)

 

[bmcculla]

The device should come with C libraries free with the device. I think the $500 software is their graphical programing suite - nice but unnessesary for your project. We have one here and I'm fairly sure we didn't pay for any special software. Give them a call or email and ask.

www.LabJack.com has a competing device that does the same thing.

Brent