no Im talking about my solution(hack) with the pic and a digi pot only(no voltage devider, or fancy things like that)
this is all in the context of the original question of how to split a analog channel in to more than 1 digital channels
I know. The digital pot IS the voltage divider. This is exactly what you are trying to accomplish. There is nothing fancy about it. You make a variable voltage divider out of the DIG pot. This is very easy to do.
Hello Mike,
Thanks for contininuing the discussion… and perhaps I should appologize for being a bit of a wind bag coupled with the ability to type. 
As neither IFI nor, apparently, anyone else had taken the time to provide a complete summary of the joystick interface, I did feel that it was important for anyone considering going down that this path to be aware that there are several things to consider when engineering something that will work, as-is, with this interface, and within FIRST’s current rules.
Aside from considering how to do the digital to analog conversion, and its pitfalls, the other significant consideration, as I’m certain you will acknowledge, is the question of how to power it.
Your situation is unique in that it has been granted an exception to the rule of external power. Clearly any device intending to act as a USB host could not be powered from the OI… it just would not work.
For something less complicated that only needs to consume a 10-20mA, the problem is certainly much more manageable/tolerable.
Shifting the discussion to/back to, implimentation specific details…
As you correctly point out, using a digital pot comprised of a tapped string of polysilicon resistors is succeptable to large errors when used in an application where an absolute resistance value is important. Your solution of adding a series resistor to lift one end of the pot off ground is a good solution for making a 10K pot work, whether it be digital or analog. Perhaps for the benefit of others you could expand upon how you compensate for the poor absolute tolerencing of the digital pot.
Polysilicon resistors work well in ratiometric configurations such as a simple voltage divider (as in the case of a digital pot) or R-2R ladder configurations because on any given die, the resistors will be matched well in terms of ratios, even though the absolute values vary over a wide range (from die to die).
For my own purposes, I had also considered configuring a pot as you suggested, as well as simply using a 100K pot with only two connections, but decided that I wanted to avoid the tolerancing problem without trading off resolution, or individually compensating each device… which is a valid design descision. Alternately, you could create a common, low impedance, 500mV voltage source to tie the pot to.
I then considered using the pot strictly ratiometrically (i.e. tied between +5 and gnd) and using an op-amp to sum the wiper with an offset voltage to push the zero value up without sacrificing resolution, and to have a low impedance output to minimze that error… but that all took up space I didn’t have.
A more traditional R-2R, multiplying DAC coupled with an external op-amp and offset voltage would be another way to accomplish the same thing at about the same cost and component count.
In the end, I chose to use a 10bit, voltage output, quad DAC. In particular, an Analog Devices AD5314. I chose this part more for size and immediate availability, than for reasons of cost. The higher resolution allows for the 500mV offset to be removed in software without loosing the ability to hit each of the 8 bit A/D converter ‘bins’ as seen by the OI.
Anyone considering designing something that will work within the constraints of IFI’s joystick interface is bound to have their own reasons for wanting to do so, and there are a number of ways to solve these interface problems, each with their own set of pro’s and con’s.
Perhaps in the future, FIRST and/or IFI will afford us with a more flexible operator interface. Usable power and a serial port would be excellent additions, but I wouldn’t take away the existing interface as it is quite usefull in its own right.
Thanks,
Hello Stuart,
What you are doing, and what Mike has done on the Chicklet, are essentially the same except that he’s encouraging you to add one resistor (per channel) so that you don’t throw away 10% of your pot’s resolution. If you make your series resistor a trim pot, or hand select the resistor, you can remove the error introduced due to the absolute value of a given digital pot.
The origional poster, Marcan, was interested in the “how-to” aspect of interfacing to the OI, and I think someone else had brought up multiplexing.
Marcan was also talking about pulling power from the joystick connector, and I’m not sure anyone had addressed how to calculate the error that will result from doing so… so I elected to explore that topic in a way that hopefully would provide some insight as to how to make a personal decision on how much is too much, and what the tradeoff’s are.
From my own exploration of this interface, I found some things that disagree with what IFI has documented, and those were included in my posting, and have also been brought to the attention of IFI in case they want to correct, or clarify, those portions of their user manual.
Thanks,
OHHHH ok I see I thought he was saying run the pot from a voltage divider not as part of one.
that makes a lot of sense. and might be a good idea for the next time I build one(the current one Ive got seams to be spot on as far as tolerance so maybe I got lucky).
Thanks everyone for the comments. This certainly clarifies a lot of the details about the OI.
Right now, I’m considering two options: a 100K digipot in rheostat mode (the “hack”) or the 10+1K divider. I’ll probably end up trying both, and see how they behave.
On the subject of DACs and op-amps (or op-amps with the digipots), how would you deal with the range limitations of the op-amp? Even rail-to-rail op-amps aren’t truly rail-to-rail (they just get close). Would you be able to use the full input range using an op-amp?
As for the +5V Aux supply, I’m pretty sure it’ll meet my needs, based on Dave’s info and my own testing, as far as the power required goes. A more important aspect is how the voltage drop due to the current limitation affects the analog inputs when the current is higher and the voltage drops. I’ll do some testing once the components arrive.
QUOTE=Dave K.;567119]A more traditional R-2R, multiplying DAC coupled with an external op-amp and offset voltage would be another way to accomplish the same thing at about the same cost and component count.
In the end, I chose to use a 10bit, voltage output, quad DAC. In particular, an Analog Devices AD5314. I chose this part more for size and immediate availability, than for reasons of cost. The higher resolution allows for the 500mV offset to be removed in software without loosing the ability to hit each of the 8 bit A/D converter ‘bins’ as seen by the OI.
Dave, using an ADC is the best way to interface to the O/I. The Rev2 Chicklet will use an ADC. We realized the short commings of using the digpot when we got our first batch of pots in the lower end of the spectrum. Although we anticipated it, we thought the tolerances were on the conservative side. We developed a way to test the pots prior to assembly. We sorted them out into seperate groups based on there A to B resistance. This was tedious and not very cost effective due to the fact that we needed to purchase about 33% more pots than we actually needed in order to get enough that were within our spec. As far as elaborating on the voltage divider. It is very simple to overcome the tolerance issues. The 10k pots are actually a little better than the 100k. They vary from 8k to 12k. The object is to keep the offset resistor value within 10% of the pots AB resistance. One way to do this is to use another 10k pot as the offset resistor. That way you can adjust the offset value in software. The offset resistor is not just for allowing full range, actually it’s primary purpose is to prevent the input of the O/I from going to ground. If this condition is allowed the O/I will read 127. Another way to calibrate with software is to use a second digpot to adjust the input voltage to the voltage divider pot. The idea is to make it so the center is 127. That is more important than getting full range. Most digpots have a hardware/software shutdown mode. This puts the wiper to center. This is very usefull. But only if the center is 127 on the O/I. If for some reason your device is not connecting to your controller you need a safe state for the interface to go to. This is an effective way to interface to the O/I. But I would still suggest the 10 bit ADC.
Well one op-amp you could consider would be something like the Burr-Brown (now TI) OPA363 series. Worst case, with a 10k load, which is more than the OI effectively presents, it will get within 20mV (worst case) of V+ and typically within 10mV. That’s one I spotted, and I’m sure there are others that would work OK.
As I think I mentioned earlier, you’d need something capable of handling the dynamic loading presented by the multiplexing that the OI uses to scan the channels. There are of course capacitive loading effects as the analog switch selects the channel, and then the load of the current sink.
In the case of the OPA363, it is specified driving a 10k load, which is an order of magnitude greater than the load presented by the OI. Other op-amps that come this close to the rails, are specified at even higher resistances, such as 100k, and may not handle the switched load without introducing some additional error.
As I wrote earlier, I chose not to go down this road for different reasons, and you’ve certainly highlighted one additional concern that further justifies not pursuing this approach.
If you can make good use of your microprocessor’s sleep mode, and provide some local capacitance buffered by a series resistor, I think its probable that one could succeed in not loading the +5V aux supply enough for the OI to notice.
For my own interface, I’m faced with powering a 12-13mA device in addition to my interface electronics, so that will already pull the supply down by a few A/D counts. In a practical sense, it doesn’t really matter if we loose some resolution in joystick position. Heck we already toss out more bits in the deadband region just to avoid robo-creep when the joystick is a couple knat hairs shy of being truely centered.
I agree that having to sort parts is not a cost effective way to go about manufacturing.
Having been at this a while, I’ve had designs that despite our best efforts to design to worst case tolerances, the manufacturer’s let us down and provided parts well outside of their worst case specifications… and these are large, well respected companies that had the pipelines full of parts before we flagged the problem for them.
When it comes to semiconductors, design to worst case, and if possible, even a bit beyond that.
One of the reasons the AD5314 was a good fit was that its own power on reset set’s the output to zero. I’m sure there are other, less costly, devices that would also work well and also provide a power on reset to zero… but this was the one that was available quickly.
Thanks,
I’m not at all concerned with the interfacing PIC uC. The power usage of this is probably going to be very small compared with everything else. My main power hogs are external devices (over which I have little control, outside of disabling a few LEDs to avoid their power draw). However, the good news is that the worst-case power draw is not supposed to occur during normal operation, as the software should be able to configure the devices. Specifically, I want to be able to run a PS2 controller, and a Wii controller (I’m testing out different control schemes. I wonder how practical the Wii controller will be for manipulating a mechanism on the robot). With the Wii controller goes a Bluetooth module of course. Mostly everything is designed to run off of low power, but there are peaks in power usage during initialization mostly (the Wii controller blinks the LEDs which would be disabled later on via software, and the Bluetooth module uses more power during discovery). However, since the peak (init worst-case) power is well under 100mA, and the running power should be significantly under that, I think it should be doable. Everything is going to be powered off a 3V-ish buck converter (adjusted for efficiency).
Pretty much the same here - I seriously doubt full resolution is going to be very important, since humans are very good at mentally calibrating such things out. The USB-Chicklet needs to work reliably and accurately (as if the USB joysticks were regular ones), but for our one-off I’m sure we can work out any little kinks in software. Here’s an idea: if your current draw varies, you can tie extra inputs on the OI to GND+0.5 and +5V, and use them to do runtime scaling of the inputs on the RC to compensate for any differences.
Crazy idea: wonder how much power the Wii controller’s rumble uses? Probably too much, but I’ll still give it a go for kicks. If anything, we could have some fun out of competition making the rumble activate when the accelerometers on the robot measure acceleration over a certain threshold.
Not to become the rules police here, but if this is for a FIRST competition, they’d nix the control because of the Bluetooth radio.
Yes, I thought of that, and I suppose if you are pulling the +5V Aux power line down significantly, then it could be of some help. The flip side is that if the load was inconsistent, the asynchronous sampling of the analog inputs could cause you to introduce additional error rather than correct for it.
Again, the input sample rate is ~38Hz.
At that point, you might be better off with another self powered, home brew device that watches the RC->OI data stream, extracts what it needs, and gives the driver the approriate feedback via a seperate alerting device, be it visual, rumble, or a tazer jolt. As long as the wiring doesn’t tie into the same device that is wired to the joystick port, it should be permitted.
I believe radios (other than the IFI ones) are only prohibited on the robot, not on the OI.
R66:
The radio modems provided in the 2007 Kit Of Parts are the only permitted method for
communicating with the ROBOTS during the competition. Radio modems from previous
FIRST competitions can not be used. The radio modem must be connected directly to the
Robot Controller using one of the DB-9 cables provided in the 2007 Kit Of Parts. No other
form of wireless communications can be used to communicate to, from or within the ROBOT
(e.g. no Bluetooth devices are permitted on the ROBOT).
Notice that the Bluetooth communications stay within the Operator Console, and everything is channeled through the IFI radio. Thus, no other method other than the IFI radios is used to communicate “to or from the robot” (and certainly nothing within)
Either way though, we’ll have alternative control methods available, both because of the possibility of having the Wiimote denied, and to see which is more practical. If nothing else, we can still use the Wiimote out of the field 
Of course, it would work best when the load is constant or varies with a very low frequency (which will likely be the case of many control systems).
True. Not that I think it would really be that useful in competition, it’s just something that would be easy to do just for kicks, given what we already have. I’ve written a custom dashboard that, besides doing what the original does, also shows stuff like the camera vision system data, and a couple other things, so adding it onto that would be fairly trivial.
I think you’ll get burned by R11:
<R11> For the purposes of determining compliance with the weight and volume limitations specified in Rule <R07>, these items are NOT considered part of the ROBOT and are NOT included in the weight and volume assessment of the ROBOT:
…
- The OPERATOR CONSOLE.
…
However, for all other purposes the items listed above are considered part of the ROBOT and must comply with all other applicable rules and equirements. In particular, these items are subject to the shipping deadlines specified in Section 4.5.1.1 and must ship in the crate with the rest of the ROBOT.
Emphasis mine. Since the operator console is “part of the robot” when interpreting R66, you cannot use wireless communications to or from it (in my interpretation).
At competition…
<R63>, <R66>, and Section 3.14.3, make it reasonably clear that other than the 900MHz radios, no wireless communication is permitted. The one exception is <R109>, but that doesn’t apply here.
This may be helpful: http://forums.usfirst.org/showthread.php?t=630&highlight=bluetooth