Using PULSIN to decode VEX rcvr pulse train
Hi all,
Is the BS2 fast enough to decode the pulse VEX receiver pulse train output, shown in the following article by John Williams, using the PULSIN command:
······································ http://www.allelectronics.com/spec/JS-6.pdf
Here is my analysis:
The sync pulse is 9 ms long and each servo pulse is from 1ms to 2ms long (0.5ms to 1.5ms plus the 0.5 framing pulse).
All the SX28 decoder s/w is doing is incrementing a counter and looking for a sync pulse period of around 9 ms when the ppm line transitions from a high to the sync pulse low.
The trick is to make sure that the controller is not looking at a servo pulse as a sync pulse.
I believe that the BS2 PBASIC PULSIN command can be used to detect the beginning of the sync pulse and the variable portion of each servo pulse.
For the sync pulse, all the BS2 PULSIN command has to do is look for a high to low transition that is longer than say 4ms since this period is longer than the longest servo pulse.
Once the sync pulse is detected, then the PBASIC program has a maximum of around 0.5ms (the length of the framing pulse) to detect the high to low transition of each servo pulse which can be from 0.5ms to 1.5ms.
The possible inability of the BS2 to be ready to detect the first servo pulse using the PULSIN command, after detecting a sync pulse, might not be a problem as the servo pulse framing pulse is·consistently in the neighborhood of 0.5ms. The BS2 can then be ready to use the PULSIN command to detect the high to low transition of the start of the variable part of the servo pulse.
The 0.5ms framing pulse can be adjusted accordingly by checking the first servo pulse length and adding 0.5ms +/- a fudge factor to make the servo pluse length value proportional to the joystick position.
I believe that a BS2 and either a BS2px or an Atom 28 ( I happen to have both microcontrollers in-house) could be fast enough to capture the leading edge transitions. As a matter of fact, the Atom 28 is probably fast enough to do the decoding of the servo pulse string the way John Williams did with the SX28 code.
Comments?
Chris Savage, can you help out here?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
Is the BS2 fast enough to decode the pulse VEX receiver pulse train output, shown in the following article by John Williams, using the PULSIN command:
······································ http://www.allelectronics.com/spec/JS-6.pdf
Here is my analysis:
The sync pulse is 9 ms long and each servo pulse is from 1ms to 2ms long (0.5ms to 1.5ms plus the 0.5 framing pulse).
All the SX28 decoder s/w is doing is incrementing a counter and looking for a sync pulse period of around 9 ms when the ppm line transitions from a high to the sync pulse low.
The trick is to make sure that the controller is not looking at a servo pulse as a sync pulse.
I believe that the BS2 PBASIC PULSIN command can be used to detect the beginning of the sync pulse and the variable portion of each servo pulse.
For the sync pulse, all the BS2 PULSIN command has to do is look for a high to low transition that is longer than say 4ms since this period is longer than the longest servo pulse.
Once the sync pulse is detected, then the PBASIC program has a maximum of around 0.5ms (the length of the framing pulse) to detect the high to low transition of each servo pulse which can be from 0.5ms to 1.5ms.
The possible inability of the BS2 to be ready to detect the first servo pulse using the PULSIN command, after detecting a sync pulse, might not be a problem as the servo pulse framing pulse is·consistently in the neighborhood of 0.5ms. The BS2 can then be ready to use the PULSIN command to detect the high to low transition of the start of the variable part of the servo pulse.
The 0.5ms framing pulse can be adjusted accordingly by checking the first servo pulse length and adding 0.5ms +/- a fudge factor to make the servo pluse length value proportional to the joystick position.
I believe that a BS2 and either a BS2px or an Atom 28 ( I happen to have both microcontrollers in-house) could be fast enough to capture the leading edge transitions. As a matter of fact, the Atom 28 is probably fast enough to do the decoding of the servo pulse string the way John Williams did with the SX28 code.
Comments?
Chris Savage, can you help out here?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
Comments
Or like you suggested, an initial "PULSIN pin, 1, result" could be used in a tight loop to detect the frame start pulse, then repeated "RCTIME pin, 1, result" commands could be used to detect the end of successive position pulses. hm... syncing a frame would be a bit spotty, because the the PULSIN loop could take 2-3ms to get back into the PULSIN command after finding any pulse. (if the inter-frame delay is long enough this won't be a problem.) Also, each channel would have a different zero offset. (this method assumes that the time from pulse to pulse is constant, and shorter than the time it takes for PULSIN and/or RCTIME to exit and re-enter)
Blowing smoke,
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
If you read the description by John Williams in the pdf file in my first post, the pulse train from the VEX receiver has a sync (pulse train start) pulse of around 9ms and each servo pulse is preceeded by 0.4-0.5ms high to low frame pulse which is somewhat different than your description.
Chris,
My main concern is that once the PULSIN command has detected the 9ms sync pulse how long before another PULSIN command will be able to be executed to start decoding the servo pulses. I do not believe that the BS2 is fast enough to complete the detection of the 9ms sync pulse with the PULSIN command and be ready with a new PULSIN command to detect the beginning of the framing pulse, high to low transition (0.4ms), of the first servo pulse, a low to high transition of varying length (0.4ms-1.4ms).
Comments?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
If you follow the link in my first post at the top of this thread, you will see how 6 servo channels are muxed onto one serial output.
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
The BS2 has a resolution of 2 µs when measuring pulse width. As for timing between commands, please see the following website, courtesy Tracy Allen...Take care.
http://www.emesystems.com/BS2speed.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Thanks for the response and the link. Much appreciated!
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
The BS2 may not have the timing resolution between pulses to decode the VEX·pulse·standard.· However, there may be a simple hardware solution that would let you decode
the VEX pulse train.· A single 4017 Decade counter/divider IC configured as·a "Count to N and Halt" with·a couple of other components to decode the VEX sync pulse·should do it.
The "SYNC detector" is basically a missing pulse detector that resets the 4017 when the 500Hz 25% duty cycle·from the VEX pulse·skips a beat.
Note:
"500Hz 25% duty cycle" is a·worst case scenario (500uS "ON" 1500uS "OFF)
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 6/2/2007 7:03:03 AM GMT
A very elegant hardware solution! I assume that the pot is adjusted for proper missing pulse reset operation?
The only problem I see here is that there is no separtation between the individual servo pulses in the VEX receiver serial pulse train which would allow the BS2 time to be ready to read the next servo output channel with the PULSIN command. In other words, any BS2xx is too slow to catch the leading edge of the ~500us framing pulse that precedes each actual high to low transition of each individual servo variable ~1500us "OFF" pulse after measuring the preceding servo's "OFF" pulse length. Even using a tight loop counter to detect the high to low to high transition of the variable portion of each servo pulse would not allow the BS2xx to accurately measure the pulse length.
Or am I missing something here?
I am open to comments and suggestions. I hope to learn something here!
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
...Yes, the POT is used to adjusted for the proper missing pulse reset operation.
"The only problem I see here is that there is no separation between the individual servo pulses..." Right... this is a complete hardware decoder solution without using a micro controller. If you tied "N" to pin #5 of the 4017 and used CH1 through CH6, the output would be comparable to the SXB solution Jon has here ... www.allelectronics.com/spec/JS-6.pdf
As mentioned earlier, you could stagger the reads from the original VEX signal and read all of the EVEN channels first, followed by reading all of the ODD channels, repeating that cycle in a tight loop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
"As mentioned earlier, you could stagger the reads from the original VEX signal and read all of the EVEN channels first, followed by reading all of the ODD channels, repeating that cycle in a tight loop."
Yes, that thougt originally came to me when I was considering using Jon Williams SX28 hardware/s/w decode solution and measuring the servo pulse widths from the SX28 with a BS2.
Thanks for the help. Much appreciated.
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
I assume that the SYNC line which is an input to the CD4017 Reset input should not go HI (causing a chip reset) unless the SYNC detect input is LOW for longer than 1.5ms.
Therefore the POT should be initially set as follows:
CD4017 min logic HI= 3.5v
t=RC = 1 time constant = 63% of charging voltage = 3.2v
C=1uf
t= > 1.5ms
R = 1.5ms/1uf =1.5K minimum for 3.2v which is just below the HI reset threshold so the charging time to 3.5v will be guaranteed to be longer than 1.5ms.
Comments?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
Since the VEX sync pulse is 9mS I would start at about half of that just to be safe, so....
t= > 4.5ms
R = 4.5ms/1uf =4.5K minimum for 3.2v which is just below the HI reset threshold so the charging time to 3.5v will be guaranteed to be longer than 4.5ms.
Keep in mind also that the 2n3904 only discharges the cap to about .6V
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Thanks for the input. Very informative.
One other concern. The 1k resistor on the transistor base will act as the required pull-up resistor for the VEX receiver open collector output.
I realize that you want to pull enough base current to help put the transistor into saturation, but the receiver may have trouble sinking enough current to pull this line down for a logic LOW.
Jon Williams circuit shows a 10K pull-up resistor which minimizes the required sink current.
Comments?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
"The 1k resistor on the transistor base will act as the required pull-up resistor for the VEX receiver open collector output" ... Yes, that is correct. The 10K should be just fine on the transistor base.
Using a 4.7K resistor to replace the series 1K and 25K, and supplying a worst case scenario normal pulse train (500uS "ON" 1500uS "OFF"), the 1uF capacitor will only charge to about 1.4V before it's discharged
... if the "OFF" time is allowed to reach 2mS, then the charge on the 1uF capacitor reaches about 1.8V
... if the "OFF" time is allowed to reach 4mS, then the charge on the 1uF capacitor reaches about 2.8V
... if the "OFF" time is allowed to reach 6mS, then the charge on the 1uF capacitor reaches about 3.6V
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Thanks again for the fast response!
From what you have indicated in your last post, a 4.7K resistor should be adequate to allow the capacitor to charge to slightly above the minimum HI of 3.5v on the CD4017 reset input when the sync circuit input sees a 6ms LOW pulse or longer and will stay low during the individual servo pulses of ~2ms.
Correct?
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
That seems correct to me. If you or anyone puts this circuit together with a VEX unit as the signal source I would like to know.
I just happened to have a CD4017 lying around in a junk box and I simulated the VEX signal going to it with a Propeller unit. Works on this end, but the mileage may vary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I want to thank you for all of the support you have provided to arrive at an elegant solution to the VEX receiver decoding problem!
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
' {$STAMP BS2} ' {$PBASIC 2.5} 'note this program is a memory hog 'Assumptions: 'High time of the pulse train is constant 'Re-entering a RCTIME command takes longer than 500us. temp VAR Word(7) 'stores raw pulse lengths N VAR Nib 'general loop index pointer vex PIN 5 'this is the pin the VEX reciever is hooked to 're-entry to RCTIME takes >500us RCTIME vex, 0, temp(0) 'sync to pulse streem RCTIME vex, 0, temp(0) 'capture a pulse RCTIME vex, 0, temp(1) 'capture a pulse RCTIME vex, 0, temp(2) 'capture a pulse RCTIME vex, 0, temp(3) 'capture a pulse RCTIME vex, 0, temp(4) 'capture a pulse RCTIME vex, 0, temp(5) 'capture a pulse RCTIME vex, 0, temp(6) 'capture a pulse ' 're-entry to RCTIME takes <500us ' '(pulse lengths of 1 will indicate that this is happening) ' RCTIME vex, 0, temp(0) 'Sync to pulse stream ' FOR N = 0 TO 6 ' RCTIME vex, 0, temp(N) 'capture a pulse ' NEXT 'Find the indes of the sync pulse FOR N = 0 TO 6 IF temp(N) > 2000 THEN exit next 'N now contains the index of the start pulse 'to get the index of, say, Channel = 2 'use "(N+Channel)//7" To access the temp array 'dump this all with the debug command DEBUG DEC N, cr FOR N = 0 TO 6 DEBUG DEC N, " ", DEC temp(N), cr next END 'I hope everything was hooked up 'cause this program is a 1 shot.It's a memory HOG, and the zero offset may vary from channel to channel. Also, I'd recommend adding a section to pack the pulse lengths into bytes of a known order. This will make it easier for other code to read the servo positions, and this will allow four words and one nib to be recycled as temporary space for the rest of the program.
The commented out FOR-NEXT loop is included just in case the BS2 can re-enter a RCTIME command in less than 500us. Putting RCTIME in a loop should slow things down just enough to prevent this.
Once again this is THEORETICAL code based entirely off of the PDF provided. Hopefully it works :P
Best of Luck,
Marty
According to the following document, http://www.emesystems.com/BS2speed.htm , the BS2 RCTIME command takes ~240us to fetch and begin execution. The BS2sx can do it in ~140us and the BS2px is even faster. Therefore the <500us portion of your code will probably be the way to go.
What do you think?
Nice code. I really appreciate your input.
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
substitute this code to fix it.
Uncomment the RANDOM statement if this is used with the slower FOR-NEXT loop.
Marty
P.S. I'm using the RANDOM temp(0) as the equivalent of a NOP instruction. adjust this statement as necessary to get reliable performance
Post Edited (Lawson) : 6/4/2007 1:22:54 AM GMT
Thanks for the update.
I should be able to checkout your code on Thursday or Friday of this coming week.
I also plan to try Beau's hardware decoder too.
I had to work Saturday and Sunday of this last week and did not have enough time to do much of anything.
Also, the rechargeable battery for the VEX transmitter will not be here until Wednesday.
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send someone to save the world, you·better make sure that they like it the way it is!
I was recently given one of the VEX transmitter/receiver kits and I'd like to control my BOE-BOT with it.
Any chance one of you guys (who seem to be waay smarter than me) could write up a guide for interfacing the
two devices? If possible... detail WHY things work as well as how to do them (I want to learn, not be spoon fed).
If anyone is willing to tackle this, I'd appreciate as much detail as possible.
I'm sure I'm not the only one wondering about this, considering how cheap these things are now.
Thank you
My quick take (I'm no expert) is that using the 4017 gives you reliable seperation of the pulses without having to worry about the BS2 being too slow, but this requires using 6 IO pins if you want to decode all 6 channels.
If the BS2 is fast enough you can get by using one IO pin with Lawson's software solution.
Do I have it right?
Thanks!
CP
RCTIME vex, 0, temp(0) 'Sync to pulse stream
FOR N = 0 TO 6
RCTIME vex, 0, temp(N) 'capture a pulse
NEXT
If I instead use sequential individual rctime commands I end up with 1 as pulse width values on every other channel.
I'll post more when then project is completed.
Thanks for the help everyone!
CP
Good work!
It is always nice to be able to identify a software solution that works. Less hardware is better these days as software is a lot more flexible.
Regards,
TCIII
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you are going to send·a Robot·to save the world, you·better make sure it likes it the way it is!
the extra "RCTIME vex, 0, temp(0)" catches a glitch that'll shorten the width of the first measured pulse 10-20% of the time. This can show up on any channel.
anywho, COOL! I thought this up is a flash of somethingorother. totally theoretical, experimental confirmation is always the final word. (gha 1:00am, way past my bet time)
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
When I started experimenting with the vex radio and playing with the full ranges of the different channels I noticed that when some of the pulses get really short, it startes to throw off the pulse values of other channels. For example, when I move channel 1 and channel 2 to their 'minimal pulse' position (left and up I believe) the pulse values as read by the stamp for channels 3 and 4 get shorter. Also, I noticed that the value for the channel 1 pulse, which immidiately follows the synch pulse, is always a little bit higher in the idle state than the other channels. Both of these conditions are livable but I experimented a bit and was able to eliminate them both.
I ended up with the subroutine below, based on your first idea, which seems to work fine. It does occasionally seem to miss the synch pulse, so I call the subroutine until one of the values is > 2000. By the end of the night I was able to accurately decode all 6 channels. I'm ready to drive my motor controller.
Can't beat a $30 6-channel radio! (+ basic stamp cost of course)
Thanks again!
readRawVexPulses:
RCTIME vexReceiverPin, 0, vexChannels(0) 'sync to pulse streem
RANDOM vexChannels(0) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(0) 'capture a pulse
RANDOM vexChannels(1) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(1) 'capture a pulse
RANDOM vexChannels(2) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(2) 'capture a pulse
RANDOM vexChannels(3) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(3) 'capture a pulse
RANDOM vexChannels(4) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(4) 'capture a pulse
RANDOM vexChannels(5) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(5) 'capture a pulse
RANDOM vexChannels(6) ' blow some time
RCTIME vexReceiverPin, 0, vexChannels(6) 'capture a pulse
RETURN