Advertisements

MB

This user hasn't shared any biographical information

First steps with the Raspberry Pi or Pi 2

After getting a Raspberry Pi (or Pi 2), here are the first steps you should take:

login with username pi, password raspberry.

Configure the Pi:

sudo raspi-config
  • Advanced options
    • A0 Update this tool
  • Expand filesystem
  • Change user password
  • Internationalization options:
    • Change locale: Add your locale (Removing the default en_GB.UTF-8 caused display issues on mine, so just add your locale.)
    • Change Timezone

Next, update the Pi:

sudo apt-get update
sudo apt-get upgrade

Last, update the firmware:

sudo rpi-update
Advertisements

Leave a comment

DireWolf holds PTT when using KF5INZ Easy-Digi interface

I found that when using KF5INZ Easy-Digi board and DireWolf v1.2 for APRS, you will need to specify both DTR and RTS control in the DireWolf configuration file, or DireWolf will hold PTT down. All other programs seem to work normally. Example configuration line for DireWolf:

PTT COM4 DTR RTS

, , ,

Leave a comment

Using KF5INZ’s Easy-Digi with Baofeng UV-B5 or UV-B6 for PTT control

I wanted to interface my Baofeng UV-B6 using a K5INZ “Easy Digi” board from eBay for PTT control.

The K5INZ “Easy Digi” boards are very inexpensive interface boards, which are available on eBay. You can find them by searching here. The Baofeng UV-B5 and UV-B6 feature a Kenwood-style 2-pin 3.5mm and 2.5mm connector on the side of the radio. Although the radio supports PTT keying, you have to take care to wire it correctly.

I found the pinout on the Miklor site confusing. After a quick search, I found this better image of the pinout:

Source: http://ham.stackexchange.com/questions/1891/whats-the-pinout-for-kenwood-2-5mm-trs-3-5-mm-trs-connector

Going off this, you can see that the 3.5mm shield is the PTT, which gets pulled to ground to enable. You can also see that the grounds are on the 2.5mm side (ring and shield) and are for the speaker, mic, and PTT.

This should work for all Baofeng 2-pin cable compatible radios, such as the UV-5R (and variants), the BF-F8+ (and variants), 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.

Special Note for UV-82 series: The UV-82 series supports dual-PTT keying. As such, the pinout is slightly different. The rest of this article will give you a working setup, but will key PTT for the bottom display only. The top display is keyed using the tip of the 3.5mm jack instead of the shield. See this page on miklor.com for more details. 

I used a USB A-to-B cable and cut off the ends. This left me with 4 conductors, of which I only needed three. I wired the RTS, DTR, and digital ground to a DB-9 female connector, with a little bit of electrical tape to keep the cable shield from causing any problems.

Pinout source: http://www.db9-pinout.com/

Then wire the connections to and from PC audio in the usual manner. On the Easy Digi the polarity is not marked, but if you follow the wiring diagrams included, you will see the two negatives are in the center, and the positives are on the outside. I marked them myself with a silver marker to help during assembly. For this I used two 3.5mm stereo cables, and wired tip (+), shield (-), and left the ring disconnected.

Next I took a 3.5mm stereo cable and connected the ring to mic in, the shield to PTT high, and left the tip disconnected. (UV-82 series owners only, this is where you want to connect the tip instead of the shield if you want top display PTT instead of bottom display PTT)

Next, I took an Arduino jumper and cut it in half. Put one pin in mic ground, one pin in PTT ground, and twist the free ends together. Tin the twisted end, and solder and snip the excess pin leads. You could use any suitable wire for this jumper. It should end up as shown here:

Next, solder on the audio in using the tip (+) and shield (-). The radio side of this cable needs to go down to 2.5mm, and can be mono or stereo, but if it’s stereo, be sure to leave the ring disconnected. You can use a 2.5mm to 3.5mm adapter, such as this one from Monoprice, but either wire your own plug or test the adapter before use.

Take the jumper lead you made previously and wrap it around and solder it to audio ground. If you’re using the Easy Digi case, don’t go around the long side of the board (as I did in this photo), go around the short side of the board. You won’t be able to fit the board back in the case if you go around the long side. you could have also made the connections from the bottom side of the board if you so desired.

You should have your board fully assembled now.

You can now control PTT with either DTR or RTS control over your serial port, and it works fine with USB-to-Serial adapters.

This works great for an EchoLink simplex repeater, or for APRS digipeating use.

Audio leveling: I found this to work best when the Baofeng volume is set between the 9 o’clock to the 10 o’clock position, and the PC mic input is set to 20 with +20db boost. I found that the PC volume level may have to be set anywhere between 20 and 50, depending on the particular PC and software. You will likely have to adjust to your own environment.

NOTE: If using this with DireWolf v1.2 for APRS, you will need to specify both DTR and RTS control in the DireWolf configuration file, or DireWolf will hold PTT down. All other programs seem to work normally. Example configuration line for DireWolf:

PTT COM4 DTR RTS

Comments are welcome.

, , , , , , , , , , ,

Leave a comment

Mobile radio installation tips

If you’re planning to operate your ham radio from a mobile installation, it’s important to understand that your vehicle is packed full of sensitive electronics, and some of them, like the ECM and TCM, are vital to your cars operations. The very last thing you want to do is pay for an expensive repair because you got RF into the vehicles electronics and killed something important, or made a sloppy wiring mistake. So, with that in mind, how do you proceed?

Here are a few points:

  1. If you have a mobile radio, the owners manual will almost certainly recommend connecting it directly to the battery. This is essential to maintain a safe supply of power. Make sure that the leads are of proper gauge wire, and fused at both the positive and negative leads, as close to the battery as possible, using fuses properly rated for your load. It’s been recommended that instead of connecting the negative lead directly to the battery, to instead connect it to where the ground cable from the battery meets the chassis.
  2. Do not use a fuse tap or add your radio to any existing fused circuit. You will overload the circuit.
  3. Do not use a cigarette lighter adapter if you will exceed half of the outlet’s rated value, or the outlet’s rated value is unknown. You can overheat the wiring and overload the circuit. (Remember: DC watts is roughly double your RF watt output.)
  4. Attach the radio’s mounting bracket to a location that has a good chassis ground. Use an ohmmeter to test. If you cannot ground the bracket, then run a grounding strap from your mounting location to the nearest chassis ground point. Avoid Velcro mounting if at all possible. It will not stay attached in the case of a severe accident. Reference your vehicle’s manual to ensure that no components such as microphones or head units are in the airbag deployment area.
  5. Attach any accessories, such as duplexers or amplifiers, securely. Consider putting all your radio equipment in your trunk and only having the headunit and microphone in your passenger area. Although this involves running more wire, you’ll have plenty of room to secure your components.
  6. Avoid magnetic mounts on any frequency lower than the 2-meter band. Use an antenna mounting method that provides a good ground, such as a trunk-lip or through-hole. Ensure that whatever mounting method you use supports your antenna well, and check it periodically. Use thread-lock compound on any adjustment screws but NOT on screws that provide a ground, as it will interfere with the ground. If using a trunk mount, check for an included metal plate (stability plate) and ensure that two screws bite into the metal plate (use thread-lock on these) and two cut through to the metal in your trunk lid (do not use thread-lock on these).
  7. Mount the antenna as high as practically possible, keeping metal under the antenna instead of up against it. Mounting on roofs and trunk lips will work, but not so well on bumpers or against a metal truck bed cover.
  8. Remember the legal limit in the US is 13’6″ high, and parking garages and drive-through burger joints are often much lower than that (around 10′). If you are going to exceed 9’6″ from the street to the tip of your antenna, be alert when driving and parking, and be sure your antenna is removable without too much hassle.
  9. Check your SWR after installation. If you are having a difficult time getting a good SWR reading, check the location of your antenna and the ground connection. If you’re having trouble getting a good SWR on 6-meters or below, check to see if your trunk lip (or other body part) has a good ground path to the rest of the vehicle chassis metal. Run flat ground strap as appropriate. The lower the band, the more continuous ground you need. Remember, your ground is your counterpoise.
  10. Remember the elements, and weatherproof and seal connections as necessary. If you’re using a trunk lip mount, or you’re going through any vehicle weather seal, consider a mount that uses a very thin type of coax (such as RG174) to keep the displacement of weather seals to a minimum. The inside of your vehicle will thank you.
  11. Don’t operate using more than 100 watts. I’ve heard stories about people operating a kilowatt from their vehicles. Once you consider RF exposure limits, there’s no justification for this. Save it for the base station where you can get your antenna further than 10 feet from your body.
  12. NMO is the only connector that I am aware of that is waterproof when removed. While “UHF” (PL259/SO239) is a popular connector, and performs well, be aware to avoid moisture leaking into the connector when installing or removing your antenna, and keep a rain cap on the connector when you don’t have an antenna installed. It’s a good idea to seal your connections using coax tape or similar to avoid moisture contamination, even when your antenna is installed.

Remember your physical safety as well as the electrical safety in your vehicle are of the utmost importance. It’s difficult to operate from a hospital bed, and your car insurance won’t cover a vehicle fire from sloppy wiring. Ruining a vehicle over a few hundred bucks of radio equipment is just not worth it.

Leave a comment

Running EchoLink on Windows as a standalone program

EchoLink is a VOIP program that allows licensed Amateur Radio operators to talk to other operators using the Internet as a link. Unfortunately, the current version on their website (version 2.0.908) uses an InstallShield installer that causes some serious harm to Windows installations when it is uninstalled — namely, it will remove the tiles from your Start screen and All Apps screen, as seen here.

It’s important to understand that this isn’t a flaw in the EchoLink operating software itself. Rather, it’s an issue with the version of the InstallShield installer that they are using to install the software, and that this only happens when you try to uninstall the software. Installing and running the EchoLink software poses no risk to your system until you try to uninstall it. The uninstaller does some (as yet unknown) mistake in removing the program which will cause the loss of your start screen after rebooting. See this post for how to fix the issue using System Restore. 

Up until I started digging into this issue I didn’t recommend for anyone to use the software, as the consequences of trying to uninstall the software leave your system in an almost unusable state. I can now confidently encourage people to use it, but only if you run it as a standalone program — not when installing it using the bundled installer.

Now, I’m going to show you a way to run the EchoLink program without using the InstallShield installer, which makes it perfectly safe to use, and there’s no need to run an installer or uninstaller.

First, obtain the EchoLink installer exe from the EchoLink website. It will be named EchoLinkSetup_2_0_908.exe.

Next, based on a tip from this site, open a command prompt, change to the directory containing the EchoLink installer, and run the following:

EchoLinkSetup_2_0_908.exe /s /x /b"." /v"/qn"

This should create an EchoLink.msi file in the same directory.

Now, download and install 7-Zip using the default options. With 7-Zip installed, you can right-click on the MSI and click 7-Zip -> Extract to “EchoLink”. This will create an EchoLink folder which contains the extracted files. The files you’re most interested in are the EXE and CHM files.

You can run the extracted EchoLink.exe file directly, and from anywhere, and the CHM file contains the help documents, and they should be kept in the same folder. I don’t know if the elkbhook.dll is needed at all. I was able to use EchoLink normally and carry on a QSO without it.

I have already brought this issue to the attention of the EchoLink.org team, and they confirmed at the time that it was an issue with the InstallShield installer. This is what brought me to look at working around InstallShield. However, I haven’t seen an updated release from EchoLink.org to address the issue.

Thank you for reading, and please share this post with any Amateur Radio operators you know that run the EchoLink software.

Leave a comment

Manually uninstalling EchoLink from Windows 8

If you are running Windows 8, and installed the Echolink software using it’s incompatible installer, and then subsequently uninstall it, you will break your start screen (as shown here). You will then have to do a System Restore to get your start screen restored, but that will re-install the software.

If you manually uninstall Echolink using the method below, you can then extract and run Echolink using the method described in my other post on EchoLink.

Here’s the steps to remove all traces of the Echolink software from your PC:

  1. You might want to create a system restore point from Control Panel > System > System Protection > Create... before proceeding, just in case.
  2. Delete the desktop icon.
  3. Done! (Just kidding)
  4. Right-click on the Start screen icon and select “Unpin from Start” (NOT uninstall. Seriously.)
  5. Run regedit.exe (Caution: Editing the registry is risky. Pay close attention and make a backup before making any changes if you aren’t confident in your changes.)
  6. (Optional) Delete the registry branch at [HKEY_CURRENT_USERSoftwareK1RFD]. — It looks like Echolink stores some settings here and it is safe to leave this key in place if you plan to run it standalone.
  7. For a 32-bit system, I found the uninstall keys in the registry at [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall{DC33421C-0E1C-470A-BE37-7B7C82677812}]. Delete that branch of keys. Verify Echolink is no longer listed in Control Panel > Programs and Features for uninstallation.
  8. For a 32-bit system, delete the C:Program FilesK1RFD directory.
  9. For a 64-bit system, look under
    [HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftWindowsCurrentVersionUninstall]. Find the branch of keys under there that refers to Echolink and delete it. DON’T delete the entire Uninstall branch. (I didn’t run this on a 64-bit system, so I can’t give you the exact registry branch.) Verify Echolink is no longer listed in Control Panel > Programs and Features for uninstallation.
  10. For a 64-bit system, delete the C:Program Files (x86)K1RFD directory.
  11. (Optional) If you wish to delete your favorites, recorded QSOs, etc., delete C:Users<username>DocumentsEcholink. This directory is hard-coded into Echolink, so even if you run it standalone, it will still store data in this folder.

Please feel free to share your comments below. Thanks!

Leave a comment

Why FCC tested transceivers should matter to Ham radio operators

I have been engaged in conversation with several other hams in regard to Chinese imported transceivers such as Baofengs and Wouxuns. These radios are very inexpensive (usually less than $50 a piece) and readily available from US suppliers via Amazon and eBay. They frequently do not come with an FCC label on them.

The question is, does it matter?

Some hams are of the belief that FCC certification doesn’t matter because they’re used in Amateur Radio, which operates under Part 97 of the rules and does not require certification.

Other hams are of the belief that the transceiver requires at least Part 15 certification since it will receive outside of the amateur band.

So which is correct? Technically, the latter belief is correct. Part 15 certification is required because the device will receive outside of the amateur band. But more importantly, a large part of the Chinese imports do not even meet the emissions standards of FCC Part 97. We should care about Part 15 certification because FCC testing proves the emission standards of the radio, such as harmonics and splatter, and poor emissions can cause harmful interference in other radio bands.

In the November 2015 issue of QST, the ARRL published results of testing Amateur-owned handheld transceivers at various conventions from 2012-2015. This testing was done on attendees’ used radios which were brought to the conventions. Each transceiver was hooked to a calibrated set of test equipment and was tested for emission standards compliance.

While I can’t provide the actual article due to copyrights, I will sum up the findings here. For all brands listed in the article over the entire test period, I’ve provided the total number of radios and the average percent of compliant radios across all years.

  • Baofeng: 186 tested. 29% compliant.
  • Connect Systems: 13 tested, 100% compliant.
  • Icom: 151 tested, 100% compliant.
  • Kenwood: 129 tested, 99.5% compliant.
  • Motorola: 11 tested, 100% compliant
  • RadioShack: 11 tested, 100% compliant.
  • TYT: 6 tested, 50% compliant.
  • Wouxun: 79 tested, 82.5% compliant.
  • Yaesu: 280 tested, 99.8% compliant.

For greater detail of the radios tested and the emissions findings, including spectral graphs of the emissions of a few tested radios, please see the issue of QST I mentioned above.

Comments are welcome.

, , , , , , , , ,

Leave a comment

APRS messaging bug in the Yaesu FT1D

UPDATE 1-19-2017: Another ham reached out to me about this, mentioning that it may be related to having extra spaces at the end of your callsign if it’s less than 6 characters. I loaded my programming in RT System’s FT-1D Programmer and went to Settings > Radio Menu Settings, then clicked the APRS tab. Here I was able to verify that an extra space does exist in the “My Callsign” field. I’ve decided not to test this further, but it should be trivial for someone to verify whether or not removing this extra space fixes this issue.

I have a Yaesu FT1D that supports APRS messaging. I set the callsign in my radio (via SET:12), and I set my APRS callsign as my callsign with SSID -7 via SET:9>23. (See the FT1D manual here or an explanation about APRS SSIDs here.)

I tried sending a message to CQSRVR and ANSRVR to test, but I never got any replies. I have a low-budget digipeater set up in another room using a laptop and another HT, so I checked the screen. The packets were received, gated, and responses were received and transmitted, but my radio never showed anything under messages.

I installed PocketPacket (iOS App Store) and using SSID -5 for it. I sent a message from my radio to my -5 SSID. It showed up on my iPhone. I replied to that message, addressed to SSID-7, it did not show up on my radio.

A bit frustrated, I sent a message to my callsign without SSID. It showed up on my radio. However, when I replied from my radio, the -7 SSID was appended, and so replies to the -7 SSID wouldn’t show up.

By changing my APRS SSID via SET:9>23 to my callsign only without SSID, I was able to get messaging working as expected.

So, in a nutshell:

Issue: APRS messages are not displayed on the radio when an SSID of non-zero is set via SET menu 9>23.

Occurrence: Always

Steps to reproduce: Set an SSID to your callsign via the above-mentioned settings menu. Transmit an APRS message from another device to your callsign-with-SSID. It is not shown on the radio. Transmit an APRS message from another device to your callsign-without-SSID. It is shown on the radio.

Workaround: Set menu 9>23 to your callsign without SSID.

Expected behavior: When the SSID is set via menu 9>23, messages are shown as addressed to your callsign-with-SSID.

I will be emailing Yaesu regarding this issue and hopefully they can fix it in a firmware update.

, , ,

Leave a comment

How much data does a Voice-over-LTE call use, and does it bill against your data plan?

Yesterday a friend of mine sent me this text message:

So, I spoke to two separate AT&T representatives, one on Tuesday and the other yesterday, and they both said that VoLTE calls when available will subtract from monthly cellular data.

So, I spoke to two separate AT&T representatives, one on Tuesday and the other yesterday, and they both said that VoLTE calls when available will subtract from monthly cellular data.

Well, I can’t well ignore that. I reached out to AT&T via Twitter for comment:

@ATT @ATTCares Can you comment on VoLTE data usage?

@ATT @ATTCares Can you comment on VoLTE data usage?

Not receiving a response, I decided to do some ballparking on my own. I wanted a rough estimate of the peak usage that VoLTE could use under any circumstances, because, what if it’s true?

So, first thing to note is that under AT&Ts roll-out of VoLTE, they’re introducing HD Voice. HD Voice is also being rolled out on other carriers, some possibly independent of a VoLTE roll-out, but since I’m focusing on bandwidth utilization, that difference is not applicable to this.

Now, for the purposes of VoLTE, there are two codecs in play here. AMR-NB (for narrowband, normal calls), and AMR-WB (for wideband, HD Voice calls) [source]. AMR-WB will naturally have the higher bandwidth utilization of the two.

The AMR-WB codec uses, at peak, a 23.85kbps (kilobits) codec [source]. That’s one-way, making it 47.7kbps peak for both ways. I’ll say 48kbps to add a little overhead. This number is in line with an article at NetworkWorld, which states that VoLTE calls come out to about 30-40kbps at peak. That comes out to 6kBps (kilobytes), both ways, at peak. Roughly speaking. It’s possible for the codec to shift to a lower bandwidth during silences and lower frequency-range conversations, or during network congestion, and that’s important to understand.

So, doing the math on a 15-minute phone call will give you a peak usage of 6kB/sec, 360kB/min, and 5.4MB/15min (1MB=1000kB). That’s absolute peak. All other usage not withstanding, that’s [very] roughly at least 92.5 hours or 5,550 minutes of talking on your 2GB plan.

And that’s if VoLTE calls bill against your data plan.

UPDATE: A reader has sent me the following from Verizon’s website, which specifically mentions HD Voice, but not VoLTE:

HD Voice is available at no additional charge and is included in existing plans.
HD Voice calls are billed as standard voice calls according to your plan. No data charges apply.

Mobile-to-Mobile calls that happen to be HD Voice calls are charged just like traditional Mobile-to-Mobile calls and are billed against your monthly minute allowance according to your plan.

A video call is an HD Voice call combined with real-time video. The voice portion is billed as a standard voice call, according to your plan. The video portion is billed as data, according to your data plan. No data charges apply to video calls transmitted over Wi-Fi.
Note: An average 1-minute video call uses about 6 – 8 MB of data. The actual data consumption of your video call may vary. You can estimate your data usage using our online Data Usage Calculator.

Source: https://www.verizonwireless.com/support/advanced-calling-faqs/

Thoughts on this? Corrections on my math? Please feel free to comment below. 

,

Leave a comment

Synology Antivirus Essential detects PHP.Exploit.CVE_2015_2331-3

Today my DiskStation emailed me about detecting malware in the system files. When I looked at the log, I saw this:

Antivirus Essential detects Php.Exploit.CVE_2015_2331-3 in zip

Antivirus Essential detects Php.Exploit.CVE_2015_2331-3 in zip

It appears this is a false positive in the ClamAV database.

Further reading: https://www.clamxav.com/BB/viewtopic.php?f=1&t=4186&hilit=php.exploit

If your Synology reports the same, simply restore the quarantined file, update virus definitions, and re-scan. It should come up clean. If you had configured Antivirus Essential to automatically delete files, you may have to restore the DSM OS to get the file back.

,

Leave a comment