SparkFun Forums

[roach]

Ok, you're thinking bit banged.

I've seen this term bandied about before. What is "bit banging"? How does it compare to whatever you were thinking this was (ie: non-"bit-banging")?

Also, you guys are onto SPI now. Is that the same as i2c (or in atmel-speak, TWI)?

[SOI_Sentinel]

Bit-banged is slang for software emulation of hardware, usually used for serial interfaces.

SPI is the Serial Peripheral Interconnect. Check your Atmel datasheet. It's fairly simple. You have one outbound data line, one inbound data line, and a clock line. All unidirectional. The data rate is driven by how fast the master of the transfer toggles the clock line, so it's very simple to software emulate, and can regularly be clocked at 10Mhz+. On the Atmel AVR's, the hardware SPI is used to program the flash via ISP as a secondary function. It's also the interface of the Atmel Dataflash series of low pin count high capacity Flash memories. The major issue I've run into is, depending on MCU manufacturer, it can often be multiplexed on the same lines as the I2C/TWI hardware.

[roach]

Okay, so I've got two USARTS, TWI, and now SPI. How many serial communications implementations ARE there on this thing?

...very informative stuff, this. Good thing I'm constantly browsing this forum

[NateW]

to read USB data with a uC? This is about about reading the stream of data coming out of the transceiver.

I thought it was just about using the wireless XBox controller to drive a robot. If that's the goal, I'd suggest looking at it as a USB device, and work on making the robot a USB host. If that's not the goal, then never mind.

[Philba]

creating a usb host is pretty complex. Probably much more so than cracking the procol between the transciever and the usb controller. At least I think so.

I was not talking about bit-banging SPI. (SPI is not I2C) who cares - 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).

cute trick with the pic (shift a port) but you have to catch both positive and negative transitions. Interrupt over head is going to be 4 instruction clocks + interrupt handler code (shift, clear int flag, count, test end, and so on). Int on port change might work but i still would like to see the code.

You might get a burst rate of something very high for a small number of bits but the average is going to be much lower. This is why uC based logic analyzers are pretty slow, relatively speaking. Until we know the form of the transmission, there is now way to know what can be done. Too bad roach doesn't have a scope - that would tell us a bunch.

[roach]

Nate: Your statement of the original purpose is correct. Ultimately I want to drive a robot using the wireless controller. Unfortunately, acting as a USB host is definitely non-trivial. So far we have been operating under the assumption that it would be easier to intercept the signal directly from the wireless receiver "Daughter" board and try to interpret it.

This may turn out to be an incorrect assumption, but I won't know until I explore it in a little more detail. USB hosting is my second choice...

Too bad roach doesn't have a scope - that would tell us a bunch.

Amen. Now soliciting donations!

[NateW]

Is the robot in question big enough to mount a Linksys NSLU2 and batteries for it? It's got a USB host and it's pretty straightforward to reflash it with your own Linux image with help from http://www.nslu2-linux.org/.

If the xbox controller acts like a regular USB joystick, there's a fair chance that you'll be able to get going pretty quickly. No promises, but it's worth a shot. I just came across something a little while back from someone who is using an NSLU2 to get images from a USB webcam.

[samlittlewood]

... 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.

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.

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.

[Philba]

damn, littlewood, you are good...

I think it would be good to crack the Rx (as you call it) protocol. I can see the hand controller being quite useful in a number of contexts. My guess is the 280 bit stream is just a series of registers being dumped so it should be pretty easy to map it out once we've decyphered the encoding.

3uS is probably doable with most PICs and AVRs. I have a renesas16 that will work great grabbing and crunching the data. I've been Logic Analyzer shopping but don't know when I'll get it (ebay bidding vagaries).

What brand controller do you have, Sam? I may have to get one now. This is getting interesting.

Phil

[samlittlewood]

damn, littlewood, you are good...

Nah, it's just that this happens to cross over with several things I have done before, so all the elements are familar.

I think it would be good to crack the Rx (as you call it) protocol. I can see the hand controller being quite useful in a number of contexts. My guess is the 280 bit stream is just a series of registers being dumped so it should be pretty easy to map it out once we've decyphered the encoding.

Sorry, the console side was easier to get at, so that was my perspective in choosing names. As you say, I don't think the protocol will be very difficult, tho' there will probably be a little bit munging to remove dc bias.

3uS is probably doable with most PICs and AVRs. I have a renesas16 that will work great grabbing and crunching the data. I've been Logic Analyzer shopping but don't know when I'll get it (ebay bidding vagaries).

Make sure you get the pods - it can be very expensive to get replacements (like 3x what you paid for the analyser!). Have you thought about one of the pc based analysers eg:Bitscope? - Not a recommendation - I have been looking at them and have not got off the fence yet - curious to know what other people think.

What brand controller do you have, Sam? I may have to get one now. This is getting interesting.

I have a Mad Catz Wireless XBOX Controller (Model #4556) - BUT - there are at least two different elecronics assys. that appear in the same package. The one I have has FCC ID P25CPMC4556D1904C:

https://gullfoss2.fcc.gov/prod/oet/cf/e ... 556D1904C'

If you look at the internal photos, you will see the small radio module:

Internal Photos

You want one that looks roughly like that, and a legend of the form -'Ver X.Y' where X is 5,6,7,8, and a 16Mhz crystal on the main board nearby. The chip will probably be blobbed.

These modules do seem to appear in many brands of controller - If you can find controllers with tranlucent plastic, you should be able to see what is inside - failing that, make a note of the FCC ID and put in into:

FCC Generic Search

I'll try and put together a table w/ pictures.


TTFN

SamL

[Philba]

...

3uS is probably doable with most PICs and AVRs. I have a renesas16 that will work great grabbing and crunching the data. I've been Logic Analyzer shopping but don't know when I'll get it (ebay bidding vagaries).

Make sure you get the pods - it can be very expensive to get replacements (like 3x what you paid for the analyser!). Have you thought about one of the pc based analysers eg:Bitscope? - Not a recommendation - I have been looking at them and have not got off the fence yet - curious to know what other people think.
...

I've looked at these as well as used HP LAs, The intronix logic port has some very respectable specs (34 channels/500mhz timing/200 mhz state/ 300 mhz freq counter) and a decent price. http://www.pctestinstruments.com/ I've talked to several people that have it and are happy but I didn't get the sense that they were very sophisticated. There are several others but they seem to be quite a bit more expensive for similar specs.

I hear you on the probes. I'm looking at the HP 1630 and 1650 series used. 200-300 usd on ebay with probes and grabbers (what's that like, 125 quid? lol). that's getting towards the cost of the logic port so I'm still not sure. I sure like the feel of a real instrument vs a tiny little pod but I sure like the specs of the pod...

[samlittlewood]

Well, I have pulled together a summary of what 2.4G radio modules are typically used in wireless gamepads.

I have a pair of the first in the list, and I have one end talking to a Silabs C8051F310 dev. board. - I'll post more details when I have it debugged and am confident that is not doing anything hideous (tho' at ~1mW power, there is not too much danger).

It is starting to look as if you want a source of cheap RF modules, then this is a good path - Over here, 10 quid on ebay will get you a gamepad with a pair of radios. It is worth noting that the 3rd party no-name designs seem more likely to have bought in their radios, rahter than integrating onto the main board.

Also, if you are interested in evaluating the current contenders in this field _WITHOUT_ shelling out ~$1k for each dev. kit, this is fab! - and why I am doing it.

NB, for those in FCC land - you are allowed to build prototype radios that use the ISM bands, with no certification, as long as they are competently engineered. (Up to 3 devices I think).

- Signia 5210 Type 1
Datasheet

Several versions, widely used, and used interchangeably. Usually supplied with 16Mhz clock.





- Signia 5210 Type 2
Datasheet

The one that started this investigation. Usually supplied with 12Mhz clock.



- Nordic nRF2401 Type 1
Datasheet
Largely used by "Asoka Incorporation" - don't know what brands that appears on the shelf as, also used in recent Intec (Hip Gear, NYKO) devices:



- Nordic nRF2401 Type 2
Datasheet
Widely used - some Mad Catz, Intec (Hip Gear?, NYKO?), E-Core Technology




- Nordic nRF2401 Type 3
Datasheet


Looks like TechCorp/Joytech own design - used for all their recent devices.

- ?Atmel ATR2406 Type 1
Datasheet
Seems to come from the same mfgr as the Signia Type 1 modules - very similar pinout. It is almost certainly the atmel part - the rf layout closely follows the atmel ref. design, and the 13.842Mhz osc. is pretty indicative.

Curiously, the schematics supplied to the FCC have signal names that also imply the Chipcon 2400 part has been involved at some point? - I guess this mfgr (whom I have not identified yet) just builds up modules with whatever the best deal is.



- Various others - a few other stragglers that only appear in one device:
The unknown mfgs that seems to supply most modules has also built a nordic version "NVer2.0".
Whoever made the RFMODUL boards has also made a Chipcon 2500 version with the legend "MARIO5C".
Pelican accessories (Blade2.4, Predator2.4) use an module with the legend "TITAN-DDS" - no idea what that is.
Logitech use the Nordic parts, but integrated onto the main board.

[roach]

I think someone already asked this question, but is it safe to assume that the etched antenna basically sucks? Would an external antenna give a longer range?

[samlittlewood]

I think someone already asked this question, but is it safe to assume that the etched antenna basically sucks? Would an external antenna give a longer range?

I am not so sure about this, after reading the some of the freescale app notes on antenna design and range testing:

http://www.freescale.com/files/rf_if/do ... AN2902.pdf
http://www.freescale.com/files/rf_if/do ... AN2731.pdf

It looks as if an F antenna can be pretty efficient - I suspect the range is not going to increase that much if you add an external ominidrectional antenna - as an extremely rough guess, you might increase the range 60% if you replaced both ends with 2dBi rubber ducks. (and had them oriented right)

If however, you use directional antennas, then yes, huge improvements will be available - if you figure 6dB to double the range, then a 12dB antenna at each end might give you 16x range - obviously only when they are pointing in the right direction, and the all the other black magic is in place.

TTFN

SamL

[Philba]

one of the reasons the microstrip antennas suck is orientation and height. If you can put the module up high and in proper orientation (not sure what is best, though), then you will have better reception/tranmission

I spent a couple of hours at the local big-box retailers yesterday. There are some no-name ones that go for $20 usd (dreamGear) that the FCC info includes the controller schematics and block diagram. It doesn't look exactly like the one at the store, though. The FCC one uses a chipcon cc2500 with the crystal on the transciever module so it may be easier to repurpose. Here's the cool part - the cc2500 is a complete rf modem with 64 byte xmit and rcv FIFOs accessed via SPI. No messing with a single bit datastream, no need for encoding in the micro. chipcon has configuration software (smart rf studio) for the download. this just gets better. I'm going to go grab one of those, hopefully it's got the cc2500 in it..

[edit]It turns out the FCC listings are for a PSII controller (dreamGear LavaGlow) which doesn't show up in any online merchants but there are numerous other dreamGear wireless controllers. there are no other dreamgear listings in the fcc database. I checked the grantee ID also (TW8). Sam, do you know if the FCC requires recertification if the transcierver modules are used in a different product? [/edit]

Phil