First ham app for Android

My first Android app

I thought that some of you might be interested to look at the first app I have completed using Basic4Android (B4A) called WhereAmI. It's no great shakes as an app, and I think there is at least one other in the Android Market that does a similar job. My app's unique feature is that besides the locator it shows the national grid reference (NGR) as well as the Worked All Britain (WAB) square. WAB is a popular activity on the low HF bands over here.

Because NGR and WAB only cover the UK, my app will not be very useful if you are outside of Great Britain. Indeed the app will probably blow up if you try it outside the UK as I haven't included any test that the user is within these sceptred isles.

I'd rather not say how long the app took me to complete, but it was far longer than expected given that I had already written code to convert from lat/long to grid locator in VOAProp. That code was in Pascal, and the trouble was caused by the fact that Basic4Android does not have equivalent functions to those in Pascal, or even Visual Basic, so I could not just do a copy and paste. In the end I found a conversion routine written in C++ and converted that to B4A's dialect of Basic. From there on it was easy, as there is a user-written library in B4A to handle conversions to/from National Grid references, upon which the WAB programme is based.

If I don't try something else I might have a go at displaying a Google Map centred on my location, as one of the examples that come with B4A does just that.

I don't plan on publishing any of the apps I create in Google Market (or Google Play as I think they now call it). I am doing this just for fun. Think of this as the programming equivalent of those radio projects knocked together on a breadboard or built Manhattan style, with no expectation that they will get put into a nice box.

If there is any interest I will make available the B4A project files as a zip file so that folks can play with them, hack them about or use them as a starting point for something better.

RR9O back on the air

ChangeDetection sent me an alert that the International Beacon Project web page has changed. The Hawaii beacon KH6WO has gone off the air.

The Russian beacon RR9O is still shown as off the air but I noticed today that Faros has recorded several spots of this beacon on the 17m and 12m bands. Other amateur beacon monitor sites have recorded it as well. I have updated the beacons.txt file for VOAProp with both changes.

Seeing red

I just started up Google Chrome and my eye was caught by the minimize, maximize and close buttons in the title bar, which are bright red.

They stick out like a sore thumb. I can't believe I wouldn't have noticed it before. Is it just me, or my computer? If the buttons have changed colour, why? My eye is constantly drawn to these bright red buttons. It is a real eyesore.

A PSK Core DLL mystery

The runaway success of the Elecraft KX3 has resulted in a sharp increase in the number of users of KComm. Even those who use a full-featured logging program in the shack find the simplicity of KComm and the compactness of its user interface (which was designed to fit a netbook) better suited to portable operating.

I received an email from a KComm user in Vienna, Wolfgang OE1MWW who wrote that he found the option to "Use PSK modem" (which uses AE4JY's PSK Core DLL to operate PSK31 using the sound card) was disabled on his laptop running Windows XP SP3 though it was enabled on his desktop running Windows 7 64-bit. Wolfgang eventually found that replacing the file PSKCore.dll that was installed by KComm with one dowloaded from AE4JY's website cured the problem.

I am surprised and a bit mystified as to why this occurred. My shack PC also runs Windows XP SP3 (I prefer to stay as far from the bleeding edge as possible) and it uses the same version of PSKCore.dll as is installed with KComm.

KComm's version is much smaller so I'm hazarding a guess (since I can no longer remember) that it may have been compressed using UPX, an executable file compressor. I used to have a bit of a mania for compressing executable files so I could claim how small they were compared to certain other ham radio bloatware, but in these days of 100GB hard drives it's probably rather fatuous. Possibly the compression caused an issue with some security software?

Whatever the reason, I'm grateful to Wolfgang for discovering a solution. I have added a note to KComm's Troubleshooting page and updated the installer package to include AE4JY's copy of the PSKCore.dll so hopefully new users will not encounter this problem.

Basic Android Programming

Up until I got an Android smartphone, there has not been a single programmable device that I've owned and not tried to write my own programs for it. However, programming for Android devices seemed to be fiendishly difficult, requiring a good knowledge of Java (which I haven't got) so I didn't attempt it. The other week I saw an article in a computer magazine that went through describing how to create programs using a tool called Basic4Android. It seemed similar enough to other development tools I have used such as Visual Basic, Delphi and Lazarus. So I thought I would download the trial version and have a play.

The Basic4Android development environment,

I soon discovered that the trial version is pretty limiting. It's enough to get a feel for the environment and the development process by creating "hello world" apps and suchlike, but in order to do anything interesting you need to use libraries and these are only accessible using the full paid-for version.

There are two full versions of Basic4Android you can buy: the Standard version which costs $49 and includes support and free upgrades for two months, and the Enterprise version which costs $99 and includes support and free upgrades for two years. As I'm not an Enterprise, only a dabbler (and a cheapskate one at that) I bought the Standard version. With hindsight that was not such a good idea, as I discovered after purchasing that only current paid-up users get access to the download links for additional libraries, even user-written ones, and access to the support forum. So after two months I'm on my own. A false economy, I think.

Sophisticated GPS apps can be developed

Basic4Android is a very powerful development tool and I don't think there is much you couldn't do with it if you're clever  enough. The language is object oriented like any modern Basic, and objects exist to let you access the internet, draw charts, access SQL databases and much more. You can access the Android device's GPS via a fully featured GPS library. There is even code to work with Google Maps. I have no intention of developing an Android version of APRSISCE (as if I could!) but Basic4Android looks powerful enough to make that possible.

So far I haven't learned much about Basic4Android programming that's worth sharing with people, but here are a few things I wish I had known prior to buying.

There is no need to pay the full prices I mentioned earlier. Once Google finds out you are interested in Basic4Android, ads to buy Basic4Android with 30% off will follow you around the web. To get the deal, click on one of them.

There are two options you can use to pay for Basic4Android, PayPal and Plimus. If you are in Europe then be sure to use the PayPal purchase buttons. If you use Plimus then you'll get stung for VAT which will bump up the price 20%.

Better still you can get Basic4Android Enterprise version with two years' updates and support at half price by using the coupon code dnxyif. Unfortunately this is only valid if you use the Plimus payment option so there is no avoiding VAT if you are in Europe. But even with VAT it's still the best deal I think. I hope that helps someone.

Snow on the roof

This morning we woke up to a covering of a couple of centimetres of snow. It's fairly wet snow: The temperature is just above freezing so it is already beginning to thaw. This is about as much snow as we usually get here, but the less time it hangs around the better. When it's cold the smow doesn't melt and eventually gets compacted into ice which, especially as we are on a hill, is a real nuisance.

I am often asked whether snow on the roof affects the performance of attic antennas. My answer is: Not so as I've noticed. The SWR of my attic antennas remains exactly the same (in fact it changes more on hot days when the attic temperature reaches 40 degrees plus, due to expansion.)

My magnetic loop on 30m did not need any re-tuning this morning and the first APRS packet sent was received by a German digipeater. My 2m APRS gateway is also functioning normally. I've put the K3 and multiband dipole on beacon monitoring duty and the beacons are coming through just as I would expect. In other words, all is normal.

Perhaps if there was a metre or more of snow I might notice a difference. But I think the amount of frozen water the RF has to pass through on the roof is negligible compared to the clouds it must traverse on its way to and from the ionosphere.

First WSPR spots on 630m

A few of my blogging colleagues have written about having surprising success WSPRing with modest antennas on the 474kHz VLF band. I thought I would try to see what if anything I could spot using my attic dipole as an antenna.

Receiving WSPR-15 on the 630m band

I downloaded the WSPR-X software which supports the new WSPR-15 mode. (The standard WSPR for HF and VHF is now called WSPR-2, the number indicating the duration in minutes of the transmit cycle.)

First problem was to find a receiver that would tune to 474kHz. My K3 would not tune below 490kHz nor the KX3. My K2 doesn't have general coverage at all. My SDR-4 receiver would not go anywhere near the frequency. My FT-817 came to the rescue. I took it out of the drawer, blew the dust off it, found a power lead, switched it on and it tuned to 474.2kHz quite nicely.

The next problem was to find a sound card to receive the audio. I have three USB sound devices currently connected to the shack PC and I could only identify which driver was for which sound card by trial and error. After I realized that WSPR-X can be used for HF WSPR as well I tried it out first on 30m. For about an hour I had confusion as I did not seem to be receiving any WSPR signals at all. Eventually I tried WSPR-X on the sound card used by my K3. Once I verified that the program worked and was decoding spots I then tried receiving 30m WSPR on the '817. Once that was successful I tuned the receiver to 474.20kHz, set the mode to WSPR-15 and left it for a few hours to see what would happen.

I was doubtful whether I would receive anything on my 80 - 6m multiband dipole which is too short and totally unmatched on the 630m band, but when I came up to the shack later this evening I saw there were three spots of PA0A in JO33 at 30 minute intervals! These spots were not reported to WSPRnet as I had been so pessimistic of my chances of decoding anything that I hadn't bothered to tick the "Upload spots" check box.

So the experiment was a success. I doubt that I will receive anyone else on this antenna so it is probably not worth leaving the radio set up for it but it was fun to see what can be received here on this new amateur band.

A good session on 15m

There was not much life on 10m this morning but 15m was really hopping. I started off using PSK31 and my first QSO was with a Ukrainian YL named Olga! Her call was US5UFF and her QSL shows that she is (X)YL of UR4UHE. I think the UFF stands for Ukrainian Flora and Fauna which seems to be a popular award scheme over in Ukraine.

I was calling CQ and worked a whole string of east European and Russian stations. Calling CQ is a good way to fill the log but not a good way to work much DX as if any DX did reply it would likely be lost under the strong local stations calling.

As the hour approached lunch time I did some search and pouncing and managed to nab HS4ESF from Mahasarakham University in Thailand. I don't think it's the first time I have worked Thailand on PSK but it was nice nonetheless, and he has a nice QSL.

I've often noticed from my beacon monitoring that the time around midday to lunch time is a good time to work DX on the higher HF bands. I didn't work any other DX today but I was pleased to see on Propagation Reporter that my 40W of PSK31 to an attic dipole had been decoded near Sydney in Australia! Perhaps I'll work VK on PSK31 one day!

PSK31 spots of G4ILO on 15m

I tried JT65A briefly but the band segment was full of the same stations I could easily work using PSK31 so I thought I would try CW instead. I "shook hands" (as John N8ZYA puts it) with Z320K, a special call to commemorate 20 years of the Z3 prefix (Macedonia.)  I then had a real QSO with Bill, WA1HMW who is an ex-Royal Navy. That QSO taxed my receiving abilities a bit so I decided to call it a day.

Another Doh! moment

I have found the solution to a problem that had been bugging me for ages: Omni-Rig did not work with JT65-HF. It was not a major bother for me as it could be worked around by the simple expedient of setting the frequency manually. But after an episode yesterday when I thought I was on 15m and was actually on 20m I decided to look at the issue again.

The solution turned out to be very simple and I stumbled across it by accident. You must start OmniRig before you start JT65-HF! That may seem obvious, but in fact other programs that use Omni-Rig manage to do so without it being run first. Which is why it never occurred to me to try that before. Doh!

Unfortunately the communication between the programs only works one way. JT65-HF can read the frequency from the rig using Omni-Rig but it can't set it. As I have the JT65-HF source I took a quick look to see if I could fix the problem, but it would not be easy. A major discouragement to tinker with the source code is the fact that the newly-compiled program breaks the link between HT65-HF and JT-Alert. So I am not going to venture down that road. When it comes down to it I'd rather have my alerts than have rig control.

Jamming on PSK

I was on 15m PSK31 and in the process of calling PY3ED when a vicious jamming signal started up.

Jamming on 21MHz

As you can see, it did a good job of obliterating all signals. It seemed to be centered around 21.070MHz and extended for 50kHz or so in either direction.

I don't know how long it stayed on for because it was lunch time so I went to have something to eat. When I came back the interfering signal had gone.

Was it something local to me or has anyone else seen it?

From attic to attic

Thanks to some excellent support from JT-Alert's author, Laurie VK3AMA, I now have my alerts fully working and have gone back to JT65A with renewed vigour. I was getting a bit frustrated as many DX stations that I could decode clearly were not returning my calls. Is there something wrong with my setup? Perhaps it was just because it was the weekend and busier than usual so that others whom I couldn't hear were replying to the same call and the DX couldn't decode any of us. A few times the station I called replied to someone else.

I still managed to work several DX stations on 10m and 15m using 30 watts of power. Best contact of the day was with KC2WUF who said that he was running 3 watts to an attic dipole. (Actually he sent "3W ATIC DP" but I got the message!) It's a pity I wasn't running QRP this end as it would have been good to have a 2-way QRP QSO attic to attic!

JT-Alert

I know conditions on 10m are going to be good when I turn on the Albrecht 10m handheld and can hear activity on its 6 inch antenna. Sure enough when I turned on the K3 the band was alive with wall-to-wall Russians at S9 plus.

I made some QSOs on SSB including one with Vadim UA1ZFG from the icy wastes of Murmansk. The nice thing about eQSLs is you don't have to wait long to receive them.

I also heard two stations from Thailand HS0ZEO and HS0ZJS, probably the first time I have heard that country on SSB, but I could not work them because of pileups. I curse the person who invented the DX Cluster as it has taken away the chance for weaker stations to work a DX just by luck tuning across them and turned it in to a contest where he who has the biggest power wins.

I switched to PSK31 where I made several more Russian contacts. Then I decided to try some JT65. My first JT65 contact of the day was with UA3TN whom I had worked before. I only found this out after logging the contact because my JT-Alert utility seems to have stopped working.

After lunch I continued with JT65 and found that all I could now hear was US stations. The first contact of the afternoon was with Tom K4AFR, then I made three other Stateside contacts all first time QSOs.

I downloaded and installed a new version of JT-Alert which is supposed to alert you when someone calls CQ or replies to your call. It also flags stations you have worked before, which I find very handy as I have a poor memory. But this feature is not working. It's probably some stupid setting I've got wrong, but I'm darned if I can see it.

A nice new facility in the new version of JT-Alert is the ability to log contacts to a third party database such as MixW. This just happens to be the log format KComm uses. It's very handy, avoiding the need to import contacts from an ADIF file one at a time, so it is worth running JT-Alert for that reason alone. But I really wish I could get those alerts working!

An interesting discovery about sound cards

CheckSR result at 48kHz with internal sound card

I have several radios connected to my shack PC. For the audio interfacing I have several sound cards or sound devices since most of them are not internal cards but use USB ports. I wanted to make sure the rig I mostly use for digimodes used the best sound card I had so I thought I would do some tests.

Some people believe it's better to use a high end sound card for radio work. I don't think there is any benefit for HF use as the noise level will be much higher than even the poorest sound card. There is no advantage to using a device capable of more than 48kHz sample rate unless you are using SDR software and need the extra bandwidth.

The one factor that can really made a difference is the accuracy of the sample rate. Most digimode software uses either 11025Hz or 48000Hz. There is no theoretical advantage to using a faster than 11025Hz rate for terrestrial digimodes. A 48kHz sample rate should not give any benefit and will need more CPU cycles to transfer and process the extra samples.

Sample rate accuracy is important because it affects both the pitch of playback and the data rate. It's like playing an LP at the wrong speed. If you play a 33rpm LP at 45rpm the music is played at a higher pitch and a faster tempo. If played at a lower speed the sound is lower pitched and slower. This is analogous to what happens if the sample rate of your sound card is not exactly what your digimode software expects it to be.

I tested a number of sound devices using CheckSR.exe. This is a utility that is distributed with the MixW digimode software, but you can probably find it on its own if you Google it. To use it you simply select sound devices for input and output and set the sample rate you wish to test. You then run it until the measured sample rate settles on a stable figure.

I tested the Realtek sound cards built into my shack PC (HP) and a laptop (Dell) using both 11025Hz and 48000Hz sample rates. Both sound cards were as close to the specified sample rate as makes no difference.

CheckSR result at 11025Hz with USB device

I then tested a number of USB devices ranging from a $1 audio 'dongle' to a $10 model with surround sound and SP-DIF inputs and outputs. The drivers for these devices had names like 'USB sound device', 'Generic USB sound device' and  'USB headphone set'. These devices were also close to spot-on at 48000Hz.

But at 11025Hz every single USB device had a measured sample rate of 11100Hz - 1% faster than specified. This would make a 1kHz audio tone play at 1010Hz, whilst a 1200baud APRS packet would be transmitted at a rate of 1212baud. This error is more than enough to prevent decoding of an FSK packet signal. Other digimodes are also subject to sample rate errors. If you have ever seen a PSK or Olivia  signal that is strong and clear yet decodes as garbage, an incorrect sample rate (at one end or the other) is the reason.

I was surprised that the sample rate error at 11025Hz was consistent across all USB device samples. This suggests to me that the measured rate of 11100Hz is a factor of the drivers for these devices which may not run at the speed you select but instead resample down from a native speed of 48kHz. It would be interesting to see the results of running CheckSR on some branded USB devices or SignaLink USB interfaces that have their own drivers.

I ran some tests on USB devices at other sample rates. There was no consistency. At 8000Hz the measured rate was fast by a significant amount, but 16000Hz it was slower.

The results suggest that USB audio devices are only as good as internal sound cards if a 48000Hz sample rate is used. The use of lower sample rates with USB devices should be avoided.

A virtual impossibility

If you have been following my attempts to set up beacon monitoring using a software defined radio (SDR) then you may remember that I had found that Omni-Rig, the radio control software used by Faros, the beacon monitoring software, would not talk to the virtual serial port created using VSPE in order to control the SDR-Radio software. I thought there was a problem with SDR-Radio's emulation of the Kenwood control protocol. In fact, that turned out not to be the case at all.

A reader asked if I had tried DDUtil, a.k.a. VSP_Manager, a program by K5FR so I got hold of a copy. The instructions made my hair stand on end as it seemed very complicated. But I managed to set up a virtual port pair between COM8, the control port that SDR-Radio was using, and COM9 which would be used by Faros. VSP_Manager threw up a few error boxes but it still seemed to have done what I asked. I then tried setting up Omni-Rig. The first attempt failed, but I decided to try again as the help files actually showed VSP Manager being used with Omni-Rig and sure enough I had Faros changing bands and frequencies of SDR-Radio.

My joy was boundless, but not for long. I fell at the next hurdle which was using a Virtual Audio Cable (VAC) to pipe the audio from SDR-Radio into Faros. VAC also looked complicated to set up, but what I was attempting to do was the simplest application of it. I created a virtual audio port and set the SDR-Radio output to use it. As soon as I connected this to Faros' input Faros began spitting out "divide by zero" message boxes so fast that I couldn't close them quick enough to get back to the Settings window to change it back again. Another brick wall.

A separate issue was that of creating a serial port splitter to allow two applications to connect to physical port COM3 used by my Elecraft K3. VSPE could do that easily, but yesterday I discovered that WSPR would not talk to the virtual port created by VSPE. However, VSP_Manager does not seem to enable you to split a real port into a pair of virtual ones anyway, so I did not pursue this avenue any further.

If you are confused trying to follow all this you are not the only one! I have abandoned the idea of using an SDR for beacon monitoring and am breathing a sigh of relief that I never decided to go down the road of buying a Flex or other software defined transceiver. SDR will never catch on until connecting the software defined radio to logging programs or digimode software becomes as simple as plugging in a real cable.

Hamlib and virtual serial ports

Sometimes it seems as if half the posts in this blog relate to trouble with computers.

After I got back from the hospital today I thought I would try some WSPR for a change. Paul PC4T had mentioned that conditions on 80m were good. 80 is not a band I often use so I thought I'd try there. But no sooner than I had tried to change band than the software beeped rudely at me. The console window contained an error message: serial_open: Unable to open COM13 - Invalid argument.

COM13 is a virtual serial port splitter on COM3 which I'd created using Eterlogic's Virtual Serial Port Emulator, VSPE. I've used this utility for years to create virtual serial ports so that more than one program can open my radios' computer control ports at the same time. I'd used one to try out CW Skimmer with KComm before Christmas. As I'd uninstalled Skimmer I removed the virtual serial port. WSPR, which does its rig control through hamlib, then opened COM3 up just fine.

That's a temporary solution, but I haven't given up the idea of running other ham software alongside KComm for good. I think there are other serial port splitters out there (there's com0com which was far too complicated for me to figure out) but VSPE has always worked for me until now. Don't you just love computers?

SDR-Radio and Omni-Rig

Yesterday I thought I would set up my Cross Country Wireless SDR-4+ receiver to use for IBP beacon monitoring using Faros. The purpose of this was mainly to reduce the wear and tear on my Elecraft K3 which otherise would have to be on 24 hours a day.

I established that Simon Brown's SDR-Radio software supported external program control by emulating a Kenwood transceiver. I therefore needed to see if SDR-Radio could be controlled using Omni-Rig, the control mechanism used by Faros.

SDR-Radio supports CAT control using a virtual serial port.

I created a linked pair of virtual serial ports, COM8 and COM9, using VSPE, a virtual serial port emulator. Using the serial ports option of SDR-Radio, I assigned the control port to COM8. Then I used a serial port emulator connected to COM9 (I use RealTerm) to verify that SDR-Radio 'spoke' Kenwood. It did. In fact it emulated the Kenwood protocol well enough to fool KComm into thinking it was talking to an Elecraft K2. So far so good.

Now to see if Omni-Rig could control SDR-Radio. Omni-Rig uses "rig files" to define the command set of different radios and it includes one for generic Kenwood. Unfortunately it did not work with SDR-Radio: the receiver indicator of Faros turned red to indicate a fault.

I downloaded the rig file documentation and debug tools from Omni-Rig's site and tried hacking the Kenwood rig file to get it to work with Omni-Rig by trial and error. But no luck. Whatever I did, the program reported an error with the inscrutable message: "RIG1 Status commands already in queue".

Error messages reported by Omni-Rig

So it looks as if I've hit a brick wall. Clearly there is something in SDR-Radio's emulation of the Kenwood protocol that Omni-Rig doesn't like. If anyone else would like to have a go solving this problem, be my guest.

Tecsun PL-360

Tecsun PL-360

The only item of radio equipment in my Christmas stocking this year was a Tecsun PL-360 FM/MW/SW DSP receiver. These smartly-styled radios in black or silver are widely available on eBay for less than £30 including postage from China. The radio looks and feels a much better quality item than you might expect at that price.

The PL-360 covers medium wave, Band 2 FM (with stereo decoder) and 13 short wave bands from 2300 to 21950 kHz. Unlike most cheap short wave radios that have a frequency counter displaying the frequency of an analogue VFO, the Tecsun PL-360 is a true digital radio having a fully synthesized PLL VFO.

The Tecsun is also a digital radio in that it is DSP based not the usual superhet. The benefits are immediately apparent when you listen to the radio - it has that clear, open sound characteristic of DSP receivers. The internal speaker does not deliver much bass but you really hear the difference, especially listening to FM stereo, when using earphones, of which a Walkman-style pair are included.

For AM use Tecsun supplies a rotatable ferrite rod antenna that plugs in to the top of the radio. This can be used over a frequency range of 150 to 1710 kHZ, though note well that this radio does not have a long wave band. The 7-section telescopic whip antenna is 38cm (15in) long and is used on the short wave and FM bands.

Showing the rotatable MW antenna

The tuning control is a click-stopped rotary encoder which tunes the radio in 1 kHz steps on short wave and 9 or 10 kHz steps on medium wave. The radio can be tuned outside the broadcast bands but this is rather a tedious exercise due to the 1 kHz steps - there is no provision for direct frequency entry using a keypad. The  Tecsun PL-360 does not demodulate CW or SSB so there is not much point in tuning into the amateur HF bands - a pity, though that is not unexpected at this price level.

For tuning the Tecsun has a neat trick inherited from TV receivers. Called Easy Tuning Mode (ETM) the radio first tunes the entire MW, SW or FM frequency range and stores all the frequencies on which a signal was heard in memory. You can then tune from one signal to the next using the click-stopped tuning control. This makes short wave listening really easy and pleasurable. Doing an ETM scan of the short wave bands takes a few minutes. The feature is a useful tool for checking out HF propagation, though it's a pity the tuning range stops at 22 MHz.

Power is provided by 3 x AA cells which may be standard alkaline or NiMH rechargeable (not supplied.). A charging circuit is built-in and power may be applied using a mini-USB socket on the side, so you can charge the batteries from a PC (using an appropriate USB cable) or a mobile phone charger. A charger is not included, but you do get a long wire antenna that clips on to the top of the telescopic whip for improved short wave reception, and a nice faux-leather case.

As an alternative to the Easy Tuning Mode the receiver may be tuned manually and frequencies entered into memories, but as mentioned earlier this is quite tedious. There is no programming software that would enable memories to be set up using a computer. There is a built-in clock which is quite accurate and includes an alarm function. The radio also has a temperature sensor and displays both temperature and time even when switched off.

To sum up, the Tecsun PL-360 is a portable radio of surprisingly good quality and performance for the money. Its Easy Tuning Mode makes casual listening a pleasure, the audio quality is excellent and the provision for rechargeable batteries is welcome. At less than £30 it is a real bargain.