Philba wrote:... SPI appears to be used to set up the transceiver. The transmitted data appears to come in on a single bidirectional pin (not spi, not serial I/O, not I2C). there is an, as yet, unknown protocol used for that tansmission. this could be running at up to 1 MBit/sec (though I believe much less).
Certainly - a very common pattern for this sort of peripheral (compare and contrast with the ongoing camera discussions next door)
I don't think the radio is imposing any protocol on the bitstream - from my understanding of the data sheet, during transmission, the bit stream simply controls the frequency deviation, and during reception, the bitstream is the output of the discriminator. It also recovers a 1Mhz clock from the rx bitstream (PLL I guess) for helping the baseband.
If this is the case, I would expect:
- The tx MCU to be responsible for producing a bitstream with no DC bias (Manchester encoding/ XOR with PRNG, 8B/10B etc..) (The data sheet does reference DC estimation, but it would do no harm)
- The tx MCU to generate preamble and sync bits. The preamble will be 101010101.. maybe a few tens of bits, to let the rx get its gain sorted out. The sync will be a fixed 16? 32? bit pattern to let the rx MCU recognize the start of packet.
- Each bit will be 3uSecs or longer (and maybe an odd number of uSecs) The RX MCU can then sample at uSec intervals and take a majority vote to decide on the result. (Also, the tx could XOR the data at 1Mhz, each bit becomes a little pseudo random number)
To get things going, I suspect you could send a fairly slow bit stream, and ignore the recovered clock completely (heck, rs232 with the data xored could work, prepend a few bytes header to train the rx)
The first thing for using these modules standalone will be to capture the register setup from an existing implementation - the datasheet is pretty light on details (proper customers will probably not have got much more detail - ' err .. here, this code works, good luck...' seems to be a common documentation technique in this area).
I have no concerns about driving these modules directly from an MCU - I am fairly certain that is all these joysticks have under the epoxy. (My bet woud be 8051 clones with some custom pinouts). You may lose some range by not sampling the rx stream as often as you could, but a shift register soon sorts that out.
Philba wrote:Too bad roach doesn't have a scope - that would tell us a bunch.
I do - I have got the controller I picked up on friday wired up to my PC as a USB device, and it all works just fine with XBCD. A very quick browse w/ the scope showed that this was the same as the datasheet and pinouts I found earlier. Unfortunately, it is not a storage scope, so I have not got a good idea of the data yet, The next thing is probably to hook it to the parallel port, or an MCU, and capture some of data flying past - see above.
NateW wrote:Is the robot in question big enough to mount a Linksys NSLU2 ...
Heck, if you are going that route, do it simple - replace the 2 rumble motors with a pair of motor/gbox/wheel units attached to the side of the controller, wire bump switches and rev counts to the button pads & skid pad/dolly wheel on the front of the controller. PC code uses DirectInput - sets L/R rumble to drive motors, reads buttons to react.
Whilst it is possible to get a robot going by using the entire joypad/host and a wrapper, so far it seems a betterlong term deal to pull the rf link out of the middle, given the amount of documentation and increased flexibility.
TTFN
SamL
Edit:
Spent some more time with the scope - console side - triggered on BPKCTL, whic gives a nice frame sync, and looked at BDATA1:
12 ms frame time:
~0.7ms transmit (console->pad)
~1.3ms recieve (pad->console)
3uSecs per bit
tx:
~24 bit sync (12 x '01')
~8 x 0
~24 bit fixed pattern
~160 bits of data - some area change when rumble values are changed
rx:
same as above but:
~280 bits of data - lots changes when sticks are waggled
Important points -
- The radios modules are not doing any of the encoding etc. - we can choose our own.
- The packet format is roughly as I thought.
- 6 time more data could be transferred over the same range.