Blog


Internet Radio – Part 3 “The clock module, preview”

The motor arrived today. I’ll put a more detailed writeup when I have more time, but I stuck the new motor on the old one’s mounts (only about 1mm difference between mounting hole distances!) and spring-loaded it in place – and… well, observe.

Sorry for the poor quality – the focus length of my camera meant that to put it on the stand made it too close to focus properly.




PCIDevices Update

  • March 7, 2012
  • C, Code, ...

Fixed some bugs in the files I posted before, and included the commented-out sections.

Again, if anyone does anything interesting with this, let me know!

PCIDevices.tar




Hamilton ‘beta’ now on the Android market

The title says it all! Grab it using the link below (select from a mobile device to automatically launch the market).

More information available here.

Available in Android Market




Internet Radio – Part 2

  • February 1, 2012
  • C, Code, ...

I said I would put some more photographs of the clock, so here we go. These were taken after the radio board and power connectors were completely removed.

The clock module is entirely mechanical, save for the constant-speed motor that ran the mechanism (now defunct, and 110v, yeesh.) but doesn’t it look nice!

The front of the clock module through the plastic cover

The dial on the left is the alarm rotor, which is a simple stepped cam triggering a microswitch on the back of the module – see the later photographs. The split-flap digits are perfect, no damage at all, and the action is smooth and constant.

The sleep timer, which rotates a cam past a second microswitch.

The Sleep timer rotates a small cam against a second switch on the top of the module. Nice! I spy an interrupt pin input!

The back of the clock module, showing the alarm microswitch and the back of the alarm display spindle

The alam rotor moves the metal arm shown on the right of the photograph above, and triggers quickly at ‘alarm time’ then slowly re-presses the arm against the switch over the course of approximately an hour, I spy another interrupt!

 

The switches along the top of the radio

The switches along the top of the radio are simple nPnT type, one with four position – the On/Off/Wake to music/Wake to alarm switch – and the other with two positions – the current AM/FM switch.

The four position switch will remain unchanged, both in function and device, but the AM/FM switch is obviously redundant now, and I will *probably* repurpose that as a stream/saved selector.

The switches actuate small plates behind the front panel with white markers in appropriate places.

The front panel includes a thin section along the top above the tuning gauge containing various basic indicators, composed of holes in the front panel with a sliding plastic indicator with white splotches at the appropriate position.

It is my intention to keep this top section intact for the final build, (as it covers the back of the switches!)  and all but two of the indicators make sense for the final build’s features.

The rest of the case is wholly uninteresting, and is mainly open space, leaving plenty of room for new electronics, and currently only contain the new power socket (a basic barrel-jack socket and two wires hot-glued in place over the existing grommet hole for power) and a medium-sized speaker with no markings (which will be investigated in a future post).

Until next time.




Internet Radio – Part 1

I recently started working on a project I’ve been meaning to do for a long time.

I listen to a lot of internet-based radio stations, mainly Shoutcast or Icecast stations, and tend (at the moment) to do this on my phone, as I can leave it on the bedside table and listen with it charging.

But the sound quality from such a tiny speaker is… well… terrible, to be honest. While phone manufacturers are getting better at building half-decent speakers into their devices, they simply cannot compete with the much better dynamic response of a larger speaker, so the want for a better device to play music arose.

Further to this, my Fiance really hates my current alarm clock, (which displays time in binary, octal, roman numerals and boring old normal decimal) due to it’s hideous alarm, and having attempted to remedy this by cracking the case to see what could be done, I gave up due to the components mainly being surface mount and resin-blob type :'(

So. Half-decent sounding clock radio, that satisfies the Fiance-test and actually wakes me up. That doesn’t exist! Time to build it then!

I’ve started with a donor clock-radio, as shown here:

The donor clock-radio, how innocent it looks here, so unsuspecting...

It has a split-flap display! Excellent! (I love these things, and miss them from stations – they had a nice self-announcing quality as the noise they made when refreshing caught everyone’s attention without being irritating… but I digress) and the large tuning area to the right is perfect for a display of some variety!

The existing electronics were dead-on-arrival, so have been discarded (I wouldn’t feel right removing working parts from a ‘vintage’ radio) along with the 240v gear motor for the split-flap display. The power cord and connector were also discarded, and replaced with a barrel-jack socket on the back (photo tomorrow) ready for the 5v mains power adapter to drive the new electronics.

The existing speaker has been kept for the moment, until I build the amplifier I won’t know how good the sound is, but it is easy to remove, and the area it covers is easily large enough (and the new electronics small enough) to support larger drivers if required.

Unfortunately I didn’t have my camera with me during the disassembly, but photographs will be taken tomorrow and appended to this post.

So… it begins.




Enumerating PCI Devices

In a fit of ‘getting stuff done’ at 6am today, I wrote a basic PCI enumeration class, allowing my research OS to display what it has found along the PCI bus.

QEMU diplaying a list of PCI devices and their respective ID's

Acinonyx Jubatus running in QEMU, displaying the connected virtual PCI devices.

The actual enumeration itself is pretty straightforward, just a bit of indirect addressing and you get a nice structure back (sequentially) with the vendor and device IDs.

The awkward part was gleaning any meaning from those – obviously I can match an ID to a driver, but it’d be nice to output some human readable stuff so that we show that specific hardware has been recognised.

VirtualBox's PCI devices enumerated in my research OS

To this end, I enlisted the help of http://www.pcidatabase.com/ which provide an open list of PCI device and vendor IDs, as well as a C header (yay!).

Except that I’m using C++, and a fairly trimmed-down version of C++ at that, with the String libraries missing (I haven’t written them yet!) so the header won’t work without modification.

Thus, after many a minute of search/replacing, I’ve altered the header into a object/header pair (to avoid linker errors) that works with a stripped-down compiler.

In case this is useful for anyone else (god knows who) I’m attaching it here – PCIDevices.tar.gz – do let me know if anyone finds any use for it! I’d love to know what for…




Hamilton

I’m getting ready to release ‘Hamilton’, a file browser for Android 3.0+ devices, and as such, have thrown together a page on it for linking.




Virtual Machine Relocation

I’ve recently relocated the virtual machine that runs the sites I host, if anyone has any trouble, can they report it to me pronto, that way I can take down the old machine sooner.

Ta!




BugDroids!

Yaaaay!




Malloc

Interesting…

Allocation and Deallocation Times for Varying Size Chunks

Black-box profiling the Linux memory manager