Category Archives: Internet of Things

Two bits of hardware on order…

Yes, my fascination with cheap computing devices continues. I’ve got two bits on order at the moment.

First is the Pine A64 from Kickstarter. This one won’t be showing up for a while, but seems to be a pretty nice piece of kit. You can think of it as a competitor for the Raspberry Pi, but it’s got a few additions that seem pretty interesting. You can order them with up to 2G of RAM, it can drive a 4K display, it has a real time clock, and it’s actually cheaper than the Pi.



Second is the LinkIt Smart 7688 Duo from Seeedstudio. It should ship to me fairly quickly, and I’m pretty excited by it. It runs Linux OpenWRT, which I have had some experience with on other router hardware. It’s tiny and limited, but still powerful. I view it as basically competition for the WRTnode, which has similar specs and also runs OpenWRT, but this one nicely includes a microSD card slot. I will try to get it up and running and maybe do a comparison between the two when I get it.

Stay tuned.

Beginning to look at MQTT…

My weekend experiments lead me eventually toward flashing nodemcu, a Lua based firmware that runs on the ESP8266. Having a simple programming language (albeit one I’m not super fluent in) is very cool, and enables a whole bunch of nifty experiments.

While reading up, I encountered the acronym MQTT again. From Wikipedia:

MQTT (formerly Message Queue Telemetry Transport) is a publish-subscribe based “light weight” messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a “small code footprint” is required and/or network bandwidth is limited. The Publish-Subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message. Andy Stanford-Clark and Arlen Nipper of Cirrus Link Solutions authored the first version of the protocol in 1999.

So, I thought I’d experiment a bit. I installed an MQTT broker called Mosquitto on a spare Raspberry Pi along with some simple command line clients and the python library with this command:

sudo apt-get install mosquitto mosquitto-clients python-mosquitto

The mosquitto broker is started automatically. In its simplest form, you can run a client that “subscribes” to a given “topic” in a shell window.

mosquitto_sub -d -t hello/world

The -d specifies a slightly noisy “debug” mode. You’ll keep keepalive ping messages from the broker. The -t specifies the topic as something that looks like a path expression. You can specify more than one pattern, and there are expressions to wild card match subexpressions within the pattern. By default, these will connect to a broker on your localhost, but if you specify a -h flag, you can contact brokers running remotely (indeed, this will be the common case for IoT applications.)

From another window, you can “publish” to all clients which are subscribed to this topic:

mosquitto_pub -d -t hello/world -m "Hello world."

This sends the message to anybody subscribed to hello/world. You can send pretty much anything: it’s up to the application to know what to expect and what to do with it. You can even send the contents of complete files.

mosquitto_pub -d -t hello/world -f sendme.txt

So far, it doesn’t look all that exciting, but looks can be deceiving. First of all, the client code is relatively small and simple. This means that it’s easy to put into the small, low memory, low power nodes that you will typically use as sensors. There are already libraries for the Arduino and as I mentioned at the start, it’s already builtin to the nodemcu firmware for the ESP8266. Because it’s lightweight, even very modest brokers can handle huge numbers of messages. To give you some idea of scaleability, Facebook Messenger uses MQTT to route messages between users with very low latency, and without chewing the battery power on your mobile device. And it enables two way communications to sensor nodes, clients can both publish and subscribe at the same time.

As an experiment, I’m thinking of creating a notification service for my hummingbird camera that will update me when new captures occur. It seems pointless (and is) but it’s all a learning experiment. Eventually, I’m sure I’ll get back to the ESP8266.

Oh, and incidently, I’ve ordered some MCP23017 I2C I/O extenders, and hope to experiment with those on the ESP8266. They are nifty little chips which provide 16 additional digital I/O lines all under I2C control. Combined with the ESP8266, you’ll be able to sense lots of buttons and light lots of LEDs. Perhaps with the addition of an I2C A/D converter (or any other I2C sensor), you can do some serious tinkering.

First electrons for the ESP8266…

IMG_5702In the telescope making world, we call the first time that a telescope is used to look at the sky “first light”. I’ve decided to call the first time I load some code onto a new development board “first electrons”.

A few weeks ago, when I did a video that illustrated some of the bucket of development boards that I had lying around, I decided that I should at least make a sincere effort to try to do something, anything, with each of them. Since then, I’ve discovered platformio which has enabled me to at least get some code running on the more obscure ARM based boards that I had lying around. Buoyed by that positive experience, I sought to see how I could get code running on some of the other boards. Tonight’s board was the ESP8266, a little cheap board (I paid $6 or so for mine, I’ve seen them on eBay for as little as $3) which are often used as serial-Wifi links, but which actually include a nifty little 32 bit SOC.

Luckily, the gods have smiled in the form of a three part article (Part 1 Part 2 Part 3) by Alasdair Allen for Make magazine. Previously, getting code to compile onto the ESP8266 required finding the right version of gcc and the download esptool, configuring it… Who has the time? What’s awesome is that now you can download a version of the Arduino environment that already has the necessary compiler and tools installed, and use the friendly, comfortable Arduino environment to compile and run code.

So, tonight, that’s what I did!

Conveniently, I had an 3.3V FTDI serial cable that I had purchased back when I was experimenting with 3.3V boards. That’s convenient, because otherwise I’d have to wire up a 3.3V voltage regulator, which isn’t hard, but at least takes one more step. Using the diagram in Part 2 of the article listed above, I setup some jumper wires to connect it all up. I then downloaded the necessary version of the Arduino environment (for my Linux laptop), installed it, loaded the WifiServer example application, modified it with my own network’s SSID and password, and tried compilation. It compiled fine, but when I tried to download the new code to the ESP8266, I got a communication error. I double checked all the connections against the diagram, no dice. Hmmph. There was one small bit of confusion that I always have when hooking up serial devices: the RX (receive) pin of one side needs to be connected to the TX (transmit) on the other, and vice versa. But when you try to document this, it can be confusing: if an end of your cable is labelled RX, does it mean that you should attach it to the RX? Or that the other end of the cable is RX, so you should connect it to TX?

I swapped RX and TX. And voila. The download works just fine.

To reboot and run the code, you need to remove one of the ground connections from the boad and cycle the power. I then fired up the serial monitor, changed the baud rate to 115200, and then watched it boot. It printed out that it was attempting to connect to my network, printed a series of periods, and eventually reported it’s IP address.

Nifty! I need to go dig up some current limiting resistors (maybe 220 ohms or so) so I can test it, but I verified that if I accessed http://192.168.1.116/gpio/0, it turns the gpio pin low, and http://192.168.1.116/gpio sends it high. Voila!

Well, with a few caveats. It seemed a little unreliable, and seemed to hang a couple of times. I’m not sure what the deal is. I’m suspicious about how much power my FTDI cable can actually supply, maybe that’s part of it. Or it could be software related. I’ll have to play with it more to be sure. But it’s pretty nifty. I’m sure I’ll be playing with it more. Good stuff.

Addendum: I dug up an LED and a 330 ohm current limiting resistor, and then recorded this trivial little demonstration.


Another bit of programmable hardware: the WRTnode

I’ve got a weak spot for cheap, programmable hardware. In my junk drawer I’ve got a collection of Arduinos, Parallax Propellor boards, a couple of STM32 based ARM boards, and several Beagle Bone Blacks and Raspberry Pis. Today, another entry arrived: the WRTnode.

I’ve only had it out of the box for a few hours, and a little bit of tinkering, but here are my initial impressions.

WRTnodeA few basics first: it’s a small, cheap Linux computer. Nominally, the list price is supposed to be $25, but I ordered mine via the Amazon store and paid a bit of a premium: it cost $35, but shipped in two days via Amazon Prime. It comes in a small plastic box the size of an Altoids tin, and includes a little USB cable that allows you to chain an extra USB device to it, as well as provide power. I plugged mine into a little D-Link USB hub I had lying around. Seems to work fine.

In terms of capability, it falls somewhere between the Arduino and a Raspberry Pi. The processor is actually not ARM based, it’s an MTK MT7620N MIPS processor that runs at 580Mhz. It has a 512Mbit DDR2 RAM and 128Mbit of SPI flash ROM. This is quite a bit less than the Raspberry Pi, but it does have one cool added feature: it’s got a 300Mbit wireless networking chip on board which can do 802.11n. It also can handle USB host mode. Basically, you can think of this as the brains to a fairly reasonable wireless router. It’s a very small board, only 45mm x 50mm, and includes 23 GPIO pins, as well as JTAG and SPI.

Because of it’s rather limited memory, it can’t run full Debian. Instead, it runs the OpenWRT distribution, a small distribution which is often used on tiny embedded boxes that serve as routers. It runs BusyBox, has the tiny shell “ash”, as well as the LuCI web based configuration interface, which is based upon the uhttpd webserver.

Setting it up was pretty darned easy: I plugged the supplied USB cable into it, and the other end into my powered hub. A small blue LED comes on, and about 20 seconds later, a new wireless access point was visible called WRTnode9DDB. If you attach to that network, you are asked for a network password, which defaults to 12345678, and then you can telnet to the device, which defaults to IP address 192.168.8.1. You can login as root with no password. If you run passwd you can enter a new password, and then you can use ssh to connect to it.

Screen Shot 2015-01-02 at 9.14.47 PM

Nifty! If you cat /proc/cpuinfo you can get information about the processor:

system type		: Ralink MT7620N ver:2 eco:6
machine			: WRTNODE
processor		: 0
cpu model		: MIPS 24KEc V5.0
BogoMIPS		: 398.13
wait instruction	: yes
microsecond timers	: yes
tlb_entries		: 32
extra interrupt vector	: yes
hardware watchpoint	: yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa			: mips1 mips2 mips32r1 mips32r2
ASEs implemented	: mips16 dsp
shadow register sets	: 1
kscratch registers	: 0
core			: 0
VCED exceptions		: not available
VCEI exceptions		: not available

and ditto for cat /proc/meminfo:

MemTotal:          61852 kB
MemFree:           22516 kB
Buffers:            4828 kB
Cached:            17928 kB
SwapCached:            0 kB
Active:            14292 kB
Inactive:          10744 kB
Active(anon):       3772 kB
Inactive(anon):       76 kB
Active(file):      10520 kB
Inactive(file):    10668 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2296 kB
Mapped:             1960 kB
Shmem:              1568 kB
Slab:               6028 kB
SReclaimable:       1784 kB
SUnreclaim:         4244 kB
KernelStack:         296 kB
PageTables:          292 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       30924 kB
Committed_AS:       6948 kB
VmallocTotal:    1048372 kB
VmallocUsed:        2204 kB
VmallocChunk:    1032516 kB

OpenWRT isn’t as full featured as some Linux distributions, but it’s not bad. It includes ssh, Python and Lua. It’s got vi. It runs its own small package manager called opkg, which has a pretty good selection of precompiled packages available for install (although its good to be careful, you don’t have an infinite amount of space). Scanning the list, it’s got installation packages for lighttpd, Asterix, and a bunch of other goodies.

I haven’t had a lot of time to mess with it, but I’m fairly impressed so far. I have a feeling I’m going to miss having a C compiler/make setup on the board, but it looks to be pretty simple to cross compile to it from my main Linux box. I have already rebuilt the distribution, and will probably try flashing it sometime soon.

If you are in the market for a little machine with features like this (esp. with WiFi), it might be worth it.

The first Internet of Things Bay Area Meetup and the Air Quality Egg…

Last night, I met with Nanode creator Ken Boak and Chris Jefferies from tinajalabs.com at Cafe Actual in Berkeley for the inaugural IoTBayArea meetup. IoT groups are already going strong in many cities like London, Amsterdam, and NYC, but now that Ken is operating here in the SF Bay Area, he wanted to get a group going here.

The current big project being developed by these groups is the Air Quality Egg: a crowd sourced air quality sensor network based upon open source technology. It’s a new Kickstarter based project too (which I have decided to back)!

Air Quality Egg



Beyond the fact that it uses some cool technology, I like this project mostly because the data it gathers will enable people to understand something about the world that they live in day to day. In the Bay Area, we have the Bay Area Air Quality Management District, a government group established in 1955 by the California legislature to monitor air quality in the nine SF Bay counties. This is the government agency that is responsible for (among other things) the Spare the Air day program, which warns citizens of days with particularly unhealthy air pollution, and urges them to take personal action to reduce the problem. It’s a great program, and they produce some interesting real time data on air quality in different areas, as well as forecasts. The air quality index (AQI) that they report measures ground-level ozone, airborne particles, carbon monoxide, sulfur dioxide and nitrogen dioxide.

So, if the government is doing such a good job, why do we need a citizen network to monitor the same things?

First of all, this data may not be accurate for your neighborhood. If your home or business is located near sources of pollution (such as busy streets or some industrial polluters) in spite of the fact that the overall air pollution in your city is reasonable, you might be experiencing high levels of these pollutants. Or it could simply be a matter of geography: I live in a fairly smallish valley, which might be more isolated from the offshore winds that might blow pollutants away. It would be interesting to understand how the pollution in my relatively suburban environment compared with other locations.

Secondly, an open source archive of raw sensor data opens up opportunities for research. Instead of just getting a single AQI number, we’ll end up with a bunch of spatially distributed raw readings for individual pollutants. Perhaps ozone is the dominant pollutant in your area. Or perhaps burning of yard waste causes particulates to spike in certain areas at certain times of the year. Perhaps we can see the daily variation in carbon monoxide as traffic peaks and ebbs in certain locations.

Third, it encourages citizen participation in thinking about air pollution. Just as “Spare the Air” days challenge us to consider ways to change our behavior to improve air quality, participation in an air quality monitoring network turns something that is easy to take for granted into something that we can understand and improve.

Oh, and it involves cool software and hardware too. 🙂

If any of this interests you, you might try following Ken (@monsonite) on Twitter. The IoTBayArea is just beginning, but I suspect we’ll see some rapid growth. We are shooting for regular meetings, with the next one tentatively set for the last weekend in April (but subject to change, stay tuned). Even if the Air Quality Egg project doesn’t thrill you, if you are still interested in the world of Internet connected devices, I urge you to try to come to the next one, you’ll find like minded people and good conversation.

Thanks to Ken and Chris.