Gary Baluha wrote: > On Dec 27, 2007 10:41 PM, Douglas A. Tutty <[EMAIL PROTECTED]> wrote: > >> 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.
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 slot cut in it" donation box. >> You could have a "Please wait" light to be lit during the reboot. 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 mess, I'd rather just avoid the mess. :) >> 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). >> > 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, 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 sound file..note the use of the plural "files" in my original posting. I actually considered doing something like the old DuKane filmstrip projectors did, embed a tone in the file, detect the tone, filter it out at the amp. Detect money? Press play. Hear tone? press Pause. That makes creating/editing/revising the sound files got a lot more complex, so it would no longer be owner-maintainable. As it is, 1/3 of the storage device (I'm not gonna use the 'f' word here, as people apparently keyed off it and have been answering questions I didn't ask, so just pretend it is a little, slow disk) is a DOS FAT partition, so someone (anyone!) could remove the storage device, plug it into their Windows computer, and add, remove, replace, or re-order the message files. (I've also set it up that if someone plugs a USB storage device in at boot, it uses that for sound files rather than the "on-board" files.) I can assure those who thought I jumped to an OpenBSD-based computer as my first choice for the design are very wrong. A lot of brainstorming took place. Considerations included cost, parts availability, long term maintainability, development ease, field maintenance, etc. I'm pretty thorough and pretty creative in my designs, and quite aware of the "When all you have is a hammer, all the world looks like a nail". Using a computer for this app sucks, but not as badly as the alternatives that I could think of. About the only compromise I took that I really didn't like was not using the parallel port for the input on the thing. I wasn't having much luck doing that when the idea of using a mouse as an input device was suggested to me by the artist I'm working with. My first thought was, "that's crazy", but then I realized I could simply hack wsmoused to execute a program whenever the mouse is clicked, and ta-da, we got ourselves a solution. I don't think I spent more than a couple hours doing that before I had a demonstrator program running. When I got the opportunity to get the iPaq desktops, I grabbed one, flipped it over, saw PS/2, parallel and serial ports, figured "That's it!", and grabbed twenty of the things. You can see where I'm going: I kid you not, the one I grabbed was the ONLY one with PS/2, parallel and serial, the rest were all "legacy free". Suddenly, the mouse-as-input-device didn't seem anywhere near so stupid. :) > even if it is something as simple as a Soekris ( > http://www.soekris.com/, which by the way, is a very nice device). In spite of being everyone's favorite hammer, they are completely wrong for this nail. I knew when I posted this someone was going to suggest a NETWORK device for a COMPLETELY NON-NETWORK application. In fact, the point of the question is the "no-network". NOT the fact that I'm using flash, which everyone seems to want to dwell on. I don't need three network ports, I need a sound interface. Not sure how well the Soekris boxes would power a generic sound card, I've not heard great things about their power systems. Not sure how many sound cards would be happy in on the 3.3v-only PCI bus. I also suspect the power draw on a sound card bounces around a lot, and might do unpleasant things to the stability of a system with a marginal power supply like the Soekris, but that's just speculation (the Soekris 4501 boards I have don't have the PCI slot, so not easy to test) If something goes wrong in the field, the people near the machine will be much more likely to be able to put a monitor and keyboard on it than they will be able to put a serial terminal. Then there is the cost factor. Even using mostly free hardware, I'll be lucky if I cover my costs on this. Adding the price of a new computer makes this a losing game for me. Soekris's aren't free. On the other hand, the stash of Compaq iPaqs I came across recently have built-in sound, a very capable built-in speaker, nearly silent in operation and are easy for Joe Average to understand. We've got enough we could even ship out a spare with the system for spare parts. > 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. But..you aren't doing it, your use is very different than what I am asking about, so can you say that for sure? I've set up literally hundreds of installs like yours. I feel this is different. (as it was, I found some "churn" in the /var/spool/clientmqueue directory that surprised me, as it was AFTER I thought I had killed sendmail, both in rc.conf and in cron, but I may have forgot to reboot after that. Something to keep an eye on) > 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. well, I really don't want to make the thing entirely read-only. You see, this machine isn't just the runtime environment, it is also where I did most of the development. Why not? The thing can compile the primary program in about five seconds (a slightly hacked wsmoused), and the rest is just shell scripts. Yes, the entire basic OpenBSD install is there, compiler, man pages, everything 'cept for X and games. Will the owner ever use it? Probably not. But they could if they wish to. OR, we can if WE wish to when the thing is delivered and they say, "But, we want it to do ..." without having to go hunt for a "development environment". In OpenBSD style, the thing is not only the production device, but also the development environment. It's completely free-standing (and completely network free, the network cable hasn't been attached since initial install). What I have done this evening is moved /var to an mfs, which is pre-populated from /var.template (which is RW). So, now I can (and did) manually create a locate(1) database, copy it to /var.template/db, and upon reboot, it's usable. (mount_mfs(8), see -P option), or easily make other changes as desired/needed. In case anyone is wondering, the power consumption of the thing is about 21W idle, 35W while booting, and 22-27W while playing an mp3 file (most of that seems to be the audio itself, at reasonable home volumes, it's 22W, at full volume, 27W). Not bad. Nick.
