Entries : Category [ Computers and Technology ]
[Miscellaneous]  [Computers and Technology]  [Travel]  [Education]  [Hacks]  [Robotics]  [Science]  [Programming and Software]  [iPhone]  [Digital TV and Video]  [Intellectual Property & Copyright]  [Personal] 

18 October
2009

Last week I was in Mexico and gave a keynote talk at the International Congress on Multidisciplinary Research at Monterrey Tec (more formally Tecnologico de Monterrey). The general chair was Dr. Marco Iván Ramírez-Sosa Morá n who turns out not only have be working on some interesting topics in control theory, but to be an extremely nice guy. The meeting and the campus were quite impressive. It also didn't hurt to have a chance to warm up a bit. In addition, I had a chance to visit Luz Abril Torres-Mendez who is now a faculty member at Cinvestav in Saltillo, Mexico. Her lab is looking at computer vision systems for underwater vehciles, among other things, and thus shares several interests with our own lab.

In a bit of free time one afternoon I visited the Desert Museum in Saltillo. It's quite diverse and includes an exhibition on fossils, dinosaur reconstructions, a huge taxidermy collection, a substantial live snake collection (serpentarium), various cacti, and lots of other stuff. Well worth checking out if you are in the area.



By Gregory Dudek at | Leave a comment |    
16 November
2009

I gave a talk on recommender systems at the Drupal Camp Montreal meeting. The nice people at DBN.ca did a great job of
recording the talk and have put it on line. It's not super-technical but it gives an overview of recommender systems in general and a bit about how our particular system, Recommendz.com, operates.


By Gregory Dudek at | Leave a comment |    
14 July
2010

This post deals with Xbee/Zigbee firmware with non-windows software for editing the Xbee parameters from the command line. There's also a trick for re-flashing and Xbee in an Arduino shield. Below, I explain the different kinds of hardware and software.

Contents: my application, XBee hardware versions (confusing!), firmware versions, non-Windows programming software (Mac OS X, Linux, etc.)

My application

Last weekend I implemented a GPS broadcasting system using Xbee (Zigbee) modules from Digi International. These are small wireless networking nodes that can be connected using a serial line. The Funnel IO variant of the Arduino open source CPU module directly supports the Xbee hardware, and also provides a lithium-polymer charging circuit, so it seemed just right for my needs. (FunnelIO is very nice, but poorly documented.) The idea was to receive GPS data on one module and transmit it to another one (that was in a location where direct GPS reception was impossible: i.e. inside our robot). While everything seemed pretty straightforward in principle, I had few problems.


XBee rear
(click to zoom)



I programmed the Arduino to pull in GPS data on a software serial port, and then retransmit the data on the hardware serial driver connected to the Xbee. I also wrote some diagnostic code to verify the GPS data was solid, to check the fix and do some housekeeping. This worked well, and I was even able to deploy the GPS receiver at the end of a 10 meter cable. When I tried to relay the data across the Zigbee link, however, I encountered all kinds of data losses. These looked like buffer overflows which led to lost data.


Hardware

On the whole, I found the terminology and variety of options pretty confusing, partly because terms have changed and there are both obsolete and even misleading documents widely readily available on the net. Also, non-windows support, and even Windows Vista/7 support, was poor. Hence this page.

Firmware and device families

[ Sorry, this part of the story is almost assured to confuse you on the first reading. That's because the mish-mash of names and models is just a mess. Just ahead to the more readable part on "Reflashing in an Arduino shield" is you start to feel sea sick. ]

Now these xbee modules can work in either point-to-point mode, or via broadcast. My first attempt was with broadcast using ZB firmware since that was easier to configure. Well, broadcast mode automatically retransmits packets multiple times (since acknowledgements can;t be sent in a broadcast context). I figured I'd try point-to--point mode. I could never get this to work.

My observations and inferences about the Xbee line:

-- There are at least 4 main families of the hardware, and several variants of the firmware for each hardware family. All the modules on a network should have the same hardware and firmware. (In addition, within each family there may be different modules with alternative antennas, but I'll ignore those little differences since they don't impinge on functionality at a software level.)

-- There are 2 different hardware "series": Series 1 and Series 2, and each has a Pro (and non-Pro) variation. This makes for 4 classes of hardware: Series 1 non-pro, Series 1 Pro, Series 2 non-pro, Series 2 Pro. These different variations differ at a hardware level. You cannot reprogram one to become another.


XBee series 2 indication
(click to zoom)


-- Confusing names: Series 1 is now officially called "XBee 802.15.4." Series 2 was renamed "XBee ZNet 2.5" which is really confusing since this names also seems to be used for one of the types of firmware for these devices.

These two series (1 and 2) are also known as Freescale and Ember respectively, based on the different hardware makers for the 802.15.4-protocol networking chip. The Freescale MC13213 is an integrated radio transceiver and a 8-bit 689S08A microcontroller. The Ember EM250 is a radio and a 16-bit XAP2b RISC microcontroller with AES encryption support and 128kB of flash memory. Series 1 and Series 2 differences are described in this document from Digi.

Firmware versions (4 types)

-- ZNet 2.5 firmware is based on the "EmberZNet 2.5" radio networking software. (This equivalence and terminology is indicated in the Firmware Revision History, although a Digi employee I spoke to disputed some details.)

-- ZB firmware is also known as Zigbee, or more correctly as "ZigBee PRO" since that is the name of the protocol specification it adheres to. It is based on the Ember "EmberZNet 3.x" rio-networking software. Thus, ZB is newer than ZNet 2.5, but for me ZNet 2.5 worked better.


-- Devices running ZNet 2.5 firmware cannot talk to devices running the ZB firmware, even though they are used in very similar ways and with similar commands.

-- Another firmware called 802.15.4 for Series 1 modules also exists, as well as DigiMesh. This makes for 4 different firmware families, and they should all be considered incompatible with one another. Note that 802.15.4 appears the name of one of the firmwares, but it is ALSO the name of the networking protocol. This 802.15.4 has two different meanings: the firmware and a IEEE standard protocol. (Yes, this is bewildering.)

-- The Zigbee networking protocol is defined by an organization called the Zigbee alliance. They have two key variations of the Zigbee protocol: the original Zigbee (Zigbee 2006) and a new protocol called Zigbee Pro based on Zigbee 2007. This "Pro" suffix is unrelated to the word Pro in the name of the "Xbee Pro" module family, where refers to modules with high power output. Also, both these Zigbee protocols are built upon the lower-level IEEE 802.15.4-2003 standard.


-- "XBee Pro" modules operate at higher RF power levels, 50 or 100 milliwatts. Same pinout, slightly longer chip housing for the Pro models. The regular (non-pro) units work at 1 or 2 milliwatts. (It is possible they inter-operate with non-pro, but I have not tried.) Regular XBee devices have serial numbers starting with "XB" (e.g. XB24-B) while Pro devices start with XBP.


Using the "DD" command, you can read the pre-loaded device family code.


The Xbee's using I purchased came with "Zigbee" firmware pre-installed. I believe this is what they suggest for new customers. I could never get point-to-point (non-broadcast) communications to work with or without a coordinator, so I tried another firmware. When I eventually decided to download and burn in the "ZNET 2.5" firmware instead of the Zigbee firmware, everything worked. Point-to-point worked, but I am pretty sure the throughput was so much better that broadcast would have worked fine also. My morale: use the ZNet 2.5 software on the Xbee if you can.

Firmware versions -- details
Using the VL command, you can query the currently-loaded firmware version. It is a 4-digit number (ABCD), but if the last digit is zero it might appear in the form ABC. The digits have the following interpretations:


  • A: seems to be 1 for ZNet 2.5 release firmware, 2 for Zigbee firmware and 8 for beta-test code.

  • B: the "variant". 0 for coordinator in AT mode (one of two possible command languages used for the modules). 2 for end device code. 1 and 3 are for API command mode.

  • C: seems to identify the version of the code. New releases have bigger values.

  • D: revision number of the version.


Thus my XBee Series 2 node in coordinator mode currently uses firmware version 1047.

See also Digi's firmware documentation, the list series 2 firmware releases.



Reflashing in an Arduino shield

To reflash the Xbee firmware you need to use the XCTU program. My Xbee was in an Arduino "shield" (which provides a USB interface). To directly control the Xbee, you need to remove the microcontroller from the Arduino CPU board (as described here). This is great for accessing the Xbee serial interface from a computer, but to use XCTU you will also need to reset the Xbee a couple of times and no such button it provided on the shield. With a small section of wire, you can do this the "hard core" way. Just touch the wire between pin 5 and pin 10 of the Xbee (or the solder pads beside it). Pin five is the reset pin and pin 10 (at the corner of the module) is the ground pin. Pulling the reset pin low (to ground) does the reset. This is pretty easy and works reliably.


XBee reset using jumper
(click to zoom)


Python-based XCTU replacement

I rarely use Windows and thus I also wrote a python-based program to allow the parameters of the Xbee to be queried and set. This allowed me to configure the Xbee from OS X and (later) from other software systems. This is command-line based. I've tested it on Apple's OS X and it is likely to work on Linux. On Windows I have no idea, but Windows supports XCTU which in the vendor supported solution. On the other hand, since as of this date XCTU does not seem to support either Windows Vista or Windows 7, this might be useful even there. If you try this on Windows, let me know what happens. This software does not support re-flashing the firmware, so to switch from Zigbee to ZNet you still need to use XCTU from Digi.

My Python program called "xbee-gdxctu.py" is available for download. Version 2.10 was put in place Feb. 2011, but it might have been updated since (e.g. it was update to v2.1 on Dec 1 2012). This link provides the current version ID.

Note that my program requires the pyserial module that you might also need to download.

This software is is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.Creative Commons License


If you find problems of have suggestions, please let me know. An example session is given below.


Here is an example of what you get when you run the code. By default, it prints some of the key XBee parameters, and then lets you do manual queries. I have also added some comments on the "ND Discover all other nodes" command output (where it detected another node that I had activated).

python xbee-gdxctu.py
Here is an example of what you get when you run the code. By default, it prints some of the key XBee parameters, and then lets you do manual queries. I have also added some comments on the "ND Discover all other nodes" command output (where it detected another node that I had activated).



python xbee-gdxctu.py


xbee-gdxctu XBee configuration tool. 2.1 Copyright Gregory Dudek (c) 2009.
xbee-gdxctu.py using /dev/tty.usbserial-A5002WY6
Try 19200 got: 'OK'
Connected.
---
Firmware: 1047
Non-Beacon Enabled 802.15.4 Code
>> %V Vcc Voltage (multiply by 0.001173; thus 0x8FE means 2.70v)
%V AE8 equal to 3.275016 V
>> BD baud code (2:4800, 3:9600, 4:19200, 5:38400, 6:57600 )
BD 4 => 19200 baud
>> CH Addressing: The channel of the module
CH 17
>> DB Received Signal Strength [in dB] of last good packet (see RC)
DB 41
>> DH Addressing: destination address for wireless communication (hi word)
DH 0
>> DL Addressing: destination address for wireless communication (lo word)
DL FFFF
>> ID Addressing: The network ID (default 0x1234)
ID 1234
>> MY 16-bit address of the spefic module
MY 0
>> ND Discover all other nodes (takes NT*100 ms). MY/SH/SL/DB/NI
11CA


[Article posted 2009/11/24, revisions: July 14 2010, Feb 26,2011,Dec. 1,2012 ]

By Gregory Dudek at | Read (7) or Leave a comment |    
06 April
2010

Here are the top 4 reasons why I am frustrated and disappointed about the Google Nexus-1 made by HTC. Two weeks ago I borrowed a Google Nexus-1 phone for a few days and last week I bought one. I was initially unhappy with my purchase (although I have gotten used to it).

All-in-all I would say the Nexus-1 is usable, but it has numerous rough edges and for such an expensive phone it was a substantial disappointment and frustration.

The key downsides are:

1 - Poor power management and power consumption. The first two days I had the phone, it went from fully charged in the morning to out-of-power before I went to bed. If you turn off the cell-phone radio, the GPS and the wireless and don't run anything intensive, then the battery can last 24 hours. It's not a very useful device in that case, however. This isn't just bad, it's utterly ridiculous and unforgivable.

Low battery -- this should be familiar to Nexus-1 users
Low battery -- this should be familiar to Nexus-1 users




2 - Limited or missing support for WPA-Enterprise ...


Wifi networks. There is lots of discussion on the web about this, but for commonplace network configurations for in professional environments and universities, Android is sometimes unable to connect. For me, this was a show-stopper! The very first iPhones had this limitation also, but that was a long time ago and Android has been around for 2 years.

3 - Excessive dependence on the cloud. This phone transmits and synchronizes data via Google. That means sharing almost everything with Google, which is a serious privacy consideration. Moreover, it means lots of data exchange and a need for a good data plan.

4 - A generally unpolished user experience. The worst thing in this regard is frequently laggy or erratic performance, probably caused by multiple applications using processor time at once. There are lots of other ergonomic rough spots thought: excessively small attachment icons in the gmail program (too small to click reliably), a quit button placed to close to an important key in some cases, inconsistent operating modes, etc.

The dependence on the cloud is Google's key business advantage. I can understand and accept it, but I am very squeamish about them having a bead on everything I do, including who I call and where I go. The absence of robust and complete WPA-Enterprise support is inexcusable -- the Android operating system kernel has the support in it, but the user interface is just too rough. The power management and laggy interface are both indications of what appear to be poor management choices and an absence of sound leadership. This are fixable, but entail hard choices that would limit some the the geekish features at the expense of an overall better (i.e. generally usable) experience.

All in all, this phone has served as an impressive illustration of the great ergonomic design and decision-making that went into the iPhone. I am not ready to buy an iPhone now, but the comparison of the iPhone and the Nexus one provides many object lessons in making though design decisions, and the Nexus-1 seems to come out the loser in several ways.

By Gregory Dudek at | Read (1) or Leave a comment |    
16 July
2011

Last week I was at the Google Faculty Summit in New York City. It is was interesting how careful the Google people were about avoiding "creepy" applications. They purposely avoid a lot of data cross linking just to be "clean", more so than I had expected or realized. This was especially important in the context of their new social network Google Plus (which I get to below). There are cool things they could do, maybe even easily, but which they avoid just to stay on the safe side of what people are comfortable with. That's quite impressive as a policy, and an interesting tradeoff between medium term coolness and long term continuance of user trust.



I think making users trusting is, rightly, a top priority for Google since everything else is dependent on that. Simply providing fantastic serve: that's a relatively easy thing, but trust is this evanescent ineffable thing you can't buy.

One of the topics they talked about was the challenge of keeping the huge legions of Google servers efficiently deployed. John Wilkes talk amount this configuration management issue in the context of their upcoming new system for handling it called Omega.

New York, of course, was the crazy exciting hub of activity is always has been. I stayed in the Standard Hotel in the meat packing district, which is a hub of the fashion industry, and right near the


Google NYC offices (they own a nice big high-rise building there). Well, staying there (a) made me feel hip, and also (b) made me feel like a poorly-dressed yokel (especially in the evening when the Bugatti's were parked on the street). I did drink the metaphorical Google Kool-Aid and discovered a slew of new Google "products" that I had not known about, or lost track of.

I got in on Google Plus about a week ago, in anticipation of the meeting. As most readers probably know by now, it's the new social network Google has launched.
I must say I am loving it, and find it much nicer than Facebook. While the user community is much narrower, I have found quite a few people I know, respect or am interested in. Of course, it helps that I move in techie circles. Most importantly for me though, it has a much more nuanced find-grained model of privacy. I can share some things with one sub-community (i.e. family members and close friends) and other stuff with my profession community. It also has lots of other nice flourishes like great mobile integration with Android devices and a very nice video conferencing feature. On top of that, it really encourages cross-use of multiple Google "properties" like Google Docs (which is destined to get better and better). All in all, I think this is going to be a very very very good year for Google.

By Gregory Dudek at | Read (2) or Leave a comment |    
31 August
2011

I am lucky enough to work in a milieu where I meet smart teenagers and twenty-somethings all the time, and they are often brilliant. Of course, being relatively young they tend to be relatively short on experience. Most of the time, though, they know their own strengths and weaknesses (and if anything suffer from being too modest). That contact made the article about a very rich 26-year-old touting his age and experience relative to his 25-year-old competitors especially amusing.


26-Year-Old Founder Says He’s Way Smarter Than 25-Year-Old Founders
http://gawker.com/5835878/26+year+old-founder-says-hes-way-smarter-than-25+year+old-founders


By Gregory Dudek at | Leave a comment |    
Prev  1   2   3   4   5   6   7   8   9   [10]   11   12   13   14   Next