I've got a little project I'm working on here.
It involves stuffing a computer in a donation box with a
money detector, so every time someone tosses money in the box,
it plays an MP3 file.

(no, you can't make a living at this.  At least, *I* can't)

The first two of these I did were many years ago, and we used a
486 running a simple DOS app.  Well, computers that run DOS well
are gone, and trying to bring up a new program to play sound
files on any of the modern sound chips would be (not) fun...and
annoying the next time the hardware all changes again.

So, for this generation, I'm using OpenBSD, mpg321, and a 1G
CF flash device attached to an CF-> IDE interface.

However, this is the first time I've ever done an OpenBSD system
that wasn't going to be attached to some kind of network for
(hopefully) years at a time.  In fact, hopefully, it will NEVER
be attached to a network.  And, while I got a 1G CF device, I
could imagine doing something stupid and having it slowly fill
the CF media and six months from now getting a call saying, "It
died.  Come fix it", and since it will be in another country and
probably a ten hour drive away, I'd like to avoid that. :)
Once this thing is deployed, I won't have access to it at all,
so I'll have no ability to spot a potential problem or fix it.

SO, to try to keep things quiet, I've disabled the daily, weekly,
and monthly scripts, I've disabled sendmail in /etc/rc.conf.local.
Before I ship it out, I'll move /var/log and /var/tmp to point to
a mfs system, so hopefully, if something starts logging, a power
cycle will dump everything.  Only 60M is mounted RW, so it fsck's
very quickly, and my app writes only to the MFS.

What have I forgotten?  Is there anything else I can do to avoid
slapping my forehead and saying, "D'oh! Forgot to ..." before I
ship it out fully detached?  The good news is I'm pretty sure
there is at least one OpenBSD developer near-by, but that's just
all the more reason to make sure I don't screw it up, I'll never
l...
[ message continues ]

step 1.  get a any old ipod on ebay
step 2. put a single mp3 tune on it
step 3. place it in a big box, with the play button located right  
under a coin sized slot


openbsd is great, but it's not the hammer for all nails...

/Pete

Why mount any CF partition RW?  And you should be able to test your 
system on a CD to prove it'll work without writing.

A noob-ish question/observation... since the mfs could eventually fill, 
why not point potential logs at /dev/null instead?

I'd wire in a hardware-type heartbeat detector that will power-cycle the
computer if it stops working.  I'd have a door over the money slot
powered by the computer so that it only accepts money when its working.
You could have a "Please wait" light to be lit during the reboot.

Or, you could just rewire an MP3 player to play a tune when it is
powered on, then just hook the money-detector to the power switch.
Money turns it on, a timer just longer than the tune turns it off.  No
computer needed (just a 556-dual-555 timer IC and some spare parts).

What about a built-in modem set up to allow a login.  Then if something
_does_ go wrong, you can ask the user to provide a phone line to the box
and you with the phone number.  With this, you can fix or even upgrade
the box over the phone.  Add a hardware cycle-counter; if the heartbeat
causes a reboot and the cycle counter doesn't get reset, it lights a
"please call for service" light.

Doug.

I second the idea of something as simple as an MP3 player connected to a
money detector, if that's all it will be doing.  Seems a little over-kill to
get a whole computer, even if it is something as simple as a Soekris (
http://www.soekris.com/, which by the way, is a very nice device).

However, if you do decide you still want an embedded OBSD device, it
certainly is doable.  I have a Soekris net4801 that I am using as my
firewall/router, and it is working like an appliance.  I'm using a 1GB CF
card; it's mounted RW, but for the most part it is really only writing data
to an mfs mount point.  In this case, it's obviously connected to a network,
and I have a monitoring tool running to report back on disk space usage, but
it could easily do without this.

I have a cron job that periodically checks to make sure the mfs mount points
don't fill up, and cleans them out as appropriately.  I have also highly
tuned the log rotation to further ensure mount points don't get filled out.

Should a problem arise, since the CF card is effectively read-only, a reboot
is as simple and unplugging the device and then plugging it back in.  Unless
there is a hardware fault, it will come back up on its own.  For further
protection, you should mount the CF read-only so no mount points there can
accidentally fill up.

uh, the point is to get their money.  The fact that it does something in
return is just a bonus.  It might prompt them to say, "Hey, did that
just talk to me??" and they stick another coin in to find out.  At that
point, it says something different, and by now, the kids all want in on
it.  Soon enough, a dollar or two worth of coins has just gone down the
toad's mouth.  "Failure" mode should still to be accept the first coin,
not reject it.  Not desired, sure, but no worse than the cookie jar
collection box.  We've done a couple others of these things, the owners
tell us they do considerably better than just the traditional "can with

This is precisely why I asked this question, to make sure this doesn't
happen.  While having a self-cleaning mess beats having a persistent

Getting an off-the-shelf MP3 player to play one sound file is not too
difficult.  Ah, heck, a tape loop would work fine, too.

Getting it to play one of a pile of different sound files, not trivial.

That idea was considered, but the reverse engineering of the things would
be very difficult, both because they are mostly "sealed blobs" and anything
developed on Model X would have to be repeated next year, when Model X is
discontinued, and model Y is out.  Further, while at my peak, I could
solder a 16 pin IC with a 400W unregulated soldering gun in about five
seconds (and make it work!) (for those not into soldering, that's way too
big a soldering tool and way too fast), I'm a bit out of practice, and I'm
not even sure I could see what I was soldering on with a modern MP3 player.
They aren't designed for hacking.

One would have to come up with a way to sequence the buttons on the thing
to play one sound file, detect the end of the sound file, stop the play back,
then resume the playback on the next sound file...ick.  If it isn't obvious,
the files WILL be of wildly differing lengths, some a couple seconds, some
maybe close to a minute long.  I have no idea why so many people assumed it
would play back only ONE...
[ message continues ]

There are commercial "MP3 modules" which are designed to do exactly
what you are looking for, one example:
     http://www.hobbyengineering.com/H2168.html

By itself, the "uMP3 Playback Module" has 8 inputs, pulling any of the
8 inputs low plays back the associated MP3 file from a FAT filesystem

With some help from a PIC (e.g. Basic STAMP), this could be made to
play random sounds for each coin.

While the uMP3 hardware has changed slightly over the past couple of
years, the electrical and logical interface has remained stable, as
has the price, at around US$100/ea, with substantial discounts for
larger quantities.

Kevin

Is that one of the handheld Windows Mobile devices, or one of the "thin 
client" things they used to sell?

Apparently, Compaq likes to (surprise) reuse product names.
http://www.cl.cam.ac.uk/~pb22/iPAQ/10638_na.html

It's a full i386 computer, though free of expansion slots or 5.25" drive
bays.  It has provisions for a laptop-style CDROM drive (only two of the
20 machines had that), no floppy, unless you got one for the CDROM bay.
i810 chipset.  Celeron 500MHz, though apparently other things can go
in them.  Other than the bottom, not a flat surface on them, which makes
them very difficult to handle, store, stack or relocate.  In fact, while
they are small and light enough that I should be able to carry probably
four or five at a time, the awkward shape pretty well limits it to two
at a time, as there is just nothing to hold onto (and even picking the
two up is a challenge).

However, the form is not at all bad for our project.

HW-wise, it's very solid OpenBSD-compatible stuff, and seems to work
well.  It's got classic annoying Compaq quirks (it wants a keyboard),
but they are able to be worked around.

Interesting test (even more off-topic than the rest, but...)
  With JUST the flash drive, idle OpenBSD power draw was about 21W.
  With added HD, idle OpenBSD power draw was about 26W
  With bc soaking all available processor time, power was up to 44W.
(and you thought those distributed computing projects were "free"...)
(my Wattmeter reads only to the nearest 1W, so all those figures are
+/-1W on top of whatever the accuracy of the thing is.)

(the hard disk is installed on this thing so I can start imaging
and making additional flash cards on my dev system, not for
production.)

Nick.


OpenBSD 4.2-current (GENERIC) #607: Tue Dec 18 18:36:52 MST 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Celeron ("GenuineIntel" 686-class, 128KB L2 cache) 499 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem  = 132739072 (126MB)
avail mem = 120451072 (114MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIO...
[ message continues ]

I think that's what I was thinking of, at least the case looks like it. 
  I think at one point they marketed these as a "thin client" type of 

How's that compare to a Mac 68k?  I'm surprised you didn't go with one 
of those... although I suppose a SCSI flash adapter is hard to find.

With standard COTS hardware and a admittedly bug-containing OS (yes,
everyone agrees that even OpenBSD contains bugs), you cannot guarantee
that something won't happen to either cause a spontaneous reboot or to
make the device stop working causing any heartbeat monitor to force a

I didn't read your description of the issue to mean playing different

I wouldn't want to risk the root filesystem by having the device its on
be plugged into a random user's windows box.  It would make more sense
to use your CF card for the root device and provide a USB port under a
flap or something for people to mount replacement sound files.  It would
be nice if it could be ro mounted-on-insert and used with the next coin and

What was the problem having the coin detector trigger the "printer
ready" line on a parport or one of the status lines on a serial port?
Would seem to be less hacking.  Personally, I would avoid hacking the
base system (e.g. wsmoused) and instead have my program over top of
base.  Python has both a parallel and a serial module to allow accessing

I wasn't suggesting a serial terminal for use by the user.  I was
suggesting a phone jack that the user plugs in then you or another
service tech dials in to the unit from the comfort of your office.

Summary:

I still suggest a heartbeat monitor and a modem.

Good luck,

Doug.

A heartbeat monitor makes the system seriously more complicated and thus less 
reliable.

If the proposed system boots from a non writable medium (yes there are flash 
devices with a write-protect switch, CD-rom is also OK although dust 
collection on the laser detector is an issue) and works in memory, diskless!, 
unintended log events will be written to memory (that might overflow but who 
cares for this application) and the system always boots the same after power up.

+++chefren

How does that help if the computer just crashes or freezes instead of
just spontaneously rebooting?  Sure, there's the version 0.0.1 Human to
push a power button.

Presumably, one can get solid reliable RS-232C heartbeat monitors that
can trigger a power-cycle.  If not, they're not that difficult to make
assuming that you can source some reliable parts.  

I totally agree with the non-writable medium issue.

Doug.

The basic point is: Hardware should work reliably, if it isn't you have a 
broken system. Software idem.

For the situation the hearbeat monitor works, it just proves the system is 

I presume that's not the case. RS-232 is less and less available etc.

And look at the workings of your heartbeat monitor: I bet it needs a loop in 
the software that "pings" it. With software failures: Big chance that loop 
still works and thus the heartbeat monitor isn't triggered while the system as 
a whole can be considered broken. Your heartbeat monitor also needs a way to 
power-cycle the whole system. Relays? How is/are these powered? Don't forget 
for all the cables and connectors needed.

I thought this was about about reliability!!!

KISS is the usefull acronym here.

+++chefren

Even so, it still allows recovery from some serious problems without
touching the machine. There are quite a few situations where this could
be very useful, though it might not be worth the extra expense and
complexity of adding an external device, watchdog timers aren't too

In the case of the hardware Nick mentioned, there should be a watchdog
timer in the I/O controller hub (82801AA ICH); adding support for this
might be as simple as adding the device ID to /sys/dev/pci/ichwdt.c then
test by setting sysctl kern.watchdog.auto=0 and kern.watchdog.period=30
and wait 30 seconds for it to reboot. See watchdog(4) and watchdogd(8)
("man -k watchdog" gives a list of device drivers supporting watchdog
timers).

The main docs for driving the ICH* watchdog timers are here:
http://download.intel.com/design/chipsets/applnots/29227301.pdf
(also see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ichwd/
which supports 82801AA).

Put it somewhere in the main software loop.  Hook up a second trigger
off the money-detector.  The computer decides what tune to play and
plays it.  The heartbeat monitor can detect the money and listen for any

Last time I needed such a timer was about 20 years ago.  Used a mil-spec
556 TTL dual-timer IC and appropriate caps, resistor, and relay.  Fit it
inside a small box with a 110V recepticle and a power cord, and
connected with a serial cord.  Powered it right off the serial port.


Doug.

Correct me if I am wrong but I believe it was this that saved the Mars
lander from total disaster a few years ago. I heard it was due to the
brilliant idea of some Indian professor. I don't remember much about it

Watchdog is a great idea. And for embedded/real time systems it might be
inevitable and even life saving. But since I lack experience my ideas

Wow! Great!

I believe Intel gives very good documentation for everything except
wireless chipsets. ;) Theo should have more to say on this. ha ha

Many thanks Stuart.

-Girish

It's somewhat more difficult to access the hardware on the Mars lander, 
let alone replace parts.

Read this and 'CTRF-F' for watchdog.

http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html

If I remember right this made a lot of headlines few years ago.

This is not on topic but other threads don't look any good anyway.;)

-Girish