Redhatter (VK4MSL)

Sydney APEC Meeting Roundup

The following is a satirical piece regarding the APEC saga last week. I’m considering whether I put it in vodcast form on YouTube for our dear PM — but for now, I’ll just put the transcript up.


Well, it seems Sydney drew the short straw, and thus got the joy of almost completely shutting down while some high-brow politicians go gather to discuss trade and other issues. All this, whilst at the same time dealing with a betting industry which is sounding rather hoarse at the moment. Well, what do you expect when they shut the stable doors after the horse-flu bolted?

I must admit, I’m glad I live in Brisbane… 1000km away from all the hassles. We’re largely insulated from all the hassles playing out down south. That said, the local media has been doing a good job of letting us know what’s been happening down there.  It as been interesting to see what these politicians bring with them in their travels. Most of us, when we go abroad, we bring clothing, whatever papers, etc we need… in general, we’re careful to not pack too much. Not the United States of America it seems. The US President turned up with a 800-strong entourage.

Here’s hoping he didn’t forget the kitchen sink. The strategic placement of one rather large bird over at Brisbane Airport was genius too — I mean, have you ever tried to get up the Pacific Motorway in a hurry? If WW3 came knocking, it’d be at least a day before they’d get over the border — then there’s the Gateway Motorway traffic to contend with. They’d be sitting ducks stuck in one of Brisbane’s most prestigious parking lots.

George Bush is off to a great start, right in the opening speech, he welcomes everyone to the OPEC meeting. Well, it’s good to see that Operation Iraqi Liberation (OIL) hasn’t been far from a certain president’s mind. For a world leader though, it’s a shame he didn’t pay more attention to his geography teacher at school. Do I look like an Austrian to you? Hmmm?

Osama Bin Ladin … apparentlyThe Chaser’s APEC passes — an obvious fakeSecurity has been tight though… I mean really tight. The only people allowed through are those dressed up like Osama Bin Ladin, or those carrying a Chaser’s War on Everything “Insecurity” pass with “Joke” written on it. No terrorist could possibly penetrate this iron-clad wall of security.   (Image source & credit: News Corp.)

It was rather amusing too, to see the cast of “The Chaser” get a dose of their own medicine too. Indeed, the shoe was on the other foot. They should indeed consider renaming the show, “The Chasee’s War on Everything” — at least while the courts decide their fate.

As far as breeching security is concerned, either someone in charge of the gates doesn’t quite understand what “joke” means, or they mis-interpreted the number of barks emitted by their guide dogs. If they let through something as blatantly suspect as they did, then I’m afraid they’ve only got themselves to blame. But it seems security is everyone’s problem, and everyone is at fault when it falls down. Unfortunately for the NSW Police, it’s done little other than make them look like fools — and their present attacks only make the hole deeper.

If it’s one thing we can learn from this whole experience, it’s this: don’t go hosting such highly sensitive events in the middle of a busy city. Seriously guys, go somewhere rural where you’ll be miles away from any trouble, and you’re not going to be a right pain in the arse to millions of people. Of course, this would just be common sense, and we all know just how common that is these days.

Riverfire 2007 Photos & Video

The photos have been up for a little while, but I haven’t bothered to actually post the link to them.

Brisbane has a fireworks event called Riverfire on an annual basis around this time each year.  It fires off around various points of the Brisbane River that passes right through the CBD

For the last few years, we’ve been going as a group of friends up Mt. Coot-tha and taking shots of the fireworks.  Last year’s efforts are here.

This year, I tried using some different exposure settings … normally I like leaving the shutter open for a while, to capture the full effect.  This time I tried 1/6 sec exposure.  If I hit the button at the right moment, the effect worked well, but the timing was a real issue.  I wound up going back to long exposure, which produced some nice shots towards the end.

The ground wasn’t as stable this time either, thus there was a little camera wobble in some of my shots as the tripod moved.  I also managed to get some videos of the F111 dump-and-burn sequences at the start and end.  These are in pretty low quality MPEG4+AAC or Vorbis+Theora since I’ve only got a 128Kbps upload pipe — so go easy on the downloads.  For best results, download them to disk, then start playback.

I make an appearance in some of these photos — I won’t say which ones… that I leave as an exercise for the viewer.

See http://gallery.longlandclan.id.au/viewalbum.cgi/riverfire-2007 for the photos and videos.  If you decide to link to the videos, please mirror them on your space, providing a hyperlink to the photo gallery.

Re-inventing the headlamp… the Hat-lamp

This is an idea I’ve had for some time now, but only recently started doing anything about it. Anyway…

The problem:

As many of you may know, I study at university. Often the lectures and tutorials are on late at night. Thus, I frequently find myself making my way from or two university in the dark. Many of the areas I walk through are dimly lit, with sparse street lighting and quite a few road crossings. Often the footpath is an uneven surface, and therefore one needs a torch of some kind to see any hazards underfoot. The same torch does improve one’s visibility — but only for those in the torch’s beam.

Headlamps are really nifty torches… freeing both hands. The problem one has though, is that the small compact ones aren’t much good for distance vision, and the big bulky ones chew batteries like they’re going out of fashion. Then there’s the fussing over whether they’re pointed up or down, adjusting head straps…etc. They’re great when camping, and even for walking home of an evening, but the balance between light intensity and battery drain is a big problem, especially when only a limited supply of batteries is on hand. Seldom does one need a high-power beam all the time, but they’re useful to have.

Bike tail-lights are useful for improving one’s visibility to vehicles coming from behind, but they aren’t much help if they’re approaching side-on. And none of these lights will turn themselves off if there’s sufficient ambient light.

My idea:

These problems got me thinking about how I could solve the problem. Does it really need to be solved? Well, it isn’t a big one, so I guess not… but for the sake of it, I’ll try and solve it anyway. LED technology has vastly improved in the last few years, to the point now where they’re talking of using them in street lighting and car headlights (PDF; IEEE Explore subscription required). The big advantage is the high efficiency and low heat of LEDs. A few high-power LEDs should last as long, if not, longer than the incandescent bulb that my present headlamp uses.

My idea revolves around mounting 3 sets of LEDs on a hard hat of some description. Why a hard hat? Well, they’re a rigid structure that I can easily drill holes into and mount components on. Using a full-brim hard hat (rare in Brisbane), it’ll also keep the sun off during the day, thus serving a fourth purpose.

This headlamp would use 3 different LED banks:

  • High-Beam LED: Single 1W high-power White LED — mounted above the rim facing forward in the distance.
  • Low-Beam LEDs: Three high-intensity 5mm White LEDs — mounted under the rim facing downward.
  • Rim LEDs: Twelve high-intensity 5mm Red or Yellow LEDs — mounted around the rim of the hard hat facing outwards.

The high-beam LED would provide the distance lamp… acting like any high-power torch. It’d be focussed slightly below the horizon. The low-beam LEDs would be directed downwards so that they light up an area just in front of the wearer, allowing them to see what they’re doing. The Rim LEDs would be divided into two groups of 6 that flash alternately to warn approaching vehicles at any angle.

Mounted on the top of the hard hat, would be a light-dependant resistor (cadmium-sulfide cell) that detects ambient light, and just underneath, a PCB containing the controller logic for the automatic switching. Then down the side under the rim, would be the switches and threshold pot for controlling the whole circuit.

Each of the functions can be in one of three states, controlled by the user: on, automatic, or off

Controller Circuit:

The key to this headlamp design is the controller circuit. I ended up trying three different circuits before settling on this design. By far, the most simple circuit was based on a IRF630B N-channel power MOSFET.

In this configuration, the CdS cell and potentiometer were wired in a resistor-divider configuration, such that the voltage rose as the light level dropped. This drove the MOSFET’s gate pin, causing it to sink current whenever the light levels were low.

I soon discovered this circuit was no good for high-current devices such as my existing incandescent headlamp. Because the bulb was such a heavy load, it put a heavy strain on the batteries, causing the voltage potential to drop significantly. This in turn, shifted the threshold point on the voltage divider, causing the MOSFET to turn off again, causing the batteries to rise up again… ad nauseum, until the batteries were flat or the user got frustrated and switched to manual modes.
Addition of a relay helped… the ciruit was slightly more stable, increasingly so as large amounts of capacitance were added across the relay, slowing response times. It still was possible to get the whole system into a battery-guzzling oscillating state.

In the end, I turned to the humble 74HC14 Hex Inverting Schmitt Trigger. By turning my voltage divider up-side-down (so voltage rose with light level) I found I could gain the effect I needed. Due to the hysteresis provided by the Schmitt Triggers, the light doesn’t turn off until it gets significantly lighter than the threshold point, and doesn’t turn off until it gets significantly darker. This provided the stability I needed. Hard Hat headlamp controller, rev3

The final design (click image on right, or see SVG or Kicad .sch versions) works as follows. The CdS cell and pot provide the means for detecting the light level. Adjusting the pot will make the circuit more or less sensitive to light. This drives the first Schmitt-Triggered inverter.

The output of this inverter is passed through a BC547C NPN transistor which in turn, drives a small reed relay. This relay is the main switching workhorse, providing a switched 6v rail which hooks to small toggle switches for the low and high-beam LEDs.

For the Rim LEDs, the same schmitt trigger IC could be used to make the oscillators. The Phillips 74HC14 datasheet describes how. I didn’t care much about frequency, so long as it flickered just fast enough to be noticable. To get the alternate flashing action — I set one inverter up as an oscillator, and used it to drive a second inverter. The outputs of both drive individual BC547C transistors, which act as current sinks from the Rim LEDs.

The following two photos show my testing of the circuit on a breadboard.

Testing on breadboardCircuit in action

Bill of Materials

The following is the list of parts for this headlamp, and where I purchased them. Some components can be exchanged to suit one’s needs. At the moment, I haven’t yet bought the 1W LED and power supply which would form the high-beam LED.

Quantity Part Desc Supplier. Part No. Approx. Price each (at time of post)
1 Hard Hat Blackwoods 05339960 $22.00
1 74HC14 Hex Inverting Schmitt Trigger Jaycar ZC4821 $1.30
3 BC547C NPN Transistor (or similar) Jaycar ZT2152 $0.20
1 5V SPST Reed Relay Jaycar SY4036 $2.95
3 1kOhm Resistor Dick Smith Electronics R1074 $0.04
1 10kOhm Resistor Dick Smith Electronics R1098 $0.04
1 33Ohm Resistor (for low-beam LEDs) Dick Smith Electronics R1038 $0.04
1 10Ohm Resistor (for rim LEDs) Dick Smith Electronics R1026 $0.04
1 33µF Capacitor (electrolytic) Dick Smith Electronics R4340 $0.25
1 Veroboard PCB 95mm×76mm Jaycar HP9540 $3.80
1 1MOhm Potentiometer Jaycar RP8524 $2.50
1 Photoresistor (CdS Cell) Jaycar RD3480 $2.50
1 4×AA battery holder Jaycar PH9282 $2.25
1 1W Constant Current Supply Jaycar AA0582 $19.95
1 1W High-power White LED Jaycar ZD0508 $9.95
3 18000mcd White 5mm LED Jaycar ZD0195 $4.95
12 4000mcd Red 5mm LED Jaycar ZD0154 $0.80
1 Packet of Nylon bolts 12×3mm Jaycar HP0140 $2.65
1 Packet of Nylon bolts 25×3mm Jaycar HP0142 $3.00
1 Packet of Nylon nuts 3mm Jaycar HP0146 $2.50
3 DP3T Switch Dick Smith Electronics R7614 $0.98

Assembly

Underside of modded hardhatConstruction of this headlamp will require drilling holes into the shell of the hard hat. So once complete, I wouldn’t go using it on a construction site. To mount the rim LEDs, I found the best way to do it was to use a 3mm drill to make the hole, then use a screwdriver to widen the hole so it was just big enough to accomodate the LED. The LED was then forced into the hole, plugging it — friction holds it in place.

The switches were small enough to mount using double-sided tape just inside the hard hat. A small piece of PCB was used to mount the potentiometer, allowing it to be fastened to the underside of the rim using a nylon nut & bolt.

The low-beam LEDs were mounted onto a small PCB with the current-limiting resistor, and fixed to the front of the hard hat using masking tape (yeah, dodgy I know) — some cardboard prevents the light from shining into the wearer’s eyes.

The main PCB and battery pack were fitted inside the shell of the hard hat — two 25mm long bolts hold the battery pack in place, while one 12mm bolt holds the PCB in place. The actual components are placed on the PCB according to the PCB board design shown to the right (click for larger image).

Final Product (almost)

Well, I haven’t bought the high-beam LED yet, that’s for later. The end result however, works great. I first used it at Riverfire 2007 and found it very convenient. At the time I had lost the LDR, so had to buy one yesterday, which I fitted last night. The unit now automatically switches off if the light levels are sufficient. As far as appearance, it doesn’t look that different to an ordinary hard hat, until you switch the LEDs on. These show the hard hat, before modifications, after, and what it looks like in action.

Original Hard hat After modifications Hat-lamp in action

Safety & commercial considerations

It’s worth noting that although this hard hat would’ve been manufactured to meet AS/NZS 1801. I’ve destroyed this rating by drilling holes and inserting electronics. This project might still survive the double impact tests needed — but it’s never been tested, and isn’t intended to. I just wanted a hat that shaded me by day, and lit my path by night.

If this idea prooves popular, I could see it being adapted into a removable brim that sits over a hard hat/cap. The actual electronics cost over $60 … so embedding it into a hard hat on a commercial basis is not economic, since hard hats have a limited lifespan and need to be replaced every few years. So the headlamp would need to be detachable.

Update: 22nd November

Finished hard hat+headlampWell, having used it now for two months, the idea has worked great. One set of 4×AA batteries lasts about 2 months, with moderate usage — and even then everything still worked, just the light was getting a little dim. I’ve since added the high-beam 1W LED (the supply for it wound up costing about $40, but anyway) and extended the brim so that it provides additional shade during the day.

The photo on the left shows what it looks like now. There has been one minor technical problem, in that the relay occasionally sticks — I’m investigating whether I replace this with something solid-state such as a P-channel power MOSFET which should do the job nicely. The only other one is the odd social problem — of people asking if you’re expecting a disaster, but once they’re used to seeing me wear it, this usually isn’t an issue. 😉


Update 2009-06-05: I did get around to making a P-MOSFET version. See the schematic in PDF or gschem. The circuit can theoretically use any P-MOSFET rated at 1A current for Q1… this one uses the IRF9540N available from Jaycar (which is overkill). I use BC547Cs for Q2 and Q3. CONN1 connects to the adjustment pot (use a 2M? one), CONN2 connects to the LDR. R1 and R2 may be omitted, but are present to allow the circuit to operate if either the pot or LDR connections are broken. CONN3 and CONN4 connect to your low and high beam LED banks. CONN5 connect to the two warning LED banks. R4 and C1 control the rate of oscillation… any value can be used, see the NXP 74HC14 datasheet for details on how to calculate these.

Murphy’s Law

Well… I’ve had some interesting issues this week.  Murphy must be looking down on me.

O2: RM5200 CPUs with PROM 4.0

I recently purchased a RM5200 CPU module for my O2.  Now, my O2 at the time came with a R5000 180MHz CPU, and had PROM rev 4.0.  After handing across AU$100 on the new CPU module, I later discovered my PROM didn’t recognise the CPU, instead, it emitted the message:

Not supported CPU type. PRid<impl>=0x28

PANIC: assertion failure (IMPOSSIBLE) in file cache_mi.c at line 203

… via serial console.  The seller had tested the CPU in one of his boxes (accidentally left one of the riser connectors attached to the module) prior to me picking it up, so I knew the CPU worked.   He hadn’t struck this problem before — which I suspect is because 99% of his customers would have IRIX 6.5 installed (the PROM gets updated during the install process).

My problem, I don’t have a complete set of IRIX.  I downloaded IRIX 6.5.30 from SGI’s SupportFolio website, plonked some files out of the first overlay CD on my TFTP server and managed to netboot IRIX into a miniroot, however I lacked the foundation CDs, thus couldn’t perform an installation.  Thankfully, J. Scott Kasten was generous enough to email me the flashinst utility and IP32 PROM image, which I used to update my PROM to v4.18.  It’s a shame that SGI haven’t considered releasing a minimal IRIX miniroot with flashinst so that us Linux users can update our PROMs without downloading >2GB of tarballs and spending an entire weekend trying to figure out how to turn tarballs into an IRIX installation.  I’ll post up how I netbooted IRIX and updated the PROM later.

In any case, my O2 is back up and running… flying along at 300MHz.  Just to upgrade the RAM (it already has 36GB+4GB HDDs)  and it’ll be a sweet machine (as far as O2s go).  I’ve since left feedback on the item, and posted the surplus riser connector back.  (I got the CPU module from “octane_king” on eBay Australia, who has a few of these available as a buy-it-now auction, if people are interested.)

Building a new headlamp

I broke my LED headlamp on a recent camping trip … it was one of these 3-LED jobs, that ran on AAA batteries, and could either work as a handheld torch, or clip onto a bracket.  The torch still works, but it is now an ex-headlamp, a pain in the arse if you’re trying to carry things.

Not happy with what’s on the market, I got a bright idea to make my own.  Basic idea, I’d use a hard hat to mount the LEDs on and conceal the electronics under the shell.  As an added feature, the headlamp was intended to incorporate a light-dependant resistor (CdS cell) which was to drive a inverting schmitt trigger, so that the headlamp could switch-off if there was sufficient light around (e.g. I stepped indoors).  I’ll be posting about this in detail later too.

I had all sorts of fun getting the hard hat… I was after a full-brim one, since the others look bland, and the full brim one would also give me more surface area for mounting components.   My first problem was not knowing the right key words, I had tried “wide rimmed”, mining, and numerous other keywords without success.  Once I had the right keywords though, I did discover a couple of suppliers here in Brisbane (such as Blackwoods at Carole Park).  They’re still insanely rare in this part of the world.

Now that I’ve got everything, I started building it last night.  Trouble is, the CdS cell has gone walkies, and I just know it’ll turn up if I buy one.  I also didn’t count on the curvature of the hard hat being a problem — I planned to use double-sided tape to attach the battery packs and PCB to the underside of the shell.  Turns out I’ll need to drill a hole and use nylon nuts & bolts to attach these.  That said… I have my headlamp partially working now — sure, I look like I’ve just stepped off a building site, but it’s functional (still some fine tuning to do).  I intend to make use of it at Riverfire tonight, as well as those late nights when heading to/from university.

Anyway, right now I’m in procrastination mode… I need to resume studies on a telecommunications subject pronto, so I better pull my finger out and get to work. 😉

Thanks :-)

Hi All… figured I’d thank you for the support, and better explain my emotional ramblings (as I lie here trying to wind down and sleep, battling a 15″ CRT that wants to emulate a disco light).

A little about my personal life. I certainly realise I’ve had it a lot easier than some, but I’ve had some rough moments.

This includes witnessing a marriage breakup of my parents back in the early 90’s. (Being the ham in the sandwitch is no fun at all.) Bullying both verbally and physically over my years at school, not just from individuals, but from entire classes. Even some sexual abuse (from a female student, more on that later).

So it’s little wonder that I am sometimes a bit on the fragile side. Am I looking at blaming others for my problems? Well no. I’ve moved on for the most part.

This includes the one case of sexual abuse. Without going into details, it was back in 1992, and involved a year 7 female student at my primary school. I’m not planning on hunting her down though. If I do happen to come into contact, I only wish to know two things:

  • Has she committed the same act on others?
  • (most important) Has she gotten help for her psychological condition?

What I’ve heard… this kind of abuse starts when the abuser themselves, is abused in some manner. I’m willing to forgive (not forget) the act if the guilty party is willing to, or has, undergone some rehabilitation & councelling on the matter.

As for the bullying… the worst of it occurred in 1995. I don’t exaggerate when I say I had a good 20 or so students from the year 6 class ganging up on me. I don’t recall every incident, but I do recall getting surrounded and screamed at.

It didn’t help that I didn’t get along at all with my teacher at the time. The problem solved itself however… the main ring leader wound up switching to BBC and the group kinda collapsed. The teacher also wound up switching schools if I recall, not sure of the exact reasons.

So yeah, I carry a bit of baggage around with me. I don’t let it stop me with what I’m doing now… and it has very little to do with my outburst a few days ago — which was brought on by more recent issues.

Right now… I’ve been trying to wrap my head around some telecommunications topics for an exam I have on Tuesday. (I’m repeating the subject from last year — so I really want to pass this time.)

Progress has been slow however, since I haven’t completely grasped all the concepts. My apathy/laziness and a sub-optimal teaching method (for me, not everyone learns the same way) are likely to blame there.

Needless to say, I’ll be looking forward to the upcomming Christmas/New Year break. I’ll like it even better if I can put these engineering skills of mine to some constructive use.

Depression

Well… now that I’ve redirected most of the major viewers to a safer feed, I can now drop a few bombshells and let off some steam without making Linux distributions look bad.

The last 12 months have been a bit of a roller coaster ride for me. Specifically, it has been events at university, and the stress brought on by these events that have lead to me getting burned out. No longer have I any interest in persuing a career in IT or electrical engineering, or continuing with life in general.

Early last year, I was looking forward to finishing my degree, and ideally working with some embedded systems, as that was what I seemed to enjoy. The idea of getting useful software onto an embedded computer (with limited memory, storage and CPU power), then stuffing that computer inside some package appealed to me.

In a way, it kinda still does… but not to the same extent. See, my big problem is that I’m not able to play the social game, and have no desire to. While some are not happy unless they’re chattering away with the big boys in the posh end of town — I’m more comfortable sitting back in a quiet space working on whatever projects interest me at that moment in time.

I do have quite a few technical abilities, and some social qualities that are considered highly valuable by many employers — however, what they get is a package deal, and it’s some of my personal traits that could make it a deal breaker at the interview. Put simply, interviews do not suit me or people like me. Which is a shame, since it’s people like this, that gave us many of the advances we have today including AC power generation and modern computers.

My situation at the moment is this. Make no mistake right now, I am in a suicidal state mentally. I however, don’t want to put undue stress on those that I’m working with within the university… thus I won’t be enacting on any plans until next year. If things don’t go well this year, I may well be a corpse around March next year.

Essentially, my problem revolves around the fact that I see no worthwhile future at this moment in time. If I can’t gain employment, then I’ve got no means to support myself — I’ll wind up on the streets. I’d rather jump now whilst I have some dignity, then wait until I sink to the bottom of society.

I’m in talks with various medical people at the moment… so far this has largely been a waste of time and money. I’ve been following the advice given, but so far haven’t had any real resolution to the issues that I face. My biggest problem, is that not being a socialite, more or less means that my skills are not in an easily accessible form. Thus, people conclude that I have nothing to offer them.

They see me as an ordinary person who should understand the unwritten rules of social behaviour. I mention that I have AS, the usual retort is, “You look fine to me…” Yes, I do look fine. I have good vision (slightly myopic, but acceptable), good hearing, etc. I have both arms and legs fully intact and operational. I have no mobility problems and my mental abilities are fine. But this does not mean that I react the same way as everybody else. It’s this total lack of understanding for people like myself that has me on the brink of suicide.

And no, pills aren’t the answer here … not unless you want to try and medicate 6.1 billion people who have the lack-of-understanding disease. Indeed, it’s not just AS, it’s other conditions too: being of a particular ethnicity, various forms of disabilities (mental, physical and social/communicative), demographics… you name it.

It’s something that really gets up my nose about society today. The bigger we get, the less we care. If this is how the world is going, then count me out — this is not a world in which I wish to participate.

Change of feed URL

I’ve done some changes to my blog with respect to categories.

I’m quite conscious, that what I say on this blog gets syndicated on a number of websites. So as to protect the owners of those sites from posts that may not be appropriate, I have hacked my WordPress installation to force syndication requests to use the “Public Syndication” category unless they specify an explicit category.

I would greatly appreciate it, if this post winds up on your aggregation site, if you could change the feed URL to https://vk4msl.com/feed/rss2/?cat=10

My present TODO list

Well… if you looked at the number of commits I’ve done lately, you’d be forgiven for thinking I’ve been resting on my laurels for the past month. In some ways, this is true… but I’ll soon be doing a bumper crop of updates.

KDE 3.5.7 Keywording

I’ve been using this release of KDE for a good few months now. I’ve given it a run on my Octane, everything seems to work alright there… and I’ve been using it on a daily basis on both Loongson machines — and thus can be fairly confident it won’t break anything.

Avahi to earn ~mips badge

Again, I’ve been using this package on MIPS for a very long time, since mid-last year. Everything seems to work. Along with this, will be dbus-1.0 and nss-mdns.

Re-keywording of Gnome

This hasn’t been discussed yet, and as such no decision has been made, but I have been working towards getting Gnome installed on my O2. Some packages failed tests, some failed to compile completely … but nonetheless, there’s now the beginnings of a useful Gnome desktop. (Well, as useful as Gnome is likely to be… I’m a long-time KDE user myself, having switched to it during my SuSE 5.3 days. Prior to this, I used FVWM.) I’d like feedback from present MIPS users, about whether there’s any demand for this desktop.

Other packages presently in testing

I’ve started looking into other packages for ~mips candidates. Namely, I’m concentrating my efforts on packages that turn an otherwise useless MIPS box into a useful workstation. That is, desktop type applications such as KOffice, mplayer, xine, Amarok, Gimp, Inkscape … etc. Some of these, I’ve been using for a while… others I’m only just starting to build now. (e.g. I’m building Amarok, since I prefer it to Audacious, and in my experience, it handles Sun Audio better than mplayer or Audacious presently does)

On this matter, I’d love feedback on what people actually use their MIPS boxes for, and how Gentoo/MIPS can be better tailored for their needs. If you’re using Gentoo/MIPS for something productive, either as a hobby project or for something more serious, I’d also be interested to hear about it… since this will help in planning what needs to happen with respect to this port.

Lemote Loongson Support

Still, no word from trustees… but I figure any legal hurdles are well and truly gone now. I’m starting to look into how to produce media for these systems.

The biggest hurdle thus far, has been µClibc — or namely, it’s dynamic library loader (ld.so). The Lemote systems use a page size of 16KB — this was the default when I first started using the boxes, and as far as I can tell, they do not like using 4KB page sizes, the kernel dies a rather horrible death. Unfortunately, µCLibc, in it’s infinite wisdom, assumes a page size of 4KB. Thus when it tries to dynamically load libraries, one gets hit by a “can’t map <foo.so>” message.

So where does this leave me? By the sounds of things, the netboot images will probably wind up being either a hybrid statically-linked µClibc busybox with dynamically-linked glibc filesystem tools, or will be a completely dynamically linked glibc affair, depending on which winds up being smaller.

Thankfully I can kinda get away with using more space — I don’t have the size restrictions on the platforms I support. CoLo on Cobalt will load kernels of almost any size, as will PMON2000 on Loongson, but still, I cringe at the idea.

Apart from netboot images… there are a few other steps to be done here:

  • Keywording of the ATI Radeon driver — this can probably happen straight away. It won’t break the SGI boxes, since they don’t use the Radeon driver, and I know it works out-of-the-box on Loongson.
  • Patch X.org — There’s some patches needed to the core components of X.org for it to work on Loongson. These need to be tested on SGI systems to ensure they don’t break things. It’s quite likely they’ll wind up in X.org CVS in the next few months, but it’d be worthwhile locating and fixing any bugs that occur ahead of time.
  • Inclusion of patches into mips-sources — At the moment, I’m waiting around for a 2.6.21 or 2.6.22 ebuild to show up so I can try out the patchset I have here, the holdups being IP28 and IP30 support. Once I can get the Lemote patchset into a form that cleanly applies to mips-sources, we’ll then look at formally including them in the ebuild.
  • Handbook updates — to be done once formal approval has been granted and the other steps are complete.

So, lots of work to do… and all of this whilst getting into my studies (e.g. there’s one piece of Allen Bradley ladder-logic code that’s just screaming for me to pick through it for a uni subject) and looking for industrial experience. Hopefully university studies won’t burn me out like they have for the last 12 months.

As always… you know where to find me if you wish to get in touch.

Time-shifting radio

Well, right now I’m lying back, listening to the fruits of my labours.

When it comes to time-shifting, there are quite a few solutions that allows a user to time-shift television. MythTV, Tivo, Foxtel IQ… just to name three. However, I’ve looked around, and found very little for radio.

My needs are basic… I have an old stereo FM tuner plugged into the line-in socket of an old laptop. It’s in a spot where it can get good reception. The machine has a 20GB HDD, Apache web server, and enough CPU grunt to push the data. I thought it’d be nice if I could stream my radio around the house, in a manner that allowed me to time shift backwards up to a few hours or so. Therefore… if I wanted to hear a radio programme, but missed the first 15 minutes — no problem, just tell it to start playing from 15 mins ago. Done.

It’d also be nice if it could be in lossless form. I’m on a 100Mbit LAN — I don’t need compression, but some extra CPU cycles could be nice.

Icecast did the basic need of streaming radio quite well… but there were a few problems:

  1. It couldn’t timeshift
  2. I found it would frequently drop the feed mysteriously
  3. It used Vorbis — not so much a problem, but for my needs, lossless was better

So seeing few alternatives, I set about designing my own system. The concept is simple:

  • Create a capture programme, that records audio to a series of 1sec raw blockfiles, stored in a stream directory.
  • Make a CGI application that scoops up a number of these blockfiles, concatenates them, adds an appropriate header and pushes them out to the client
  • Construct a shell script that can clean up old files (to keep the disk from getting full)

After looking around at a suitable capture API, I settled on Portaudio v19. I had done some apps with v18… thus I had some familiarity with it. Doing this allowed my app to be cross-platform, should I decide to develop it further.

It was simply a case of writing a program that would write blockfiles, one for each second, identified by a Unix timestamp. As time ticks forward, it closes one block file and opens the next. My capture app is basically 137 lines of pure C code. Very tight and efficient.

For the CGI app, I again did it in pure C. It picks up its parameters from the PATH_INFO environment variable, allowing nice clean URLs, and parsing is as simple as calling getenv. I ended up writing two versions of this app.

The first version used sox in a child process, to convert the raw audio to a RIFF stream. My problem was that I used popen to execute sox. It worked well, except that disconnecting the player left loads of sox instances running, hogging the CPU. I started looking at writing my own RIFF header library, only to discover how complicated it was.

Looking around, I stumbled across the humble Sun Audio format. Apart from the minor inconvenience of having to pass everything through atonl/atons… everything works fine. I specify a URL like http://blackbox.local/cgi-bin/stream/linein/2 (the laptop, an IBM T20 is called blackbox), which gives me the stream “linein” from 2 seconds ago. I find it’s a bit glitchy any closer than that… but for maybe 6 hours coding, I’m quite happy with the result.

The problem has been clients… Amarok seems to know what to do with the stream. mplayer tries despairately to seek in the stream (why?) then drops out. And don’t even ask what Audacious does — I’m at a loss there. That said, good ol’e sox and wget or curl works fine, and is lightweight — just the interface is a tad annoying.

I’ll probably wind up writing my own client anyway — so I can time-shift somewhat more conveniently (using a slider to set the offset).

Still on the TODO list, is to make the capture app daemonise itself (it runs in the foreground for now), and to write an app that can be run from cron, and will record a radio programme for later listening (e.g. on a portable music player for instance) — perhaps optionally encoding it in a compressed format.

I’m tossing up whether to release the sources or not… if there’s demand for such a project, I’ll look into cleaning things up and releasing it. That said, if anyone knows of something that does similar to the above… I’d be interested to hear about it.

Gentoo/MIPS on QEMU: Update

Well, those who recall my earlier post… I’ve managed to get a VM going.
qemu-mipsel ~ # emerge --info
Portage 2.1.2-r9 (default-linux/mips/2007.0/cobalt/o32, gcc-4.1.1, glibc-2.3.6-r4, 2.6.18-4-qemu mips)
=================================================================
System uname: 2.6.18-4-qemu mips MIPS 4Kc V0.0 FPU V1.0
Gentoo Base System release 1.12.6
Timestamp of tree: Sun, 12 Aug 2007 13:50:01 +0000
dev-lang/python: 2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox: 1.2.17
sys-devel/autoconf: 2.61
sys-devel/automake: 1.6.3, 1.9.6-r2, 1.10
sys-devel/binutils: 2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.14.4
ACCEPT_KEYWORDS="mips"
AUTOCLEAN="yes"
CBUILD="mipsel-unknown-linux-gnu"
CFLAGS="-mips1 -O2 -pipe"
CHOST="mipsel-unknown-linux-gnu"
[...]

The assessment? Well, firstly, it’s slow, very slow. I realise the BogoMIPS is a somewhat dubious benchmark… but:

QEMU:
system type : Qemu
processor : 0
cpu model : MIPS 4Kc V0.0 FPU V1.0
BogoMIPS : 246.27

versus… my Qube2 (250MHz):
system type : Cobalt Qube2
processor : 0
cpu model : Nevada V10.0 FPU V10.0
BogoMIPS : 248.83

one of the Lemote Fulong miniPCs (660MHz):
system type : lemote-fulong
processor : 0
cpu model : ICT Loongson-2 V0.2 FPU V0.1
BogoMIPS : 444.41

or my IP28 (195MHz):
system type : SGI Indigo2
processor : 0
cpu model : R10000 V2.5 FPU V0.0
BogoMIPS : 193.53

Is it usable?  Well, if that benchmark is anything to go by, it isn’t that much slower than my Qube2.  But the CPU that QEMU emulates, doesn’t implement any cacheops… so in that respect, it’s even slower than the Qube2 (which at least has some primary cache) .  I’ll know as I install more stuff, but my first impresions are that it’ll be too slow for most tasks running Gentoo, unless your host PC is a beast (mine isn’t).  Unless you’re doing development, you’d be better off just running everything on the host PC bypassing the emulation layer.

I might consider putting together a kernel that will allow installation of Gentoo/MIPS, since it’ll be a good way for me to test the userland components of any netboot images I produce.  I’m yet to try a kernel build, at the moment I’m using Debian’s kernel.

It is doubtful that this machine will ever be officially supported, but I’ll consider it if there’s sufficient demand. 😉