Amateur Radio

Mucking around with AX.25 and APRS

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:

socket ip
mode tnc
device /dev/ttyS0
speed 9600
loglevel 2
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.

vk4msl-mb stuartl # kissnetd -p 2
kissnetd V 1.5 by Frederic RIBLE F1OAT - ATEPRA FPAC/Linux Project

Awaiting client connects on:
/dev/pts/1 /dev/pts/4
^Z
[1]+  Stopped                 kissnetd -p 2
vk4msl-mb stuartl # bg 1

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.

# ln -s /dev/pts/4 /dev/kiss-ax25ipd
# ln -s /dev/pts/1 /dev/kiss-xastir

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.

socket ip
mode tnc
device /dev/kiss-ax25ipd
speed 9600
loglevel 2
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

Some stations visible direct via RF (click to enlarge)

2013/03/31 by Amateur Radio Public Syndication WICEN 0

Hand-held radio musings

Just recently, I managed to kill yet another hand-held. Not deliberately, just a combination of conditions and not adapting my behaviour to suit.

I have a Yaesu VX8-DR, which I mainly use on the bicycle for APRS. It isn’t bad, the GPS could be faster, and the Bluetooth is more of a gimmick (in that it only works with some Bluetooth headsets and is intermittent at best), but my biggest nit with it, is that you can’t charge the thing while it’s turned on.

This leads me to the bad habit of just leaving a DC power lead semi-permanently plugged into the side, with the other end plugged into the 12V supply on the bicycle. You guessed it… one bad day of rain, some water got in via the DC jack and basically destroyed it.  I’m pretty sure warranty doesn’t cover that kind of abuse.

I’m not in a hurry to buy another one.  In fact, I probably won’t.  I’m too clumsy to look after an expensive one, so better just to keep the two Chinese cheapies going (Wouxun KG-UVD1P’s).  This lead me to thinking about what I specifically like in a hand-held, and what features I’d look for.

Looking around, it seems the vast majority of sets out there are evolutionary.  An extra handful of memory channels, higher power, bigger battery, ohh look Bluetooth, and this one has {insert some semi-proprietary-digital-mode here}.  Yawn!

Most of them have tiny screens which can’t show a decent amount of information at a glance.  Digital voice is a long way being usable, with about 3 or 4 proprietary or semi-proprietary competing standards.  What about D-Star you say?  Well, what about it.  Nice mode, pity about the codec.  How about P25?  Same deal.

If a digital mode is going to succeed in Amateur radio, it’ll be necessary for a home base to be able to implement it with nothing more than a desktop or laptop computer loaded with appropriate Free Software and a sound card interface.  Not a silly proprietary “DV-Dongle” or some closed-source blob that speaks gibberish no other software can understand.

As for portable use; it should be possible for a hand-microphone that implements the mode on a DSP be plugged into an existing hand-held (like the Wouxun or Yaesu sets I mentioned earlier) to make it interoperable — open standards will help keep costs down here.

Until such a mode comes along (and they’re working on it — already making excellent progress on HF, keep it up guys!) there’s no point in pouring money into a digital mode that will be a white elephant in a few years.

By far the most popular mode on VHF and UHF is plain old FM.  The mode Armstrong made.  It’s everywhere, from your cheap $100 Chinese firecracker set to the most expensive SDR, they all offer it.  Repeaters abound, and it’s available to pretty much all amateur license classes.  And it works good enough for most.

The big problem with FM, is interfacing with repeaters.  In particular, the big use case with hand-helds and repeaters, is being able to recall the settings for a repeater where ever you happen to be.  Now you can carry around a booklet with the settings written in, and punch them into your radio each time.

This works better for some than others.  On the KG-UVD1P with its horrid UI, it is a tiresome affair.  The Yaesu VX-8DR and Kenwood TH-F7E aren’t bad, once you get used to them.  It’s still fiddly and time consuming, definitely not an option while mobile.  This is where memory channels come in.

Now I realise that sets which stored more channels than you could count on one digit-challenged hand were considered a revolution about 10 years ago.  Back then the idea that you could basically control a digital counter, which would supply an address to an EEPROM that would spit out the settings to drive a PLL synthesizer and other control circuitry was truly remarkable.

Today, the EEPROM and counter have been replaced by a MCU that reads the keypad matrix and outputs to a LCD panel, but we’re still basically incrementing a counter that’s acting as an address offset into non-volatile memory.  The only change has been the number of channels.  The Kenwood set I had gave you 400.  The VX-8, gives you 1000 — which can be optionally grouped into 24 banks (by far the best system I’ve seen to date).  The Wouxun gives you a poultry 128.

The hardest thing about this is finding a given repeater in a list.  128 is more than enough if you don’t travel, or if you pre-programme the set with the appropriate channels in some logical ordering before you leave.  In there hints another factor; “logical ordering”, since there’s no way to sort the memory channels by anything other than channel number.

In this day and age, 1000 channels, linearly indexed, is a joke.  I can buy a 2GB MicroSD card from the supermarket for $10.   How much repeater data could you store on one of those?  FAT file system drivers are readily implementable in modern MCUs and a simple CSV file is not that big a deal for a MCU to parse.

It wouldn’t be difficult to build up a few indexes of byte locations to store in NVRAM, and have the CSV store frequency, call sign, a Maidenhead locator and other settings of all the repeaters in the country, then allow the user to choose one searching by frequency, by call-sign, or if the user gives their current grid square (or it derives it from a GPS), by proximity.  That would be a revolution.  The same card could also store a list of Echolink and IRLP nodes, and make a note of such nodes via RF so it can automatically suggest the nearest IRLP node, take you there, then dial whatever node for you after you announce yourself on the frequency.

I’ve seen more elaborate software written for 8-bit micros like the Apple II, the Commodore 64 and the Sinclair ZX Spectrum back in the day, so clearly not beyond today’s equally powerful AVR, PIC, MSP430 and ARM chips.  A STM32F103RE packs 64KB RAM, 512KB flash and a SDIO interface in a nice small TQFP64 package and costs less than $8.  Even for a Wouxun, that’ll maybe add no more than 20% still keeping it rather competitive with the opposition.

As for user interface?  We don’t need Android on there, although that could be nice.  A decent size resistive touch-screen with a reflective dot-matrix LCD would more than suffice.  This technology, thanks to mobile phones, is cheap enough to implement in this application.  The MCUs needed to drive them have also come down in cost greatly.

Even without the touch-screen — a LCD bigger than a matchbox would allow for text that is easily readable, menus that aren’t constrained in their presentation, and a generally nicer user experience.

SDR hand-helds will likely be the next big revolution, if they are affordable, but I feel that’ll be a way off, and for rag chew on a local repeater, I doubt SDR will be that much superior.  It certainly will push the price up though.

I suppose a start will be to try and come up with a suitable front-end device that can be bolted onto existing transceiver hardware, maybe something that drives the computer control port of a mobile rig such as the FT-857 or IC-706.

From there, it just takes one brave manufacturer to package such a device up with a suitable transceiver in a hand-held form factor to put something to market.  If they did so in a way that could keep this UI module open-source, even better.  Bonus points if there’s a bit of an interface that can take a DSP for digital modes.

Want D-Star, P25, FreeDV, Wongi?  You got it, just slot in the right module, load on the firmware into the UI module, and away you go.  Want to do something special?  Break out the text editor and compiler and start hacking.  The RF side of things can still be as it was before, so shouldn’t pose any more of a problem for regulators than a transceiver with a digital modes jack and computer control interface.

I’m not sure if anyone has worked on such a front-end.  Another option would be a cradle that takes a modern smart-phone or tablet, interfaces via USB to the set, and uses the smart-phone as the UI, also extending the phone’s battery at the same time by supplying the 5V it needs to charge.  Bonus points if it can feed the audio signal to/from the phone for digital modes and/or interfacing with BlueTooth.  A pocket APRS I-Gate and Echolink node, perhaps?  Whatever takes your fancy.

I guess the real answer here will be to come up with something and see if there’s any interest — the “throw it against the wall and see what sticks” approach.

2013/03/08 by Amateur Radio Public Syndication Rants Thinktank 0

Full-duplex streaming between sound cards with GStreamer

Some may recall my old set up I used to record the AWNOI net. A bit fiddly, but it worked, and worked well. However the machine I used was short-lived. Basically, I wanted to stream in both directions between a sound device connected to a HF radio transceiver, and a USB wireless headset, with a feed being recorded to disk.

The problem with newer sound devices is the rather limited sync range possible with the modern audio CODECs. Many will not do sample rates that aren’t a multiple of 44.1kHz or 48kHz, and I have a headset that won’t record any other sample rate other than 16kHz. ALSA’s plug: doesn’t play nice with JACK, and I shelved the whole project for later.

Well, tonight I did some tinkering with gstreamer to see if it could do the routing I needed. Certainly all the building blocks were there, I just had to get the pipeline right. A bit of jiggling of parameters, and I managed to get audio going in both directions, and to a RIFF wave file to boot. I’ve put it in a shell script for readability/maintainability:

#!/bin/sh
# GStreamer bi-directional full-duplex audio routing script
# Stuart Longland VK4MSL

CAPT_BUFTIME=50000
CAPT_LATTIME=25000
PLAY_BUFTIME=20000
PLAY_LATTIME=1000

STREAM_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
OUTPUT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=16000
OUTPUT="${1:-out.wav}"

HEADSET_DEV=hw:Headset
HEADSET_CAPT_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
HEADSET_CAPT_BUFTIME=${CAPT_BUFTIME}
HEADSET_CAPT_LATTIME=${CAPT_LATTIME}
HEADSET_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
HEADSET_PLAY_BUFTIME=${PLAY_BUFTIME}
HEADSET_PLAY_LATTIME=${PLAY_LATTIME}

SNDCARD_DEV=hw:NVidia
SNDCARD_CAPT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_CAPT_BUFTIME=${CAPT_BUFTIME}
SNDCARD_CAPT_LATTIME=${CAPT_LATTIME}
SNDCARD_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_PLAY_BUFTIME=${PLAY_BUFTIME}
SNDCARD_PLAY_LATTIME=${PLAY_LATTIME}

exec    gst-launch-0.10 \
    alsasrc device=${HEADSET_DEV} \
            name=headset-capt \
            slave-method=resample \
            buffer-time=${HEADSET_CAPT_BUFTIME} \
            latency-time=${HEADSET_CAPT_LATTIME} \
        ! ${HEADSET_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=headset \
        ! audioresample \
        ! audioconvert \
        ! ${SNDCARD_PLAY_FMT} \
        ! alsasink device=${SNDCARD_DEV} \
            name=sndcard-play \
            buffer-time=${SNDCARD_PLAY_BUFTIME} \
            latency-time=${SNDCARD_PLAY_LATTIME} \
    alsasrc device=${SNDCARD_DEV} \
            name=sndcard-capt \
            slave-method=resample \
            buffer-time=${SNDCARD_CAPT_BUFTIME} \
            latency-time=${SNDCARD_CAPT_LATTIME} \
        ! ${SNDCARD_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=soundcard \
        ! audioresample \
        ! audioconvert \
        ! ${HEADSET_PLAY_FMT} \
        ! alsasink device=${HEADSET_DEV} \
            name=headset-play \
            buffer-time=${HEADSET_PLAY_BUFTIME} \
            latency-time=${HEADSET_PLAY_LATTIME} \
    interleave name=recorder-in \
        ! audioconvert \
        ! audioresample \
        ! ${OUTPUT_FMT} \
        ! wavenc \
        ! filesink location="${OUTPUT}" \
    headset. \
        ! queue \
        ! recorder-in.sink1 \
    soundcard. \
        ! queue \
        ! recorder-in.sink0

Now the fun begins ironing out the kinks in my data cable for the FT-897. At present, it works for receive, and seems to work for transmit. I use VOX on the radio itself and keep the headset’s microphone on mute when I don’t want to transmit.

At present, I was getting a bit of distorted audio coming back through the headset when I transmitted, almost certainly RF-pickup in the cable and line-in circuitry of the computer’s sound card. I’ll have to see if I can filter it out, but the real test will be seeing if such distortion is present on the outgoing signal — or rather, if it’s significantly audible to be a problem.

2012/04/21 by Amateur Radio Public Syndication Thinktank 0

Inside the GL4Ever Flytouch III

Well, it’s been a while since I touched this tablet.  I basically chucked it in a corner in disgust after it shat itself rather unceremoniously on the trip before we even got to the NSW/Victorian border.  By “shat” itself, I mean corrupting files on the internal microSD card, intermittent device resets, display flickers, all the hallmarks of a dry joint.

The seller on eBay that sold me the device have been completely unresponsive as to the problems, so looks like I kissed about $250 goodbye.  Ahh well, such is life.  They are still being sold on eBay, but buyer beware, they are cheap, and it’s pot luck whether yours is cheerful, or nasty like mine.  If you want something reliable, look elsewhere.

Having made this mistake, well, I’m looking to make lemonade from the lemon.  First step, was to figure out what on earth I had.  So out with the screwdriver.

You’ll notice on the top and bottom of the unit, there are four small plugs concealing screws.  These hold the LCD screen assembly in place.  Undo these, then you need to carefully work your way around and release the clips that hold the LCD screen assembly.  Do not try to detach the LCD touch panel from the LCD!  I initially couldn’t get it to budge, so I tried doing exactly this in the hunt for possible hidden screws (there were none).  This was the end result:

Shattered Flytouch III touch panel

Why one should not try to detach the touch panel.

Never mind I say… the unit was just about destined for the bin as it was.  External USB HID devices work for what I’m after, but it’ll mean any touch-related fun is out unless I can pick up a replacement 4-wire panel.  Element14 and RS have them at >$80, to which I say, bugger it, I’ll do without.

Having pulled the unit apart, the main PCB is held to the back shell by a few screws, one thing is immediately apparent.  The whole device is based on what looks to be a fairly generic System-on-Module based around the Vimicro VC0882BCXA System-on-Chip, and the Vimicro VC7822EL companion chip.

Flytouch III PCB

Top left is a Wifi module based on the Realtek RTL8111, and to the right, the GPS module (which hooks to one of the serial ports from what I recall).  Down the bottom of the image are the USB ports.  Near the HDMI socket is a Silicon Image SiI9022ACNU HDMI transmitter.

The system on module looks interesting, and I’m curious to find out more about it, as for hobby projects, the pins are not too small to deal with using a soldering iron.  The OS and boot loader exist on the microSD card.  I tried putting a 16GB card in, but evidently I wasn’t getting the partition table right as it wouldn’t boot.  I haven’t tried hooking up a serial port as yet, so it’s hard to know what is wrong.  Some research indicates that ttyS0 lurks on this board just near the aforementioned microSD socket:

The system on module within the Flytouch III

The system on module within the Flytouch III

I haven’t spotted the bad joints that were giving me grief. In fact, having gotten it out of the case, I find the top USB port (flakey from day one) seems to be behaving, and I’ve had no issues with it running with the case apart.  Otherwise I’d be running a soldering iron over a few joints just to make sure everything was right.

Next step?  Well for now, I’ll put it back together (minus touchscreen) and put it aside.  I’ll have a look at tacking a connector onto those serial pins, with a level shifter so I can interact with the serial console.

Having gotten bootloader access, I should be able to debug the SD card cloning issue, then I can have a close gander at what the current u-boot and kernel are doing to tickle the hardware.  End game?  Well, Android isn’t much use without a touch screen, so I’ll be probably hacking together a Gentoo-based environment with some amateur radio related software.  We shall see.

2012/04/01 by Amateur Radio Linux Development Public Syndication Thinktank 0

Experiences with the Yaesu VX-8DR

Prior to my road trip to LCA 2012 Ballarat, I bought a new toy, namely a Yaesu VX8-DR handheld.

At that point it turned up only just before I was due to leave, so I wasn’t able to get the accessories I wanted. I cobbled together my own 12V charger lead by snipping the original power supply and soldering on a cigarette lighter socket, but otherwise I used the handheld in its out-of-the-box configuration.

Having gotten back, I have purchased the FGPS-2 GPS module, CT-136 GPS adaptor and the BU-1 Bluetooth module.

Transceiver performance

The set works quite well. The antenna is pretty deaf and useless on 6m, maybe I can get a better after-market tri-bander whip, but on 2m and 70cm it works reasonably well. I’ve heard APRS traffic over distances of 100km, and even been heard on APRS by a digipeater some 90km away.

Audio quality is good, both transmit and receive. Plug in a pair of stereo headphones, and the wideband FM receiver sounds excellent; in stereo to boot.

Probably my biggest nit, is you can’t simultaneously charge and externally power the set. To charge, you must either detach the battery and drop it into a separate charger cradle (an optional extra) or turn off the set.

GPS Performance

When I purchased the VX-8DR, it was a real toss up between it and the VX-8GR. The reason I went the VX-8DR was because it had 6m, and Bluetooth. Having gotten the GPS, I’ve run into the problem a lot have reported; the GPS module is deaf as a post.

The VX8-GR doesn’t improve on this either. However, the good news, is that because my module is external, I can (1) mount it in a better spot, or (2) replace it with a better compatible module.  For VX8-GR owners, this is the end of the road, they can do nothing but moan to Yaesu.  I at least have options.

The module is mounted vertically inside the FGPS-2 casing. Usually with GPS modules such as these, they embed a small patch antenna, whose radiation pattern is perpendicular to the plane of the antenna surface. Being vertical, this means when you hold the radio vertically (as you normally would), GPS reception is poor because the radiation pattern is directly in front of the radio.

The radio seems to perform a lot better, if the radio is held with the screen facing upwards towards the sky. It’ll even work inside my house if I do this. It seems this is a screw-up on par with the iPhone 4.  Another alternative is to replace the module, the FGPS-2 apparently uses 9600 baud serial with NMEA format strings.  However, it seems the parser in the VX-8 is rather crude.  I have a module that does NMEA at 4800 baud, so I’ll either need to coax it up to 9600, or use a microcontroller to buffer and convert rates, and perhaps do some tweaking of the sentence format to make up for the VX-8’s shortcomings.

My hunch; if I make an alternative bracket to the CT-136 adaptor, I can nail this, and another problem, the inability to plug in the GPS and a headset. I have the CT-M11 cable, and thus I plan to make a bracket to connect the FGPS-2 to the end of this cable; allowing me to also plug in a wired headset.

Bluetooth

I bought the Bluetooth as an insurance policy to give me another means of interfacing a headset. Then began the fun of getting it to work with my headsets. I have a couple; a Bullant earmuff-headset, a lightweight mono Digitech headset, and a “MyTalker” headset.

The first was one set I bought some years ago, back when the Bluez was far less stable than it is today, and also long before I was into Amateur Radio or possessed a Bluetooth-capable phone. I tried pairing using a USB Bluetooth dongle, but had little luck, so they got put on one side. Also despite advertising being able to stream music, it only supports HFP and HSP profiles, so you get to listen to your tunes in 8kHz 8-bit mono. They are sold at some hardware stores, such as Mitre 10 The Gap (where I bought my set).

The handheld did pair with this set, but I couldn’t get PTT to work, and the headset itself also had a few faults; namely it was always noisy, and the broadcast receiver stopped working, so I’ve taken them apart for now to see if I can fix these issues. I can key the radio up using the radio’s PTT, but then both internal and headset microphones go live.

The second set is sold by Jaycar, catalog number AA2080. This would be my preferred set to use with the radio as it can pair with two devices simultaneously. It supports the same profiles as the earmuffs, but it’s at least more lightweight.

The BU-1 takes one look at this set, and turns its nose up at it, with the VX-8 giving up and displaying “PAIRING ERROR”.

I also bought the MyTalker set from Jaycar, catalog number XC4894. This set is much like the earmuffs. It embeds its own microphone, but the unit itself provides a 3.5mm socket for you to plug in your own headphones, or use the supplied earphones (which are awful and uncomfortable, don’t use them). At the other end of the unit, is a lead terminated with a 3.5mm plug to plug into a music player. I’ve modded this set to be able to use an external microphone, switchable between a transceiver and the Bluetooth set, allowing a headset connected to a radio to also connect to a phone. I’m still working on this bit.

The VX-8 treats this set with much the same contempt as the mono headset before.

Today, I poppsed in and bought a more expensive set; this time I looked for A2DP functionality, Jaycar have one, catalog number AA2082. Like the AA2080 it can talk to two devices, unlike the AA2080 it supports AVRCP and A2DP. Also, not advertised, is it can function as an analogue headset; supplied in the box is a dual 3.5mm to mini-USB cable that can plug into the headset and allow you to use it with a non-Bluetooth capable device.

I plugged it into the bicycle’s battery to charge on the way home. When I got home, I read the instructions (which are in awful Chinglish). Basically, the English translation of the pairing instructions go like this:

  1. Hold in the MFB button (the centre one on the right ear-cup) in for several seconds. You will hear the voice prompts “Hello”, followed by “Enter Pin Code 0000 on phone”.
  2. When you hear the latter prompt, tell your device to start looking for the headset
  3. When it finds a device called “AA2082”, select it, and enter 0000 as the pin code

So, the steps I followed:

  1. Turn on the VX-8
  2. Hold in the MENU key to bring up the Set menu, then select BLUETOOTH PCODE
  3. Enter 0000 on the keypad.
  4. Hold in the MFB button on the headset until you hear the “Enter Pin Code” prompt
  5. Hit V/M on the VX-8
  6. After a few brief moments, you should see “PAIRING COMPLETE”, press PTT to confirm.

Having got this working, I notice a few things:

  • Stereo (A2DP) sounds a little weird, perfectly clear, but the compression is apparent. I’ll experiment with the laptop later to see if it’s the headset or the radio.
  • Mono works well, pressing MFB toggles PTT on the VX-8. VOX doesn’t seem to work, but no great loss as I find VOX to be a disaster when outdoors.
  • In mono mode, a buzzing is apparent on the received audio. This isn’t audible on transmitted audio, nor did I notice this on received audio when I tried using the headset with my mobile phone.
  • Range seems to be quite restricted, possibly due to where the module is installed it doesn’t get the reception it perhaps needs. A2DP suffers more from this than HFP, with drop-outs being frequent. Again, I’ll need to do some experimentation with the laptop, and perhaps some experimentation with the radio without the battery installed to see if that helps performance.

I’m tossing up whether I get one of these motorcycle Bluetooth headsets.  I ride on the bicycle quite a lot, and at the moment I use headsets embedded in the helmet that are home-built from old computer headsets.  The longevity of the microphone seems to be the biggest problem  I also am on the look-out for an earmuff headset for things like the Imbill car rally, ideally one that can do A2DP.  The Bullant ones I know can’t do this.  I see some earmuffs in the $400+ price bracket that offer Bluetooth, but no idea if that includes A2DP, and frankly, I shudder at that price.

The motorcycle ones are designed to fit a wide range of helmets, and they look as if they’ll fit a set of cheap regular earmuffs quite well.  They typically sell for about $200, support A2DP, multiple devices, and intercom.  Add in $30 for a set of earmuffs, and it makes this a much more attractive option.

More experimentation will be needed I think, but this is looking promising.  I’ll probably post up more details as I come across them.

It’d be nice if Yaesu had been a bit more up-front on what the BU-1 supports: the AA2080 supports both HFP and HSP, yet the BU-1 won’t touch it, the Bullant set supports the same profiles yet the BU-1 works fine with it.  The reasoning for this is not clear, but it does seem that it’ll reliably talk to A2DP capable headsets, so maybe that is a starting point for others.

Likewise with the CT-136, I’ll see if I can fabricate a bracket using the CT-M11 cable, and see where that gets me.

2012/03/24 by Amateur Radio Public Syndication Rants Thinktank 0

Build Log: 60W 2m Linear: Day 2

This post may also be read here.

Well, today I did some more work on the 2m linear.  Earlier this week I ordered some SMA connectors and some 1N5711 diodes for the project.

Two 1N5711 diodes will be used to make a voltage peak detector, to detect when the amplifier is subjected to power above 60mW.  The SMA connectors will be the interconnects between the modules.  This afternoon’s effort was spent soldering the SMA connectors onto two of the boards, and mounting the 2m amplifier module onto the heatsink.

The EME157B2 preamplifier kit was originally intended to be mounted in a masthead box, with BNC connectors soldered to the PCB, and stuck up a pole near the antenna.  In my application, I wanted it to be in the same enclosure (with suitable shielding) as the power amp, so that I could use its RF detection to automatically switch the power amplifier on.  I will also be using different relays, mounted on a separate board.

Instead of mounting the SPDT relays for the kit on the EME157B2 board, I’ve instead left these off.  I also omitted the 2N7000 MOSFET which turns on the relays, and L4, an RF-blocking choke which permits the preamp to run from a 12V source supplied up the coax.  I instead will power the preamp directly.

Since the relays will be on a separate board, the plan is to run wires from the gate and source connections where the 2N7000 belongs, and run those out to a controller board.  With the relays gone, the RF detection and the preamp are essentially two distinct circuits.  So 3 SMA connectors will be needed.  Here is the completed board with the SMA connectors fitted, and suitable jumpers installed, ready for tuning.

Completed 2m preamplifier

Completed 2m preamplifier. Connectors going left-to-right: Antenna input, Amplifier output, RF detector input.

Next, I finished off the power amplifier board, mounting it to the heatsink.  I have left one EMC filter disconnected for now, as the instructions say to power it up first with it disconnected to set the trim pot for 4.5V bias.  Rather than mounting the board flat on the heatsink, I have instead opted to mount the PCB at 90? to the module.  I had to make the supplied eyelets a fraction longer to accommodate this.  I also mounted SMA connectors on this board.

Completed 2m power amplifier

Completed 2m power amplifier. RF input is on the left.

The plan is, I’ll route RG195 coax on the left side to a small module which will contain the overload detection circuit and two SMAs for an external attenuator module.  On the right, a low-pass filter will be connected.  I also had a stab at tapping holes into the sides of the heatsink for mounting a bracket.  This bracket would hold the fans on top, and would bolt onto the main enclosure.  In doing this, I managed to bugger up two of the 8 holes, and thus what I’ll probably do, is buy a M4 tap tomorrow, drill them all out to 3mm and tap them to 4mm.  These are structural holes, so bigger is probably better anyway.

Much of today though was spent designing the controller.  I’m still finalising the design, but a rough schematic is below.

2m amplfier controller

2m amplfier controller

So, not yet going, but big parts are built now.

2011/08/13 by Amateur Radio Homebrew Public Syndication 0

Build Log: 60W 2m Linear: Introduction and Day 1

This build log is also viewable here.

Background

A few months back, I grabbed the trusty FT-290R II ready to do my weekly run from The Gap to Tarragindi.  Quick test to check everything’s okay… the power meter swings to full scale, but strange, I’m not hitting any repeaters.

Okay, grabbed the FT-897D instead, and I just did my weekly radio duties with that instead.  When I came home that evening, I had a closer look.  The FT-290R II was emitting a signal, the hand-held was picking that up.  It was also receiving just fine.  On a hunch I took off the FL-2025 linear, and hooked the antenna up directly to the radio.  Bingo… the radio works, the linear does not.

So, the linear had died, and thus I was in need of a new one.  Hand helds really don’t have much punch for mobile use, in fact, the FT-290 has been brilliant on the bike.  Not menu driven, so it’s real easy to drive while riding, simple, no frills, and sufficient grunt to get out of a bad area.  It also does SSB (and CW, but I’ll leave that to LY2KW).

I could buy a new set, in fact, I may get a FT-857D, as the 897D is a heavy lump of a radio to lug around, and there are times when HF capability is useful.  It is less than ideal on the bike however due to its size and weight.  There was nothing wrong with the FT-290, just its linear was dead, thus I was limited to its barefoot transmit power of 2.5W, even less than most handhelds.

So, I decided I’d try my hand at a semi-homebrew linear amplifier.

The concept

I wanted an amplifier that could achieve at least 25W of transmit power using SSB.  As I’d likely use it for things like WIA broadcasts, I wanted one that would also handle transmitting for a long period of time.

Designing a full blown amplifier on 2m is a bit beyond me with my limited homebrew experience.  It is also an issue sourcing the PCB material needed for VHF projects.  A lot out there call for FR4 grade fibreglass PCBs.  I have no idea what Jaycar sell.  So this was going to be a potential minefield.  Thus, I opted for a kit.

Minikits sell one based on the Mitsubishi RA30H1317M.  The same kit, can also take the 60W module, which sounded good to me.  Most of the time I’d be running it at 30W, but having 60W capability sounded good.  I purchased this, along with the 30W module as well just in case.

I also thought a pre-amp would be nice.  The same supplier sells this preamp kit.  The kit also offers RF sensing, which would allow the amplifier to auto-detect the radio transmitting, and switch into transmit mode automatically.  This also allows for filtering, to prevent reception of pagers (not fun copping an earful of one of those when you’re wearing a helmet-embedded headset riding a bicycle).

Cooling

Minikits recommends using a Pentium 4 heatsink for 30W modules, however it wasn’t clear if this would be sufficient for 60W modules.

I wanted the amplifier module to stay below 100?C while operating with ambient temperatures at 40?C.  Pretty sure I don’t want to operate a radio under such conditions, so it should work fine in all conditions that I’m likely to encounter.

The amplifier module is about 45% efficient, thus about 135W is dissipated when operating at full power.  By my calculations, I was looking for cooling that can provide 0.22?C/W.

A quick search revealed that I could get one via Conrad which in the open air achieves 0.84?C/W.  Combined with a fan, it can achieve 0.24?C/W.  Jaycar sell this fan, which is quite capable.  In fact, two of them will fit across the back of the heatsink, so with dual fans, I should be well and truly within limits.

I placed the order for the heatsink a fortnight ago.  Due to a mix-up, I didn’t get it until Wednesday, but that’s fine, I wasn’t in any hurry.  With the heatsink now in my possession, I today headded to Jaycar to pick up some of the bits and pieces I’d need for this project, starting with the enclosure.

One thing I did neglect to procure today, were the fans… but no biggie, I’ll get those later.

Prior work

Well, technically day one was some time ago.  I had already mostly built the amplifier kit, and the preamp.  The preamp got built way back when I first obtained the kits.

The power amp was built later, however the instructions suggested that I wait until I have the amplifier module mounted on the heatsink before I go soldering it to the PCB.

Amplifier kit and 60W module

Amplifier kit and 60W module

Day 1

Having got the heatsink, enclosure and tools, I set to work.  Initially I positioned, drilled and tapped the two M3 holes for mounting the amplifier module.  I haven’t tried putting the amplifier in place yet, but it looks like the holes are positioned pretty well.

Amplifier module on heatsink

Amplifier module on heatsink

My plan, is to bend the pins on the module at 90? and mount the PCB horizontally.  Both module and PCB would be passed through the side wall of the enclosure, with the heatsink outside.  I originally wanted the heatsink inside the case (with vent holes), but of course, Jaycar are not good at providing internal dimensions, and I soon discovered it’d be awkward to fit.

It took a bit of experimentation to cut the hole in the side.  No, I won’t be winning any prizes for my metal work, in fact, it never was one of my best subjects.

Heatsink and empty enclosureHeatsink and empty enclosure (side view)

Heatsink and empty enclosure

Next steps:

My immediate next step will be to mount the amplifier module, solder it to the PCB, and mount the PCB inside the case.  Then I mount the heatsink and fans to the case.

I have a controller that I have designed at digital logic level, however I’ll need to do some further design work to make sure it’ll do what I intend, before procuring the parts and building it.

2011/08/04 by Amateur Radio Homebrew Public Syndication 0

RFC: Evening Ragchew Contest

The problem

For some time now, we’ve been putting up with interference from a few stations, who for now will remain nameless.  Foul language, deliberate interference, the list goes on…

Allegedly some of these people have been doing it for longer than I’ve been alive.

It is as if, these people, believe we are not entitled to use a small patch of radio spectrum to engage in a little friendly chat.

Some have even gone as far as vowing to do “everything they can” to “ruin” amateur radio.

This means war.

Well, we could complain to the ACMA… apparently some have done this already… many times.  If they haven’t acted after 20 years worth of complaints, I don’t think they’ll ever act.  Not without a very substantial amount of evidence.

There is nothing however, that stops us, getting on the band and having a chat, except one thing.  Someone parking on the frequency we choose and interfering with our communications.  Yes, we could QSY, but experience has shown the culprits just chase us up and down the band.

They cannot be on all frequencies however.  One big group, on one frequency, is vulnerable to attack.  Numerous smaller groups, scattered across the band however, is far more resilient.  They cannot be on all frequencies at the same time.  More to the point, more ears open and listening, means more data points … bonus points if those “ears” are directional.

My proposal

What we need to do is stir up some activity on the 80m band.  The 80m amateur band is a wonderful local chit-chat band.  It has almost guaranteed propagation for distances over 1000km on any given evening.  It is open to all license classes.  (Well, if you ignore the DX window.)  I’m proposing a contest with a difference.

Most contests, you make contact with a station, exchange numbers, then it’s ta ta… (or “73”) and you go your separate ways.  Not terribly exciting listening.

I’m proposing a social ragchew contest.  I want to encourage as many people, on as many groups, as possible.  The more people, the better.  Talk about anything you like.  QRP and QRO stations welcome.  Mobile and portable stations, also welcome.  Newcomers, especially welcome.  Make it a large group, or a small group, doesn’t matter.  It doesn’t have to be a formal net, just so long as there’s at least three people.

How will it be scored?

This is something I’m still thinking about… but I’m thinking something along these lines… I would love your input.

For every hour, or part thereof, each member of a group chatting on the same frequency, will get one point for each member of that group.

So if 3 of you talk for 2¼ hours, that’s 3×3=9 points.

Multipliers

  • Triple points for every station who has held their license:
    • Less than 12 months
    • Greater than 50 years
  • Double points for every:
    • Station that is “mobile” (i.e. moving between localities) or  “portable” (i.e. set up temporarily at some location for less than one week)
    • QRP station (running 5 watts or less)
    • DX contact (overseas)

I’m thinking these should be added together, so if in your group of VK’s you happen to score someone joining your group from Europe (for example) that only just got their license a month ago and is running QRP whilst mobile, add 24 points to each group member for every hour or part thereof that they participate on your group.

What about interference?

More than likely, this will stir up the trolls that seek to ruin our experience.  Part of the aim of this, is that a lot of people will be listening.  The following is something anyone can do, even the shortwave listeners.

  • Log the following:
    • the time in UTC
    • your location (latitude/longitude or Maidenhair Locater)
    • the signal strength
    • the nature of interference
  • If you can, record the interference
  • If you have a directional antenna, point that in the direction where the signal is strongest.  Use that to measure the signal strength, and log the bearing, along with the antenna type.

With enough evidence, we can flush out these serial pests once and for all.

When will it be held?

This is open to discussion… I’m thinking Friday or Saturday night.  I’m thinking it should start some time in the evening when the band opens up, maybe after 7:00PM.

The contest should remain open until the last group participating in the contest goes clear… if a group manages to successfully run to dawn the next day, good on them, maybe there should be bonus points for their efforts. 🙂

Let me know what your thoughts are… this is, as I say, a request for comment.  Feel free to get in touch with me directly or leave a comment here.

2011/07/17 by Amateur Radio AWNOI Net Public Syndication Thinktank 0

Open letter to Mal Moors, VK3CWM

(I’m not one normally for airing dirty laundry in this manner, but I feel it is marginally better than airing it on the air.)

Dear Mal,

Please.  What is your problem?

This evening, your behaviour on this band was absolutely appauling.  For someone who has apparently had a radio license for longer than I’ve been alive, I am disappointed.  Sadly this is not an isolated incident but for now I’ll turn a deaf ear to previous offences and just focus on tonight’s offence.

I’m not sure if you’re the one that has been playing music over the top of us… some have made this allegation.  I’m happy to give you the benefit of a doubt, but the tirade that followed is very unbecoming of a radio amateur.  Foul language, deliberate interference, not identifying, name-calling, and generally making a nuisance.  As best I can tell, completely unprovoked.

You claimed, “I was here first”.  I was listening on 3584kHz from around 9:15PM.  I did hear Danny ask “Is the frequency in use“.  Several times.  I was mobile at Red Hill at the time.  Prior to this the frequency, as best I could hear with my marginal antenna, was devoid of all activity.  None the less, we gave you the benefit of the doubt, and after listening to your protest, we did the respectful thing and QSY’ed to 3590kHz.

Not a minute after we had done so, there you were, trying to talk over us (and only succeeding with the exceptionally weak stations), and misbehaving as before.  We had left you 3584kHz, moved to 3590kHz, and you followed us up the band.  Why?

All I have heard, is the ramble from a seeming madman.  All I, and others want to do, is use of 2.4 kHz, to have our friendly weekly chit chat.  You are even welcome to join in if you wish to be civil and play by the rules.  If you wish to have a discussion with someone else, we are not going to stop you.

On the 80m band, you’ve got 3.503kHz to 3.700kHz and 3779kHz through to 3800kHz.  You can go anywhere on that spectrum which isn’t already in use, why pick the frequency we’re using?  If you still wish to use the frequency we’re on, why not do the gentlemanly thing, and ask politely?  We’re reasonable, we will move if you ask nicely.

Please, I am asking as nicely as I possibly can, please leave us alone.  We do not wish to interfere with you, please don’t interfere with us.

Regards,

Stuart VK4MSL, and other regulars of the Australia Wide Night-Owl and Insomnia Net.

2011/07/09 by Amateur Radio AWNOI Net Public Syndication Rants 0

An example of a true DC-to-daylight station

Some have looked at my bicycle, with the HF regalia and have commented on how extreme the setup there is.

However, it is worth pointing out, my station only covers the bands between 80m and 70cm (3.5 ~ 450MHz).  The radio can do 160m, however my license doesn’t permit me to go there, and 80m really stretches the friendship of the autotuner as it is.

For true DC-to-daylight though, or very close to it, have a squiz at the portable/field day station setup Roy VK4ZQ has come up with.  This is as close as most will ever get to DC-to-daylight… covering all bands from 80m through to 3cm.  Nicely done.

2011/06/30 by Amateur Radio Public Syndication 0
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