July 2010

VK4MSL/BM: Photos of the current setup

Well, I’ve been riding a lot between West End and The Gap, and I get a lot of questions from people on the band about my setup. I was doing some repairs… one of the wires to the PTT had disconnected, luckily there was a 0V return via other connections… and so while I had the bike outside fixing that (it was too dark in the garage) I took the opportunity to snap some photos.

The light was fading at the time, so the pictures aren’t particularly great… I’ve touched them up to make them brighter, hence there’s a bit of noise in the photo… The last two showing the HF setup, required a flash (which I was trying to avoid due to the aluminum and reflectors)… and of course I didn’t spend time putting the FT-897D in the back… maybe later when I get everything tuned up and actually do make a true bicycle-mobile contact on HF (this one was not made mobile).

VK4MSL/BM on 2m

VK4MSL/BM on 2m: side view

Above, is the station in its entirety… fairly simple. The antenna is a plain 2m ground-plane, formed using a tunable mobile whip cut for 145.700MHz, the aluminum angle bracket makes up one counterpoise, and an additional counterpoise hangs out the back. Adjusting the angle has an influence on the SWR… in this arrangement, it works nicely.

VK4MSL/BM: Closeup of rear basket

VK4MSL/BM: Closeup of rear basket

Shown here is the rear basket where the FT-290R II (or FT-897D for HF) lurks… along with a 9Ah gel cell battery, which also powers the tail light. I haven’t been very neat about the cables. Two leads run from the front controls, the grey one (shielded) carries transmit/receive audio and the PTT, the blue one (Cat5e UTP) carries the four directional buttons — with spare wires connected to 0V. A DB15HD (“VGA”) connector terminates the cable at each end.

VK4MSL/BM: Radio controls

VK4MSL/BM: Radio controls

Remember how I mentioned the hand-mic in the last station was going to be temporary? Well… this is the arrangement here. Shown here is the PTT switch (red) and four directional buttons. Not all radios make use of all buttons … the FT-290R II uses only the up/down buttons, the FT-897D uses the right-hand button in addition for the “fast” button. Homebrew microcontroller-based radios I build will probably use all five shown for a menu interface. There’s no display in front of me, so don’t ask for an accurate signal report, I can tell you whether it’s a Q3 or a Q5, but any S-meter reading will be a wild guess. Future expansion of this may include a small potentiometer for a local volume control, and a small microcontroller-driven LCD that could be used to interface to the FT-897D’s CAT interface… but this is just early days.

Now… I did say I managed to mount a HF antenna on here and make a contact with it. The contact into VK5 that yielded this QSL card was made using a 6′ long CB whip… the station looked a lot like this:

VK4MSL/BM: HF Antenna

VK4MSL/BM: HF Antenna

The flash was needed here, took me a while to figure out where I had put the bracket (I don’t plan to ride with the HF antenna or bracket mounted very often). This is fortuitous in a way since you can now more visibly see the 2m antenna. The CB antenna mounts on a nearly identical bracket. I don’t bother with the radial out the back, as there’s no way I’ll make one long enough that would be practical. The antenna will need some work, in particular, either addition of a base-load coil, or modification, to make it resonant on the amateur bands.

VK4MSL/BM: Closeup of basket with HF mount

VK4MSL/BM: Closeup of basket with HF mount

With a small base-load coil, I should be able to make it a half-wave end-fed on 6m… some more and I should be able to make an end-fed quarter-wave on 10m. This will be the subject of future experiments. This tuning section will probably mount on top of the mounting itself, underneath the spring shown on the right.

And to answer the number one question I get from non-radio amateurs… no… I do not have a camera on my helmet (this is not a camera)… I am not broadcasting video. Kindly don’ t act like someone excited to be on television… you’re not. 😉

Gentoo/MIPS: Bootstrap of new stages

It has been a long time between drinks for Gentoo/MIPS… but at last, I’ve managed to get something rolling, and hopefully I should have some stages out by the end of the year.

What took me so long? A number of packages didn’t want to compile… particularly python-2.6 and gcc-4.4. The former exhibited various compiler errors… I think I’ve got that sussed now. The latter would compile xgcc, then that binary would promptly die with an Internal Compiler Error.

I couldn’t resolve the latter due to not having anything other than MIPS hardware at home for development. So when I managed to cobble together a Duron 900MHz, I was able to use that to cross-compile a minimal environment with a C-only gcc (it wouldn’t build without USE=nocxx) and supply a version of Python from my Yeeloong.

I now have the Qube2 busy running the bootstrap script, it has self-compiled its own python-2.6 now and is working through the other base-system packages. I found the Lemote boxes seemed to exhibit an odd lock-up at specific points of the build, but the Qube2 just keeps plodding along. Ahh well, they do say “slow and steady wins the race”.

Speaking of slow and steady, the Duron 900MHz decided to keel over this morning… so I’m not sure if I’ll be able to put together a similar environment to bootstrap the big-endian port, but we’ll see. There’s money in the budget for a new 6-core AMD Phenom II system in the near future though, so by the time I get Gentoo/MIPS little-endian up and running, I should have new hardware to tackle the big-endian port with.

On other news… it seems the next Linux.conf.au is going to be here in Brisbane… shock horror I might be able to attend this one. 😉

Open firmware

I was just reading back through the posts on Gentoo Universe… and Diego’s post regarding Free Software Washing Machines caught my eye.

There are many benefits for why free software firmware would be good… However, you’ve got to convince the marketeers and management of such companies that this is a good idea. This is not so simple. In extreme cases, you’ve also got to convince government… more on this later.

Take my current project at my workplace. We’re developing a new video intercom system. The devices are based on the Freescale i.MX27, and incorporate an 800×480 LCD, resistive touchscreen, USB port, ethernet (with PoE), mono internal speaker/microphone, handset interface and a small software-controlled relay. The audio interfaces are mono, but capable of sample rate up to 192kHz (limited to 96kHz by ALSA) and it wouldn’t be difficult to get stereo out of them. I wouldn’t mind buying one later on to play with at home … maybe one of the early ones with psychodelic colours (the first revisions didn’t have the LCD lines routed quite right) since we’ll want to sell the others. My role was with the audio CODEC, the TLV320AIC3204, some code for this is already on the ALSA-devel mailing list (the continued development of this driver is the mainly the reason why I want one for home).

They’re a fun little device to play with… and there may be some who might be interested in hacking such devices. They already run Linux… a few of them at my workplace run Gentoo even — mostly the test modules. However, the firmware for these, particularly at the higher levels will remain proprietary. I’ve released the CODEC driver as GPLed software … and ideally I’d like to see the rest of the kernel changes released openly. I’ll play this by ear first however. The good news is that if someone wanted to port Linux over from scratch, it’s real easy to get Linux booting on these things (tip: start with the Freescale MX27ADS support, I ported kernel 2.6.34 this way).

The CODEC driver I’m mostly happy with… the machine/fabric driver I use for ASoC on this thing however … let’s just say, it’s a hack. The CODEC’s clock is generated from a pin on the MCU, and so I have to use some rather “creative” methods to configure that clock and make it available to the CODEC. There’s no way it would be accepted into mainline… and we’ve since found that clock drifts the moment you look at the chip funny. Ahh well, live and learn.

There’s also a GPIO module that allows us to use the keypad controller (which is not routed via IOMUX AFAIK) as a GPIO chip… similarly, it was a monkey-see-monkey-do hack… but I might be able to make that more acceptable to upstream.

So there’s the issue that such code is considered a bit of an embarrasment to its author. (I don’t speak of other code on these things, just the parts I have written!)

Secondly, there’s the thorny issue of intellectual property. The firmware on these VoIP stations incorporate a proprietary protocol for VoIP. Why not go with SIP? Basically this protocol was designed to run on their earlier products… which were all based on small 8-bit microcontrollers. SIP was just too much for a ~40MHz 8-bit micro like the Rabbit 3000. Thus a simpler protocol was developed. I have no idea about the specifics, other than the fact that it was developed to suit the lower-end microcontrollers in use at the time. I think in future the newer units may wind up moving over to SIP, but for now, deadlines are on top of us, we’ll go with what we know works for now. Given how much of Jacques’ business relies on this protocol, I don’t see them opening it up to their competitors anytime soon.

Finally, there’s one of support. The modules we use were purchsed from Ka-Ro Electronics, and the kernel we use was supplied by them directly… based on kernel 2.6.28. To my knowledge, there’s no openly-available patches that allow a user to run the latest Linux kernels on the Ka-Ro modules — you more or less either have to forward port the patches that Ka-Ro provide, or try to hack up a patch of your own (this is what I did). Now, Ka-Ro clearly have their reasons for not openly releasing a patch for their hardware, I haven’t enquired as to why this is… I have a patch that gets their TX27 module working under kernel 2.6.34 (theoretically newer kernels too) but I’ll probably run it by Ka-Ro themselves before I release it.

Ka-Ro presumably will only provide support for the kernels and board-support packages that they provide, which is reasonable. They started with a known stable kernel, and started their development on that (it was a year old before they touched it), and released it knowing it would be reliable. Obviously they cannot provide the same guarantee to newer kernels… because they won’t necessarily know what might have changed — you could encounter severe bugs that were not their doing and thus, a lot of time and effort is spent trying to fix a problem that was not their doing. Similarly, at Jacques, we don’t have the resources to answer questions from inquisitive geeks wanting to turn the monitor station in their apartment into a music player or web server. At best, we’d be able to put some of it online, but we’d have to say “Sorry, can’t answer questions, you’ll just have to work it out yourself.”

In the Amateur Radio world… homebrewing, and home-modification of equipment is common. In fact, once upon a time, it was the only way to get on air unless you had a lot of money! Thankfully, one can now purchase a radio station for far less money than it would cost to design, build, and debug, and the build quality in general will be much higher. Of course if you do go the homebrew route, you’ll at least be wiser and richer for the experience.

The difficulty with homebrewing radios these days, is getting parts, and working with them. Back in the day, things were valves, and discrete components… maybe the odd DIP-packaged IC… and no more than double-layer PCBs. The two Yaesu FT-897Ds I have, incorporate multi-layer boards (4 I think) and SMD devices. One got cooked in a storm, frying the microphone preamp and a DDS chip (although the finals appear to be okay, and it makes a good shortwave receiver). The complexity of this radio made it impossible to repair, and so I had to buy a second one (or rather, insurance did). Now, I’m mostly very happy with this radio, but there are one or two niggles I have with regards to its interface… and a few features I’d like to implement.

Yaesu do provide a block diagram of their transceiver, but they don’t provide the code to the Hitachi H8300 microcontrollers that reside inside the unit… and there are several of them. Suppose I get the microphone circuitry fixed in the cooked one… I might be able to get FM functionality back. The DDS chip was responsible for the carrier sidetone generation with SSB, and for generating the carrier in AM and CW. It’s no longer manufactured… and the chances of a different chip being compatible with the existing firmware are next to zilch. I’ve still got it… I intend to build my own radio out of the bits that are left over (the Phoenix897 project) … it’ll be here that I’ll be able to explore the possibilities in terms of implemented features.

However, one challenge will be designing and producing PCBs that will be suitable for use with today’s devices. The construction methods of the past such as wire-wrap and dead-bug, work fine for discrete components, work okay for DIPs, SOICs, TSSOPs and QFPs… but I’m afraid you can forget it on a BGA or LCC. So you have to build a proper PCB, and the track work has to be very fine. Then there’s the actual fitting of components onto the board.

The boards I was building for the electric harvester project I was involved in at Laidley didn’t involve anything smaller than TSSOP ICs, or discrete SMD capacitors/resistors smaller than 0603 (most were 0805) … easily hand-soldered. At Jacques we’re dealing with components even smaller… they don’t get soldered by hand — instead they’re oven baked. It takes a few hours to lay out a board, and the slightest bump will scatter all those carefully placed components. The smaller components are not marked… with no means of identifying them, they get tossed. (And yes, I did accidentally bump some one Friday evening… not proud of that at all.) I can see me going through a lot of components because a PCB gets knocked for six.

So the modern components are much harder to work with. An ideal solution to my dillema would be a pre-built radio that I can customise the firmware on. Alas, the closest I’ll get to this, is SDR kits such as the Softrock… even they have to be supplied in “kit” form. FCC rules basically forbid manufacturers from producing off-the-shelf transceivers with customisable firmware… or at least that’s how I understand it. Not sure whether the EU works the same… and the ACMA’s EMC directives are more or less based on the FCC’s… so I suspect that’s the issue here.

More or less the worry is that you might hack the firmware to circumvent the bandplan restrictions that may exist in your area (i.e. modifying a transceiver to broadcast WFM on the 88-108MHz band for example). I’m not sure how this is different to homebrewing a set, or modifying a set yourself … but being able to just hack the firmware yourself is not something the various spectrum management organisations want us to do.

This is sad in a way… I think there would be a big market in having a radio that had completely opensource firmware.

One of my big niggles is that the transceiver I have won’t remember power limits by mode… I can do 100W PEP, but only 30W average, so for FM I find myself constantly winding the power back to 30W, but the moment I kick the radio into SSB, I’m winding back up to 100W. More than once I’ve accidentally called into a FM net on 2m using 50W because I had been using 2m SSB the previous night (my radio only does 50W on 2m)… or accidentally found myself transmitting 100W on a 10m FM repeater.

IRLP/Echolink functionality, and memory channel organisations are other improvements… remembering node numbers is a chore I could well do without… and I find there’s often not enough channels to cover all the repeaters in the country… or it’s difficult to organise them in a manner that allows quick retrieval. Modern storage, modern microcontrollers, I see no reason why this can’t be stuffed into a relational DB (something akin to SQLite) so that you just whistle up the repeater by location, callsign or frequency… and if it has IRLP or Echolink, be able to just choose a node, browsing by country/state or provence… put your callsign across then press a single button to dial it for you… then at the touch of a button, it dials “73” for you to close the link. (or maybe after a fixed period of inactivity, it can put your ident across, wait 10 seconds, then dial “73” for you).

My old TH-F7E could remember 10 DTMF code sequences and 400 channels, the memory channels just being sequentially accessed… so you really had to put careful thought into ordering or you were relying on cheat sheets to figure things out, in that case why even have the memory channels at all?

I’d also be nice if the set could do HF CB… I can receive it… I see no reason why the set can’t just automatically drop its power to the 12W and restrict its modes to USB/LSB and set the channel spacing accordingly as per the CBRS. I can make a radio with opensource firmware do that… then again, I could also make it do 100W on that same band, and violate the CBRS. One has to convince the government that we won’t try to do the latter (although there are plenty that already do).

All of the above I’ll probably look at implementing when I go and rebuild the old FT897D … and you can bet your bottom dollar I would have tackled some of them already had there been opensource firmware on these rigs. However, the red tape one would have to deal with in order to make such a radio available on the market, I can well understand why the firmware on these things is proprietary.

In a perfect world … if only such a utopia existed!