Why you shouldn’t listen to Pat Burns on LinkedIn

An article entitled “Why The Internet of Things and the Cloud Should Break Up” showed up on Reddit and Twitter earlier this week. It sounded promising – I’m a proponent of decoupling IoT systems so that they don’t rely on the cloud, even if they still use the cloud most of the time. What I was greeted with was a terrible opinion piece, full of misinformation.

I don’t know where to start, it’s so bad.

A FitBit wristband connects via Bluetooth with your smartphone but sends your activity data to a FitBit cloud app. Does your personal health data really need to sit in the cloud or can you extract sufficient value from it by simply keeping the data stored locally on your smartphone?

This isn’t the IoT. That’s a Bluetooth device connecting to a phone. He seems to be one of these people who will call anything connected and not a full blown machine “IoT”.

For most of the IT industry — let’s just get this on the table — the cloud today is the hammer and there’s almost nothing that isn’t a nail. And the cloud is an easy place to build an IoT application and operates without the messy hassles of embedded software, endpoint security, FCC regulations, or fertility risks, to name a few.

Firstly, using the cloud generally means adding functionality to endpoints. Take a standard IP camera, accepting connections on port 80, using port-forwarding for remote access. Add cloud functionality to allow remote streaming and the system takes more time to develop. It is not a freebie.

Secondly, using the cloud normally makes endpoint security much less of an issue. Traditional architectures, such as port-forwarding to devices, or customers running their own infrastructure, involve inbound connections to your network and endpoints. Many cloud connected devices have absolutely no ports open at all – SmartThings v2 hub for example. Because of this, endpoint security becomes a lot less difficult.

Thirdly, regardless of your architecture, if you want to use wireless connectivity, you need to deal with RF. I don’t see how the cloud avoids this.

It’s cheap and everywhere. Like beer in your dorm, the cloud today is so popular and so well-capitalized that infecting the IoT was only a matter of when, not if. Spin-offs like cloud analytics or cloud perimeter security (no laughing!) are simply too affordable and too visible to pass up. Traditional enterprise IoT pilots that used to cost $250,000 in enterprise software and systems integration services can be executed at a fraction of this price now due to the cloud.

Developing cloud systems and operating robust, secure cloud systems is a cost and complexity. People are not doing it to avoid cost.

Tools. Compared to older desktop-based tools, cloud-based environments and API’s are vastly simpler to use and integrate while offering robust functionality.

He seems to be conflating using a cloud-based development environment with operating in the cloud. Nearly all cloud based solutions need significant development in traditional languages, on a desktop. It’s not point and click.

Weak endpoints and edges. Endpoints that don’t do analytics, support real-time queries, or even support full two-way messaging tend to spew data remorselessly to an edge router and/or the cloud. Bluetooth, ZigBee, 6lowPAN, and others are all guilty as charged and as a result, they end up driving their users to the cloud.

He seems to have a bee in his bonnet about how “stealthy” wireless protocols are. There really is no link between the wireless protocol used and how much data ends up getting sent to the cloud. They are different layers – one a transport protocol, the other application. Zigbee does send a fair amount of beacon traffic, but none of this ends up outside the PAN. If your app sends a lot of traffic over Zigbee and then your gateway sends it to the cloud, that is not the fault of Zigbee.

It’s not secure. This one is hard to overstate as crummy IoT security is the sordid “yeah, but” in so many discussions about the IoT. IDC predictsthat nearly every IT network will have an IoT security breach by the end of 2016 and IT departments are in full freakout mode now. Endpoint security is comically bad and compounded with a hacker-friendly cloud, what could go wrong?

There is absolutely nothing inherent in the cloud architecture that makes it insecure. In fact, there can be a lot of advantages:

  • Endpoints no longer need to accept any incoming connections
  • Endpoints and gateways accept no user-input, massively simplifying design of secure interfaces
  • Connecting to a central point facilitates use of IDS, a skilled operations team, and regular centralised updates

Equally, there is nothing inherent in a cloud architecture that means the endpoints are insecure. An insecure endpoint will be insecure regardless of the architecture.

It’s not real-time. IoT apps that require real-time responses can’t tolerate the extra seconds or minutes required for a cloud lookup.

and later:

Waiting 2–3minutes for a cloud app to make time for you is a non-starter.

This is just pure misinformation. Going over the Internet adds latency. It doesn’t add “2-3 minutes”, it adds milliseconds typically. 2-3 minutes means the system has been designed badly, and this would be an issue regardless of where it operates.

It may not be faithful. The integrity of your data in the cloud is only as good as the people and systems hosting it. Sensors in your manufacturing facility in Taipei showing you running at 50% below your normal run rate or showing a supply chain hiccup? Hedge funds and competitors enjoy learning about this kind thing!

The integrity of your data on your self-hosted platform is only as good as the people and systems hosting it. Again, nothing inherent about cloud. I would rather have a skilled operations team managing intrusion detection, performance monitoring and disaster recovery than burden a sysadmin with yet another system in-house.

Getting out may be easier than getting in. Once you’ve married a cloud service, how easy will it be to disengage/migrate to another solution at some future date? Is standardization and interoperability in a state that will increase the risk of vendor lock-in? What if the cloud vendor is bought by your competitor and changes policies?

Which is equally true of any bought-in platform. Just remove the word “cloud” from the above paragraph. Vendor lock-in is real however.

A new golden rule of IoT network design is to store sensor data as close as possible to its point of origin and limit its sharing across the network unless absolutely necessary.

You can’t just invent golden rules. Many people want low-cost, low-power endpoints with no storage and no persistence, pushing everything to more powerful gateways or servers. The AWS and Azure IoT platforms both accommodate for this. This is Pat Burn’s golden rule, to sell his product.

The endpoint is key to the golden rule. Better processors, cheaper memory, and better networking stacks from companies like Haystack are evolving endpoints from dumb terminals to independent, distributed computing devices with real-time query (think Google for the IoT) and NoSQL-like filesystem support. Endpoint-centric designs also have the bonus of being more stealthy and secure, faster, cheaper, and better stewards of battery life and wireless bandwidth. In short, good IoT network design should begin with the endpoint in mind and “dumb” endpoint technologies that beacon or create unnecessary security risks should be phased out

I just don’t know where to begin on this.

The enemy of security is complexity. Are you actually trying to argue that having hundreds of endpoints in a distributed network, able to store data and be queried, are going to be more secure than, say, a memory-based RFID tag? Or a transmit-only 8-bit PIC based humidity sensor?

How are these endpoints cheaper?

What is his issue with beacons and stealth? Well – it’s lucky there is another article – “A Simple Proposal To Improve Security for the Internet of Things” to help us demolish yet another series of misconceptions and misinformation.

Almost every IoT security breach in recent news can be traced to the poor architecture of the wireless protocol used by the device.

No, no they can’t.

Firstly, that is very, very specific. “Poor architecture of the wireless protocol”. Not “Weak implementation of the wireless protocol” or “devices using wireless protocols”.

Secondly, neither of the links provided are breaches. A breach is the result of a system being exploited. One is information leakage, the other is a report of a vulnerability.

Thirdly, the Jeep hack was nothing to do with the wireless protocol. Jeeps could be using wired Ethernet and the same issues would have been present.

Fourthly, nearly every IoT breach in recent news has been carried out over the Internet. Not local attacks to the wireless protocol. There is a lot of research into wireless security, and there are a lot of noise at conferences, but the bulk of issues occur over the Internet remotely. Hackers are not sat outside homes and business cracking your Zigbee or wireless burglar alarm.

Avoiding or minimizing the chances of unauthorized discovery is not technically difficult. But today’s IoT technologies like Bluetooth, 6lowpan, Sigfox, LoRaWAN, and others make unauthorized discovery very easy and it creates the worst kind of angst in IT departments.

Most of the protocols make discovery easy because it is intentional. They layer security with discoverability, enabling systems which people can actually use and are actually deployed (unlike Dash7).

The link doesn’t support that unauthorised discovery is causing angst in IT departments. He seems to often do this – provide a link which is vaguely related but doesn’t support the argument. It would be fair to say “IoT is causing angst in IT departments”.

Most wireless IoT technologies were originally conceived as ways to stream large files (Bluetooth, WiFi) while some were designed to be “lighter” versions of WiFi (e.g., ZigBee). Today they are being re-positioned as “IoT” technologies and security, to put it nicely, is an afterthought. Oh yes — some have tried to “layer on” security and may profess to support encryption

Layering encryption onto a transport protocol is completely valid. It’s widely acknowledge that ZigBee, Z-Wave and WiFi, if implemented correctly, are secure from the risk profile that is involved. Skilled hackers are not sat outside your house, waiting for you to pair you Hue bulbs to the hub and grab the keys. It is not happening. Even if they did, all they can do is turn your lights on and off.

I have no idea why they “profess” to support encryption. They all offer encryption. WPA2 is actually a very secure protocol.

hacks for all of these technologies are quite public yet fundamentally traceable to one original sin:

these wireless IoT technologies don’t know how to keep quiet.

What? What hacks of wireless protocols can be traced to not keeping quiet?

More recently, drones are being used to hunt for ZigBee-based endpoints, giving bad actors an easy way to discover, map, and hack ZigBee endpoints:

No, drones are being used to map Zigbee broadcast traffic. This is not enabling anyone to hack Zigbee anymore than putting your house number on the door of your house enables someone to pick your locks.

this type of hack provides all sorts of information about each endpoint, including manufacturer ID.

This is not a hack.

This need to be “discoverable” — and this is not limited to ZigBee, Bluetooth or WiFi but to most wireless IoT technologies — requires a near-constant advertising of a device’s presence, leading to any number of “disaster scenarios” that others have extensively written about.

The link, again, doesn’t support that a wireless protocol being discoverable will lead to any disaster scenario. Just pile the links on and hope no one checks.

There is no technical reason that the Internet of Things cannot embrace silence, or stealth as I prefer to call it, as a first principle of endpoint security. Stealth is not a silver bullet for IoT security (there is no silver bullet) and stealth alone won’t protect a network from intrusions, but dollar-for-dollar, stealth is the simplest, cheapest, and most effective form of IoT security protection available.

There is, quite literally, nothing to support this position.

A endpoint, receiving and sending plaintext, unauthenticated commands and data, will not see a noticeable improvement in security. Passive monitoring of the channel will still leak data, and active tampering will cause havoc. The stealth must be broken for the device to send, and this can be seen.

An endpoint, receiving and sending encrypted, authenticated commands and data, will not see a noticeable improvement in security. The data is still encrypted. Unauthenticated commands won’t be carried out.

This is just garbage.

Dollar for dollar, it might be worth making your nodes quieter, but not at the cost of switching from a widely adopted, widely inspected wireless standard to Dash7.

He tries to explain why:

Cloaking. It is harder to discover, hack, spoof, and/or “stalk” an endpoint if a hacker cannot locate the endpoint.

Endpoints need to send. Being stealthy can reduce the traffic but there will still be traffic. Stealth is only a weak layer of security through obscurity.

Googling the IoT. Stealth enables real-time queries of endpoints, a la Google search that non-stealthy endpoints can’t support. Stealth also enables fast queries (<2 seconds) in environments with thousands of endpoints, in turn enabling big data analytics at the true edge of the network.

This has absolutely nothing to do with how stealthy communications are from the node. If you enable your node to be queried, it can be queried. In fact, querying and accessing data from the edge of a network almost negates attempts at being stealthy as you will see an increase in complex and important traffic of the wireless network.

Minimize interference. Less data being transmitted minimizes the opportunities for interference and failed message transmissions. Contrast this with the tragedy of the commons at 2.45 GHz, where WiFi, ZigBee, microwave ovens, and other countless other technologies engage in wireless gladiatorial combat and cause too many customers to return their IoT gadgets because they “don’t work”.

Again, this has very little to do with stealth. 434MHz – that Dash7 uses – has as many issues with contention as 2.4Ghz. In the UK, there are many more poor quality, untested, non-standards compliant transmitters in the 434MHz band than there are on 2.4Ghz.

Access control. Stealthy endpoints make it easier to control access to the endpoint by limiting who can query the endpoint.

Again, absolutely no link between stealth and access control. If you limit access to something, you limit access to it.

Storage. Less data being transmitted reduces storage costs. Storage vendors, on the other hand, love the non-stealthy IoT status quo.

Again, what? If your endpoint decides to ditch data, then your cloud can also decide to ditch data. This has nothing to do with stealth of the wireless protocol – it’s about volume of data at the application layer.

At this point, I’m bored of this. These articles are utter crap.




Converting a USB BUB II to use a 3.3V regulator

Anyone who works with Arduino for any length of time will become familiar with the FTDI USB to Serial bridges. These convert the USB interface found on all modern computers into a simple serial interface, required by many Arduino boards for their bootloader.

There are many FTDI cables and boards available. A lot of Arduino boards have a built-in FTDI chip (the older ones with a USB port). Many vendors sell FTDI cables which have USB on one end and a pin header on the other (the chip is embedded in the USB connector). There are also a lot of breakout boards available.

There are two important voltage specifications on each cable:

  • Signalling voltage – they are generally available in 5V or 3.3V signalling. It is possible to damage some 3.3V boards using 5V signalling. With the ATmega microcontrollers, you should never exceed 3.8V on any pin with Vcc at 3.3V, but it doesn’t seem to cause damage. Conversely, a ATmega running with Vcc at 5V will pick up 3.3V as logic high with no issues. If in doubt, go with the 3.3V cable.
  • Power supply voltage (Vcc) – the normal FTDI pin out provides a power supply on one of the pins. Generally you get either 5V or 3.3V. The 5V versions often supply VUSB direct – so you can draw 500mA. Most of the 3.3V ones however use the pin 3V3OUT on the FTDI chip, which cannot supply more than 50mA (and the FTDI chip gets very hot when doing so!). This often isn’t enough to power a project. Again, a lot of boards don’t really care, but some ancillaries like radio chips will die if given 5V instead of 3.3V. The ATmega is a very forgiving chip.

There’s one big thing to catch you out here. A lot of the 3.3V cables still provide 5V on the Vcc pin. I didn’t realise this until I frazzled a CC1110 board with 5V.

So there are a lot of combinations of voltages available. Rather than have a four or more FTDI cables handy, I’ve found one particular board is versatile enough to use in all situations, with a bit of modification.

The USB BUB II is available from Jeelabs and Modern Device. It’s a small board, and by default it has 3.3V signalling with a 5V power supply. With a few small changes, it can be a lot more versatile.

It has a some good points that many other solutions don’t have. A small polyfuse protects your computer from over-current (although most machines seem fairly tolerant of this nowadays). It also has RX/TX lights, which are absent on many DIY and smaller boards.

Onto the modifications.

1. There are two pairs of small solder bridges on the front of the board, one labelled VOUT and the other LGLV. Use solder braid to remove solder from whichever combination is currently soldered.

2. Solder a pair of 3-pin headers into the space next to VOUT and LGLV. This allows you to chose between 5V from USB or 3.3V from 3v3OUT using jumpers.

3. Turn the board over and cut the 3v3_OUT trace using a scalpel. Bridge the VR_OUT pads using solder.

photo 2

4. Finally, solder on a 3.3V regulator on the back of the board. Modern Devices suggest a MCP1703 which can provide 250mA. I used a MCP1825 which can provide 500mA as it was what I had lying around.

Now you have a FTDI board which will work for all of your 5V and 3.3V boards, as well as being able to provide power for most small projects.

Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 3

Last time, we installed OWFS to read the DS18B20 sensors connected to the 1-Wire bus and represent the temperatures as a file system. We now need to be able to publish them to the Emoncms to log and display the data.

Publishing to Emoncms is very easy – it has been designed to work with lightweight embedded devices with limited memory. A simple Python, Perl or C program could form a JSON request and post the data periodically. However, my Raspberry Pi is already using an RFM12Pi to receive data from my network of sensors. This uses a demon-ised Python script called oem_gateway to listen to the RFM12Pi and send the data to Emoncms.

You can install oem_gateway by following the instructions supplied on the github page.

I decided to modify oem_gateway instead of rolling my own script. The changes can be seen here, in my github repo.

A new OemGatewayListener called OemGatewayOWFSListener was created. This requires a number of settings in oemgateway.conf:

# Listener for OWFS 1-Wire sensors
  type = OemGatewayOWFSListener
        # The path where the 1-Wire FS is located
        path = /mnt/1wire
        # The node to send as
        node = 9
        # How frequently we should send
        interval = 10
        # What resolution should we read the sensors with
        resolution = 11
        # A list of sensor IDs in full
        # sensorX must be unique
        # ID has 28. (family) and 0000 (blank CRC bits)
        sensor1 = 28.33F749050000
        sensor2 = 28.DB564A050000
        sensor3 = Dummy
        sensor4 = 28.AB1663050000

These are relatively self-explanatory, probably with the exception of “Dummy” sensors. oem_gateway sends all sensor values using numerical indices i.e. {1:18.7,2:18.6,3:19.2} by iterating through a list of values. There are no names or explicit indices, so if one of the data values isn’t present, the indices change, and Emoncms has issues. Rather than change all listeners to have named sensor values, I decided to allow “Dummy” sensors to be placed in the list of DS18B20 IDs.

This means that we can unplug a sensor without impacting the indices, so that Emoncms shifting all the values incorrectly.

This has been publishing temperatures to Emoncms for a number of weeks with no issue now.

DS18B20 in EmonCMS


Whilst this is neat, I would much prefer to use an Arduino to poll the DS2482 and send the data wirelessly to this node – for next time!

Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 2

Last time, we setup the Raspberry Pi so it could read the values from some DS18B20 sensors using the command line tool owfs. We’re a still few steps away from publishing these temperatures to Emoncms at the moment – namely getting owfs to start automatically, reading the values in Python, and then publishing them.

Running owfs automatically

When building owfs from source, you don’t get automatic startup as an option. It is quite easy to setup though.

First, let’s build a config file to store settings:

sudo nano /etc/owfs.conf

And copy and paste this in:

# owfs will source temperatures from this device
owfs: device=/dev/i2c-1

# file system location
mountpoint = /mnt/1wire

It is important to note that this setup means that only owfs can access the 1-Wire bus. The default configuration is to run owserver and then have all other ow* processes connect to owserrver – i.e. it distributes the data. I want to keep my setup as simple as possible, so owfs connects directly to the bus.

Let’s test this config out:

pi@raspberrypi2 /etc/init.d $ sudo /opt/owfs/bin/owfs -c /etc/owfs.conf
pi@raspberrypi2 /etc/init.d $ ls /mnt/1wire
28.33F749050000  28.79774A050000  28.EDEE49050000  bus.0     simultaneous  structure  uncached
28.3474A3040000  28.DB564A050000  alarm            settings  statistics    system
pi@raspberrypi2 /etc/init.d $

Now we need to create an init script:

sudo nano /etc/init.d/owfs

And then copy and paste this into the file:

#! /bin/sh
case "$1" in
        /opt/owfs/bin/owfs -c /etc/owfs.conf
        killall owfs
        echo "Usage: $N {start|stop}" >&2
        exit 1
exit 0

This is totally barebones, but I always use this form of init script and it works well.

Now make it executable:

sudo chmod 755 /etc/init.d/owfs

Then use the very convenient tool, update-rc.d to add links so that this script runs at the appropriate times and runlevels:

sudo update-rc.d /etc/init.d/owfs defaults

Then restart your Pi:

sudo shutdown -r now

Once restarted, check everything is running and you can still see the devices:

pi@raspberrypi2 ~ $ ps aux | grep owfs
root      2175  0.0  0.2  28416  1136 ?        Ssl  23:48   0:00 /opt/owfs/bin/owfs -c /etc/owfs.conf
pi        2340  0.0  0.1   3544   808 pts/0    S+   23:50   0:00 grep --color=auto owfs
pi@raspberrypi2 ~ $ ls /mnt/1wire
28.33F749050000  28.79774A050000  28.EDEE49050000  bus.0     simultaneous  structure  uncached
28.3474A3040000  28.DB564A050000  alarm            settings  statistics    system
pi@raspberrypi2 ~ $

Publishing 1-Wire temperature sensors to Emoncms via a Raspberry Pi part 1

There are a number of sensors that can be used to monitor temperature using a microcontroller. RTDs, thermistors, LM35s, thermocouples and so on. These are all analog output sensors, and this introduces a few problems:

  • You need to use a single analog input (ADC) for each temperature sensor, and this might also include additional buffer/amplifier circuitry, Wheatstone bridges or horrible stuff like cold junction compensation on thermocouples. ADCs also tend to be power hungry and slow in small microcontrollers.
  • Each sensor needs it’s own cable running back to the microcontroller.
  • As cable runs increase in length, you end up with all sorts of nasty analog issues like voltage drop, noise, etc.

There is a way to avoid these issues – using digital temperature sensors like the Dallas DS18B20. These solve the above problems.

  • You only need to use a small number of digital IOs to interface to the sensors (either directly, or via a bridge chip). This can be as little as a single pin.
  • Tens or hundreds of sensors can be on the same bus, massively reducing the number of inputs used, and simplifying cabling especially when you are reading more than a few sensors.
  • Driving a bus digitally is much easier than reading analog values. Many of the bridge chips have quite advanced features to deal with the analog gubbins (slew rate control, power active pull-ups etc.)

It’s for these reasons that I much prefer using DS18B20 sensors when I can. They do have some disadvantages though:

  • They are slow to respond and slow to read. With 9-bit precision, a reading takes at least 100ms. At 12-bit this increases to 750ms. You can sleep your microcontroller during this period, so this is more a latency than a power issue.
  • They have a narrow temperature range compared to a lot of sensors – only -55degC to 125degC. But this is more than enough for domestic heating flow/return and ambient air temperatures.
  • They are costly – about £4 a go through big suppliers (though closer to £1 if you buy 10 on eBay), possibly offset by other advantages like less circuitry and cabling.
  • They are only readily available in the bare TO-92 package. There are waterproof versions, there are stainless steel pocketed versions, but they are much harder to find than PT100 waterproof sensors.

In balance though, I feel they are ideal for this project.

Previously I have driven the DS18B20 sensors directly off a pin on the Arduino, bit-banging the 1-Wire protocol using the excellent 1-Wire and DallasTemperature libraries. This works – mostly. However, as soon as cable runs get longer or network topologies get non-ideal, you start getting errors – the dreaded 85degC readings.

The Raspberry Pi has far weaker IO drive than the Arduino (16mA per pin vs 40mA on an ATmega328), and is far less resilient to ESD and mishandling. I was really concerned that directly using an IO pin in a real world application would cause problems, so started looking for a add-on driver board. I quickly found the Sheepwalk Electronics RPI2 I2c to 1-Wire bridge. This is a small plug-on board, with a DS2482-100 1-Wire master, PCA9306 I2C voltage level converter, and a DS9503 1-Wire ESD protection IC. This takes the hard work out of doing 1-Wire, and is supported by lots of software. I also ordered a passive hub and a number of RJ45 connected DS18B20 sensors.

The I2C->1-Wire bridge

The I2C->1-Wire bridge

So, how do we get these working with a Raspberry Pi?

Make sure you can communicate with the I2C device

The I2C module is blacklisted by default on Raspbian. You need to edit a file to stop this happening by removing it from the mod probe blacklist file:

sudo nano /etc/modprobe.d/raspi-blacklist.conf

and comment out the line with a hash.

blacklist i2c-bcm2708

You also need to make sure the i2c-dev module is loaded. This isn’t dev=development but dev=/dev i.e. access the i2c device via /dev. To do this, edit modules.conf:

sudo nano /etc/modules

And add the line


right at the end.

You can now either restart, or issue the following commands to make sure the modules are loaded:

sudo modprobe i2c-bcm2708
sudo modprobe i2c-dev

And you can confirm they have loaded using:

pi@raspberrypi2 ~ $ lsmod | grep i2c
i2c_dev                 5557  0
regmap_i2c              1645  1 snd_soc_core
i2c_bcm2708             3949  0
pi@raspberrypi2 ~ $

We’re good to start communicating with the DS2482-100 bridge chip now, and to do so, we are going to use i2cdetect, which is part of the i2ctools package. Issue the following command to install this

sudo apt-get update && sudo apt-get install i2c-tools

Now run i2cdetect:

pi@raspberrypi2 ~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
pi@raspberrypi2 ~ $

This shows the device at i2c address 18 – you can alter this to another value using some jumpers on the RPI2 board. You can see my i2c bus isn’t exactly jam packed, so we will stick with 18.

Communicate with the 1-Wire bridge

Now we need to communicate with the 1-Wire bridge. There are a number of pieces of software that can do this, but for simple temperature monitoring, OWFS (1-Wire file system) seems popular.

The standard package available from normal repos is 2.8p15, and the latest code is 2.9p1. There are enough changes that I wanted to build from scratch.

There are a few bits and pieces that need installing for this to work on the default Raspbian install.

sudo apt-get install python2.7-dev libfuse-dev swig

This won’t build PHP etc. libraries for OWFS but I am not very likely to be using PHP.

Next we need to get the source and unpack it.

wget -O owfs-latest.tgz http://sourceforge.net/projects/owfs/files/latest/download
sudo tar zxvf owfs-latest.tgz -C /usr/src

Then we need to configure:

cd /usr/src/owfs-2.9p1
sudo ./configure

You need to make sure this confirms that it will build with the options you need.

Current configuration:

    Deployment location: /opt/owfs

Compile-time options:
                      USB is DISABLED
                      I2C is enabled
                       W1 is enabled
    Parallel port DS1410E is enabled
         Zeroconf/Bonjour is enabled
             Debug-output is enabled
                Profiling is DISABLED
Tracing memory allocation is DISABLED
1wire bus traffic reports is DISABLED

Module configuration:
                    owlib is enabled
                  owshell is enabled
                     owfs is enabled
                  owhttpd is enabled
                   owftpd is enabled
                 owserver is enabled
               owexternal is enabled
                    ownet is enabled
                 ownetlib is enabled
                    owtap is enabled
                    owmon is enabled
                   owcapi is enabled
                     swig is enabled
                   owperl is enabled
                    owphp is DISABLED
                 owpython is enabled
                    owtcl is DISABLED

pi@raspberrypi2 /usr/src/owfs-2.9p1 $

You need i2c and owfs support in there for what we are doing.

Now you need to build and install, expect this to take a long time on the Pi (30-60m):

sudo make && sudo make install

owfs allows us to access the i2c devices using the file system. To set this up, first create a directory for the devices to show up in:

sudo mkdir /mnt/1wire

owfs uses something called fuse to allow it to create the filesystem representing the 1-Wire bus and devices. I don’t fully understand what it does, but you need to change one of the options by editing fuse.conf:

 sudo nano /etc/fuse.conf

and then uncomment this line by removing the #:


And last, at least for this part, we are going to start owfs manually and check that everything is working:

sudo /opt/owfs/bin/owfs --i2c=ALL:ALL --allow_other /mnt/1wire/

This starts owfs, looking at all available i2c bus masters, and mounts the result in /mnt/1wire. So we take a look in /mnt/1wire

pi@raspberrypi2 ~ $ cd /mnt/1wire
pi@raspberrypi2 /mnt/1wire $ ls
28.33F749050000  28.79774A050000  28.EDEE49050000  bus.0     simultaneous  structure  uncached
28.3474A3040000  28.DB564A050000  alarm            settings  statistics    system
pi@raspberrypi2 /mnt/1wire $

The directories starting 28. are the temperature sensors. Four connected to the hub and one on the hub itself. The other directories and files control settings and provide information about the bus and communication.

Now we can read the ttemperature off all of the sensors:

pi@raspberrypi2 /mnt/1wire $ cat 28.*/temperature
       17.25     17.1875      17.625      17.375      17.125

Yes, our front room is that cold. I broke the heating last night.

The passive hub with additional DS18B20 sensor

The passive hub with additional DS18B20 sensor

In the next part I am going to get owfs starting automatically with the Pi and then read the sensors in a simple Python program.

Bus Pirate power supply oscillations

Earlier today, I saw that Jeff Keyzer (aka MightyOhm) had posted on his blog about power supply oscillations on the Bus Pirate. The Bus Pirate is one of my go-to tools, and 99% of the time it works as I’d hope, so I thought I’d check mine for issues.

Jeff’s SparkFun built Bus Pirate was showing a 15kHz, 150mVpp signal on the 3.3V power supply rail. Surely I would have noticed if mine was doing this?

Ian at Dangerous Prototypes replied to Jeff on twitter:

So I took a quick look at mine, hoping it wouldn’t be the same. I have a v3 Bus Pirate ordered from Seeed Studio many years ago.

It wasn’t the same, but it also exhibited an issue.

Turning on the 3.3V power supply gave me the following trace:


So I have fairly strong bursts of noise, sometimes up to 400mVpp! These seem to repeat at about 150kHz.

Zooming in on one of these bursts:


It looks like something is ringing at about 20MHz.

It was a very similar story on the 5V rail.

So the quick fix is to whack a small electrolytic capacitor in:


I did this for the 3.3V regulator. As soon as I had, the severe noise and ringing on the 3.3V rail stopped.

Interestingly, the noise on the 5V rail stopped as well…

I thought I was going loopy. Yet desoldering the cap causes the noise on both to return.

So what is going on here? Are two regulators oscillating and interacting in a bizarre manner? Who knows. I’m just going to put a second cap on the 5V regulator as well.

Does this make the Bus Pirate worthless? No. I doubt the noise would cause problems for most people. I doubt the noise is as serious when load is placed on the regulators. The fix is incredibly quick and easy. It’s still an incredible tool.