A few years ago I did a couple of piezo contact mic amplifier designs, because people often moan that these things sound tinny and crap. There’s a wrong way and a right way to use these – they want to work into a high impedance. Using Piezo Contact Mics Right sets you right. Trouble is these use a 9V battery, and it seems world + dog want to use 5V, because that’s what they had. Time was when power supplies were +/- 15V for analogue and 5V for digital, but that’s a different story for later.
So what can you do with your piezo contact mic at 5V then?
Not much. If you are looking for low signal level performance an emitter follower biased at an output of 2V would work well, but if you only have 5V available it’s likely you are trying to digitise this signal and bung it in an Arduino or something. In that case, think laterally. Toss the power supply. I developed those amps because as a field recordist I wanted to hear faint signals from the contact mic. You know, like the whispering in the rails as a distant train approaches, though you need to avoid the Fredzania Thompson ending.
These days people would look at you funny if you attach a box with wires to the underneath of the rails. Don’t try this at home and all that.
Turns out many people want to use their contact mics on an instrument, or drum pad, or generally something they bash seven bells out of. Life is a lot easier for you. As established in Using Contact mics right, you want an input resistance of about 330kΩ so the bass doesn’t roll off with the typical series tens of nF capacitance of the sensor. 330kΩ is a damn sight more than your typical plug-in-power audio recording doohickey, which usually feeds the electret mic power from 3V via about 6.8kΩ. I measured my Olympus LS-14 and even the line input is 10k.
So stick the 330kΩ resistor in series with the input. Even writing that makes me cringe, because it will lose a hell of a lot of signal level, making a potential divider with the input resistance – for a 6k8 input you’ll take a loss of 33dB. That translates into a direct worsening of your noise figure by that much, that’s a lot of performance to throw away1. OTOH it works perfectly well down to 1.8V, it’ll be OK down to 0V as it doesn’t use power 😉
how much signal do you get from a piezo contact mic?
Back-from-the-dead supplier of marked-up Chinese tat Maplin started life out as a supplier run by geeks for geeks, with a wide range of electronic music modules and later on projects which didn’t have any real use, but were technical curiosities.
Maplin sold a lot of Geiger counter kits in the years after Chernobyl. Mine is still in service, I vaguely seem to recall the tube was a ZP1401 with the thin mica window. It saved me a radon survey –radiation is a problem in the south-west with radon leaching out of granite underground. The Geiger counter reads lower in the basement than on the first floor my old house (Maplin’s tube was a mica-window type). Interestingly in 1996 Maplin magazine claimed that the prototype of this detected the Chernobyl cloud passing over Britain.
Another story behind the scenes was that during the testing phase of the Geiger Counter project, the normal background radiation readings rose significantly, these were recorded for prosperity on a printout.We later learned of Chernobyl, the world’s first major nuclear accident. It was detected here first at Maplin [^1]. The implication of this is that the radiation cloud passed over Britain, and not just contaminating the hillsides in Wales.
Sad day, I used their RF modules for farm telemetry and they were great products at a good price. I have a fair stock of their XRF and RFu micros and bought a few of the latter and a bunch of boards in their closing down sale. But I’m sorry to see them go, and support and data are going to be nonexistent now. London Stock Exchange RNS announcement
They’re still on GitHub as Ciseco, the original company, though I guess how long that will last is questionable
Paramagnetism is a reasonably straightforward characteristic of materials – if there are unpaired electrons in the atoms then the element will be paramagnetic and weakly drawn to a magnet. This demo of oxygen being paramagnetic is great – so far so scientific. Compounds can change this – water is diamagnetic although H2O is clearly contains oxygen.
A lump of paramagnetic rock (the coin is ~2cm dia)
The issues with the Raspberry Pi farm camera were of waterproofing and of iffy Wi-Fi range. Both of these are addressed in the new version. The PICE waterproof case from the guys at EdVenture marshals this motley collection of bits
Pre-PICE prototype
into something a bit more organised. There’s no getting away from it, the PICE is quite expensive at about the same as the Pi itself, but it does solve a lot of the mechanical problems of trying to run a Pi outside with a camera. The landscape version is the one i needed, since the case is only water-resistant with the top horizontal – the Pi is mounted on that and even if water does get in it falls to the bottom away from the Pi. The previous version of the PICE took the picture in portrait mode with the case oriented for best water resistance, which isn’t so useful for our aims.
This is a good interim solution – it gets the cameras into a tighter configuration, and should let me pull back the main MiFi box back to a more central location to serve the rest of the cameras. As a result each camera will draw less power which is good. The Edimax EW7711 USB WiFi unit has a better performance than the USB nano-dongle – the reason is obvious when you look at the size of the aerial of the nano
size really does matter in some applications, and and aerial much less than 1/4 wavelength is going to struggle to get the signal out
Clive from the Raspberry Pi Foundation very kindly let us have a Pi Model A and camera, so it’s time to take this project forward a stage. At the moment the alpha test version is in service keeping an eye on our new piglets. Although the original purpose was to keep an eye on our newly arrived cattle pigs are more enterprising, so it’s good to know where they are
Our camera on the pigs
Development was stalled however since it’s not easy to work on a piece of kit in service. Ideally one MiFi box could serve a number of cameras. This would reduce the camera power drain and consolidate.
The trouble is that the site is on the edge of town, a couple of hundred metres from the nearest houses, and I want to use BT Wi-Fi
Yagi wifi antenna
I acquired one of these from ebay I didn’t have much hope for the integrity of the device, and to gain height I needed to go 250m further way from any likely source of WiFi. But it worked a treat, as a WISP client, I’m amazed. I was able to see 18 access points, five of which were BT WiFi , 3 of which were 5dB or above. The TP-Link gives a decent link at more than 5 and nothing at 2. I streamed a video to confirm the stability of the link.
TP Link signal strength with yagi
I use it with a TP-Link TL-WA5110G which has the advantage of having a sma antenna socket and a native power supply of 12V. Although the adaptor is specced at 1A I measured the power drain at about 210 mA (~2.5W @12V). Which isn’t great but not terrible
A WISP client is not a repeater
The trouble with using the tP link as a WISP client is the signal is presented as Ethernet, and I’d then want to re-radiate the signal on a different Wi-Fi network. I could set it as a repeater, but then every Raspberry Pi would have the hurt of logging into BT WiFi. Whereas if I use a Raspberry Pi connected via ethernet to the TP-link and a WiPi dongle to connect to the farm I can collect pictures from the cameras on the farm network and perhaps power-manage the TP Link to only update every so often.
So an unexpected win, and I can look at using a Model B as a concentrator
The SMS gateway worked between the sensor RF network and the mobile phone network. However, it lacked sensitivity, occasionally struggling to get a signal 20 yards away.
Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implemented
I mounted the OKG board on the lid of the box and the SMS board in the base, unwittingly placing the sensor RF receiver between two ground planes. And a mobile phone signal source in a similar part of the radio spectrum. Which was probably not the best way to get good performance out of the LLAP sensor radio – screen it and then desensitise it with a strong nearby signal. Oops. Continue reading “Improving the coverage of the sensor radio network”
Our smallholding is an island site with no power and no broadband. No power means things like a Raspberry Pi are marginal – we’re looking at a current drain of about 500mA for a Model A. For a 85AH leisure battery of which you only want to use half the capacity for good service life that’s about 80 hours. So it’s time to look at the system architecture of a remote sensing network to try and reduce the power used at the remote site. The aim is to offload the processing for graphing to a site with mains power (home), so the system has sensors, a gateway that collates all the sensor data and sends it via SMS in my case, and a data processor.
Remote sensing network system architecture
At a site with mains power the gateway and data processor can be the same thing. The architecture of such a system is therefore two-level –
many sensors out in the field
a gateway/data processor
At home I have a Raspberry Pi that collects data from my sensors using a RF board, Ciseco’s Slice of Radio. The same Raspberry Pi runs RRDtool to do the graphing and SFTP to put the graphs onto the web.
Sensor network on a mains-powered site – the Raspberry Pi does most of the work
At the farm, however, because of the power constraint I need to use a gateway to transfer the data onto the mobile network using SMS.
That sort of site typically consists of three levels –
many sensors, out in the field doing the data collection,
a gateway, that collects all the sensor data
a data processor – that consolidates the data from the sensors, graphs it and saves it, perhaps uploading to the web
So the next stage down from a Pi is something like an Arduino
The Arduino OKG and Sainsmart SMS to serial device reduce power usage by 80%
The Raspberry Pi can be at home so its power consumption isn’t an issue any more. It takes an SMS message of various sensor readings and munges this via Python and some scripts into a RRD database which then goes with RRDgraph. Which gives the single-sensor plot as shown below. The battery voltage chart shows that something rather nasty is happening to the main battery – it looks like the charge controller is not disconnecting the solar panels from the battery when the battery voltage is high enough – if so this is the second Kemo charge controller I’ve had from Maplin that has failed in service.
Simplified sensor chart
What, no IoT platform?
I’ve gone off third-party IOT services, because the RPi lets me run RRDtool, and shifts the conversion from simple CSV text files to home. I get to control what goes on, I am not subject to the whim of third-party changes, cessations of service, charging for what was free and all the other hurt that goes with relying on people you don’t pay. I found the Xively Arduino stack memory leaky and buggy despite my initial enthusiasm, and now I can run a Raspberry Pi at home I can insource the job, and get the Ethernet stack off the Arduino.
In that way the data gets processed more as it is staged along the signal path as the processing power of my devices and electrical power available to them increases. Electrical power is shortest at the sensor, which draws an average of about 1mA. It gets consolidated at the OKG gateway, which is powered by a 12V leisure battery and draws about 60mA, handling all the sensors. Once it gets to the Raspberry Pi at home that is mains powered I can live with the 500mA-700mA@5V and that does the collating, data transforming into a RRD database, graphing and uploading to the Web.
Sensor design
For my system architecture I have pinched ideas from the design of industrial process control system – historically these used wired sensors, firstly using 4-20mA analogue signalling using current (this independent of wire resistance). With zero response the sensor would draw 4mA and at full scale it would draw 20mA. These fed into a console for display.
However, I don’t want to run wires all over the farm, so I will use Ciseco’s LLAP serial data format over radio. This replaces the naalogue current loops and wiring and lets me reduce cost and power at the sensor, which can sleep for most of the time, only waking every 10 minutes to send a 12-byte packet on the radio network to be received at the gateway. That’s just as well, since losing the wiring means the sensors each have to be autonomously powered.
Ciseco’s thermistor board with XRF
Ciseco already make some sensors using the processor on the XRF radio – you simply upload a different firmware to the XRF – there’s an example in the picture, and this is powered from a CR2032 coin cell on the board just under the XRF.
thermistor board in box
These make a neat small sensor, and great for measuring the temperature in a shed where sunlight doesn’t fall directly on the black box (generating large readings unrepresentative of the air temperature) but they aren’t great for soil temperature measurements.
soil temperature measurements from a buried probe and a LLAP thermistor sensor in black box on the soil surface
The blue line is the LLAP sensor in a box – placed next to the soil sensor – they are physically very close, but the box on the soil experiences a much wider temperature range!
Sensors deployed in a polytunnel
Not only is there the sunlight problem, but being on the soil keeps the radio low which minimises range, hence the choppy blue line. However, it wouldn’t be hard to mod one of these with a jack switched socket to use an internal thermistor unless an external one was plugged in, and they’re quick and easy to deploy, which is great. They can also be run off two NiMH AA cells instead of the Li battery, which opens up the possibility of using solar power for unattended operation (the CR2032 battery is good for 6 months at least at a 10min update rate).
To get more out of the limited data rate on the SMS gateway, I’ve also got a LLAP sensor design with two sensors and a PIC microcontroller than encodes two temperatures onto one LLAP packet. I use two of the the Dallas18B20 digital temperature sensors for that.
PIC microcontroller/XRF dual dallas 18B20 control box. Powered off 4xAA NiMH maintained by a solar cell
The Gateway
Ciseco do a Arduino Uno based gateway PCB that has an UNO and sockets for their XRF modules, called the OpenKontrol Gateway. This also has space for a Real Time clock which is nice. I only needed the Arduino, the RTC and the XRF hence the gobs of unused space on the LHS. I wired this via the serial port to a Sainsmart TC35 used as a SMS gateway, mounted on the bottom of the box. Unfortunately the XRF ends up between two ground planes, which doesn’t do wonders for the RF sensitivity. However, I was ready for that, bringing out the serial connections to a DIN socket, so I can mount the XRF remotely and up high if necessary, taking just power and 9600-baud RS232 back to the box.
Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implemented
the finished LLAP to SMS gateway
So far I have learned a lot from this deployment – it’s proved the principle, but I need to improve the RF performance of the OKG/SMS gateway with a remote XRF receiver to be in with a good chance of covering a significant part of the smallholding.
Ciseco’s LLAP format is a nice lightweight and PIC microcontroller and Arduino friendly serial protocol. I use their XRF modules for RF communication, these support power-down so they are well-suited to intermittent operation off a battery. Standing current on receive is 23mA so continuous operation is more of a challenge, for instance at the RF to SMS gateway. It has 12 bytes like so:
LLAP Message format
Each message is exactly 12 characters long and in three distinct sections:
See Appendix 3 for details of the permissible characters in each field.
Their examples, however, send only one data value per LLAP message, with a descriptive section. Hence
aAATMPA12345
Which is wasteful IMO. A lot of sensors have two data points,for instance temperature difference measurements, or temperature and relative humidity.
Few real world sensors can justify the precision of using all the digits; I don’t have any with an accuracy of more than three digits. Sensing temperature to an accuracy of 0.1C is unusual – the popular dalas 18B20 is accurate to 0.5C but to do much more implies a piece of laboratory equipment. Useful values of temperature in the UK would be -20 to 120 °C, Relative humidity is 0 to 100 – cheap sensors don’t really justify a .x so allocating four digits covers most bases. Negative values give the ugly -21. as the – takes up a digit but it’s only a machine that sees it. So I can make a double density device as
aAA12.34X5.67
and keep within the spec. I use **** for failed or missing sensors, and the X is replaced by L,M or H for battery status. M and H are operational, L means may be about to switch off in a few cycles. In sensors that support H then M means would still accept charge, H is enough. However I use a simple comparator at about 4.4 V on a PIC 16F628 so I can only show L and M.
This saves me precious power, and allows me to consolidate two temperature sensors to one radio saving cost of the radio and aggravation of maintaining batteries.
two-sensor PIC and XRF device
I couldn’t use JAL for this because I laid out the board to use the 16F628’s internal oscillator that runs at 4MHz and the JAL one-wire lib wants to run at 20MHz. So I had to code it in assembler 🙁 Next time I’ll leave space for a 20MHz resonator on the board that will save me all that grief.
I now get to read two temp sensor and the battery status, all in one LLAP message 🙂
Note: I don’t do this any more. Third party APIs are a world of hurt – you save some time up front and end up chasing someone else’s upgrade path on their agenda, supporting their ads. There’s nothing fundamentally wrong with building cloud services and dependencies into your work, as long as you don’t want it to be up there for more than six weeks in my experience.
In their increasing commercialisation as Pachube went away from the original hacker ethos to Cosm, and now Xively, Xively have totally borked the documentation, at least for freebie cheapskates.
The most obvious thing you want to do with an IoT device is to chart the time series. With Pachube and Cosm that was easy. It’s also pretty easy using Xively, but what isn’t easy is finding out how to do it!
I don’t use Xively any more so this is a static capture from some time ago
This is what I’m after. I have a Geiger counter, and a PIC ticks up a counter each time it detects an event. After a minute is up, it reads the counter, sends it via LLAP over a serial RF network to a Raspberry Pi that uploads the count to Cosm Xively and resets the counter, and it all starts over again.
Note: I’ve now moved to running RRDtool on the Pi because I found Xively just a little bit too intermittent, plus there’s the whole getting control of my own data thing. I found it more reliable to store the data locally, generate the graph and then upload the graph. It isn’t necessarily Xively’s fault – I get the feeling my ADSL connection just isn’t reliable enough for something that needs to update every minute,
RRDtool looks a bit more grungy, though I kinda like that here –
A little bit more grungy from RRDtool, but more reliable in my application
Anyway, back to Xively, and how easy graphing from Xively worked for me –
It was easy to find out how to do it on Pachube and Cosm but because Xively is all about provisioning IoT bits rather than hackers’ web charting now it’s the devil’s own job to find out how to do it. Xively favour stackexchange for support nowadays, but they can be less than helpful to n00bs or those who do not show that they feel The Force to the required extent 😉
Here is what I did to embed a Xively chart:
Read this from Xively on how to embed a chart – it’s not linked from any obvious place.
It so happens that the png chart option is a specific instance of reading a single datastream. You, me, and everybody else asks Google ‘how do I embed a Xively chart image’. Xively think of this in terms of ‘how do I display as single datastream’ and they’d rather you not do that, but parse the data returned from the feed, so they hide the relevant page in a backwater of their documentation because they don’t see it as important. Which is entirely their right – after all, you get the support you pay for!
obviously fiddle with width height, colour to taste. Note that it doesn’t need you API KEY, because presumably a PNG isn’t about to start posting data back to your feed any time soon. One of the more useful extra items is the duration=3hours
which doesn’t happen to be one of the official parameters in the Xively historical parameters documentation, but it is in the example they give and is a useful undocumented feature. A shorter duration works better with the Geiger count.
Your device needs to be public access if you want other people to see it, natch 😉 Make it private and they will be invited to log in on Xively, which sort of defeats the point.
Now why did that have to be so hard?
Alternatives ways of showing Xively data
The embedded Xively chart is loaded when you load your page, it doesn’t auto-refresh like the display on your Xively Workbench. That’s fine for many things, but it is very Web 1.0 so if you want more then take a look at Dave’s method of using Google charts by getting the raw data back from Xively. That way you get a more responsive chart and can plot more than one thing at a time, but you are looking at a lot more work compared to the quick-and-dirty method of an embedded image.
