pwm-in timing

[jimturpin]

Hi all,

I have a simple code segment that is returning erratic timings. I'm sure it is operator headspace problems, but I am looking at this and the results don't agree. Hopefully the scope output will be available as well. Can anybody tell me what I am doing wrong? Thanks in advance for your advice and comments. -jim-

Here is the code:
: RPM
DECIMAL
BEGIN
TB3 ACTIVE-LOW
TB3 SET-PWM-IN
BEGIN
TB3 CHK-PWM-IN ?DUP
UNTIL
4 10 */ .
?TERMINAL
UNTIL
;

Here is the output:
RPM 297 294 294 298 2857 291 290 297 2855 291 2857 290 2859 299 294 2857 296 289 292 297 2858 291 293 298 292 2855 291 294 293 294 292 298 294 290 297 289 297 293 291 299 294 294 2860 2862 292 297 294 294 290 293 2853 2858 291 296 289 292

[nmitech]

I think the DECIMAL and HEX base you defined in your program is causing the erratic readings. Try this,

DECIMAL
: RPM
BEGIN
TB3 ACTIVE-LOW
TB3 SET-PWM-IN
BEGIN
TB3 CHK-PWM-IN ?DUP
UNTIL
4 10 */ .
?TERMINAL
UNTIL
;

[RMDumse]

That doesn't really look like a HEX DECIMAL problem to me.

I think it is probably something else, but I'm not sure what.

It could be you are getting erratic readings or it could be that your serial link isn't fast enough. I've seen weird results, where it turns out the PC wasn't fast enough to keep up with the 'Pod. I generally notice it as the buffer fills up, not right at first. Those numbers look awfully consistent, though for any kind of random overlay of previous numbers.

Just a thought. You're hitting the CHK-PWM-IN awfully soon after the SET-PWM-IN. I wonder if it takes some time for the SET-PWM-IN to load, and maybe you're snatching it before its reset. It shouldn't be a problem, but something is going on here. Try this:

: RPM
DECIMAL
TB3 ACTIVE-LOW
TB3 SET-PWM-IN
BEGIN
TB3 CHK-PWM-IN ?DUP
IF
TB3 SET-PWM-IN
CR ( D EMIT ( CR OR DEMIT
4 10 */ .
THEN
?TERMINAL
UNTIL
;

Please try this code and see if your results are different. It sets up the timer and when it gets a result it resets up and does the print while the next measurement is taken.

[jimturpin]

I tried the code, same problem persists, only there is a CR that changes the output which isn't a problem though, just different here (below). I did try various flow control on the terminal emulator just to see if there were characters being dropped. No change there either. I did notice the data continues to stream a second or two after I hit "esc" before I see the "OK", so I'm guessing it is buffering the output properly. Also, I tried to upload the o'scope output as a BMP, GIF and JPG so you could get a better feel for what I am looking at, but the site kept rejecting it as an invalid GIF, or JPG file. I did notice the high only goes to 2.32V. Do you think that perhaps there may be a DC threshold level issue here? FYI, I did try the DECIMAL code above from NMITech with the same results.

OK
RPM
470
4806
4797
477
4810
5285
471
470
4807
4798
5282
472
481
472
477
474
482
4806
4807
4804
471
4802
4810
5281
470
477
471
4806
5285
4802
471
481
477
469
4809
4812
4814
4809
472
4809
4823
474
4826
4824
5297 OK

[RMDumse]

Email the picture to LC via nmitech@newmicros.com and I'm sure he can put it up on the site for you.

It is interesting this signal seems to be either approximately 1 or 10x. Is it a RC Servo signal?

Yes it could be a signal level problem, but above 2V should be enough. You could try adding an extra pull up to get a higher voltage, but this is not likely the problem either.

[jimturpin]

well, just to make sure I didn't have some other problem, I set the pwm-out, then jumped that signal over to that particular input, and ran the code. Rock solid results. I will try to pull-up with a resistor just to eliminate that variable too... FYI, I am trying to measure the RPM's of a mirror by sensing a laser beam sweeping across a photo sensor. The mirror and motor is spinning very smoothly without much variation in rotation speed, and the waveform generated from that is very consistant.

Yes, it is strange it varies by a factor of 10. Maybe it is a strange threshold problem, and it is measuring the low and the relative high of the wave form, which is about what I am seeing as a high and low...

I'll get back after shortly and let you know what I find... thanks!

[nmitech]

Here is the new link for jimturpin's attachment files,

http://www.newmicros.com/temp/waveform.gif

http://www.newmicros.com/temp/TEK00002.jpg

[RMDumse]

What about a common ground? From the photocell circuit, to the 'Pod, there must be a common ground return.

Yes, using a PWM out to test against was a very good idea. I would have recommended it myself. So now we know more. It is not per sa a software problem.

I do notice that the 1x 10x corresponds very well with the high period and the low period, and one sample above seemed to be a whole period (high and low). So I am very suspicious the signal is capacitively coupled, as you would see with a missing return loop.

[jimturpin]

I checked the ground, around .3 ohms from the photosensor to the IsoPodX board. The photosensor has its own built in amplifier, and has a relatively low impedence output. I connected the photosensor supply to the 5vdc instead of the 3.3vdc, which brought its peak level to 3.12vdc with the low at 0vdc.

Here is the code and output:

: RPM
DECIMAL
BEGIN
TB3 ACTIVE-LOW
TB3 SET-PWM-IN
BEGIN
TB3 CHK-PWM-IN ?DUP
UNTIL
4 10 */ .
?TERMINAL
UNTIL
;

OK
RPM 5654 5656 402 403 402 403 5653 402 403 402 402 402 5658 402 401 404 403 402 402 5658 401 401 404 403 401 403 402 402 402 402 403 5657 402 402 402 5658 402 5656 403 402 401 402 5655 401 403 5653 401 5655 401 403 402 5654 401 5652 402 402 402 402 402 401 401 402 402 402 401 403 5656 402 401 402 5657 400 403 402 401 401 402 402 5658 5656 402 402 401 402 402 5656 401 401 403 402 400 402 402 402 5656 5656 400 5657 402 402 402 5656 402 402 401 401 400 402 402 5651 400 403 402 402 5656 402 402 401 5651 5652 400 402 402 401 5652 402 OK

 ?

I'm not sure what is preventing me from being able to read the duty cycle correctly, but I honestly I am getting side tracked with this issue, since all I am really interested in, is the period, since that is what I need to calculate RPM. Kind of like forgetting the mission was to drain the swamp and not fight off alligators, lol.. Anyhow, it is a learning experience, and I'm taking it at face value.

I'm still having problems uploaded the gif and jpg files, so I will email those in, just for reference.

One last thing, I noticed the time on the form web site is an hour off..

[nmitech]

jimturpin, Here are the Links to your new waveform images,

http://www.newmicros.com/temp/TEK00000.jpg

http://www.newmicros.com/temp/TEK00000.gif

The FORUM currently does not support file uploading or attachments. We are working on this next.

Still having timing problem with our VBulletin host. Sorry!

[RMDumse]

One thought. You might want to run this pulse through a Schmidt-trigger. Since we know the board counts correctly if you feed its own output into the timer pin, then it has to be related to the signal and its quality. Remember this chip is sensitive to noise spikes running up to 40,000,000Hz, so there could be edges there your scope cannot see that are causing false starts/stops. Signal conditioning is most likely the answer.

[jimturpin]

You are right, high freq noise could cause the problem, but I can't seem to see any. I'm using a 500Mhz digitizing oscope (Tektronix TDS 520B), and have searched for glitches as you mentioned. The output seems very clean, and consistant, even cleaner than the PWM-OUT output.

Perhaps it is time to take a different tact; how would you go about measuring the period of a pulse? I thought about creating a timer loop, that starts when the pulse goes high by toggling a flag, counts up, and keeps counting until it sees another high, which toggles the flag low, which at that point prints out the timer loop count.

Also, what if I used another timer input as that trigger/filter you mentioned, just simply looking for a high, which in turn triggers an output to go high, which in essence is telling the output to follow the input, then feed that output to the timer that is doing the pwm-in measurements? Have you heard anything as hare-brained? lol?

[jimturpin]

Gentlemen,

Signal conditioning is the solution! RMDumse hit the nail on the head!

I went out, grabbed a function generator, so I could generate a known, good clean signal, connected it to the input and the PWM-IN count stayed rock solid, pretty much regardless of the duty cycle and freq, at least in the range I'm working.

I added a little capacitance to simulate the slight “rounding” of the pulse I was seeing with the pulse the photo sensor/amp was generating, and “viola!”, the counter would start getting crazy the same way. Who would have ever thought a square wave had to be square. ;)

I stuck a simple hex inverter chip, CD74HC04E, in between to clean up the photo sensor output, and the timing code works properly now.

What was not evident in those waveforms I sent in earlier, was the relatively slow rise time of what appeared to be a "good" clean pulse. Once again, thanks for all the help!

I included a “good” and “bad” pulse example for future reference.


http://www.newmicros.com/temp/GoodRise.gif


http://www.newmicros.com/temp/BadRise.gif

[RMDumse]

Whew! Good news.

I will not bother with the other timer approach then. Actually, the PWM-IN uses the setup on the timer to count while the timer is gated. So we could have set it up "by hand" but we would have gotten the same result if we chose the same setting. We could have resorted to a software approach, but that would never have been as accurate as the hardware supported function. So squaring up the signal so the hardware can work is the best solution.

Glad we were able to help.