Actually we should not get here. Notice the lines:
; If I did the right if valid the cs should be zero
if bXBeeCS = 1 then ; changed checksum to bias by 1 to not match old data...
return;
endif
So if we are falling through then the checksum is not matching. Note: I did hack up the code to add 1 so that it would not match the old save values. I assume you updated and saved a new set. Will verify on mine that I am getting the saved values…
Quick update, 
there was a bug in the read function:
[code]GetSavedJoystickRanges:
ReadDm JoystickRangesDMStart, [cbXBee, bXBeeCS]
#ifdef DEBUG
serout s_out, i9600, "Get Saved Joystick ", dec cbXBee, " ", dec bXBeeCS, 13]
#endif
if cbXBee = 24 then
ReadDm JoystickRangesDMStart+2, [str AtoDMinT8\12, str AtoDMaxT8\12]
for i = 0 to 5
bXBeeCS = bXBeeCS - (AtoDMinT8(i).lowbyte + AtoDMinT8(i).highbyte + AtoDMaxT8(i).lowbyte + AtoDMaxT8(i).highbyte)
next
; If I did the right if valid the cs should be zero
if bXBeeCS = 1 then ; changed checksum to bias by 1 to not match old data...
return;
endif
endif
; if we fail for some reason just default to our defaults...
AtoDMinT8 = 392*8, 416*8, 361*8, 426*8, 0, 0
AtoDMaxT8 = 636*8, 630*8, 598*8, 638*8, 1023*8, 1023*8
sound p9, [50\4000,50\3500]
#ifdef DEBUG
serout s_out, i9600, "GSJ ", dec bXBeeCS, 13]
#endif
return[/code]
The problem was the checksum code was changed earlier how it walked through the values, but the range of the for loop had not changed… First put in a sound statement to see if it was loading defaults… It was. Then I added debug print and clearly showed the value was wrong at which time I looked that the loop and went dah 
Kurt
You are welcome. But now that it is close to being done, I am considering tearing the whole thing apart again.
Actually I am somewhat serious. It may not be a nasty surgery, but I am thinking of trying XBEE API mode instead of transparent mode. Why? I think it might be a bit faster and later could add some more flexibility.
Disregarding the SSC transparent mode, I currently send the data in transparent mode in a form of packets, that look something like:
<seq#>[optional cb bytes].
In transparent mode, this is packaged up internal to the XBEE into It’s on API packet format and sent on to the other side which extracts the data from the packet…
<Length msb, lsb>, <01=data packet>
What you will notice is that in my own data packets I am replicating most of this same stuff: Byte count, chksum. Note on the receiving side this gets translated into RX packet 01->81, DL into source address, …
This could open up some interesting flexibility. For example we could define a couple of things we communicate with. For example maybe on your phoenix you wish to send and receive stuff from the remote control, but in addition to this, maybe you wish to define a debug or logging port to send stuff to, like a terminal or VB program running on your PC. In transparent mode to switch back and forth you would have to enter command mode (2 20ms waits, plus output the ATDL command to change to the one you wish to send to next. In API mode you simply change the two bytes in the packet…
So to me it makes sense to simply build these packets myself. What do you think?
Kurt
I’m glad you figured out what was causing the error about getting the saved values! Thanks.
I hope the hardware/wiring configuration are the same though. 
I bet you are serious about this, I’m just glad you are willing to share your work. If you think this would make it even faster I’m very interested to try it out. But I was hoping to move on with other stuff and I might just use the current XBee code in the near future. Unless I get very convinced by you next move…
This sounds very interesting Kurt!
May I ask why you didn’t try the API mode at first?
Anyway, this type of coding is mostly over my head so I don’t think I’ve much to contribute. But I would really like to test it out.
Yep, don’t plan to change anything hardware wise. Although for the fun of it, I thought it might be fun to see how hard it would be to build another transmitter. So while looking for the gimbals, I ran across: hobbypartz.com/4warcratr.html
It probably is a piece of … but hopefully the joysticks work and maybe I will just try to stuff a processor in it’s own case and stick an xbee inside and add a keypad and LCD and see if I can get most of the functionality of the DIY remote…
Yeah I know what you mean. Since currently we appear to be the only ones interested and we have a working version, I am tempted to move on to some other projects. 
I don’t know, the transparent mode just seamed easier to implement, but once I got into it and reread the xbee stuff a few more times it did not not look that hard to convert to. Maybe I will do it first part way with my C code and see how well it works, but at first keep the same packets…
Kurt
That was a relief!
Sounds like a fun project too. I’ve also been thinking of making another DIY remote, maybe with 3 joysticks or a custom 4d joystick similar to what I’ve seen been used for animatronics. I think i’ve almost all parts needed (- keypad).
Since I’ve worked with repairing and customize electrical wheelchairs I’ve a “little” collection of several old high quality Penny&Giles and Dynamics joysticks…
Nice parts!
Alan KM6VV
Hi Zenta and any others who may be following:
I thought I would do an update to make sure you have everything…
The main changes are:
Kurt
CheckPoint.zip (618 KB)
Hi Kurt,
I’ll take a look at your newest code when I’m finished with the hardware modifications. I think I’ll start a new thread of what I’ve done lately.
The ability to pass trough a sound was a genius idea! Especially since I’ve disabled my speaker on the DIY remote
Hi Zenta,
Well in that case the sound command may not work very well 
I believe you did that to gain back one IO pin.
When I get back to building my second DIY remote, I was thinking of trying a different approach. That is I was thinking of picking up one of these (sparkfun.com/commerce/produc … ts_id=9056) from Sparkfun. At about $5 I could move the analog inputs from the 2 joysticks(4) + 2 sliders(2) + I believe I could take the 5 input IOs used on keypad if necessary. So my guess is for 5 IO lines I could pick up 11 of the current IO lines and still have room for 5 more on that one break out board… Just a thought.
So far I have not gotten very far in building my second DIY remote. I found that the case of the remote I bought was not large enough to hold the BB2 inside, even after I stripped out most everything. The Gimbals did come out nicely though so I will be able to use them. So at some point I will probably build some form of case. Too bad Jim is not selling the case or better yet a kit with most of the parts (sliders, keypad, …)
Kurt
Argh… I read your words a bit wrong then. Yes, I needed that last output port.
Interesting, that would sure give us many options! I was also thinking about using A/D MUX. I think I have some 4051’s laying around. Another thing I would like to use on a second DIY remote is a 20x4 serial LCD display, it support up to 38400 baud.
I belive using the ARC-32 on a DIY remote would give us even more I/O pins… (but still “only” 8 AD though)
Yep that LCD would be nice! Maybe I will have to start putting an order together.
Don’t have an ARC32 
so that won’t work for me But you could still add your 2 more AtoDs on it! Of course if you needed more, my Axon2 has 16 AtoD ports , but that would be a lot more work. But for now I think one of my old trusty Bap28s with maybe 1 of those Muxs would probably do the trick.
Kurt
Yes you should. Btw, do you have any experience with the XBee’s with chip antenna? They sure look useful if you don’t have any space for the antenna, or wan’t to hide the module.
Yep, probably at least half of mine ore with chip antennas. They work fine for me. Now they say they may not have as much range as the others do, but it works just fine for me as I simply want to communicate within the same room…
Kurt
Hi Kurt,
I think I’ve to order some XBee’s with chip antenna next time then!
I mentioned that I’ve been busy with some modifications on the DIY, I don’t wan’t to hijack your thread with that so I’ll try to start a new thread tomorrow and explain how I did it (if someone are interested?). Anyway, here are two pictures of the result:
Did you notice the difference?
Not the best quality picture because of the bad fluoresent light in my workshop.
And here is the code (your code) I modified for testing the extra potmeters:
DIY transmiter extra pot.zip (47.8 KB)
Hi Zenta,
Looks great! Don’t worry about hijaking the thread. I take it that you rotate each of the sticks, which gives you another analog value. It will be interesting to see how you did it. i.e. if it was a whole new joystick or if these attach directly to the old ones and have the wires run through the old one…
Again Looks great
Kurt
Thanks Kurt
I’ll post some more information here then.
You got it right how it work. The extra potmeters on top of each joystick can easily be rotated while holding the joystick with two fingers. I’m thinking of limiting the need for movement range on the potmeters, that could be easily fixed in your code. Another thing is that the left joystick are also auto centered on both axis. I don’t see the value of having a left throttle stick when there are two sliders and two potmeters in addition. Having two centered joysticks opens the posibilites for better control of both walking and body movement/gun turret/camera/head++.
I had an older cheap RC helicopter laying around with a remote control that had similar gimbals like the Hitec gimbals. But they wasn’t identical. So I had to modify the springloaded centering arm (is that the right word? 
).
Here is a picture of the modified arm and one original arm for comparing:
The long screw are for adjusting the centering position. Its a bit hard to see, but this picture illustrate how the centering screw work. If you look at the center of the picture you’ll see that the end of the screw are holding the outher gimbal in a adjusted position:
For guiding the wires through the joystick shaft I had to drill a hole through the shaft using a lathe.
Here is the result after drilling. I used a 1,8mm thin drill, and had to drill a 35mm long hole. And the upper part of the joystick shaft are cutted off.
I did post a picture before of the new potmeter holder. At first I was thinking that I should make threads on the joystick shaft, but I decide to use an easier method. The potmeter holder was drilled with a 3,9 mm hole, and then I pressed the potmeter holder onto the shaft (measuring 4mm in diameter) using a vice:
So now I got a hole for the potmeter wires:
I’m using some very thin wires for the potmeter. I’ve to check what diameter they are. The potmeters I used are some I’ve had laying around for awhile, I’m sorry but I can’t say where to buy them. I’m using hot glue for protecting the soldered connections:
The potmeter are also mounted inside the holder using hot glue. Its an simple but good solution.
At the rear end of the gimbals there is just a little hole where you can see the joystick shaft when the stick is centered.
So I had to extend the hole for avoiding conflict with the potmeter wires
You know, every roboteer must have a Littler Helper:
So, now I’m looking forward to start modifying the code for all my hexapod robots…
Hi Zenta,
You always amaze me 
You have great imagination and workmanship skills that I could never hope to duplicate. Great job (as always) 
I agree about having both joysticks being spring loaded would be nice for several of the robots. Way to go!
Kurt
Thanks for your nice comment Kurt!
I think the same about your programming skills, lucky me the code/software are much easier to duplicate (read copy, ).
Like I mentioned in an earlier post I think having a bit larger LCD display (20x4) would be perfect for the DIY remote since we doesn’t have enough space on the current display for showing all the info we wish for. But I think we would need to remake the top panel for that. And also some switches placed close to the gimbals would be useful. More multiplexing or replacing the BB2 with ARC-32 (future projects)?
Making another DIY remote would be a great project though.
Not sure where to talk about this, but after Robot Dude posted information about the Binary input to the SSC-32 and a couple of Private Messages, I took my first pass through converting my DIY Phoenix code to convert to binary. I have not had much time to test it yet. Some of it appears to work, but I am having a few legs maybe not moving 100% correct.
Zenta (and others), I thought I would post the updated file that I hacked for this in case you would like to try testing/fixing it. I hacked up both for using TASerial for high speed and for using the standard serouts… To find the changes look for code that is ifdefed under
SSC_BINARY
Kurt
Edit: Update: found some bugs in my port - fixed appears to be working better!!!
phoenix_v21k.bas (46.9 KB)