That bandwidth petition...

Some of you may have been wondering what ever happened with that push to remove the symbol (baud) rate restrictions for ham radio and to just set a bandwidth rule.

The FCC's June 2016 conclusion to their request for comments on the ARRL's proposal (RM number 11708) was; They agree that a hard baud limit is not good, but the bandwidth limit proposed by ARRL isn't any better, so FCC denied the request.

Theodore Rappaport, N9NB has been making a fairly big media campaign to get the FCC to dismiss the the subsequent pending Notice of Proposed Rule Making (Docket No. 16-239).  His issue is that wide-band connected digital modes and modes that are hard, expensive (or need proprietary hardware, firmware or software) to intercept communications on-the-air need to be removed from the amateur bands.

He goes so far to say that these these modes encourage crime, terrorism and are a threat to national security.

I agree with his first part, but won't go that far out on a limb to make his secondary claims.  Having open communications in ham radio is essential to preventing unauthorized use of the bands/self-policing.  It's also essential to the self-learning/training aspects of the hobby.  Anything else stifles innovation


Ham radio operators have long been some of the original open source , Do-It-Yourself (DIY) proponents.   I wrote about this some time back after the economy collapsed.


Bruce Peren's K6BP brought this proprietary "black-box" problem to the forefront back in 2006.  At that time he was concerned about the proprietary vocoder in D-Star.

In a reply RM-11625 comment from Bruce Perens in 2012, he made the suggestion that comment that only open source protocols be allowed...
(https://ecfsapi.fcc.gov/file/7022090358.pdf)

"Amend Section 97.309(a) to read:
Any digital code that is fully disclosed to the public in sufficient detail that a Knowledgeable person can create a computer program to encode and decode it, or any digital code of a type specifically authorized in this part, may be transmitted."

I'd be in favor of Bruce's suggested emission code language in conjunction with the FCC's intended resolution for removing the symbol rate and not adopting a bandwidth limit.

Many may respond that this will there would be detrimental effects from banning existing technology like Pactor and AMBE. Radio amateurs will simply have to undertake an joint effort to reverse engineer protocols and/or petition the manufacturer's to create an open specification of their technology.

APCO (the Association of Public-Safety Communications Officials) required this very thing in relation to their standard, P-25. And ham radio should also adopt that type of policy. The future of radio is more and more software defined, so sharing information/specifications and working together is what ham radio has always been about.

What is more disturbing to me is that the "leaders" of ham radio haven't really even gotten on soap box about this, let a lone proposed a solution.

Getting on DMR and other Digital Radio networks from your phone

There was recently a message from the folks that run the BrandMeister servers requesting that folks do not cross link the traffic to Zello or other non-amateur VOIP networks.

Zello is not to be cross-linked to BrandMeister in any way.

All of the US Master server owners decided among themselves that they do not want any part in facilitating other amateur radio operators to knowingly or unknowingly break the rules that the FCC have made for us to abide by, these are the same rules that you sign to agree to after you successfully pass an amateur radio examination.

But the reason people are doing so, is because they want access to the network in a more logical way than we have now. So lets review.

Presently the only thing that ensures the voice traffic is from a ham is that traffic be AMBE encoded, as that is how its natively transported anyway. This leaves you with two traditional options;

1.) Use an transparent RF "hotspot" to take the native AMBE traffic from your HT and put it on the internet. These are generally Part 15/10 mW transmitters, to provide "in-house" coverage
2.) Use an AMBE hardware dongle to do the encoding.

The problems are that the first option is a lot of hardware to haul around to effectively talk ~50 feet into a radio. And the cost.

The problem with second option is mostly cost and a lack of wide support for doing so, especially with mobile devices. So that is why people are bridging to Zello.

In the near future software AMBE will be widely doable. The "unverified ham origin" problem will metastasize as software AMBE becomes easier. So WE NEED to incorporate automatic authentication into this somehow.

Right now we have security by obscurity, as the traffic is merely in a strange non-standard AMBE format. BrandMeister seems okay with cross linking to Allstar. Allstar, like EchoLink, IRLP, and the other "ham" VOIP systems manually verify that you are a ham.

That could be and probably should be automated. You could be uploading your LoTW (Log Book of the World) digital P12 certificate to their sites to verify that you are a ham. (The LoTW verification process sends a post card to your FCC address, and Then issues you the digital P12 certificate)

But we need to get all these ham VOIP network operators to implement that. From there, you can use the IAXRPT or Zoiper apps to talk into the Allstar networks and thus DMR and other digital networks.. Or the Echolink app, etc.

It would be ideal if your allstarlink.org account could be verified automatically this way.  And a unique SIP credentials would be auto-generated. so you can use normal Apps to connect to their server directly.  From there and IVR menu of options could exist.  Like "Press 1 for Talkgroup X" etc.


These concepts could also be something for the newer hamshack hotline folks to explore.

Listening to D-Star on the Rasperry Pi3 with op25 and a SDR

A while back I blogged about how to listen to DMR using a SDR.  I tried to do the same with D-Star, but was having problems.  I ended up reaching out to the author.  He just released a fix, so if you download / install from now on, you shouldn't run into the head banging that I was.

I am not going to lie, it doesn't sound the best.  There was no information for coder's to work off of, so what we have is rather crude, but intelligible.

If you are looking to help improve it, start here.  This is from the folks from the community that brought us what we have today.


There was also this tip from user "groovy"

If anybody wants to continue the research / work, I suggest you look at the osmocom GMR code that Sylvain Munaut worked on. Those phones use a similar codec - I believe with longer frames for the satellite latency. Initially he used the mbelib code, enhanced it for things like tone support, but he later rewrote the synthesis code completely. See OsmocomGMR for his presentations and source code.

Unless other developers take this on, DVSI releases specs, or you switch to a hardware-based decoder like the thumbDV, I don't see the dstar voice quality improving in the short term.

I'd love to see further work on OP25. More so on the transmit part (hooked to analog radio, perhaps using the MMDVM hardware/Arduino.   Anyone care to join forces with Max?

Perhaps an update to Johnathan Naylor's (2009) GUI Linux client that would decode and generate GMSK using a soundcard and interface to a radio with a 9600 Baud packet connector. ..

Wouldn't mind a way to hook op25 to Allstar either  :-)

The Next 100 Years of Ham Radio

A few years back I shared a video about ham radio in the future.  It's was from a 2012 webinar, where Chris Imlay W3KD and Ed Hare W1RFI predict and speculate what ham radio will be like in 25 years.

As the focus of my blog has been more of a modern ham radio theme, it seems appropriate also share an excerpt from Mike & Key Amateur Radio Club (Seattle) Newsletter (K7LED Relay) by Peter N. Glaskowsky K4PNG.

October 2014

The Next 100 Years of Ham Radio

By Peter N. Glaskowsky K4PNG, Activities Manager

The video we saw at last month’s meeting, ARRL at 100 — A Century of Ham Radio, helped me to better understand the history of our hobby. It also got me to thinking about how amateur radio might continue to advance over the next 100 years.

I believe the key elements of ham radio’s future will be developed from recent history’s three biggest technologies: the personal computer, the Internet, and the cellphone. Each of these fields has much to offer us. I'd like to explain some of these opportunities and describe one possible vision of what we can achieve.

The evolution of the PC has shown us that microprocessor-based digital electronic devices are faster to develop and more flexible than those using fixed-function digital or analog circuitry. While most modern ham radios have some digital logic in them to manage buttons and displays, most of the RF and audio processing in these radios is still done by analog circuitry.

Even most of the so-called software-defined radio (SDR) products on the market are still predominantly analog inside, with digital processing only in the audio stages. While features such as noise reduction, voice processing, and simple digital modes are valuable enough, the full potential of SDR is achieved only in direct-conversion designs that digitize one or more bands with minimal analog processing.

Although there are several direct-conversion radios on the market, including commercial and hobbyist designs, it’s still early days for this product category. Many valuable features remain to be integrated, including features that will come from those other two fields: the Internet and the smartphone.

The Internet teaches us the advantages of packetized data. Packets let us route our transmissions through complex networks, share a single channel among multiple users and messages, and confirm error-free reception where desired.

The latest smartphones deliver high-fidelity voice quality similar to that of landline phones—but over radios, a far more demanding environment. They also feature full-duplex operation, which is more convenient for users and opens the door to techniques such as collision detection, transmit power minimization, and real-time band coordination. Whereas cellphone networks are controlled by one central authority, amateur radio operators work together to follow the guidelines of band plans they develop themselves, like those of the ARRL and the Western Washington Amateur Repeater Association (WWARA).

It may seem as though many of these technologies could use more of our limited spectrum for the same amount of traffic. After all, packets and control channels add considerable overhead, extra error-correction bits do no good for clear, strong signals, and it’s wasteful to retransmit a whole message when only a word or two isn’t heard.

But in truth, today’s amateur radio is terribly inefficient. How many times, on average, do you send (or say) “CQ” for each QSO you complete? How many calls do you hear, but not understand? And when nobody is transmitting, the frequency is still occupied. Our modulation schemes are far less efficient than digital methods. CW, which is one of our more efficient modes, uses about 100 Hz of bandwidth to carry 35 words per minute (roughly 30 bits per second) of information. With a digital modulation scheme such as 64-symbol quadrature amplitude modulation (64-QAM), the same amount of data would fit into as little as 5 Hz of spectrum... and 64-QAM is far from the most efficient modulation scheme known. Digital radios are also better at sharing one channel among multiple users, delivering the benefit known as statistical multiplexing.

There are dozens of other techniques used to improve the throughput and reliability of communications channels, more than I could possible describe here, known by terms such as 8B/10B, CDMA, DSSS, MIMO, NPML, PRML, RLL, Turbo, and Viterbi. Some of these methods are already used in radios, and some were developed for wired networks or even disk drives, but they’re all worth studying to see how they might apply to the unique requirements of amateur radio.

A common objection to the rapid adoption of advanced technologies is that they interfere with what 47 CFR 97.1 describes as “the amateur's proven ability to contribute to the advancement of the radio art.” It’s a rare amateur who can understand everything going on inside modern analog radios, never mind digital ones. It may seem as though adding more layers of technology will make it more difficult for amateurs to contribute meaningful innovations—but digital radios are simpler inside, and it’s easier to add new features with software than hardware.

Amateur operators used to lead the development of radio technology. It may take many years for amateur radio to regain technical parity with commercial interests, but I believe we can and will get there.

Opening up our hobby to technologies that were developed for computer networks and cellphones creates the potential for hams to attract interest and assistance from the companies that developed them. Intel, Qualcomm, and Samsung (to mention just three of the largest) employ armies of RF and communications system engineers, but few if any of these professionals work on ham-related projects because their employers see no significant profit potential there.

These leaders of the cellphone industry are aware, however, that they aren’t taking full advantage of the potential synergies available in large networks of smartphones. In a technology known as cognitive radio, smart radios cooperatively adapt to changing conditions and requirements. With the flexibility to try experimental new technologies and the pressing need to deal with the changing conditions of the HF bands, amateurs may already be making more rapid progress toward cognitive radio than commercial firms.

Similarly, while there is much talk of “cloud computing” today, rigidly hierarchical computer networks aren’t very cloud-like. Mesh networking technology, which is under active development here in the Pacific Northwest, is a great solution for amateur radio and may also be a better solution than the networks from which the public Internet is built. As amateur mesh networks become more sophisticated, their underlying technologies may transfer back into the commercial world.

Unlocking the full potential of amateur radio will require more than technology. The language of the law will have to change, too. The current legal framework dates back to the days of crystal-controlled radios, and creates unnecessary obstacles to improving spectrum utilization with smart, agile SDRs. The current prohibitions on commercial and encrypted content preclude using amateur frequencies for Internet access; reversing that stance would surely create tremendous new demand for ham licenses and radios. Such prohibitions still make sense in the crowded HF and VHF bands, but with tens of megahertz of amateur spectrum available in UHF, and over a gigahertz in the SHF band—where line-of- sight propagation means the bandwidth in a geographical area is practically unlimited—more accommodating policies could spur more rapid progress.

I’d like to show how all of these advancements could apply to amateur radio by sketching out a hypothetical future DX contest—using only technology we could deploy today.

As the contest opens, participants introduce themselves by broadcasting just one digital CQ call. Since everyone has a software-defined radio that simultaneously receives and decodes every transmission on every band, each station knows the call signs and locations of every other station within minutes. The stations spontaneously construct a distributed control system that calculates the ideal combination of long-range and short- range connections to maximize the number of QSOs on the network.

The best stations get the most points for completing their own QSOs and for relaying the QSOs of others. Instead of a hundred contacts per hour, each operator could make thousands.

True, some of the skills needed for this kind of contest aren’t the traditional ones, but they are unquestionably more relevant to the real- world needs for amateur radio. There would be very little difference, for example, between a contest and a disaster-response operation, except for the content of the messages. And bear in mind that digitally programmed and enforced band plans will keep digital radios from interfering with CW, SSB, and RTTY operations. The spectrum of the future will have plenty of room for tradition and progress.

Listening to DMR on the Rasperry Pi3 with op25 and a SDR

This past summer I blogged on how to listen to a simulcast APCO-25 trunked public safety system. Since that time was looking for a way to listen to a DMR system.  Last winter I gave the Raspberry Pi2 a try using DSD.  That didn't go so well.  I suspect because DSD was written a long time ago, and is a single threaded application that can't take advantage of the Pi's multiple cores.

Last April Transmit support was added to op25 for; DMR/YSF/P25 and D-STAR.  Just after Christmas this year, Receive support was announced.  So I had to try this!

I just heard DMR audio on a Pi3.. And it sounded good!

Linux op25 4.9.28-v7+ #998 SMP Mon May 15 16:55:39 BST 2017 arm71 GNU/Linux (Raspbian Jessie)

ppm set to 3 for me (see json file below)  using my NooElec SDR

Note: DMR audio for the second time slot is sent on the specified port number plus two.  In example 'udp://127.0.0.1/56122', audio for the first slot would use56122; and 56124 for the second.

You can setup a mix of the various digital channels in the json file... It works like a scanner.. And if you want you can define SDR dongles to channels... In case you want certain channels banded to a certain hardware... for RF/antenna reasons for example.

Graham and Max have been hard at work improving op25.  And thanks to that hard work its child's play to install:

sudo apt-get update
sudo apt-get build-dep gnuradio

cd ~
git clone https://github.com/boatbod/op25
cd op25
./install.sh

If you are wondering what your tuning offset is, the best thing is to enable the datascope plot, and adjust the ppm value by one click at a time to center the eye plot.

{Edit/update April 2020}

Max just added a way to specify talk group id's for DMR:

There are two new json keys defined for the channel entry - examples

   "whitelist":  "4,6,8"

        or

   "blacklist": "9"

The talk group id's are specified as a string (comma separated list) with the entries in decimal.