Tag Archives: My Projects

Recommended Reading: AA7EE’s Boris Beacon…

I’ve been interested in low power beacon transmitters for a long time.  If you’ve followed my blog, you’ve probably read about my experiments with WSPR and QRSS operation.  Most of those took place on 30m using my FT817 transmitter, sometimes with software that I wrote myself.  But I’ve long thought that I should homebrew a transmitter, and the idea of making it solar powered has always been in the back of my mind.

These operations have all been on ham frequencies, but even if you are unlicensed in the United States, you can get experiment with low power beacon operation under what is known as “Part 15“.   These rules are part of the Code of Federal Regulations, Title 47, and specify certain bands and limitations as suitable for unlicensed devices.   Rather than reading the boring regulations, you can go to Long Wave Club of America website and read up on experimentation under Part 15.  You’ll generally find operation divided into “LowFER” (operation below 200khz, usually in the 2200m and 1750m bands), “MedFER” (operation in the AM broadcast band, usually between 1600khz and 1800khz) and “HiFER” (mostly centered around 13.55Mhz).  

I was initially most interested in the LowFER bands, but I’ve never really gotten off the ground with the project, but recently have become more interested in operation in the HiFER bands.  It presents some significant limitations.  The most desirable band is limited between 13.553 and 13.567 Mhz.  The total power output is specified in terms of a field strength at 30m distance from the antenna, but is on the order of one milliwatt into a half wave dipole at the frequency.   You also are supposed to maintain frequency stablity to about +/- 0.01% over a temperature range of -20 to 50 degrees C. 

This isn’t a lot of power, so it can be challenging to get an effective signal out, but it also makes for some interesting opportunities for home brew construction.  Most beacons of this sort are small crystal controlled transmitters, and they can be powered by reasonably small solar cells, and controlled by inexpensive, low power, eight bit microcontrollers that are readily available. 

Dave Richards (AA7EE) wrote up an awesome description of his Boris Hifer beacon, named after his cat.  It’s a very straightforward design: a Collpitt’s crystal oscillator, a small two stage low pass filter, and an ATtiny85 microcontroller driven by a LP2950 5V regulator that is powered directly from his solar panel.  (He also points at this $20 kit from Chris Smolinksi at blackcatsystems that would be dead simple to put together).   As it happens, I have almost all the parts in my junk drawer, and could easily put such a beacon together.  I even have a stash of the 13.56 crystals somewhere.

Dave’s construction is gorgeous, and he mounted it fairly low at the top of a fence.  I have a similar fence at the back of my property.   I would be tempted to use a more sophisticated solar setup perhaps utilizing a small battery.  Propagation on this frequency is probably better during the daylight hours, but the solar panel likely generates an excess of power each day, and being able to survive small dips in cloud cover and the like would be good.  But then his experience is that even on cloudy days his beacon wakes up, so perhaps I’m overthinking it.  He also has a good description of using the BOD (brown out detection) in the ATtiny85 to ensure proper startup in varying voltage conditions.  His write-up is really great, and will no doubt save me from a lot of hair pulling.  

Well worth reading.  You might also read his page about making a temperature beacon which was inspired by K7TMG and also this short experiment I did back in 2012 (apologies for the jittery phone video):

Debugging my cordless lawnmower, with an side of musing about Torx screws…

As part of my attempt to become slightly more virtuous, I’ve been trying to do four hours of work cleaning and organizing my garage workshop every weekend.  Last weekend, I got to the point where I was forced to address my cordless lawnmower.

My mower is a fairly old Black and Decker model CMM1000, which uses a 24V lead acid battery.  I hadn’t used it in several years.  I had bought a gas-powered Toro lawnmower because the B&D was occasionally underpowered, particularly when the lawn got tall.  It was also a mulching lawnmower, and over the years a thick layer of thatch had formed in the lawn, and it didn’t really look very good.  I tried shifting to use the side outlet to bag the clippings, but that never seemed to work very well either.

But in any case, I had thought the B&D should be in good working order: it certainly was when I had left it a few years ago.  I plugged it in to recharge it, and… well, nothing good happened.  12 hours later and the mower still wouldn’t start.  It’s not shocking really: I had probably left the battery in a discharged state for a very long time, and it was probably dead.

Sunday I decided to try to extract the battery and put it on the bench, and see what I could figure out.  Sadly, Black and Decker doesn’t seem to have the manual for this mower on their website any longers.  Boo!  A bit of Internet searching found lots of websites that would install various bits of crap on my machine or exchange a new account for a download of the manual, but all that was irritating.  I decided to turn to YouTube to determine if someone had done this.   And, of course they had.

This didn’t look too hard, so I dug out a Phillips screw driver, and my socket set, and started to work.   Removing the throttle control and the two rear screws on the main housing wasn’t difficult.   I then moved to the front screws, which lie in the bottom of a hole (maybe two inches deep) in the front housing.   These holes were chock full of grass and dirt (naturally) but luckily I have an aircompressor and a blow gun, which made short work of the dirt.   I blew them all out, and then took my handy Phillips to it.

Hmmm.  No dice!  I couldn’t get a grip on it.   I changed bits to a smaller one.  Still no dice.  Finally, on a hunch I got a small flashlight so I could peer down into it.  And… it was a Torx screwhead.   Grumble!

Luckily, I have a pretty good supply of (very seldom used) Torx drivers, and a few minutes later I got the silly thing out.   What was kind of annoying was that the video didn’t mention them being Torx screws, and the fact that the other two bolts on the same part were both Phillips.   Grrr.

But it was pretty easy going from there.  I took off the cover housing, and revealed the foam encasing the battery.   Pulling the front piece did snap part of it off, but a little glue will restore it to good condition, and I got the battery out.

I say “battery” but it is in fact two 12V batteries mounted back to back and jumped in series to form one 24V pack.  I got out my trusty multimeter, and found that the total voltage was around 12.5V for both cells, or about 6.5V each.   I removed the strap that connected the two batteries so that I had them separated, and used my little 12V charger on one half.  I also wired in a small LED voltmeter across them.  It read about 11.2V.

Twelve hours later, it was about 11.3V.  I took off the charger, and the voltage immediately sagged and the LED volt meter went out.  Using my multimeter, it showed about 5v.

I proclaimed the batteries dead, and went inside to find out how much it would cost to replace them.    Our local Batteries+Bulbs seemed like they stocked a Duracell Ultra replacement, but they were $80 for each, resulting in a replacement cost north of $150, which seemed like a lot.  Amazon would ship me a pair of MightyMax batteries that would serve as a replacement for just $75.  I’ve been using a Mighty Max as the power source for my solar energy project, and they seemed to work just fine.  So, I placed my order and am awaiting the shipment.

So, while I’m waiting, I went back to thinking about Torx screws.   I stripped one of the heads pretty well trying to motor it out with the Phillips, so I thought I should replace it.  The question is should I replace it with Torx or Phillips?

See, while I grumble at Torx screws, I do basically admit to their fundamental superiority.    Let’s face it, Phillips heads suck.  They are actually designed to cam out as part of a crude form of torque limiting.  This wouldn’t be bad if either the screws or the screw drivers you used were tough enough to handle this ill-treatment without mangling themselves.  This is simply not the case with crappy zinc-pot-metal-lowest-bidder fasteners.  They are really easy to mangle, and if you think that you might have to undo and redo them, it’s possible for you to end up with a bout of swearing.   I hate regular hex key screws (such as seem prevalent in 3D printers) for much the same reason: in small sizes they simply are too easy to strip.

Torx screws are simply engineered better.   They are designed not
to cam out, and thus are much harder to strip.   That alone means I should like them.

But I hate that the mower uses a mix of the two.  So, the question of the day is: Should I replace all the screws I took out with Torx, replace them all with Phillips, or leave them with the odd mix that I found?

Feel free to leave your comments in, well, the comments.

Found Item: Kodak Aero-Ektar Lens

It’s not uncommon for me to find unusual, nerdy objects while cleaning or organizing.  I’m a bit of an eclectic pack rat, and have all sorts of weird objects, and some I literally have placed on shelves and forgotten about.  Since I am trying to tidy up my garage work area, I’ve been finding objects wich I haven’t seen in quite a while, and I thought that I would share some of them with you.  Perhaps this will become a new feature on my blog.

Today’s found item is a Kodak Aero-Ektar lens.  I snapped a couple of quick pictures:


The lens itself, with lens cap on, with the accompanying khaki colored storage can.

The lens itself, which is perhaps the most common sort, a 178mm f:2.5. 

The Aero-Ektar was one of Kodak’s crown jewels in lens design, and was covered by a 1941 Patent by George Aklin, which gives a lot of details about its design.

US2343627Download

Several versions of this lens were made, including a 12″ focal length.  This one is the most common design, the 7″ focal length with a weight of around 3.2 pounds.  It’s quite a chunky piece of glass.  They were originally designed for aerial reconnaissance.   I was trying to find a serial number on mine, but other than a few hand scratched numbers on the lens, was not able to find mine.  I found Michael Briggs’ site which proved to be pretty interesting and informative.  Most notably, it pointed to the fact that these lenses included the use of thoriated glass (glass that includes Thorium) and thus they are radioactive.  Apparently it is common for such lenses to darken to a brownish color over time, and shining a bright light back through this lens does show that at least one of the inner elements shows the telltale faint brown color.

I guess I will be storing this in a can in the far side of the garage.  I’m not especially concerned for all the reasons mentioned on Briggs’ site, but neither am I going to stash it underneath my pillow.

I don’t have any gear to actually measure any of the radiation coming from this gadget.   If any of my hacker/geek friends do, and happen to be in the area please let me know: I’d love to have the lens measured. 

I’ve no real plans for this.  I offered it to a colleague who does a lot of interesting camera work, but (naturally) he already has one.  They apparently bring a fairly good price on Ebay, so I could convert this one into additional monies for other projects.  But it is an interesting artifact, and adapting it for a home made camera could be interesting, and would give a lot better images than my previous foamcore camera attempts.  Anybody have any ideas?  Any lens hackers interested in having this interesting bit of optical history?

Stay tuned for another episode of Found Item.

Addendum: I was an idiot, the serial number is right on the front: EM11794.  The EM code means the lens was manufactured in 1943.

How not to code an simple IOT sensor, and a new task list.

This weekend I mostly did work on further organization and cleaning of my garage workshop.  This included taking out the old dog door and cutting a plywood cover to block it up, putting up a monitor mount so I could hang a new $80 22″ HDTV that I could use as a monitor, and then some general cleaning and organization of four shelving units.  

But as I finished, I thought I would go back and try to understand the issue with my solar project.  When I had taken it in from the outdoor location, it seemed to go off line, and no longer connected to the Adafruit IO service that I have been using.  I suspected that I knew what the issue was, but today was first time that I could sit down and actually debug it.

The problem arises because of the haphazard way I cobbled together the code that runs on the ESP8266 module.   It begins (in its Arduino setup() function) by probing for the existence of all of the I2C sensor modules that are installed.  When I first coded this up, I wanted it to check just so I could be sure that the peripherals where installed and accessible via the bus.  Thus, if it didn’t detect the peripheral, it printed a warning message and then entered a dead loop, where the watchdog timer would force a reset.

Of course, when the module is deployed in the garden, this isn’t especially useful.  As I coded it, the check occurs even before the WiFi network is initialized, so no message gets sent.  This also prevents the system from being able to be reflashed with an OTA update.  Not a good state of affairs.

This was the state when I sat down at the workbench today.   I could have simply hooked the ESP8266 module up via the USB to my laptop and worked on debugging it that way, but I had a new technique available, so I decided to use it.   I had a second module programmed with the esp-link software (as I described in a previous posting)  so I was able to monitor the boot messages.

What I discovered was that the MCP9808 temperature module was not being found by the I2C bus probe.  To help with debugging, I decided to write some code that would try to probe all available I2C addresses, and print out a nice table of all the peripherals it found.

What it revealed was that the MCP9808 was actually being detected at address 0x19, whereas the default location was 0x18.  The module does have three address pins to allow you to change its address, but according to the schematic, it has resistors in place that should pull the address low.

I’m was confused why it was acting as if A0 is pulled high, but I decided to just install a jumper to tie it to ground.  And, boom!  Booted right up and started to log data again for the first time in a week.

So, it’s working (after a fashion) but it does spawn a bunch of new tasks for me to work on for the next few days.

  • First, why did I need to tie the address pins explicitly low?  Never seemed to have to do that before.   It puzzles me, and I’d like to resolve it.
  • Rewrite the application.  In fact, I’ve already begun on this.  The biggest change is that it’s much more forgiving about the absence of peripherals that it expects to find.  Notably, it connects to the WiFi network first, and only then does it start to probe the I2C network and take telemetry measurements.  It’s also careful to ensure to process messages related to the Over The Air (OTA) updates, so that if I do need to update the software, it will be listening for the updates.
  • And while we are at it, I think it’s time to stop using Adafruit IO’s MQTT server.  It’s a good, quick and easy way to get started, and allows you to setup a quick dashboard, but there are a number of problems that make it less than ideal.   In particular, it doesn’t support retained messages properly, either in the client side or on the server.  I have installed the mosquitto server, and will eventually move to that instead.  I have decided to shift to the PubSubClient library which also appears to work with SSL and provides the retained message support that I like.
  • The current version is rather overactive: it records telemetry once a minute and pushes it to the servers.  In between, it’s running, just busywait-ing in a loop, on the off chance that it receives a request to update its firmware.   The new version should update telemetry at a longer interval, and use deepsleep to lower its power requirements in between.
  • The current version of the software is one-directional: it just sends telemetry to the broker.  But MQTT is a bidirectional protocol, and it can receive information from the broker as well.   I’ve tested this a bit, and envision it be able to send new configuration messages to the sensor.
  • In particular, we can use retained messages to set the “mode” of the sensor.   When the sensor wakes up, it will receive a retained message from the broker indicating what mode it should be in.  If it is in battery saving mode, it does a read of all its sensors, sends them to the broker and then goes to deep sleep to save energy.  If the mode was “wait for update”, then it can enter a loop where it stays alive, waiting for a firmware update.

That’s about it for now.  Stay tuned for more (and eventually code on github). 

Jeri demonstrates some interesting polarization phenomena…

I’ve been interested in optics for many years, ever since I started building my own telescopes at age 11 and began writing ray-tracing software in my early twenties.  But one thing that I haven’t experimented with too much is polarization, probably because my self-educated view of light is mostly in the form of little billiard balls called photons, and understanding polarization requires understanding quantum mechanics, and while I’m not completely ignorant of that stuff, I must admit it seems mostly baffling, and haven’t worked hard to figure it out since modeling polarization in computer graphics has been (mostly) of limited utility.

So, I found Jeri’s video pretty cool.  She demonstrates a type of optical device that I’d never seen before, which is always cool.  Check it out.

As a tiny bit of value added, I thought I’d add a video demonstrating a polarization effect shattered my early feeling that I understood what polarization worked: the three polarizer experiment.  A little YouTube by minutephysics has a nice video demonstration of the effect and uses it to introduce Bell’s theorem: