linux

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!