Engineering (20)


Upcoming Talk – Serial Communications

I’m currently slated to present a talk at the CSLU (Lancaster University’s Computing Society) on serial communications with micro-controllers.

In addition to the talk, there will be a lab session where we will be working on a simple, practical communication scheme using Arduino micro-controllers and these beauties:

11 RS-485 Shields for the Arduino

Arduino RS-485 Shields for the Arduino

All ready to solder up, when I have the stacking headers that is – shipping from Hong Kong takes way to long!

I’ll update when I have more information about the talk, and after the fact will update the ‘Talks’ page on here with the slides, should anyone want to follow along.




At the controls of tram engine…

Took a quick video with me at the controls of the tram engine my Dad and I built some time ago.

I never reach anywhere near the top speed for the tram, as it has about a horsepower crammed into it’s comparatively small frame.

The track is 1240ft long and is 5″ gauge.

Those of you who know me might have seen the signal control unit I’ve been putting together for this track (not shown here, as the signals were already put away) and this was a full speed run to test the reed-switch based sensors in the track.




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.




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…




Malloc

Interesting…

Allocation and Deallocation Times for Varying Size Chunks

Black-box profiling the Linux memory manager




OS Development

I’m working on a hobby OS to keep my C skills sharp, I’ll document stuff about it here when I remember

Progress

So far, I have a bootable kernel, with ISRs, IRQs, working, no memory manager yet, and no multitasking!

Grub on my bootable ISO

Grub on my bootable ISO




SCMES Track Signals – Track Sensors

My intention is to use reed switches for the track sensors, as they fit the needs of ‘non contact’ and ‘cheap’ (ish).

This method only requires a magnet to be fitted to the riding trucks, leaving them electronics (and complication) free. Furthermore, should a guest driver wish to use the track, they can either use one of the club riding trucks, or simply attach a magnet to their own in the appropriate place.

The innards of a riding truck

The riding trucks have this central bracing, providing a nice mount point for our magnets on the underside!

On the subject of the club riding trucks, and the ‘appropriate place’ – mounting the magnets on the trucks should be fairly simple, as they are constructed mainly from mild steel (and thus, magnetic!) so magnets can be stuck anywhere flat on the underside of the truck giving great freedom with regards to fine tuning.

The track sensors themselves will be simple reed switches arranged in parallel such that any switch action will cause an input on the microcontroller to be pulled low.

These ‘sensor bars’ are to be mounted on the inside of the outermost rail (The left-most rail in the image here) as this is where the origonal sensors (microswitches) were mounted by means of bolts through said rail, thus we can re-use the mountings as they were left.

I’m going to write another post covering the design of the `sensor bar’s once I have drawn up the schematics.




SCMES Track Signals

I’m currently designing and building an electronic signalling system for the South Cheshire Model Engineering Society.

A view across the track site

The Track Site

This consists of a set of 10, 3 aspect (red, amber and green) signals to control and 10 track sensors (the nature of which is to be determined) as well as 3 other special-case sensors (two on traverser locking mechanisms, and one station master switch).

The original system was based around a control unit which worked on digital relays and used 36V lamps.
Unfortunately the designer was involved in a car accident and died, leaving the system unfinished, and futhermore, the method of detecting a locomotive passing a signal (microswitches on plates in the track) resulted a far-too-short pulse length to actually trigger the relays.

This left the system in an unfinished state for several years, during which I finished my degree, and now I have time to work on the project.

A development signal's internals

The three high-brightness LEDs inside the head of a signal

The first order of business would be to determine what the control unit is required to drive, in this case high brightness LEDs are used for each aspect, and, although my development unit had a dead red LED, the LEDs could easily be powered by a simple 6v source (in my case, AAA batteries, as can be seen in the larger image).

The LEDs are more than bright enough to be seen far away, so will be acceptable as lamp replacements.

A signal showing all lights on, except red is broken

They're bright (shot taken from an angle to see anything at all!) except for red, in this case!