Lego bug

Bug Labs has developed a modular mini-computer running on open source software. I first read about it in the O’Reilly Radar blog. Bug Labs has promised to make all the source code for the platform available. The main BUGbase module is 10×5 cm big and can accommodate four other modules, each 5×5 cm big.

The system isn’t completely finished, but soon it will be possible to buy the base module and other modules like:

  • BUGlocate – GPS receiver.
  • BUGcam2MP – 2 megapixel digital camera.
  • BUGview – 2.46″ 320×240 pixels LCD screen.
  • BUGmotion – A combined motion detector and accelerometer.

The base module will eventually have built-in WiFi and hopefully they will also make a UMTS (3G) communication module. Applications are developed using Java together with an Eclipse based IDE. I’m very interested to see what kind of applications people might come up with for this thing.

It’s like Lego for grownups.

Advertisements

Slow

This was a slow week. I didn’t get much done in terms of programming and I also took a short vacation a couple of days to clear my head.

Some late breaking news about Android: Google Android phones make debut.

Estimated time used for the project the past week: 30 hours

The Java Magical Service

JMS is like a magical service. Inject a message about a certain topic into a JMS system and other people, who are interested in the same topic, can read the message as well. Maybe not too much magic, but it does work. JMS has basically two types of message channels:

  • Topics – used by publish/subscribe (pub/sub) where the communication can be many-to-many.
  • Queues – used for point-to-point communication.

In both cases the sender and receiver can be decoupled in terms of both space, time and synchronization as described by Eugster et al. in The Many Faces of Publish/Subscribe. JMS also has a hierarchical topic-based publish/subscribe model which is easy to get into. I’ve been working with Apache MQ to implement a simple JMS based publish/subscribe system. The server part of the system is almost functional, but I haven’t started on the mobile client code yet. I’m not quite satisfied with the way the server system processes all the incoming events because the business logic is spread out into several listener classes. My current goal is to find a more convenient way to arrange the logic so that it will be easier to set different policies for the system. I’ll also start writing some code for Android and find out how easy it is to get Android to talk to a JMS based system. Maybe I’ll have to use one of the alternative transports that Apache MQ provides to make it easier.

I’ve done some checking on IEEE 802.1Q and 802.1p (which is rumored to be defined in 802.1G) in regards to the router that might be used in a practical implementation of this system. 802.1p is essentially a standard for providing QoS at the MAC level. It defines eight different traffic classes which are used by 802.1Q. 802.1Q is the Virtual Bridged Local Area Networks (VLAN) standard. In this standard the IEEE has defined a framework called the Generic Attribute Registration Protocol (GARP) for switches and bridges to work with different types of attribute values. GARP is in turn used by a VLAN management protocol called GARP VLAN Registration Protocol (GVRP) which enables you to manage how VLAN configurations are propagated throughout a network of switches (Cisco has a similar proprietary protocol called VTP).

What seems to be the case is that GVRP can only be used to manage switches when there are several connected in a network. According to this article by HP it looks like the first switch must be manually configured. I’m not entirely sure about the technical details, but from what I can tell it doesn’t seem to align with our needs of just configuring one switch and getting it to forward Internet traffic.

Estimated time used for the project the past week: 40 hours