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.

Hi all…

I’ve now uploaded the stages for Gentoo/MIPS 2008.0.  I’m hoping to get these pushed out to mirrors shortly, but in the meantime, you can find them on my devspace.  These stages need a fairly modern kernel, 2.6.19 or later, ideally  2.6.2x-series, otherwise you’ll strike issues with rm doing strange things (as people have reported already).  I have some kernel images for IP30, IP32, Loongson and Cobalt that should work with these stages.

These are only freshly compiled, and haven’t undergone much testing, so I’d appreciate it if some brave souls could give them a try and report back.  Stages are available for:

• Big Endian Systems (MIPS1, MIPS3 and MIPS4)
• Little Endian Systems (MIPSel1, MIPSel3 and MIPSel4)

Enjoy.

Last Friday (23rd), was the night of the Brisbane Amateur Radio Club Annual General Meeting. Anyone who has been involved in a small club or community group, knows how dangerous it can be to attend these meetings — if you don’t intend to stand for a position, especially when most of the people holding executive positions are stepping down.

Well, needless to stay, the vast majority of the membership was away… leaving about 8~9 of us in the room. One of the newer members wound up with job of President, along with myself scoring the job of editor for QSP, the club newsletter. There will be more on this in the next issue of QSP. I’m still toying with ways I can produce that newsletter efficiently — the three options I’m looking at are (in order of preference): LaTeX, OpenOffice.org and Scribus. I put Scribus last as I’m not familiar with it, and at last check, didn’t easily run on Win32. LaTeX is available for Win32 as part of Cygwin amongst other sources, as is OpenOffice.org.

In any case, this is a new role for me, and I look forward to the challenge.

News items for QSP can be sent directly to the new email alias I have for this: qspnews@longQlanRdcMlan.yi.org (remove the interference). Preferred formats for text are plain ASCII text (just put it in the body of the email), OpenDocument Text (as produced by OpenOffice.org), HTML, LyX and LaTeX. Preferred formats for diagrams are PDF, SVG, EPS, PNG or JPEG (the last one is best reserved for photos) — just indicate in the text roughly where you want these diagrams put, and I’ll try to fit them in as best I can.

In other news, I now have some HF kit. BARCfest saw me acquiring a second hand transceiver, a Kenwood TS-120S. Presently I’ve just got it hooked to a simple 40m dipole, and I mainly hover around the WICEN frequency on 40m (7.075MHz LSB). The eventual plan is to set up a full-wavelength 40m loop in the ceiling space of the house (we have a tiled roof) and hook that up to an ATU. I have purchased an ATU, and hope that will arrive some time this week, so before long, I should be contactable on HF. I’m permitted 10W PEP on 80m, 40m, 15m and 10m, and am able to transmit USB, LSB and (once I learn morse), CW.

Hi All…

Just figured I’d bring you all up to date on how the new release is coming along. At this time, all little-endian MIPS builds are complete… and the big-endian builds are nearing their completion, with the MIPS3 BE build expected to be completed in a few hours. Only MIPS4 BE remains.

A number of users have had issues with the beta stages that I released earlier, in particular, there are known oddities with rsync and rm. These oddities arise when an old kernel (<2.6.19) is used. You’ll want at least kernel 2.6.20, preferably 2.6.22 or 2.6.23 running on the machine to use these stages.

Using the existing netboot images, you should still be able to at least set the disk up, extract the contents, then boot a precompiled kernel that’s sufficiently recent. How do you get the kernel? Well, for an up-to-date kernel, your easiest bet is to cross-compile. On a fast box (x86, AMD64… whatever), install genkernel, then use the command genkernel -t mips64-unknown-linux-gnu -S1 (or mips64el, or use mips/mipsel for a 32-bit compiler) to generate the cross compiler. Then use ebuild /path/to/mips-sources-VERSION.ebuild unpack to unpack a copy of the sources to your PORTAGE_TMPDIR (/var/tmp/portage by default). Then follow the instructions in the handbook as per normal, specifying CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el…) when running make.

To get the kernel modules onto the machine, run make modules_install INSTALL_MOD_PATH=/somewhere, then tar these up. Then from the SGI box, use scp inside the chroot to download them, and unpack into /. Use the same procedure to fetch the vmlinux (or vmlinux.32) binary from your build host.

I’ve put up a new netboot image for Cobalt, although I’ve noticed 2.6.23 mips-sources has some stability issues with Cobalt, so I may yet put up another netboot image. Lemote users should find the existing images are sufficiently recent to run these stages, so I haven’t worried about putting newer images up for that platform. I’m not sure how the big-endian netboot images are constructed, so at this time, I’m not able to provide images for these platforms. (Plus, I can only test R4k IP22, IP28 or RM5k2 IP32… my Octane is dead for now.)

I hope to be uploading some material in a fortnight’s time for you to all try out.

Hi all…

Lately I’ve been busy with university stuff. In particular, my final year project, which is investigating Controller Area Networks, in the context of the Atmel AT91SAM7X256 MCU.  These microcontrollers are a low-cost system-on-chip based around the ARM7TMDI core.  This particular one includes 64KB RAM, 256KB flash, RS-232, device-side USB 2.0, 10/100Mbps ethernet, and of course, a CAN interface.

When I first started looking into this project, I was thinking about using Linux and SocketCAN… well, needless to say the moment I saw the specs on the exact board I was using (the AT91SAM7X-EK), I soon realised Linux was simply out of the question.  That doesn’t mean however, that one is stuck to using proprietary kernels and toolchains.  The following, are some notes on how to code for these things… and where I’m at.

Kernel

You don’t have to use a kernel of course, you can code bare-iron, but I decided to go with a multitasking kernel to make my life easier — I can code each thread to do something basic, and let the kernel manage the IPC and task switching for me, hooking them together.  There are a few options out there, but so far the option I’m liking the most, is the FreeRTOS kernel.  This kernel is free software under the GNU GPL, and supports many platforms, including ARM7.

Toolchain

There are a few compiler toolchains you can use for this board.  The DVD that comes with the board, includes a version of IAR Embedded Workbench, which isn’t too bad, but unless you pay for a license, your code size is limited to 32KB.  The GNU toolchain however, is very mature for the ARM7 platform… and getting a toolchain up and running isn’t too difficult.

FreeRTOS can be built using IAR, and indeed to get me started, that’s what I did.  Once I was comfortable with the system though, I turned my attention to getting a GNU toolchain running on my laptop.  The toolchain needs to be built, targetting the arm-elf platform, using the newlib C library.  Thumb mode, multilib, and interworking support need to be included in this toolchain to build FreeRTOS.  There are numerous prebuilt toolchains, and guides on how to do them from source… but I wound up going my own way…

In my devspace, you’ll find a compressed Makefile.  Download this into an empty directory, decompress it, then rename it to Makefile.  Gentoo users, may find it helpful to symlink their distfiles directory (/usr/portage/distfiles for most people) to ’src’ — the Makefile uses the same toolchain sources as Gentoo.  Edit Makefile to point to your local Gentoo mirror (I use these mirrors because they’ve got all the sources in one place), then run make.  With luck, it’ll build everything and install it for you.  It runs as a user, then uses sudo to copy the files to /usr/local where they are to be installed.

At the end, you’ll be left with a full arm-elf toolchain, based on GCC 4.2.3, binutils 2.18 and newlib 1.15.0.

Building the FreeRTOS kernel

FreeRTOS comes with numerous demos which can be used as starting points for your own projects.  The best one for the AT91SAM7X using GCC, is the lwIP_Rowley_ARM7 demo.  This demo does three things:

1. Runs a webserver displaying some task statistics
2. Flashes the onboard LEDs to indicate it’s working
3. Emulates a CDC-ACM device, writing characters to it at 115200 baud 8N1.

To start, go into the Demos/lwIP_Rowley_ARM7 directory, and rename ‘makefile’ to ‘Makefile’.  To set the IP configuration, edit EMAC/SAM7_EMAC.h and change the IP address settings as appropriate (line 69 onwards).  Save this, then type make.  It should go ahead and build an rtosdemo.bin file, which is your executable to be flashed.

Flashing the project

This is where my usage of free software came unstuck.  There are a few projects that theoretically allow you to flash these devices.  The kit comes with a SAM-ICE J-Tag, which is equivalent to the J-Link device developed by Segger.  These, to my knowledge, do not work using J-Tag tools available under Linux.  You could use one of the Wiggler-style J-Tag cables, but I don’t have one of those at my disposal.

The AT91SAM7X has a trick up its sleeve though.  If you power the board up for a few seconds with the ERASE jumper enabled, power it down, then power it back up with the ERASE jumper removed, it’ll revert back to using SAM-BA firmware.  SAM-BA allows for the board to be flashed either via the DBGU serial port, or, via a CDC-ACM USB device.  Tools such as Sam_I_Am, then connect to the /dev/ttyACM0 device created.  For this to work, a small patch needs to be applied to the cdc-acm driver in the Linux kernel (This same patch also adds support for the FreeRTOS CDC device created by the above demo).

For me, this has been the most promising, but hasn’t quite gotten things going… I’m able to flash the device, but for some reason, it sees it as an AT91SAM7S256… and the thing won’t boot.  If anyone has some pointers as to what could be going wrong, I’m all ears.

At the moment, I’m using the SAM-BA flashing utility available from Atmel’s website free of charge.  This is a Windows NT utility requiring administrator privileges, which is suboptimal, but so be it, it works, I just boot my desktop PC into Windows 2000, and access the output binary via SMB.  This works, and isn’t too painful.  It may also work in a VM, I haven’t tried yet.

I’ll keep tinkering with the Linux utilities, because I feel it’s almost there… I’ve thrown this post up so that others who may be looking for this information, have somewhere to work from.  Apart from the little issues I’ve had, I’ve found this board quite enjoyable to work with.  I can use mostly my own tools to work with the files, and the C compiler is both stable (unlike the GNU toolchain for Altera Nios II) and fully ANSI C compliant (unlike the Z-World compiler used on Rabbit Semiconductor devices) — a nice change indeed.

http://en.wikipedia.org/wiki/ANZAC

Hi all…

There seems to be a little confusion as to whether the PS2 is supported by Gentoo. To clarify, it isn’t. There was never any effort to officially support the PS2. Some unofficial work did begin some years ago, however that work ceased fairly early on, and there has been no interest in continuing it.

There are a number of technical reasons why the PS2 is not supported.

First and foremost, the CPU is a real bastardised piece of work. It implements a custom instruction set, which is a hodge podge of MIPS I, MIPS II, MIPS III and MIPS IV, with some special instructions thrown in. It doesn’t fully implement any of the aforementioned instruction sets. So binaries such as my mipsel1 stages, will not work — you’ll hit illegal instruction errors fairly early on.

Secondly, the patches necessary for the kernel, and toolchain, are based on a really ancient set of packages. The kernel released with the PlayStation II Linux kit (2.2.1), was a year old when the first PS2 hit the shelves. Not so bad then, but the kernel was never properly maintained. Even today, unofficial efforts have only gotten as far as 2.4.3x-series. The toolchain is still quite ancient, at best, gcc-3.3 from what I recall, is the best they’ve got. Maybe they’ve got as far as 3.4… who knows…

Thirdly, the memory on the PS2 is restricted to 32MB. This is soldered on-board, can’t be upgraded. Gentoo/MIPS will not build most packages with 32MB RAM. Once upon a time, I could just build stages with 64MB on my Qube2, if I shut down things like MySQL — not anymore, I need 128MB to do this today. uClibc could be feasible, but you’d still have problems with the “special” CPU. Virtual memory doesn’t help — even if you had 2YB of swap, it wouldn’t stop builds dying.

Other MIPS-based consoles, such as the original PlayStation (MIPS R3000-based) and the PlayStation Pocket (MMU-less MIPS32r2) are also not supported for similar reasons.  And we (MIPS team) don’t support the PlayStation 3 either — for that, you should talk to the PowerPC team.

Now… I have no complaints about answering questions about what we support/don’t support… but a few points… (this is where my rant starts by the way)

1. Write properly when in the IRC channel. If it’s one thing that’ll quickly get my back up, it’s SMS-like chat on IRC. I’m tolerant of spelling errors and grammatical mistakes, but I won’t tolerate laziness. If a word has vowels in it, include them! It’s not like it’s significantly more effort to press an additional button on a keyboard. If you’re using morse to drive the computer, or have a physical disability that makes typing difficult, fine, declare this up front, and all will be okay, but otherwise, there’s no excuse.
2. Read the documentation! It tells you what we support, and what we don’t. It’s likely your question is answered there already.
3. If we can’t help you with some non-supported platform, we mean it… don’t pester us about it, we’re not going to start supporting a new platform in 5 minutes flat.

The following arrived via email via the Department of Defence… figured you might appreciate it — clearly the Chinese are really keen — this road isn’t my cup of tea!

Try a mountain trail stroll in China …

First, let’s take the cable car up to the start of the trail

Now follow the path

Be sure to hold on to the railing

Keep an eye on the person in front of you

Be very careful when passing someone going in the opposite direction

Now just up a few steps (they are on the left in the picture)

It gets a little steeper here - so put your toes in the holes

A few more steps to go

Finally in sight, the Teahouse!

I’d go almost anywhere for a Beer but a cup of tea?

Hi All…

Whilst building a new netboot image for Cobalt systems, I discovered there’s a bug relating to the PCI handling in the latest kernel ebuild. In short, the pata_via driver is broken out-of-the-box, it’ll complain about being unable to register I/O resources, and the disks will be inaccessible.

To fix — download this patch, and apply it to your source tree using patch -p1 < patchfile, then rebuild your kernel (it’ll take a few seconds). You’ll notice the new kernel should boot successfully.

When Kumba returns, I’ll get him to add it to the mips-sources patchset so this is done automatically.

Hi All…

Those who have been trying out the 2008.0 beta stages I put out recently, probably will have ran into problems with tools like rm and touch not working properly.  It turns out, a series of kernel updates between 2.6.16 (what most of the netboot images are based on, except Cobalt which uses 2.6.13), and 2.6.19-rc5 (what my O2 runs), there have been changes to some of the system calls.  So the newer coreutils breaks on the older kernels.

I’m now in the process of updating the kernels used.  As I type this, I’m recompiling the Cobalt netboot image (same userland tools, just a newer kernel … at some point I’ll recompile the userland too), downloading the 2.6.20 kernel for IP28 users, and I’ll look into IP22 (r4k), IP30 and IP32 as well.

Sadly, R5k IP22 and IP27 will get ignored here — because I don’t have any suitable hardware to test them on.  Otherwise I’d update those too.

I’ll let you all know when the newer netboot images are available.