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.
OK,i’m ready to add the gimbals. one question before i start. i don’t know what the green yellow and white wires do. it’s a hitec laser 4 transmitter. it looks like a pot. so i guess its white to 5V yellow to signal and green to ground is this correct? :
Jim or James could probably answer this one better than me as they built the first ones. I was starting to collect parts to build another one, but the gimbals that I collected were not from Hitec. The pots on these have Red white and black wires.
If you have a multi-meter I would recommend that checking the resistance between the pins of the pot, when it is at center and when you move it to both edges. My guess is you can connect one outside pin to +5v the other to ground and the center one to an analog input pin. You may want to check the different voltages and may need to adjust the program depending on how different it is. But since I believe that they used laser 4 gimbals in the first ones it may just work.
Kurt
Unfortunately I used up all the gimbals Hitec and I had. lol But as Kurt said it’s not difficult to ohm out the connections. Or just look at where the wires connect to the pot. The one in the middle is the one that varies when the joystick is moved. You can put 5vdc and ground on the outside pins. If the result is backwards you can reverse the outside pins.
Jim/Kurt
I thought the wire colors might have had a color code associated with them. I was able to get the gimbals hooked up, they seem to work as i see the display numbers change when moving the them. Thanks this also helped me get the sliders figured out 
I must agree with this as it was slim pickings to find them.
Thanks for the help
Phil
Hi All,
Sorry for my little to no knowing about botboard and basic Micro…
I have a spare transmitter that i just disassembled. I have “for now” just take one potentiometer and hook
it to a servo lead.
Ok… so now for understanding the programming and the hardware…
I want to connect that potentiometer to the board and send back the info on the serial port.
After that i would like to be able to send a command to the SCC-32 to move a servo accordingly to
that input…
Am i clear…?
(sorry again for my english)
Tanks
Eric Nantel
Qc Canada
Got something that work
Bit of code from one and another… llol
I have finally gotten in the Spektrum DX5 radios and we will be adding them to the store soon. We have to change some tutorials to add them to the kits. I believe Spektrum is the most reliable solution to 2.4ghz RC.
I did some comparisons, the DX5 goes for 100.00, but the DX6 goes for 200.00… Now on both radios the 4 channels for the 2 joysticks are obviously analog, but all the extra channels are 1/3 - 2/3 throw. In order to control a rover and a small arm you would need 5 analog channels. 2 for the motion of the rover and 3 for the simple arm. This condition is not met by either radio… However, if you take the guts from 2 DX5 radios you get the equivalent of a 10 channel radio with 8 analog channels and 2 (1/3 - 2/3 throw) channels. Yes you would have two receivers on the bot, but after binding the two receivers to the two radios it’s just a matter of turning them on one then the other. So for $200.00 - the same price as the DX6 - you get a 10 channel radio. Googling for a 10 channel radio shows 600.00 to 1400.00.
I think we may be able to make a case that would hold the guts from two DX5’s, and would require zero hacking. Just take the electronics out and put them into the new case. FCC shouldn’t care about this.
The other option would be to make a holder for the two radios side by side. Not the most elegant solution, but a workable solution none the less.
Of course there is also the possibility of swapping the pots on one of the radios to the pots inside modified servos to make an arm controller. Basically you make an arm with the servos modified to just be potentiometers, and plug the same axis servos of the real arm into the receiver, then the normal arm follows the modified one when it is moved. Of course doing this would void any warranty…
These are some interesting ideas that anyone could do without any programming whatsoever.
Anyway, just some ramblings… 
Hi Jim,
I’ve made this one:(1) 
potentiometers are not yet mount
Is it possible to order the moulded box? (2)
because I like the look, the texture of yours
thanks for your work
Sorry I’m not selling the boxes.
I just stumbled across this thread and fell in love Now with tax time around the corner this is going to be my first project of the new year. YAY, I’m excited.
You state this was a standard box and you ordered it custom machined. Can you disclose the Standard Boxes Part number/supplier? I have access to a mill so trimming the box down won’t be an issue. Also, would you be willing to share the top panels dimensions? A cad file would be sweet.