thouton

Andrew's Blog

Monthly Archives: December 2010

Spindleumen

Ever since I saw the “Death Calls the Tune” project by Lab Binaer (via Make and Hack a day)  have wanted to get in on the Phosphorescent screen coolness. As luck had it a broken record player showed up in the local pawn shop (someone had torn out the needle assembly, also damaging the USB/sound board). For the princely sum of £1 I was thus the new owner of a skytek tec-3100.

Note: I know the images show the text on the screen to be illegible, I cannot capture with my camera a decent photograph of the screen. Please take my word that it is much more readable in person than the images would seem to indicate.

Witchcraft!

It doesn’t work by witchcraft, in fact the principle is very simple. Glow in the dark paint (I’ll just call it glow paint) reacts to UV, effectively UV light will “charge” glow paint. When given a very brief flash of UV the paint persists in glowing for a few seconds but the brightness rapidly dwindles. By placing an array of UV LED’s above a moving sheet of glow in the dark material we can draw images and text. Since the paint is brittle the object it is painted on cannot be allowed to warp (or else the paint will eventually flake off), which means that we can either use a spinning disk or other spinning shape that is symmetric about a plane of rotation (like cylinders and cones). A disk is by far the easiest method of achieving the desired effect, and record players already spin disks at a slow steady rate – quietly and very reliably. I decided to use the felt “under mat” that came with the device as the canvas for the paint, largely because the thought of ruining a perfectly good record might upset someone.

Build

Internally tec-3100 was impressive. Control for the stylus arm was all run from a central wheel which had groves that would actuate the movement of the reading arm with a series of control rods, a truly lovely piece of engineering (as you might be able to tell I love smart design like this). Despite the use of USB and micro controllers the stylus arm control was done by mechanical computer to presumably keep costs down. Unfortunately since all this was useless to me I stripped out all of the control rods leaving just the table rotating motor, the power supply and the front switch for speed selection. Happily the damaged USB/sound circuit board was only connected for power (~12v) to the separate “power board” and was removed without fuss.

Movement of the stylus arm is controlled by a tiny (and cheap) servo motor, unit price was roughly £5. Since I cleared out all the control rods and gears there were plenty of mount points for the servo. The connector between the servo horn and the record arm is actually a wooden skewer (with the point cut off). I found that this gave a certain amount of flex that would reduce the stress caused by fast movements of the servo (also it is a nice and cheap, replaceable point of failure in case the arm is subjected to undue stress).

The build went exceptionally smoothly; there are 4 small circuit boards that I had to make, largely because this modular approach allowed me to breadboard and test everything was working board by board. But also because the number and spacing of screw pegs inside the device, and the awkward crevices and nooks lent itself to this approach too. The boards are;

  • Power regulator for servo (12v to 5v)
  • Shift register and connector for LED’s
  • Main board containing an Attiny2313
  • USB board (cobbled together from the original USB connector from the audio board and a USB to Serial converter (Nokia USB connector))

I realised fairly early on that there would simply not be room in the flash of the attiny2313 to contain all the data necessary to render a 8 by 5 fixed width font (and currently I do not have any Atmega devices to hand.). So this data is piped over the serial connection. As a bonus this means font can be dynamically switched if necessary. As a bonus bonus the font does not have to be fixed width. As a bonus bonus bonus you can handle symbols and icons, the only constraint is that the height is limited to 8 pixels. All in all I would say the draw backs with this design are that;

  • The screen is always tethered to a PC (i.e. as-is it cannot operate as a stand alone device)
  • The serial channel constrains the output speed. Resultantly the code is a little messy (with many Thread.sleep(500) calls waiting for a response)

The general principle is that the device operates in one of three modes; output to stylus, move stylus and command mode. In command mode the device waits for a new mode to be given via serial. In Stylus write mode the device outputs every character given to it over serial (if it gets a zero then it clears the output and enters command mode). In Stylus move mode the stylus is moved to any position (0..255) and then returns to command mode. The Stylus movement is limited in software to stop the servo pushing too far and breaking something. Since the “mode” is echoed back over serial the computer can tell if something has gone wrong with the modes and endeavour to fix it. As a side note, more modes can be added if needed with minimal fuss, a provision that may be useful if switching to a more capable platform like an atmega series device.

The computer side “device manager” program reads a “font file” (an XML file with definitions for each character)  then connects to the screen and sends instructions to move and write. This device manager is itself connected to by a socket. This allows anyone on the local network to put messages on the screen via the socket. Currently the only functionality is to write text to the screen, and the screen manager moves the cursor and handles font conversions. The current implementation is a proof of concept, I expect to make continuing modifications (see Future section) to bring it up to a release standard.

Result

I’m fairly happy with the result. I would have been happier with access to SMD UV LEDs (alphabet soup!) but the 5 mil LEDs have worked fairly well. I have now realised that the “Death Calls The Tune” project have a very slow rotation on the platform. Currently my implementation is readable but it could be better, and it is certainly not as readable as the project that inspired it. I have no idea how to slow the motor down further, I have hacked the motor to run much slower than it’s default speeds, however it is still marginally too fast. I suspect that limiting the voltage available to it may do the trick. The motor is not a standard stepper/DC motor it appears to have an internal speed controller designed specifically for record players (lowering the voltage may cause it to fail and the motor to stop entirely). I may have to replace the motor, which is a shame but not undo-able.

With all this said the first time the display printed “hello world” I was on top of the world, and I am very happy with the project. Currently I am working on bringing the computer side interface up to scratch, but aesthetically the project is pretty much there, apart from exceptions noted in the “Future” section. The clarity of phrases is limited and the most legible “ring” is the middle ring, the inner ring text is a little warped by being so close to the point of rotation. Conversely, outer ring text is barely distorted at all, but the speed that the table rotates at means you need to be a fast reader. The latter could be mitigated by reducing the table rotation speed, the former by reducing the LED size. The trick to reading the outer ring appears to be to let your eye’s natural reading “skip” reflex to take over and track the words…this is somewhat disconcerting at first and it is easy to fall behind and miss words.

Future

I plan to make some further hardware and software updates;

  • SMD LEDs instead of the 5mil LEDs currently used, possibly using more than 8 on the write head to allow a greater clarity and number of fonts (16 SMD LED’s could fit in the space of 8 5mil LEDs)
  • More functionality, like text output that spirals in or out of the disk, a graphic bar chart style output, a seismograph style output, etc.
  • Attiny bootloader (including breaking out the rst line from the USB to Serial) or
  • Move to atmega series and store character rendering data in flash.
  • Release code and plans for others to work with (preferably polishing the project a little more before this stage)
  • Move to a direct network connection, negating the need for USB and a supporting computer. (Serial connection maintained for extensibility purposes). Probably by means of a wiznet chip/board.

Finally

If anybody wants to do something similar I would be more than happy to help, swap notes and so on. I’m happy to share the code with individuals, however until the project reaches v1.0 stage I can’t say it would be reliable or indeed very good, so I wont release publicly until I am happy with stability and extensibility. The source and any designs still need some tidying. In short the project needs a little more work before I sign my name to the designs, so to speak. Please check back to my blog for updates, source releases and new info.

Advertisements