2023-12-01 — AMSAT-CA Formed, Amateur Radio Will Soon Lose Use of Most of the 1240 - 1300 MHz Band, Digital Voice or Data - Not an Either Or Choice, More Thoughts on IPv6 - No “44Net” within IPv6
We in Philadelphia ARES whose served agency is the Southeastern PA Chapter of the American Red Cross (SEPA-ARC) have run into the problem of magmount failure as many SEPA-ARC vehicles have fiberglass bodies. Bill W3AOK has designed and built a suction cup mount which has stood up to 60MPH travel and performs well with a half-wave antenna (thus not requiring a ground plane) such as a Diamond SR-777. I'll send you a photo in email. 73 de K3FZT / Steve
Dec 2, 2023Liked by Steve Stroh N8GNJ, AF7SJ - Bill
23cm: This shows how important political representation of ham radio is! Finnish hams lost the 23cm band completely last year. In Scandinavia (SM, OZ, LA, OH) the 70cm band has been only 6 MHz wide for a long time, including the ISM band. The Scandinavian hams must operate their relays with 1.6 MHz offset, partly up and partly down. Many relay input frequencies are in the ISM band :-(
Integrated voice and data: One feature makes or breaks digital voice for me: Any delay of more than perhaps 200 ms. I want do do my QSO, especially group QSOs, with a minimum of delay. You know the effect: You start to talk and after a word or two you release the PTT to check whether you are alone. Some time ago I bought a DMR handylalkie. These days, I only use it in FM mode. On the other side: Try to spell an URL over voice...
That's an interesting point, voip should manage a delay of less than 70 ms over the Internet, doing that on radio depends on the modem and the bandwidth. But collision detection is easier with digital. If you had a modem that was faster than the code needed it could semi randomly skip a frame and listen for another station using the link and notify you of collision.
What I find exciting about voice over data is the flexibility, we could build broad band repeaters and multiplex several voice streams over the link, or if no one was talking occupy the unused bandwidth with other data. What kind of data? Anything we can imagine that fits into the bandwidth including files, sms, paging, even video on bands where we have the available bandwidth.
Bill - One of the primary uses I can think of for unused bandwidth is bulletins using a "flood and fill" protocol. The original one I remember was RadioMirror, but that code is very old (MS-DOS) and unmaintained and mostly unobtanium. FLAMP (FL digi suite Amateur Multicast Protocol) - http://www.w1hkj.com/files/manuals/US_English/FLAmp_2.2_Users_Manual.pdf. One really nice thing about FLAMP is that it doesn't require "acks" from receiving stations - it does Forward Error Correction and if there's an error received in a FLAMP transmission, the receiving station won't recreate the file until it receives a complete error-free transmission. There's an infinite source of bulletin info specific to Amateur Radio, including periodic APRS products, updated repeater lists, club bulletins, etc.
Good point Steve. I also remember reading about a service a few years ago that would broadcast information over a GEO satellite to a basic receiver. It numbered it's fragments and would repeat the message several times over the course of a few days so that the ground station could assemble what it had missed. That plus FEC could be fun for gathering data without having to leave your gear on 24x7...
Or from a multicast perspective, have a mechanism to request fills for any packets that fail at the end of the initial data dump... I'm not sure I have that much useful information to put on the air, but it would be fun to work out the project. I also BTW like the idea of a paging / message system being developed over, similar to APRS instant messaging, but with persistence and retries if you somehow miss the first transmission.
Alexander - Indeed, that was one of the arguments I've read for putting digital voice systems "onto bare metal" - no overhead of a multitasking OS, etc. (or at minimum, use a realtime OS with few other processes).
@AF7SJ: I did not talk about standard VoIP acros the Internet. I did talk about radio services like DMR, linked through massive digital networks over the Internet. In this environment, delays during a hand-over easily add up to several seconds.
The delays start with the codecs that need a certain number of samples before they can start to compress speech. The RF transmission uses time-domain multiplex (TDM), adding another few ms. This all happens in front of the VoIP transmission. Then we need the hand-over procedure that needs to flush all buffers. Then follows another TDM RF transmission. At the receiver you need a buffer to mask Internet and RF delays - this buffer must be filled before its output can be used.. Finally another codec delay.
Right, but what I'm saying is that with the Internet we've proven we can have lower latency. With PTT the total delay doesn't matter as much as with full duplex voice if we have a way to signal usage of the radio link to prevent doubles. I believe if that is a concern foe hams other than you we can find a way to add that feature. If we have good collision detection that is low latency I believe the buffer lag won't matter as much.
The coolest part though is we cam experiment and add features that we think we want and see what makes for the best end user experience. After all, the current HF digital modes that are popular are because many different ideas and priorities are being experimented with.
We use VoIP full duplex all the time. When you can hear the voice delay from one cellphone to the next, you will be astonished that several 100 ms do not really matter. But most voice traffic we hams do is half duplex. Then all the delays that are imminent to DMR etc. really matter. To the point that I flat refuse to use those modes. In a 1:1 conversation that might all be acceptable. But group conversations need a net control station.
BIll - Agreed that experimentation is key. That's one of the reasons I really like the idea of repeaters being refitted with MMDVM, especially once we have "production" MMDVM-TNC, that we CAN experiment with various new things like newer digital voice. For example, I wonder how much better FreeDV / CODEC 2 digital voice would be versus the frozen CODECs in DMR, D-Star, SF, etc.
Alexander - I wonder if CODECs are needed any more now that we have fast-enough processors to digitize and compress speech rather than breaking it down into artificial representations and then just playing back the artifacts.
A codec is primarily a piece of software that compresses the analog/digitized voice signal into as few bits as possible. The codec ICs you have to buy for certain algorithms are only to ensure you pay the license fee. Even very cheap CPUs are able to process such algorithms easily these days.
Over the decades there have been many concepts to compress voice data. For example early digital phone systems increased dynamic range by using small digitizing intervals for small amplitudes and larger intervals for larger amplitudes, therefore producing reasonable audio with 8 bits per sample - remember A-law and µ-law? There were tries to only transmit the difference between one digitized voltage to the next. Such systems introduced hardly any signal delays. But today's codecs take for example 1024 samples, do FFT or similar computations and then minimize the signal to those spectrum samples that make up most of the signal - remember MP3.
If you sample at 8 kHz, you get a 128 ms delay alone from gathering those 1024 samples. The same happens in the receiving side: Get the data for that 128 ms interval and compute the audio signal. You need all of the data before you can begin.
I believe one issue is you keep referencing DMR, which wasn't designed to be conversational, its target audience was small group communication on a shared channel of business / tactical information (so brevity of message) or dispatch.
Have you tried FreeDV? There we have a very low bandwidth codec, fully open source, that works over narrow channels. Opus is another codec that is used in VoIP and works well with minimal latency.
The catch with low end user latency is balancing the three legged stool of Compression Latency, Bandwidth Usage, and Error Correction. We can get better compression if we analyze the voice longer but at the cost of delay. How much bandwidth we are willing to use determines how much compression we really need, and finally with forward error correction where you send additional data with the packets we use more bandwidth, but can recover from lost voice packets more transparently or completely. VoIP sounds great because it rides on a very reliable, low latency, high bandwidth network.
For your conversational needs a different blend makes sense compared to a directed network. Of course Software Defined means if we could send some header info could let us change that balance on the fly different users of the systems could have the experience they prioritize... More experimentation is of course required.
I agree, current DMR is not very conversational, but I believe that isn't "digital" so much as what Motorola prioritized for their perceived product usage.
Bill, we agree that DMR was developed for a completely different target group. Nevertheless it is used quite often in ham radio.
I know about FreeDV, but have not experimented with it. By what I have seen, it has lower turn-around delays than DMR, the only system I have experience with. But I am more interested in emergency traffic and welfare traffic, combined with general preparedness stuff. Last weekend we got 40 cm of snow within two days...
Have I written before that VarAC brought me back to shortwave after more than 10 years, as 59/73 does nothing for me? With the typical data rates of my QRP station I need not think about digital voice on shortwave. VARA provides a lowest data rate of 18 bit/s...
I don't know how much you are into the theory of how things work, but the developer of FreeDV's site https://www.rowetel.com/ has lots of info on how he is trying to get the best performance for the lowest power levels. I suspect in another year or two his modem work will dominate, and possibly even become a rival to Vara. I've enjoyed browsing his site, I found it mind expanding.
FreeDV just outputs baseband audio, so it could be used SSB on VHF / UHF if you found willing participants, or even just played over a FM channel via a sound card interface. I know for a lot of users that would include a what's the point, but I suspect (don't 100% know), that it would be intelligible over an FM link longer than voice would be copyable. OK, now I need to do some testing there...
It looks like the IARU were successful in keeping this as a recommendation - meaning its still up to individual countries to decide whether to implement it (assuming my reading of this is correct)
I expect CEPT will make it mandatory as it is future commercial GALILEO usage which has driven this. As GPS is not affected, I suspect the FCC couldn't care less unless some commercial or political pressure is brought.
Well done to the IARU representative though. Tough negotiations - only two instances of interference documented, but a lot of commercial and political pressure in the negotiations. I'm glad it got sorted by this conference - it threatened to go on longer, or become instituted in a worse manner.
There's a talk on this on YouTube from the RSGB by one of the IARU representatives - it sounds very frustrating.
We in Philadelphia ARES whose served agency is the Southeastern PA Chapter of the American Red Cross (SEPA-ARC) have run into the problem of magmount failure as many SEPA-ARC vehicles have fiberglass bodies. Bill W3AOK has designed and built a suction cup mount which has stood up to 60MPH travel and performs well with a half-wave antenna (thus not requiring a ground plane) such as a Diamond SR-777. I'll send you a photo in email. 73 de K3FZT / Steve
Thanks Steven! That's a clever solution. Next chore is to figure out how to route coax into the interior of a Cybertruck.
23cm: This shows how important political representation of ham radio is! Finnish hams lost the 23cm band completely last year. In Scandinavia (SM, OZ, LA, OH) the 70cm band has been only 6 MHz wide for a long time, including the ISM band. The Scandinavian hams must operate their relays with 1.6 MHz offset, partly up and partly down. Many relay input frequencies are in the ISM band :-(
Integrated voice and data: One feature makes or breaks digital voice for me: Any delay of more than perhaps 200 ms. I want do do my QSO, especially group QSOs, with a minimum of delay. You know the effect: You start to talk and after a word or two you release the PTT to check whether you are alone. Some time ago I bought a DMR handylalkie. These days, I only use it in FM mode. On the other side: Try to spell an URL over voice...
That's an interesting point, voip should manage a delay of less than 70 ms over the Internet, doing that on radio depends on the modem and the bandwidth. But collision detection is easier with digital. If you had a modem that was faster than the code needed it could semi randomly skip a frame and listen for another station using the link and notify you of collision.
What I find exciting about voice over data is the flexibility, we could build broad band repeaters and multiplex several voice streams over the link, or if no one was talking occupy the unused bandwidth with other data. What kind of data? Anything we can imagine that fits into the bandwidth including files, sms, paging, even video on bands where we have the available bandwidth.
Bill - One of the primary uses I can think of for unused bandwidth is bulletins using a "flood and fill" protocol. The original one I remember was RadioMirror, but that code is very old (MS-DOS) and unmaintained and mostly unobtanium. FLAMP (FL digi suite Amateur Multicast Protocol) - http://www.w1hkj.com/files/manuals/US_English/FLAmp_2.2_Users_Manual.pdf. One really nice thing about FLAMP is that it doesn't require "acks" from receiving stations - it does Forward Error Correction and if there's an error received in a FLAMP transmission, the receiving station won't recreate the file until it receives a complete error-free transmission. There's an infinite source of bulletin info specific to Amateur Radio, including periodic APRS products, updated repeater lists, club bulletins, etc.
Good point Steve. I also remember reading about a service a few years ago that would broadcast information over a GEO satellite to a basic receiver. It numbered it's fragments and would repeat the message several times over the course of a few days so that the ground station could assemble what it had missed. That plus FEC could be fun for gathering data without having to leave your gear on 24x7...
Or from a multicast perspective, have a mechanism to request fills for any packets that fail at the end of the initial data dump... I'm not sure I have that much useful information to put on the air, but it would be fun to work out the project. I also BTW like the idea of a paging / message system being developed over, similar to APRS instant messaging, but with persistence and retries if you somehow miss the first transmission.
Alexander - Indeed, that was one of the arguments I've read for putting digital voice systems "onto bare metal" - no overhead of a multitasking OS, etc. (or at minimum, use a realtime OS with few other processes).
@AF7SJ: I did not talk about standard VoIP acros the Internet. I did talk about radio services like DMR, linked through massive digital networks over the Internet. In this environment, delays during a hand-over easily add up to several seconds.
The delays start with the codecs that need a certain number of samples before they can start to compress speech. The RF transmission uses time-domain multiplex (TDM), adding another few ms. This all happens in front of the VoIP transmission. Then we need the hand-over procedure that needs to flush all buffers. Then follows another TDM RF transmission. At the receiver you need a buffer to mask Internet and RF delays - this buffer must be filled before its output can be used.. Finally another codec delay.
Right, but what I'm saying is that with the Internet we've proven we can have lower latency. With PTT the total delay doesn't matter as much as with full duplex voice if we have a way to signal usage of the radio link to prevent doubles. I believe if that is a concern foe hams other than you we can find a way to add that feature. If we have good collision detection that is low latency I believe the buffer lag won't matter as much.
The coolest part though is we cam experiment and add features that we think we want and see what makes for the best end user experience. After all, the current HF digital modes that are popular are because many different ideas and priorities are being experimented with.
We use VoIP full duplex all the time. When you can hear the voice delay from one cellphone to the next, you will be astonished that several 100 ms do not really matter. But most voice traffic we hams do is half duplex. Then all the delays that are imminent to DMR etc. really matter. To the point that I flat refuse to use those modes. In a 1:1 conversation that might all be acceptable. But group conversations need a net control station.
BIll - Agreed that experimentation is key. That's one of the reasons I really like the idea of repeaters being refitted with MMDVM, especially once we have "production" MMDVM-TNC, that we CAN experiment with various new things like newer digital voice. For example, I wonder how much better FreeDV / CODEC 2 digital voice would be versus the frozen CODECs in DMR, D-Star, SF, etc.
Alexander - I wonder if CODECs are needed any more now that we have fast-enough processors to digitize and compress speech rather than breaking it down into artificial representations and then just playing back the artifacts.
A codec is primarily a piece of software that compresses the analog/digitized voice signal into as few bits as possible. The codec ICs you have to buy for certain algorithms are only to ensure you pay the license fee. Even very cheap CPUs are able to process such algorithms easily these days.
Over the decades there have been many concepts to compress voice data. For example early digital phone systems increased dynamic range by using small digitizing intervals for small amplitudes and larger intervals for larger amplitudes, therefore producing reasonable audio with 8 bits per sample - remember A-law and µ-law? There were tries to only transmit the difference between one digitized voltage to the next. Such systems introduced hardly any signal delays. But today's codecs take for example 1024 samples, do FFT or similar computations and then minimize the signal to those spectrum samples that make up most of the signal - remember MP3.
If you sample at 8 kHz, you get a 128 ms delay alone from gathering those 1024 samples. The same happens in the receiving side: Get the data for that 128 ms interval and compute the audio signal. You need all of the data before you can begin.
I believe one issue is you keep referencing DMR, which wasn't designed to be conversational, its target audience was small group communication on a shared channel of business / tactical information (so brevity of message) or dispatch.
Have you tried FreeDV? There we have a very low bandwidth codec, fully open source, that works over narrow channels. Opus is another codec that is used in VoIP and works well with minimal latency.
The catch with low end user latency is balancing the three legged stool of Compression Latency, Bandwidth Usage, and Error Correction. We can get better compression if we analyze the voice longer but at the cost of delay. How much bandwidth we are willing to use determines how much compression we really need, and finally with forward error correction where you send additional data with the packets we use more bandwidth, but can recover from lost voice packets more transparently or completely. VoIP sounds great because it rides on a very reliable, low latency, high bandwidth network.
For your conversational needs a different blend makes sense compared to a directed network. Of course Software Defined means if we could send some header info could let us change that balance on the fly different users of the systems could have the experience they prioritize... More experimentation is of course required.
I agree, current DMR is not very conversational, but I believe that isn't "digital" so much as what Motorola prioritized for their perceived product usage.
Bill, we agree that DMR was developed for a completely different target group. Nevertheless it is used quite often in ham radio.
I know about FreeDV, but have not experimented with it. By what I have seen, it has lower turn-around delays than DMR, the only system I have experience with. But I am more interested in emergency traffic and welfare traffic, combined with general preparedness stuff. Last weekend we got 40 cm of snow within two days...
Have I written before that VarAC brought me back to shortwave after more than 10 years, as 59/73 does nothing for me? With the typical data rates of my QRP station I need not think about digital voice on shortwave. VARA provides a lowest data rate of 18 bit/s...
I don't know how much you are into the theory of how things work, but the developer of FreeDV's site https://www.rowetel.com/ has lots of info on how he is trying to get the best performance for the lowest power levels. I suspect in another year or two his modem work will dominate, and possibly even become a rival to Vara. I've enjoyed browsing his site, I found it mind expanding.
FreeDV just outputs baseband audio, so it could be used SSB on VHF / UHF if you found willing participants, or even just played over a FM channel via a sound card interface. I know for a lot of users that would include a what's the point, but I suspect (don't 100% know), that it would be intelligible over an FM link longer than voice would be copyable. OK, now I need to do some testing there...
It looks like the IARU were successful in keeping this as a recommendation - meaning its still up to individual countries to decide whether to implement it (assuming my reading of this is correct)
I expect CEPT will make it mandatory as it is future commercial GALILEO usage which has driven this. As GPS is not affected, I suspect the FCC couldn't care less unless some commercial or political pressure is brought.
Well done to the IARU representative though. Tough negotiations - only two instances of interference documented, but a lot of commercial and political pressure in the negotiations. I'm glad it got sorted by this conference - it threatened to go on longer, or become instituted in a worse manner.
There's a talk on this on YouTube from the RSGB by one of the IARU representatives - it sounds very frustrating.