Blogospheric Refraction

One thing that I’ve noticed is how inefficient most calculator apps on the desktop computer are. Not just from a computational point of view, but from a user interface point of view.

It seems the vast majority of them are more of an exercise in UI element layout than in producing a practical computation application. This got me thinking about my needs, as an engineering student (soon to be full fledged graduate engineer, if everything goes to plan this month).

Python, Octave (or Matlab) and the calculator applet in KDE’s Kicker, are probably the most useful as far as practical calculators in my experience. There are probably others… these mostly use the keyboard for input and have a minimal interface. I find KDE’s kicker applet works well for quick calculations, with Python or Octave taking up the slack for more complex stuff. I’ve experimented with x48… the HP48 is indeed an awesome piece of kit… but why should an app limit itself to the confines of a real-world device?

I did some thinking about this… and coding. RPN calculators are conceptually very easy. All the values are placed on a stack, operations pop off operands from this stack, then place the result back on the stack. They’re also very easy to code, especially in a high-level language like Perl. I set to work coding up a RPN calculator.

RPN calculators in my experience take a bit of getting used to, but often are more convenient in the end, than a regular calculator. The limitation though is one can easily get themselves tied in knots with the stack… you find that you didn’t push the elements on in the right order, and so you find yourself popping it all off to have another go.

Thus, with my app, I decided to experiment with a multi-stack concept. In addition, sometimes it’s nice to copy a calculation made into a temporary space where it won’t get buried in the stack… so each stack has an associative array for the storage of variables.

RPNCalc is a first stab at this calculator concept. It has a few limitations, but works reasonably well. Its biggest limitation is complex math, or rather, the lack of it. I thought I had done well until I encountered a problem that needed it.

The code is also a monolithic mess… so I’ve began re-writing it in an effort to produce a workable project for public release. HanoiCalc is the current working title for this new calculator app. At the moment, it’s little more than two Perl modules, one which provides the stack, the other providing all the operations… but it should serve as a basis for a workable RPN calculator. It uses complex maths by default (most calculations will just use the real part, ignoring the imaginary component).

I’ve held off implementing scripting… which could be done providing more power… but that’s beyond the scope of what I want to achieve at this point. I’ve tossed the code I’ve got presently into a git repository for now… you can either browse it via gitweb or clone git://git.longlandclan.yi.org/hanoicalc.git for yourself to play with.

I plan to add a user interface over the coming week. The API is simple enough, so GUI interfaces (even ones that pretend to be real calculators) are possible.

At university, I’m currently studying a subject entitled “RF & Applied Electromagnetics”, and at the moment, we’re looking at the issue of electromagnetic compatibility.

One thing that has come up both here, and browsing through the ARRL Amateur Radio handbook (I have the 1975 edition) is that above all, circuit layout has some of the most profound effects on how a circuit behaves.

What I did not realise, is just how low in frequency these issues show up.  The physical construction of many electronic components often means that, far from being a “pure” component, they in fact exhibit both resistive and reactive components.  I understood this occurred a lot in the VHF and UHF… which is a good reason why many homebrew radios stop in the lower HF.  These effects in fact, start to become visible as low as 14MHz.

This got me thinking… the typical circuit design workflow is some variant of this:

1. Draw up the schematic in a schematic capture frontend
2. Feed this into the circuit analysis package, inspect the simulation results.
3. If unsatisfied, tweak schematic then go back to step 2.  Else feed into PCB layout package.
4. Lay out the PCB
5. Get PCB manufactured and build circuit.
6. Do testing, tweaking component values… maybe go back to step 3.

It seems to me… the workflow should be more like the following:

1. Draw up the schematic
2. Lay out the PCB
3. Feed the PCB layout and circuit schematic into the simulator, inspect results.
4. If results are unsatisfactory, tweak layout and schematic, else get PCB manufactured and build the circut.
5. Test & tweak

One criticism I have of gEDA, it seems to treat the schematic and the PCB as being two different things.  I find it awkward to move from gschem to PCB and back again when designing a circuit.  I also haven’t figured out simulation as yet.

I’d say the behaviour of the circuit has more to do with the way the board is layed out, than with just the components alone, and as such, I feel a modern EDA system should reflect this.  Qucs does seem to be approaching what is going on, in that you can simulate a stripline or similar PCB object in your circut.  I think it has possibly the greatest promise, but alas, it can’t yet do PCB layouts itself.  Time will tell I guess.

The commercial suites… well, I’ve used Electronics Workbench for years… I really must say I find the simulation in that much more intuitive than working with SPICE or Qucs… there is perhaps something worth looking into with its interface.  Multisim is more like traditional SPICE… but still retains some of the old feel of EWB.  However, all of them seem to simulate the schematic… which is fine… but you do miss out on a lot of what goes on in the circuit.

I’ve been getting used to Qucs… and so far, I quite like it.  Once again though, we’re looking at a simulation of an ideal circuit, under ideal conditions.  That is… pass a 100MHz sinusoid through a circuit: the resistors remain resistive, the capacitors store charge as they should and the inductors continue to add inertia.  In the real world, many resistors and capacitors become inductive in nature, and inductors look more like capacitors, depending on the physical construction of the component.  Mutual inductance, and capacitive coupling are also problems in the real world.

With today’s modern hardware, I figure the computing overheads to model how a physical circuit would behave based on the layout, is certainly a lot more feasible than it was when SPICE was first conceived.  SPICE was good for its time… but with the modern world requiring a higher level of engineering for its electronics, I think it has had its day now.

Lately I’ve been looking around at microcontrollers.

With my work with Eze Corp, I’ve gotten quite accustomed to the MSP430. It’s a nice little MCU, with a very low power drain, gcc port and is in general, quite easy to drive. At my workplace, I use a Windows XP machine to do development under MSYS, using a MSP FET-430UIF JTAG device for programming and debugging. This is not my preferred mode of development, I’d much rather be doing it on a Linux host (or at least something that properly understands POSIX)… but it’s tolerable.

For my home projects though… this isn’t an option. I do not own a Windows computer any more, and in any case, I dislike working with it at my workplace — to hell with using it in my recreation! (The reasons why are best saved for another rant at some other time. No, I’m not a free-software hippie, I have other reasons.)

There are a number of MCUs available that I’m aware of. The biggest hurdle with many of them is the requirement of some piece of hardware which is either proprietary, expensive and/or unavailable. I like the MCUs that provide a JTAG interface, since it’s a well defined protocol that allows real-time debugging of the device as well as programming. JTAG for what its worth is little more than an SPI bus at the hardware level, it’s what’s layered on top of this that differs between devices.

JTAG can be implemented via GPIO. Since a computer parallel port is merely a specialised form of GPIO port, this enables people to wire up a JTAG port to a parallel port, and bit-bang the signals. There’s a couple of issues with this approach:

• Parallel ports (I mean real ones) are getting harder to come by, especially on portable computers (understandable on netbooks, but I don’t see why full-size laptops don’t have them…anyway)
• Most USB Parallel cables only have the smarts to drive a printer, they don’t allow arbitrary bit-banging of data. (e.g. the PL2305. And try explaining the difference to a salesperson…)
• USB introduces a 1~2msec latency… which stuffs up timing at high speed.

I’ve seen some programmers (for PIC and AVR chips) that use RS-232. Now these are usually specialised devices for a given range of MCUs… that’s fine… but they suffer the same problem as the parallel-port JTAG cables… that is, most modern computers don’t have RS-232 anymore for some silly reason (as I say, understandable on netbooks… but are they saying they can’t cram a mini-din8 somewhere on a 15″ laptop?!)… and the USB latency screws timing up (I suspect this is the issue with the PL2303-based adapters we have here).

That leaves me with native USB devices.

A lot of the ones used by ARM devs are based on a FTDI chip which offers UART (RS-232) and SPI… so you get a serial console and a JTAG in one unit. Nice… In addition, there’s a open framework for debugging with them, OpenOCD. I don’t have the knowledge necessary to port this across to other MCUs… I guess one hope is that a MSP430 guru might contribute an OpenOCD port, but in the short term this isn’t an option.

For many ARM devices, there’s the J-link developed by Segger.  I’ve mentioned this one in past posts.  For MSP430, TI provide their MSP FET430UIF.  Both of these devices are on the nose from a usability point of view.  Both require you to use proprietary software in order to access their device.  This is fine if you’re on a supported platform, and the tool is well maintained.

For the J-link… well, if you’re not on Windows… forget it, that’s all they support.  The advice from them is to just run a Windows computer purely to run their GDB proxy software (which costs too I might add).

TI’s tool is theoretically a little better for support… the userspace drivers are proprietary freeware… but again, if you’re not using Windows or Linux on an i386 PC, forget it.  More to the point, the Linux version doesn’t seem to get updated as often — so the only real option is Windows.  Bad luck for me and my Yeeloong.

For what it’s worth, I do not understand why these things need to be proprietary… it’s a flipping programming cable.  Just moves data from one end to the other.  If they need to load firmware into the RAM of the chip being programmed, fine… but why can’t this be an ELF binary or something that just gets picked up by OpenOCD (or equivalent) and stuffed down the wire?

Devices like the Rabbit Semiconductor series of microcontrollers drive me insane with their non-standard nonsense… they decided to chuck many years of C history down the gurgler and invent their own “wannabe C”. #include <foo.h>? Nah… don’t be silly, we’ll just stuff everything into .lib files and #use them. Urgh!

I’d love to know what low-end microcontrollers exist that don’t exhibit the proprietary nonsense that is outlined above. 8 or 16 bits wide… I like ARM, but I’m not needing something that flashy. I like the low current drain of MSP430, and the fact they use gcc… which I guess pushes me in the direction of AVR and maybe PIC, but I’d be interested in other options. Cheap is important too, I don’t have a lot of cash for expensive tools or chips.

The other thing in the favour of AVR/PIC MCUs, is that there’s a local shop that I can buy them from — no need to order on-line. Farnell and RS have a wide variety, but I have to purchase from their website, which is awkward for me.

The applications I’d have in mind? Well, one idea is a more modern version of my headlamp… some of these MCUs draw less power than the 74HC14 chip used in that project (a few mA in standby mode) and would offer more functionality. Other applications include small controllers for amateur radio projects (not SDR though).

I’m really interested to know what controllers are out there, which are open-source friendly. Once I have a clear picture of what’s on offer, I can look more closely at my applications.

I just stumbled across this article, discussing the issues behind digital voice encoding at low bitrates.  The use of AMBE in the D-Star protocol really does get up my nose, at best it’s distasteful, at worst, harmful.

I’ve been doing some experimentation with Speex… so far my experimentations have been with bitrates above 12Kbps.  Above this, it is quite intelligible.  This is helped with pre and post filtering with the following filter:

It’s not ideal… it means things do sound rather flat, but it’s similar to existing filters employed on existing SSB and FM transmission systems. On SSB, around 2.2kHz is the maximum upper frequency… and it tends to drop out around 300Hz, give or take a little bit. That filter could do with some fine tuning, but I find for low-bitrate Speex, using it to filter the audio before encoding, and after decoding, helps to reduce the distortion of the codec. Some fine-tuning could allow for better fidelity.

It is interesting to hear though, that DVSI even cuts corners though in an effort to lift perceived clarity by trying to reproduce the bottom end.

A good low-bitrate encoder benefits everyone… VoIP becomes even cheaper when you can send the same quality audio in fewer bits, and the benefits for HF radio communications would be immeasurable.

I guess though, it comes back to the old saying:

The superior man understands what is right; the inferior man understands what will sell. — Confucius

Here’s some humourous food for thought.  Those of you in front of a Linux/Unix system, install fortune-mod and have a squiz at /usr/share/fortune/law — or just view this file that I have compiled.  Looking around, I found some more from elsewhere.

After you’ve stopped laughing… a query… How many of these laws are actually true?  I’m curious to know.

One theory that was proposed to me, is that there may not be a law as such prohibiting some act mentioned, but that someone was charged whilst doing an act mentioned in that document.  (e.g. shooting off a policeman’s tie… shoot anywhere near a policeman, and I’ll bet you’ll get busted!)

So, a query… how many of these are urban myth, and how many are actual laws?  And what law enforcement agency would have the audacity to enforce them?

Well, I spent much of my weekend fooling around with antennas in one form or another.

I had taken down my HF rig to bring to the Brisbane Amateur Radio Club social — to sort out why it wouldn’t tune up on 10m… the problem turned out to be my power supply. I was using an old 250W AT computer PSU capable of supplying 9A at 12V. My radio, a Kenwood TS-120S is a 100W radio, and draws 20A when running full power. Now I had assumed since the mic gain was turned down to comply with my 10W limit, so the limited power wouldn’t be a problem… not so… it turns out that although I turned the mic gain down, the radio still wants its 20A for voice peaks. This causes the voltage to drop, and of course, instability.

Well, BuyEquip had some 600W ATX power supplies, that advertised a 52A 12V output rail, brand new for $60, so I snapped one up. A few more bits and pieces, and now my radio is much happier on 10m. Interestingly, the box says 52A, the unit itself says 20A… either way, I’ve met my requirements.

Earlier when I had my HF rig set up, I had taken the balun out since I noticed it seemed to be shorting out the feedline (measured with an Ohmmeter), and I couldn’t even pick up commercial SW stations (I used to hear Radio New Zealand quite strong around 7.145MHz).

I later discovered that it’s quite normal for a 1:1 balun to appear as a DC short… my balun uses ~10 turns of not-very-thin copper enamel wire and I guess I’m used to transformers for other applications where one sees a much higher resistance. Transformer Baluns are typically almost purely reactive — remember the reactance of an inductor is Xl=2(pi)fL — at DC, f=0, thus my ohmmeter sees Xl=0.

However, I knew I had done something wrong when wiring it up as when I disconnected the shield — I received Radio NZ S9+10dB, connecting the shield back dropped that to S2.

In the meantime, I used a 5cm piece of RG58, soldered straight to some 300ohm ladder line (surplus from my sim jim antenna).

I wasn’t sure that I had wired the balun correctly — and had lost the plans, so I set about locating some on the ‘net. A quick search revealed this page from the Antrim & District Amateur Radio Society. Well… what a difference it made… my noise floor on 80m went from S7 down to S3!

I spent the evening chatting on the Australia Wide Night Owl Insomnia Net (Friday evenings after 10:00PM at 3.6MHz LSB) — talking with stations as far away as Coffs Harbour, and even heard a feint amateur contact from New Zealand (ZL1?? callsign).

The other issue, was with my handheld. I’ve got two portable antennas for it, neither of them are particularly efficient on 2m, both are brilliant 70cm band antennas. One is the antenna that Kenwood supplied with the radio, the other was a Comet SMA3 antenna that I had bought at BARCfest. Not bad for portable use — but I wondered if I could do better.

People might remember my old project, the Hat-lamp, where I set out to homebrew a headlamp using a hard hat. Two radio amateurs suggested that I add an antenna mount to that — one suggested I could have a SMA-SMA socket adapter there and use my handheld’s existing antenna, the other suggested a SO239 socket on the top with a mobile antenna.

Well I gave the idea some thought… The big issue with this is two-fold: clearance (the antenna would have to incorporate a spring to absorb being whacked against low objects) and the social aspect (what would people think after seeing it). Neither of the handheld antennas were particularly good on the former part — I managed to bend the newer antenna once just sitting down — it’s mostly bent back into shape now, but I didn’t want to risk it. Both would be rather conspicuous though. A mobile antenna would be a rather heavy thing to have sitting on one’s head, so I gave that idea a miss.

I found some stainless steel fencing wire that was quite stiff, and cut off about 60cm of it. The idea was I’d wind the bottom of it into a spring, and a SMA plug would be soldered to the end (using some copper enamel wire to make the connection). Well, I built that Saturday Night, and using it directly on the handheld, noticed an immediate improvement in performance — I was hitting repeaters I normally don’t hit unless I’m plugged into the roof antenna. It is shown below… click on the photo for a larger view.

Last night, I set out to attach the antenna mount to the hat. One hole and a bit of elbow grease later, I had screwed the SMA-SMA adapter into the hole. The antenna neatly screws onto the fitting around the back of the hat, and a length of coax screws in underneath running to the radio. I haven’t tried walking around outside with it, but indoor performance is good.  The photos below show the socket views on top and underneath the hat’s brim…

The plan, the whip is still rather conspicuous — and there’s the risk of doing someone an injury if I’m not careful where I point the whip. I’m now looking around for a souvenir peacock feather that I can stick the antenna up the centre of… the idea being the assembly becomes decorative as well as functional (below is what it looks like now, sans feather). Well kinda… it’ll still look weird, but hopefully people will notice the feather rather than the antenna.

Seems I’ve coined a new term tonight… “faceborg”.  Okay… seems others have come up with the same idea before me, as pointed out by others.  Not sure what to call the MySpace users… I’m sure someone will come up with a succinct term for them.

Ever since social networking sites such as MySpace and FaceBook have come on the scene, the internet veterans have been under increasing pressure to join up with these sites.  Me?  I don’t see the point.  They don’t appear to offer anything new.  From what I can tell, they are centred around allowing someone to create their own identity.

The misconception out there among the non-technical people, is that you need to be part of one of these sites to have an online identity.  This is simply not true.  You can achieve much the same thing, through the use of traditional media such as email, IRC, and modern media such as blogs.

The one big “advantage” I keep hearing, is that it makes it easy to find others.  Again… you don’t need these social networking sites for that.  There are two ways you can achieve what these sites give you:

Keep your identity consistent.  If you like being known by a certain nickname, then use that nickname.  You can also put your real name up there too if you wish, and anything else that identifies you.

In my case, there are three identifying keywords that will locate me in many search engines: my full real name, my nickname, and my radio callsign.

The major thing that social networking sites offer however, is friendship lists.  Guess what… good ol’e HTML provides that already.  And blogs these days offer XFN.  You simply link to your friends’ blogs/webpages… and voila… your friendship is instantly publicised.  Many search engines also track links between sites — so they will also pick up on these links.

What are the advantages in having your own blog/site?  Well, you can have all the bells and whistles you like.  Want to post videos?  No worries, there are tools for doing exactly that, and embedding them in your blog posts.  The other big advantage, is you’re totally in control — you own the content, and you’re responsible for it.

How about messaging?  Well… you can add that to your blog… there are facilities that can accept such addons.  Or there’s a plethora of tools already out there… such as IRC, XMPP, MSN Messenger (dare I mention it), and of course, plain old email.

To those who are already on these social networking sites.  Great… you’re happy where you are… this is fine.  However, don’t be disappointed if the rest of us, who may likewise be happy with where we are on the web, don’t come rushing to join you.

I’ve been doing some thinking today.  I haven’t been in the amateur radio gig very long… I got my license in mid January, and I’ve been active mostly on the 2m and 70cm bands for the past few months.

The last month saw me acquire the parts needed for a HF station, and so lately I’ve also been poking around on 40m and 80m too.  I’ll admit I’m still very new to the scene, getting to know what bands are best in what conditions, and making a small number of contacts.

I’ve been very active lately on 70cm on the Mt. Coot-tha repeater, VK4RBC (438.525MHz), and have been on the odd occasion, tried making contact on various frequencies on HF.

At BARCfest this year, a number of commercial traders were present, showing off the latest and greatest from two of the big communications companies out there… ICom and Yaesu.  It was at BARCfest, that I picked up my current HF rig, a Kenwood TS-120S, and a few sellers had a number of older rigs on sale.

Now this particular rig is quite old… according to the eHam site, they are 1980s vintage, although the exact date my rig was manufactured is unclear.  As far as features, it’s basic… SSB and CW modes, coverage of 80m, 40m, 20m, 15m and 10m, and around 100W output.  For my needs, okay, the power output is overkill, but it’s sufficient.  In fact, the power output is good, as if there is an emergency, I have the extra power to make contact.

At BARCfest however, there were some of the very latest rigs on display.  There was one Yaesu base station monster being shown off by Kyle Communications, I can’t recall what model, but its (discounted!) price tag was around AU$8000.  This thing did just about everything except errect its own antenna and make you coffee.  SSTV, RTTY, Packet, DSP filtering, you name it, it had it.  Very impressive, but are all these gratuituous bells and whistles really needed?

One thing I like about the rig I have, is that the handbook includes full schematics of the transceiver circuitry, with explainations on how it works.  It’s all implemented using solid state components that are easily sourced.  In fact, the handbook has some hand-written notes suggesting that the thing has been serviced a couple of times before hand already.  Being basic in features, has enabled it to be serviced, and I suspect that I should have this rig for a very long time, as long as I can get replacement parts — I see no reason why it shouldn’t continue operating for years to come.

However, rigs like the one I described above, the average operator, I suspect, would be helpless to try and fix a complex beast like that.  There’s just so much that could go wrong, and loads of specialised components that are purpose built for it.  Sure, it might be off-the-shelf DSPs and microcontrollers in use… you might be able to buy replacements… but where do you go to get them reprogrammed so they perform the function for which they are intended?

Even my handheld, a Kenwood TH-F7E, is a rather complicated beast.  It has a small microcontroller in it, and a lot of integrated circuitry, that I couldn’t possibly fix if something went wrong.  I bought it because it had FM transmit capability on 2m and 70cm (the only two VHF/UHF bands I’m permitted on presently) and it could receive AM, {,W,N}FM, SSB and CW over a wide range from 100kHz through to about 1.3GHz.  Now okay, in order to minaturise the device, it was necessary for specialised components to be used here… that’s fair enough, but I can forget doing much in the ways of repairs.

I believe that base station rigs are getting overly complicated these days — we really need to get back to basics.  For someone like myself, I really only need a few basic features:

• Coverage of all the analogue modes: CW, AM, FM and SSB
• Reasonable output power
• Good sensitivity/selectivity
• Digital readout

All of this (except digital readout) can be implemented with analogue electronics.

Digital modes in my book are better implemented on a desktop PC.  Computers these days are quite capable of doing software DSP… I don’t see any reason why it is necessary for the transceiver to do all that.  A small microcontroller inside the rig to provide PC control, and memory banks, no worries… but that’s about as complicated as it needs to be in my opinion.

Heck, there’s no reason why some of this couldn’t be modular — that is, the rig works without the microcontroller.  The microcontroller would just be responsible for loading/storing VFO frequencies, and switching modes — if it’s absent, this just gets done manually by the user.  The controls on the front would just manipulate digital flip flops, that could also be driven by the microcontroller.

The upshot is, a rig like the above, could be made quite robust… and reasonably inexpensive.  Some of us don’t need the frills — or if they do, are sufficiently knowledgable enough to make them ourselves.  There are people who will demand very fancy rigs, and that’s fine… there’s plenty in the market now to cater for that group of operators, but for the rest of us, I think a lot could be gained from reducing the complexity in current transceivers.

I’ve been pondering this idea for a while now. When I’m at home, I like to listen to my music… and sometimes, talk to people using VoIP. One big bug-bear I have, however, is being tethered to a desk by the cord of a headset.

Now… I basically have a few options:

• Cordless headphones (either infra-red or radio) — but these usually are receive-only. I’d need to rig up some sort of cordless microphone to transmit a signal the other way.
• Bluetooth headset — but they’re much too expensive, and I have no idea how well Linux works with them.

I’ve heard comments that both of the above options, have somewhat lesser audio quality, than a wired set. Many cordless headphones operating on radio, use stereo wideband FM to transmit a signal with a bandwidth of approximately 15KHz/channel. This is okay for what I want, but if I can do better, I might as well aim for it.

Bluetooth headsets offering the A2DP profile, may do better, but they do it through the use of lossy compression. To be honest though, I’m also concerned with compatibility — I don’t have any Bluetooth interfaces on my computers so I’m up for a dongle. My phone (a Nokia 3310… yes, I’ve had it since 2001) doesn’t support Bluetooth, thus the only device I’d be able to use it with, is my laptop. I don’t have a lot of money to experiment — and headsets of this nature cost around AU$250 or more.

So I’m looking at homebrewing a set. Looking at the ACMA radio frequency class licenses, it would seem these devices are classed under the LIPD class license. I’ll have to double check with the ACMA on this… but looking at the gory details, it would seem there are a few bands that are allocated under this license for this purpose…

• 88MHz – 108MHz (FM broadcast band) with 180kHz bandwidth and maximum EIRP of 10µW
• 174MHz – 230MHz (VHF television) with 330kHz bandwidth and maximum EIRP of 3mW
• 520MHz – 820MHz (UHF television) with 330kHz bandwidth and maximum EIRP of 100mW

Now… out of these… the 520MHz-820MHz band has the most liberal power limit of the three, and is also the least populated of the three bands. The catch is… all three of these have to use FM.

There are three signals to be transmitted in two different directions for this project…

• Two 25kHz audio channels, transmitted by base station to be received by the headset.
• A single 25KHz audio channel, transmitted by headset back to the base station.

For the headset microphone->base station path, this is trivial… I’ll just use one frequency to transmit a 25kHz mono signal, modulated on a wideband FM carrier. Easy. The difficult bit, is the other direction.

Stereo FM is normally achieved through the use of a subcarrier technique. The left and right channels are transformed into two signals that I call the mono signal (left + right), and the differential (left – right). They’re both band-limited to 15kHz. The mono signal is sent at baseband, with the differential modulated using a DSBSC subcarrier at 38kHz. The entire modulating signal has a bandwidth of 53kHz, generated by these two 15kHz sources.

My idea… is to use single sideband to conserve the bandwidth a bit. I’m undecided as to how I’ll transmit the left and right channels, whether I transmit them separately, or using the mono+differential technique discussed earlier. However it’s done… the plan is that one signal will be transmitted at baseband, and the other… using upper-sideband at approximately 30kHz. The entire modulating signal will have a bandwidth of approximately 55kHz, generated from two 25kHz sources. By reducing the bandwidth of the modulating signal, I hope to improve the noise immunity of my system so I can rely on minimal transmission power.

I have covered the principles behind single-sideband transmission, including simulating a Hartley modulator using Matlab. But looking around, I can’t see any schematic or notes on a Hilbert transform. It should be noted that a real-world Hilbert transform is an approximation, since the theoretical one is non-causal — this is why Harley modulators have a compensating delay.

There’s notes on how to implement them using discrete signal processing techniques, but I really don’t want the complexity of a DSP in something so trivial. I know it can, and has, been implemented using analogue electronics. If anyone knows of a simple, easy-to-follow schematic or notes on the topic… I’d be greatly interested.

Looking around I’ve found these documents… but if people know of others, I’m all ears.

• Google Query: phase shift schematic
  • Transistor/Diode Phase Shift Ladders
  • K0JD – Phasing Network Notes for R2 Receiver

I had a bit of a crazy idea today. Some would think I had a little too much spare time on my hands … but maybe there’s a point to this insanity.

Many of us have old computers laying about. Now, “old” is a subjective term. As goes the Weird Al song, “All About the Pentiums”…

You say you’ve had your PC for over a week?
Throw it away man — it’s an antique!

(Well, that’s how I remeber it… I might be paraphrasing a little.)

Not everybody needs a fancy box to do simple tasks. Pentium-class systems, and high-end i486 systems make quite decent X-terminals. As slow as early 486s and 386s are, they still are useful in situations where you just need a router or DHCP server (for example) to service a small home network.

I’m planning to put my 386 into active service. My Qube2 sits in my laundry, which is great. It’s cool, it’s a headless box with no need for direct interaction.

But interacting with the serial console is a pain, I have to get my laptop out, and plug it in. Thus I probably don’t do as much kernel testing as I should.

The 386 should be fast enough for this task — all it needs to run, is sshd and minicom. For a single user. Gentoo using uClibc sounds like an ideal platform. Why?

• Minimum bloat: I merge what I need, and nothing more
• uClibc is targetted at low-memory, low-processing-power computers
• Gentoo gives me fine-grained control regarding what features I enable and disable.

Now the box is rather slow booting Gentoo. If I boot root-over-NFS, it takes about 30-35 minutes. I can reduce this to about 20 minutes when loading from a local HDD (narrow SCSI, as it happens), but I haven’t got far installing it due to problems with flakey disks. The kernel reports a BogoMIPS reading of about 3.9~4.2 when running at full-speed (33MHz), and about 1.6 with the “turbo” feature disabled.

Once I get it going however, it should simply be a matter of re-merging dropbear sshd (the default one in the Gentoo/uClibc stages dies with a SIGILL), merging minicom and a bootloader, and voila.

Any updates can be done via a chroot on a faster box, then the binaries shipped to the 386. Bootup time isn’t an issue, since the box can just sit there running — 386s don’t chew that much power.

This is quite low down in my priorities, at the moment I’m concentrating more on getting Gentoo/MIPS 2007.1 out the door, hopefully with some newer netboot images for Cobalt, and maybe some first ever boot images for Loongson.

But after that, I may look at what the Gentoo/Embedded people have (particularly GNAP) and see if that can be adapted to suit the needs of older computers.

I see no reason why this can’t be done — I’d much rather see the code in Gentoo streamlined to work better on older computers, than to see the specs increased, as this streamlining benefits all — not just those with few CPU cycles to spare.