The product is back up on their website and now the link works for the schematic again sparkfun.com/datasheets/Wireless/Zigbee/XBee-Regulated-v10.pdf. As far as I can tell they are simply relying on the resistor and LED to take care of voltages. I remember when I was playing with a propeller processor, they would often simply use a resistor when hooking up a 5v device to one of the inputs on the propeller. That probably is not as safe as using a proper converter…
Hi again Rotorman. I have not tried my sparkfun versions yet, but glad you got yours to work. I have been playing with my transmitter/receiver code and trying to get better handshaking to work. Also still experimenting between using flow control or not or use HSERIN or not. My current version is using HSERIN and my own SEROUT function.
I think if we can get this to work well there are several others who will be interested, but I have a lot of work left to do…
Yeah, I’d feel more comfortable with at least a resistor divider. What do the LEDs do for the conversion? If DIN goes high, no current flows through the LED. Now if they’d used the DIN signal to ground for an LED, it might have worked as a resistive divider.
And you’re right, your improved HSERIN and SEROUT functions could also be useful for my blueTooth interface.
Uh not really following the discussion too much but with respect to the diode in the DIN line of the sparkfun schematic you linked, the diode effectively is a wire-AND for the DIN pin. It relies on pull-up current established by LED+resistor plus the pull-up resistor internal to the XBee module (on by default, see the PR command description on or about page 49 of the XBee manual) to pull the DIN pin back to a high state unless a host is actively driving it to a low state through the diode.
I didn’t see anything about it in the 2.5 Pro XBEE manual I came across (wrong manual).
I can see the wire-AND function, but still nothing to limit the voltage of the incoming signal. OK, a diode drop. Can the XBEE sink much back into it’s power lines via an input pin (protection)?
the cathode of the diode is attached to the incomming signal. when the incomming signal is > 3.3V the diode is in reverse bias not forward so the DIN pin is right about 3.3V. when the incomming sinal is 0v the diode is forward biased and the DIN pin is pulled to a diode drop above ground.
I have been making some reasonable progress here. I am rolling my own handshaking between the controller and a robot, which is starting to work OK. I still have a few issues to work out to make sure that it is reliable. I am currently always sending/receiving packets even though nothing has changed, which will change soon.
For now I have settled on using HSERIAL to communicate with the XBEE. I have a few assembly language functions to replace some of the functionality of HSERSTAT which at times resets the processor. As I now have the xbees running at 38400 I am using my timer based serout to output to the LCD. I may try bumping up the baud rates to 57600 to see how that does…
I have just started to take a diversion in the transmitter code right now. For now I am using the “D” key on the keypad to cycle through a few different pages of displays/configurations. So far I am thinking fo doing 4 pages.
Page 1: will have the same stuff as now.
Page 2: Top line will show when a slider/joystick changes values, bottom line will be reserved for data transmitted from robot…
Page 3: Will allow me to choose who to send to (XBee DL). That is you will be able to hit keys 0-9 to change the DL. Will need to expand on this later to make it more configurable if you have multiple robots with multiple controllers in the same place… Could do a Node Discovery and maybe have some Bind Function that the Robot/Controller maybe exchange 64 bit unique address…
Page 4: Thinking of a calibrate function. Have users move joysticks/sliders to mins and maxs and leave at center point have the code calibrate the ranges…
So far I have put one of the Sparkfun XBEE boards on my old TV brat and it has taken a few steps with the updated code. Need to better handle how I am timing out the conversations… Soon will be updating my MechBrat who now has two guns mounted and I now have the pico switches to wire up…
Also I am not sure about the range differences between the chip versus the wire versus the external. I think I read someplace that the chip has a shorter range… But could be wrong.
I do have a couple of the series 2.5 Pros, which I may try out later. I will need to figure out more the differences of topography between series 1 and 2.5…
Yes my brat has one of the XBee exporer regulated that you called out, have a second one that will be going to Mechbrat or the Rover or the CHR-3…
Yes you need just one per the transmitter and one per robot that you wish to control.
Hi Kurt, thanks for the info. I will pick up some stuff to play with. 8)
Are you implementing error correction on this. Basically send a character stream and checksum and the receiving end asks for the data again if the checksum fails. Or something like that. lol
Not sure if this is necessary or if it adds significantly to the difficulty.
Yep, Currently I have the a little handshaking at the start that the Transmitter says I am ready…
Then the Robot sends out a 4 byte packet:
The controller responds back with a packet of data:
Again something like:
<CBexra=8>
I don’t resend as the data is not critical, if the robot does not like it, it simply asks again… If I get too many timeouts on either end I then reset and wait for the transmiter to say it is ready again.
I am late to dinner, but I had some thoughts about the discussion of scaling the joysitck values. Kurte originally said, “…I believe we found that these joysticks maybe had a range of 392-692 (~300 values)…”. This could be expressed in 9 bits, not 10. Scaling from 9 bits instead of from 10 bits would lose much less precision, wouldn’t it?
The raw range would require 10 bits admittedly.
Simply subtracting the minimum value results in a range of 0-300 (expressible in 9 bits) with 300 possible values.
Then performing an integer divide by 300 (the upper limit) results in a range of 0-255 (8 bits) and 256 possible positions.
Scaling the entire range from 10 bits to 8 bits results in a range of 144-255 with only 111 possible positions.
So in this example, expressed in MS Excel formulas,
ScaleDown = int(255*((position - 300)/300))
ScaleUp = int(300*(value/255))+392
When scaling you always want to trim the unused portions(indicated by your minimum value) and then scale using the max range(max value-min value). So given 392 to 692 first subtract 392 and then do your scaling.
value = ((value - 392)*256)/(692-392)
will give you the best posible scaling for this particular range of values. With this you will get the full 256 position resolution of your byte.
To do the reverse:
value = ((value*(692-392))/256)+392
So you had the ScaleUp part nearly right. Remember you are dealing with a byte which has 256 possible values, not 255.
Also the order in which you multiply/divide integers for scaling should ALWAYS be multiply first and then divide. With integer numbers you will lose precision if you divide before multiplying.
Yep, my calculations are similar to what you mentioned. They look like:
bPacket(2) = (((((sums(0) + SumOffsets(0)) min (AToDMins(0)*8)) / 8) - AToDMins(0)) * 256) / AToDRanges(0)
They are a little more complicated as I now have stored away both the minimum for the joystick or slider, and also the Range, which is equal to the Max - Min + 1 as both value are inclusive.
Also we have the sums where are equal to the last 8 samples for the item and we are also trying to take the center point into account. That is while we wish the center point to 0x80, we may be off by a little…
I have been playing around with the code over the weekend. Now when you press the D key on the keypad it has two different display modes (Not quite implemented yet), plus a page that allows you to hit 1-9 to choose the destination robot (DL in Xbee 1 talk). Soon I will change this to probably allow you to enter in hex a full 16 bit address for DL. Also have a second config page, that allows you to Move both joysticks the full ranges as well as the sliders and then when you hit a key it will save the mins/maxs for the joysticks in the EEPROM of the BAP, such that each receiver can be configured properly.
I need to work on improving the communication reliability next, which maybe I am timing out too quickly… May also try bumping up to 57.6K or Could try the 114…
Things on my todo list:
Finish being able to set My and DL on Remote. Change the connect message from Remote to have it’s My sent to robot to use. Also make them both be able to set full 16 bit address. I have not done yet as I am using “D” key to cycle pages… May break down and do hardware upgrade to add 1 or more switches to DIY receiver Could be simple 1 switch 1 IO, or could try muliple switches (Gun buttons…), could try to hang them off of 1 IO with Rows or Cols in reading keypad, or maybe different resistors and using different voltages with AtoD to know which switch(s) have been pressed…
Finish implementation of Send data only when it changes. things like:
a) Robot sends packet saying: I want only data when it changes. Also use a deadband of X for each of the joystick values…
b) Transmitter keeps track if data changes and sends out a simple packet telling user it changed.
c) When Robot wants the data it can ask at any time regardless of data change or not. (ie it may want to ask every second for data just to make sure that the receiver did not go away…)
Finish implementing Second page of output on the Remote: Maybe first line shows what if anything has changed (sliders/joystick), 2nd line shows Info returned from Robot.
Maybe add a page that allows me to addjust the servo offsets that I save in the Brats BAP EEPROM. I had a PS2 program that allowed me to adjust the servos, but maybe merge into my MechBratXbee so I can configure that brat to be in Offsets mode and use joysticks to adjust…
I am currently setting some values on the XBEE like its MY, Descriptive Name, Baud rate, command timeout, … using a USB adapter I plug into my PC, using the DIGI utility X-CTU. I will probably write a Quick and Dirty simple application that runs on the BAP to set these, as maybe you don’t have this ability.
Probably seperate out some of the XBEE Robot code into a self contained file that makes it easier to integrate into other robots. WIll probably add to my Hex or Rover…
…
When this will all get done? Good question. Depends on whatever else I decide to do as I am doing it just for fun!
Kurt
P.S - If anyone is interested, maybe I should try out the new file upload capabilities of the forum and upload my incomple sources…
A short update, from the previous post. I think I have the communication handshaking working better now. I now have the two different versions of the display working (at least the first part). I will now implement some of the protocol for the robot to send information back. I also updated my MechBrat code some, need to work on the directions it walks when I move the joystick…
For the fun of it I uploaded the current snapshot of these two files. They are not complete yet, but this way if I totally screw up, I can at least come back to these
I am thinking about adding a few switches to my DIY Xbee receiver to allow me to be used to wonder through configuration screens. Things like next page, cancel, OK… I am thinking about using one of the analog inputs to handle this and as such try a resistor ladder. I am thinking about hooking it up something like what was mentioned in a thread on Trossen roboticsforums.trossenrobotics.com/showthread.php?t=1284&page=2&highlight=button+resistor.
If you go with the diagram by clavis that is about 2/3 the way in this page, where each switch is connected to +5V and then goes through a different resistor (r1-rn) and then there is a resistor that goes to ground (r0). So each switch sets up a differnt voltage divider.
If I remember my resistor stuff, if one button is pressed then the voltage out should be: Vout = Vin * (R0/(r0+r1))
So assuming three switches and using some resistors I have on hand: Lets say R0=1K, r1-r3=(1K, 5.5K, 10K) and Vin = 5v, I would have for the three switches
I think from looking at this I can choose some better values. Also If I remember my resistor stuff well, if two switches are pressed, we end up with two resistors in parallel. The equivlent resistance for two in parallel = 1/rt = 1/r1 + 1/r2 -> Rt = R1*R2(R1+R2)
So if I use my resistor values from before and lets say we press S1+S2, we would have: R12 = (1K5.5K)/(1K+5.5K) = 846
R13 = (1k10k)/11k = 909
R23 = (5.5K*10k)/15.5K = 3550.
I could do the math again here to convert to AtoD values. The question is, does this look correct? Has anyone done this and if so what resistor values worked well for you?
That’s certainly a way to do it. Do you have an extra pin? Why not use a panel shaft encoder? It would allow you to spin through selections. Can even be done with a single pin, if you are willing to accept scrolling only in one direction (not bad). And I seem to recall that you have code already for the encoder!
I didn’t work them out, but your resistors would probably be OK. R-2R ladders are commonly used. Might even be able to buy an R-2R package? Seems I saw/used one somewhere.
