We got um.
lynxmotion.com/Product.aspx? … egoryID=46
It’s a fun project! 8)
Hi Alan,
Actually it looks like they now sell the RF module:lynxmotion.com/Product.aspx?productID=676&CategoryID=46. The hard part is getting the gimbahls. I think I saw a differnt thread where some people were trying to make their own and went up and buying some used modules up on ebay…
On the receiver side, you can use the pulsin command to read them in, this can eat up a lot of the processing time, especially if you don’t guess at the right order to do the pulsins. You should read every other one in the order they are received, such that by the time the basic finishes processing the first pulse, and gets to the next pulsin, the pulse had not already started or you have to wait for a whole RC pulse cycle. That is why I wrote an assembly version where you can pass in an array to hold all of the pulse widths and a bit mask showing which pins you are interested in. Works pretty well, but you still have to go for a complete RC cycle… I think the code is up there on this thread, could be on a few others…
But it would be nice if you did not have to worry about it and had a receiver that simply knew what all of the values were and you could query it when you needed it. That is why for example Zenta used two processors on his phoenix… That is why I think it would be fun to try it using something like xbee, maybe I will take it up again.
Kurt
Great!
Any other components available? I don’t recall seeing any joysticks, keyboards, or slider pots. Although I probably have all that stuff laying around.
Didn’t ketch what the receiver side had in addition to the dual (?) receivers (Diversity?). 7 PWM channels to decode?
In a robot I custom built and just shipped, I used a Superdroid board to decode receiver channels to run four PWM motor drivers and also operate a pair of relays. Are you doing something similar?
Alan KM6VV
Hi Kurte,
Yeah, Jim just sent the URL. I probably saw it when he announced it, but forgot.
Good joysticks I’ve got. I’ve interfaced them before. I like the idea of being able to get into things for a XMTR, but I’m interested in a digital link, rather then sending several channels of PWM. Then data could be sent as well. XBee would be a thought.
Thanks for the comments on reading the PWM into the uP. Sounds like a good candidate for a slave process over I2C.
Alan KM6VV
Sorry for joining this forumn so late and probably asking real basic questions. I am wanting to build a very similar remote and I have been going through the posts trying to figure out the basics without being too familiar with the atom. I wish to build something a lot simpler and am not planning on using the atom, just a microchip programmed in C or PicBasic. I don’t
need to to use the keypad or do any manipulation at the receiver side. I just want to make a custom transmitter and plug servos into the AR7200.
My understanding is I have to send 8 channels of data to pin 1 of the module. The thing I am confused about is the 400uS pulseouts (are they high or low) and the pause statements (are they high or low). The data is a pulse ranging from 1000uS? to 2000us? with a 400us pause between each channel that is subtracted out (is the 400 some randumn number Spektrum choose to distiguish the leading edge, can it be a different number?). Then I repeat the loop every 20 to 23mS? So I guess my primary questions is what should the pulses look like going into pin one of the module. Is the Spektrum looking for rising or falling edges to start counting? What are the max and min values for each channel? Do you need to send all channels? What is the max and min for repeating the loop? Sorry for a million question in one thread…
Thanks for any help with this matter, hopefully I will come back with some progress, but likely just more questions 
Hokay… A good place to start is with the pulse stream generation. For an understanding of what is happening is to look at the code. The pulses were being created on pin 15 (at least on the earlier versions), which was made low early in the program. That means the pulses are positive going. 
So at the beginning you create a 400uS pulse. But the time for the first position starts at the beginning, so you subtract 400uS from the desired pulse and pause that long. When that time elapses you create another 400uS pulse, then pause for the desired position (minus 400uS), etc. What you end up with is illustrated below.
Well I have like 5 minutes to finish this diagram, it ain’t looking good. I will give it a shot tomorrow. 
Ok here’s the diagram! 8) It’s pretty self explanatory, the pulses are 5vdc forgiving.
The connections to the module are very simple.
Pin 1 = Signal
Pin 2 = Power (have tested at 5vdc ok)
Pin 3 = Ground
If I understand the question right, that you want to generate the 8-servo waveform, then I’d suggest using two interrupts, one at a 2.5 mS rate in which you get the “current” servo channel, and load the PWM time into a second timer (generates 2nd interrupt) that times out to stop the pulse. The cycle repeats, and the next servo channel is serviced. Quite easy to generate 8 servo signal this way, or to toggle eight output pins to control eight servos directly.
Alan KM6VV
Thanks, I think I got it all now. I am going to start playing with my own code and save up for the AirMod. Should be a fund project 
Please let us know how it goes. We love to see DIY radios. 8)
Is there any more updates to to his thread like final code for tx and rx. it has been a most interesting thread to read. amaz
ing guys. ty for sharing. And any applications by the ppl that have built it and using on their bots, or has the ps2 controller taken over, as this thread is about a year old.
Hi there was code posted for the transmitter and I think code fro running it with the phoenix. Since this was completed, I personally on my unit have converted it over from the 2.4ghz system to XBEE based. There is another thread on that. With that I have posted code for the transmitter, as well as the phoenix. I also have code for the brat that still needs testing as well as for the rover.
Kurt
I recieved most the parts needed to proceed, just waiting on the key pad and LCD. I was going through the thread again and saw this part about using pull ups
But did not see any more. could you please shed a little more light on this part.
Thanks
I think I’ve figured out how to connect the the keypad. I’m just not sure what resistance i should use. I found several articles using 4k7,100ohms some help here would be helpful. This is how I’m read yo connect the 4x4 keypad is this correct?
I think we used 10K resistors. I added another 5 stitches to mine to control what is displayed, changing configurations and the like. I had a diagram of it, but Zenta made a much better diagram of it as you can see: viewtopic.php?f=21&t=5447&start=91
Kurt
Kurt,
Thanks I’ll add the 10K resistors and build in an upgrade path to add more switches later. Is your avatar a picture of your DIY remote control? Looks like it has an additional LCD.
Thank you
Phil.
Yep, my avatar is a picture of my remote control. Still using the original LCD. The thing toward the top is my XBEE that is on a board that used to be available from Selmware for holding an XBee and doing the level shifting… Can easily use sparkfun version as well.
Kurt
I added the 10K resistors to P4-7 and tried this code. I still haven’t recieved my LCD so used the terminal
[code]aa var bit
bb var bit
cc var bit
dd var bit
input p4
input p5
input p6
input p7
output p10
output p11
output p12
output p13
low 10
low 11
low 12
low 13
start:
high 10
aa = in4
bb = in5
cc = in6
dd = in7
serout s_out, i9600, [bin aa, bin bb, bin cc, bin dd]
low 10
high 11
aa = in4
bb = in5
cc = in6
dd = in7
serout s_out, i9600, " ",bin aa, bin bb, bin cc, bin dd]
low 11
high 12
aa = in4
bb = in5
cc = in6
dd = in7
serout s_out, i9600, " ",bin aa, bin bb, bin cc, bin dd]
low 12
high 13
aa = in4
bb = in5
cc = in6
dd = in7
serout s_out, i9600, " ",bin aa, bin bb, bin cc, bin dd, 13]
low 13
goto start[/code]
I get “1111 1111 1111 1111”
I think I might have something wrong 
Hi,
Since we are using pull-ups, we will only set one row to low and the others will stay high, with this the code will assume that a button is not pressed with a bit value of 1 and is pressed with a bit value of 0.
The current code does not set the values of the pins high it sets them to input (ie it lets them float). Why? I was afraid that if the user pressed two buttons and during the scan it ran into 1 pin being set to high being connected to another pin being sent low we would have a dead short… With it set to input, then the logical high is set by the pull-up resistor, so there is no direct short. I hope that makes sense.
The current code (which probably can be cleaned up looks like:
Row0 con 10 ; Row 0 on keypad
Row1 con 11 ; row 1 on keypad
Row2 con 12 ; Row 2
Row3 con 13 ; Row 3
col1 var bit ; Column values on keypad used in check keypad
col2 var bit
col3 var bit
col4 var bit
; P14 RXD ; HSERIAL
; P15 TXD ; hserial
RowB con 17 ; Cmd buttons new row
;==============================================================================
; [CheckKeypad] function
;
; Input Parameters:
; FCheckModeChange: Should we do checks for mode change? Currently always true.
;
; Variables updated:
; keypress - the ascii value associated with that key.
; Ver 2.0 - Add 4 buttons hang off of keyboard as an extra row...
; change Highs to inputs to keep possibility of dead shorts from happening
; when pressing multiple switches.
; BUGBUG:: Need to clean this up, maybe table drive?
;==============================================================================
fCheckModeChange var byte ; should we check for a mode change ?
CheckKeypad[fCheckModeChange]:
low Row0
input Row1
input Row2
input Row3
input RowB ; buttons we hacked on
col1 = in4
col2 = in5
col3 = in6
col4 = in7
bPacket(0) = 0 ; assume no buttons pressed
bPacket(1) = 0
keypress = " "
CmdBtnsPrev = CmdBtns
CmdBtns = 0
if fCheckModeChange then
fTModeChanged = FALSE
endif
;Read buttons - New version reads multiple keys as well are down.
; Process Row 0
if col1 = 0 then
bPacket(0).bit1 = 1
keypress = "1"
endif
if col2 = 0 then
bPacket(0).bit2 = 1
keypress = "2"
endif
if col3 = 0 then
bPacket(0).bit3 = 1
keypress = "3"
endif
if col4 = 0 then
bPacket(1).bit2 = 1
keypress = "A"
endif
; Process Row 1
input Row0
low Row1
col1 = in4
col2 = in5
col3 = in6
col4 = in7
if col1 = 0 then
bPacket(0).bit4 = 1
keypress = "4"
endif
if col2 = 0 then
bPacket(0).bit5 = 1
keypress = "5"
endif
if col3 = 0 then
bPacket(0).bit6 = 1
keypress = "6"
endif
if col4 = 0 then
bPacket(1).bit3 = 1
keypress = "B"
endif
; Process Row2
input Row1
low Row2
col1 = in4
col2 = in5
col3 = in6
col4 = in7
if col1 = 0 then
bPacket(0).bit7 = 1
keypress = "7"
endif
if col2 = 0 then
bPacket(1).bit0 = 1
keypress = "8"
endif
if col3 = 0 then
bPacket(1).bit1 = 1
keypress = "9"
endif
if col4 = 0 then
bPacket(1).bit4 = 1
keypress = "C"
endif
; Process Row 3
input Row2
low Row3
col1 = in4
col2 = in5
col3 = in6
col4 = in7
if col1 = 0 then
bPacket(0).bit0 = 1
keypress = "0"
endif
if col2 = 0 then
bPacket(1).bit7 = 1
keypress = "F"
endif
if col3 = 0 then
bPacket(1).bit6 = 1
keypress = "E"
endif
if col4 = 0 then
bPacket(1).bit5 = 1
keypress = "D"
endif
; Process Row B - Our 4 added on buttons.
input Row3
low RowB
col1 = in4
col2 = in5
col3 = in6
col4 = in7
if col1 = 0 then
CmdBtns.bit0 = 1
keypress = "W"
endif
if col2 = 0 then
CmdBtns.bit1 = 1
keypress = "X"
endif
if col3 = 0 then
CmdBtns.bit2 = 1
keypress = "Y"
endif
if col4 = 0 then
CmdBtns.bit3 = 1
keypress = "Z"
endif
; Check to see if the state of the command buttons has changed.
if fCheckModeChange and (CmdBtns <> CmdBtnsPrev) then ;
if (CmdBtns & CMD_UP_MASK) and ((CmdBtnsPrev & CMD_UP_MASK) = 0) then
; CmD Up button has been pressed
if TransMode = TMODE_MAX then
TransMode = 0
else
TransMode = TransMode + 1
endif
fTModeChanged = TRUE
elseif (CmdBtns & CMD_DOWN_MASK) and ((CmdBtnsPrev & CMD_DOWN_MASK) = 0)
; CmD Up button has been pressed
if TransMode = 0 then
TransMode = TMODE_MAX
else
TransMode = TransMode - 1
endif
fTModeChanged = TRUE
endif
if fTModeChanged then
gosub ClearLCDDisplay
bTDataLast = 0xff ; make sure we will display something when it changes.
endif
endif
return
Kurt
Ok, keypad now works correctly. I had forgotten to change the lows to High and vice versa. also found some loose wire crimps.
Thanks.