Tuesday, December 27, 2016

Upgrading the sensor pods: Boxing the boards.

Now that I've confirmed that the CAI board works, it's time to put it in a box. For this project, I used one of the boxes I'd originally purchased for the energy monitor project.



This was a wired alarm housing when purchased, although I discarded the alarm board after removing some of the more interesting parts, like nice screw-terminal connectors. (They have the same footprint as the ones I used on the purple alarm relay board.) I didn't need the built-in board, and most alarm manufacturers won't talk to you unless you have a license. Into the recycle bin it goes.

I've made some minor modification to the box, which includes drilling some new holes inside (the original push-lock standoffs were kept and re-used) and putting a meter on the front. Since this box will be talking to the leak detector box, I decided to add the meter to this one. As this will sit on the wall as you open the closet door, you can immediately see the meter without peering around the corner. It's currently displaying 13.5, which is being provided by a power supply.


Inside is still pretty sparse. I've placed the terminal strip for the incoming power, mounted the CAI board, and wired it and the meter in place and tied everything down. There will be another board under the terminal strip, probably a rectifier and supply board as I'd like to add a current monitor to the unit, but I'm not sure. Since I'm keeping the same form factor for everything, I went ahead and punched the pilots for possible mounts.

The CAI board is connected to the local network via a wireless adapter, aka a repurposed WRT54GL, that will probably follow it into the closet. Both units are perfectly happy running at 13.6V, so no other regulator is needed save the battery. (From what I can tell, the WRT54GL is good up to about 18V or so, and is probably good to around 10V on the other end. I have not verified this, so YMMV.)

Something I've read in a few places is these boards like to lock up after a few days when running with multiple DS1820s. I've placed a solderless breadboard in the bottom for now with 4 sensors on it to see what happens. So far, nothing other than good solid temps. As the CAI board is capable of reading I2C units, I also have a BMP280 pressure sensor mounted, although this isn't hooked up as of yet. That, and possibly an I2C RTC board are projects for another day.

Thursday, December 22, 2016

Thinking more about the energy monitor...

I had kind of given up on the energy monitor project for the simple reason that getting data into some useful form would be beyond what I have available to me at the moment.

However, opportunities present themselves in odd places. My employer needed something similar to monitor the lines of an air compressor to determine when the compressors are on or off. They didn't want to break the lines, so a non-invasive method of collecting data was needed.

Well, I had these clip-on current sensors from Seeed Studios left from my attempt, so I brought them in and measured the output to see if it would work. Yes, but the output of the clip is AC, and every device we have only measures a DC input.

Easy enough to solve, I pulled out an old design I had from the audio days, a precision full-wave rectifier circuit located on Page 234 of a book called "Encyclopedia of Electronic Circuits, Vol. 1" by Rudolf Graf. While some of the circuits in the book are less than useful due to age, incompleteness, or simply by being reference block diagrams instead of circuits, there are a few gems.

(This image is presented as a reference only.)

While I've made some changes to the circuit, using TL08x Op-Amps and germanium point contact diodes, output buffers and some minor output filtering, the circuit presented is doing the dirty work.

Since I have access to circuit board tools, I've decided to lay it out on a new board, give it it's own filtered power supplies, and add some easy-to-use connectors to it. What's amazing is how much bigger the diodes are as compared to almost everything else on the board, save the input connectors.

Then again, what's cooler than a 1N34A point-contact germanium diode in a glass case?


(image from https://www.banzaimusic.com/image.php?id=5047&type=D)

The board layout is the same form factor as my power supply and alarm monitor board, a size I've adopted for a lot of different things. Right now, I've completed the schematic (save the power converter, which I have not chosen yet) and am getting ready to see how well everything fits. Here's hoping I can get everything on this board!



Once it's all done, I'm going to work the design a little and begin the energy monitor project again.


Tuesday, December 20, 2016

Upgrading the sensor pods...

The power supply, leak detector, and alarm box has been working well for the past few months, but I'm kind of unhappy with the sensor arrays. While they work well enough, they consume a lot of space for the amount of inputs they have (two one-wire channels of one input each, plus single contact input.) As I needed three, they take up a good portion of the wall where they are mounted. Add that to the relatively weak output (1mW) in an area with a lot of metal and water, and you get Good, but not Great performance.

How to replace these? Well, there are several options. I considered a number of single-board computers, but settled on a device designed more for industrial environments as a PLC. The CAI WebControl unit offers a lot of functionality in a small package - 10baseT Ethernet, 8 channels of 1-wire input (DS1820-style,) 10V analog inputs, Digital I/O and I2C/SPI capability. It has a pretty wide range of input voltages, so it runs off my battery charger setup with no issues (at ~13.6VDC.)

It has a simple programming language that resembles assembly, so if you have any familiarity with ladder logic or any kind of logical programming language, it shouldn't be an issue. As an example, a program I wrote for testing, which sends an I/O summary every hour at 45 past:



START

WHATTIME:
     TSTEQ CM 45 RAM1
     BNZ RAM1 TELLME 
     GOTO WHATTIME 

END

TELLME:
     EMAIL EM1
     DELAY 120000
     GOTO WHATTIME 

In the program:

Test if CM (Minute) is equal to 45 and store in RAM1
If yes (branch if not zero) go to the email function sub
Loop it forever

Tellme subroutine:

Email using the parameters specified in EM1
Wait 120000 1/1000 of a seconds (2 minutes, so we don't loop back and send another email)
Return to the main program

Right now, I just have a single DS18B20 and an HIH4000-001 humidity sensor connected to the board, which is wirelessly connected to my network via a repurposed WRT54GL running DD-WRT and acting as a wireless bridge. Total current draw for the board at 13.6V is about 110mA, with the wireless bridge consuming another 220mA.

Something of note regarding this board: Older variants of the WebControl used a linear regulator, which got HOT quickly. This one has (what appears to be) a simple switcher, which doesn't get anywhere near as warm, and offers a wider input range. It's supposed to run at 5V, but the lowest I could get reliable operation is 6V.

I'm looking forward to replacing everything and adding yet more sensors to the system!


Wow that's a terrible picture!

Turning everything on - and there's no smoke!

Installation of my board was without issues (other than the filtering issue, which was corrected before installation.)

The box everything goes into is an Elk Products box with integrated battery charger originally designed for the alarm industry. It's basically a pass-through, and uses the battery as a cheap regulator. Nominal output voltage is 13.6-13.9, which is what the battery is floating at during charge, so everything in the box needs to handle this.

Starting at the top right, my board, the built-in battery charger, the battery, the power transformer (12.6VAC 2A), terminal strip and fuse, and the final component which is a commercially available water leak detector, "The WaterBug," available from Winland Electronics. The wireless sensors being powered are off to the right (out of frame.)

Everything powered up with no issues, and has been working reliably for the last few months.


The box was installed in the furnace closet, with the leak detector going down to the water heater directly underneath. (Lid removed during installation.) The only addition was to hang a temperature/humidity sensor in the box and connect it to one of the wireless sensor units.

(Apologies for the picture, it was taken in the dark with a potato!)

Board Built and (mostly) operational!

My boards came back from OSH Park with no issues, and they look good. Everything is gold-plated, and solderability is excellent. The only issue (not really an issue) were the tabs left over from where the boards were broken out of their larger panel. A quick hit with a file took care of that no problem.

The board consists of two power converters - one a DC-DC device that powers wireless sensor pods (on the left by the fuse.) The other is a simple three-terminal regulator that provides a somewhat dirty 5V to engage the alarm relay. There are two supplies, as the dirty supply needs to fail when the AC is removed. This causes the relay to fall, and a remote sensor (powered by the DC-DC converter and a battery) sends an alarm to a remote system. The DC-DC converter runs off the battery and powers sensors during an outage.

The three-term device doesn't get a heatsink, as there is only about 50mA of current draw. The DC-DC converter is rated for 500mA, and has a load of about 150mA.

The back of the board (which I didn't take a picture of for some reason) has the remaining components - a rectifier for the alarm side (as it runs directly from the input transformer) and some filter capacitors. I actually didn't put enough filtering on the board, so a radial capacitor was added. As I'm making a second run with a few more functions, the capacitor will be changed to surface mount and placed on the board.

In all, my first personal project PCB turned out pretty nice, and I've decided to add some extra stuff like a low battery monitor and cutoff circuit to the next rev.


Friday, October 21, 2016

A simple board for a project

I've decided to shelve the energy monitor for now, as I need to do some consideration on how to actually get data into the system. I've decided to use the wall box with the battery charger for something else - a power supply for the existing wireless sensor transmitters that I have running on the network.

In the past, I'd probably have used a Radio Shack protoboard to lay circuits out on, but the maker economy has brought a number of low volume PCB vendors to the market. It's easy enough to lay out a board, and get 3 boards for $5/sq. inch.

One such house is OSH Park, which manufactures boards on community panels - that is, your order gets added to a bunch of other people's orders, and the fab house makes everything on one big panel. You get your boards, and it's cheaper than what conventional prototype houses offer. It just takes a while (few weeks) to get your boards.

My first board design with them is a simple unit. This design features a low ripple 5V DC-DC converter to power existing wireless nodes. The regulator (U1) is 1/2A, which is fine as the nodes draw about 60mA, and there are currently only 3. It's fully bypassed and has some extra filtering onboard just in case.

The other section of the board is a simple rectifier and regulator to power a relay. This side takes the AC directly from the battery charger's transformer, rectifies and regulates it, and turns a relay on to trip an alarm. AC goes away, relay contacts fall, and alarm is triggered, the alarm itself running off the battery that was just being charged.

The circuit itself is nothing fancy, a simple LM78xx is used here. The only thing I decided to do was lay pads for either a TO-220 or a TO-92 regulator. The relay itself is a Hamlin 3700 reed relay, a batch of which were purchased on eBay (but the footprint is standard SIP.)

In all, not a whole lot is going on here, but doing it this way simply provides a nice, clean layout.



Monday, July 25, 2016

An LCD screen for my energy monitor project? (Part II)

One of the things that I thought would be nice with my energy monitor project would be to have the unit display some basic information without logging into the device. There are a number of options, but the cheapest (and probably easiest) to work with is the Nokia 5110 display. These can be purchased from many sources, but the ones I have came from Adafruit. Adafruit also provides some ready to go libraries written in python for your coding pleasure, so it's almost trivial to get the thing up and running.

I was using a Pi B (original model) and my old CSC breadboard. That unit has served me well, and CSC replaced the terminal strips on it once for me for free. It's interesting to think how many technologies this thing has seen over the years.



It took about 30 minutes to wire the Pi and install the libraries, and get coffee. Mostly coffee...

After a quick glance at what the libraries do, I ran the demo program included with the library.


Yes, you sure can haz LCD, mister cat!

Next step is testing the power supplies for the system.

Friday, July 1, 2016

My DIY Home Electricity Monitor: Collecting Parts

I've been interested in monitoring the total current input to my residence for a while now, but all of the solutions I've found don't really do what I want. Either they are tied to some remote service for operation, they collect data in some hard-to-use proprietary format, or they offer gee-whiz features while skimping on actual functionality. All of that led me to the conclusion that I needed to roll my own device.

I started by trying to figure out what I'd need:

Current loops that can be snapped around the wires in the box and aren't overly large.
Some sort of data collection device with enough intelligence to store data.
Boxes to put everything in.
Odds and ends to tie everything together (power, data lines, etc.)



Snap-On Current Loops

Current sensors are fairly easy to get, but finding ones that weren't overly large was a problem - I have a very limited amount of space in my electrical box. I also cannot undo the main coming into the residence, so small, snap-on loops were a must. I settled on these units from Seeedstudio. I purchased 100A units for the main, and 60A units for a branch panel. This particular variant was only offered in mA output, and I'm unsure as to it's output type - I assume DC but have a backup plan if not...


Precision Instrument Rectifier Board

Originally meant for an audio spectrum analyzer, this board was 1/2 of a set of 12 precision full-wave rectifiers (10 audio channels plus 2 for R and L.) That never came to be, but I have this half of the rectifier assembly. Since I plan on having 6 channels of measurement - 2 on the mains, 2 on a branch panel, and 2 on a generator input, this was perfect. Now, I just need to remember how this thing works...


A Box To Put It All In

A $5.00 hamvention purchase, these boxes came out of an old-school wired alarm system. I originally had purchased these due to the cellular modem in one of the boxes:


But it turned out to be permanently attached to a service provided by it's manufacturer. I'll set this aside for investigation at a later date, but for now it's worthless to me. However, inside one of the boxes was another board which I believe may be of use:


An Elk Products ELK-624 multi-voltage power supply and battery charger. This device kept the cellular modem and accompanying alarm box up in the case of power failures. While it didn't have a transformer, I have plenty laying around that will probably work with this. I think this unit will come into play as a UPS for the microcontroller. It's a linear supply, but I'm not too worried about it. 


Glue

Some other odds 'n ends that will probably go into the box is an AVTech Room Alert 3A device that was given to me when the original owner managed to completely destroy the firmware load and throw it into recovery mode, a Trendnet 5-port Ethernet Switch to connect the monitor, 3A, and whatever else into the network, and some power supplies. I don't know if the Rhino 5V DIN-mount power supply in the back will work yet - it's taller than the boxes I have but I may be able to work it in.

The only parts left to get are some sort of microcontroller device - I'll probably go with a Raspberry Pi 2B, simply for ease of use, some sort of ADC board to allow sensor input, and some power supplies and converters.

Off to search for more parts!


Wednesday, June 15, 2016

Quick and dirty temperature monitoring.

One of the projects I've been tasked with is finding a new CPU assembly to replace my employer's aging PC104 stack. While the PC104 stuff is still available, it's nearing EOL and last time buys, so we need to get it out of circulation now.

One of the requirements, as this device is going to be on factory floors, is that the CPU runs comfortably at 120F in a 10x12" painted steel box. Comfortably, meaning the device can sit there and not halt or otherwise die while running at a load of 40-60% CPU time. Getting the temperature up to that point is no problem - our homemade solution is a modified chest freezer with some heating coils and a simple FUJI-style temperature controller.

Measuring the temperature and getting it into a useful form, however, is a different story. The usual solution here is to use Labview and a bunch of complicated Advantech hardware to read sensors, store it someplace and graph the results. Since I only have a few weeks to evaluate this, tasking the programmers with yet another project was out of the question.

So, how to do?

I had an AVTech RoomAlert 4E device left from a previous project, with a couple of DS1820-compatible temperature sensors. While the 4E is meant for permanent installation to monitor computer rooms for overtemperature (and other environmental failures,) it works just as well as an SNMP-capable temperature box.


A single point calibration was performed on the sensors. They are in a plastic bag, suspended in an icewater bath. A NIST-traceable thermometer provides the standard.

The logical choice for a simple project (in my mind) was a Raspberry Pi. I had an older Model B laying around doing nothing, so a simple reflash with Raspbian Lite started me off. I needed some tools, so:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install snmp rrdtools apache2

snmp - gives snmptools, which gets me the snmpwalk command to read the box
rrdtools - so I can create and maintain Round-Robin Archives and graph the data
apache2 - so I can display the information on a local webserver for viewing

First thing to do was create the graphs.

rrdtool create freeair.rrd \
        --step 20 \
        DS:fa:GAUGE:120:U:U \
        RRA:AVERAGE:0.5:1:525600

rrdtool create cputemp.rrd \
        --step 20 \
        DS:cp:GAUGE:120:U:U \
        RRA:AVERAGE:0.5:1:525600

Basically, just a 20 second step with a 120 second timeout. The points specified are far in excess of the 3 days or so the test is going to run.

The next part was more difficult. I had to figure out how to read the SNMP values from the AVTech box. That's normally pretty easy, but the MIBfile that AVTech provides had errors and didn't provide the entire OID necessary to get the values. I also found out that the local network here was kind of flaky - where I can read values all day, the network here timed out my reads for some reason, so I had to put in a small routine to hold values and check against new ones.

#!/bin/bash

# Read the SNMP values and put them in a RRD.

function showme {

fa=`N=4; snmpwalk -v 1 -c public 10.0.0.93 1.3.6.1.4.1.20916.1.6.1.2.1.2.0 | awk -v N=$N '{print $N}'`
cu=`N=4; snmpwalk -v 1 -c public 10.0.0.93 1.3.6.1.4.1.20916.1.6.1.2.2.2.0 | awk -v N=$N '{print $N}'`

if [ "$fa" = "" ]
        then
                fa="$fold"
                cu="$cold"
                echo "Old values retained"
fi

echo $fa
echo $cu
echo " "

}

while :
do
        showme
        rrdtool update /mnt/flash/freeair.rrd N:$fa
        rrdtool update /mnt/flash/cputemp.rrd N:$cu
        sleep 20
        fold=$fa
        cold=$cu

done

I was able to find the OID values necessary by looking at other AVTech units I'm using, deducing the values, and comparing them to other IDs I found online. It ended up working, and I'm planning on notifying the vendor that the values they provide are incomplete.

The script reads the values with SNMP and returns only the 4th data item in the string, which is the actual data I need. It's compared to an empty string, and if empty, the last good values recorded are used. A simple infinite while loop calls the read routing, puts the values in the RRAs, and waits.
Graphing the data was a simple matter of using RRDTOOL's built in graph function:

rrdtool graph  "/var/www/html/fa.png" \
-w 1000 -h 343  -a PNG \
--start -1h --end now \
--title "Chamber Air: Last Hour" \
--vertical-label "DEGFx100" \
--upper-limit 14000 --lower-limit 3000 --rigid \
DEF:asource="/mnt/flash/freeair.rrd":fa:AVERAGE \
LINE1:asource#fcad00:"Chamber Free Air."

This was repeated for each graph, with the filename being changed as appropriate.

Finally, to get the information into a useful form, it was pulled into a simple webpage and served by Apache2:



The whole mess was started at boot via a crontab @REBOOT call, with the graphs being regenerated every 10 minutes. A 30 minute refresh was specified in the HTML code, and it all worked nicely.
The Raspberry Pi ended up just sitting on a table, needing only an Ethernet connection and power provided by an old BlackBerry phone charger.


Everything turned out better than I expected. (Note that the data was graphed raw. SNMP doesn't provide decimal points, so everything needs to be divided by 100 to get "actual" values.)



The CPU performed without issues, and I have some nice graphed data for what amounted to 30 minutes worth of setup time, instead of the unknown amount of time that would have been needed otherwise.

And the Pi? It gets put back into my pool for use in another project, some other time.

Monday, May 23, 2016

A Pi Zero!

This past weekend, the local Micro Center got a big batch of Raspberry Pi Zero boards in stock. They currently limit them to 1 per person - but at the price of $5 per I can see why you'd want to pick up a handful.



This thing is TINY. The Ethernet adapter I used to set it up is almost bigger than the board itself. With the OTG cable attached, it literally is bigger. I can see now how they were able to attach these to a magazine as a promo piece.

Setup was pretty much standard. The Pi recognized the ancient CompUSA (!) adapter I was using, and grabbed an IP address. Configs and updates later, I decided to give it a try.

For the test, I grabbed an otterized microblog application called Pjuu, from this github repository. Running as root, it installed with no issues, and started serving right away.


Load average with a couple of users was running around 0.15 at the 15 minute mark. Not bad! I don't know how this would perform under heavy load, but for my test it worked well enough.

The only thing I wish that the Zero had was a way to permanently add a network device. I realize that the point here was to reduce the cost to the point of insignificance, but adding some pads in the shape of a purchasable network adapter would have been ideal, since these things are small enough they can fit in a wall box.

But for $5, it's really difficult to complain.

Thursday, May 12, 2016

I repurposed an app instead of writing a new one...

The microblogging service I installed has been working well. It's easily accessible via any browser, and presents a nice mobile face to the world. It's inconvenient (Yes, I know, cry) to access through a browser, so I figured I'd see if the author of the original code offered any kind of application for Android devices.

Well, yes and no.

They do offer an application, but it's to demo their own install. There appears to be no way of changing that from within the application, so I almost simply tossed it aside, as I don't need to access theirs. However...

I noticed that the mobile version of their install and the app looked identical, so I assumed that they were simply using a browser-based wrapper instead of writing an actual application to retrieve data from their system. Turns out I was right.

I confess I know little of Java, and nothing of writing Android applications, so I made a lot of leaps of faith here (and probably did some of them wrong.) I also run my devices as root, which makes it a lot easier to do what I did.

I started by grabbing an APK decompiler. There are a number of them, from command line to online, but I settled on one called APK Studio which is available from here. It isn't the most full featured thing of it's kind, but it was the only one that worked without seeming to need a lot of know-how on it's own. I also had to grab the apk file from my the backups created from Titanium Backup. Again, running as root allows me to grab them, but you can also use various online tools to either get the APK directly or download it from the play store.

Open APK Studio, and...


What am I looking at? Who knows? Off to read a little about APK files...

Turns out I was right. The application provided by the vendor is simply a web wrapper that calls a specific website, and displays it fullscreen. Nothing more. So I just started clicking on things, opening folders.


Ah ha! What's this? app_name? I remember that, it's the name displayed by the Android launcher! I make the change to my new name, "Chirper". And what else has revealed itself? A number of .png files that turn out to be the launcher icons. Great! I import those into paint.net, and simply overwrite them with my own icon image, keeping the original size and color depth. So far, so good. Now, I just need to figure out where the program calls the website in question.

Buried down in the structure, under FullscreenActivity, is what I'm looking for...


const-string v2 contains a URL which points directly to the address of the vendor's site. I made that point to my own install. Interestingly, the .smali file directly above this one also had the address, minus the http:// prefix. I changed that as well, following the format already established. I'm not even going to guess why this is like it is.

I save everything, push the APK back to my device, and have to do one more step: Resign the file. Android expects all files to be signed by some sort of key. Most files are signed by the Play Store, so you can get updates to the application. I didn't want this to happen, so I used an Android app called ZipSigner to resign it with my own personal key. That way, while the internal name of the file still matches that of the Play Store, the keys no longer match, it won't try to update, and I can install it on my device.

Signed, and installed, and it works just like I expected. The name is correct, the icon is correct, and it points directly to my own webserver.


So, was this the best way to go about getting what I needed? Probably not. Was it useful? Sure was, I learned some stuff about how Android applications work, and I'm on my way to actually being able to write this myself. Did it work? Perfectly.



The moral of the story? Don't be afraid to dig into stuff, you may learn something!

Thursday, April 28, 2016

php and the case of the missing timezone.

Twitter is a great service for some things. Personally, I think it's very easy to allow your feed to get noisy to the point of irrelevance, but it you're careful about what you follow it's a great service.

One of the other things it's good for is simple notifications. Twitter has a varied history of allowing third-party interfacing, but they have a well documented and useful API, which has allowed things like Tweepy for the Raspberry Pi to happen.

However, it's also a third party service, which means you are reliant on someone else to hold on to your data. I don't like that, I've had services get yanked or changed underneath me without warning, so I make it a point to find something I like and then try to duplicate it locally.

Enter a program called SocialStrap. It's one of many php microblogging programs you can run on your own server. While this one does cost around $50, it offered a clean, modern view with a good mobile look, without requiring things like Flashplayer or appearing to be a WAP site. It's also popular enough to have some third-party plugins written for it. In my case, I was interested in a set of API applications someone had written in php.

In a nutshell, the API just plugs the information you provide into the SQL backend of SocialStrap, which gets dynamically refreshed when you call the website again. Nothing fancy.

But...

I noticed that everything I posted with the API was way off regarding time. In the morning, it was off by four hours, in the afternoon, off by 16!

Four hours is, of course, the difference between EDT and UTC. That problem was easily identified. 16 hours - I wasn't sure where that was coming from.

Doing some investigation with the SQL database, I found that SocialStrap expects the time of post to be UTC, which then is calculated to be your local time when the page is called. SocialStrap also wants the time in 24-hour format, which the API was not providing. 14:00 was being passed as 02:00. 12+4 is 16. Both of my problems right there, but how to fix?

php is interesting in that you can specify a timezone locally, inside your script. So if you want to process everything UTC while your machine sits in EDT, no problem! You can place this code at the top of your script, directly below your <php? tag:

date_default_timezone_set("UTC");

This command has a list of timezones you can operate on, and that list can be found here.

That took care of part of the problem. Now, why is it giving me 12-hour time? Turns out, php is like most other modern scripting languages - it can give you the time in an almost unlimited number of formats. Digging through the API code revealed this:

 $created_on= date("Y/m/d h:i:s ");

What's wrong with that? Well, it's a perfectly valid statement, except that the small "h" tells php you want the time in 12-hour format. Changing it to this:

 $created_on= date("Y/m/d H:i:s ");

fixes the problem. Now, the API inserts posts into SocialStrap with UTC, 24-hour formatted timestamps, and my automatic posts are no longer 16 hours off from their actual post dates! What do I get for my trouble? A list of machine outputs and things hosted locally on my own server.


Kestralbot, the confused bird who can't even spell his own name, chirps on a regular basis, no third-party required. (I passed the bugfixes on to the author who was delighted that someone was using his code and had taken the time to improve it.)

Wednesday, March 16, 2016

The Raspberry Pi 3 - Finally!

These guys have been kind of scarce for a while, but I'm pleased to add one to my collection!


I also picked up an Orange Pi (from LoverPi on Pi Day) and a Pine 64/2GB/WiFi unit to play with. I have a lot of new toys to set up soon!

I'm not sure what's going to happen to the 3, but I was thinking I could combine two of the units I currently have into one, moving the mail, chat, and weather radio monitor from one unit and the RSS/Image scraper and remote storage functions from another onto this one unit.

If the trend continues, the Pi 4 should be able to handle the Cacti, Smokeping, X10, and miscellaneous network functions of the other unit I'm currently running, as well as the aforementioned mail/chat/etc. functions.


Best part? It's still US$35. Rock on, Pi.

Wednesday, February 24, 2016

Tweeting from your Pi - Fixing issues with Tweepy

Edit (10/21/2016) - Debian Jesse took care of most of these problems, so you may not need to do all of them. I ran through on a fresh Jesse install just to see what happened, no errors but there was a lot of "already installed" messages returned. YMMV!

I've set up one of my Raspberry Pis to do some various functions around the house - monitoring a weather radio, checking temperatures - that sort of thing. I have it send alerts via email, but wanted a more publicly accessible way of getting this data in the event that I don't have my phone with me, or whatever. You know - more redundancy is better!

Twitter is a pretty good way to satisfy that requirement, and they provide a pretty decently documented (and well hashed by programmers) API. It's pretty easy to push messages from the command line with a few lines of python.

I started by following this guide to create the application in twitter and get the necessary python libraries on my Pi. It's using Tweepy, which seems to be the de-facto way of sending data to twitter via python. For the most part, the guide works, but I did run into some issues.

First was this error while actually installing the Tweepy library:

TypeError: parse_requirements() got an unexpected keyword argument 'session'

Searching for information, it seems that pip needs to be updated. Now, you're saying to yourself, "I just installed this! Why does it need to be updated?"

The version in the repository is an old version, which is the reason for the needed upgrade. See this post on github for a description of the problem. It's easy enough to correct, just run the upgrade command on pip:

sudo pip install --upgrade pip

Great. You're now ready to tweet. You've put your keys in the programs from the guide, you execute the program, and:

/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning


Well, crap. The tweet worked, but this warning pops up. Certain cryptographic extensions aren't available on the Pi. Easy enough to fix, see this stackoverflow question for more information.

To fix THIS issue, you'll need to install some more stuff. I assume you already have a gcc compiler installed, along with dev tools for it. There are plenty of tutorials out there for that, so again - I'm not going to cover it here. However, once you have that set up, you'll need to install some libraries, and then install the cryptographic extensions:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install libffi-dev
sudo apt-get install python-dev

What that just did is install the Foreign Function Interface that allows Python to use compiled code from other languages. This actually has to compile some code, so it will take a few minutes (or longer, depending on your Pi.) It also installs some python development tools so gcc can properly compile python support into the next command.

Now:

sudo pip install requests[security]

That will install all the necessary security extensions. Again, this will take a few minutes. If you get other errors at this point, I would suggest just copying the error directly into a google search. Chances are, someone else has had the same error - in fact, that's how I solved all the problems here.

Now, you can tweet with Tweepy. You shouldn't get any kind of messages on the Pi unless the tweet failed in some way.

This is a fairly top-level overview of what I encountered when installing Tweepy. As always, if you're unsure of what the steps mean, or encounter other errors during the installation process, STOP! Research your particular error before continuing.

Tuesday, February 23, 2016

Replacing a commercial NTP server with a Raspberry Pi

This past week, my rack-mount, commercial GPS NTP box suffered a failure. Apparently, the GPS receiver was unable to make sense of an extended week count number, rolled over, and now thinks it's 1996. There's a firmware patch for it, but mine didn't seem to like it (the manufacturer has been very helpful and we are working through it.)

While I'd certainly like to think it's now 1996 again (let's see, buy some silver, some Bitcoin, sell Lucent stock...) it's not, and having your network clock so far off isn't the best thing for time-sensitive signed certificates.

In steps the Raspberry Pi. While there have been a number of ways to use a Pi as a NTP server, such as this guide, the hardware they rely on can sometimes be difficult to get, especially if a few years have passed since the article was written.

That guide did show a link to a piece of hardware that is still available in an updated form.

This board is designed to drop directly on top of a Raspberry Pi + or 2, and provides, according to the vendor, an adequate enough service for a Pi-based NTP server, as well as stationary mode and PPS output. I take that to mean that it's not going to be as good as say, a US$5000 unit, but is going to be much better than trying to sync from internet-based time clocks, especially if you want all of your local devices to be very close in reported time. They even provide a helpful how-to guide for setting up a stratum-1 NTP server.

You can order one of these boards from habsupplies' online store. I currently have a board + antenna on order, when I can get it installed I'll do a quick write-up of my experiences.

Note: The original problem was older Trimble GPS units rolled over at week 1024, taking the date back to 1996. The firmware patch corrects this by, I assume, making the attached computer think it's year+20. The original device is now working again - I had to get special instructions from the manufacturer of the NTP box regarding disabling certain watchdogs to allow the firmware update to complete.

Monday, February 15, 2016

Unusually high load average times on my Raspberry Pi?

I run a few Raspberry Pi 2 on my network. They handle basic tasks - network and device monitoring via Cacti and Smokeping, a local email and chat server, and an ad-blocking DNS server, ala a Pi-Hole. None of these services really task any of their respective machines terribly, so when load times on the Cacti/Smokeping machine started creeping up past a 1m average of 1.06 from a 1m of 0.05, I got a little concerned. It didn't seem to be affecting the machine adversely, and top didn't show me anything unusual, so I let it go as it seemed stable.

That is, until a bootloader update came along recently. Attempting to install it threw I/O errors while the installer tried to copy the new files to /boot.

 I boot my devices from an NFS share that sits on the network, but due to the way the Pi is designed, you still need a single FAT32 partition on an SD card that contains the bootloader's binary blob. This partition gets mounted as /boot at runtime, and is the only partition residing on the SD card in my particular case. Everything else sits on the network share, safe from the corrupting influences of the SD card.

Attempting to ls the /boot directory revealed an empty directory!

I was really happy I hadn't tried to reboot the machine remotely at this point. I shut it down and pulled the card. While the files normally there were still there, the directory was considered dirty by Windows and wanted to be checked on mounting. I was, however, able to copy files from the /boot directory onto a new card, which consisted of a single FAT32 partition.

I reinserted the card, and the Pi rebooted normally at this point. Updates installed, everyone cheered, and I forgot about it until today. Logging in, I noticed that the load averages were now back to what I considered normal for the light load on the machine! I'm not sure why having a bad /boot directory caused my load times to skyrocket, but the cause and effect seems to be there. The machine is running happy again, and my original thought of having the actual OS offloaded in case of SD card failure proved to be a sane one. The whole operation took about 10 minutes to correct, most of that time trying to find an SD card that I could erase.

I've had problems with SD cards simply failing, but that was with the entire OS on the card. Having only part of the system on the card allowed it to continue running, just...strangely.


The happy Pi, chirping once more...

 I'm sure there's an explanation for why the load times were high with a bad boot sector, but I'm unable to explain it. Perhaps you can?

Saturday, February 6, 2016

Burroughs B-7971 Nixie Tubes...

A long time ago I acquired some of these giant Nixie tubes from some old equipment. I had intended on doing "something" with them, but never got around to it as the sockets for the tubes were as expensive as the tubes, and I didn't really have enough to do a whole lot with. I didn't want to use them in a clock, but that seems to be the best use for them.

These are fully segmented alphanumeric tubes, and are about the size of a 12oz can of soda!


I honestly can't remember what they came out of, other than it was some big industrial controller. They were working when pulled, and I don't have any reason to think they are not operational right now. Considering these things date to 1964 and 1967, that's pretty impressive.

They're really dirty, but I hate to clean them as it may destroy the printing.

They're all the same model, but they are all marked a bit different. 5 of the tubes are marked with the Burroughs "B" but are labeled "Ultrasonic Systems Corp." - I can't find any reference to Burroughs and this other company, so I have to assume they are a OEM marked part for this other company.


These guys were all dated to around 1967.

The other 3 were simply labeled as Burroughs, and dated around 1964.


The best thing to do with these is sell them off. If you're interested, please let me know and I'll direct you to the craigslist ad that they are posted under. I prefer local pickup, but will ship (postage, insurance extra) to most places.

Now, all together for a family portait (I see you hiding in the back!)


Hopefully these guys will find a home. 

B7971 and B-7971

Edit: As of 2/29/2016, these tubes are SOLD. Thank you.

Monday, February 1, 2016

A small rack system for a friend.

A friend of mine wanted to set up a small home network rack in his basement, but needed to do it as inexpensively as possible. We already had most of the normal equipment you'd set up in a home system - the modem provided by the cable company, an older (but still operational) Linksys WRT-54GL router and WiFi access point, and some other odds and ends.

In order to get it all set up, I needed a small rack. Craigslist was the first choice for this type of item, and browsing revealed a number of different items available. I settled on a Cooper half-rack on wheels, which I picked up for $50 (It fit in my car.) It appeared to have had some sort of high-speed fiber termination in it, as there were a couple of fiber patchpanels, and some Cat6e cables hanging out as well. A cable management rack was included as well, but the plastic had been shattered and it was discarded. I kept as much of the extras as I could, which was mostly just the Cat6e cable. These were about 1' long, and I set them aside for later. Pretty much everything else in the rack was discarded, as it was chopped or broken.

In order to add some good functionality to the rack, I located a seller with a slightly used rack-mount UPS (in a nice carpeted rack box) for another $50. Another Craigslist find, the seller was moving and wanted it gone. The PDU above it was a demo from some local company that had dead LEDs in the display - these were easily replaced. An AVTech RoomAlert 32e, left over from another job where I was able to purchase 3 of these units for under $50 was mounted as well, with some of the homemade sensors I described earlier. A discarded D-Link 10/100/1000 switch that was recovered from a junk pile at work after a switch upgrade was bolted in. Shelves were purchased surplus. Full of holes, but who cares? A Monoprice patch panel and some keystones rounded out the project.

We made some new cables with new wire and ends to run through the house, but I also reused all of the Cat6e cables that came with the rack. These turned into jumpers between the patch panel and the switch.

The rest of the equipment in the rack was already owned. Two Synology units and the aforementioned modem and router. As payment for setting things up, I requested co-lo on my own Synology unit, which along with it's accompanying APC UPS, makes a nice off premises backup system.

It's not the prettiest thing in the world, but it keeps everything in one place, and allows for airflow and offers a little bit of expansion if needed.


In all, the project totals, for things we didn't already have:

Rack and Jumpers: $50
Patch Panel: $20
Keystones: $20
Switch: Free
Room Alert device: $20
PDU: $65
UPS: $50
Shelves: $20
Cables and misc: $100 (we didn't use all the cable for this job.)

TL;DR: When setting up a small system, Craigslist and eBay can be your friend.

Bitcoin?    1B1DWLzvgp3tdtNjbHufyqRP1fUdN6HXLh


Thursday, January 28, 2016

Too much junk?

Never.


It's all good stuff. Not junk. No sir.

Bitcoin?    1B1DWLzvgp3tdtNjbHufyqRP1fUdN6HXLh

Indoor and outdoor temperature sensors

Similar to my previous build, here are some more temperature sensors using DS18S20 TO-92 case 1-wire temperature sensors.

These are designed to talk to an AVTECH Room Alert system, but would work just as well with any device that can speak 1-wire protocol ( the ends are wired for AVTECH's particular setup. )

I chose the 'S' variant of the 1820 family because evidence suggested that AVTECH used the older devices. Besides, I'm not willing to plug an unknown device into a $1000 monitor without good reason!

Starting the build, I chose some scrap stainless tube, cut down to about 1.5" and cleaned of any flash or other sharp edges that may cut into the cable. A pre-made cap of rubbery plastic serves as the cap to the tube.



The sensors themselves are simply telephone-style cable soldered directly to the devices using "44" core flux, and then cleaned with alcohol. Heat shrink tubing was placed over the individual leads ( be sure to do that BEFORE soldering! ) with larger shrink placed over the whole assembly, leaving the sensor uncovered.

The sensor assembly is inserted into the tube, and the tube is filled with an epoxy. In this case I have access to some industrial materials from 3M, but any good, runny epoxy should do - as long as it's not corrosive to the leads of the sensor. The epoxy is allowed to cure, an RJ-11 is crimped on the other end, and that's it for indoor sensors. They are fairly liquid tight at this stage, but I like to go one more for outdoor use.

For outdoor sensors, I then dip the entire sensor end in tool dip, and allow that to cure. At this point, with the epoxy center and the rubberized overcoat, I'm fairly certain that these will withstand normal outdoor weather. I wouldn't dip it into liquid for extended periods of time, but it would probably work without issues.


Two sensors are now ready to go - one for indoor use and one for outdoor use.


It works! It's actually pretty nice today, for January!

Bitcoin?    1B1DWLzvgp3tdtNjbHufyqRP1fUdN6HXLh

Some more Blonder-Tongue Audio Baton pictures

A family member recently gave me an envelope full of things related to my high school - certificates, grade cards, that sort of thing. Upon sorting out the papers, I came upon some more pictures of my Audio Baton restoration project. I'm not sure why these were in there ( and not in my private collection, ) other than I used their camera to take the shots. The negatives, however, are still missing...


The pictures, in order, show the restored underside of one of the chassis units, the rack case with the switching and meters ( Still like the way this turned out, the sweep on the front was pleasing to look at,) and the original cased unit. Sadly, the lettering was all scratched off for the bands, so I had to resort to a label maker. I had intentions of re-lettering them, but sold them before that happened.

The chassis itself doesn't look as nice as I remember - I guess time does make those things blurry. I do remember enjoying the rebuild process, and coming up with a tighter layout than BT's original setup.

( And yes, that's a copy of The Radiotron Designer's Handbook, 4th ed. in the bottom! )