PDA

View Full Version : understanding the pulse.



geckogrotto
- 25th February 2007, 17:34
I just got a scope recently and don't know everything about it but enough to play with it.

The signal im reading is about 300 mv and its a square wave.
Depending on the signal being sent the frequency changes.
Looks like in one state its repeating every 14ms and the other state its repeating every 6.5ms.

How do I read this information in on a pic in picbasic to see what its at?
PulsIn GPIO.4, 1,Pulselen
PulsIn GPIO.4, 0,Pulselen2
Both return 0 do I need a pullup or down on the signal or to use another command?

skimask
- 25th February 2007, 20:15
I just got a scope recently and don't know everything about it but enough to play with it.

The signal im reading is about 300 mv and its a square wave.
Depending on the signal being sent the frequency changes.
Looks like in one state its repeating every 14ms and the other state its repeating every 6.5ms.

How do I read this information in on a pic in picbasic to see what its at?
PulsIn GPIO.4, 1,Pulselen
PulsIn GPIO.4, 0,Pulselen2
Both return 0 do I need a pullup or down on the signal or to use another command?

What version of PBP are you using?

Are the PulselenX variables bytes or words? Probably should be words...

Are both of your grounds (the PIC and the signal being checked) connected? Probably can't check another signal with one wire, gotta have a common ground.

How fast is your OSC? The pulsin command might time-out before the pulse ends or the pulse width might be too long, both possibly because your OSC is too fast.

mister_e
- 25th February 2007, 20:31
with a 300mV of amplitude... i really want to know how a digital i/o of a PIC could make the difference between the low level, and the high.

You need to amplify the signal first or use a comparator interrupt to start/stop an internal timer, or feed it's output to a CCP module

many possibilities...

skimask
- 25th February 2007, 20:33
with a 300mV of amplitude...

DOH! missed that! :) I suppose it would only work if that 300mV of change is right near the TTL low-high switch point.

geckogrotto
- 26th February 2007, 00:32
Thanks for the replies.
I have no problem measureing a signal from another source thats at 270mV using 12f675 so I don't see why that would be the problem?

mister_e
- 26th February 2007, 00:37
because you're lucky?

look at the datasheet, the min voltage to be considered as HIGH level is written somewhere.

geckogrotto
- 26th February 2007, 01:21
Are you talking about VIL and VIH?
If so that means there have to be a 2V swing...

Thats to tell if its high or low, im not sure this is the same thing.
I have seen many other people using pics to decode the signal from a R/C receiver. The output of the receiver signal, the pulse width is no where near even half a volt.


I have done this with a 270mV signal on over 50 chips so im either really lucky or something else.


Again im new to all this but like I said I have never had any problems reading a pulse width off a rc receiver and thats at 270mV

mister_e
- 26th February 2007, 01:24
any model or datasheet for your receiver? Is it possible that it's open-drain output type? what happen if you place a 1-10K pull-up resistor on it's output?

And yup it's Vil and Vih. it may differ from one i/o to another depending if it's an TTL or shmitt trigger one.

0.3 v seems realllllly low to me. If it works... maybe your scope miss some noise or maybe you have some better receiver / pic.

still thinking you're lucky ;)

geckogrotto
- 26th February 2007, 01:28
No I don't have a datasheet for either Receiver.

I don't know what open-drain output type means :(

1K resistor made no difference using pulsin.

geckogrotto
- 26th February 2007, 01:32
I'm so stupid...
I didn't have the input pin set as input, works fine now

skimask
- 26th February 2007, 01:36
-> If so that means there have to be a 2V swing...
The difference between VIL and VIH is dependant upon the type of circuitry involved...generally speaking:
CMOS: 0= <1/2 Vdd, 1= >1/2 Vdd
TTL: 0= <.8v, 1= >.7Vdd

-> the pulse width is no where near even half a volt.
Pulse width is measured in time, not in quantity. If you are putting a meter on a line with a signal meant for a servo, what you are actually reading is the average DC voltage on that line. And 300mV seems about right consider that the signal isn't constant (50hz give or take) and is only around 1.5ms during those times.

-> I have done this with a 270mV signal on over 50 chips so im either really lucky or something else.
You probably haven't been measuring a 270mV signal. As stated in the paragraph above, you've probably been measuring a signal that swings from 0v to 5v, with an average DC value of 270mV.

-> Again im new to all this but like I said I have never had any problems reading a pulse width off a rc receiver and thats at 270mV
Again, R/C receivers don't output a signal that's around 270-300mV. It's definetely a signal that's repeating at a rate of 50hz, for about 1.5ms for every repitition. So if we do a bit of math on that...
50hz = one signal every 20ms. A centered servo wants a signal of around 1.5ms, generally between 1-2ms. Therefore, over a second, the total amount of time, on average, with a pulse width of 1ms, this signal is reaching 5v is about 20ms.
20ms out of 1000ms = (5v * 20ms) + (0v * 980ms) = .25V on average.

Does that work for you?

skimask
- 26th February 2007, 01:37
I'm so stupid...
I didn't have the input pin set as input, works fine now

I hate it when that happens :)

mister_e
- 26th February 2007, 01:38
http://www.mister-e.org/Pics/ROFL s h i t happen :D

don't worry, it happen to everybody one day or another... expert or newbie...

here's a few explanation of the open-drain output
http://en.wikipedia.org/wiki/Open-drain
http://www.acroname.com/robotics/info/concepts/opn_clct.html

geckogrotto
- 26th February 2007, 01:45
Thanks for the help guys hehe, question tho I was reading the voltage with a scope I thought that would give me an accurate voltage?

mister_e
- 26th February 2007, 01:48
well, if the i/o was set as an output, it's impedance become really low (assume a short) hence why the level was as this low.

Now what happen when you read it on a 'input configured' i/o?

and depending what your scope measure... the mean, RMS, peak-to-peak, results will differ

geckogrotto
- 26th February 2007, 01:58
I was measuring it before not connected to anything. Just connected to the ground pin and the probe to the signal pin.

I think I have enough to get me started now tho.

Bit confused about the signal its putting out, looking at the scope I can see what I need to do but using the pulsin data its kinda jumpy.

I have done the standard servos like mentioned above 1-2 ms constant freq but this signal is not a constant freq it seems. On the scope it looks like the width and freq changes.

Standard servo I don't remember the exacts but like 100 to 225 or something that would be the pulse width.
Can you explain what I should be reading on the pulsin when the freq changes?

mister_e
- 26th February 2007, 02:04
and how fast does it change?

will this help to do few reading and do and average... but reject those which are to away of the midpoint...

How about using count... or an internal timer?

what's the most important? the frequency or the duty cycle?

sorry i don't know anything in RC receiver.. :(

skimask
- 26th February 2007, 02:18
I was measuring it before not connected to anything. Just connected to the ground pin and the probe to the signal pin.

I think I have enough to get me started now tho.

Bit confused about the signal its putting out, looking at the scope I can see what I need to do but using the pulsin data its kinda jumpy.

I have done the standard servos like mentioned above 1-2 ms constant freq but this signal is not a constant freq it seems. On the scope it looks like the width and freq changes.

Standard servo I don't remember the exacts but like 100 to 225 or something that would be the pulse width.
Can you explain what I should be reading on the pulsin when the freq changes?

The frequency isn't changing, although it might look like it is changing based on what the rest of the servo's are doing. In other words, say you've got 4 servos...1-3 are all at one end with a pulse width of 1ms and the 4th servo is the one you're playing with. It'll look like one thing on the 'scope. Then if servo's 1-3 go to the other extreme at 2ms, the signal off the 4th servo will look like something else on the 'scope.

It might be a bit jumpy because the input frequency is 'only' 50hz or so, and it's supposed to vary a little bit. Play around with your trigger and 'sweep delay' if you have one on your 'scope. You should be able to get it to smooth out. I've got a Tek 2246A, 4 channel 'scope, I can plug 4 servo's into it at once and be able to see the pulse's on all 4 and they are all steady. But, I have to play with the trigger and sweep delay a bit before they steady out.

geckogrotto
- 26th February 2007, 03:16
skimask, I don't think this is the case.
This isn't a standard servo im working with, When I measure a signal from a standard servo I see what your talking about and it works as expected.

Here is a little pic to help explain I hope.


I don't know how to figure out to read the signal because is moving around unlike the standard servo signal.

Mister_e
Will reply to you in another post

geckogrotto
- 26th February 2007, 03:19
>>and how fast does it change?
Looks like its repeating every 14ms on one end and 6.5 on the other end.

>>will this help to do few reading and do and average... but reject those >>which are to away of the midpoint...

I'm not sure if that would work here

>>How about using count... or an internal timer?
I am not sure how to do that with the signal im getting.

>>what's the most important? the frequency or the duty cycle?
In this case I think its the frequency that matters. But I don't know how to get the freq from picbasic.

mister_e
- 26th February 2007, 03:23
only the duty cycle change, Ton+Toff remain the same. so using Pulsin to read it should work. case not, the internal timer would be perfect...



' just a snip... not the whole thing...
while InputIO=0 : wend ' wait for rising edge
Start timer
Whiel InputIO=1 : wend ' wai for falling edge
stop timer
copy Timer register to a variable
enjoy!


Or use an interrupt to start and stop the timer and dump the results to a variable.

mister_e
- 26th February 2007, 03:27
>>How about using count... or an internal timer?
I am not sure how to do that with the signal im getting.

forget the frequency, from your picture, it's only the dutycycle that change.



>>what's the most important? the frequency or the duty cycle?
In this case I think its the frequency that matters. But I don't know how to get the freq from picbasic.

to get frequency, you could use COUNT, but in your case it should always be the same.

geckogrotto
- 26th February 2007, 03:34
forget the frequency, from your picture, it's only the dutycycle that change.


are you sure? I don't know much about reading the scope but to me it looks like between signal 3 and 4 on my picture the freq of the pulse is changeing but not on 1 -2. I need to get this to work on the 2 and 3 example.

Am I reading the scope wrong?

mister_e
- 26th February 2007, 03:36
can you do some screen capture of it?

Sorry but i have to ask, Do you know the difference between DutyCycle and frequency?

F.EDIT : SORRY... yeah seems the last one is different.

:eek: can't tell you if it's normal or what... the only thing i see is to do some error trapping, frequency/duty cycle, averaging etc etc etc.

geckogrotto
- 26th February 2007, 03:39
I can try taking a picture of the scope.

I think I do, lol I may be wrong.

The duty cycle is how much of the cycle is on vs off.
The freq is how often the cycle restarts basically?

geckogrotto
- 26th February 2007, 03:41
Edits :)

Well the 2nd two signals are from a proprietary non uniform signal that im trying to figure out.

I think its normal for it to be like that, I just didn't know how use it.

From your previous post looks like count will help me here going to give it a go and let you know what happens :)

skimask
- 26th February 2007, 03:46
skimask, I don't think this is the case.
This isn't a standard servo im working with, When I measure a signal from a standard servo I see what your talking about and it works as expected.

Here is a little pic to help explain I hope.


I don't know how to figure out to read the signal because is moving around unlike the standard servo signal.



(reference the picture from the earlier post)
That's what my picture on my 'scope looked like when I had the 4 channels plugged in. If the first servo's pulse changed, the rest of the pulses changed with it (i.e. the 2-4 pulses slid back and forth) if I was triggering off Channel 1. and I was using a standard Futaba FM RX for aircraft.

What kind of servo is it? What brand or whatever?

geckogrotto
- 26th February 2007, 03:54
If your look at the pic there are 2 sets of signals.
top 2 are 1 signal(standard futaba)
bottom 2 are the 2nd signal (unknow)

The first 2 are from a standard servo signal. Thats normal futaba whatever.
No matter how long the pulse is the peaks start at a set interval.

The 2nd 2 are from off brand cheapo thing. It if you notice looks different than the top 2 at the same settings. When the low shrinks the pulses get closer.

I'm getting it now tho.

geckogrotto
- 26th February 2007, 03:55
Oh I think we may be comparing two seprate things skimask.
I'm looking at just one servo channel not all of them at once like I think you are.

geckogrotto
- 26th February 2007, 04:03
Ok that works like a charm measuring the freq will let me know exactly where the stick is :)

Thanks for all the help!


You guys rule.

mister_e
- 26th February 2007, 04:06
Nice! good luck!

skimask
- 26th February 2007, 04:08
Oh I think we may be comparing two seprate things skimask.
I'm looking at just one servo channel not all of them at once like I think you are.

Well, ya, I get what you've got cooking (I think)...but what I'm saying is that I'm looking at 4 channels at once on 4 seperate channel's on the 'scope. If the first channel's pulse width gets lengthened, the rest of the channels get slid back a bit, and vice-versa if the pulse width gets shortened.
BUT...if I look at the total string (i.e. the whole string of channels as they are all received with all the data on one line), at the end of the chain (in my case 8 channels), there's always a sync pulse of at least 4ms that 'resets' the receiver back to channel 1. So, if each channel's pulse width is 2ms with 8 channels, that's 16ms + a 4ms sync pulse. And there is also an 'inter-servo' (for lack of a better phrase) time of a few us or so. So, if you're looking, or maybe just concentrating on one channel, it may appear that the frequency changes a little bit because the pulse width is changing. It can change a little bit, but overall, it will keep happening at a rate of about 50hz.

Wait a minute... I forgot what you were trying to do in the first place...what's the end result supposed to be?

geckogrotto
- 27th February 2007, 02:16
hahah well the end result has been achieved already.

skimask
- 27th February 2007, 02:19
hahah well the end result has been achieved already.

WHAT? I missed it! Hey, where was I anyways?
Have you seen me lately? 'cause I owe me some money...and I'm going to kick myself when I find me...

What was the end result?

geckogrotto
- 27th February 2007, 02:38
WHAT? I missed it! Hey, where was I anyways?
Have you seen me lately? 'cause I owe me some money...and I'm going to kick myself when I find me...

What was the end result?

Well we differ on what we see when looking at the standard signal so I will leave that alone :)

I measure 1 signal pulse off one channel every 20ms no matter how long the pulse width is.
So say we have a 1.5ms HIGH pulse width. we get a rising edge and high for 1.5ms then for 18.5 its low. then repeats. If the high pulse is 1ms then its low for 19 so the new rising edge is always at the 20ms mark. that make sense? Talking single channel here no reset pulse when channels are done.

The new signal im messing with I can get a pulse that repeats between 5ms and 20ms depending on how long the pulse width is... and the pulse is low.
Hard to explain.
The new one has much longer pulses and they are LOW. (so I guess not really pulses just delays between the 1ms pulse)
Say we have a 10ms pulse... It goes low for 10ms then high for set time think its 1ms. then low to 10ms again. That would make 2 pulses in a 21ms range instead of 2 pulses in a 20ms range. With a 15ms pulse it would equal 2 pulses in a 31ms range.

Maybe im not explaining it correctly but on a standard the rising edge always starts at a set point every 20ms measuring 1 channel.

So basically I am using the freq off the new one and thats working instead of the width. I don't know how else to explain it. If I knew the proper terms maybe it would make more sense lol.

I do have another question tho :D

On a 4mhz chip how long would this take to add 1 and get back to while?

while GPIO.4=0
Nosig = Nosig + 1
wend

skimask
- 27th February 2007, 03:17
I do have another question tho :D

On a 4mhz chip how long would this take to add 1 and get back to while?

while GPIO.4=0
Nosig = Nosig + 1
wend

So, in my world:
one channel, idles low, 1-2 ms high going pulse, repeats every 20ms, no matter the high going pulse width

In your world:
one channel, idles high, 5-20ms low going pulse, repeats every 15-30ms depending on the low going pulse, minimum of 10ms idling high...

Is that good? Sure, you can get a freq off that.
And what I meant by the end result was...what is this whole thing running off of, what's it supposed to do in the end? Is this a new egg frying machine :)

As far as measuring the time in the above example, one way I do it is to write a program that is only the above example. I label every line. When done, I go back into the generated .lst file, find those labels, and write down the hex address for each label. Most instructions take 1 cycle (ie. 1us @ 4mhz clock rate), jumps, goto's, branches, etc. take 2 cycles (ie. 2us @ 4mhz clock). So, in your example (and I'm guessing here):

while GPIO.4=0 a 'bit test, skip if clear' instruction 1 or 2 cycles depending
Nosig = Nosig + 1 an 'add' instruction, 1 cycle
wend[/QUOTE] a 'jump' or 'goto', should be 2 cycles

So, this could be anywhere from 4 to 5 cycles depending on conditions. However, there are also bank bits to set sometimes if your code goes over code boundaries (not applicable in the 18F world) which will add 1 or 2 cycles. So, now you're at anywhere from 4 to 7 cycles per loop. Best way to figure it out is how I described it earlier. Or use MPLAB's IDE simulator and use the 'stopwatch' function. Or just build a prototype that'll work off it and toggle an led and 'scope those leds for freq.

geckogrotto
- 27th February 2007, 04:05
Ugg I typed up a reply but it didn't get posted.

Basically I get the same results as you do on the standard servo signal and the new results on the new one.

I'm not doing anything amazing or anything just trying to adapt a cheapo Tx Rx to a standard servo signal whoo hoo.

Also thanks for the help on the time, I don't need it that specific so 5us is close enough. Whats a few millionths of a second between friends hehe