Not sure if I’m asking this correctly, I want my android tablet to talk to my wixel without another wixel, just using the wifi in the tablet. How can I do that? Or can I? I assume it doesn’t do this out of the box? Is there a TCP/IP implementation available? How about something like Contiki? Any other options?
The wixel won’t do what you want without an enormous amount of work. Check out the WiFly, which is set up to communicate with a cell phone or other wifi-networked computer. Spark Fun, among others, offers breakout boards.
Final cost and size are big factors, development time, not so much.
Hello.
The Wixel uses the CC2511F32 microcontroller from Texas Instruments, which uses a proprietary RF protocol and is not compatible with any standard protocols like WiFi. Even if the radio supported some form of WiFi, the amount of code required for a complete TCP/IP stack would almost certainly not fit on the Wixel.
You might have better luck with something like this:
adafruit.com/products/814
But then you would need a microcontroller that can act as a USB host to talk to it, and that could be expensive.
Maybe you could look for projects that use the Micrium TCP/IP stack and see if there is any inexpensive hardware it will run on that includes a WiFi radio:
micrium.com/page/products/rtos/tcp-ip
–David
Hmm. Ok. Thanks much for the links. Perhaps I’m over thinking this, I tend to do that 
Forget the native TCP/IP, just hang a wixel on my RPi as a ‘master’, then talk to (many) wixels? I assume that would work ok?
The protocol in that case would not matter, I could just make it up. Then the droid tablet can go through the RPi as a web surface to talk to the master wixel who then talks to the slaves? Bit of lag perhaps, but that’s not a big issue.
The idea here is a tiny $20 wixel to control a servo or two. That puts me at a really low price point (and small footprint) for my application.
Only some of the Wixel apps support communication between more than two Wixels. We don’t have any lossless radio protocols that let you connect more than two Wixels. I recommend checking out the Wixel User’s Guide and the Wixel SDK to see what is available, and also checking out Geoff’s work in this area: tabletoprobotics.xyz/tabletop/multigrid.html
–David
What I would suggest would be for you to look into one of the many TCP/IP and Wi-FI based serial port converters. Have a look at some of these devices…
serialio.com/products/mobile/wifi/WiSnapKit1.php
This way, you could simply implement a serial port on the wixel. Of course you’d still need one more chip to do the logic level shift and state inversion needed to convert the wixel UART levels to RS232, but at least then you’ll only have to deal with simple serial port I/O. You could then easily create your own protocol based on ASCII (text) based commands, which will make it very easy to troubleshoot and monitor what is going on.
Of course this means you’re not really using the RF capability of the WIXEL itself. But, you could also implement a master/slave scheme, with one WIXEL connected to your tablet via the serial-WIFI link, and that wixel would then relay commands to other wixels, if you had several to talk to. This would make the WiFi->serial adapter link into a one time expense.
Upon further reflection, I can live without the TCP/IP if I can just implement my own protocol.
I just got my three wixels today, I put one in my desktop and another in a laptop. I can walk down the hall here at work with the laptop and with the test_radio_signal apps I get a good 30-40ft or so. My implementation will be outside with no obstructions and 50 ft is about twice what I will need so as far as range, it seems great.
I was thinking of trying the packet address feature and then doing a sort of token ring/round robin implementation, does this seem feasible?
So my only question would be, is this feature not used in any of the apps because it’s well, not used, or are implementations of this problematic for some reason?
It would be nice if I could just send out an addressed packet and everyone would ignore it except for the matching wixel.
Hello. You could take a look at the Wixel’s I/O Repeater app for an example of packets that contains addresses, and Wixels ignoring the addresses that don’t apply to them. It is documented in the user’s guide and the source code is in the Wixel SDK.
We don’t have anything to make a true mesh network or token ring where Wixels retransmit packets that originated from other Wixels, but since your project is relatively short range maybe you don’t need that?
–David
Spent an hour or so this morning and modified the test_tx and test_rx apps to use the hardware packet address function as described in the datasheet:
13.8.3.1 Address Filtering
I made two small changes to radio_registers.c, I enabled the bits in the PKTCTRK1 register to use the h/w packet addressing and set the ADDR register to 0x22 (just an arbitrary address)
I then added the 0x22 to the tx app as packet[1] (so it’s right after the length byte as per the datasheet) and added the packet address to the data that gets sent to USB (just so I can see it on putty)
Reloaded the apps and it worked fine. Changed the address in the tx app to 0x21, reloaded and it quit (as I would expect, sometimes nothing is success
I need to do more testing, I have to get a cable and hook up my third wixel but so far this is quite promising!
Martan,
You are getting into the often frustrating but at the same time rewarding and fun area of protocol design here! When you consider a message to be sent, you’ll want to consider appending all your messages to a header, meaning a data structure of your own design, which all transmitters and receivers agree on. Now all receivers will have to receive every packet that comes their way. But if you design your message “header” to contain a source and a destination address, your receiving applications can easily decide to keep the message and act upon it, or reject it completely. I do that in every communication protocol I design. Typically if I see a message is for me (based on an address in the header), I’ll then copy that message to a separate buffer for later processing. Another thing to consider is a message ID number in the packet header, which only increments in cases where the transmitter is sending genuinely NEW data. This is helpful because you can’t guarantee all packets will be received, so you’ll sometimes want to send multiple duplicates when there is activity. The duplicate message IDs are then easily ignored by the receiver, just as easily as it would ignore a message with a non-matching destination address. Other things you can do in a protocol header is to specify specific commands, or even sub-addresses where the receiver is actually controlling one of several devices.
So bottom line, you may not need to implement a token-ring type of arrangement at all, and should be able to do just what you’re describing as your desire, just by putting some thought into your protocol design.