Internet of things – a problem and solution with dynamic DNS

I just found out that Netgear routers support Dynamic DNS. Not bad for a $29 router, like my WNR 1000.

Let me explain what that is cool:

If you want to access an ‘internet thing’ in your house, you need either:

1. A proxy service. OR you need to set it up yourself, with
2. Dynamic DNS + Port Forwarding + IP Reservation. ALL available on your router.

Proxy services offer a lot of features and convenience, but will always control your data and you will always be beholden a 3rd party. So I’m not so keen on those options. It is a tiny,tiny bit more work to set up, but once you have it running, you can effectively make each little ‘internet thing’ accessible (like … 20 minutes work, or less).

Setting it all up.

The WildFire is perfect for this application. So let’s say you have a WildFire running in your home controlling something, and want to access it from your cell phone. Log into your home router and do three things:

1. Reserve the IP address of the device. That is, grab the MAC address, and tell your router “whenever this MAC address connects, give it this particular IP address”. Your router will have a ‘IP reservation’ screen, probably under Advanced > LAN settings or similar,
2. Forward a port on your router. So when a person comes from the outside, and accesses a particular port (like port 80), send them to a particular IP address – the one you just set up. Now you can contact your WildFire from anywhere in the world, by IP address.
3. Use Dynamic DNS to give your WildFire a nice name, instead of an IP address. With Netgear you can sign up directly inside the Admin console. This will give you an address like myhouse.mynetgear.com. You have limited choices in the ‘mynetgear’ part, but that is fine.

Voila! You can access your device from anywhere, using your cell phone, by entering in the URL Not bad for 20 minutes work.

–Dirk

CE mark = “China Export”

Take a look at the two logos  above. One is the familiar CE mark – meaning that the product has conformed with a bunch of EU health, safety and other standards. The one on the right means “China Export”. It makes no claims to any health or safety standards I am aware of, and “is placed arbitrarily“. One can’t help thinking that the China Export logo is intentionally similar to the CE mark, but that can’t be right, can it?

Wikipedia has more, or Google ‘China Export’.

An embeddable ARM board, the ARMiGo

This is a guest post by Ken Boak (@monsonite).

As integrated circuits get smaller, and more powerful, it becomes increasingly difficult for the hobbyist to utilise them easily. Soldering tiny SMT parts is a challenge for many – but an amazingly useful skill, once mastered.

32 bit ARM microcontrollers are now virtually the same cost as older 8 bit devices, yet offer a many fold increase in performance, as a result of their 32 bit architecture and faster clock speed. In addition to this, they come with a rich set of peripherals, making them ideal for more demanding applications.

For the hobbyist who may have first gained exposure to microcontrollers via 8 bit products such as the Arduino, the move to 32 bit may appear a little daunting.  However we all have to progress and keep up with the times, and so now the time has come to move up to the “big school”.

For a particular microcontroller to gain traction in the hobbyist community, it has to meet a few basic requirements:

1. Low cost development boards
2. Free to use, open source toolchain
3. Lots of online code examples, projects, forum support
4. Support from a vibrant user community
5. Easy to use and incorporate into projects
6. Easy to upgrade to different devices from within the same microcontroller family

1.  Low Cost Hardware

After some investigation, and triggered into action by exceptionally low cost development boards, I have settled on the ST Microelectronics STM32F range of microcontrollers as being the basis for future projects.

These micros are already being used extensively in a range of hobbyist boards including Maple, Netduino, Olimex, Expruino, mbed, MicroPython and STM’s own range of very low cost Discovery boards, which are priced around the  $11 – $18 range.

A recent offering from mbed in collaboration with ST is offering boards for as little as $10, and come complete with a detachable ST Link programmer, which can be used for programming other boards. These boards are now available from suppliers including Newark,  Mouser, Digikey.

Low cost hardware is the new trend, with dev kits often being sold at close to cost price, so gone are the days when you forked out $30 for your first Arduino, and then another $30 when you wanted to build it into a more permanent project.

2.  Open Source Toolchain

3. Lots of Online Support and Code Examples

Getting started with ARM chips is as easy as dowloading the free tools, installing some drivers and learning the basics from a wide range of code examples easily found online.  The STM32 range of microcontrollers have been available for about 4 years now, and so there is a rapidly growing resource of online code examples, reference designs and supporting documentation. ST Microelectronics produces a firmware pack for all of its evaluation and Discovery boards, and this is a good place to start for code examples. Other online examples,  which are easily Googled, are downloadable from repository sites such as Github amongst others. YouTube is also a good place to search for STM32 projects. As the processors are considerably more powerful than 8 bit devices, they are often used with LCD colour displays, and there are several examples of these on YouTube.

4. A Large User Community.

All popular devices build up a loyal user community and the STM32 is no exception.  The popularity is driven by low cost hardware and free tools, and is ever expanding as new products based on the STM32 are released.  Again a simple Google search will often turn up a blog from an enthusiast who has already covered a lot of ground and is happy to share it. 

5. Easy to Incorporate into Projects.

This is where things are not so clear-cut.  The problem with most dev boards is that they are either too big, or use header pin layouts that are incompatible with breadboard or stripboard.  This can be a major inconvenience, and often force the user to buy some form of shield for mounting other hardware expansion, or resort to using female/male jumper leads, so that the headers can be jumpered into a breadboard. Either way the result is not ideal, and a rat’s nest of jumper wires is neither permanent nor easy to work with.

6. Easy to move between devices in the STM32 family range.

There are now a considerable number of devices in the STM32Fxxx family, based broadly around the Cortex M0, M3 and M4 ARM architectures. Whilst to the newcomer the range of different parts may seem confusing, STM have designed the family in such a way which makes it relatively easy to move between parts.

The first thing to realise is that they are all microcontrollers, with on chip SRAM, and only the larger packaged parts will support external memory.

Secondly, all parts share identical, or very similar I/O and peripheral architectures, so if you are using USART 1, or Timer 2 on a 48 pin pack, you will find the same peripherals, and more, in the 64, 100 and 144 pin packages.

Thirdly, you will find that you can switch between family members – because specific packages share common pin-outs. This means if you have designed a pcb for a 48 pin STM32F103, and you want to move up to the STM32F303, then you will find all the ports, clock lines and power pins are exactly the same – so no pcb changes are needed.

Here are some guidelines to selecting a part:

1. How much I/O will my application require?  The GPIO ports are 16 bits wide, and devices are made with between 2 and 8 ports.  The 48 pin package provides 2 ports PortA and PortB,  the 100 pin package provides 5 ports PortA – PortE.
2. Choose the appropriate amount of flash memory and SRAM.  The smaller parts have 128kB of flash and 32kB of SRAM. The largest parts have 2MB of flash and 256k of SRAM.
3. Choose the Cortex family member. M0 is the cheapest with the slowest clock, and generally without USB. M3 is a good starting point with a 72MHz clock and on chip, full speed USB.  M4 is similar to M3, but supports clock speeds up to 180MHz and has a floating point unit (FPU) which may be useful for intensive maths code such as used in robotics and flight controllers.

 Getting Started.

 Initially I bought a Discovery F3 development board, which uses a 100 pin STM32F303 processor and has  compass, accelerometer and gyro devices on the board. It was exceptionally good value at under $11 from Newark.  However, whilst it provided a platform to get me started writing code and getting the framework to support my application built, it was just too big and the double row headers are not the friendliest of connectors to use. I didn’t need all of the  80 lines of I/O provided by the 100 pin device,  so I settled on the 48 pin part, which somewhat smaller, cheaper and more manageable in terms of pcb layout.

 My solution was to create a 2″ x 0.75″ (51mm x 19mm)  double sided pcb, which mounts the STM32F303 microcontroller,  its clock and reset circuits and USB/programming connectors. This small breakout pcb, converts the pins from the 48 pin LQFP to an easier to use 40 pin dual in line module, and provide the minimum of features to get the STM32 to load and run code.

This approach is not new and has been used in minimalist products such as the Maple Mini and the Arduino Pro Mini. Micro and Nano, all of which have been around for some time.

I decided to name the board “ARMiGo” in respect to its user friendliness and I designed the ARMiGo to be as open and flexible as possible, so that it can be used as a core for incorporation into other designs.  The essential parts of that core are the microcontroller, the 8MHz crystal, the reset circuit, USB connection and programming header. 

• Full speed USB interface
• 4  Fast (5 Msps)  12bit ADCs, each with up to 4 input channels
• 4 Programmable gain op-amps and 7 comparators
• 2  12 bit DACs
• 3   USARTS
• 3   SPI
• 2   I2C
• RTC with 32768 Hz oscillator and dedicated output pin for “alarm”
• 10 timer channels,  2 basic,  6 general purpose and 2 advanced:
  5  General purpose  16 bit timer channels with up to 4 outputs for PWM generation, timing, counting etc.
• 1 general purpose 32 bit counter/timer – for optical encoder reading etc
• 2 advanced 16 bit timers for complimentary PWM generation etc.

Windows 7, Python, virtualenv and the “Unable to find vcvarsall.bat” error

If you are using Python on Windows 7, you have probably run into the annoying error “Unable to find vcvarsall.bat” when trying to install some software. (For the record, I’m using Python 2.7.3)

Here’s how to stop that error from happening:

1. Download the Microsoft Visual C++ 2008 from this page. That is a generally useful page anyway, so you should probably bookmark it. For Python 3.3+ use MS Visual C++ 2010, as described in that page.
2. Install it.
3. Open Windows explorer (the file browser) and search for the location of ‘vcvarsall.bat’ and cut it to your clipboard.
4. run regedit from the Windows start key. You will need admin privilges.
5. Add a registry entry to
   HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC\ProductDir (64 bit Windows) or
   HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\9.0\Setup\VC\ProductDir (32 bit)
   as described in this Stack Overflow post.
6. At the Windows start key, type cmd to get a command shell. If you need to, go to your virtual environment and run activate.bat.
7. pip install <your software> or whatever you use to install it.

This should banish that error.

IIDRE wins Opendata in France

Our French Air Quality Egg reseller, IIDRE, has won the Enterprise category of the French Opendata competition using the Air Quality Egg in an indoor configuration.

A big congratulations to Michel Seyrac and the IIDRE team. Well done!

Take a look at air quality in Aquitane here: http://aquitaine.air-qualite.com/

Air Quality Egg: Shield Firmware Update

Based on my research findings (described in my last post), I spent some time digging into the Egg Shield hardware and firmware and I made some significant updates in hopes of improving results. I’m currently running an overnight experiment of the latest firmware, which I pushed out on GitHub (also for the Ozone and VOC add-ons). I also put load scripts out there to help ease the update process. I wanted to give an update on what I found and what I did.

Constant Heater Voltage

There was an observable random “spiking” phenomenon associated with the dynamic heater voltage control algorithm. I still don’t know the root cause of that, but I know that if I take that algorithm out, the associated phenomenon goes away, so the current version of the firmware sets the voltage at start-up and leaves it alone. I determined the settings for each heater experimentally by trying a setting, measuring H+ and H- and calculating the heater power, until I hit the datasheet targets.

Range Selection Algorithm / Fixed Point Math Rewrite

I was concerned about the frequent reports of apparent overflow conditions occurring. I looked into how to make better use of our range selection capability and rewrote it to select the range that yields results that are closest to the mid-range voltage. I believe this algorithm should provide more stable / continuous results than the original algorithm. In particular, I expect that it will be more immune to overflow conditions.

NO2 Hardware Bug – Workaround

In re-writing the Range Selection Algorithm, I was astonished to find an undiscovered hardware bug in the Egg Shield. I kept trying different settings on the range selection divider for NO2, but no matter what I did, two of the range settings always yielded the same analog-to-digital conversion result. I dug in and traced it back to the schematic (after hours of assuming I must be doing something wrong in software).

It turns out there is a node named “/NO2_R2_SEL” and a separate node named “/R2_SEL.” Those were meant to be the same node, but the tools don’t know that, so they never got connected in the layout. The effect is that it’s impossible to select a low-side resistance of R1 + R2 = 24.2 kΩ for NO2. <face-palm!> The firmware didn’t know about that bug either, so its model of the world didn’t agree with reality when it chose that range. This inconsistency was almost certainly also contributing to the instability in the NO2 readings we’ve been seeing. Anyway, the firmware agrees with the hardware now. I think it will be less accurate than it could have been were it not for the hardware bug, but I think this will be much better than what we had going on.

What To Do Next

I’ll follow up with a post tomorrow night with my overnight results. If you’re ambitious and know what you’re doing, the software and binaries for the firmware updates above is already out on GitHub and you can go ahead and re-flash your Egg Shield to hopefully start getting better results right away. As a reminder, Joe Saavedra also made a nice tutorial on how you can use an Arduino (or a Nanode) to reprogram a Sensor Shield. I plan to do a video to demonstrate that process as well in the next couple weeks. As always, if you’re uncomfortable reprogramming the hardware for yourself and  you are willing to pay for the round-trip shipping, I am willing to personally reprogram your hardware at no additional cost.

Air Quality Egg: Research Findings

I’ve been looking at a lot of the data being published and trends in questions on the forum, and there is a theme developing. The results are not consistent with expectations. We’re also now getting some reports from laboratory studies that are confirming there’s a problem. The collective information strongly suggests that the data the Air Quality Eggs are reporting is incongruent with the natural response of the sensors.

In light of this growing body of evidence, I built a much simplified reference circuit based on the sensor datasheets and recorded sensor readings along side the Egg for several hours. Sure enough, the reference circuit exhibited a fairly smooth / continuous response over time. The Egg did not. 

I decided the rational thing to do was to conduct a series of controlled experiments in an effort to establish the root cause of the variation between the Sensor Shield and the Reference Circuit behavior. This was a daunting proposition with so many potential variables in play, but I did my best to come up with some viable hypotheses. The fundamental differences between the reference circuit and the Sensor Shield / Air Quality Egg are:

• The Air Quality Egg had a fan (which affects airflow and electrical load), the reference circuit did not
• The Air Quality Egg was in an enclosure, the reference circuit was not
• The Sensor Shield dynamically controlled the heater voltage, the reference circuit did not
• The Sensor Shield dynamically selected the voltage divider, the reference circuit did not

For the first two bullets I did a series of tests that ultimately revealed the enclosure didn’t have much of an impact, but that disconnecting the fan from the Air quality Egg circuit has a very noticeable impact. As a quick aside, all of the following graphs have elapsed time in milliseconds on the x-axis and ADC counts on the y-axis. The following graph compares the response of the reference circuit, to an Air Quality Egg with a fan and enclosure, and to an Air Quality Egg with neither a fan nor an enclosure.

The difference is readily apparent. The data with the fan (red) has a bout 50 ADC counts of noise on it. The data with no fan (blue) in the circuit, however, still had a peculiarity of these randomly appearing spike discontinuities in the data. I made modified builds of the Sensor Shield firmware that took out the Heater Control algorithm, took out the Range Selection algorithm, and took out both.  The result of taking out both looked like this (with and without an enclosure) in comparison to the reference circuit.

Lo and behold, with the fan removed and the software sophistication removed, the Air Quality Egg response has neither noise nor spikes, and it seems to track the reference circuit quite well. I then added just the Heater Control algorithm back in and I got this result:

This confirms, in my view, that the Heater Control algorithm is the source of spiky-ness in the Air Quality Egg data. I’m currently studying the software intensely to come up with an improved version of the Sensor Shield firmware, and will post another update when I know more.

“Air Quality Egg” is now a trademark

We have followed in the footsteps of Arduinoâ„¢ and received a trademark on the “Air Quality Egg”. This post explains why we did this, and it’s effects.

A quick note in case you are unfamiliar with Trademarks: This has no effect on the open source-ness of anything of the hardware and software. It is still 100% open source.

This blog post has a pretty good explanation why open source projects should trademark. A trademark prevents other people from calling something an “Air Quality Egg”. We did this for two reasons:
– It would be confusing to us if other people created a product with the same name.
– If might also confuse customers, and they might expect us to support all products called “Air Quality Egg”

Here is another good discussion on trademarks and open source.

Air Quality Egg status update

All,

It has been awhile. Here is an update on the Egg.

If you ordered:

• an egg with no add-ons (Just the basic egg),
• a shield only or
• a Kit,

Then we have shipped your order. If you don’t think we have, then please contact support AT wickeddevice.com

If you ordered an Egg with any add-ons (Ozone, VoC, etc), we have not shipped your egg yet, but will be doing so soon (starting next week).

If you ordered a radiation module, as noted in January, Joe Saveedra has been kind enough to design and help with delivering it.

Wicked Device announces strategic partnership with ITT Exelis

ITT Exelis (NYSE: XLS) and Wicked Device LLC have entered into a strategic partnership to explore innovative technology to provide real-time weather information at a hyper-local scale.

Wicked Device is developing an embedded system to integrate with Exelis’s Helios™ platform. The Helios platform enables traffic and other cameras to function as weather sensors, providing more accurate, real-time environmental intelligence for better decision-making and response.

The Helios platform integrates networks of surveillance cameras already in use to watch traffic, facility security and railroad assets for weather monitoring. It aggregates disparate images into a single source and uses algorithms and image processing to reveal actionable real-time environmental intelligence. Providing hyper-local weather data, versus regional data, to national and local agencies, utility companies, transportation services and first responders can help in their decision-making process, saving lives and resources.