Project Logs

Collapse

• Revival

  jason.gullickson • 07/04/2017 at 11:33 • 0 comments

  Jamie & I have been talking about reviving this project, and it looks like there's a few more people interested in it now so this might be a good time to kick-off another iteration.

  The hang-up of previous designs has been the hook. It's been tough to design something that is both simple enough to work and durable enough for outdoor use. If you look at payphone designs, the hook switch is connected to a lever which goes through the face of the cabinet. I wanted to avoid this to support a flush-mount capability, but I'm learning why the original design was chosen.

  So, the next iteration will be more like a traditional payphone hook, and will be designed around an all-in-one cabinet housing the hook switch internally (as well as the electronics).

• Hook iterations

  jason.gullickson • 01/04/2016 at 15:36 • 0 comments

  I tried to improve the hook by encasing the microswitch but it worked better on-screen than IRL. Avoid using the current Tinkercad model as it is non-functional (the STL for the previous working version is available in the repository).

  I'm considering going back to OpenSCAD to design the hook as I struggle a bit with getting the precision I want out of Tinkercad. Stuff like centering one shape against another seems more difficult to me when you're dragging stuff around vs. doing it in code, but then again I'm a programmer.

  I also came to the conclusion that I'm going to design a printable box for the electronics as well. I looked for an off-the-shelf solution that met my needs and didn't find one. There's several options that will work, but for my specific application I have some size and shape requirements and the boxes I could find locally won't cut it. That's OK, because it's fun to design stuff.
  

• Leverage

  jason.gullickson • 12/19/2015 at 16:50 • 0 comments

  Trying to add a lever to the hook for a couple reasons.

  The first is that using the switch's built-in one is a bit twitchy.

  The second is that I don't like having the unprotected switch exposed, including the electrical connections. It's not really a safety thing, but if it's every used outside, they'll probably corrode, etc.

  The third is that it just looks better :)

  I'm not sure how it's going to turn out, but that's the fun of rapid prototyping. You can try something that you think *might* work, run off some parts and see first-hand what you did wrong. For me this is a huge help because it's easier to understand how things fit together with my hands than on-screen, but it would be impractical to do it this way if I was spending hours hand-fabricating parts.
  

• Catch-up

  jason.gullickson • 12/18/2015 at 14:33 • 0 comments

  So far we have a working playback system and a functional hook switch mounted to a plastic box I've used a million times. You pick up in the receiver, the audio starts to play, you hang it up, it stops.

  The plan is to mount this hook on the side of our library and anchor the cable to one of the steel posts. Nice thing about the payphone receiver is that it's very tough, and the cable has a braided steel anchor so I'm fairly confident that it will remain connected and intact even under moderate abuse.

  The hook is less durable, but that's part of why I wanted to go with a printed part. If it gets broken, or succumbs to the elements, we can just print a new one. I considered using a commercial payphone part for the hook as well, but I didn't know that they were available when we started the project, and they are a bit pricey. Also the ones I've seen would require more substantial modifications to the library (vs. just screwing the hook to the side) so for our application the custom design is better. That said you could save a lot of time with an off-the-shelf hook, and it would probably withstand more abuse, and if you don't have access to a 3D printer, that's probably the way to go.

  There's a couple of possible directions to go from here. We need to come up with a means of mounting and protecting the electronics when the system is attached to the library. The current box won't do for several reasons, but I'm not sure if we want to go with an off-the-shelf box or something custom. Custom gives us the most flexibility (and is more fun) but it's probably easier to get the durability and weather-resistance needed with an off-the-shelf part.

  The other area to explore is the "management" interface. Right now the software plays a hard-coded audio file included in the sourcecode repository when the handset is picked up. This works, but it would be cooler to have a way to easily change the file, or potentially upload several different audio files. What I'm thinking right now is having a simple web interface to list and upload files, and organize them so that one is designated as the "greeting" that will be played before every track, and then a directory containing the actual story recordings which will be cycled through each time the handset is picked up.

  The barrier with this for me is that I haven't done much webserver development in Python, and I'd prefer to stick with Python since it ships with Raspbian and performs well on the hardware. I plan to write most of the interface as an HTML5 application, but I'll need a couple of API endpoints served from the device to interact with the filesystem, etc.
  

  The obvious thing to do is to expose this interface via our regular WiFi network, but I'm considering configuring the Raspberry Pi as an access point instead. This would allow the library to function stand-alone, and would let Storyphone work and be managed even on libraries that don't have nearby Internet access. This opens the door for providing other library services via this "hotspot" like Ebooks, etc.; not unlike a Piratebox.
  

View all 4 project logs