Blogospheric Refraction

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.

Seriously… don’t ask.

Once upon a time, I used to know quite a bit about running a PC with the Windows operating system.  People used to turn to me for assistance in solving technical issues with computers.  This was fine, I was happy with that.  I still am happy to assist in areas where I am knowledgeable.

The Microsoft world today, however, is not a field with which I am comfortable anymore.  The Windows OS has changed to such a degree… and with all the technical issues faced by users of this OS… I have lost all patience with it.  I almost never use it at home or at university unless absolutely necessary.

So long is it since I’ve used the OS, I can no longer recall the layout well enough to guide people without seeing it in front of me… and of course, Microsoft keeps changing the layout at every given opportunity.  Add to this the constantly changing procedures for maintenance… it’s a nightmare to keep track of.

To those around me… if you choose to use this OS… that is fine.  Your personal choice, not mine.  Have a question?  I may be able to give some hints… but you are on your own… I now refuse to spend time trying to fix the issues thrown up by this foreign and arcane environment.  I have wasted much energy, fixing the troubles that in my opinion, should not have occurred in the first place.

I don’t know anything about this OS anymore… I left that community a long time ago.  Just because I have been using a computer for much of my life, does not mean that I am an expert in all fields of computing… and to the Windows users, I repeat… don’t ask, as refusal may offend.

Did anyone happen to visit Google today? Those who haven’t… if it isn’t too late, have a squiz now.  Update: Google have reverted back to their old logo… the one they had up is pictured below.

Yeah… I saw it and said… WTF… then it hit me what I was looking at. You’d think with the number of times I’ve heard CW on the air, I’d have recognised it straight off.

Anyway… happy birthday to you Samuel, and thank-you for providing us with this wonderful low-bandwidth mode that still sees use today. One of these days, I’ll actually get around to having a QSO on this mode.

- – • • •   • • • – -      • • – •   • – •   – - -   – -      • • • –   – • -   • • • • –   – -   • • •   • – • •

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.

This is mainly for my own reference… but may be useful to others, so I’ll publish it here.  We have two routers, one which we keep as a spare, is a D-Link DSL-504 (not a 504T… and not a Generation II) 4-port ethernet switch and router.

Recently, I noticed the unit was not firing up — the status LED remained off, and I could not remember what the IP address was for the life of me (I had changed it from its default, and had disabled the DHCP server).  As it turned out… it didn’t have one, the flash memory had become corrupt, and so it was not booting.

These routers have a RS-232 serial port on the back for a console, to which you plug in a plain 9-pin serial extension lead (not a null-modem) and hook up your favourite serial terminal program.  The unit spits out its messages at 9600 baud 8n1.  In the above scenario, you will notice the bootloader (PP boot) complain that there is “no ATMOS image present” or some such message, and it’ll drop you to a prompt.

Firstly, you’ll need the flash image to load back in.  You get that from the D-Link Australia website, just go to their support section and look up DSL-504.  You’ll find the firmware under the downloads, it comes in a 3MB ZIP file, when you decompress this, there’ll be a .bin file inside — this is your image.

There are two ways to stuff this image back into the device.  The most obvious is the way D-Link tell you to… that is… enter xmodem at the prompt, then upload it using the Xmodem protocol.  Slow… it takes about 30mins.  There is a faster way.

These routers are capable of booting off a network in much the same manner as a SGI workstation… that is… obtaining an IP address via BOOTP, then downloading the above image via TFTP.  The concept is exactly the same.  Set up your boot server as per the Gentoo/MIPS handbook — you won’t need the special kernel parameters… but the host setting will look identical.  Just place the .bin file you obtained earlier in your TFTP root directory, and point the filename parameter at it.  If you don’t know your router’s MAC address, type tftp and it’ll tell you, then reset the router.

Once all the settings are in, and the daemons are started… turn to your terminal emulator, and issue the tftp command. It’ll immediately download the image and boot it, should take a few seconds. It’ll tell you to type quit to boot, do this.

When it prompts for a password, just press ENTER… the password is blank (not “private” as D-Link will have you believe).

Upon booting, type config save to store the settings… Don’t make the mistake I made at this point — I tried mucking with the settings via serial console and had to start over (the webserver kept giving me a blank page). If you need to, isolate it from your network at this point, just plug in a machine with a web browser.

If you decide to muck around, and have to reset it… at the prompt, type flashfs wipe followed by restart, and you’ll be back to step 1.

From here, you should be able to visit the router’s homepage and configure it as if pulled straight out of the box.

Well, after a few minor hiccups with delivery (basically I wasn’t home when the first delivery was made, the second delivery — apparently the driver knocks on the door with a very delicate touch), I have at last gotten hold of one of these devices.

Out of the box, they run Debian Linux/MIPS, with just about every app you could think of that would be useful on a desktop.  They feature nicely integrated power management… and… looking at the defconfig for these devices, there seems to be the hint of suspend-to-disk capability, although I’m not sure how well developed it is.  Lemote have pulled off a lot of voodoo at the kernel level to get this going.  There are not a lot of MIPS systems that have power management to worry about.

Performance, well subjectively, it seems about on par with my old laptop, a Toshiba TE2100 (Pentium 4M 1.7GHz)  for responsiveness.  It runs a 64-bit kernel out-of-the-box, although runs a 32-bit userland (O32).

Ergonomics, for the size of the machine, it is not bad to use.  I think I found my old PDA more painful… this thing once you get used to the positions of keys, is quite usable.  I’m still getting used to the right-hand shift key being small, the backtick being above the 1 key (consequently, those numbers being one position to the left of where I expect), and for a while, I kept hitting S instead of A.  I find myself constantly hitting the up-arrow when typing capital letters, hitting Fn instead of Ctrl, and sometimes bumping the touch pad… but this will of course settle down as I get used to the machine.  Given the space available, Lemote have done well with the design of the machine.

Video capability seems quite good for 2D, there seems to be little evidence of 3D acceleration, but I guess that will come before long.  It did struggle to play a DVD earlier, however this is not conclusive, since there are a number of factors at play needed to play video smoothly.  I shall know more as I experiment.

What about Gentoo?  Well, I’m preparing new stages… I’ve had a few hiccups there, mainly glibc being difficult.  In the short term, I’ll stick with Debian on this box while I find out what makes the device tick (Gentoo will lurk in a chroot), then I may move to a dual-boot or pure Gentoo environment.

Anyway, I’m off to play with my new toy.

Hi All,

Well, I’ve just dusted off the second Lemote Fulong here, and I’m booting it up for another round of stagebuilds. (Yes… I haven’t gotten around to locating and implementing the auto stagebuild scripts that everyone else seems to be using.)

I’m also getting a newer piece of MIPS kit… a Lemote Yeeloong is currently sitting at Brisbane Airport in a box with my name on it… hopefully it’ll be in my hands by Wednesday evening. This will enable support of Gentoo/MIPS on this platform, and will also allow me to do some MIPS testing of packages while on my many hours of travelling between Brisbane and Laidley and hours spent at university. It’s based on the Loongson 2F CPU, which implements the MIPS64 ISA (the Loongson 2Es in the Fulongs implements MIPS3), and is little-endian.

Hopefully this will mean the bug count will start to decline once more for the MIPS team.

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

The AWNOI net is a weekly evening net that starts at 10:00PM UTC+10 (or 9:30PM UTC+10 when daylight savings time is in effect) and continues until the last station falls asleep.
This recording is produced by myself using my HF set (Kenwood TS-120S), Yaesu FC-700 tuner and G5RV-like outdoor antenna.
My QTH is at The Gap, Brisbane, QLD.
Most of the stations participating, bar 3, are VK4 stations (two VK2s and one VK1).

If you’re a licensed amateur with equipment for 80m communications, feel free to join us at any time.

This recording was made 2009-01-30 and is available as Ogg/Speex, Ogg/Vorbis or MPEG4/AAC codecs.
A short highlights recording is also available, in MP3, Ogg/Vorbis or Speex.
(more…)

I took this photo more than 24 hours ago… I’m wondering what the “authorities” intend to do about it…

(And yes, it’s a real sign near the Brisbane Powerhouse museum, just along the river.)