Reinventing the mail chime:
I honestly thought this was a novel idea until the project was about
90% complete. That is when a Google search found more than a few
attractively packaged consumer products that do the same thing,
probably better, and definitely cheaper. But where’s the fun in buying
something if you can make it yourself for twice the cost, and there’s a
outside chance it will work.
Alex (DD5ZZ) sent us a pair of RF24
development kits that he had designed—He calls them ZZduinos. Each
integrated kit includes two MPU’s: ATmega328PU and ATtiny, an RF24
module, a small OLED, power and I/O headers, and multiple test buttons
and switches for prototyping applications. After assembling the kits we
ran a test sketch to demonstrate 2.4 GHz communication between them,
and walked one of the units about a block from the house before losing
contact. Their potential was obvious, but for what? We knocked around one or
two ideas, and
then set the units aside.
An idea that recurred from time to time was mail delivery notification.
Our mail delivery time is highly variable, from late morning to late
afternoon. Obviously it is desirable to retrieve QSLs from the mailbox
as quickly as possible, so that they don’t
rot. Thus it happened that one Saturday we went shopping for a mailbox to
play with. The idea was to put the mailbox in one room with a
transmitter, and have the receiver in another room. In that way we could
try out whatever was needed to make the scheme work. We purchased the
least expensive mailbox we could find (pictured), at $19.95 from
Home Depot. Our previous mailbox was metal. This one is plastic, but
that is good because plastic is essentially transparent to the
We first thought of using a motion sensor to
detect the mailbox door opening and closing—one of these was left over
from another project. This worked well enough for detecting changes
in the mailbox door’s state, but we wanted the circuit to report the
door’s current state (open or closed) unambiguously, and for this a
magnetic switch worked better. Switch wires were routed to the ZZduino
along a groove in the top of the box and secured with Scotch 88
Electronic components were housed in a plastic project box and affixed
to the back bottom of a mailbox-shaped wooden cutout using Velcro. This
wooden piece was painted black, making a false back for the mailbox. To
pull it out easily we put a large screw in the middle—yes I know the
screw should also have been painted black.
To reduce drain on the 4.2 volt battery pack we removed the OLED and secondary MPU on the mailbox end.
The ZZduino has selectable clock speeds, 4, 8, and 16 MHz. Normally it
would be set to run at the highest frequency, but again to conserve
battery a lower clock speed was selected. We made no provision for
charging or monitoring the battery during initial field testing. Once
inside testing was complete, the mailbox was deployed to the street (on
a Friday). Nine days later we pulled the electronics to check the
battery level. It had dropped to 3.2 volts, an unacceptably low level.
Without provision for charging, it would be necessary to service the
battery pack weekly.
We had a small 12 volt solar panel on hand
that had been used to charge a motorcycle battery that was in turn used
to power a QRP transceiver. Without calculating anything we decided to
try this solar panel with the mailbox battery. First an LM7805 dropped
the voltage to 5 volts. From there a TP4056 charge regulator connects
to the battery pack, supplying the 4.2 volt charge during daylight
hours. We also added a battery voltage monitor feature at the same time as the solar charger was deployed. Whenever the mailbox was opened or closed it would report current battery voltage.
So far I have described only the mailbox end, the more challenging
part. The receiver inside the house does not need a solar panel as it
can be powered from a wall brick. However, to make things interesting I
decided to interface a real time clock. In that way we could see not
only that mail was delivered, but also the time of delivery.
The Arduino tone() function was used to generate an audible
notification. A pair of brief ascending pitches indicated ‘open’ and
descending pitches indicated closure. This idea was cribbed from the
Four State QRP Group Hilltopper kit MPU code, where these two-tone
sequences are referred to as boobeep and beeboop. Electrically the tone
pin connects to the speaker through an electrolytic capacitor, without
filtering or amplification. Finally, timestamped notifications are
stored to EEPROM. There is no particular reason for this—just because
The cell phone camera does not capture a sharp image of the small OLED
screen display. However, the zoomed image left is readable. The date
and 24-hour time of last delivery are shown on rows 3 and 4, and
battery voltage is reported at the lower right. This example reading
followed 5 days deployment, including two mostly sunny days. It appears
that the charging scheme will be adequate for southeastern US winters,
though no good for the Arctic circle or Germany.
The accompanying Arduino sketch
includes code for both transmitter (mailbox) and receiver (house). The
first declared constant at the top of the program determines whether
the sketch behaves as transmitter or receiver. If MASTER = true it is
the receiver and if MASTER = false it is the transmitter. An
appropriate value must be set before loading the sketch to one
controller or the other.
on this page are intended for entertainment only.
The author makes no claim as to the accuracy or completeness of the
information presented. In no event will the author be liable for any
damages, lost effort, inability to carry out a similar project, or
to reproduce a claimed result, or anything else relating to a decision
use the information on this page.