BS2pe Mobo Tach question

jsaddiction

I need to build a precision RPM Gauge for a rotating light (light house) I must be able to display to the hundredth of an RPM and the Rotating assembly has an IR sensor and an encoding strip which has 550 pulses per revolution. I know sounds like a lot but this will make it easier. Max rotation speed to be measured is 20 rpm. I think that is 183.333 hz so i think this would work. I would like to display this on the master 7seg display. I am guessing that an update rate of the display around once a second or faster would be sufficient. Can this be done? I onlyhave experience with the BS2. Would it be very difficult?
TIA

Phil Pilgrim (PhiPi)

What you propose seems like an ideal app for the MoBo. However, to obtain an accuracy of 0.01 parts in 20 (i.e. 1 in 2000) you would need to sample the nominal 183.333 Hz clock for nearly eleven seconds to count the pulses in that interval using the COUNT command. To obtain a result more quickly, you could measure the high and low widths of your 183.333 Hz clock via the PULSIN command. You would probably have to keep a moving average to accommodate the inevitable jitter in the pulse widths encountered during a rotation. As an alternative, you could also run the encoder clock though an external divider to reduce the frequency and lengthen the period seen by the Stamp, so that it encompasses more pulses. For a one Hertz update rate, a divide-by-128 external counter would not be unreasonable.

-Phil

jsaddiction

Phil that is a very interesting solution you have suggested. I think that maybe a running average would be a good idea and maybe update the display with the result of the average and then clear the average and start over every second. That would measure the pulse width 183 times calculate and then display. I do know that the jitter is present as watching this on a frequency counter shows proof. The rotating assembly has a motor controller that controls rotational speed of the brushless dc motor. no gearing and it is 3 phase with 3 poles. the controller has two hex rotary switches to select the rotational speed (end user feature) I need to verify each switch position produces the correct RPM. one switch controls a coarse adjustment and the other a fine adjustment. Currently our test procedure only checks for rotation and doesn't require a rpm calibration or check. Thanks again Phil for the insight. and if you don't mind could you provide a little more info on how this measurement could be done.

jsaddiction

o yea one more thing. it seams to be a sinwave from the IR sensor. I think its only one volt peak to peak. Could i use the built in ADC some how or will i need more daughterboard and components to condition the signal first.

Phil Pilgrim (PhiPi)

What are the high and low voltages from your 1V P-P sine wave encoder output?

-Phil

jsaddiction

I will check tomorrow at work to be sure. I know its a sinwave riding on a DC level.

jsaddiction

i have to appologize we got kind of busy at work today. (fall out funds had to be spent) I promis i will get the info tomorrow morning

jsaddiction

OK here is the data

it is a sinwave with 3.44v Pk to Pk riding on 2.96vdc. High part of the wave is at 4.68vdc and low part is at 1.24vdc.

Phil Pilgrim (PhiPi)

Theoretically, you should be able just to input that signal to a BS2pe pin. However, the 1.24V low is perilously close to the Stamp's TTL input threshold of 1.4V. For the utmost reliability, I would interpose a 74HC Schmitt trigger buffer between your encoder output and the BS2pe.

-Phil

jsaddiction

I do not currently have the BS2pe so all of my tests will have to be done with a plain old BS2. I did find a SN7414 in my parts bin and hopefully that will give me some good results. It does invert but that shouldn't effect anything. I am going to give it a try on a breadboard and see how much jitter i have after the schmitt trigger. Thank you for the help. If you have anymore insight to this please let me know. First I will try a circuit that will count the number of lines on the encoder (the BS2pe is on order)

Phil Pilgrim (PhiPi)

The same caveats apply to the 7414 as to the BASIC Stamp: the 1.4V TTL threshold is too close to the 1.24V low. In the case of the 7414, the Schmitt triggering may even make things worse. Unfortunately (and I'm going to have to revise my advice here), a 74HC14 doesn't fare much better. You would probably be better off with a comparator, in which you can control the threshold and amount of hysteresis and tailor them to your app. If you need a schematic suggestion, I can provide one.

-Phil

erco

How about pop a diode in to drop the voltage 0.7 V down into the TTL-detectable range? Although I much prefer Will Smith's gangsta phrase "pop a cap" in ya...

Alternatively, use a pot as a voltage divider to do the same thing. Using the Stamp's inputs directly as comparators are one of my favorite tricks.

Phil Pilgrim (PhiPi)

erco,

Your idea would certainly work, but with a sinewave input coming, perhaps, over a cable from the encoder, I would still encourage the addition of some hysteresis to eliminate any concerns about noise.

-Phil

jsaddiction

Ok so i tried the inverter and just like you guys said ... no good. I pulled out my function generator and recreated the sinewave with a dc bias. I tried to put in a coupling capacitor and it helped bring the bias a little lower but still not low enough. Then it hit me. If i have any adjustability in the circuit i.e. a comparator or something of the sorts then that adjustment would effect the pulse width of the output wave. With that... now my RPM gauge will be adjustable. This particular gauge "application" should not allow for an allignment. I will have non electrical engineers operating this gauge. Is there a way to design this so that it is either accurate or doesn't work at all? I know i could use the comparater to generate a signal and then use the COUNT function but as said before it would take 11 seconds to retrieve a measurement update. Is there a function in the co processors that can do this with better accuracy and speed? Different way to do it? Accuracy and ease of use are my priorities. If these two goals are not met then the only one that could reliably operate it is me and honestly i don't want to do all the work...

Phil Pilgrim (PhiPi)

Try erco's idea ahead of the 7414: a diode placed forward into the inverter, with a pulldown on the inverter input to ground.

-Phil

jsaddiction

I will do that on monday. I messed around and left all my stuff at work. That sounds like it could work. any insight to how to measure the 7414's output with some accuracy? O yea I will also take a look at the motor controller's circuit. It uses this same pulse and puts it into an amtel chip to regulate rotational speed. I am sure it has some way of making it readable at TTL levels (maybe it won't be too complicated. I do know that it uses an opamp some how.

jsaddiction

Ok Tied the circuit idea and here is what i found. When connected to my function generator it works perfect. unfortunatly it is too much of a load for my speed controller. It causes the Motor controller to speed up out of controll Kind of cool though... I tried various pull down resistors and even no resistor but none of them was able to pull the signal low enough to allow the 7414 to trigger. I got to looking closer at the schematic of the motor controller and the sensor connects directly to an op amp.. LM358N sensor to pin 6 reference to pin 5 with a 10kpot various resistors and finnally goes out of pin 7 to a microcontroller. I soldered a Test point to pin 7 of the opamp and put my scope on it and sure enough a nice square wave. Judging by the output and the configuration it looks to be wired as a comparator but im just guessing. I could use the output of this opamp as my input to the guage but like mentioned earlier i would probably need to measure period as the duty cycle is adjustable and the pulse widths have twice as much deviation as the period (measured with a freq counter)

Phil Pilgrim (PhiPi)

Did you use a diode ahead of the pulldown to drop the voltage first? That was the gist of erco's suggestion, which I followed up on.

-Phil

jsaddiction

Yes I tried a diode. I also tried various resistance values for the pulldown resistance. There was too much current draw from this circuit and caused my motor controller to not regulate speed. I could also try to use a second it sensor and make the tach totally independent of the controller. Then I could control the biasing of the sensor and maybe even make it quadratic and tell direction. This would be ideal. Is it.difficult to allign some sort of dual sensor system to tell direction

Phil Pilgrim (PhiPi)

I think you've exhausted that approach, then. I'd recommend going with the comparator and a little bit of positive feedback for hysteresis. As far as quadrature decoding goes, I may have some AVR code that you can drop into a MoBo coprocessor that will handle that for you. Later this evening, I'll check and see.

-Phil

jsaddiction

Ok Cool... I think with the pwm 3 step 3 phase brushless motor controller generating so much noise and for isolation sake I will explore the possiblity of of adding a set of ir sensors to the housing (time to fabricate) I really appreciate the offer on the AVR code. Along the lines of the comparator this would lead to haveing to calibrate this thing right? I don't have a known RPM to judge the accuracy. The best thing i can do is use several motor controllers all set to the same speed and maybe average the readings and adjust this gauge to match. Any thoughts on this? As far as coding goes how is the pulse width related to RPM?

Phil Pilgrim (PhiPi)

jsaddiction wrote:

Along the lines of the comparator this would lead to haveing to calibrate this thing right?

A little, maybe, but not a lot. You don't need an accurate 50% duty cycle, as long as you measure full cycles instead of just single pulses.

jsaddiction wrote:

As far as coding goes how is the pulse width related to RPM?

Pulse widths will be shorter as RPM increases, but you cannot count on their individual widths for measuring RPM.

-Phil

Phil Pilgrim (PhiPi)

'Just looked through my AVR files, but nothing for encoder input. Sorry for the false hope ...

-Phil

jsaddiction

I guess your saying measure pos pulse width and then measure neg pulse width then add them together or is there an easier more efficient way. No problem about the AVR stuff. I can try to write that code too if that is nessisary

Phil Pilgrim (PhiPi)

jsaddiction wrote:

I guess your saying measure pos pulse width and then measure neg pulse width then add them together

Yes. It does depend on neighboring pulses being more or less identical, since the negative pulse you measure won't be the one immediately following the positive pulse, but the one following the next positive pulse.

-Phil

jsaddiction

I did forget to mention that at one physical position on the rotating assembly will result in whole period's worth of time at a high level. I suppose this is a heading flash or something but the circuitry doesn't need or seem to use a heading flash. I guess as i am reading pulse widths and doing averages i can check if a positive pulse width is N% greater than the average and then throw out that measurement. Is that how you would keep things accruate. I know it would be once in a great while i would have to throw out a measurement since im not counting every pulse but i wouldn't want it to skew any results and causing a motor controller to appear bad when in accuality it isn't

Phil Pilgrim (PhiPi)

Considering this further, I think I would revert to the COUNT command, after all. Record counts during one second intervals in a 16-byte FIFO buffer. Keep a tally of the sum of the counts in the buffer. After each new interval, add the count for that interval to the sum, and subtract the count for the interval that it replaces in the buffer. That way you will have a count for the last 16 seconds or so, giving you the accuracy you need, but updated every second.

Jitter and pulse asymmetry issues are beginning to scare from the period measurement approach. And I don't believe they will give you more accuracy any quicker than a simple pulse count would, since you have to average them anyway. The best part is that counting pulses is just simpler.

-Phil

jsaddiction

That sound a little easier. Another thought on the FIFO buffer. the typical use would be to measure several different RPMs. The user would start up the motor controller and verify correct direction of rotation and then look at this gauge and verify rpm. Then the user would change the hex switches located on the motor controller to change the desired rpm and then look at the gauge to verify RPM changed and is accurate. I could use the initialization part of the code to fill up the buffer while writing dashes to the display. the main code could display the acctual RPM on the display and update the FIFO. After the user changes the desired RPM on the motor controller the user should maybe push a button on the gauge that would send the program back to the initalization and clear the FIFO and make the user wait until the acctual RPM can be displayed again. I just need to get some parts in and start trying things i suppose. i thank you so much for your help on this.

jsaddiction

Phil I found this thread you made back in 2007. Is this the AVR code you were talking about? http://forums.parallax.com/showthread.php?91750-BASIC-Stamp-Encoder-Tracking-at-37-KHz

Phil Pilgrim (PhiPi)

Yeah, that's what I was looking for, but I couldn't find it on my PC for some reason. (It must be in a backup archive somewhere.) 'Glad you came across it!

-Phil

jsaddiction

Phil , I have finally completed the circuit to interface the optical sensors to the atmel chip. just like you said i ended up with a dual comparator with some feedback to create some hysteris. I have 0.5v between high and low outputs. the signal is pretty good looking and I also built the hardware for the quad encoder. little tricky getting the position just right but its all glued together now. I have about 100 degrese of phase shift so its pretty close to optimal. anyway I have been studing your documentation pretty hard on the thread i listed on my last post. Is there a way to get my hands on the code that was written for your project? I want to see how it was all put together and maybe taylor it for my application or add some of those features discussed in that thread.