Posted: March 10th, 2014 | Author: admin | Filed under: Uncategorized | Comments Off
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:
- Low cost development boards
- Free to use, open source toolchain
- Lots of online code examples, projects, forum support
- Support from a vibrant user community
- Easy to use and incorporate into projects
- 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
Free to use toolchains are nothing new. Microchip realised in the 1990′s that they would sell more chips if they made the coding tools free. Fortunately the ARM microcontroller is supported by GCC, and there is a free to use IDE, called CooCox CoIDE, which supports a wide range of ARM chips from several main manufacturers.
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:
- 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.
- 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.
- 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.
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.
The first of the prototypes arrived this week, and now working running some simple test code.
ARMiGo uses the STM32F303 Cortex M4 ARM device which runs at a maximum of 72MHz. The pcb also supports the STM32F103 which is based on the M3 core.
The board is the same size as a standard 40 pin DIL format IC – making it ideal for breadboarding, and small enough to be used as a plug in module in a 40 pin socket, on a larger board.
All 35 I/O lines of the ARM chip are brought out to standard 0.1″ (2.54mm) spaced headers.
The 5 pin right angle header on the left accepts the clock and data signals from the “ST-Link” programmer/debugger device. These are available very cheaply but it is relatively simple to use the embedded STM bootloader and program it via either the mini-B USB connector on the right or via one of the USART channels.
There is a really rich mix of on-chip peripherals, which gives these small ARM parts tremendous flexibility – including the following:
- 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.
In addition, the analogue section of the IC contains programmable gain op-amps and comparators which feed the ADC channels, and can be used to replace external analogue circuitry.
This small 48 pin packaged part contains 128KB of Flash and 40KB of SRAM – of which 8K can be battery backed up when the rest of the IC is powered down.
Posted: April 22nd, 2013 | Author: admin | Filed under: AQE | Tags: Air Quality Egg, AQE, aqe sensor | Comments Off
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.
Posted: April 16th, 2013 | Author: admin | Filed under: Uncategorized | 1 Comment »
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.
Posted: February 14th, 2013 | Author: admin | Filed under: Uncategorized | Comments Off
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.
Posted: February 7th, 2013 | Author: admin | Filed under: Uncategorized | Comments Off
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.
Posted: February 4th, 2013 | Author: admin | Filed under: AQE, Software | Tags: Air Quality Egg, AQE, software | Comments Off
Over the weekend I worked on making the color expressions of the Air Quality Egg more… well, expressive. The update is on Git-Hub so feel free to update your software (howto videos) for the Remote and Base units. This is the 1.03 version of both baselines (version number gets printed to the serial console).
As the Eggs have been reaching their destinations, feedback from users indicated that the setup process had some significant holes in diagnostic feedback. The most important of these was that the outcome of the pairing interval was invisible to the end user; the only way you knew that pairing succeeded was that the system started working a couple minutes later. If the system didn’t start working, you were left scratching your head and trying again. So I added an acknowledgement to the pairing behavior, and now there’s clear feedback about the outcome of the pairing interval: after the yellow pulses that signify pairing in progress, three magenta blinks indicate “pairing was not acknowledged” and three cyan (light blue) blinks indicate “pairing was acknowledged.”
The second feedback notable feedback confusion was related to Cosm provisioning. The previous behavior was to indicate solid green when provisioning succeeded, but *only the first time* after that you would never see green again. So now, if provisioning has previously succeeded, you get three green blinks.
In summary, the colors the Egg expresses now come in three “flavors”:
- Pulsing colors are used to indicate normal activity and progress (I know some people find this annoying, but I’m erring on the side of more feedback)
- Blinking colors are used to signify status
- Solid colors are used to indicate conditions that result in a restart
- Blinking/Solid green, blue, and cyan are used as “positive” indicators
- Blinking/Solid red and magenta are used as “negative” indicators
The following flowchart describes the feedback behavior of the 1.03 baseline.