I tried the hardware solution but I havent figured out how to see what the controller is sending to the receiver. The software solution appears to work but my values dont fall on the right channels. could you please post your current code? I think my timing is off.
Blank254: the final code from Cparker is just the data capture section of the code. To be useful it needs at minimum the code below to find the index pulse for you.
'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
'assumes Channel is from 1-6
so to get a value for channel one you'd use "temp((N+1)//7)" (i hope expressions work for array indexing) If you get any 0 or 1 values in the temp array that means that the timing is off. Add another "random" statement or even a "pause 1" to solve this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
Update. Here is a video of our father/son summer geek project. This is just a protoytype (I know it's not pretty). We have a larger chassis on the way. We've learned a ton about motor control over the last few weeks. Some highlights:
1. We're using the vex 6-channel radio and receiver. We're decoding the vex pulse with the BS2 pretty well. It glitches now and then. It can probably be smoothed over with some defensive coding. Autonomous rather than manual control is more our goal, so we don't really need 100% smooth radio control.
2. The chassis is a Tamiya Construction Crawler. It's a good platform, though it's a little small. It has two tiny little 3v motors, one for each tread.
3. We're using the L298 Motor Driver Kit from solarbotics. I added a heat sink on to the L298, and it gets very hot after operating for about 20 mins
4. We're using 6 2500 mAH batteries for the motors, and a separate 9v for the stamp (common grounds of course). We hit the common-newbie pitfall of the stamp resetting when the motors were drawing a lot of current. With the separate batteries we see no resets
5. We're using the PWMPAL to generate pulses to the motor driver's enable lines in order to control speed. We're using the other 4 control lines to control direction.
Our new chassis is a 1:12 scale tank. 32" long, 12" wide, so we'll have plenty of room for sensors. We want to integrate the ping, and maybe a metal detector along with a crane/electro magnet to gather metal objects.
The most fun part (for me) was developing the code that translates radio stick movement to motor control (spin vs. slight steering right/left etc).[noparse][[/noparse]url]
Does anyone have a rudimentary pinout diagram and more details on operational code? This would be a great upgrade to publish here for RC of the Boe-Bot...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */ BotConnect.com
Post Edited (slashsplat) : 9/22/2007 12:17:44 AM GMT
Oh yeah. I saw that. And even toyed with the idea of going over to the other side (SX). But it IS a really valuable resource to see the dynamics of interpreting the stream. Wanted to make sure nobody missed it.
On eBay, they are Buy It Now at $14.99 plus $14.95 freight. Bids start at $13.99 best case with $14.99 shipping. search.ebay.com/search/search.dll?from=R40&_trksid=m37&satitle=vex+transmitter&category0=
I am sure somebody occasionally offers one for $10, if you are willing to wait.
AllElectronics shipping is only $7 for any quantity, and I get other stuff there in the same order...
(But their shopping cart is broken right now for FireFox so use IE.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */ BotConnect.com
I have noticed considerable time has been spent in the decoding of the Vex Receiver from
the posts I have read.· Did anyone try the BS2 code ?· Did it work ?· How about the hardware solution with the 4017 ?· I would like to use this for our robotics classes here in Montana.
I tested the hardware solution, and I was close... It would have worked but Ch1 combined the SYNC with the Received pulse width value.(All other channels were fine)· A simple inversion to the clock signal going into the 4017B did the trick.
I have included a Propeller Spin File that I used to generate a VEX signal based on the documentation that Jon Williams provided here... http://www.allelectronics.com/spec/JS-6.pdf
The attached images show what the Output from the 4017 looks like...
dcp_2140 shows a pulse width of 1uS when the VEX width is 500uS.
dcp_2141 shows a pulse width of 2uS when the VEX width is 1500uS.
The "additional" width comes from the Servo frame pulse which has a fixed width of 500uS.· The result is the fixed 500uS width plus the width of the Vex pulse. This is ok though, because in most cases there's no further translation that you need to do in order to drive a standard servo that expects a pulse width ranging from 1mS to 2mS. In fact, you could drive a servo directly from the pin of the 4017B without having to go through a microprocessor. You only need to do that if you want to further condition the signal or use it for something other than a servo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/21/2007 1:52:40 AM GMT
Thank you Beau !·· Nice design.· Just for fun I went through my old radio controlled goodies from years gone by.· I placed a VEX xtal in an old Challenger 620 FM receiver and it worked with the VEX transmitter !· Range was at least 75 feet (from the kitchen wall to my office).· So I must conclude that the VEX is not as complex as I had surmised.· I plan on bread boarding the 4017 circuit soon, thanks again.· Oh, since you are a Parallax guru have you or do you know of a complete program listing for the BS2 solution to the VEX receiver.
"...have you or do you know of a complete program listing for the BS2 solution to the VEX receiver." - None other than what is in this thread.
There really shouldn't be a myth to the VEX signal. The VEX signal is just as typical as any other multiplexed transmitted signal. The only thing that VEX didn't do is add the extra layer of hardware that·we are used to working with that de-multiplexes the channels into nice neat ordered positions. I have an 8-Channel Futaba transmitter that has nearly the same style of signal. The only difference is that the on-times are 300uS instead of 500uS, and the SYNC pulse is 2mS rather than 9mS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/21/2007 5:20:56 AM GMT
Beau and others who have put such an effort out to accomplish the BS2 solution,
For some unknown reason I can not view all the posts in sequence to extrapolate the complete working program.· I wonder if others are experiencing this as well ?· Can someone post·the complete working BS2 code to demodulate (TDM) the VEX receiver.
Let me rephrase my question,· Does anyone have a copy of a complete working program for the Parallax BS2 which interfaces with the VEX receiver ?· Could you please post it ?· Thank you.
The program that Lawson posted looks like it would work (clever use of RCTIME by the way Lawson) ... The only changes that he made were at the SYNC detection. I can't test his program at the moment but the code looks pretty straight forward, it should work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I think some of the timing with various commands and the way that they operate have been misinterpreted.· Last night I did a series of timing tests for various commands and configurations.
The method I used to time each command is below
[b]'Command Timing:[/b]
OUTPUT 0
TEST:
TOGGLE 0
'
'Command or sequence under test goes here
'
GOTO TEST
By placing a scope on pin 0, each Period will contain TWO passes of each command under test, so to get the time of one pass, simply divide the Period measured on the scope by two.
To create a baseline, run the minimal loop without any commands under test.· All subsequent tests will subtract this baseline time value.
[b]'Baseline Timing:[/b]
OUTPUT 0
TEST:
TOGGLE 0
GOTO TEST
·The general timing for each command and configuration using a BS2 and the method mentioned above is as follows:
[b]Timing Summary:[/b]
RCTIME Pin,0,temp 260uS ; temp defined as a WORD
RCTIME Pin,0,temp(0) 356uS ; temp defined as a WORD
RCTIME Pin,0,temp(N) 379uS ; temp defined as a WORD , N defined as a NIB
RCTIME Pin,1,temp 262uS ; temp defined as a WORD
RCTIME Pin,1,temp(0) 358uS ; temp defined as a WORD
RCTIME Pin,1,temp(N) 382uS ; temp defined as a WORD , N defined as a NIB
RANDOM temp(0) 447uS ; temp defined as a BIT
436uS ; temp defined as a NIB
425uS ; temp defined as a BYTE
420uS ; temp defined as a WORD
RANDOM temp 255uS ; temp defined as a BIT
244uS ; temp defined as a NIB
233uS ; temp defined as a BYTE
228uS ; temp defined as a WORD
NOP=0 185uS ; NOP defined as a BIT
179uS ; NOP defined as a NIB
176uS ; NOP defined as a BYTE
173uS ; NOP defined as a WORD
[b]'Timming Data:[/b]
'---------------------------------------------------------------------------------------------------------------------
'Time Test1: 'Baseline time required to TOGGLE pin and LOOP
'OUTPUT 0
'TEST: '<-- 404uS
'TOGGLE 0
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test2: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP
'OUTPUT 0
'TEST: '<-- 664uS ; 260uS for the RCTIME command (664uS - 404uS = 260uS) ; temp defined as a WORD
'TOGGLE 0
'RCTIME 3,0,temp
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test3: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP
'OUTPUT 0
'TEST: '<-- 760uS ; 356uS for the RCTIME command (760uS - 404uS = 356uS) ; temp defined as a WORD
'TOGGLE 0
'RCTIME 3,0,temp(0)
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test4: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP
'OUTPUT 0
'TEST: '<-- 783uS ; 379uS for the RCTIME command (783uS - 404uS = 379uS) ; temp defined as a WORD, N defined as NIB
'TOGGLE 0
'RCTIME 3,0,temp(N)
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test5: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP
'OUTPUT 0
'TEST: '<-- 666uS ; 262uS for the RCTIME command (677uS - 404uS = 262uS) ; temp defined as a WORD
'TOGGLE 0
'RCTIME 3,1,temp
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test6: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP
'OUTPUT 0
'TEST: '<-- 762uS ; 358uS for the RCTIME command (762uS - 404uS = 358uS) ; temp defined as a WORD
'TOGGLE 0
'RCTIME 3,1,temp(0)
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test7: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP
'OUTPUT 0
'TEST: '<-- 786uS ; 382uS for the RCTIME command (786uS - 404uS = 382uS) ; temp defined as a WORD, N defined as NIB
'TOGGLE 0
'RCTIME 3,1,temp(N)
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test8: 'time required to TOGGLE PIN , 'RANDOM var(0)', and LOOP
'OUTPUT 0
'TEST: '<-- 851uS ; 447uS for the 'RANDOM var(0)' command (851uS - 404uS = 447uS) ; temp defined as a BIT
'<-- 840uS ; 436uS for the 'RANDOM var(0)' command (840uS - 404uS = 436uS) ; temp defined as a NIB
'<-- 829uS ; 425uS for the 'RANDOM var(0)' command (829uS - 404uS = 425uS) ; temp defined as a BYTE
'<-- 824uS ; 420uS for the 'RANDOM var(0)' command (824uS - 404uS = 420uS) ; temp defined as a WORD
'TOGGLE 0
'RANDOM temp(0)
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test9: 'time required to TOGGLE PIN , 'RANDOM var' , and LOOP
'OUTPUT 0
'TEST: '<-- 659uS ; 255uS for the 'RANDOM var' command (659uS - 404uS = 255uS) ; temp defined as a BIT
'<-- 648uS ; 244uS for the 'RANDOM var' command (648uS - 404uS = 244uS) ; temp defined as a NIB
'<-- 637uS ; 233uS for the 'RANDOM var' command (637uS - 404uS = 233uS) ; temp defined as a BYTE
'<-- 632uS ; 228uS for the 'RANDOM var' command (632uS - 404uS = 228uS) ; temp defined as a WORD
'TOGGLE 0
'RANDOM temp
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
'Time Test10: 'time required to TOGGLE PIN , 'NOP=0' , and LOOP
'OUTPUT 0
'TEST: '<-- 589uS ; 185uS for the 'NOP=0' command (589uS - 404uS = 185uS) ; NOP defined as a BIT
'<-- 583uS ; 179uS for the 'NOP=0' command (583uS - 404uS = 179uS) ; NOP defined as a NIB
'<-- 580uS ; 176uS for the 'NOP=0' command (580uS - 404uS = 176uS) ; NOP defined as a BYTE
'<-- 577uS ; 173uS for the 'NOP=0' command (577uS - 404uS = 173uS) ; NOP defined as a WORD
'TOGGLE 0
'NOP=0
'GOTO TEST
'---------------------------------------------------------------------------------------------------------------------
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
The PULSIN function is fast enough to decode the VEX signals without staggaring them!!
Based on my timing above, it was hard to determine the exact execution speed of the PULSIN command.· empirical testing revealed a minimum "ON" time of 215uS and a·minimum "OFF" time of 39uS.· About 4kHz much faster than VEX is able to spit it out.
[b]'TESTED BS2 VEX Receiver CODE[/b]
' {$STAMP BS2}
' {$PBASIC 2.5}
temp VAR Word(7) 'stores raw pulse lengths
N VAR Nib 'general loop index pointer
Sync VAR Nib
vex PIN 0 'this is the pin the VEX reciever is hooked to
Main:
PULSIN vex,0,temp(0)
PULSIN vex,0,temp(1)
PULSIN vex,0,temp(2)
PULSIN vex,0,temp(3)
PULSIN vex,0,temp(4)
PULSIN vex,0,temp(5)
PULSIN vex,0,temp(6)
FOR Sync=0 TO 7
IF temp(Sync)>2000 THEN EXIT
NEXT
DEBUG CRSRY, 0
FOR N=Sync TO 6+Sync
'Note:
' Use (N - Sync)//7 to Decode the Channel Number ; Channel Number 0 is the SYNC
' Use temp(N//7)*2 to Decode the Channel Value
IF (N - Sync)//7 = 0 THEN
DEBUG " SYNC = "
ELSE
DEBUG "Channel = "
ENDIF
DEBUG DEC (N - Sync)//7,TAB,"Value = ",DEC temp(N//7)*2," ",CR
NEXT
GOTO Main
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/25/2007 5:31:03 AM GMT
well! that makes things simpler. I figured it took longer to re-enter a PULSIN. Using PULSIN does simplify the synchronization to the Vex's pulse stream. This same basic code should also work with normal RC receivers if the equivalent signal pin is found.
most cool,
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
Lawson, ·
I tried the RCTIME method and could not get stable results. I think only because RCTIME does not have a proper framing reference·for each individual pulse and I was observing a "picket fence" nyquist effect.· RCTIME only looks for a transition from LOW to HIGH or HIGH to LOW, whereas PULSIN looks for a LOW-HIGH-LOW or a HIGH-LOW-HIGH.·· To visualize what I think happens, here is an illustration showing where PULSIN is in relation to the pulse stream vs. where RCTIME is in relation to the pulse stream....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/25/2007 5:24:08 AM GMT
Sorry if I'm a little slow here. The circuit you posted, with the 4017, does that provide standard PWM signals that a speed-controller would understand at the 6 outputs?
If what you are connecting to, be it a standard servo or an ESC expects a 1-2mS input signal, then yes, the 4017 circuit is a complete hardware solution.
The two images below show the output directly from one of the pins on the 4017 with a 1mS pulse and 2mS pulse·EVEN though the VEX signal was a 500uS pulse and a 1500uS pulse respectively.· Because of the 500uS framing pulse used in the VEX signal... the output result of the 4017 is the sum of the frame pulse·plus the·500uS to 1500uS VEX value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/30/2007 3:58:58 AM GMT
Cool. I managed to pickup TWO of the VEX transmitter kits here for $12.99 each (Canadian) at a local shop and I'd love to use them on a robot I'm building with my kids. I'm using surplus windshield wiper motors with 6" wheels mounted directly to them so I needed to be able to interface with an ESC. Thanks again for the great work!
So, I'm looking around at controllers and I see that the cheapest one I can get is ~$50, and I need two. Then I stumble upon these: http://www.tncscooters.com/LB27.php . . . am I missing something here? Are these only analog in and not PWM?
Never mind. I figured it out. They seem to be POT driven, and, of course, they are one direction only. So, to make the equivalent of a ESC you'd need 2 plus electronics which prices them above robotic ESCs.
For those who subscribe to CIRCUIT CELLAR, this issue, Nov 2007, has a great article on the Vex Transmitter "Motor Driving for a Robotic Arm" by Jeff Bachiochi.
If you look at the electrical parts list, http://tncscooters.com/partsdb.php?type=ES you will find some controllers with reverse. It would be good to get more info on the speed control input requirements for these things because they are REALLY inexpensive. Ditto for the motors and other robot related parts.
Comments
so to get a value for channel one you'd use "temp((N+1)//7)" (i hope expressions work for array indexing) If you get any 0 or 1 values in the temp array that means that the timing is off. Add another "random" statement or even a "pause 1" to solve this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
Link to video: www.youtube.com/watch?v=EvaveI61OmU
1. We're using the vex 6-channel radio and receiver. We're decoding the vex pulse with the BS2 pretty well. It glitches now and then. It can probably be smoothed over with some defensive coding. Autonomous rather than manual control is more our goal, so we don't really need 100% smooth radio control.
2. The chassis is a Tamiya Construction Crawler. It's a good platform, though it's a little small. It has two tiny little 3v motors, one for each tread.
3. We're using the L298 Motor Driver Kit from solarbotics. I added a heat sink on to the L298, and it gets very hot after operating for about 20 mins
4. We're using 6 2500 mAH batteries for the motors, and a separate 9v for the stamp (common grounds of course). We hit the common-newbie pitfall of the stamp resetting when the motors were drawing a lot of current. With the separate batteries we see no resets
5. We're using the PWMPAL to generate pulses to the motor driver's enable lines in order to control speed. We're using the other 4 control lines to control direction.
Our new chassis is a 1:12 scale tank. 32" long, 12" wide, so we'll have plenty of room for sensors. We want to integrate the ping, and maybe a metal detector along with a crane/electro magnet to gather metal objects.
The most fun part (for me) was developing the code that translates radio stick movement to motor control (spin vs. slight steering right/left etc).[noparse][[/noparse]url]
www.allelectronics.com/cgi-bin/item/JS-6/search/6-CHANNEL_TRANSMITTER_AND_RECEIVER_.html
More info here:
http://forums.parallax.com/showthread.php?p=635586
Does anyone have a rudimentary pinout diagram and more details on operational code? This would be a great upgrade to publish here for RC of the Boe-Bot...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
Post Edited (slashsplat) : 9/22/2007 12:17:44 AM GMT
www.allelectronics.com/spec/JS-6.pdf
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
I think that if you read the article a little more closely you will find that the code is for a SX28 and not a Basic Stamp.
I am the one who started this thread in the first place to be able to do the VEX receiver conversion with a Basic Stamp instead of the SX28.
Just a thought.
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!
And here is a little more from another source:
www.kronosrobotics.com/Projects/VEXRadioInterface.pdf
Granted, it is another system, but each resource can have just one little piece of critical info...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
Post Edited (slashsplat) : 9/23/2007 5:47:19 PM GMT
www.allelectronics.com/cgi-bin/item/JS-6/search/6-CHANNEL_TRANSMITTER_AND_RECEIVER_.html
The shopping cart seems to be a bit broken, but they say they are in stock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
The VEX transmitter\receiver comb can be purchased on eBay for around $10 plus shipping.
Why pay $30 plus shipping?
Just a thought.
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!
search.ebay.com/search/search.dll?from=R40&_trksid=m37&satitle=vex+transmitter&category0=
I am sure somebody occasionally offers one for $10, if you are willing to wait.
AllElectronics shipping is only $7 for any quantity, and I get other stuff there in the same order...
(But their shopping cart is broken right now for FireFox so use IE.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
the posts I have read.· Did anyone try the BS2 code ?· Did it work ?· How about the hardware solution with the 4017 ?· I would like to use this for our robotics classes here in Montana.
I have included a Propeller Spin File that I used to generate a VEX signal based on the documentation that Jon Williams provided here... http://www.allelectronics.com/spec/JS-6.pdf
The attached images show what the Output from the 4017 looks like...
dcp_2140 shows a pulse width of 1uS when the VEX width is 500uS.
dcp_2141 shows a pulse width of 2uS when the VEX width is 1500uS.
The "additional" width comes from the Servo frame pulse which has a fixed width of 500uS.· The result is the fixed 500uS width plus the width of the Vex pulse. This is ok though, because in most cases there's no further translation that you need to do in order to drive a standard servo that expects a pulse width ranging from 1mS to 2mS. In fact, you could drive a servo directly from the pin of the 4017B without having to go through a microprocessor. You only need to do that if you want to further condition the signal or use it for something other than a servo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/21/2007 1:52:40 AM GMT
dcp_2137.jpg - Signal at Pin #14 of the CD4017B
dcp_2139.jpg - Simulated VEX signal from Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
"...have you or do you know of a complete program listing for the BS2 solution to the VEX receiver." - None other than what is in this thread.
There really shouldn't be a myth to the VEX signal. The VEX signal is just as typical as any other multiplexed transmitted signal. The only thing that VEX didn't do is add the extra layer of hardware that·we are used to working with that de-multiplexes the channels into nice neat ordered positions. I have an 8-Channel Futaba transmitter that has nearly the same style of signal. The only difference is that the on-times are 300uS instead of 500uS, and the SYNC pulse is 2mS rather than 9mS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/21/2007 5:20:56 AM GMT
For some unknown reason I can not view all the posts in sequence to extrapolate the complete working program.· I wonder if others are experiencing this as well ?· Can someone post·the complete working BS2 code to demodulate (TDM) the VEX receiver.
proftoy
Chuck in Montana
The program that Lawson posted looks like it would work (clever use of RCTIME by the way Lawson) ... The only changes that he made were at the SYNC detection. I can't test his program at the moment but the code looks pretty straight forward, it should work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I think some of the timing with various commands and the way that they operate have been misinterpreted.· Last night I did a series of timing tests for various commands and configurations.
The method I used to time each command is below
By placing a scope on pin 0, each Period will contain TWO passes of each command under test, so to get the time of one pass, simply divide the Period measured on the scope by two.
To create a baseline, run the minimal loop without any commands under test.· All subsequent tests will subtract this baseline time value.
·The general timing for each command and configuration using a BS2 and the method mentioned above is as follows:
[b]Timing Summary:[/b] RCTIME Pin,0,temp 260uS ; temp defined as a WORD RCTIME Pin,0,temp(0) 356uS ; temp defined as a WORD RCTIME Pin,0,temp(N) 379uS ; temp defined as a WORD , N defined as a NIB RCTIME Pin,1,temp 262uS ; temp defined as a WORD RCTIME Pin,1,temp(0) 358uS ; temp defined as a WORD RCTIME Pin,1,temp(N) 382uS ; temp defined as a WORD , N defined as a NIB RANDOM temp(0) 447uS ; temp defined as a BIT 436uS ; temp defined as a NIB 425uS ; temp defined as a BYTE 420uS ; temp defined as a WORD RANDOM temp 255uS ; temp defined as a BIT 244uS ; temp defined as a NIB 233uS ; temp defined as a BYTE 228uS ; temp defined as a WORD NOP=0 185uS ; NOP defined as a BIT 179uS ; NOP defined as a NIB 176uS ; NOP defined as a BYTE 173uS ; NOP defined as a WORD[b]'Timming Data:[/b] '--------------------------------------------------------------------------------------------------------------------- 'Time Test1: 'Baseline time required to TOGGLE pin and LOOP 'OUTPUT 0 'TEST: '<-- 404uS 'TOGGLE 0 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test2: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP 'OUTPUT 0 'TEST: '<-- 664uS ; 260uS for the RCTIME command (664uS - 404uS = 260uS) ; temp defined as a WORD 'TOGGLE 0 'RCTIME 3,0,temp 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test3: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP 'OUTPUT 0 'TEST: '<-- 760uS ; 356uS for the RCTIME command (760uS - 404uS = 356uS) ; temp defined as a WORD 'TOGGLE 0 'RCTIME 3,0,temp(0) 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test4: 'time required to TOGGLE PIN , RCTIME (mode 0 - input pin tied to Vdd) , and LOOP 'OUTPUT 0 'TEST: '<-- 783uS ; 379uS for the RCTIME command (783uS - 404uS = 379uS) ; temp defined as a WORD, N defined as NIB 'TOGGLE 0 'RCTIME 3,0,temp(N) 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test5: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP 'OUTPUT 0 'TEST: '<-- 666uS ; 262uS for the RCTIME command (677uS - 404uS = 262uS) ; temp defined as a WORD 'TOGGLE 0 'RCTIME 3,1,temp 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test6: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP 'OUTPUT 0 'TEST: '<-- 762uS ; 358uS for the RCTIME command (762uS - 404uS = 358uS) ; temp defined as a WORD 'TOGGLE 0 'RCTIME 3,1,temp(0) 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test7: 'time required to TOGGLE PIN , RCTIME (mode 1 - input pin tied to Vss) , and LOOP 'OUTPUT 0 'TEST: '<-- 786uS ; 382uS for the RCTIME command (786uS - 404uS = 382uS) ; temp defined as a WORD, N defined as NIB 'TOGGLE 0 'RCTIME 3,1,temp(N) 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test8: 'time required to TOGGLE PIN , 'RANDOM var(0)', and LOOP 'OUTPUT 0 'TEST: '<-- 851uS ; 447uS for the 'RANDOM var(0)' command (851uS - 404uS = 447uS) ; temp defined as a BIT '<-- 840uS ; 436uS for the 'RANDOM var(0)' command (840uS - 404uS = 436uS) ; temp defined as a NIB '<-- 829uS ; 425uS for the 'RANDOM var(0)' command (829uS - 404uS = 425uS) ; temp defined as a BYTE '<-- 824uS ; 420uS for the 'RANDOM var(0)' command (824uS - 404uS = 420uS) ; temp defined as a WORD 'TOGGLE 0 'RANDOM temp(0) 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test9: 'time required to TOGGLE PIN , 'RANDOM var' , and LOOP 'OUTPUT 0 'TEST: '<-- 659uS ; 255uS for the 'RANDOM var' command (659uS - 404uS = 255uS) ; temp defined as a BIT '<-- 648uS ; 244uS for the 'RANDOM var' command (648uS - 404uS = 244uS) ; temp defined as a NIB '<-- 637uS ; 233uS for the 'RANDOM var' command (637uS - 404uS = 233uS) ; temp defined as a BYTE '<-- 632uS ; 228uS for the 'RANDOM var' command (632uS - 404uS = 228uS) ; temp defined as a WORD 'TOGGLE 0 'RANDOM temp 'GOTO TEST '--------------------------------------------------------------------------------------------------------------------- 'Time Test10: 'time required to TOGGLE PIN , 'NOP=0' , and LOOP 'OUTPUT 0 'TEST: '<-- 589uS ; 185uS for the 'NOP=0' command (589uS - 404uS = 185uS) ; NOP defined as a BIT '<-- 583uS ; 179uS for the 'NOP=0' command (583uS - 404uS = 179uS) ; NOP defined as a NIB '<-- 580uS ; 176uS for the 'NOP=0' command (580uS - 404uS = 176uS) ; NOP defined as a BYTE '<-- 577uS ; 173uS for the 'NOP=0' command (577uS - 404uS = 173uS) ; NOP defined as a WORD 'TOGGLE 0 'NOP=0 'GOTO TEST '---------------------------------------------------------------------------------------------------------------------▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Based on my timing above, it was hard to determine the exact execution speed of the PULSIN command.· empirical testing revealed a minimum "ON" time of 215uS and a·minimum "OFF" time of 39uS.· About 4kHz much faster than VEX is able to spit it out.
' {$STAMP BS2} ' {$PBASIC 2.5} temp VAR Word(7) 'stores raw pulse lengths N VAR Nib 'general loop index pointer Sync VAR Nib vex PIN 0 'this is the pin the VEX reciever is hooked to Main: PULSIN vex,0,temp(0) PULSIN vex,0,temp(1) PULSIN vex,0,temp(2) PULSIN vex,0,temp(3) PULSIN vex,0,temp(4) PULSIN vex,0,temp(5) PULSIN vex,0,temp(6) FOR Sync=0 TO 7 IF temp(Sync)>2000 THEN EXIT NEXT DEBUG CRSRY, 0 FOR N=Sync TO 6+Sync 'Note: ' Use (N - Sync)//7 to Decode the Channel Number ; Channel Number 0 is the SYNC ' Use temp(N//7)*2 to Decode the Channel Value IF (N - Sync)//7 = 0 THEN DEBUG " SYNC = " ELSE DEBUG "Channel = " ENDIF DEBUG DEC (N - Sync)//7,TAB,"Value = ",DEC temp(N//7)*2," ",CR NEXT GOTO Main▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/25/2007 5:31:03 AM GMT
most cool,
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
·
I tried the RCTIME method and could not get stable results. I think only because RCTIME does not have a proper framing reference·for each individual pulse and I was observing a "picket fence" nyquist effect.· RCTIME only looks for a transition from LOW to HIGH or HIGH to LOW, whereas PULSIN looks for a LOW-HIGH-LOW or a HIGH-LOW-HIGH.·· To visualize what I think happens, here is an illustration showing where PULSIN is in relation to the pulse stream vs. where RCTIME is in relation to the pulse stream....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/25/2007 5:24:08 AM GMT
Statik
If what you are connecting to, be it a standard servo or an ESC expects a 1-2mS input signal, then yes, the 4017 circuit is a complete hardware solution.
The two images below show the output directly from one of the pins on the 4017 with a 1mS pulse and 2mS pulse·EVEN though the VEX signal was a 500uS pulse and a 1500uS pulse respectively.· Because of the 500uS framing pulse used in the VEX signal... the output result of the 4017 is the sum of the frame pulse·plus the·500uS to 1500uS VEX value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/30/2007 3:58:58 AM GMT
Statik
Statik
Statik
www.circuitcellar.com/magazine/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
BotConnect.com
If you look at the electrical parts list, http://tncscooters.com/partsdb.php?type=ES you will find some controllers with reverse. It would be good to get more info on the speed control input requirements for these things because they are REALLY inexpensive. Ditto for the motors and other robot related parts.
Rick