Servo32v5 errata - YouTube'ed
W9GFO
Posts: 4,010
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
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
Comments
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?
Would this be any different, aside from being hard to follow?
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
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
Rich H
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
Thanks!
Rich H
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
Earl
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'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
IC Layout Engineer
Parallax, Inc.
Hi Beau,
The code is in the Obex - RC Input...
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
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.
Rich H
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
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
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 4:42:50 AM GMT
Earl
getting olderrrrr.......
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
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 5:25:35 AM GMT
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.
Ok, does that mean that the last four pins in a group being shorted 1 uS is expected?
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
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
IC Layout Engineer
Parallax, Inc.
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
The Missing Microsecond.
Rich H
Up close view of the 1us difference between P0 (purple) and P4 (green):
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
Thanks Harrison,
Rich H
So my fix is:
IF pin & 4 servo.set(pin, pulse + 4) Else servo.set(pin, pulse + 3)Rich H
@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
Rich H
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
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
Post Edited (hover1) : 7/18/2009 7:17:06 PM GMT
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
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 7/18/2009 7:54:15 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log