ZX-24a reading RPM information . . .

[kurakaira]

The Turbo speed sensor is a Garret 769366-0001 .
It's datasheet states that it outputs square wave at 1/8th of the input rpm .
So when our turbo has 14 blades / 8 , the actual rpm should be divided by 1.75 .
I will measure the Haltech ( E11v2 ) output tacho signal with a O-Scope .
I can enter a value of 10 pulses per revolution , but the documentation claims i can only enter a value up to the number of cylinders ( in this case 4 cylinders ) . i think it would be best to lower this value to 4 pulses / revolution just to be sure and change the code to divide by 4.0 .
I have had the setting at 10 so far , but now that i think of it i cant be sure what it outputs . ( could be why i have to divide the rpm in my code by 5.0 instead of the 10.0 that my head tells me would be correct )
Too many unknowns and too little time to figure them all out ...
I have thought about converting the 2 rpm readings to 0-5v voltage ...
But after a quick glance i couldn't find a simple part that could do this .
Maybe i could use another ZX-24a that would use CountTransitions over a 100-200ms and output the data to a DAC , and be read with the MUX ...
I think this would be more accurate . Am i right on this one ?
The Turbo RPM is not so important , it is only needed on the dyno .
But almost every other temperature and pressure value rely on correct RPM reading . ( if RpmS > 2000.0 and FuelPresS < 2.0 then AlarmLedB = 1 ... and so on )

Using another ZX is probably the way to go , because my friend that builds the car ( Drifter - Mazda RX 7 ) , now want's to have a option called FlatShift enabled , the car has a sequential 5 speed gearbox that has a potentiometer built in so you can see the gear it is in . What he want's now is a ignition cut at the moment he starts to put a bigger gear in .
Can i use CountTransitions with a 100ms window ( x 2 rpm readings ) and at the same time read the gear box potentiometer with the ADC ( maybe at least 20Hz refresh rate )

Thank You for Your wisdom & help !

[pdubinsky]

Just as an aside, what GPS receiver are you using? I have some GPS experience but it's with rcvrs that run at 1 hz. I'd like to look at something that runs at 4 hz.

Thx,
Paul

[kurakaira]

I bought the GPS from Sparkfun .
It's a 32 Channel LS20031 GPS 5Hz Receiver , from sparkfun.com / LS20031 you can find a program called MiniGps that was able to change the sentences outputted and refresh & baud rate .
I decided to set it to 4Hz , not because i could see the speed on the lcd instantly , but because all data is logged and can be analyzed after a race .
( Also the car goes from 0 to 100km/h in 3-4 seconds , not much joy from 1Hz speed reading : )
I also bought a 32 Channel San Jose Navigation GPS 5Hz Receiver with Antenna . But i haven't had time to to even try it out yet .
I live in Finland , and as this car project got a bit out of hand , i was in a hurry to find suitable fast gps , so i bought two different ones because i thought they would travel forever , but when i ordered them on a sunday evening , the package came wednesday at 1600 . A fast delivery !

The car was supposed to have a Racepack IQ3 dash , but 2 weeks ago the distributor said they didn't know when it would arrive ( ordered 2 months ago and paid in advance )
So as i was still doing wiring on the car , the owner asked me if i could build a dash for him ... i have been busy since that ...

[kurakaira]

Hello again ; )

I have a new approach for the rpm ,
The GetElapsedMicroTime function .
I have been experimenting with it a bit , and it seems a bit more useful for my purpose .
Because the timeout in InputCapture happens too fast for my purpose .
I calculated that the rpm pulse is 60ms long at 1000rpm ( at 1pulse / revolution ) and 13.3ms as 4500rpm ... and so on .
Maximum pulse time that i will measure is about 105ms ( turbo rpm at 1000 rpm / 1.75 )
Am i right in assuming the example in GetElapsedMicroTime that uses (1 to 5) byte counter space is filled in 4.4ms ?
And i must use at least a byte array of 12 to make space for a 105ms timing ?
Also if i don't specify a second parameter (LaterTimeData) to the GetElapsedMicroTime it suffers a +-1.95ms resolution accuracy ( RTC resolution ) ??

I'm thinking of trying this ,

Code: Select all

Dim First(1 to 12) as byte
Dim Seco(1 to 12) as byte
ValB = getpin(12)
Do
Loop until getpin&#40;12&#41; <> ValB

Call GetMicroTime&#40;First&#41;
ValB= getpin&#40;12&#41;
do
Loop until getpin&#40;12&#41; <> ValB
Call GetMicroTime&#40;Seco&#41;

PulseW = GetElapsedMicroTime&#40;First, Seco&#41;

[mikep]

I think you misunderstand the function of the API. If you call GetMicroTime it returns the time result in a 5 byte array with a resolution of up to 4.34uS.

When you call GetElapsedMicroTime with 2 of these 5 byte arrays, the two times are subtracted and the difference returned as an UnsignedLong with a resolution of 4.34us. The maxiumum time difference is around 15,000 seconds (as documented).

You should specify a second parmeter to GetElapsedMicroTime. The whole point of this function is to calculate time differences for you.

See also Register.TimerSpeed2

[kurakaira]

Ok , so the 5 byte array only captures the really fast ticks of the RTC .
I got confused with "The array is expected to contain at least 5 bytes" , and i tought how 5 bytes could hold more than 4.4ms , but then of course it holds only the really fast values and adds the rest from the normal RTC tick ...
My bad , again .
When i tried the GetElapsedMicroTime fuction , i only used the first parameter and as a result my engine rpm reading was fluctuating .
Now i'll get some sleep and try again tomorrow with a fresh mind and updated code . ( like the one i posted earlier , but with a timeout if no transitions occur )

Thanks again !

[kurakaira]

Here's a few photos so You can see what i'm talking about .
The screen is now housed in a carbon fibre housing , unlike in the photo which is a few days old .
I can post better pictures if they are of intrest ?

[spamiam]

Wow, that's a nice rally car. My brother does rallying in the US in the "Historic" class with a Datsun 510. They do reasonably well even against the modern RWD cars.

I hace designed a rally computer for TSD rallying, and I had considered adapting it for special stages. They have a slight problem in matching odometer readings with the rally route book. With wheel lock-up and wheel spin they were getting some noticeable deviations between the route book and the measured odometer even when zeroing the odometer between instructions.

I was considering having the computer watch for impossibly fast accelerations or devcelerations and then substitute the maximum deceleration/acceleration for the erroneous signals coming from the speed sensors.

I had also considered using GPS. Do you find that 4Hz is fast enough updates considering that the course is very curved with many sharp turns? Does heavy tree cover seem to interfere with the signals?

-Tony

[pdubinsky]

Tony,

I believe he said in an earlier post that this is a drift car rather than a rally car. As an old SCCA Pro Rally driver, that Mazda has way too little body damage to be a rally car.

I'm surprised that your brother has wheel spin/ lockup problems with the 510. Usually at least one of the odo sensors is put on an undriven wheel to solve the wheel spin problem - on the 510 that would be a front wheel.

If you have wheel lockup on a front wheel, you need to change the brake bias to avoid the following scenario: angular velocity of front wheel rapidly goes to zero; steering control goes to zero; vehicle velocity goes to zero. The usual outcome tree 1, rally car zero.

C8-)

And kurakaira,

Thanks for the info on the GPS.

[spamiam]

Well, they have a few sensors that they read from. At least one if from a front wheel. One is from the driveshaft. It may well have been a problem with the sensor(s) itself. In the wet/damp it was definitely unreliable, and I think it was having problems in the dry as well.

They changed the entire wiring of the computer and sensors recently and I don't have any updates regarding its reliability.

In the photo of the interior of the car, there are 4 white tubular devices on the center console. What are they?

-Tony

[kurakaira]

Spamiam : I do think that with a 4Hz or 5Hz readings You can get good course and speed readings . As i housed the LS20031 , i had it in my car for a few hours ( and i used a laptop to read the RMC sentence ) and it performed very reliably , consistent speed readings compared to my Magellan XL GPS .
But MUCH faster update rate , the difference is staggering compared to 1Hz .
And the tubes are fluids for clutch , front , rear & handbrake . ( i think because that is the highest place in the car , must ask the builder ... )


And pdubinsky : You are very welcome , it think it's best to share my research ( the time searching trough all the datasheets has been long ... ) , so You don't have to buy the part and try if it works or not , now we both know that at that price range the LS20031 is the way to go . ( At least for all my GPS projects for now on )
I understood ( from SparkFun webpage ) that the 32 Channel San Jose Navigation GPS 5Hz Receiver would be even more sensitive but i haven't tested it yet .

I will try the InputCapture again today with the Register.TimerSpeed1 = 2

[kurakaira]

Does the InputCapture(pdUI, 3, 1) start the capture instantly if the pin is already 1 ?
So i if a want to measure a full pulse width of 2 segments 1 & 0 , i should read 3 segments and discard the first , and sum pdUI(2) & pdUI(3) .

[mikep]

The capture is started on the next edge transition that you specify (either 0->1 or 1->0). If it is already 1 then you will have to wait for the next 1->0 transition. In that case you should be able to call InputCaptureEx with a data count of 2 and a 0 for the flags.

[kurakaira]

At last success , steady & accurate RPM readings .

Code: Select all

Call LockTask()
 Register.TimerSpeed1 = 2  ' slower * 8 , 542.4ns / count
Call InputCapture(pdUI, 2, 1, 2) ' timeout in 70ms
 Register.TimerSpeed1 = 1  ' back to default  , 67.8ns
Call unlockTask()
ERpmS = RpmS
if pdUI(1) = 65534 or pdUI(2) = 65534 then ' if no pulses are acquired
RpmS = 0.0
else
RpmS = 0.0
RpmS = 60.0 / (RpmS * 0.0000005424)  ' To minutes * 542.4ms
RpmS = RpmS / 4.0  ' Four pulses per revolution
End if 
If pdUI(1) = 65535 or pdUI(2) = 65535 then  ' if pulse width is longer than 35ms ( this should not happen since the PW is 15ms @ 1000 rpm )
RpmS = ERpmS  ' go with the previous value
End if

[kurakaira]

This is the code for the Engine RPM , the difference in the Turbo RPM is that it measures 3 segments and discards the first and sums the 2nd & 3rd .

But as this code works ( so far ... ) good , still the GPS loses its validity every now and then for a second .
I have a ShiftOut for the 74595 , but as it writes only 8 bits , it should only take 40uS .
Counted with a 200kHz update rate , the time the DAC takes is 80uS ( with interrupts disabled ) , so it is possible that i am missing characters from the GPS here . ( as Don said the max. time interrupts should be disabled is 50uS )
I will try to change the code for the DAC to bit banging .
Should i also change the ShiftOut to the 74595 to bit banging ?
This is how i write to the DAC ,

Code: Select all

Call putpin(CS4921, 0)
Call shiftout(SDO, SCK, 8, MCP2B) ' MSB
Call shiftout(SDO, SCK, 8, MCP1B) ' LSB
Call putpin(CS4921, 1)