Making cables


I have to build all these cables by hand.  It’s not difficult, but I always get to a point where my eyes cross and I forget what I’m supposed to do next.


Xbee lessons

I’ve been using the Digi International Xbee radios in a project at work, and I thought I would share a few findings that weren’t always clear on some of the internet guides I found.  I use the Series 2 (or ZB) version, which you can get at Mouser for $17.  These have the ability to use the mesh networking feature of the Zigbee protocol.

The first bit of disinformation I have found regards the use of API or Transparent mode.  The first uses a packet of bytes to tell the radio what data to send, how to send it, and where to send it.  The second allows serial data to be transmitted directly, without the need of a frame.  Most tutorials indicate that all your radios should be set up in one mode or another.  This is incorrect.  Dave over at Desert Home tipped me off to this, and has a bunch more excellent examples of using Xbees.  I guess I should warn any readers that this discussion is for those who have some knowledge of Xbees already, and understand terms like API, transparent, Router, Coordinator, and PAN ID.  Otherwise, Dave’s site is a great place to get started, as is Jeremy Blum’s tutorial.

I can think of a very valid reason for using a mix of transparent and API modes, and it has to do with the how easy it is to change the settings in each mode. In transparent mode, changing the destination address, or any other setting for that matter,  requires entering command mode.  This is not too bad if you’re connected to a serial port display like Putty, but can be a bit cumbersome when using  a micro-controller or some other programmed interface.  In API mode, however, the packet can be constructed to change the settings on the fly rather easily, because you don’t have to put the radio into a special mode, you just have to know how to build the right packet (something that micro-controllers are very good with).

So why would you ever use transparent mode with an Arduino, for instance?  Because there are plenty of times that you  don’t need to change anything.  You just need to configure it once to send serial data to a known destination (usually the Coordinator, but the other most common destination is Broadcast, which sends the data to every radio on the network).  And yes, you can use an API Router with an transparent Coordinator, if you’d like.  The point is that you can mix and match the radio setups.

That leads into the next bit of disinformation, that the radios have to have the same baud rate, API mode, etc.  The truth is that only some of the settings on the radio regard how it communicates on the network: PAN ID (both 16 bit and 64 bit), serial number, destination address, operating channel, and the like.  In the X-CTU software, these are grouped together under the Networking and Addressing categories.  Security is another big one, but not often used.

But the category of Serial Interfacing, which is where settings are most often changed,  only deals with how the radio communicates with it’s host, whether that’s a computer or an Arduino.  If you have one radio transmitting in API enable 2 set, you must provide escape characters when you assemble your packet.  But if the receiving radio has API enable 1 set, that data will be read out with no escape characters.

And one last thing to remember, which I haven’t seen anywhere else: Xbees want to be on a network.  They will seek out whichever is available unless they think they are already on one (which has burned me a few times).  And if they are a Router, they don’t need a Coordinator in the network to get new nodes to join.  According to the Xbee data sheet:

A coordinator has the following characteristics: it
•Selects a channel and PAN ID (both 64-bit and 16-bit) to start the network
•Can allow routers and end devices to join the network
•Can assist in routing data
•Cannot sleep–should be mains powered
•Can buffer RF data packets for sleeping end device children.

A router has the following characteristics: it
•Must join a ZigBee PAN before it can transmit, receive, or route data
•After joining, can allow routers and end devices to join the network (emphasis mine)
•After joining, can assist in routing data
•Cannot sleep–should be mains powered.
•Can buffer RF data packets for sleeping end device children.
An end device has the following characteristics: it
•Must join a ZigBee PAN before it can transmit or receive data
•Cannot allow devices to join the network
•Must always transmit and receive RF data through its parent. Cannot route data.
•Can enter low power modes to conserve power and can be battery-powered.

In other words, if you are working on a set of radios, and decide to set up a different network nearby, even if you remove the Coordinator from it’s power, your new radios will try to join the first network if any of the Routers are still powered.  It can cause all kinds of fun and hours of entertainment!  The best bet is to remove all power to the first network, set up the second network, and make sure the second is configured properly before powering up any Router or Coordinator on the first network.

I’m sure there’s lots more to learn about these great little radios, but I thought I’d pass along these tips now.

Raspberry Pi

I’m an electronics engineer, and specifically, I design electronics that test other electronics.  I love my job, and I love finding new technology to solve problems.

Right now I am exploring the world of single board computers (SBCs).  I have four, and I am always looking at new ones.  I have the Raspberry Pi Model B, the UDOO Quad, the PCDuino (the link is for a version 3, but I have several of the originals), and the Iteaduino Plus A20.  Each has something that sets it apart from the others, and each is touted as the greatest thing ever.

But from an engineering perspective, there are trade-offs.  The biggest one is the cost/benefit ratio.  The RPi is the least expensive, at about $40 in most places, while the UDOO Quad comes in at $135.  The feature sets are reflective of the price, fortunately: the RPi has 512Mb of RAM, and a single core ARM1176JZF-S  processor running at 700 MHz.  The UDOO has 1Gb of RAM, a quad core ARM Cortex-A9 running at 1Ghz, and a built in Arduino Due.  These are not minor differences, and the price reflects it.

But what about usefulness?  I am looking for something that runs a Linux distro, but has GPIO pins I can manipulate.  Both do this.  I’d like to talk to it using serial communications, and have support for I2C and SPI bus communications.  Okay, still good on both.  And I need to collect data, collate it, store it, and push it out to a cloud platform.  Again, both meet this need.

What I don’t need to do is stream videos, have a super cool GUI, or act like a desktop replacement.  And yet… both will do this, though the UDOO is better at it. And I am not making a DIY tablet, which is good, because both have drawbacks for that application.

And for me, the kicker is this: both need a monitor, a keyboard and mouse, and some kind of SD card for both the operating system and for storage.  So for what I intend to use it for, the Raspberry Pi is a more cost efficient solution.

I’m not going to stop looking at all the new SBCs that are coming out, though.  Maybe one of them will have something that I really want.

Where are we going?

I had a discussion with a friend recently about the future, specifically the future of the internet.  He works in technology, is arguably more plugged in than I am, and yet his contention was this: If Comcast can charge customers for access the higher bandwitdths, then the internet as we know it will change forever.  no longer will there be a low barrier to entry and innovation, but it will be restricted to those who can pay a premium.

I respect my friend, and think he’s brilliant.  He is also correct in the sense that if you can charge for getting your content to consumers, then the only content consumers will see will be produced by deep pocketed corporations.

But he misses two important things in this view.  The first, most important, is that Comcast will be able to get away with this for a year or two at most.  The most remarkable thing about our era is not the internet itself, but the innovation constantly being applied behind the scenes.  I remember using the Prodigy service ages ago, and playing simple graphic games over a dial-up modem (28.8K, if I remember it correctly).  Will people be willing to return to this level of technology if Comcast sits on bandwidth like an elephant on a water hose?  Probably not.  But they won’t have to, because while Comcast thinks they control the flow of the water, a million leaks are going to spring up to get the water where it needs to go.

And that leads to the second thing my friend missed: he thinks it’s all about selling to customers.  But the internet is more about communicating than it is about selling.  Sure, Comcast might dent the money making aspects of the internet, but I think that overall, they cannot prevent the flow of ideas.  Look at Twitter: 140 characters to get your point across, and it takes so little resources, that even if Comcast cut off Twitter itself, a thousand clones would spring up inside of a week.

Comcast (and the government) want control of the internet.  But I think that they are reacting to what has happened in the last ten years, and are unable to even predict where the next ten might take us.