A while back I wrote a post called “Why FCC tested transceivers should matter to Ham Radio operators.” As part of this post, I drew attention to testing performed by the ARRL on used ham radio transceivers. One of the highlights of this article was that the Baofeng HTs performed exceptionally poorly due to a high level of spurious emissions.
However, I recently stumbled onto an article on PD0AC’s Ham Radio blog called “Baofeng UV-5R Spectrum Analysis Revisited,” in which Hans (the author) looked into comments about the UV-5R’s suspected spurious emissions. I quote:
“But wait, we did this(link) already … and the UV-5R wasn’t too bad at all. All of his bothered me enough to pick up a few of my own UV-5R’s and repeat the measurements… The only way I could replicate his [failing] results was by reducing external attenuation to such a low level that the linearity of the spectrum analyzer was compromised”
In his initial testing, Hans and Tom (PA2TSL) used a 30 dB attenuator for the spectrum testing.
So I went back to the original QST article (November 2015, page 74) and re-read it. It’s important to note that the following quote appears under the test results table on page 75:
“Specific makes and models in which the majority of the units tested were noncompliant: Baofeng, UV5R, UV5R+…”
I found the following description of their test equipment and setup:
“Our convention tests measured … using a test fixture consisting of a Bird Model 43 RF Power Meter, a Bird Model 8322 30 dB power attenuator, a Hewlett-Packard HP355C 0 to 12 dB step attenuator, and a Rigol DSA-815TG spectrum analyzer. … First, the power output … was measured using the Bird Model 43 meter. … Next, with the radio push-to-talk (PTT) button pressed and held, the Rigol DSA-815TG spectrum analyzer was used to perform a sweep…”
So, I went to the FCC’s testing setup. They’re the ones who initially gave the UV-5R a pass, so let’s see what they used to do it. Starting on page 37 of the FCC’s published test results, you can read for yourself the detailed setup and testing of the transceiver, including the directly-connected spectrum analyzer test. Note that they specifically show that the signal from the radio passes through an attenuator (if I’m reading the report correctly, the attenuation is 13 dB).
On page 76, of the QST article, Figure 3 shows a borderline result of a tested UV-5R. The attenuation displayed on the display of this figure shows an attenuation of 10 dB, below either of the previous two test setups.
Let me say that I appreciate what the ARRL does, and I don’t believe for a minute that they are unfamiliar with their equipment, but testing at the informal environment of a convention could lead to simple mistakes in the test setup. I would have really liked to see a clear spelling out of what level of attenuation, if any, was between the equipment and the spectrum analyzer. It’s also important to note that the ARRL clearly mentions in their article that this testing was performed on used equipment, not newly-manufactured units specifically submitted for testing. In light of the two previous articles I mentioned above, and the lack of clearly-mentioned attenuation between the radio and spectrum analyzer, I have to say that, in my opinion, the ARRL’s testing is inconclusive.
Your comments are welcome below. Thank you for reading.
If you have purchased a cheap programming cable for your radio from Amazon, eBay, or another dealer, you’ve probably run into an issue where the cable initially won’t work, and someone (perhaps the vendor) told you that you have to use an older driver to get it to work. What you have is a cable that uses a counterfeit chipset. The Prolific chips seem to be the most problematic, while FTDI chipsets work very well. This page on miklor.com offers some background information on this subject.
The Miklor Cables & Drivers page talks about this and offers the older Prolific drivers that work well with cables that feature those counterfeit Prolific chipsets. You will run into one of two problems while dealing with them, however.
Under Windows 8 and previous Windows versions, Windows will offer the newer, non-working driver through Windows update. It is sufficient to go in and block the update, as described here, but you may have to do that each time you plug the cable in to a different USB port.
Under Windows 10, it’s a whole different situation. Windows 10 will install all updates offered through Windows Update, and you have the option to defer upgrades, but not to block individual updates. Windows 10 will continue to install the updated driver, which will continue to cause your counterfeit chipset cable to stop functioning.
So, if you’re using the counterfeit chipset cable under Windows 10, do yourself a favor and get a genuine programming cable. You’ll save yourself a lot of headaches and frustration.
A good source for programming software and cables is RT Systems, as they offer both cables and software for radios they support. If you’re only interested in the cable, and you want to use it with the factory software or the open-source software Chirp, look for cables that mention using genuine FTDI chipsets. They aren’t hard to find, but they will cost a little more. For the Baofeng 2-pin models, this cable from Amazon works well. This cable should work for all Baofeng 2-pin cable compatible radios, such as the UV-5R (and variants), the BF-F8+ (and variants), UV-B5 and UB-B6, and UV-82 (and variants). This should also work for all 2-pin cable compatible radios from other manufacturers, as long as they use the same pin out.
You could also try replacing the chipset with a $3 adapter, as described here. A good eBay seller for that adapter is here. Many other people report success. but I tried it with a counterfeit cable for my Baofeng and couldn’t get it to work.
Questions and comments are welcome below.
A problem exists when trying to access AllStar’s Web Transceiver under Linux where no sound is played.
This is due to issues with Java under Linux.
A workaround is documented here.
I tested Ubuntu 14.04 LTS in VMware. I started with a clean install. I made sure sound was working in the VM, then updated everything using this command:
sudo apt-get update && sudo apt-get upgrade
I then checked Software Updater and found a few more packages that didn’t get updated, and updated them.
I then made a backup of the VM to have a good baseline. I then installed OpenJDK 7 and the icedtea-7-plugin, using the following command:
sudo apt-get install openjdk-7-jre icedtea-7-plugin
I did not have openjdk-6, icedtea 6, or Oracle Java installed. If you do have any of those installed, try removing them to prevent any conflicts.
You can test your Java sound output any trying any Java applet that produces sound, such as this SoundApplet demo. If you don’t hear sound from it, you have an issue. If you have more than 1 sound device, check the other sound device for the sound output. In my case I only had 1 device (through virtualization), but it worked fine.
I also tried AllStar and was able to hear audio from the node announcements just fine, albeit with occasional crackle, perhaps due to the limited resources of the VM. I tried transmitting but did not get a reply from the few nodes I tried.
If you have something to add, please feel free to comment below.
One of the uses I found for my Raspberry Pi was using it to display weather data. I retrieved the weather data from Weather Underground using their API, parsed it, and displayed it on my RPi’s small LCD. This gave me an always-on view of the weather, which was nifty, and it was done all in bash scripting with a few external programs to parse the data.
This script is very customizable and extensible. You could use it to do any number of weather-related tasks.
I reduced the font size on the LCD to Terminus 6×12 using the following command:
sudo dpkg-reconfigure console-setup
This helped make room for all the forecast data on the tiny LCD. If you are running this on a PC, it’s not necessary.
For the smoothest updates, I have found it ideal to run the script under ‘watch’, as so:
I tired doing a ‘while true; do… clear… done’ loop, but the refresh rate was too low and the updates were not smooth.
Here is the script:
UPDATE : This has moved to github, here.
Last updated: 11-21-2015
If you want your Raspberry Pi to share its files and folders over the network, you want to install and configure Samba.
Start off by installing the basic Samba requirements:
sudo apt-get install samba samba-common-bin
Edit the samba config file
sudo nano /etc/samba/smb.conf
edit the workgroup= line to match your network. workgroup=WORKGROUP is the default and usually fine. It needs to match what your Windows PCs are set to.
[pi] path=/home/pi browseable=Yes writeable=Yes only guest=no create mask=0777 directory mask=0777 public=no
Add the pi user to samba. Use the same password for the pi user:
sudo smbpasswd -a pi
It takes about 2 minutes for the changes to take effect, but after this you should have no problem exploring files over the network. Note that some may be owned by root and you may have an issue writing to them.
If you have trouble logging in under Windows (password errors), try using “raspberrypi\pi” (raspberrypi-backslash-pi) as your username (without the quotes)
sudo nano /boot/cmdline.txt
add the following to the end of the line:
I picked this inexpensive LCD up at MicroCenter for my Raspberry Pi, but getting it to work was a bit of a chore.
I wanted to install it onto a Raspberry Pi 2 which is already set up and running some software of mine. Therefore, I wanted to install it in as few steps as possible. Fortunately, WaveShare provides some drivers (but they don’t clearly document the setup process).
Here’s now to set it up:
Do the normal update/upgrade procedure:
sudo apt-get update && sudo apt-get upgrade
Download the correct “LCD-show-*” driver for your version of Raspbian Jessie from the Drivers section of the product page on WaveShare, and transfer it to your Pi, or use the following example commands from your Pi to download it directly:
wget http://www.waveshare.com/w/upload/9/9d/LCD-show-151020.tar.gz tar xvzf LCD-show-151020.tar.gz cd LCD-show/
and run this command to set up the 3.2″ screen. :
Note: You may need to have the SPI interface already turned up via raspi-config before this will work.
Important note: The LCD32-show and LCD-hdmi scripts will overwrite several system files. If you have customized them, or have concerns, you are strongly advised to read through the scripts before running, and consider merging the changes in manually. Here is the list of touched files:
After a few seconds, you Pi will reboot, and the screen should be active. You can refer back to the WaveShare page to see documentation on how to switch to HDMI and back to the LCD.
Follow these steps to download and install xinput_calibrator to calibrate the touchscreen. I noticed that on my panel, the touchscreen does not respond well to input; I suspect I have a defective panel.
sudo apt-get install libx11-dev libxext-dev libxi-dev x11proto-input-dev wget http://github.com/downloads/tias/xinput_calibrator/xinput_calibrator-0.7.5.tar.gz ./configure make sudo make install
Now, following the directions from WaveShare, you can run this command to calibrate the touchscreen:
Refer to WaveShare’s page on how to edit 99-calibration.conf to save the calibration data so it persists over reboots.
Comments are welcome.
I wanted to put up my roll-up J-pole indoors temporarily, and I didn’t want to drill holes to do it. (Also, I was feeling lazy).
I used a plastic hangar, zip ties, and cable mounts to put it up. It took less than 5 minutes and it works quite well.
This approach could be used for any temporary installation of a light antenna that could be hung, such as a roll-up j-pole, horizontal dipole, or anything of the sort.
The Raspberry Pi has two LEDs on the front: One hardwired as a power indicator, and the other is (by default) an SD card activity indicator. This second LED can be changed via software to anything (even a GPIO), but for this, I’m going to show you how to set it as a heartbeat indicator.
sudo su modprobe ledtrig_heartbeat echo heartbeat > /sys/class/leds/led0/trigger
The Pi’s led should now start blinking as a heartbeat indicator. If you want to restore the default behavior, you can do so:
echo mmc0 > /sys/class/leds/led0/trigger
That’s all there is to it.