Dr. Joe,
The joystick interface does consist of 4 analog and 4 digital channels. We had intended to have 4 possible modes for gamepads with two analog sticks,
mode 0 - axis 1 XY, axis 2 XY - 4 channels used
mode 1 - axis 1 XY only - 2 channels used
mode 2 - axis 2 XY only - 2 channels used
mode 3 - axis 1 Y, axis 2 Y - 2 channels used
And you are correct in saying we can use the unused channels for digital values! In fact we intended to use the upper nibble of unused analog channels precisly to send digital button info. We're only using the upper nibble (MSb 4 bits) due to possible jitter in the analog transmission, 4 bits is overkill we know and we may change that to support more digital support.
So lets say a,b,x,y (XBOX controller) are decoded in one of the analog channels. And lets say a and x are pressed and b and y are not.
The data transmitted would be binary : 1010 1000 or 168(decimal).
the 1010 would be a-press,b-not,x-press,y-not.
the lower 1000 is ignored by the application. Since we can't ensure that a value of n won't be read as n-1 or n+1 on the OI side the lower nibble is set to the middle of the value range. This uncertainty is do to the jitter in the OI side.
The POV will be decoded as 4 buttons. I grew up on SEGA, there's no way we're not supporting this. The only trick would to implement application code to recognize up and left pressed together as up/left, which shouldn't be hard for most teams.
So the intended use we designed for was so that through a simple calibration mode you can set the number of analog channels and which axises to use (mode 0-3). This selection would determine the number of digital slots available, in which case the next step of calibration would be to pick which buttons you want to be included in the digital transmission, we were thinking of having an led blink the number of digital slots available(4 or 12). And to select a POV button you can simply press one of the POV buttons.
So somehow the user would enable calibration mode, i.e. jumper and power recycle perhaps
1) Choose which axis profile, either using lcd outputs from controller (which is a FANTASTIC idea) or maybe number of button presses.
2) Observe led blinks to see how many digital buttons you can have.
3) press the buttons you want decoded (max 4 or 12 depending on axis selection).
4) leave calibration mode and PLAY.
Settings are saved in EEPROM so you never have to do this again.
Now this IS NOT SET IN STONE. We could use the lcd outputs to select axis mode during runtime or better yet allow us to transmit 4 times the data through indexing. My only concern is that we don't make this so complicated that only veteran teams use this.
Omar Zrien
Cross The Road Electronics
Quote:
|
Originally Posted by Joe Johnson
Yes, you are correct. I have really been out of things too long.
As to Mode2, where you send the 12 buttons. Do you send them via the analog channels, where different ranges imply different button combinations for example
0-15: 0000 0000 0000
16-31: 0000 0000 0001
32-47: 0000 0000 0010
48-63: 0000 0000 0011
etc.
If this is true then you don't use the switch inputs or the LED outputs.
If this is correct, can I propose 2 more modes?
mode 3:
LED outputs used by the RC to multiplex between mode1 and mode2
mode 4:
every other data packet switch between mode1 data & mode2 data with the switch inputs used to tell the RC which type of data to expect*
Finally, you don't discuss the POV data. The POV button is a very nice way to drive robots in many cases. From a Windows application, the data is returned as 0, 45, 90, 135, 180, 225, 270, 315 but as a practical matter, the POV data is really just 4 more switch inputs that are mapped to these 8 pionts of the compass. Any chance you can map these 4 switches to give access to that data too**?
Think about it.
Joe J.
*This may run into problems with aliasing since you can't sync with the IO packet sending. perhaps it would be better to send 2 packets in mode1 and 2 in mode2 or maybe even randomly switching, within limits. Also, there is another possible problem with this if the OI does not synchronize the reading of the OI switches with the reading of the analog ports, but the ability to have all the switches and both X-Y data on the thumb would be great.
**note that if you can use 16 bits per range on the analog inputs, then you have room for 16 swithches with a 255 bit resolution on the ADC on the OI -- I am not sure but I think that the ADC on the OI is still just 8 bits. It seems feasible.
|