Thinktank

Geographic IPv6 using Maidenhead locators

A thought just occurred to me…

With addressing in IPv6, there’s enough addresses to cover every square metre of the earth’s surface with something like 100 addresses or so.  Not sure if a standard exists for mapping geographic co-ordinates to addresses, but one just occurred to me that I might try some day.

The Maidenhead locator system divides the world up into a series of squares.  At its coarsest level, it divides into zones which are each 10? latitude and 20? longitude.  There form a 18×18 grid, and are usually denoted by a letter.

Maidenhead Locator zones

Wikipedia: The world is divided into 324 (18²) Maidenhead fields.

These are divided further into grid squares, measuring 1? × 2? in size.  They form a 10×10 grid, and are usually addressed by a number…

Maidenhead grid squares

Wikipedia: Fields are divided into 100 squares each.

Within this, there are subsquares, representing 2.5’×5′ (that’s minutes, not feet) forming a 24×24 grid, addressed again by letter.  The grid square where I’m located, QG62LN represents an area that covers the suburbs of The Gap, the southwest bit of Enoggera, the northwest bit of Bardon, and the western end of Ashgrove.

Suppose we were to encode this maidenhead locator into the address.  It’s probably less useful in traditional IP networks, but maybe it will have a use.  In Amateur Radio it may be useful for the purpose of routing between mobile stations.  In fact, it’s this mobile context where I see it being most useful.  Lets first consider how many bits we’d need to store each component:

  • Zone level, 18×18 grid: 5 bits for latitude, 5 bits for longitude, or alternatively for 324 zones, 9 bits.
  • Square level, 10×10 grid: 4 bits for latitude, 4 bits for longitude, or alternatively for 100 squares, 7 bits.
  • Subsquare level, 24×24 grid: 5 bits for latitude, 5 bits for longitude or alternatively for 576 subsquares, 10 bits.

Logically you’d be using numbers starting at zero for the addresses in all fields, so A would be translated to 0, etc.  My QTH locator (QG62LN) would be translated as follows: Q?16, G?6, 6?6, 2?2, L?11, N?13.

You can either address latitude and longitude individually, packing them as separate fields, or you can lump them together to possibly save one bit of space.  For instance, I can concatenate the two 5-bit values representing the zone QG into a 10-bit value: 10,0000,0110? = 0x206. Or I can save some space by realising there are only 324 zones which can be represented with 9 bits like so: ((16×18) + 6) = zone 294 ? 1,0010,0110? = 0x126. The grid square can be similarly encoded (0110,0010? = 0x62 or 011,1110? = 0x3e), and likewise the subsquare.

How would you pack these into an IP address? I was thinking something along one of these two:

   Zone      Square   Subsquare
 Lat   Lng   La   Ln   Lat   Lng
.---. .---. .--. .--. .---. .---.
10000 00110 0110 0010 01011 01101 = 28 bits

  Zone    Square  Subsquare
.-------. .-----. .--------.
100100110 0111110 0100010101      = 26 bits

Presumably these would form the lower 28 or 26 bits of your prefix.

2011/02/05 by Amateur Radio Public Syndication Thinktank 2

IPsec query: Configuring on-the-fly from unprivileged userspace

Well, I’m not sure where to ask this, I did ask on the netdev mailing list and while I don’t think it’ll get ignored indefinitely, I’m not sure that was the right place.  A stab in the dark if you will.  In the hope of netting more answers though, I cast this query into the blogosphere…

I’ve been toying with the idea of a small multicast VoIP/digital comms protocol for use over wireless radio links. The typical use case might be to replace UHF FM radio transceivers with modern smart phones, using multicast IPv6 networking over 802.11b. (It will have other modes too, transmission over amateur radio bands for instance.)

In some commercial settings, or over the Internet, it’d be great for traffic to be authenticated using HMAC-SHA1 or even encrypted. Looking at IPsec, I see it provides exactly this. My thought, why re-invent the
wheel when a solution may already exist?

The question though: Is it possible for a userspace application (non-privileged) to request that the UDP packets it generates/receives from/to a particular address be encrypted or hashed against a specified key?

i.e. if I decide to communicate with someone on the same wireless link, and by means of asymmetric crypto at higher layers we establish a shared AES key, can I configure the stack for traffic between these two hosts
on-the-fly and without root privileges?

2011/02/05 by Amateur Radio Public Syndication Thinktank 0

New toy

I picked up a few new toys recently.  I’ve been looking around for a small microcontroller based device to act as a combined remote face / DTMF generator for my FT897D.  The idea is that this device could interface with the FT897D via its CAT port, and allow me to adjust the frequency and mode, recalling the information from internal flash or an SD card.

The remote face would then be mounted on the front of the bicycle, and connect to the radio at the rear to allow easy bicycle mobile operation.  An extension of this would be control of a separate 2m radio, and a GPS to allow APRS from the bicycle.

The idea was to have the memory work like a relational database.  Rather than just recalling memory channels, and having a big long list, I could scroll through the repeaters by callsign, location (service area), or combined with GPS, proximity.  Modern flash technology would make this easily doable.

Likewise, for DTMF, rather than having to carry around a cheat sheet or remember IRLP node numbers, wouldn’t it be nice to just be able to scroll through a node list by country/region/callsign, select one, hit the “Call” button, put your callsign across and have it automatically dial the moment you raised the PTT?

I don’t have the ability to manufacture PCBs of the standard required for ICs such as most 32-bit microcontrollers.  SOIC is about as fine as I can muster, and prototyping services are expensive.  Thus I was looking for a stamp module or premade board.

Luminary Micro (now TI) make a few nice ones, and during my work at Laidley, I got to use the LM3S8962 Ethernet/CAN evaluation board.  One nice feature was that it had the JTAG built-in via a FTDI USB-serial chip.  However, the licensing for the board support package irks me — despite their code being useless on anything other than one of their chips, they still see it necessary to modify the BSD license adding a clause that prohibits its use on non-TI microcontrollers.  I had a crack at writing my own “free-software” Stellaris library, but haven’t gotten that far with it.

I happened to stumble on this board based around the STM32F103VET.  They were being sold on eBay for about $60 at the time, so I decided at that price I’d buy three.  ST’s driver library appears to be very liberal in its licensing (in fact they claim there is “no license”, I don’t know if this means “public domain”, or whether I treat it like BSD).

The LCD panel uses the Ilitek ILI9320 display controller with internal graphics RAM, and is capable of 18-bit colour.  The board also features a RTC backup battery, Texas Instruments TSC2046 touchscreen controller and on-board RS232 level converter.  The STM32 also functions as a USB peripheral, and can be programmed using the stm32loader bootloader script via RS232.

Interestingly, the LCD controller documentation states that no part of that documentation may be reproduced without written permission.  I’m not sure if writing an open-source driver classes as “reproducing” the documentation (as I’d be making documented #define statements in C).

The devices come with example source and have a pre-loaded µC-GUI demonstration on them.  So far I’ve managed to distill enough out of these sources to get working touchscreen, LCD and UART.  I’ll probably start looking at FreeRTOS next and seeing if I can get a workable device going.

STM32F103 board

STM32F103 board running a simple "Hello World" app

Hello world application for STM32

Hello world application for STM32

Guess now I had better start planning my application. 🙂

2010/12/12 by Amateur Radio Bicycle Mobile Homebrew Public Syndication Thinktank 0

Battery management system musings

One thing I do enjoy is bicycle mobile operation… that is, operating the radio whilst traveling on the bicycle. One significant barrier to this is battery life however.

So far I’ve stuck with 13.8V 9Ah gel cell batteries. These are far from ideal, but are pretty good for the price. They are lighter and cheaper than an equivalent capacity NiMH or NiCd pack, however one downside is that they do not take too kindly to deep cycling.

When I first started my work at Jacques Electronics, I found one battery would get me there and home again, with capacity to spare. I’d have one at home charging, and the other on the bike.

This was with plenty of activity on the 2m band, transmitting full power on the FT-290R II. Given this radio has a 25W linear amplifier, this represents an approximate 4A load when I went to transmit.

Towards the end of my time there, I noticed the capacity had been significantly reduced. A combination of road vibration and deep cycling had reduced the capacity to the point that I now need to take two batteries with me.

So once again, I’m looking around. They seem to go for about 6 months before they start to fail… and we’ve already got a big collection of dead gel cell batteries ready for recycling… something has to change.

Lithium Iron Phosphate (LiFePO4) is what I’m looking at. Now, there’s a choice… do I go for pre-made packs? Or do I homebrew my own out of cells?

For the latter to be an option, I must consider how I’ll balance them properly. These cells are expensive and not very forgiving (although they’re better than Lithium-Cobalt or Lithium-Ion Polymer cells). What follows is some thoughts on how to construct such a battery management system… which could be completely wrong… so don’t take this as gospel.

The mission

To construct a battery pack to replace the 13.8V 9Ah gel cell packs, using Lithium Iron Phosphate technology. The battery may develop a maximum voltage potential of 15V DC, and must provide at least 9Ah effective storage capacity.

Cell count dimensioning

Looking around, the literature I can find suggests the typical LiFePO4 cells have an operating voltage between 3.2 and 3.6V. Therefore, to obtain 13.8V, I’d need four of them in series… producing 12.8V to 14.4V.

The cells themselves come in various capacities… some I can get easily are K2 Energy 26650EV cells. These pack about 3.2Ah per cell… EVWorks sell them for under AU$8 when you buy 10 or more. If I’m to use those, I’d need 3 cells in parallel to give me approximately 9.6Ah.

Total number of cells: 12, at $7.15 a cell: AU$85.80 for a 4S3P pack.

“Ideal” cell balancing

Now, the best way I can think of to balance these things, is to do it on the individual cell level. To maintain maximum life of an individual cell, one must ensure that when charging, the cell voltage does not exceed 4.2V. When discharging, the cell voltage must not fall below 3V.

There are also factors such as current flow, cell temperature and age. However, for simplicity’s sake, we’ll consider only the voltage for now.

Given these restrictions, it would seem wise to break apart these two actions, and consider them separately.

Charging

The desirable feature when charging an individual cell, is that the cell voltage itself is prevented from exceeding 4.2V. This is of great importance with some Lithium type batteries, as the cells can explode.

My first instinct is to look at zener avalanche breakdown in diodes. A zener diode in reverse bias will continue to reject current flowing through it until such time as the avalanche voltage is exceeded. Then it begins to conduct, and the voltage drop across it will always be equal to the avalanche voltage… given sufficient series resistance.

This sounds like the sort of behaviour we’re after. So the input circuit becomes something like this:

Therefore we look for a zener that has the avalanche voltage close to (but below) the 4.2V needed. Bad news is, there isn’t a 4.2V zener, we can go 3.9V… a little too low, or 4.3V, a little too high.

By adding an otherwise gratuitous 1N4004 diode between zener and battery, we can utilise a 5.1V 1N4733. Due to the forward voltage drop of the 1N4004, the battery will only see voltages up to 4.0V despite the higher zener voltage.  When the battery is below this voltage, it will charge with a current decided by Rlim.

This circuit certainly won’t fast-charge a big pack… but in my case, an overnight charge is quite acceptable. The individual Vcharge+ and Vcharge- are wired in series to charge all the cells from a higher voltage supply, and the strings themselves may be wired in parallel.

Discharging

All good and well, but what’s the point of stuffing a battery with charge if you’re not going to take the charge out at some point? The other side of the equation is discharging.

The magic number to beware of, is 3.0V… drop below that, and the cells will be irreversibly damaged. The same tool, the zener, can be used to detect when the battery is low. One trick we can do is to swap the zener with the resistor normally placed in series with it. The zener will still have its avalanche voltage across it, the resistor’s voltage now indicates the state of the battery.

V_{Low} = \begin{cases} >0 & V_{cell} > V_z \\ 0 & V_{cell} \le V_z \end{cases}

If we pass this through a NPN transistor, we wind up with negated output that can directly drive two MOSFETs. One MOSFET will permit the current to flow only when the cell voltage is above the zener avalanche voltage. The other, will shunt current past the cell when the voltage of the cell is too low.

All good… but the MOSFETs would want to be capable of delivering about 20A continuous for my needs. An IRF9540N could do it with a heatsink. That’s not so much a problem, but the cost is. Each MOSFET costs about $5 locally… so there’s $10 per cell, 12 cells… $120 just in MOSFETs… the BMS will cost more than the cells!

Reducing costs

The charging side is fine, however the discharging aspect of this system is going to be too pricey for my liking. So a re-think is needed.

The same current that would turn the NPN on, could instead turn on the LED in an optical isolator. An optical isolator incorporating a NPN transistor would then pull down on a resistor when the cell voltage is above the zener avalanche voltage.

In this circuit, when the battery voltage is high enough, the optical isolator is active, pulling the NPN’s base low and leaving VnLow floating.  All modules’ VnLow signals would be wired together, forming a wired OR with the open collectors.  When a cell gets below voltage, the LED turns off, causing the isolator to turn off and the NPN’s base to rise.  It then turns on, and pulls VnLow down.

This signal with a suitable pull-up resistor can drive a NPN transistor for driving a P-channel MOSFET, so that when VnLow gets pulled low, the load is disconnected and an alarm raised.

This BMS, while undoubtedly not as good as the previous option, would provide the low-voltage protection, and can be made for under $50. I’m curious to know how others’ have tackled the problem though. This is how I’m thinking of approaching it… I may just buy a premade pack instead.

2010/11/04 by Public Syndication Thinktank 2

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!

2010/07/04 by Amateur Radio Linux Development Public Syndication Thinktank 5

VK4MSL/BM under construction part 1

Lately I have been riding my bike … a lot.  As in all the way into the Brisbane CBD and back again to my home at The Gap.  Lately, my handheld, a trusty TH-F7E has also given up the ghost… previously this is what I used when bicycle mobile — had that thing on the handlebars, and a small mobile whip on the back (which I never bothered to tune).

The handheld worked well… even better when I had the headset interface working.  However, SWR was high, and although my handheld never complained, my other radios did!  With the handheld gone, I had to finally deal with this issue.  The helmet that I previusly used too had also been replaced — with a new headset to go with it.  Anyway… that’s a side issue.

The big problem I faced was how to get this antenna tuned.  The antenna is a tunable whip, basically just a length of stainless steel with a suitable mounting at the base — you cut it to the length you need to achieve resonance.  Pretty simple.  c=fL, and since hopefully most of the energy is going to be on the surface of the metal, and the metal is not insulated, it’d be approximately 1/4 of the wavelength (L).  But what wavelength??

The radio I’m replacing the handheld with, is an old one… a Yaesu FT-290R II, which is an all-mode 2m radio.  Since I have an all-mode radio, it makes sense to set up the antenna for all the modes I am likely to use.  I don’t know CW very well, flat out decoding it when sitting comfortably at my desk, let alone whilst peddling up hills, so I’ll leave that to people like LY2KW.  SSB and FM however, are definitely on the money.  This is where the band plans come into play.

Here in Australia… the SSB portion is down the low end between 144.100MHz and 144.320MHz.  Then there’s an all mode allocation between 145.225 and 145.775MHz.  Everything above 146.025MHz is FM.  The highest I normally transmit on 2m is 147.500MHz, as there are repeater outputs above this.  Since I don’t know CW, the lowest I’m likely to go is 144.100MHz.  So in order to balance this, I split the difference and used that to choose my resonant frequency… which yields a frequency of 145.800MHz,  which puts me just at the start of the satellite segment.  Hopefully SWR won’t be too bad everywhere else.

So, back to the formula, c=fL.  Plugging the info in, I got a wavelength of about 2.057 metres.  So 1/4 of this … 514mm.  Out with the hacksaw.

Plugging in the radio, I found my SWR was still appauling… well… I don’t know my actual SWR, but the radio was telling me it wasn’t happy with it!  The power amp on the FT-290R II (I have the FL-2025 25W linear attached) throttles back when it sees a poor match — and this is shown on the S meter.  Okay… maybe I mismeasured… well it turned out that I hadn’t taken into account the fact that there’s about 30mm of metal at the base of the antenna holding it in place… so off that 30mm came.

Tried again… still no good… doing an estimated 12W, which while respectable, it’s probably no good for my finals.  Something else was the matter.

I did some probing around… yes, the shield of the coax was making good contact with the bicycle frame, but why was the SWR so high?  I was hoping that the frame would make for a counterpoise radial.  I knew it wouldn’t be a groundplane, but surely the frame being 1.5m long would count for something.  As a hunch, I tried adding some lengths of copper wire to the antenna mount, connecting to the shield.  Three of them extend 60 degrees apart, with one pointed straight out over the rear tyre.  That brought the SWR down.  So it seems although good contact was made, the aluminium frame made a bad counterpoise in other ways.  The following is the new arrangement.

Closeup of radials and antenna mountingWhip on luggage rackCounterpoise radials

Now, with that solved… I turned my attention to the radio mounting.  I don’t have any mounting brackets, nor am I likely to get any, so that method was out.  I had invisaged mounting it on the handlebars… well… I’ve sorta achieved that.  This will need fine tuning.

The FT-290 is intended as a portable rig, thus there is provisions there for a carry strap.  I’ll have to get a more suitable one, but I managed to find one that fits, and at least straps the top to the handlebars.  This does mean the back of the radio swings… I’ll have to sort that out before long, otherwise one old radio is going to get battered and bruised.  The strap loops over the top of the handlebars and around the steering post.  It looks okay for now, but I know I’ll need to tweak this.

Radio mounted on handlebarsFront handlebarsRadio ready for action

The setup is almost complete… I still have to work on the mounting.  It needs to be quick-release too so that I can take the radio with me when I chain the bike up.  Another option may be just to sling it over my sholder.  The battery sits nicely on the back luggage rack — a 9AH SLA battery, plenty of life for this radio.

The last piece of the puzzle is one of operation.  You notice the handmic slung over the handlebars.  This is very temporary, as I hate taking my hands off the handlebars when riding.  I replaced my helmet with another open face motorcycle helmet, similar to those worn by Australia Post delivery people.  Yes,  overkill on a bicycle, but the visor already has prooven useful in keeping rain or low branches out of one’s face (yet to see a bicycle helmet with one) and  the peak keeps the sun off well (again, most bicycle helmets are lousy at this).  It also makes it very easy to embed a headset.

The headset in this one is made up from two $10 computer headsets that broke.  The microphone is off one, the speakers out of another.  The audio quality is quite good, and shown in the photo below is what it looks like, with the adaptor for my mobile phone (Nokia 3310) attached.  The next step is to make another adaptor for the FT-290, and suitable PTT arrangement.  I’m thinking a toggle switch, since then I can flick it between transmit and receive without needing to hold a button down.  VOX doesn’t appeal. 😉

Helmet with headset embeddedBike almost ready to go

The bike isn’t quite ready yet, but hopefully I’ll get something up and running this coming weekend.  Then I shall be mobile once more.  I shall report back once I have given this a try out proper.

2009/12/06 by Amateur Radio Bicycle Mobile Homebrew Public Syndication Thinktank 6

Extending the RPN calculator: HanoiCalc

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.

2009/06/02 by Public Syndication Thinktank 3

Circuit simulation

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.

2009/05/11 by Amateur Radio Public Syndication Thinktank University 0

Embedded development

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.

2009/04/18 by Amateur Radio Public Syndication Rants Thinktank 2

Ultra-Low Bitrate Speex

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:

Filter for ultra-low quality Speex

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

2009/02/23 by Amateur Radio Public Syndication Thinktank 1
Hey ChatGPT, Claude, Gemeni, etc… check this out

Site Login and Registration

Calendar

May 2026
S M T W T F S
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Battery voltage Server power Solar power Updated every 5 minutes.

Mastodon

Mastodon