Following up on the previous post about pulling sensor data from sensors in a Verisure alarm system, here is a slightly more hardware focused post.
One use case that the new Verisure alarm system does not handle nicely is machine-to-machine notification when the alarm is disarmed (turned off). Such notifications are sent to the mobile app – so the data exists somewhere. The problem is that it’s all undocumented and thus hard to build something on top of.
Let’s hack a solution instead – be aware, some soldering required….
Last weekend I finally got around to doing something I have postponed for several years now.
Being somewhat of a gadget hoarder, I have ended up with quite a large stack of rechargeable batteries. Everything from 12 Volt lead-acid ones from old UPS:s to Lithium-ion variants from mobile phones.
The last kind are actually pretty interesting. They pack a significant punch when it comes to energy storage, the problem is that they are designed to go into cell phones (at least pre iPhone ones where you could remove the battery!), and there are thus no separate charging docks or battery holders.
Still, it would be sweet if they could be used to power electronics gadgets that I build myself… It is of course possible, and even quite easy to do – here is the very first prototype in action:
I was recently in Helsinki, giving a talk at a QlikDevGroup event. Great event, great crowd. The topic was SenseOps and Butler SOS, and I showcased the lamp above as an example of a funky, but still relevant way to monitor user activity in a Qlik Sense Enterprise environment.
A person in the audience asked how the map works. I claimed it was super simple, costing less than USD 10 to build (assuming you already have a suitable enclosure) and uses just four wires hooked up between some pre-made modules. Time to prove it.
The four wires part might have been a slight exaggeration… but it depends on which wires you count – right?
A real pain point when developing sensor nodes that are scattered around a building (or a country or the world!) is the updating part. How do you get new firmware onto the devices?
The cell phone manufacturers were early to investigate the options, but from my days in that industry I know first-hand how challenging it was to send new firmware to tens or hundreds of thousands of devices. Lot’s have happened since, today a system update for tens of millions of Android or IOS devices is no big deal, you just make sure your phone is plugged into power before starting the upgrade. Leave it overnight, and next morning you have the latest (and hopefully greatest) version installed.
Looking specifically at the ESP8266, it does have drawbacks in terms of power consumption (it’s hard to get the power consumption down for a device that needs 3-4 seconds to wake up from sleep, connecting to a wifi network and send its sensor readings – but improvements are possible). On the other hand, its wifi connectivity means Over The Air (OTA) updating is possible.
Having a bunch of ESP8266’s lying around, I looked into the options for doing OTA on ESP8266.
Got myself an Andonstar 2 megapixel USB microscope about a year ago, mainly just for testing it out, and having it readily available when some repair project demanded it. The microscope is actually pretty nice given its ca USD 60 price point, with decent picture quality, a sturdy stand (even though it’s somewhat of a pain adjusting it) and a built-in adjustable light source.
To be honest it hasn’t been used much (it did come in handy during the repair of the BK Precision LCR meter though).. but this is in part due to the lack of good OS X software for use with generic USB microscopes. Over the past year I have tried some video software, and still have a few on the try-these-out-list.
Got myself a new toy a while ago – A FLIR TG165 infrared camera.
These devices used to cost thousands of Euros/Dollars, but during the past year the have come down in price a lot. I got mine from SOS electronic, think had a campaign on it back when I got it. This a rather low-end unit that does only have an IR sensor – no regular camera as the more expensive models have. That combination is actually very nice – it becomes really easy to understand where on the object under inspection the hotspots are.
The TG165 isn’t too bad though – it has a couple of lasers that create a bounding rectangle, indicating what part of the object is shown on the meter’s display. In practise this works great, so no problem there.
Some time ago I got what I thought was a score on Ebay – a really nice LCR meter at a very good price. Ok, it was broken, but the error message indicated it was just the fuse that was gone. Looked like on the right.
According to BK’s help site, this error could be caused by a busted fuse. It’s an SMD fuse, but not too hard to replace. Unfortunately that didn’t solve the problem… the meter was still dead after fuse replacement.
So, enter a new toy I got recently: A FLIR TG165 IR camera. Did an unboxing of it recently, it’s a very nice piece of gear. Got it from SOS Electronic, it cost a fair bit of money, but still nothing compared to what FLIR cameras cost just a few years ago.
So what about Raspberry Pi’s?
Are they vulnerable?
Turns out they are, but there is already a fix available for them and patching a Raspi is very simple. Whether your actual Raspi is vulnerable depends on what distribution you are using, and how recently you upgraded the software in it.
The Raspi used below is running IPE-R1, which is a blackout-proof version of Raspian.
First let’s find out what bash version we have:
root@raspi-2:~# dpkg -s bash | grep Version
You can also run this little script to determine whether your Raspi is vulnerable to Shellshock
Let’s fix this. Just refresh the repos and upgrade bash (the patched version is available in the main repos).
root@raspi-2:~# apt-get update && apt-get install --only-upgrade bash
Get:1 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:3 http://archive.raspberrypi.org wheezy Release [10.2 kB]
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
1 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
Need to get 1,443 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main bash armhf 4.2+dfsg-0.1+deb7u3 [1,443 kB]
Fetched 1,443 kB in 1s (1,386 kB/s)
(Reading database ... 29754 files and directories currently installed.)
Preparing to replace bash 4.2+dfsg-0.1 (using .../bash_4.2+dfsg-0.1+deb7u3_armhf.deb) ...
Unpacking replacement bash ...
Processing triggers for man-db ...
Setting up bash (4.2+dfsg-0.1+deb7u3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
The installed version of bash is now +deb7u3
root@raspi-2:~# dpkg -s bash | grep Version
You could of course also just do an “apt-get upgrade” to upgrade all packages on your Raspi, would take a bit longer but will work just as well.
Also, if you are not logged in as root you need to do a “sudo apt-get update”, of course.
There is a new tool in the lab: An HP 6632A power supply.
It might be a a bit dated, but it has some pretty good and useful specs (0-20 V, 5 A). True, modern supplies are more compact and offer more features in a smaller box, but a major advantage of an older supply like this, is that all schematics are available, they use large, easy-to-change components, and you have a decent chance of actually understanding how they work. A great thing about this particular model is that it can not only source current, but also act as a current sink. Useful when you need to see how other power supplies behave under load.
The HP 6632A is programmable over GPIB (or HPIB – it’s more or less the same thing), but given the costs of GPIB adapters, I doubt I will get one.. Most functions of the supply can be controlled locally from the front panel anyway. A main exception is however the calibration, which requires a HPIB connection. Bummer… especially as this unit at first inspection seems to show slightly incorrect readings.
Turning the supply on it worked a treat, but it is LOUD! Checking the schematics (available in the service manual) reveals that there is no intelligent fan control – it starts at full speed, and there it remains. No matter if the supply is loaded or not. Given my previous work on fan speed control, this is a challenge too good to pass on.. More on that later. So let’s take it apart. Ooohhhh… it is INSANELY dirty inside.
That fan is just clogged with dust and I don’t know what.. That’s got to be bad for the bearings. Sure, Papst make great fans, but this one has taken a serious beating. And all the dirt inside the heat sink.. Nasty. Time to bring out the compressor and blow all the dirt away.
The result is pretty good – almost all dirt was removed from the fan and heat sink, at least it is way, way better than before.
The original Papst fan still sounds like a jet engine though, it is probably worth looking into a replacement. It is a 60x60x25 mm 12V fan, but the only 60×60 fans I had around here was a slimmer (ca 12 mm) variant. It is quieter, but does not provide as much airflow. Given that a) I will rarely load the supply heavily, and b) the supply has over-temperature protection built in, I am not too worried about replacing the fan. One small problem though: The screws for the old fan (they are screwed into threaded holes in the main heat sink) are too long. No suitable screws could be found, but wait – those springs that I scavenged from the first electronics kit I got when I was 10..? Hmmm… Worked a treat – almost better than the original!
Next up: front output terminals. This is a factory fitted option (option 020) to the HP 6632A supply, but it is an easy thing to do yourself. The front panel is made of aluminium on the outside, with a plastic sheet on the inside. That plastic already has a cut-out for mounting output jacks, and there are solder tabs on the main PCB just beneath where the jacks go. Just drill a couple of holes in the aluminium and we’re good to go. But wait… it doesn’t work. The over-current protection kicks in as soon as I turn the supply on. Is it toast? No… silly mistake. The banana jacks I used were not the kind with insulated mounting. In a plastic box they would have worked nicely, but here.. they just created a short through the supply’s aluminum front panel. Duh. New, insulated jacks and all works fine.
Make sure to use proper, heavy duty wires between the PCB and the jacks, in theory 5A at 20V could be flowing through there. I used the kind found in mains power centrals in residential housing, the copper is so thick it actually takes some effort to bend it. Should be plenty.
Finally, regarding calibration. Setting the supply to 5V, the display shows 4.996 V. The 0.004 V error shown by the supply itself is 0.08 %, which is actually within spec compared to the 0.05% + 10 mV accuracy (i.e. 0.0125 V at 5 V programmed level) of the supply. A connected multimeter (Fluke 89 IV, known to be spot on with respect to multiple different precision voltage sources) shows 4.9957 V, so it appears at least the supply’s output voltage is actually within spec and calibration, after all. However, setting the output to 15 V, the supply shows 14.995 V, and the multimeter shows the same. So about the same offset as before. It might be within spec, but there does seem to be a ca 4-5 mV negative offset in the output. Not a problem in any way, this is not a precision power supply, and things will anyway change when loads are connected. And with that, the supply is in a much improved shape. It is still really heavy (not much to be done about that, I am afraid), the fan is a bit loud for continuous use, and no calibration without a GPIB adapter. Still some room for improvement thus!
A while back I got an SSD drive with the question whether it could be repaired. At first glance it looked fine. But wait… the PCB is not level. In fact, it is seriously wobbly. What on earth happened to this SSD??
Looking closer at the flash ICs, it turns out several of them have pins that have disconnected from the PCB. Ok – that’s tough but nothing some careful soldering cannot fix.
But after inspecting the rest of the PCB it is clear that some inductors and capacitors have been torn off too. Wow – this drive took a real beating – nothing here to be salvaged except maybe a crystal or inductor. Could possibly be useful in other projects. Well – it goes into the to-be-used-in-future-projects box.
That’s only half the story… Quite a while back I came across another pair of PCBs. Another SSD, in fact – broken in two. Probably on purpose to prevent data extraction from the drive, but it gives a good opportunity to have a closer look at what is inside an Intel SSD drive.
All the passive components (capacitors, resistors) are so small they are impossible to hand solder – no point in salvaging them. Most of the other components are held in place with epoxy, making removal impossible (but I will for sure buy Intel SSDs from now on – these things are built to last!).
The PCB seems to have multiple layers. There is for sure at least a ground plane in there, probably 1-2 signal layers too (hard to count them without a microscope).
The one component that might be of interest in other projects (adding memory to OpenWRT based routers comes to mind) is the SDRAM, is a Samsung K4S281632I-UC60 8Mbyte x 16 IC. On the other hand – hand soldering that one will be… difficult (understatement) and require rebuilding the OpenWRT kernel. Hmm.. Will probably just recycle it.