Q: I've heard of the original ybox. How is the ybox2 different than the original ybox?

Both devices use the propeller chip and both fit in an altoids tin. However, the ybox uses an XPort for all of the network connevtivity, whereas the ybox2 actually implements the entire TCP/IP stack on the propeller itself. The result is a more flexible and cheaper to build device. The ybox2 also has the ability to be reflashed over the network. The original ybox could only be reflashed with a prop-plug.

Q: What is a Widget?

A "widget" is simply a program which runs on the ybox2, which can be uploaded to the device via the bootloader. These programs can do a variety of things, such as poll the internet for weather info, a networked alarm clock, and a twitter client.

Q: Can I run more than one widget at the same time?

Only one program can be uploaded to the ybox2 at a time, due to memory constraints. Everything, including the TCP/IP stack, must fit in 32KB. As further development continues, I anticipate that the programs will become more rich with features, and perhaps some widgets will be merged.

Q: Does the processor on this device really have 8 cores!?

Yes.

Q: I notice there is an IR port. What kind of remote control will I need?

The IR port will work with any remote control which is modulated between 38-42KHz. At the moment however, none of the widgets are really using the IR port. This will likely change in the future. An IR test feature is built into the bootloader, which will flash the LED when a button on the remote is pressed. There is an object on the ybox2 repository for reading the codes from Sony remotes.

Q: If I am on a network without a DHCP server, is it possible to connect to the ybox2 and set the IP manually?

Not yet. This will be coming in a later version of the bootloader.

Q: How many I/O pins are free?

There are 11 unassigned pins on the board. However, there are some ways to free up a few pins if you absolutely need it, at the cost of some of the bells and whistles. The maximum number of free I/O pins while still being able to use the ethernet port (but no video, LED, pizeo, etc) is 22.

Q: How fast is the network implementation?

On the latest version of the bootloader on the source repository, I can download a RAM dump at a tad under 30Kbps. In practice the TCP stack isn't usually the bottleneck. Nonetheless, it will likely get faster in the future.

Q: Is there a way to do DNS lookups on the ybox2?

Not yet. This is on the to-do list.

Q: Why does uploading new programs using the bootloader take so long?

The bottleneck for uploading new programs is the I2C implementation in the bootloader. I'll be re-writing this at some point to be faster. Once this happens, uploads will take only a few seconds.

Q: Where are the persistent settings stored on the EEPROM?

They are stored in the last kilobyte of the 64KB EEPROM.

Q: If I upload other programs to my ybox2 using the prop-plug instead of the bootloader, will my settings be erased?

No, your settings will not be erased by uploading different firmware to the device using the prop-plug. The settings are stored in the last kilobyte of the 64KB EEPROM, and programming with the prop-plug will only write to the first 32KB. You will, however, be overwriting the bootloader.

Q: Is my ybox2 using an IEEE-assigned EUI-48 address?

No, it isn't. The MAC address for each ybox2 is calculated at the first boot and stored in the persistent settings. The first byte of each ybox2 mac address is 0x02, which designates it as an administrator assigned unicast address. The rest of the bytes are calculated using a strong random number generator. The chances of two ybox2s being on the same local network having the same MAC address are extraordinarily low.

Q: Can I change the MAC address?

I have not provided any easy way to do so, because you should have no reason to do so. More importantly, I wanted to make sure that the chances of accidently erasing or changing the MAC address after the first boot are very low. Resetting the device will not erase the MAC address from the persistent settings.

Q: I was looking at the source code to the bootloader, and I noticed that at first boot it also generates a UUID. I also noticed that this UUID is protected from being erased on reset, like the MAC address. What is the purpose of this UUID? Are you using it for some sort of nefarious tracking purposes?

Good eye! Nothing nefarious here, it's not even being used at the moment. I simply imagined that there may be cases where it would be useful to have a universally unique identifier. The UUID isn't pre-loaded on the devices, it is calculated at first boot. While a handful of EEPROM chips may have been booted for QA purposes, the overwhelming majority of them will not have a UUID until you put the kit together and turn it on—meaning that we have no way to correlate a UUID with a device and who purchased it.

Q: Can the bootloader be upgraded over the network?

Yes! It is a two step process. You upload the new bootloader into stage 2, boot into it, and then do it again... The second time it will upgrade the bootloader. The purpose of this being a two step process was to help make it more difficult for me (or anyone else) to accidently write a busted bootloader to the device. I would recommend being very cautious about upgrading the bootloader if you don't have a prop-plug.

Q: Why can't I upload new firmware directly from my web browser?

Because I haven't written it yet.

Q: Is there really a full TCP implementation on the propeller?

Well... Almost. Incoming data can be received reliably---this is necessary so that firmware uploads will work. However, outbound TCP packets are not stored for retransmission in the current implementation, so if a TCP packet is dropped from the outbound stream the connection is effectively dead. For the widgets which have been implemented so far this hasn't been a big problem. This will be fixed in the future, as I am continuing to actively develop the TCP/IP stack.

Q: What license is the source code released under?

All of the source code, unless otherwise marked, is released under the GPLv2. An exception is driver_socket.spin, driver_enc28j60.spin, and api_telnet_serial.spin, which are currently distributed under the GPLv3.

Well folks, the day has finally come. After seven months of work, and with the help of the talented Ladyada of Adafruit Industries, ybox2 kits are now finally available!

The kits are selling for $75 each, and include all of the parts required to build a functional ybox2.

Here is the cool part: You don't need any extra tools to reflash the firmware! The EEPROM in the kit comes preloaded with an ethernet bootloader I wrote, which allows you to upload new firmware to the device over the network! This works so well that over the past month or so I've used my prop-plug only two or three times. 90% of my development—including development of the bootloader—has been over the network.

More information is available in the FAQ.

UPDATE: The ybox2 made it on Engadget!! w00t!

From the Android SDK M5 API Changes Overview, Dave Cridland pointed out the following:

The com.google.android.xmppService package has been replaced by the com.google.android.gtalkservice package. This is driven by the fact that the GTalk API is not XMPP compliant, and will be less so going forward. The reason is that XMPP is too verbose and inefficient for mobile network connection, and the GTalk API will be moving to a binary encoding for the protocol between the client and the server.

I'll enumerate the implications and conclusions:

1. XMPP is verbose.
2. XMPP is inefficient for mobile networking.
3. A proprietary binary protocol would be more efficient for mobile devices.
4. The former Android xmppService API will diverge away from XMPP.

I think that this direction is unfortunate, and the reasons misguided. Read on, and I'll elaborate...

I participated in the Give-1 Get-1 program last month, and a few weeks ago I got my shiny new OLPC XO-1 laptop. I took a picture of myself using the built-in camera. As you can see, my cat Zahki never misses a photo-op.

After playing around with it for a few days, I have come to a few conclusions about the device. And, for my own amusement, I'm making this post entirely from my XO-1.

When I first started messing around with Teredo tunneling, I was really impressed with how it allowed me to get access to the IPv6 internet from just about anywhere. In fact, it excited me so much that I wrote a teredo client for MacOS X based on Miredo.

But lately teredo hasn't been all it's cracked up to be, and I think I know why: BGP routes to broken teredo relays. Whichever teredo relay which happens to be covering most of North America is really busted. I can connect to Japan (kame.net) just fine. I've been having problems like this for months but it only recently got really bad, because I no longer have a teredo relay set up at my home. Even though most of the IPv6 internet has been unavailable thru teredo for months, I didn't really notice—because at least I could access my home network. Now I can't even do that.

This is a damn shame. What was once a very promising transition path from IPv4 to IPv6 has fallen into such a state of disrepair that it has become useless.

I finally got the finished PCB for the ybox2 in the mail yesterday. I populated it last night, but I ended up running out of parts. A quick run to Fry's combined with some early-morning soldering, and behold...

It works! Woo-hoo! Now comes the hard part: the Propeller TCP/IP stack.

By popular demand, I've made a video of the ambient color lamp in action. This version may look a little different than the previous pictures, as I am still experimenting with what works best.