Instrumentation error with Propeller on Spin code.

yarisboy

I just finished my error check on the tachometer that I'm writing a story on. On the left I have a Propeller giving me a frequency. On the right I have my Propeller tachometer. For an input frequency that would yield a theoretically perfect 600 RPM I get 597. All the way up the scale to 8000 RPM my value coming back is 3 RPM low. I did not expect a decreasing percent error up the scale. A fixed offset error seems unlikely. Could it be that gain errors in the Props are canceling each other out. If I were to believe my (moron level) math skills I might jump to the conclusion that I have a -0.1% error at idle and a -0.04% error at 7000 RPM when my ECM starts retarding the timing. Any thought from the old gray beards and code warriors?
My ebay 20 MHz scope just doesn't have enough resolution on the time base to make any judgments with. According to the results I'm getting now both the commercial tachometer in my auto shop and the BS2 tachometer I built are way off by comparison.

ElectricAye

yarisboy wrote: »

...On the left I have a Propeller giving me a frequency. On the right I have my Propeller tachometer. For an input frequency that would yield a theoretically perfect 600 RPM I get 597. ....

Just for clarification: is the Propeller on the left giving you a frequency output signal that goes straight into the signal input of the Propeller (tachometer) on the right? or is the left Prop generating a frequency that drives a mechanical system that the right Prop tachometer is reading?

Also, it might help if you post the code. If you have delays in a Repeat loop caused by outputting to LCDs or something or calling up other methods, maybe it's causing some kind of discrepancy?

yarisboy

The ECM simulator outputs a 0-12 volt square wave just like my OBD-II port. The prop-tach runs that through an optocoupler to protect the inputs. Both Props are running 5.00 Mhz crystals at pll16x. At idle I had to slow down jw-synth to 5 samples per second. For the 4x7seg driver I am using an 8 KHz clock and waitpeq and waitpne to manipulate the serial com signals. The rub was getting the 4x7 LED display and PST to play well together. The PST is set for 11520baud. Slowing that down didn't make any differences. The left prop uses synth.spin and the right prop is using jw_freqin.spin, both from the OBEX. I've heard that when you write a piece for a magazine, first you open a vein........
I'm also seeing a small drift related to how long the system has been running. I looked at the curve for the xtals and at 25 C it is essentially flat. I'm not sure how much integer math truncation has to do with it. In the real (motor vehicle) world the errors are silly small. Resetting the ECM simulator wipes out the small time dependent drift.

ElectricAye

yarisboy wrote: »

The ECM simulator outputs a 0-12 volt square wave just like my OBD-II port. The prop-tach runs that through an optocoupler to protect the inputs. Both Props are running 5.00 Mhz crystals at pll16x

So I take it that the ECM simulator is the Prop on the left?
The "prop-tach" is the Prop on the right?
And your optocouplers are what connect these two Props?

And your code is...?

yarisboy

Sent you a PM. I have four optocouplers on the piggyback board. One for Tach, one for VSS, one for integration of dash dimmer that uses a duty cycle com to ECM display driver from Toyota. The extra spare is available for future expansion. I have enough I(s) on the piggyback to drive eight O(s) if I wanted to do an entire dash board. Even If I get all the features on the Protos to work I'll still be doing a rev-B board to exploit the high voltage control capabilities of the Supertex HV5522 chip. Automotive applications are just to get me familiar with the hardware before attempting relay/triac control. It's amazing how many features can be crammed on an expressPCB mini-board when you make the leap to SMTs.

Mike Green

In the absence of further information, it seems like you have a fixed error (3 counts) that is present throughout the range of measurements that are otherwise correct. What could give a fixed error? Without a listing of your code, it's really impossible to say. Maybe something isn't initialized properly. Maybe some kind of end of loop decision is based on the wrong count. I doubt that it's something having to do with the sensor although that's possible.