bluetooth

A building-block for DIY Bluetooth audio devices

I’m a late adopter of Bluetooth, having previously tried Bluetooth in its earlier days, hearing something that sounded like my music was being fed down a drain pipe, and deciding that Bluetooth was rubbish… it wasn’t until I bought a Logitech H830 headset that I found that Bluetooth can actually sound decent… moreover when I bought the Logitech Zone Wireless, that bi-directional Bluetooth can also sound decent.

Now, the Zone Wireless is fine if I’m in the office, or out walking somewhere. It’ll fit underneath the coolie hat if I decide to wear that, otherwise it works with a cap just fine. BUT, if I’m camping or at a WICEN event, I’m often wearing a full-brim hard hat. The headband on the Zone Wireless is a problem.

I really wanted a Bluetooth device that could be put on a lanyard, and I just plug in a regular common-garden variety wired headset. The closest I can get to this is a motorcycle headset — as these have to accommodate a wide variety of helmet styles, the radio module and the headset are actually separate components, and so conceivably, I can make my own compatible adaptor to plug in. Then, it wouldn’t matter… want to wear the hard hat? No problem, I already have modded earmuffs with a headset. Want to use it on the bike? Sure, plug the helmet straight in. Or am I in the office again? No problem, normal headset.

It’d also be nice to share that wired headset with a wired audio device… prime example here is a radio transceiver. Yes, there are devices that will make those do Bluetooth… and there are radios that have Bluetooth. I had one of the latter: Yaesu VX8-DR … it’s Bluetooth was next to useless… idiosyncratic and unreliable.

I see the Sena SR-10 mentioned in a few places as a way to “Bluetooth-enable” a two-way radio… but aside from being pricey, I see three complaints being raised: unreliable/slow pairing, intermittent darlek-like distortion on transmit and a noticeable connection delay on incoming signals.

I pondered doing my own… and I’ve slowly amassed parts to do exactly that. But, the other day, I stumbled on another option: Altronics sell a CSR8635 Bluetooth module. This advertises the ability to talk to two Bluetooth devices, and wideband voice. CSR’s own datasheet seems to give some hints as to how it can be used.

One catch, is the pads on this device are a 1mm spacing — so mounting this on some perfboard is going to be a big challenge. I prefer the minimalism of a module like this over a Raspberry Pi Zero W… a lot less to go wrong, and likely much better battery life.

Building my own wireless headset interface

So, I’ve been wanting to do this for the better part of a decade… but lately, the cost of more capable embedded devices has come right down to make this actually feasible.

It’s taken a number of incarnations, the earliest being the idea of DIYing it myself with a UHF-band analogue transceiver. Then the thought was to pair a I²S audio CODEC with a ESP8266 or ESP32.

I don’t want to rely on technology that might disappear from the market should relations with China suddenly get narky, and of course, time marches on… I learn about protocols like ROC. Bluetooth also isn’t what it was back when I first started down this path — back then A2DP was one-way and sounded terrible, HSP was limited to 8kHz mono audio.

Today, Bluetooth headsets are actually pretty good. I’ve been quite happy with the Logitech Zone Wireless for the most part — the first one I bought had a microphone that failed, but Logitech themselves were good about replacing it under warranty. It does have a limitation though: it will talk to no more than two Bluetooth devices. The USB dongle it’s supplied with, whilst a USB Audio class device, also occupies one of those two slots.

The other day I spent up on a DAB+ radio and a shortwave radio — it’d be nice to listen to these via the same Bluetooth headset I use for calls and the tablet. There are Bluetooth audio devices that I could plug into either of these, then pair with my headset, but I’d have to disconnect either the phone or the tablet to use it.

So, bugger it… the wireless headset interface will get an upgrade. The plan is a small pocket audio swiss-army-knife that can connect to…

  • an analogue device such as a wired headset or radio receiver/transceiver
  • my phone via Bluetooth
  • my tablet via Bluetooth
  • the aforementioned Bluetooth headset
  • a desktop PC or laptop over WiFi

…and route audio between them as needs require.

The device will have a small LCD display for control with a directional joystick button for control, and will be able to connect to a USB host for management.

Proposed parts list

The chip crisis is actually a big limitation, some of the bits aren’t as easily available as I’d like. But, I’ve managed to pull together the following:

The only bit that’s old stock is the LCD, it’s been sitting on my shelf gathering dust for over a decade. Somewhere in one of my junk boxes I’ve got some joystick buttons also bought many years ago.

Proposed software

For the sake of others looking to duplicate my efforts, I’ll stick with Raspberry Pi OS. As my device is an ARMv6 device, I’ll have to stick with the 32-bit release. Not that big a deal, and long-term I’ll probably look at using OpenEmbedded or Gentoo Embedded long-term to make a minimalist image that just does what I need it to do.

The starter kit came with a SD card loaded with NOOBS… I ignored this and just flashed the SD card with a bare minimum Debian Bullseye image. The plan is I’ll get PipeWire up and running on this for its Bluetooth audio interface. Then we’ll try and get the hardware bits going.

Right now, I have the zero booting up, connecting to my local WiFi network, and making itself available via SSH. A good start.

Data sheet for the LCD

The LCD will possibly be one of the more challenging bits. This is from a phone that was new last century! As it happens though, Bergthaller Iulian-Alexandru was kind enough to publish some details on a number of LCD screens. Someone’s since bought and squatted the domain, but The Wayback Machine has an archive of the site.

I’ve mirrored his notes on various Ericsson LCDs here:

The diagrams on that page appear to show the connections as viewed from the front of the LCD panel. I guess if I let magic smoke out, too bad! The alternative is I do have two Nokia 3310s floating around, so harvest the LCDs out of them — in short, I have a fallback plan!

PipeWire on the Pi Zero

This will be the interesting bit. Not sure how well it’ll work, but we’ll give it a shot. The trickiest bit is getting binaries for the device, no one builds for armhf yet. There are these binaries for Ubuntu AMD64, and luckily there are source packages available.

I guess worst case scenario is I put the Pi Zero W aside and get a Pi Zero 2 W instead. Key will be to test PipeWire first before I warm up the soldering iron, let’s at least prove the software side of things, maybe using USB audio devices in place of the AudioInjector board.

I’m going through and building the .debs for armhf myself now, taking notes as I go. I’ll post these when I’m done.

New headset: Logitech Zone Wireless

So, recently I misplaced the headset adaptor I use for my aging ZTE T83… which is getting on nearly 6 years old now. I had the parts on hand to make a new adaptor, so whipped up a new one, but found the 3.5mm plug would not stay in the socket.

Evidently, this socket has reached the number of insert/remove cycles, and will no longer function reliably. I do like music on the go, and while I’m no fan of Bluetooth, it is a feature my phone supports. I’ve also been hacking an older Logtech headset I have so that I can re-purpose it for use at work, but so far, it’s been about 15 months since I did any real work in the office. Thanks to China’s little gift, I’ve been working at home.

At work, I was using the Logitech H800 which did both USB and Bluetooth. Handy… but one downside it had is it didn’t do both, you selected the mode via a slider switch on the back of one of the ear cups. The other downside is that being an “open ear” design, it tended to leak sound, so my colleagues got treated to the sound track of my daily work.

My father now uses that headset since he needed one for video conferencing (again, thank-you China) and it was the best-condition headset I had on hand. I switched to using a now rather tatty-looking G930 before later getting a ATH-G1WL which is doing the task at home nicely. The ATH-G1WL is better all-round for a wireless USB headset, but it’s a one-trick pony: it just does USB audio. It does it well, better than anything else I’ve used, but that’s all it does. Great for home, where I may want better fidelity and for applications that don’t like asymmetric sample rates, but useless with my now Bluetooth-only phone.

I had a look around, and found the Zone Wireless headset… I wondered how it stacked up against the H800. Double the cost, is it worth it?

Firstly, my environment: I’m mostly running Linux, but I will probably use this headset with Android a lot… maybe OpenBSD. The primary use case will be mobile devices, so my existing Android phone, and a Samsung Active3 8″ tablet I have coming. The fact this unit like the H800 does both Bluetooth and USB is an attractive feature. Another interesting advertised feature is that it can be simultaneously connected to both, unlike the H800 which is exclusively one or the other.

First impressions

So, it turned up today. In the box was a USB-C cable (probably the first real use I have for such a cable), a USB-A to USB-C adaptor (for all you young whipper-snappers with USB-C ports exclusively), the headset itself, the USB dongle, and a bag to stow everything in.

Interestingly, each of these has a set-up guide. Ohh, and at the time of writing, yes, there are 6 links titled “Setup Guide (PDF)”… the bottom-right one is the one for the headset (guess how I discovered that?). Amongst those is a set-up guide for the bag. (Who’d have thought some fabric bag with a draw-string closure needed a set-up guide?) I guess they’re aiming this at the Pointy Haired Boss.

Many functions are controlled using an “app” installed on a mobile device. I haven’t tried this as I suspect Android 4.1 is too old. Maybe I can look at that when the tablet turns up, as it should be recent enough. It’d be nice to duplicate this functionality on Linux, but ehh… enough of it works without.

Also unlike the H800… there’s nowhere on the headset to stash the dongle when not in use. This is a bit of a nuisance, but they do provide the little bag to stow it in. The assumption is I guess that it’ll permanently occupy a USB port, since the same dongle also talks to their range of keyboards and mice.

USB audio functionality

I had the Raspberry Pi 3 running as a DAB+ receiver, Triple M Classic Rock had The Beatles Seargeant Pepper’s Lonely Hearts Club Band album on… so I plugged the dongle in to see how they compared with my desktop speakers (plugged in to the “headphone” jack). Now this isn’t the best test for sound quality for two reasons: (1) this DAB+ station is broadcasting 64kbps HE-AAC, and (2) the “headphone” jack on the Pi is hardly known as high fidelity, but it gave me a rough idea.

Audio quality was definitely reasonable. No better or worse than the H800. I haven’t tried the microphone yet, but it looks as if it’s on par with the H800 as well. Like every other Logitech headset I’ve owned to date, it too forces asymmetric sample rates, if you’re looking at using JACK, consider something else:

stuartl@vk4msl-pi3:~ $ cat /proc/asound/Wireless/stream0
Logitech Zone Wireless at usb-3f980000.usb-1.4, full speed : USB Audio

Playback:
  Status: Running
    Interface = 2
    Altset = 1
    Packet Size = 192
    Momentary freq = 48000 Hz (0x30.0000)
  Interface 2
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 3 OUT (NONE)
    Rates: 48000
    Bits: 16

Capture:
  Status: Stop
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 1
    Endpoint: 3 IN (NONE)
    Rates: 16000
    Bits: 16

The control buttons seem to work, and there’s even a HID device appearing under Linux, but testing with xev reveals no reaction when I press the up/down/MFB buttons.

Bluetooth functionality

With the dongle plugged in, I reached for my phone, turned on its Bluetooth radio, pressed the power button on the headset for a couple of seconds, then told my phone to go look for the device. It detected the headset and paired straight away. Fairly painless, as you’d expect, even given the ancient Android device it was paired with. (Bluetooth 5 headset… meet Bluetooth 3 host!)

I then tried pulling up some music… the headset immediately switched streams, I was now hearing Albert Hammond – Free Electric Band. Hit pause, and I was back to DAB+ on the Raspberry Pi.

Yes, it was connected to both the USB dongle and the phone, which was fantastic. One thing it does NOT do though, at least out-of-the-box, is “mix” the two streams. Great for telephone calls I suppose, but forget listening to something in the background via your computer whilst you converse with somebody on the phone.

The audio quality was good though. Some cheaper Bluetooth headsets often sound “watery” to my hearing (probably the audio CODEC), which is why I avoided them prior to buying the H800, the H800 was the first that sounded “normal”, and this carries that on.

I’m not sure what the microphone sounds like in this mode. I suspect with my old phone, it’ll drop back to the HSP profile, which has an 8kHz sample rate, no wideband audio. I’ll know more when the tablet turns up as it should be able to better put the headset through its paces.

Noise cancellation

One nice feature of this headset is that unlike the H800, this is a closed-ear design which does a reasonable amount of passive noise suppression. So likely will leak sound less than the H800. Press the ANC button, and an announcement reports that noise cancellation is now ON… and there’s a subtle further muffling of outside noise.

It won’t pass AS/NZS:1270, but it will at least mean I’m not turning the volume up quite so loud, which is better for my hearing anyway. Doing this is at the cost of about an hour’s battery life apparently.

Left/right channel swapping

Another nice feature, this is the first headset I’ve owned where you can put the microphone on either side you like. Put the headset on either way around, flip the microphone to where your mouth is: as you pass roughly the 15° point on the boom, the channels switch so left/right channels are the correct way around for the way you’re wearing it.

This isn’t a difficult thing to achieve, but I have no idea why more companies don’t do it. There seems to be this defacto standard of microphone/controls on the left, which is annoying, as I prefer it and controls on the right. Some headsets (Logitech wired USB) were right-hand side only, but this puts the choice in the user’s hands. This should be encouraged.

Verdict

Well, it’s pricey, but it gets the job done and has a few nice features to boot. I’ll be doing some more testing when more equipment turns up, but it seems to play nice with what I have now.

The ability to switch between USB and Bluetooth sources is welcome, it’d be nice to have some software mixing possible, but that’s not the end of the world, it’s an improvement nonetheless.

Audio quality seems decent enough, with playback sample rates able to match DVD audio sample rates (at 16-bits linear PCM). Microphone sample rate should be sufficient for wideband voice (but not ultra-wideband or fullband).

It’s nice to be able to put the microphone on the side of my choosing rather than having that dictated to me.

The audio cancellation is a nice feature, and one I expect to make more use of in an open-plan environment.

The asymmetric record/playback sample rates might be a bit of a nuisance if you use software that expects these to be symmetric.

Somewhere to stash the dongle on the headset would’ve been nicer than having a carry bag.

It’d be nice if there was some sort of protocol spec for the functions offered in the “app” so that those who cannot or choose not to run it, can still access those functions.

COVIDSafe for older devices?

So, the other day I pondered about whether BlueTrace could be ported to an older device, or somehow re-implemented so it would be compatible with older phones.

The Australian Government has released their version of TraceTogether, COVIDSafe, which is available for newer devices on the Google and Apple application repositories. It suffers a number of technical issues, one glaring one being that even on devices it theoretically supports, it doesn’t work properly unless you have it running in the foreground and your phone unlocked!

Well, there’s a fail right there! Lots of people, actually need to be able to lock their phones. (e.g. a condition of their employment, preventing pocket dials, saving battery life, etc…)

My phone, will never run COVIDSafe, as provided. Even compiling it for Android 4.1 won’t be enough, it uses Bluetooth Low Energy, which is a Bluetooth 4.0 feature. However, the government did one thing right, they have published the source code. A quick fish-eye over the diff against TraceTogether, suggests the changes are largely superficial.

Interestingly, although the original code is GPLv3, our government has decided to supply their own license. I’m not sure how legal that is. Others have questioned this too.

So, maybe I can run it after all? All I need is a device that can do BLE. That then “phones home” somehow, to retrieve tokens or upload data. Newer phones (almost anything Android-based) usually can do WiFi hotspot, which would work fine with a ESP32.

Older phones don’t have WiFi at all, but many can still provide an Internet connection over a Bluetooth link, likely via the LAN Access Profile. I think this would mean my “token” would need to negotiate HTTPS itself. Not fun on a MCU, but I suspect someone has possibly done it already on ESP32.

Nordic platforms are another option if we go the pure Bluetooth route. I have two nRF52840-DK boards kicking around here, bought for OpenThread development, but not yet in use. A nicety is these do have a holder for a CR2032 cell, so can operate battery-powered.

Either way, I think it important that the chosen platform be:

  1. easily available through usual channels
  2. cheap
  3. hackable, so the devices can be re-purposed after this COVID-19 nonsense blows over

A first step might be to see if COVIDSafe can be cleaved in two… with the BLE part running on a ESP32 or nRF52840, and the HTTPS part running on my Android phone. Also useful, would be some sort of staging server so I can test my code without exposing things. Not sure if there is such a beast publicly available that we can all make use of.

Guess that’ll be the next bit to look at.

Implementing BlueTrace: the guts of TraceTogether

COVID-SARS-2 is a nasty condition caused by COVID-19 that has seen many a person’s life cut short. The COVID-19 virus which originated from Wuhan, China has one particularly insidious trait: it can be spread by asymptomatic people. That is, you do not have to be suffering symptoms to be an infectious carrier of the condition.

As frustrating as isolation has been, it’s really our only viable solution to preventing this infectious condition from spreading like wildfire until we get a vaccine that will finally knock it on the head.

One solution that has been proposed has been to use contract tracing applications which rely on Bluetooth messaging to detect when an infected person comes into contact with others. Singapore developed the TraceTogether application. The Australian Government look like they might be adopting this application, our deputy CMO even suggesting it’d be made compulsory (before the PM poured water on that plan).

Now, the Android version of this, requires Android 5.1. My phone runs 4.1: I cannot run this application. Not everybody is in the habit of using Bluetooth, or even carries a phone. This got me thinking: can this be implemented in a stand-alone device?

The guts of this application is a protocol called BlueTrace which is described in this whitepaper. Reference implementations exist for Android and iOS.

I’ll have to look at the nitty-gritty of it, but essentially it looks like a stand-alone implementation on a ESP32 module maybe a doable proposition. The protocol basically works like this:

  • Clients register using some contact details (e.g. a telephone number) to a server, which then issues back a “user ID” (randomised).
  • The server then uses this to generate “temporary IDs” which are constructed by concatenating the “User ID” and token life-time start/finish timestamps together, encrypting that with the secret key, then appending the IV and an authentication token. This BLOB is then Base64-encoded.
  • The client pulls down batches of these temporary IDs (forward-dated) to use for when it has no Internet connection available.
  • Clients, then exchange these temporary IDs using BLE messaging.

This, looks doable in an ESP32 module. The ESP32 could be loaded up with tokens by a workstation. You then go about your daily business, carrying this device with you. When you get home, you plug the device into your workstation, and it uploads the “temporary IDs” it saw.

I’ll have to dig out my ESP32 module, but this looks like a doable proposition.

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.

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.