Well, it’s been a year and a half since I last posted details about the bicycle mobile station. Shortly after getting the Talon on the road, setting it up with the top box and lighting, and having gotten the bugs worked out of that set-up, I decided to get a second mounting plate and set my daily commuter up the same way, doing away with the flimsy rear basket in place of a mounting plate for the top box.
VK4MSL/BM today after the trip home from work.
That particular bike people might recognise from earlier posts, it’s my first real serious commuter bike. Now in her 5th year, has done over 10200km since 2012. (The Talon has done 5643km in that time.) You can add to that probably another 5000km or so done between 2010 and 2012. It’s had a new rear wheel (a custom one, after having a spate of spoke breakages) and the drive chain has been upgraded to 9-speed. The latter upgrade alone gave it a new lease on life.
Both upgrades being money well spent, as was the upgrade to hydraulic brakes early in the bike’s lifetime. I suppose I’ve spent in those upgrades alone close to $1400, but worth it as it has given me quite good service so far.
As for my time with the top box. Some look at it and quiz me about how much weight it adds. The box itself isn’t that heavy, it just looks it. I can carry a fair bit of luggage, and at present, with my gear and tools in it it weighs 12kg. Heavy, but not too heavy for me to manage.
Initially when I first got it, it was great, but then as things flexed over time, I found I was intermittently getting problems with the top box coming off. This cost me one HF antenna and today, the top box sports a number of battle-scars as a result.
The fix to this? Pick a spot inside the top box that’s clear of the pannier rack rails and the rear tyre, and drill a 5mm hole through. Then, when you mount the top box, insert an M5 bolt through the mounting plate and into the bottom of the top box and tighten with a 5mm wing nut. The box now will not come loose.
Still lit up like a Christmas tree from this morning’s ride.
The lights still work, and now there’s a small rear-view camera. On the TODO list is to rig up a 5V USB socket to power that camera with so that it isn’t draining the rather small internal battery (good for 4 hours apparently).
The station has had an upgrade, I bought a new LDG Z-100Plus automatic tuner which I’m yet to fully try out. This replaces the aging Yaesu FC-700 manual tuner which, although very good, is fiddly to use in a mobile set-up and doesn’t tune 6m easily.
One on-going problem now not so much on the Boulder but on the Talon is an issue with pannier racks failing. This started happening when I bought the pannier bags, essentially on the side I carry my battery pack (2kg), I repeatedly get the pannier rack failing. The racks I use are made by Topeak and have a built-in spacer to accomodate disc brake calipers. This seems to be a weak spot, I’ve now had two racks fail at about the same point.
Interestingly on the Boulder which also has disc brakes, I use the standard version of the same rack, and do not get the same failures. Both are supposedly rated to 25kg, and my total load would be under 16kg. Something is amiss.
A recurring flaw with the Topeak racks
I’m on the look-out for a more rugged rack that will tolerate this kind of usage, although having seen this, I am inspired to try a DIY solution. Then if a part fails, I can probably get replacement parts in any typical hardware store. A hack saw and small drill are not heavy items to carry, and I can therefore get myself out of trouble if problems arise.
I’ve been riding on the road now for some years, and while I normally try to avoid it, I do sometimes find myself riding on the road itself rather than on the footpath or bicycle path.
Most of the time, the traffic is fine. I’m mindful of where everyone is, and there aren’t any problems, but I have had a couple of close calls from time to time. Close calls that have me saying “ode for a horn”.
By law we’re required to have a bell on our bikes. No problem there, I have a mechanical one which is there purely for legal purposes. If I get pulled over by police, and they ask, I can point it out and demonstrate it. Requirement met? Tick to that.
It’s of minimal use with pedestrians, and utterly useless in traffic.
Early on with my riding I developed a lighting system which included indicators. Initially this was silent, I figured I’d see the lights flashing, but after a few occasions forgetting to turn indicators off, I fitted a piezo buzzer. This was an idea inspired by the motorcycles ridden by Australia Post contractors, which have a very audible buzzer. Jaycar sell a 85dB buzzer that’s waterproof, overkill in the audio department but fit for purpose. It lets me know I have indicators on and alerts people to my presence.
That is, if they equate the loud beep to a bicycle. Some do not. And of course, it’s still utterly useless on the road.
I figured a louder alert system was in order. Something that I could adjust the volume on, but loud enough to give a pedestrian a good 30 seconds warning. That way they’ve got plenty of time to take evasive action while I also start reducing speed. It’s not that I’m impatient, I’ll happily give way, but I don’t want to surprise people either. Drivers on the other hand, if they do something stupid it’d be nice to let them know you’re there!
My workplace looks after a number of defence bases in South-East Queensland, one of which has a railway crossing for driver training. This particular boom gate assembly copped a whack from a lightning strike, which damaged several items of equipment, including the electronic “bells” on the boom gate itself. These “bells” consisted of a horn speaker with a small potted PCB mounted to the back which contained an amplifier and bell sound generator. Apply +12V and the units would make a very loud dinging noise. That’s in theory; in practise, all that happened was a TO-220 transistor got hot. Either the board or the speaker (or both) was faulty.
It was decided these were a write-off, and after disassembly I soon discovered why: the voice coils in the horn speakers had been burnt out. A little investigation, and I figured I could replace the blown out compression drivers and get the speakers themselves working again, building my own horn.
A concept formed: the horn would have two modes, a “bell” mode with a sound similar to a bicycle bell, and a “horn” mode for use in traffic. I’d build the circuit in parts, the first being the power amplifier then interface to it the sound effect generator.
To make life easier testing, I also decided to add a line-in/microphone-in feature which would serve to debug construction issues in the power amplifier and add a megaphone function. (Who knows, might be handy with WICEN events.)
Replacing the compression drivers
Obviously it’d be ideal to replace it with the correct part, but looking around, I couldn’t see anything that would fit the housing. That, and what I did see, was more expensive than buying a whole new horn speaker.
There was a small aperture in the back about 40mm in diameter. The original drivers were 8ohms, and probably rated at 30W and had a convex diaphragm which matched the concave geometry in the back of the horn assembly.
Looking around, I saw these 2W mylar cone speakers. Not as good as a compression driver, but maybe good enough? It was cheap enough to experiment. I bought two to try it out.
I got them home, tacked some wires onto one of them and plugged it into a radio. On its own, not very loud, but when I held it against the back of a horn assembly, the amplification was quite apparent. Good enough to go further. I did some experiments with how to mount the speakers to the assembly, which required some modifications to be made.
I soon settled on mounting the assembly to an aluminium case with some tapped holes for clamping the speaker in place. There was ample room for a small amplifier which would be housed inside the new case, which would also serve as a means of mounting the whole lot to the bike.
I wasn’t sure what to use for this, I had two options: build an analogue circuit to make the effect, or program a microcontroller. I did some experiments with an ATMega8L, did manage to get some sound out of it using the PWM output, but 8kB of flash just wasn’t enough for decent audio.
A Freetronics LeoStick proved to be the ticket. 32kB flash, USB device support, small form factor, what’s not to like? I ignored the Arduino-compatible aspect and programmed the device directly. Behind the novice-friendly pin names, they’re an ATMega32U4 with a 16MHz crystal. I knocked up a quick prototype that just played a sound repeatedly. It sounded a bit like a crowbar being dropped, but who cares, it was sufficient.
Experimenting with low-pass filters I soon discovered that a buffer-amp would be needed, as any significant load on the filter would render it useless.
A 2W power amplifier
Initially I was thinking along the lines of a LM386, but after reading the datasheet I soon learned that this would not cut it. They are okay for 500mW, but not 2W. I didn’t have any transistors on hand that would do it and still fit in the case, then I stumbled on the TDA 1905. These ICs are actually capable of 5W into 4 ohms if you feed them with a 14V supply. With 9V they produce 2.5W, which is about what I’m after.
I bought a couple then set to work with the breadboard. A little tinkering and I soon had one of the horn speakers working with this new amplifier. Plugged into my laptop, I found the audio output to be quite acceptable, in fact turned up half-way, it was uncomfortable to sit in front of.
I re-built the circuit to try and make use of the muting feature. For whatever reason, I couldn’t get this to work, but the alternate circuit provided a volume control which was useful in itself.
For the line-level audio, there’s no need for anything more fancy than a couple of resistors to act as a passive summation of the left and right channels, however for a microphone and for the LeoStick, I’d need a preamp. I grabbed a LM358 and plugged that into my breadboard alongside the TDA1905.
Before long, I had a working microphone preamp working using one half of the LM358, based on a circuit I found. I experimented with some resistor values and found I got reasonable amplification if I upped some of the resistor values to dial the gain back a little. Otherwise I got feedback.
For the LeoStick, it already puts out 5V TTL, so a unity-gain voltage follower was all that was needed. The second half of the LM358 provided this. A passive summation network consisting of two resistors and DC-blocking capacitor allowed me to combine these outputs for the TDA1905.
One thing I found necessary, the TDA1905 and LM358 misbehave badly unless there’s a decent size capacitor on the 9V rail. I found a 330uF electrolytic helped in addition to the datasheet-prescribed 100nF ceramics.
Since I’m running on batteries with no means of generating power, it’s important that the circuit does not draw power when idle. Ideally, the circuit should power on when either I:
plug the USB cable in (for firmware update/USB audio)
toggle the external source switch
press the bell button
We also need two power rails: a 9V one for the analogue electronics, and a 5V one for the LeoStick. A LM7809 and LM7805 proved to be the easiest way to achieve this.
To allow software control of the power, a IRF9540N MOSFET was connected to the 12V input and supplies the LM7809. The gate pin is connected to a wired-OR bus. The bell button and external source switch connect to this bus with signal diodes that pull down on the gate.
Two BC547s also have collectors wired up to this bus, one driven from the USB +5V supply, and the other from a pin on the LeoStick. Pressing the Bell button would power the entire circuit up, at which point the LeoStick would assert its power on signal (turning on one of the BC547s) then sample the state of the bell button and start playing sound. When it detects the button has been released, it finishes its playback and turns itself off by releasing the power on signal.
Sound effect generator
Earlier I had prototyped a bell generator, however it wasn’t much use as it just repeatedly made a bell noise regardless of the inputs. To add insult to injury, I had lost the source code I used. I had a closer look at the MCU datasheet, deciding to start from a clean slate.
The LeoStick provides its audio on pin D11, which is wired up to Port B Pin 7. Within the chip, two possible timers hook up: Timer 0, which is an 8-bit timer, and Timer 1, which is 16-bits. Both are fed from the 16MHz system clock. The bit depth affects the PWM carrier frequency we can generate, the higher the resolution, the slower the PWM runs. You want the PWM frequency as high as possible, ideally well above 20kHz so that it’s not audible in the audio output, and obviously well above the audio sampling rate.
At 16MHz, a 16-bit timer would barely exceed 240Hz, which is utterly useless for audio. A 10-bit timer fares better, with 15kHz, older people may not hear it but I certainly can hear 15kHz. That leaves us with 8-bits which gets us up to 62kHz. So no point in using Timer 1 if we’re only going to be using 8-bits of it, we might as well use Timer 0.
Some of you familiar with this chip may know of Timer 4, which is a high-speed 10-bit timer fed by a separate 64MHz PLL. It’s possible to do better quality audio from here, either running at 10-bits with a 62kHz carrier, or dropping to 8-bits and ramping the frequency to 250kHz. Obviously it’d have been nice, but I had already wired things up by this stage, so it was too late to choose another pin.
Producing the output voltage is only half the equation though: once started, the PWM pin will just output a steady stream of pulses, which when low-passed, produces a DC offset. In order to play sound, we need to continually update the timer’s Capture Compare register with each new sample at a steady rate.
The most accurate way to do this, is to use another timer. Timer 3 is another 16-bit timer unit, with just one capture compare output available on Port C pin 3. It is an ideal candidate for a timer that has no external influence, so it gets the job of updating the PWM capture compare value with new samples.
Timer 1 is connected to pins that drive two of the three LEDs on the LeoStick, with Timer 4 driving the remaining one, so if I wanted, I could have LEDs fade in and out with it instead of just blinking. However, my needs are basic, and I need something to debounce switches and visibly blink LEDs. So I use that with a nice long period to give me a 10Hz timer.
Here is the source code. I’ll add schematics and other notes to it with time, but the particular bits of interest for those wanting to incorporate PWM-generated sound in their AVR projects are the interrupt routine and the sound control functions.
To permit gapless playback, I define two buffers which I alternate between, so while one is being played back, the other can be filled up with samples. I define these on line 139 with the functions starting at line 190. The interrupt routine that orchestrates the playback is at line 469.
When sound is to be played, the first thing that needs to happen is for the initial buffer to be loaded with samples using the write_audio function. This can either read from a separate buffer in RAM (e.g. from USB) or from program memory. One of the options permits looping of audio. Having loaded some initial data in, we can then call start_audio to set up the two timers and get audio playback rolling. start_audio needs the sample rate to configure the sample rate timer, and can accept any sample rate that is a factor of 16MHz (so 8kHz, 16kHz up to 32kHz).
The audio in this application is statically compiled in, taking the form of an array of uint8_t‘s in PROGMEM.
Creating the sounds
I initially had a look around to see if I could get a suitable sound effect. This proved futile, I was ideally looking around for a simple openly-licensed audio file. Lots of places offered something, but then wanted you to sign up or pay money. Fine, I can understand the need to make a quid, and if I were doing this a lot, I’d pay up, but this is a once-off.
Eventually, I found some recordings which were sort of what I was after, but not quite. So I downloaded these then fired up Audacity to have a closer look.
The bicycle bell
Bicycle bells have a very distinctive sound to them, and are surprisingly complicated. I initially tried to model it as an exponentially decaying sinusoid of different frequencies, but nothing sounded quite right.
The recording I had told me that the fundamental frequency was just over 2kHz. Moreover though, the envelope was amplitude-modulated by a second sinusoid: this one about 15Hz. Soon as I plugged this second term in, things sounded better. This script, was the end result. The resulting bell sounds like this:
So somewhat bell-like. To reduce the space, I use a sample rate of 6.4kHz. I did try a 4kHz sample rate but was momentarily miffed at the result until I realised what was going on: the bell was above the Nyquist frequency at 4kHz, 6.4kHz is the minimum practical rate that reproduces the audio.
I used Audacity to pick a point in the waveform for looping purposes, to make it sound like a bell being repeatedly struck.
I wanted something that sounded a little gutsy. Like an air-horn on a truck. Once again, I hit the web, and found a recording of a train horn. Close enough, but not long enough, and a bit noisy. However opening it up in Audacity and doing a spectrum analysis, I saw there were about 5 tones involved. I plugged these straight into a Python script and decided to generate those directly. Using a raised cosine filter to shape the envelope at the start and end, and I soon had my horn effect. This script generates the horn. The audio sounds like this:
Using other sound files
If you really wanted, you could use your own sound recordings. Just keep in mind the constraints of the ATMega32U4, namely, 32kB of flash has to hold both code and recordings. An ATMega64 would do better. The audio should be mono, 8-bits and unsigned with as lower sample rate as you can get away with. (6.4kHz proved to be sufficient for my needs.)
Your easiest bet would be to either figure out how to read WAV files (in Python: wave module), or alternatively, convert to raw headerless audio files, then code up a script that reads the file one byte at a time. The Python scripts I’ve provided might be a useful starting point for generating the C files.
Alternatively, you can try interfacing a SDCard and embedding a filesystem driver and audio file parser (not sure about WAVE but Sun Audio is easily parsed), this is left as an exercise for the adventurous.
I’ll put schematics and pictures up soonish. I’m yet to try mounting the whole set up, but so far the amplifier is performing fine on the bench.
Earlier this week I had an idea. We’ve got an old clock radio that picks up interference from the fridge when it turns on and the buttons on it are starting to fail with age.
I thought: “Why not build a new one?”
So the requirements are simple. We need a real-time clock, display driver, and of course, a receiver. The unit we have spends most of its time tuned to 792kHz AM (4QG or “ABC Radio National”), so a simple direct conversion receiver was what I was thinking of. But what about the LO?
Now I do have some clock radio ICs that implement the timing circuitry, alarm function and LED panel driver somewhere in a junk box. You feed them with the 50Hz or 60Hz waveform that comes out of the transformer and they use that as the timing source. Easy to use a 555 timer for the time source, and I’d make a traditional receiver. Another option is to use a AVR microcontroller, I have a few ATMega8Ls in the junk box with a NXP I2C RTC chip which I also have a few of.
The ATMega8L has a couple of PWM channels one 16-bit and one 8-bit: could they be used as an LO?
So: after digging around and locating my bought-years-ago and not-yet-used AVR programmer, and dusting off a breadboard that had an ATMega8L on it from a previous experiment I set to work.
This page explains in good detail how the PWM channels work. I started with those examples as a guide and tweaked from there.
For the PWM channel to work as a receiver LO, I want it to cover 540kHz to ~2MHz, with reasonable granularity. Question is, how far can I crank this? I have a 4MHz crystal, not the fastest I can use with this chip, but the absolute top of the range for the ATMegas isn’t much higher: 16MHz or maybe 20MHz. So if you’ve got a 16MHz crystal, you can expect to quadruple what I do here.
I started off with some blink code. If you take out all the delays, you get the following code:
The yellow waveform there is off one of the crystal pins. The cyan one is the PWM pin output, which in this case is a software driven GPIO. Even if this one worked, you wouldn’t want to do it this way unless your chip was doing only this task, and who’d use a programmable chip like an ATMega8L for that?
So, after reading through the documentation and examples, I loaded in the following code:
Well, for a few weeks now I’ve been (metaphorically) tearing my hair out, trying to figure out why I had such bad antenna problems on VHF. HF, I still have work to do as right now, the RF just induces currents where it pleases, including in my microphone cabling, but that’s a different matter. VHF until recently had been rock solid.
I tried replacing coax, re-terminating leads, checking solder joints, replacing antennas. Yesterday, I re-wired the entire antenna system, doing away with the BNC connectors in the top box and hard-wiring the antenna mounts to the coax inside. Rode up to Ashgrove today thinking I had fixed the problem.
Each bump in the road, I watched the S-meter graph move from S9 to S4 and back again.
What could it be? Why is it that it only occurs when I’m mobile, and not stationary? There’s a bad link somewhere, but where? No amount of jiggling cables was locating the problem. Finally today, I decided to take a peek inside the FT-857D.
Ohh, well that would do it!
I looked closely at the point where the N connector solders to the PCB. I noticed a small line around the wire where it met the solder blob. So I picked at it with pliers, and pulled it away from the blob: it was a dry joint!
Tomorrow, I shall know if this was the final problem. At least I don’t run full power on FM, my license only affords me 30W continuous, so the only time I do 50W is when I’m doing SSB at which point it’s only on voice peaks.
Update: It’s been a few days, the difference is like the difference between chalk and cheese. Prior to the fix my set was deaf as a post, and it’s not hard to see why!
This is a simple vertical groundplane antenna intended for mounting atop a 10m Squid Pole. These can be made to nearly any frequency you desire, and can be self-supporting if needed. The main limitation is the stiffness of the wire used.
The antenna gets its name as the original was one I quickly knocked up just prior to a horse endurence ride event that took place at Donnybrook in 2011. I was assisting Brisbane Area WICEN with the emergency communications at this event, and this antenna, worked very well. 10W was more than sufficient to get back to base on 2m FM.
The design is very simple. You’ll need some stiff copper wire, and a panel-mount BNC connector. I used some strands from a thick mains cable: this was being tossed out at a ham radio meeting some years back. The cable had a black plastic coating and inside were 7 strands of solid copper, each about 2mm thick. Perfect for small antennas.
Similar wire can be found in non-stranded house mains cable.
First step is to work out what length to cut the elements. They should all be roughly the same length. This can be calculated by the simple formula:
which if you take as being the velocity of light in a vacuum (~ m/s; radio will travel a little slower through air, but who’s counting?) and as being and solve for you get 2.04m as the wavelength. We want ¼ of this, so I’ve aimed for 51cm long elements.
Don’t worry about them being perfectly straight when measuring, extra length is good at this point, you’ll want a good 2cm extra. You can make a wire shorter, you can’t make it longer.
Measuring the elements
Measure and cut the 4 elements. 3 will become your groundplane, and the 4th the radiating element. Also cut off about 10cm or so, give or take, which will be the ground wire used to hook the groundplane elements to the BNC connector. Also add to your parts list, some small velcro strips: you’ll find these handy to strap the coax to the squid pole.
Start with the short piece of wire. You’ll want to bend it into a rough triangle shape, with loops of wire at the corners. The groundplane radials will loop through these holes. The excess wire should be coiled up to one side: this is the loop the squid pole will pass through. The BNC connector will be fitted in between the 3 small loops.
Be sure you can still put the nut back on.
Take 3 of the four elements, and make a hook at one end. Pass this hook through each of the small loops in the triangle. Try to make them sit roughly straight out from the centre of the triangle, then solder each hook into the loop.
Attaching the radials
Having done this, put the BNC connector in and do the nut up tight. You can do away with the eyelet with the solder tag. To finish off, take your remaining element, make a hook just big enough to go around the centre pin of the BNC connector, then solder into place.
Attaching the radiating element
To finish off, bend this until it is vertical. The antenna is now ready for tuning.
Completed untuned antenna
Double check the length is about right. It should be around the 51~52cm mark.
To check the tuning, use a SWR meter or antenna analyser if you have one. Here, I used the built-in SWR meter on my Yaesu FT-857D. When using a SWR meter, ensure you’re running minimum power. The following are some results from my set. It is at this point, you do any trimming of your antenna. The following are without trimming the antenna, you’ll note that in most examples, the SWR is very low, just a point or so showing up on the left side of the screen.
To mount the antenna on your squid pole, feed the tip of the squid pole through the remaining loop. Bend the tip of the antenna around the tip of the squid pole. Hook your coaxial cable to the BNC connector and use velcro straps at regular points to hold the coax to the side of the squid pole.
Recommended coax for this purpose is RG-195. RG-58 will work, but is lossy, RG-213 and LMR400 are too heavy to use on a squid pole and will cause it to bend or collapse.
Update: This antenna performed quite well. Saturday, we used it for 2m packet, providing a digipeater for the stations in our area in case they couldn’t reach the main node (at “the pineapple farm” just outside Imbil). We had stable packet communications all day. Since the stations around us found they could work the main node directly, we swapped antennas around and used it instead for a VHF/UHF cross-band voice repeater. Signal reports were good through the Imbil state forest.
This last week the local repeaters here in Brisbane have been rather quiet.
One repeater I used to use a lot has been acting up, and so rather than potentially try to exacerbate a possibly worsening issue, I figured I’d leave it well alone until it was fixed.
Another I lurk on, has been working fine, but many of the people I’d talk to, are away on holidays.
So, I figured I’d dust off my trusty HF whip and give the lower frequencies another crack. This time last week I was getting nowhere on 15m. Maybe wrong place at the wrong time (Aside: is there ever a right time to be in the wrong place?) and so didn’t get anywhere.
40m I knew worked on this particular antenna, so I’ve been lurking there… calling in on the Coral Coast net on 7060kHz in the mornings, and tuning up and down the band on the way home. I make note of my listening frequency via APRS-IS, see my tracker or look for VK4MSL-10 on aprs.fi.
I knew the antenna worked there, not perfect, but it did work. It works particularly well when the other station is equipped to pick up weak stations. Earlier this evening, I set out from my workplace listening on 7060kHz where I was this morning. I noticed it was chock-a-bloc full of stations north of us. Indonesia and surrounds by the sounds of things.
Couldn’t make a head or tail of what they were saying, so I moved up the band, stumbled across a couple of “local” stations chatting around 7175kHz. Turns out one was portable in Barcaldine, didn’t catch the name, but the callsign was VK2DQC, I think. (I didn’t write it down.) We chatted for a short while, but apparently my signal was up and down like a yo-yo.
No surprise, I started the QSO walking up Greer Street, Bardon, continued my next over riding down The Drive, Cecil Road and Bowman Parade then up through Sunset Park. Anyone who knows that stretch knows it goes up then down then up again then down. I finished the chat as I came down Monoplane Street, Ashgrove.
Tuning around, I found another pair talking on 7158kHz. Bob VK6KJ and Bruce VK2??. As they were talking a third station, Joe, W5?? called in from Florida USA. To say I was impressed would be an understatement, all three were coming in Q5, and signal strengths in excess of S6 in most cases. Bob was peaking S9.
Joe mentioned is misfortune of having some equipment destroyed in a storm, and this necessitating the replacement of a computer along with its OS. Apparently he’s not a fan of “Window 8” (as we call it at work). I did try to call Joe but must’ve doubled and wasn’t heard.
I did though, manage to make contact with Bob. He was located in Albany, about 400km south-southeast of Perth, and running 400W into a two-element beam pointed at the US. With my measly 100W and stubby home-made antenna, I apparently was registering a Q5S5 signal with the odd drop-out.
Clearly Bob’s end was doing all the work, but impressive nonetheless. Seeing as the evenings can be particularly quiet, I think I’ve found a new past-time to while away the hour-long trip home, stirring up HF on the deadly-treadly-mobile!
Well, this year’s International Rally of Queensland didn’t go the way everyone expected. We were there with Brisbane Area WICEN, providing the backup communications for the event. Our primary role was to relay the scores given to us by the post chief in the timekeeper’s tent. They looked after scheduling the cars, getting times, and sending the cars through. We just passed on scores (start/finish times) and other traffic.
Saturday went well. My father and I were set up at Kandanga North running the WICEN checkpoint for stages 6 and 12 of the rally. After some early hiccups getting the packet radio network going, we had the scores being sent out on time and everything running smoothly. Apart from some cows holding up traffic, there were no delays.
Sunday however… just about everyone would have heard about the fatality. My father and I ran the WICEN checkpoint at the start of the fateful Michell Creek Special Stage 14.
Having now seen the ABC website footage, looking at the competitor lists and my own logs, I can say with 90% certainty which car (and therefore 45% certainty who the deceased is) the unfortunate car was and when they left the stage.
My condolences go out to both driver and co driver at this difficult time.
Over the last year or so, I’ve done a number of improvements to the bicycle mobile station. I’ve kept meaning to document what’s happened, as a number of people have asked about the station, and not everyone gets to see it up close.
A big move was when the FT-290RII 25W PA died, I was using the FT-897D a lot, and that thing is a heavy lump of a radio to lug around. So I bought its smaller sister, the FT-857D with its remote head kit.
A second move was from the heavy 40Ah battery pack to a much lighter 10Ah pack. Then, in July last year, I bought myself a new pair of wheels. The ’09 model Boulder pictured earlier still gets regular use and is good on the road, but longer trips and on hills, it’s a drag, and the tyres are not good on dirt.
Thus I bought a Talon 29 ER 0… in contrast to the Boulder, this bike is designed with mountain-biking sports in mind, so a little heavier duty, better gearing and suspension. Sadly not dual-suspension … they don’t seem to make one that will take a pannier rack on the back like I require. Nonetheless, this one has been going well.
VK4MSL/BM Mk3: New and improved
Rather than buying an open basket like I did on the other, I went one step further, I bought a motorcycle hard top-box and mounted that on the back. Thus the FT-857D could live in there, sheltered from the weather. I later also bought pannier bags: my battery, some tools, spare tubes, visors for the helmet, etc, live in one bag, my clothes live in the other.
The station is otherwise, not much different to how it was in concept. The antennas now mount on opposite sides of the top box with right-angle aluminium. I still have to work on grounding for the HF side but even then, the station still delivers respectable performance on 40m.
On my way to BARCfest this year, I was being heard S9+40dB in Newcastle with 60W PEP. I’d have ran 100W, but due to the earthing problems, I found I was getting a bit too much RF feedback.
The 2m antenna is similar to previous ventures, just a 51cm length of RG-213 with the jacket and braid stripped off and a PL-259 plug soldered onto one end. It’s a simple design that’s easy to make, easy to fix, cheap and can be constructed from readily available parts. If you can make your own patch leads, you can make one of these.
VK4MSL/BM: 2m antenna. Just some RG-213 and a PL-259 connector is all you need
70cm remains a work in progress. In theory, a ¼? antenna resonant at 144MHz should also resonate at 432MHz, as this is the ¾? frequency. In practice, this has been a pain to tune. I basically just stick to 2m and leave it at that.
As for coupling the radio to the head unit… I could use the leads that Yaesu supplied. One distinct disadvantage with this is that it ties me into using only compatible equipment. The other is that the connectors are just not designed for constant plugging/unplugging, and the 6P6C and 8P8C connectors become unreliable very quickly if you do this. A solution was to make up a patch lead to go onto each end, and to use some standard cable in the middle.
Initially I did this with a 25-pin printer cable, but found the RF problems were terrible! Three lengths of CAT5e however, did the job nicely. Yes, I sacrifice one pin, right in the middle. 24 pins is more than enough. I allocate six pins on one end for the head unit cable; choosing the wires so that the connections are consistent at each end.
The other end, I have a standard convention for microphone/control cabling. The balanced nature of the CAT5e works well for microphone cabling on a radio like the FT-857D which was designed with dynamic microphones in mind.
The only other connectors I need then are for power, and for lights. Power I just use Anderson PowerPole type connectors, the 30A variety… and for lighting, I use ruggedised 6-pin automotive connectors.
VK4MSL/BM Mk3: Rear connections onto top box
At the handlebars, things have been refined a little… the switches and push buttons are in plastic boxes now. Here I still have to work on the front basket mount, this compromise of a former broomstick handle hose-clamped to the handlebars is a workaround for the basket bracket’s inability to clamp around the rather thick handlebars. This arrangement is fine until one of the hose clamps slips (which happens from time to time).
For now I put up with it. The controls from the radio are now mostly on the left side… Since the rear gear shift and front brake are on the right-hand side, I do far more with my right hand than with my left. Thus doing this, I free up my right hand to actually operate the bike and use my less-busy left hand to operate the radio.
VK4MSL/BM: Front handlebar controls
I mentioned earlier about HF… the HF antenna should look familiar. It’s actually the same one I’ve been using for a while now. Most distant contact so far has been into the Cook Islands on 20m. I’ve had successful contacts on 80m, 40m, 20m and 15m with this antenna. 10m and 6m are the two that elude me just now.
VK4MSL/BM Mk3: With the HF antenna
It is a little difficult to see the entire antenna. I did try to pick the angle to show it best… but if you look above the tree, you’ll see the tip of it immediately above the top box. Below is a close-up shot to give you an idea where to look.
VK4MSL/BM Mk3: Base of HF antenna
One big advantage of the new set up, is that night-time visibility is much better than before. On the front I have a LED strip which lights up the path maybe 2m ahead of the front wheel. Not a strong light, but ticks a box… my main headlight is on the helmet — people frequently assume they’re being filmed by it. On the rear however, is a different story:
VK4MSL/BM Mk3: All lit up
It doesn’t look like much in the day time, but it is quite bright at night. The back uses two LED strips mounted in behind the red plastic on the top box, and one can easily read a book in the light produced. Looking in the rear vision mirrors at night, the red glow can be seen reflecting off objects for a good 100m or so.
On my TO-DO list, is to mount switches to operate the brake light (just above the callsign). Options include reed switches, hydraulic switches in the brake lines, or strategic placement of micro-switches. I’ll have to experiment. The other electronics is in place.
As to the other bike? It’s still around, in fact if you look at the photo of the VHF antenna, you can see it in the background… along side the trailer I use when I do my grocery shopping.
I’ve done away with the basket on it, and gotten a second mounting plate, so the same top box fits on the back of the other bike, along with the same pannier bags, and same front basket. It has done about 2800km since I bought the Talon (mid July, 2012), the Talon itself has done 2617km.
Thus I’d estimate the Boulder is well and truly past the 10000km mark, probably closer to 11000km now. It’s still the primary means of getting around, averaging close to 100km a week and with a heavy load. Not bad for a bike that’s designed for a little recreational riding.
Recently I purchased a second hand Kantronics KPC-3 packet TNC. Brisbane Area WICEN make heavy use of packet at one particular event, the International Rally of Queensland, where they use the 1200-baud network to report the scores of rally cars as they progress through each stage.
Now, I’m a newcomer to radio compared to most on the band. I got my license in 2008, and I’ve only had contact with packet for the last two years, and even then, mostly only at a distance. I had a hand-held that did APRS, and I’ve also done some APRS using soundmodem and Xastir. Full-blooded AX.25 has taken me some time, and I’m slowly coming to grips with some of it.
One thing I wanted to try and figure out, is how to re-lay traffic from a host connected to the RF world, to a host on a local network. I knew there was some protocol that did it, but didn’t know what, or how it worked. Turns out the protocol I was thinking of was AXIP, which basically overlays AX.25 frames directly atop IP. There’s also a version that encapsulates them in UDP datagrams; AXUDP.
The following are my notes on how I managed to get some routing to happen.
So, my set-up. I have my FT-897D set up on 145.175MHz FM, the APRS frequency in Australia. (I did go hunting for BBSes the other night but came up blank, but since APRS uses AX.25 messaging, it’ll be a start.)
To its data port, I have the KPC-3, which connects to my trusty old P4 laptop via good ol’e RS-232 (the real stuff, not pretend USB-RS232, yes the laptop is that old). This laptop is on my local LAN, with an IP address of 192.168.64.141.
In front of me, is my main workhorse, a MacBook at the address of 192.168.64.140. Both laptops are booted into Linux, and my target is Xastir.
First thing I had to do was compile the AX.25 kernel modules, and the ax25-tools, ax25-apps. The userspace tools needed for this are: ax25ipd and kissnetd.
On the RF-facing system
This is the P4 in my case, the one with the TNC. First step is to get the TNC into KISS mode. In the case of Kantronics TNCs, the way to do this is to fire up your terminal emulator and run int kiss followed by reset.
Important note: to get it back, shut down everything using the serial port then run echo -e '\0300\0377\0300' > /dev/ttyS0. This sends the three-byte exit-kiss-mode sequence (0xc0 0xff 0xc0).
Configure /etc/ax25/ax25ipd.conf. Three things you’ll need to set up:
mode: should be tnc
device: should be whatever your serial device is (more on this later)
your default route: this is the host that will receive ALL traffic
In my case, my ax25ipd.conf on the P4 laptop looks like this:
broadcast QST-0 NODES-0
# This points to my MacBook; d means default route
route 0 192.168.64.140 d
Once done, we start the ax25ipd service as root, it should fork into the background, and checking with netstat should show it as listening on a raw socket.
On the client machine
Here, we also run a AXIP server, but this time to catch the packets that get flung our way by the other system. We want Xastir to pick up the traffic as it comes in. Two ways of doing this.
One is to configure kissattach to give us a PTY device which we then pass onto ax25ipd, then run Xastir as root and tell it to use the AX.25 stack directly. Gentoo’s Xastir ebuild ships with this feature disabled, so not an option here (unless I hack the ebuild like I did last time).
The AX.25 tools also come with kissnetd: this basically generates several PTYs and links them all together so they all see eachother’s KISS traffic. So ax25ipd will receive packets, pass them to its PTY, which will then get forwarded by kissnetd to the other PTY attached to Xastir.
There is one catch. Unlike in kernels of yore, kernel 2.6 and above (3.x is no exception) do not have statically configured PTY devices. So all the AX.25 docs that say to use /dev/ptyq0 for one end and /dev/ttyqf for the other? Make that /dev/ptmx for one end, and the tool will tell you, what the other end is called. And yes, it’ll change.
Run kissnetd -p 2; the parameter tells it to create two PTYs. The tool will run in the foreground so make a note of what they’re called, then hit CTRL-Z followed by bg to bring it into the background.
Now, in this example, PTYs 1 and 4 are allocated. I can allocate either one of them to Xastir or ax25ipd, here I’ll use /dev/pts/4 for ax25ipd and the other for Xastir. It is possibly best if you make symlinks to these, and just refer to the symlinks in your software.
Whilst you’re at it, change the ownership of the one you give to Xastir to your user/group so Xastir doesn’t need to run as root.
Set up /etc/ax25/ax25ipd.conf on the client. Here, I’ve given it a route for all WIDE* traffic to the other host. It might be possible to just use 0 as I did before, I wasn’t sure if that’d create a loop or not.
broadcast QST-0 NODES-0
# This points to my P4, attached to the TNC; d means default route
route WIDE* 192.168.64.141 d
Now start up ax25ipd and Xastir, you should be able to bring up the interface and see APRS traffic, more over, you should be able to hit Transmit and see the TNC broadcast your packets.
Some stations visible direct via RF (click to enlarge)