2024-11-22 — 2300+ Subscribers!, What’s New at DLARC 2024-11, Explaining Data Over Repeater - Part 1, WB2CBA / DX-FT8 FT8 Multiband Tablet Transceiver, New Yaesu FTM-150RASP “Data Radio”, SharkRF M1KE
“there are many subscribers who (per Substack’s metrics) never seem to “engage” with Zero Retries - never or very rarely open / read it”
If a reader is using an email client with settings focused on privacy, I wonder how Substack can provide accurate stats on which emails have been read? It’s something like the challenges facing opinion pollsters these days. Of course the other stats should be pretty solid, but from my own behavior I know that I read many more articles than I comment on or click “like”.
Craig - Thanks for that reality check. You're right, of course, and if you read ZR in your email client (like, I'm imaging text-only Pine or whatever) and you don't click or load a URL or a photo, etc. then I don't see how you could show up on Substack's metrics. So what I'll probably end up doing is if, Gosh Forbid, I have to move groups of subscribers manually, I'll prioritize the ones that are most active, and work my way through all 2300+.
That does sound daunting. It might be an opportunity for a trusted friend or assistant to lend a hand. Regarding the information available to Substack, I use the standard Gmail client, but it doesn’t load any images in an email unless I click the prompt to approve it (or have clicked the option to always load images from that sender).
Just a thought on multicast file distribution systems. There is a class of algorithms called erasure codes that take some chunk of data, run a transformation on it to break it up into blocks (the total size somewhat more than original.) Then a receiver need only receive K out of N blocks that were produced by the encoding algorithm to compute the original data. This sort of thing is used at small scale with Reed-Soloman coding and at large scale for storing files. Professionally, we used a product like this which would ingest files, generate blocks that were then stored at multiple geographically dispersed locations. By tuning K and N, you would get disaster recovery and the system overall in managing all the metadata was very scalable.
The application for amateur radio beacons and the like is to just transmit blocks and the receiver can start receiving them at any time and eventually reconstruct the original object. Some research reveals some commerical work for such a thing to be deployed on unidirectional broadcast satellite links where a reverse channel to ask for "fills" wasn't available. Missing a block means you don't have to wait for that one block to be retransmitted to you much later; you might still reconstruct the object sooner.
There appear to be some open-source libraries to do this encoding and decoding computation and that would then need a UI and data transport interface wrapped around it. This sounds like a great opportunity for combine ham radio and thesis work for the right person :-)
Louis - Thanks for contributing this and I'll mention it in next week's Zero Retries Part 2 of the repeater article. I don't know that flamp uses this sophisticated an algorithm, but with cheap compute power like Raspberry Pi, and an open source library, there's no reason something could be implemented to use erasure codes. There was an older implementation of the same idea called RadioMirror (that is now out of date and I'll guess lost to history - querying DLARC got no hits), and as that was explained to me, it was a very simple "transmit numbered blocks of a file, with a checksum" and if a block was received with a bad checksum, the "fill" was to merely to wait for the next time that block was transmitted and hopefully that block will be received with a correct checksum. It seems that this technique could be vastly improved with the "bit flipping" testing that's the secret to success of DIRE WOLF being able to decode more packets than hardware TNCs, and the use of Forward Error Correction, especially IL2P.
As someone who has experimented with multimode repeaters and hotspots for years, I do see a lot of potential for adding data capabilities to FM repeaters. I already have a test system running 5 modes using a MMDVM (currently on a dummy load until I get an antenna up and the paperwork sorted). The system cleanly switches modes, and having data modes alongside the voice modes (including FM) would be neat.
I also have extreme demands on VHF/UHF antennas from monitoring multiple frequencies to supporting APRS and intending to run some sort of data service. Being able to aggregate data services, including repeaters that can receive data such as APRS payloads over M17 or MMDVM-TNC, while transmitting traffic from remote Internet stations would be neat.
An additional factor here is the terrain lends itself to a lot of "hidden station" issues on simplex, which duplex should mitigate, especially when the repeater output isn't tied up with other traffic..
Lots of experimentation ahead, and I'm looking forward to having a play.
Tony - Thanks for the report, from "them that's doing", on multimode repeater operation using an MMDVM. All that unused airtime, from all the repeaters that are allocated "priority" spectrum and channel time, just seems like a great opportunity for applying data communications.
Steve, just to clarify, current multimode operation is voice at this stage. AFAIK, the MMDVM doesn't yet have the capability to do the things I'd like to do, like insert data bursts in a mode different to the current mode between overs (POCSAG might be an exception), or receive modes different to that currently in use for voice.
One thing people tend not to think about is that the repeater's receiver is available for local signals when a transmission is coming in via the Internet (I've made use of that to switch M17 reflectors when on a busy reflector). Being able to make use of that capability for both store and forward data locally and injecting data into Internet connected networks could lead to more useful capabilities.
Even using current hardware with updated firmware offers a lot of possibilities we haven't explored yet.
I would like to say ‘Thank You’ for sending the newsletter to your subscribers regularly. Many of the topics that you write about are outside my current radio sphere and that is what keeps this newsletter interesting to me.
Sandip - Thanks, but MOST of what I write about in Zero Retries is also outside MY current radio sphere... but I remain fascinated by all the technological innovation that IS occurring in Amateur Radio and adjacent areas. When I began Zero Retries, I wasn't sure how much interest there was in this stuff. I only knew of perhaps 100 with similar interests such as a handful of friends in the Seattle area, another handful online, and the demonstrated interest of those that went to the trouble and expense of attending Digital Communications Conferences (before they began to move online).
Thus it's an absolute delight that 2300+ readers now subscribe to Zero Retries to follow along and "conspire", like me, to do more interesting things in our individual Amateur Radio activities, beyond the "same old, same old" modes and activities.
I read through this article quickly, "Explaining the Use Case for Data Over Repeater - Part 1." I will have to go back and reread it as there is a lot of information, and I particularly want to re-read your comments on FLDIGI and FLRAMP for a project that I have in mind. However, one of your comments stood out
"All of this would be much easier explained in an interactive block diagram, which I intend to do eventually. I have not yet spent time learning how to instruct an AI like ChatGPT to create such diagrams, even videos, but that’s on my long to-do list."
One of the things we should be considering about taking repeaters and using them for more than voice is the idea of share time slots or monitoring all of the output of a repeater and a data stream and just use the mode/portion of the data stream that interests you. This could be BOTH voice and data.
DMR repeaters are the generic name of the Motorola MotoTurbo commercial product. This was introduced when the FCC started the narrowanding requirement from 25 KHz channels to the 12.5 KHz channels with another step to 6.25 khz channels or an equivalent of two separate 6.25 khz channels. DMR in the commercial bands has two time slots allowing two channels/voice streams or voice/data mixed mode stream. So today on the public service band DMR meets the 6.25 KHz standard because it can do two channel equivalent on a 12.5 KHz channel. The data stream is running through the repeater and the radio listens to one of the two time slots for the conversation desired. In the ham bands we never were required to move to the narrow 12.5 KHz channels. So for simplistic arguments sake we have two 12.5 KHz channels available on a repeater pair that each could have two time slots. Many private MotorTurbo systems on the commercial bands have just one voice channel but they use the second time slot for data. This data does not hinder the voice communications nor is it even heard on the voice channel. So that is was example to explain how one could use a repeater for both voice and data. Since they are all 25 KHz channels the channel could either be wider or you could create two voice channels and 2 different data channels. I don't believe the DMR protocol allows for this currently but it illustrates the concept. This of course does nothing to allow for traditional analog voice that we are so accustomed to today. But if we had radios that could read the whole maximum possible data stream on what an analog voice repeater is capable of today, you get an idea of what is possible.
Another more basic concept of how to you existing voice repeaters for data would be to allow data to use the repeater but without transmitting the PL tone on the data output of the repeater. So users of the data could still be receiving the data bursts but regular voice users would not have to listen to the data. The data protocol would be set such that if a voice user wants to use the repeater it would take priority and forced the data users to hold off and only continue to move the data when there are no active voice users on the repeater. On busy voice repeaters that would mean the data is not the fastest and during busy voice periods for a repeater that data would not be moving. But the rest of the time the repeater is otherwise dormant data could be moved and the users would not hear it on their radios. One of the downsides to this would be that the repeater transmitter might be used and keyed up a lot more than normal. If the transmitter PA on the repeater was not built for a much higher transmit and receive duty cycle, that would have to be mitigated or this could only be done on repeaters that are built for high duty cycles.
Looking at either of these concepts in this way one can start to understand what we are talking about with the idea of using otherwise underutilized resources. It would also not but much of a stretch to link the data between any of these repeaters and allow the digital data to be shared or routed over larger geographic areas.
Brian - Good points all. I'll be exploring these ideas and more in the future article in ZR.
For MOTOTRBO repeaters and radios, there IS a data capability to use one (or both?) of the two slots for data... but that seems proprietary to MOTOTRBO radios - requiring MOTOTRBO radios and software that communicates just with MOTOTRBO radios. Hytera did the same thing. But I haven't seen anything equivalent for "generic" DMR repeaters and radios, so I'm guessing that there may be some Amateur Radio experimentation necessary to enable that capability, perhaps an enhancement of the DMR mode that's implemented in MMDVM.
Yes, data over conventional FM repeaters works, and can work well, but in my (admittedly limited) experience to date, the biggest issue of using data over a voice repeater is that it's a continuing "Mother, May I?" issue with the user base / owners of those repeaters to use data. While they give lip service to the idea of experimentation with data, they don't want to offer "blanket permission" for data use sufficient to make the data capability truly usable (and reliable). Thus we get into the absurd situation of actively considering the creation of NEW repeaters that can be dedicated to "data first" usage... while existing repeaters continue to sit idle 99% of the time.
And agreed, the duty cycle could theoretically be an issue, but probably no more than some voice nets that can go for an hour or more of continuous use. Certainly any new repeater that's set up for data use would be prudent to set it up for enduring high duty cycles.
MOTOTURBO is just the brand name for DMR. Currently the amateur radio DMR community has decided the both time slots will be for voice. There is no reason that a stand alone DMR repeater that is not linked in to the various larger system could not be set up for data on one time slot and voice on the other. I may be mistaken but most DMR repeaters are also set up to be 12.5 KHz channels. I don't think you can get any of the commercial repeaters that have been used for amateur use to do the 25 KHz bandwidth. But sometimes I know just enough to be dangerous. I was disappointed years ago as I saw the adoption of DMR in to amateur and the ecosystem did not embrace using a time slot for data. That was likely done to appease the mentality of many to the idea I don't want to have the repeater tied up all of the time on linked conversations when we just want to talk locally. Assigning both time slots for voice kept both crowds happy. Can you imagine if ALL of the linked DMR systems assigned on time slot to data? If we could convince the DMR repeater operators and link systems to do that it could be an interesting transition of the DMR variety. DSTAR had simultaneous data and voice use built in to that protocol as well. I am not sure what System Fusion offers. We have a RACES repeater that is seldom used that is DMR capable. I am going to dig deeper in to what I might be able to do with this, possibly go full DMR on this one and set a time slot up for data only.
Brian - Disclaiming that I haven't made a very deep, or recent study of this... when I tried to understand if DMR could be used for data (it's a digital modulation, so why not use the bitstream to transmit unstructured data instead of a digital voice data stream)? My limited study of the DMR standard available from ETSI showed that there was some thought given to data over DMR - there do seems to be hooks (flags, protocols) etc. in the spec... but my (again, inexpert) conclusion was that while the spec was rock solid to insure interoperability of DMR voice between various manufacturers - in the radios, in the repeaters, etc., there was not the same rigor applied to insuring interoperability of data over DMR. Thus it was left to the vendors to create effective data over DMR, which they did... following their profit motive in the absence of demonstrated demand for interoperability between manufacturers of data over DMR.
Motorola did data over DMR that worked - over MOTOTRBO, and Hytera did data over DMR that worked on Hytera radios. So even if we could agree to reserve one of the two DMR time slots for data, it would be a long slog to develop a new open source's DMR radio that could do data - that doesn't infringe on Motorola or Hytera's methods of data over DMR. Maybe we could, develop Amateur DMR, and while we're at it, replace the DVSI CODEC with CODEC 2...
Oh wait - we just spec'ed out M17 😀 which does do digital voice and data equally well, including using CODEC 2, not DVSI's CODEC.
And, briefly, digital voice systems in Amateur Radio data capabilities:
* Icom's implementation of D-Star is the de facto standard now, and when they introduced D-Star, Icom "hard partitioned" D-Star's 4800 bps data stream into 2400 bps for the digital voice, 1200 bps for voice FEC, and 900 bps for data. Decades later, Icom quietly slipstreamed the ability to use almost the entire 4800 bps data stream for data - I think they called it DV Fast Data. But that was way too late, and only a handful of D-Star radios incorporated it, so data over D-Star is de facto limited to 900 bps if you want any data interoperability between D-Star radios.
* System Fusion data is a self-inflicted tragedy. Yaesu correctly set up System Fusion so that its (9600 bps?) data stream could be all digital voice (high quality), 50% digital voice (reasonable quality) / 50% data, or all data. BUT... Yaesu deliberately crippled data capability in the SF radios to only allow IMAGES to be transmitted via SF data, and perhaps a trickle of APRS. You cannot attach a System Fusion radio to a computer to use it like a modem... because Yaesu said you can't do that. I've asked Yaesu folks numerous times why... and no one would answer, only "that's the way it's set up". So System Fusion is, to me a sad lost cause in the world of Amateur Radio data communications.
* NXDN, P25, Tetra... those may have data capabilities, but they're so obscure in Amateur Radio that I haven't bothered to investigate.
And, truth be told, once I discovered how well specified M17 was specifically for Amateur Radio (uses callsigns in the headers!) including being able to be used for data, I stopped actively considering all the other digital voice systems. What really nailed down my decision to stop considering DMR, D-Star, System Fusion, etc. for data was discovering the work of Jonathan Naylor G4KLX on the MMDVM-TNC data mode that could run on all existing MMDVM hardware - that's 9600 bps minimum, with integral Forward Error Correction.
I had bought a nice DMR mobile radio a couple of years ago, and it's never been out of the box. I'll soon be reselling it as new in box because at this point in my life, if I'm going to go to the trouble of beginning to use digital voice in Amateur Radio, with the choice of M17 and MMDVM-TNC, I'm going to go with those more interesting and promising options.
“there are many subscribers who (per Substack’s metrics) never seem to “engage” with Zero Retries - never or very rarely open / read it”
If a reader is using an email client with settings focused on privacy, I wonder how Substack can provide accurate stats on which emails have been read? It’s something like the challenges facing opinion pollsters these days. Of course the other stats should be pretty solid, but from my own behavior I know that I read many more articles than I comment on or click “like”.
Craig - Thanks for that reality check. You're right, of course, and if you read ZR in your email client (like, I'm imaging text-only Pine or whatever) and you don't click or load a URL or a photo, etc. then I don't see how you could show up on Substack's metrics. So what I'll probably end up doing is if, Gosh Forbid, I have to move groups of subscribers manually, I'll prioritize the ones that are most active, and work my way through all 2300+.
That does sound daunting. It might be an opportunity for a trusted friend or assistant to lend a hand. Regarding the information available to Substack, I use the standard Gmail client, but it doesn’t load any images in an email unless I click the prompt to approve it (or have clicked the option to always load images from that sender).
Just a thought on multicast file distribution systems. There is a class of algorithms called erasure codes that take some chunk of data, run a transformation on it to break it up into blocks (the total size somewhat more than original.) Then a receiver need only receive K out of N blocks that were produced by the encoding algorithm to compute the original data. This sort of thing is used at small scale with Reed-Soloman coding and at large scale for storing files. Professionally, we used a product like this which would ingest files, generate blocks that were then stored at multiple geographically dispersed locations. By tuning K and N, you would get disaster recovery and the system overall in managing all the metadata was very scalable.
The application for amateur radio beacons and the like is to just transmit blocks and the receiver can start receiving them at any time and eventually reconstruct the original object. Some research reveals some commerical work for such a thing to be deployed on unidirectional broadcast satellite links where a reverse channel to ask for "fills" wasn't available. Missing a block means you don't have to wait for that one block to be retransmitted to you much later; you might still reconstruct the object sooner.
There appear to be some open-source libraries to do this encoding and decoding computation and that would then need a UI and data transport interface wrapped around it. This sounds like a great opportunity for combine ham radio and thesis work for the right person :-)
Really enjoy Zero Retries, thanks!
Louis - Thanks for contributing this and I'll mention it in next week's Zero Retries Part 2 of the repeater article. I don't know that flamp uses this sophisticated an algorithm, but with cheap compute power like Raspberry Pi, and an open source library, there's no reason something could be implemented to use erasure codes. There was an older implementation of the same idea called RadioMirror (that is now out of date and I'll guess lost to history - querying DLARC got no hits), and as that was explained to me, it was a very simple "transmit numbered blocks of a file, with a checksum" and if a block was received with a bad checksum, the "fill" was to merely to wait for the next time that block was transmitted and hopefully that block will be received with a correct checksum. It seems that this technique could be vastly improved with the "bit flipping" testing that's the secret to success of DIRE WOLF being able to decode more packets than hardware TNCs, and the use of Forward Error Correction, especially IL2P.
As someone who has experimented with multimode repeaters and hotspots for years, I do see a lot of potential for adding data capabilities to FM repeaters. I already have a test system running 5 modes using a MMDVM (currently on a dummy load until I get an antenna up and the paperwork sorted). The system cleanly switches modes, and having data modes alongside the voice modes (including FM) would be neat.
I also have extreme demands on VHF/UHF antennas from monitoring multiple frequencies to supporting APRS and intending to run some sort of data service. Being able to aggregate data services, including repeaters that can receive data such as APRS payloads over M17 or MMDVM-TNC, while transmitting traffic from remote Internet stations would be neat.
An additional factor here is the terrain lends itself to a lot of "hidden station" issues on simplex, which duplex should mitigate, especially when the repeater output isn't tied up with other traffic..
Lots of experimentation ahead, and I'm looking forward to having a play.
Tony - Thanks for the report, from "them that's doing", on multimode repeater operation using an MMDVM. All that unused airtime, from all the repeaters that are allocated "priority" spectrum and channel time, just seems like a great opportunity for applying data communications.
Steve, just to clarify, current multimode operation is voice at this stage. AFAIK, the MMDVM doesn't yet have the capability to do the things I'd like to do, like insert data bursts in a mode different to the current mode between overs (POCSAG might be an exception), or receive modes different to that currently in use for voice.
One thing people tend not to think about is that the repeater's receiver is available for local signals when a transmission is coming in via the Internet (I've made use of that to switch M17 reflectors when on a busy reflector). Being able to make use of that capability for both store and forward data locally and injecting data into Internet connected networks could lead to more useful capabilities.
Even using current hardware with updated firmware offers a lot of possibilities we haven't explored yet.
I would like to say ‘Thank You’ for sending the newsletter to your subscribers regularly. Many of the topics that you write about are outside my current radio sphere and that is what keeps this newsletter interesting to me.
Sandip - Thanks, but MOST of what I write about in Zero Retries is also outside MY current radio sphere... but I remain fascinated by all the technological innovation that IS occurring in Amateur Radio and adjacent areas. When I began Zero Retries, I wasn't sure how much interest there was in this stuff. I only knew of perhaps 100 with similar interests such as a handful of friends in the Seattle area, another handful online, and the demonstrated interest of those that went to the trouble and expense of attending Digital Communications Conferences (before they began to move online).
Thus it's an absolute delight that 2300+ readers now subscribe to Zero Retries to follow along and "conspire", like me, to do more interesting things in our individual Amateur Radio activities, beyond the "same old, same old" modes and activities.
I read through this article quickly, "Explaining the Use Case for Data Over Repeater - Part 1." I will have to go back and reread it as there is a lot of information, and I particularly want to re-read your comments on FLDIGI and FLRAMP for a project that I have in mind. However, one of your comments stood out
"All of this would be much easier explained in an interactive block diagram, which I intend to do eventually. I have not yet spent time learning how to instruct an AI like ChatGPT to create such diagrams, even videos, but that’s on my long to-do list."
I wrote a post on doing this
https://kd2wll.winstonlawrence.us/radios_and_technology/ai_and_amateur_radio_applications.html (direct link because it's still draft)
One of the things we should be considering about taking repeaters and using them for more than voice is the idea of share time slots or monitoring all of the output of a repeater and a data stream and just use the mode/portion of the data stream that interests you. This could be BOTH voice and data.
DMR repeaters are the generic name of the Motorola MotoTurbo commercial product. This was introduced when the FCC started the narrowanding requirement from 25 KHz channels to the 12.5 KHz channels with another step to 6.25 khz channels or an equivalent of two separate 6.25 khz channels. DMR in the commercial bands has two time slots allowing two channels/voice streams or voice/data mixed mode stream. So today on the public service band DMR meets the 6.25 KHz standard because it can do two channel equivalent on a 12.5 KHz channel. The data stream is running through the repeater and the radio listens to one of the two time slots for the conversation desired. In the ham bands we never were required to move to the narrow 12.5 KHz channels. So for simplistic arguments sake we have two 12.5 KHz channels available on a repeater pair that each could have two time slots. Many private MotorTurbo systems on the commercial bands have just one voice channel but they use the second time slot for data. This data does not hinder the voice communications nor is it even heard on the voice channel. So that is was example to explain how one could use a repeater for both voice and data. Since they are all 25 KHz channels the channel could either be wider or you could create two voice channels and 2 different data channels. I don't believe the DMR protocol allows for this currently but it illustrates the concept. This of course does nothing to allow for traditional analog voice that we are so accustomed to today. But if we had radios that could read the whole maximum possible data stream on what an analog voice repeater is capable of today, you get an idea of what is possible.
Another more basic concept of how to you existing voice repeaters for data would be to allow data to use the repeater but without transmitting the PL tone on the data output of the repeater. So users of the data could still be receiving the data bursts but regular voice users would not have to listen to the data. The data protocol would be set such that if a voice user wants to use the repeater it would take priority and forced the data users to hold off and only continue to move the data when there are no active voice users on the repeater. On busy voice repeaters that would mean the data is not the fastest and during busy voice periods for a repeater that data would not be moving. But the rest of the time the repeater is otherwise dormant data could be moved and the users would not hear it on their radios. One of the downsides to this would be that the repeater transmitter might be used and keyed up a lot more than normal. If the transmitter PA on the repeater was not built for a much higher transmit and receive duty cycle, that would have to be mitigated or this could only be done on repeaters that are built for high duty cycles.
Looking at either of these concepts in this way one can start to understand what we are talking about with the idea of using otherwise underutilized resources. It would also not but much of a stretch to link the data between any of these repeaters and allow the digital data to be shared or routed over larger geographic areas.
See my "new" comment for detailed reply. Substack seems to have borked this reply function to limit it to a few lines.
Brian - Good points all. I'll be exploring these ideas and more in the future article in ZR.
For MOTOTRBO repeaters and radios, there IS a data capability to use one (or both?) of the two slots for data... but that seems proprietary to MOTOTRBO radios - requiring MOTOTRBO radios and software that communicates just with MOTOTRBO radios. Hytera did the same thing. But I haven't seen anything equivalent for "generic" DMR repeaters and radios, so I'm guessing that there may be some Amateur Radio experimentation necessary to enable that capability, perhaps an enhancement of the DMR mode that's implemented in MMDVM.
Yes, data over conventional FM repeaters works, and can work well, but in my (admittedly limited) experience to date, the biggest issue of using data over a voice repeater is that it's a continuing "Mother, May I?" issue with the user base / owners of those repeaters to use data. While they give lip service to the idea of experimentation with data, they don't want to offer "blanket permission" for data use sufficient to make the data capability truly usable (and reliable). Thus we get into the absurd situation of actively considering the creation of NEW repeaters that can be dedicated to "data first" usage... while existing repeaters continue to sit idle 99% of the time.
And agreed, the duty cycle could theoretically be an issue, but probably no more than some voice nets that can go for an hour or more of continuous use. Certainly any new repeater that's set up for data use would be prudent to set it up for enduring high duty cycles.
I also had to add a new comment rather than reply to this one.
MOTOTURBO is just the brand name for DMR. Currently the amateur radio DMR community has decided the both time slots will be for voice. There is no reason that a stand alone DMR repeater that is not linked in to the various larger system could not be set up for data on one time slot and voice on the other. I may be mistaken but most DMR repeaters are also set up to be 12.5 KHz channels. I don't think you can get any of the commercial repeaters that have been used for amateur use to do the 25 KHz bandwidth. But sometimes I know just enough to be dangerous. I was disappointed years ago as I saw the adoption of DMR in to amateur and the ecosystem did not embrace using a time slot for data. That was likely done to appease the mentality of many to the idea I don't want to have the repeater tied up all of the time on linked conversations when we just want to talk locally. Assigning both time slots for voice kept both crowds happy. Can you imagine if ALL of the linked DMR systems assigned on time slot to data? If we could convince the DMR repeater operators and link systems to do that it could be an interesting transition of the DMR variety. DSTAR had simultaneous data and voice use built in to that protocol as well. I am not sure what System Fusion offers. We have a RACES repeater that is seldom used that is DMR capable. I am going to dig deeper in to what I might be able to do with this, possibly go full DMR on this one and set a time slot up for data only.
Brian - Disclaiming that I haven't made a very deep, or recent study of this... when I tried to understand if DMR could be used for data (it's a digital modulation, so why not use the bitstream to transmit unstructured data instead of a digital voice data stream)? My limited study of the DMR standard available from ETSI showed that there was some thought given to data over DMR - there do seems to be hooks (flags, protocols) etc. in the spec... but my (again, inexpert) conclusion was that while the spec was rock solid to insure interoperability of DMR voice between various manufacturers - in the radios, in the repeaters, etc., there was not the same rigor applied to insuring interoperability of data over DMR. Thus it was left to the vendors to create effective data over DMR, which they did... following their profit motive in the absence of demonstrated demand for interoperability between manufacturers of data over DMR.
Motorola did data over DMR that worked - over MOTOTRBO, and Hytera did data over DMR that worked on Hytera radios. So even if we could agree to reserve one of the two DMR time slots for data, it would be a long slog to develop a new open source's DMR radio that could do data - that doesn't infringe on Motorola or Hytera's methods of data over DMR. Maybe we could, develop Amateur DMR, and while we're at it, replace the DVSI CODEC with CODEC 2...
Oh wait - we just spec'ed out M17 😀 which does do digital voice and data equally well, including using CODEC 2, not DVSI's CODEC.
And, briefly, digital voice systems in Amateur Radio data capabilities:
* Icom's implementation of D-Star is the de facto standard now, and when they introduced D-Star, Icom "hard partitioned" D-Star's 4800 bps data stream into 2400 bps for the digital voice, 1200 bps for voice FEC, and 900 bps for data. Decades later, Icom quietly slipstreamed the ability to use almost the entire 4800 bps data stream for data - I think they called it DV Fast Data. But that was way too late, and only a handful of D-Star radios incorporated it, so data over D-Star is de facto limited to 900 bps if you want any data interoperability between D-Star radios.
* System Fusion data is a self-inflicted tragedy. Yaesu correctly set up System Fusion so that its (9600 bps?) data stream could be all digital voice (high quality), 50% digital voice (reasonable quality) / 50% data, or all data. BUT... Yaesu deliberately crippled data capability in the SF radios to only allow IMAGES to be transmitted via SF data, and perhaps a trickle of APRS. You cannot attach a System Fusion radio to a computer to use it like a modem... because Yaesu said you can't do that. I've asked Yaesu folks numerous times why... and no one would answer, only "that's the way it's set up". So System Fusion is, to me a sad lost cause in the world of Amateur Radio data communications.
* NXDN, P25, Tetra... those may have data capabilities, but they're so obscure in Amateur Radio that I haven't bothered to investigate.
And, truth be told, once I discovered how well specified M17 was specifically for Amateur Radio (uses callsigns in the headers!) including being able to be used for data, I stopped actively considering all the other digital voice systems. What really nailed down my decision to stop considering DMR, D-Star, System Fusion, etc. for data was discovering the work of Jonathan Naylor G4KLX on the MMDVM-TNC data mode that could run on all existing MMDVM hardware - that's 9600 bps minimum, with integral Forward Error Correction.
I had bought a nice DMR mobile radio a couple of years ago, and it's never been out of the box. I'll soon be reselling it as new in box because at this point in my life, if I'm going to go to the trouble of beginning to use digital voice in Amateur Radio, with the choice of M17 and MMDVM-TNC, I'm going to go with those more interesting and promising options.