ybox2 FAQ

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!?


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 driversocket.spin, driverenc28j60.spin, and apitelnetserial.spin, which are currently distributed under the GPLv3. :(