PDA

View Full Version : Servo32v5 errata - YouTube'ed



W9GFO
07-16-2009, 03:46 AM
I am using the Servo32v5 object to send pulses out on pins 1 through 12. I've just finished an object that measure pulses and have noticed that even though all 12 pins are supposed to be sending the same pulse(1520 uS), they are not.

Pins 1, 2, and 3 are 1520 uS (1517)
Pins 4, 5, 6, and 7 are 1519 uS (1516)
Pins 8, 9, 10 and 11 are 1520 uS (1517)
Pin 12 is 1519 uS. (1516)

I've made the assumption that pin 1 really is 1520, I had to add (3) to my counter value to get that number. In other words, the value in parentheses are the raw values - phsa/(cklfreq/1_000_000)

It appears that pins 4..7 and 12 are being shorted by one uS.

Is this expected behavior?

Rich H

Post Edited (W9GFO) : 7/18/2009 4:17:24 PM GMT

Timmoore
07-16-2009, 04:26 AM
Yes, the code handles 8 pins at a time, the time to process 8 pins is 1us at 80Mhz. So the time difference between pin1 in a group and pin 8 in a group can be 1us. So I would expect the pins early in a group to be up to 1us longer than the pins later in a group for hte same value.

W9GFO
07-18-2009, 03:20 AM
Timmoore said...
Yes, the code handles 8 pins at a time, the time to process 8 pins is 1us at 80Mhz. So the time difference between pin1 in a group and pin 8 in a group can be 1us. So I would expect the pins early in a group to be up to 1us longer than the pins later in a group for hte same value.


Very well then. I wrote something to add 1 uS to certain pins, I'm using pins 1 through 12. It is working as expected but today I was looking at it and I am wondering if there is a problem with the way I strung the booleans together. In the Propeller manual I didn't see an example of using multiple booleans in an IF statement, but I did notice the use of parentheses.




PUB out(pin, pulse)

if pin > 3 AND pin < 8 OR pin == 12
servo.set(pin, pulse + 1)
Else
servo.set(pin, pulse)



Would this work?



IF (pin > 3 AND pin < 8) OR (pin > 11 AND pin < 16) OR (pin > 19 AND pin < 24) OR (pin > 27 AND pin < 32)



Would this be any different, aside from being hard to follow?



IF pin > 3 AND pin < 8 OR pin > 11 AND pin < 16 OR pin > 19 AND pin < 24 OR pin > 27 AND pin < 32




There must be a better way to determine if a pin is part of four equally spaced groups - just can't think of it now...

Rich H

CassLan
07-18-2009, 03:23 AM
Can you tell the difference in the servo angle by a 1us increment in the pulse?

Rick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


NYC Area Prop Club (http://www.gothampropclub.com)

Prop Forum Search (Via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

ˇ

W9GFO
07-18-2009, 04:31 AM
I can't (or at least I haven't tried to), but when measuring the pulse widths, I'd like them to be exactly what they are commanded to be. I have made a servo tester that displays the pulse widths that are being sent. I want the value on the display to match the actual value going out.

Rich H

mpark
07-18-2009, 04:45 AM
I'm pretty sure you can replace
IF (pin > 3 AND pin < 8) OR (pin > 11 AND pin < 16) OR (pin > 19 AND pin < 24) OR (pin > 27 AND pin < 32)
with
IF pin & 4

Maybe
IF pin & 4 AND pin < 32
to be a real stickler about it.

Edit: D'oh, wasn't enough of a stickler:
If pin & 4 AND pin < 32 AND pin > 3

Post Edited (mpark) : 7/17/2009 10:48:40 PM GMT

W9GFO
07-18-2009, 05:31 AM
Much, much better!

Thanks!

Rich H

CassLan
07-18-2009, 05:36 AM
@W9GFO - No I hear what your saying, I was gonna say, those are some impressive Servos :)

Rick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


NYC Area Prop Club (http://www.gothampropclub.com)

Prop Forum Search (Via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)

ˇ

Ole Man Earl
07-18-2009, 06:41 AM
I have a prop oscope and servos hooked up. I will SEE if 1 us makes a difference you can see on servo. Give me a few minutes.
Earl

Ole Man Earl
07-18-2009, 06:55 AM
Ok, got the answer.
Elevator on my RC is :

1.0 ms Full Down (1000 us)
1.3 ms Centered (1300 us)
1.8 ms Full UP (1800 us)

Now, those are mili seconds.
You you would be hard pressed to see a 100 us variation!

Earl

Beau Schwabe (Parallax)
07-18-2009, 09:30 AM
W9GFO,

"I've just finished an object that measure pulses and have noticed that even though all 12 pins are supposed to be sending the same pulse(1520 uS), they are not." - I would be interested in taking a look at your code to see how you are reading the pulses.


The speculation that one group of 8 pins is delayed from one zone to the next is correct, but nut by 1us. Each zone "sees" a delay of 5mS between adjacent zones from the start of the servo pulse in one zone to the start of the servo pulse in the next zone. Opposite zones 1-3 and 2-4 will "see" a delay of 10ms across zones.

Within each zone, ALL 8 (if assigned to a servo) will produce a pulse (HIGH) at the exact same time. Depending on the pulse width value assigned to the servo channel, the output will drop out or go LOW if the counter value has exceeded the calculated pulse width.

Also, within the tight servo loop, the I/O pins are ONLY updated once every micro second so there is no chance for any staggering from one pin to the next within the same group.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

W9GFO
07-18-2009, 10:07 AM
Beau Schwabe (Parallax) said...
I would be interested in taking a look at your code to see how you are reading the pulses.


Hi Beau,

The code is in the Obex - RC Input... (http://obex.parallax.com/objects/482/)

I'm reasonably confident that it is not due to the way I am measuring the pulses. I'm using two separate boards, one is outputting the (identical) servo pulses to twelve pins. The other board is running the RC Input object. The thing is, I can move the lead from pin to pin and the value will change by 1 uS depending upon which pin I am measuring. It is always the last four pins in each group of eight that I read being 1 uS shorter. If my method of measuring was flawed I would not expect consistent repeatable results.

Since you say that all pins should output exactly as they are told, I will look into it further. Perhaps my code that sends the pulses is somehow subtracting a uS somewhere...

Please let me know if you see anything wrong with my RX Input code.

Edit: Just ran this code - same thing. I'm using just one lead to measure with by moving it from pin to pin. The value reported is either 1500 or 1499. There is definitely a different pulse length going to those pins.

Here's the code I used to send out the signals;



CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

Servo_Pin1 = 1
Servo_Pin12 = 12

VAR

long uS

OBJ

LCD : "LCD_16X2_8BIT_GG"
servo : "Servo32v5"

PUB Init

LCD.start
waitcnt(clkfreq/4 + cnt)
servo.start
LCD.clear
LCD.str(string("Servo32v5 Test"))
LCD.move(1,2)
LCD.str(string("Version 01 "))
waitcnt(clkfreq*2 + cnt)
uS := 1500
Drive

PUB Drive | i

LCD.clear
LCD.str(string("Pulse width is"))
LCD.debug(uS, 16, 2, false, 4, 0)

repeat
repeat i from Servo_Pin1 to Servo_Pin12
servo.set(i, uS)
waitcnt(clkfreq/50 + cnt)



Rich H

Post Edited (W9GFO) : 7/18/2009 3:35:12 AM GMT

W9GFO
07-18-2009, 10:41 AM
mpark said...

Edit: D'oh, wasn't enough of a stickler:
If pin & 4 AND pin < 32 AND pin > 3


How could it evaluate to true if pin were less than 4?

Ahh,... negative numbers.

I'll stick with the "if pin & 4". If pin is negative or over 31, there are bigger problems. http://forums.parallax.com/images/smilies/wink.gif

Rich H

W9GFO
07-18-2009, 10:49 AM
Ole Man Earl said...
Ok, got the answer.
Elevator on my RC is :

1.0 ms Full Down (1000 us)
1.3 ms Centered (1300 us)
1.8 ms Full UP (1800 us)

Now, those are mili seconds.
You you would be hard pressed to see a 100 us variation!

Earl


I can see a 10 uS difference easily on my standard Parallax (Futaba) servo. It has a 5 uS dead band. It helps having a servo tester that can be programmed to send whatever pulses you want at the press of a button. I suspect that if I looked real hard I could see the difference between pulses that are 6 uS apart on this particular servo.

Rich H

Beau Schwabe (Parallax)
07-18-2009, 11:36 AM
W9GFO,

You do realize that you don't need to keep updating the servo value every 20mS. That is the whole point of the Servo32 object, you set it and forget it. By placing it in a repeat loop, you could be affecting the timing determinism, but really 1us deviation is the normal Nyquist because that's as fast as the signal is being updated.

It also depends on how your reading the signal. I looked at your code, but did not see how it was able to measure the pulse. Looking at the signals on a scope, they all look like they are supposed to.


This portion of code can be reduced...



repeat
repeat i from Servo_Pin1 to Servo_Pin12
servo.set(i, uS)
waitcnt(clkfreq/50 + cnt)





...to something like this...



repeat i from Servo_Pin1 to Servo_Pin12
servo.set(i, uS)
repeat ' <-- this just keeps the cog alive


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 4:42:50 AM GMT

Ole Man Earl
07-18-2009, 11:48 AM
I should have said 10us not 100us
Earl
getting olderrrrr.......

Beau Schwabe (Parallax)
07-18-2009, 12:16 PM
W9GFO,

I would be willing to bet that you are experiencing Nyquist, especially since your 'RX' program is written in SPIN.


Something I did notice, in your RX code you are looking for a LOW-to-HIGH transition before you start counting. That's reasonable, but what if the LOW state is just on the edge of switching HIGH by the time you reset phsa or phsb and start looking for the signal to be HIGH? It could already be HIGH and you might lose some of your count in phsa or phsb resulting in a lower pulse width returned value. I would suggest looking for a LOW-to-HIGH-to-LOW transition before you reset phsa or phsab, look for a HIGH and start counting. Yes, you lose one of your incoming pulses, but you don't run as much risk missing the start of the rising edge.


EDIT:

just a thought... do you really want to reset phsa or phsb before you have detected a HIGH?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 5:25:35 AM GMT

W9GFO
07-18-2009, 12:57 PM
Beau Schwabe (Parallax) said...
W9GFO,

You do realize that you don't need to keep updating the servo value every 20mS. That is the whole point of the Servo32 object, you set it and forget it. By placing it in a repeat loop, you could be affecting the timing determinism, but really 1us deviation is the normal Nyquist because that's as fast as the signal is being updated.


I do understand that. However, I expected to be able to update every 20 mS, the value of uS could be constantly changing.

I did change the code as you suggested but the behavior remains.


Beau Schwabe (Parallax) said...
... but really 1us deviation is the normal Nyquist because that's as fast as the signal is being updated.


Ok, does that mean that the last four pins in a group being shorted 1 uS is expected?


Beau Schwabe (Parallax) said...
just a thought... do you really want to reset phsa or phsb before you have detected a HIGH?


I dunno, I want the count to represent a single pulse so setting to zero before the pulse occurs makes sense. So far I have not seen the pulse deviate due to coming in at the very end of a low - and I have watched it for hours. Could be that it comes and goes so fast as to not be noticed - which is then ok as far as I'm concerned. The low-high-low before resetting phsa was in the code earlier. I removed it because I am passing on the values to servo32v5 and the saved time allows smoother movement of the servos. There's a small bit of jitter now, it's almost real-time.

I appreciate the input on my "RX input" object (really!) but I don't believe the missing uS is on the reading end. It will report 1500 uS all day long until I remove it from pin 1 and switch it to pin 4 (lead being moved to different pin on sending propeller, reading propeller pin remains constant), where it then reads 1499 all day long. I move it back to pin one and I get 1500. I can move the lead to any pin back and forth and the readings for each pin are rock solid. In other words I have never measured a higher pulse on pins 4-7 or pin 12 than is on the other pins. Those pins always read one uS shorter. There is no connection between the Propeller chip that is sending the pulses and the Propeller chip that is reading the pulses except for the one lead used to connect whichever pin is being read, and the power cable. That one lead stays on pin 1 on the reading side, it only switches positions on the board that has the Propeller chip which is producing the pulses. That is why I am confident that the pulses are not all equal, in a consistent and predictable manner.

Rich H

Post Edited (W9GFO) : 7/18/2009 6:06:37 AM GMT

Beau Schwabe (Parallax)
07-18-2009, 01:36 PM
W9GFO,

The only thing I can suggest, is to cross-probe your observations. What I mean is, set one servo output pin and use that against your RX inputs. Do that, and then move to a different servo output pin and test your RX inputs again. Do this one pin at a time to see where the failure is. ...I'm not sure the RX program is doing exactly what you think it's doing. I was testing it and removed one of the inputs and it still reported the pulse. Even moved it to another input and it reported the value on the wrong pin until I reset the RX board.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

W9GFO
07-18-2009, 02:15 PM
Beau Schwabe (Parallax) said...
I was testing it and removed one of the inputs and it still reported the pulse. Even moved it to another input and it reported the value on the wrong pin until I reset the RX board.


This is exactly what I have been doing, though hard to describe.

I have two identical boards made up. On board one I have the code running which calls servo32v5 to send a pulse of 1500 uS to pins 1-12.

On board two is running the RX input program. When the RX input starts up it checks to see which pins have pulses on them. In my case, I am only using pin 1, that is the pin with the lead, I start out with the other end of the lead hooked up to board one which is already running and sending out 1500 uS pulses. All the measurements are made using the same pin on board two.

At this point board 2 (RX Input) will show 1500 , 0 , 0 , 0 , 0 , 0. The other five inputs are not used - and will not work properly unless the program is reset.

Now disconnect the lead from pin 1 on the board where the pulses are being generated and move it to another pin. The pin which does the measuring on board two does not change. While the lead is not connected the reading will be frozen - as soon as a valid signal returns it will be displayed.

So the entire time we are using pin 1 on the board which is running RX Input. Yet it reports different values when connected to different pins on the board that is sending the pulses. And it always reports 1500 on pins 1,2,3,8,9,10 and 11 - and 1499 on pins 4,5,6,7 and 12.

Since I am using only 1 pin on the RX Input side I do not need to worry if it is reading on all it's pins equally (though I have checked and every pin does display correctly), the value changes predictably when the far end of the lead is connected to different pins on board one - the pulse producing board.

Maybe I need to make a video...

Rich H

W9GFO
07-18-2009, 11:20 PM
Here's an exciting video of me measuring the pulse widths of various pins.

The Missing Microsecond (http://www.youtube.com/watch?v=tcn9YqlDlvY).

Rich H

Harrison.
07-19-2009, 12:13 AM
There is indeed a 1us difference between the first 4 pins and the last 4 pins of each pin group. Attached are some scope traces that show the delay.

Up close view of the 1us difference between P0 (purple) and P4 (green):
http://forums.parallax.com/attachment.php?attachmentid=62346

Scope screenshots:
P0+P3.png - P0 and P3 pulse widths
P0+P4.png - P0 and P4 pulse widths (showing 1us diff)
P0+P4-diff.png - 200ns/div view of P0 and P4 falling edges (showing 1us diff up close)
P0+P8-delay.png - bonus screenshot showing the 5.001ms delay between pin groups

The code I used:



CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

OBJ
SERVO : "Servo32v5.spin"

PUB main | pin

SERVO.Start

repeat pin from 0 to 31
SERVO.Set(pin, 1500)

repeat
waitcnt(0)


Post Edited (Harrison.) : 7/18/2009 5:21:24 PM GMT

W9GFO
07-19-2009, 12:24 AM
Someday I need to get me a scope like that!

Thanks Harrison,

Rich H

W9GFO
07-19-2009, 12:50 AM
Hey I just noticed that your reported values are 1497 and 1496. I have been adding (3) to my values (in the RX Input object) because I assumed that the first four pins (in each group) were outputting what they are told but it looks like the first four are shorted by 3 uS and the last four are shorted b 4 uS. In which case I should remove the (+ 3) in my code to be spot on accurate.

So my fix is:



IF pin & 4
servo.set(pin, pulse + 4)
Else
servo.set(pin, pulse + 3)




Rich H

hover1
07-19-2009, 12:58 AM
@Harrison VERY nice screen shots! Shows expected 5ms delays between groups.

@W9GFO Rich, Good video. Looks like ServoBoss works as advertised. Nice kit. I use a similar product; Jeti Spin Box:

http://www.hobby-lobby.com/spin_box_programming_control_3082_prd1.htm

I like your product better since it has more I/O, bigger LCD, and the ability to upgrade. If you could add the servo transfer speed test, even better.

Jim

Mike Green
07-19-2009, 12:59 AM
Just for curiosity, what servos can really resolve pulses to a microsecond or so reproducibly?

W9GFO
07-19-2009, 01:04 AM
@hover1 Thanks! And thanks for the link, I had not seen that one before. I've been trying to think of a way to measure servo speed that doesn't rely on current draw.

Rich H

W9GFO
07-19-2009, 01:06 AM
Mike Green said...
Just for curiosity, what servos can really resolve pulses to a microsecond or so reproducibly?


I don't know... Sounds like something interesting to test. I do know that I have some servos that have zero dead band but most have a dead band of 5 to 10 uS.

Rich H

hover1
07-19-2009, 02:11 AM
Mike,
Many of the new Hitech Digital servos have a dead band of 2us and some have a dead band of 1us. In my opinion, I think one would find it hard to percieve a mechanical movment given a +/- 2us deviation. And given the slop in most RC vehicles, this would not make a difference.

In my past life, (installing and maintaining Gerber Photoplotters), accuracy and repeatability was the name of the game, (talking .002"). I have to relax my standards now; if I tell my elevator to go up, and it goes up, I'm happy.

I think the whole point of Rich's thread is the Servo32v5.spin object is not working as advertised. As far as RC use, it doesn't cause a problem as far as I can see, but if someone where to use it in a CNC application, it could have some implications. A missing pulse here and that would lead to inaccuracies. (Although someone might would be hard pressed to use 12 servos in a 3-axis situation).

Best,
Jim


Mike Green said...
Just for curiosity, what servos can really resolve pulses to a microsecond or so reproducibly?

Post Edited (hover1) : 7/18/2009 7:17:06 PM GMT

Beau Schwabe (Parallax)
07-19-2009, 02:30 AM
Harrison,

It's very interesting to me that the offset is exactly 1us. I need to investigate this further, but looking at the servo32 software, this doesn't make sense to me at the moment. There are a lot of clock cycles in 1us and to cause this much difference needs to be resolved. I am always open to any suggestions or ideas.


Edit:

I think I have solved why this might be happening after the 4th pin in each group....

for every pin in the group, it is compared against the cnt value ..<-- which increments within each pin group by 8 system clocks (100ns) every pin. By the time you get to the 5th pin, you have 500ns that have passed which is enough to hit the Nyquist of the "tight servo loop" causing the output to "snap" to the next 1us interval.




'----------------------------------------------Start Tight Servo code-------------------------------------------------------------
ZoneLoop cmpsub ServoWidth1, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift1 '(4 - clocks) Set ServoByte.Bit0 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth2, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift2 '(4 - clocks) Set ServoByte.Bit1 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth3, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift3 '(4 - clocks) Set ServoByte.Bit2 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth4, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift4 '(4 - clocks) Set ServoByte.Bit3 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth5, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift5 '(4 - clocks) Set ServoByte.Bit4 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth6, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift6 '(4 - clocks) Set ServoByte.Bit5 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth7, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift7 '(4 - clocks) Set ServoByte.Bit6 to "0" or "1" depending on the value of "C"
cmpsub ServoWidth8, cnt nr,wc '(4 - clocks) compare system counter to ServoWidth ; write result in C flag
muxc ServoByte, ZoneShift8 '(4 - clocks) Set ServoByte.Bit7 to "0" or "1" depending on the value of "C"
mov outa, ServoByte '(4 - clocks) Send ServoByte to Zone Port
cmp temp, cnt nr,wc '(4 - clocks) Determine if cnt has exceeded width of _ZoneClocks ; write result in C flag
nop '(4 - clocks) We actually had one instruction to spare
if_NC jmp #ZoneLoop '(4 - clocks) if the "C Flag" is not set stay in the current Zone
'-----------------------------------------------End Tight Servo code--------------------------------------------------------------





...A solution would be to read the cnt value only once within each loop and compare against the temp value.

That nop command might actually save the timing here so that the loop stays exactly at 1us. Let me make some changes and do some tests, but I think this is the answer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 7:54:15 PM GMT

John R.
07-19-2009, 06:12 AM
I'm with Mike on this. What's 1us? We're delving into the land of "The better is the enemy of the good."

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log (http://share.crustcrawler.com/JohnR/)

Beau Schwabe (Parallax)
07-19-2009, 06:32 AM
John R.,

I understand your point, "what's wrong with 1us", but if it's wrong it's wrong and it should be corrected.
Especially on a processor capable of 50ns instruction resolution.



W9GFO,

Try the attached modified servo32v6 and see if that at least fixes the timing inconsistency from pin to pin.
The pulse width differences on the scope could be rounding error in servo32, but I'll tackle that next after
the pin timing is reported to be consistent.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

W9GFO
07-19-2009, 09:29 AM
Beau Schwabe (Parallax) said...

W9GFO,

Try the attached modified servo32v6 and see if that at least fixes the timing inconsistency from pin to pin.
The pulse width differences on the scope could be rounding error in servo32, but I'll tackle that next after
the pin timing is reported to be consistent.


I just ran it and found no difference in pulse lengths between the pins, Meaning, all pins are the same value (yay!). They all report 1500 uS - or 1497 uS if I don't add 3 to the phsa count.

BTW, I think it's pretty cool that something programmed in Spin can measure down to the millionth of a second, with relatively simple code.

Thanks for your work on this object Beau.

Rich H

Edited in an attempt to be more clear

Post Edited (W9GFO) : 7/19/2009 3:47:23 AM GMT

Beau Schwabe (Parallax)
07-19-2009, 10:40 AM
W9GFO,

So, let me just double check what you are saying...

The timing inconsistency from pin to pin has been corrected in the latest servo32v6 object correct?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

hover1
07-19-2009, 10:52 AM
Just got back from seeing Transformers II for the first time. I did not see any jitters in their servos.http://forums.parallax.com/images/smilies/tongue.gifˇ
This is good news! But it still doesn't explain the 3us descrepancy when you issue 1500. I guess one step at a time. I'm sure it will be easier to find now that all zones seem to be playing together. I just wish I was a little further along with PASM.


W9GFO said...


I just ran it and found no difference in pulse lengths between the pins, Meaning, all pins are the same value (yay!). They all report 1500 uS - or 1497 uS if I don't add 3 to the phsa count.


Thanks for your work on this object Beau.



ˇDitto. Thanks Beau!

Jim

W9GFO
07-19-2009, 11:06 AM
Beau Schwabe (Parallax) said...
W9GFO,

So, let me just double check what you are saying...

The timing inconsistency from pin to pin has been corrected in the latest servo32v6 object correct?


Affirmative!

At least as well as I am able to measure.

Rich H

Beau Schwabe (Parallax)
07-19-2009, 11:43 AM
W9GFO,

Ok, I think I figured out the 3us discrepancy.

To be more accurate, the discrepancy is actually 3.65us or 292 clocks from when the initial SyncPoint is referenced to the counter. The overhead within each ZoneCore requires the 292 clocks for processing the correct pulse widths from the SyncPoint. Since there are 80 clocks per 1us ... 292/80 = 3.65us

So what I did after determining the SyncPoint at the start of each ZoneCore, I added a line that reads...



add SyncPoint, #296 'Add overhead offset to counter Sync point



...Why 296 rather than 292? Since I 'added' another PASM line of code, I also added 4 more clocks to the overhead,
so 292 became 296.

The purpose of adding to SyncPoint is to project a future amount of time that we actually want to start timing the pulse.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/19/2009 6:06:59 AM GMT

W9GFO
07-19-2009, 12:06 PM
Great! I am now showing 1503 on all pins - now I need to remove that extra (3).

Thanks again!

Rich H

Beau Schwabe (Parallax)
07-20-2009, 06:29 AM
Rich H,

OBEX updated to version Servo32v6 ...

obex.parallax.com/objects/51/ (http://obex.parallax.com/objects/51/)

... Good catch by the way on the error!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe (mailto:bschwabe@parallax.com)

IC Layout Engineer
Parallax, Inc.

W9GFO
07-20-2009, 09:53 PM
Beau Schwabe (Parallax) said...
Rich H,

OBEX updated to version Servo32v6 ...

obex.parallax.com/objects/51/ (http://obex.parallax.com/objects/51/)

... Good catch by the way on the error!!


Thanks Beau,

It is working perfectly as far as I can tell.

Rich H