DUDE-Star (RX) projects and hack fix for Pi-Star DMR->YSF

Discussion in 'Digital Radio, DMR, Fusion, Wires, DSTAR' started by AD8DP, Sep 9, 2019.

ad: L-HROutlet
ad: l-rl
ad: QSOToday-1
ad: Left-3
ad: abrind-2
ad: Subscribe
ad: L-MFJ
ad: Left-2
  1. AD8DP

    AD8DP Ham Member QRZ Page

    Howdy Hamsters,

    I have been working on a cool project lately for digital modes. I call it DUDE-Star, which is a combination of software and hardware of my design, to RX and TX various digital modes, both over the Internet and ultimate over RF using, for example, an old analog radio with a packet radio interface or access to the discriminator (RX) and RF Amp (TX). I have created a software only version of all this for monitoring various modes, which I call DUDE-Star RX. My primary development platform is Linux, which the source code was written on. I have included a Windows executable at Github as well, and there is an android version of this on the Google Play store called DROID-Star. The links and more info can be found at my QRZ page.

    While working on Fusion TX support, I struggled with an issue where my transmissions would only be heard by people connected directly to the same YSF reflector as me, and would be rejected by Wires-X and not reach any users and repeaters on the other end of these nodes. After resolving this issue I learned that the same issue exists for hamsters that use the MMDVM based hotspots like Pi-Star to transmit to Fusion reflectors with a DMR radio. The software that interacts with MMDVMHost to do this is called DMR2YSF. I studied the source code for this software to learn how to add Fusion TX ability to my gadget, so it was no surprise to me that my gadget suffered from the same problem as the DMR2YSF users. From what I have been told, this is a relatively new issue, and appeared with some recent updates to the Wires-X server software.

    The issue is that with this new version of the Wires-X server software being used out there, the server will reject Fusion Internet frames that are not sent with a CM (Call Mode) of 1 (RadioID mode) in the FICH (Frame Info CHannel). This mode requires that a Yaesu Fusion Radio ID be correctly defined in the Internet frames. The diff file referenced below shows the changes I made to the DMR2YSF source code that, when built and used in place of the stock DMR2YSF executable binary, allows DMR users to be heard across Wires-X nodes and out repeaters, over RF, etc.

    It should be understood that this is not really a 'fix', because that implies that something is wrong with the existing software. This can better be described as a mod or a hack. This works by sending a bogus radio ID over the internet to trick servers into thinking that the TX originates from a real Fusion radio. Is it appropriate to do this? My position on this subject is that in ham radio, anything goes. The basis for this hobby is experimentation, reverse engineering, hacking, tinkering, and so on. I have no interest in the feelings of any major corporation like Yaesu, in the event that they disagree. That being said, here is a step-by-step procedure on how to apply this 'hack' to a pi-star. I use a made up radio ID of H0000 in this example. A great explanation of the Yaesu radio ID format is detailed in this document from K9EQ:

    The text below is from a ssh session where I log in and perform the following steps. Notice that I make a copy of the stock executable that I replace, so that the system can be restored to stock very easily if desired. The software chages are provided as a diff file (for differences) that I uploaded to my own web server, and download with the wget command. It is applied to the stock source code with the 'patch' command:
    • rpi-rw (creates read-write filesystem)
    • mkdir src (make a new dir called 'src' where I will download the source code and build)
    • cd src (enter this directory)
    • git clone https://github.com/juribeparada/MMDVM_CM.git (pull source from github)
    • cd MMDVM_CM (enter source dir)
    • wget http://www.dudetronics.com/radio/dmr2ysf.diff (download my software patch)
    • patch -p1 < dmr2ysf.diff (apply patch to source code)
    • cd DMR2YSF (enter DMR2YSF source dir, we dont need the other programs in this github repo)
    • make (build the software)
    • sudo mv /usr/local/bin/DMR2YSF /usr/local/bin/DMR2YSF.bak (backup stock binary)
    • sudo cp DMR2YSF /usr/local/bin (copy new binary to the system)
    Reboot the pi-star after this, and you should be good to go. You can view the diff file to see the C++ code changes here:

    The text below is the entire process from a Linux terminal. All text inputted by me is bold:
    $ ssh -lpi-star x.x.x.x
    pi-star@'s password:
    Linux pi-star 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l

    The Pi-Star Dashboard can be found at one of the following locations:
    http://pi-star/ http://pi-star.local/ http://2601:406:5100:4f70::26/

    Pi-Star's disk is read-only by default, enable read-write with "rpi-rw".
    Pi-Star built by Andy Taylor (MW0MWZ), pi-star tools all start "pistar-".

    Welcome to Pi-Star: v4.1.0-RC4

    Last login: Mon Sep 9 12:28:08 2019 from
    pi-star@pi-star(ro):~$ rpi-rw
    pi-star@pi-star(rw):~$ mkdir src
    pi-star@pi-star(rw):~$ cd src
    pi-star@pi-star(rw):src$ git clone https://github.com/juribeparada/MMDVM_CM.git
    Cloning into 'MMDVM_CM'...
    remote: Enumerating objects: 8, done.
    remote: Counting objects: 100% (8/8), done.
    remote: Compressing objects: 100% (8/8), done.
    remote: Total 642 (delta 0), reused 0 (delta 0), pack-reused 634
    Receiving objects: 100% (642/642), 1.09 MiB | 3.08 MiB/s, done.
    Resolving deltas: 100% (454/454), done.
    pi-star@pi-star(rw):src$ cd MMDVM_CM
    pi-star@pi-star(rw):MMDVM_CM$ wget http://www.dudetronics.com/radio/dmr2ysf.diff
    --2019-09-09 14:07:36-- http://www.dudetronics.com/radio/dmr2ysf.diff
    Resolving www.dudetronics.com (www.dudetronics.com)...
    Connecting to www.dudetronics.com (www.dudetronics.com)||:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 3932 (3.8K) [text/x-diff]
    Saving to: ‘dmr2ysf.diff’

    dmr2ysf.diff 100%[============================================================================================================================>] 3.84K --.-KB/s in 0.001s

    2019-09-09 14:07:37 (5.23 MB/s) - ‘dmr2ysf.diff’ saved [3932/3932]

    pi-star@pi-star(rw):MMDVM_CM$ patch -p1 < dmr2ysf.diff
    patching file DMR2YSF/DMR2YSF.cpp
    patching file DMR2YSF/YSFFICH.cpp
    patching file DMR2YSF/YSFFICH.h
    pi-star@pi-star(rw):MMDVM_CM$ cd DMR2YSF
    pi-star@pi-star(rw):DMR2YSF$ make
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o BPTC19696.o BPTC19696.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Conf.o Conf.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o CRC.o CRC.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRLookup.o DMRLookup.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMREMB.o DMREMB.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMREmbeddedData.o DMREmbeddedData.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMR2YSF.o DMR2YSF.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRFullLC.o DMRFullLC.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o MMDVMNetwork.o MMDVMNetwork.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRLC.o DMRLC.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRSlotType.o DMRSlotType.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRData.o DMRData.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Golay2087.o Golay2087.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Golay24128.o Golay24128.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Hamming.o Hamming.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Log.o Log.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o ModeConv.o ModeConv.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Mutex.o Mutex.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o QR1676.o QR1676.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o RS129.o RS129.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o StopWatch.o StopWatch.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Sync.o Sync.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o SHA256.o SHA256.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Thread.o Thread.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Timer.o Timer.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o UDPSocket.o UDPSocket.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o Utils.o Utils.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFConvolution.o YSFConvolution.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFFICH.o YSFFICH.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFNetwork.o YSFNetwork.cpp
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o YSFPayload.o YSFPayload.cpp
    g++ BPTC19696.o Conf.o CRC.o DelayBuffer.cpp DMRLookup.o DMREMB.o DMREmbeddedData.o DMR2YSF.o DMRFullLC.o MMDVMNetwork.o DMRLC.o DMRSlotType.o DMRData.o Golay2087.o Golay24128.o Hamming.o Log.o ModeConv.o Mutex.o QR1676.o RS129.o StopWatch.o Sync.o SHA256.o Thread.o Timer.o UDPSocket.o Utils.o YSFConvolution.o YSFFICH.o YSFNetwork.o YSFPayload.o -g -O3 -Wall -std=c++0x -pthread -lm -lpthread -o DMR2YSF
    pi-star@pi-star(rw):DMR2YSF$ sudo mv /usr/local/bin/DMR2YSF /usr/local/bin/DMR2YSF.bak
    pi-star@pi-star(rw):DMR2YSF$ sudo cp DMR2YSF /usr/local/bin
    Last edited: Sep 9, 2019
    K4YNZ and AF6IF like this.
  2. N8PWM

    N8PWM XML Subscriber QRZ Page

    Good morning! First, thank you for your work on this project. I am trying to install the patch and new binary however, I am running into an issue. I have included the outputs below from the session. Any help you can provide would be greatly appreciated.

    Pi-STAR VERSION: 3.4.17

    pi-star@pi-star(ro):~$ rpi-rw
    pi-star@pi-star(rw):~$ mkdir src
    pi-star@pi-star(rw):~$ cd src
    pi-star@pi-star(rw):src$ git clone https://github.com/juribeparada/MMDVM_CM.git
    Cloning into 'MMDVM_CM'...
    remote: Enumerating objects: 8, done.
    remote: Counting objects: 100% (8/8), done.
    remote: Compressing objects: 100% (8/8), done.
    remote: Total 642 (delta 0), reused 0 (delta 0), pack-reused 634
    Receiving objects: 100% (642/642), 1.09 MiB | 1.86 MiB/s, done.
    Resolving deltas: 100% (454/454), done.
    Checking connectivity... done.
    pi-star@pi-star(rw):src$ cd MMDVM_CM/
    pi-star@pi-star(rw):MMDVM_CM$ wget http://dudetronics.com/radio/dmr2ysf.diff
    --2019-09-21 09:24:42-- http://dudetronics.com/radio/dmr2ysf.diff
    Resolving dudetronics.com (dudetronics.com)...
    Connecting to dudetronics.com (dudetronics.com)||:80... connected.
    HTTP request sent, awaiting response... 301 Moved Permanently
    Location: http://www.dudetronics.com/radio/dmr2ysf.diff [following]
    --2019-09-21 09:24:43-- http://www.dudetronics.com/radio/dmr2ysf.diff
    Resolving www.dudetronics.com (www.dudetronics.com)...
    Reusing existing connection to dudetronics.com:80.
    HTTP request sent, awaiting response... 200 OK
    Length: 5444 (5.3K) [text/x-diff]
    Saving to: ‘dmr2ysf.diff’

    dmr2ysf.diff 100%[=======================================================================================================================>] 5.32K --.-KB/s in 0s

    2019-09-21 09:24:43 (15.1 MB/s) - ‘dmr2ysf.diff’ saved [5444/5444]

    pi-star@pi-star(rw):MMDVM_CM$ patch -p1 < dmr2ysf.diff
    patching file DMR2YSF/DMR2YSF.cpp
    patching file DMR2YSF/YSFFICH.cpp
    patching file DMR2YSF/YSFFICH.h
    pi-star@pi-star(rw):MMDVM_CM$ cd DMR2YSF/
    pi-star@pi-star(rw):DMR2YSF$ make
    g++ -g -O3 -Wall -std=c++0x -pthread -c -o BPTC19696.o BPTC19696.cpp
    g++: internal compiler error: Segmentation fault (program cc1plus)
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
    Makefile:19: recipe for target 'BPTC19696.o' failed
    make: *** [BPTC19696.o] Error 4
  3. N8PWM

    N8PWM XML Subscriber QRZ Page

    Got it. I needed to be on the RC version of Pi-Star. Works great! Thanks for the work on this.
  4. K9EQ

    K9EQ Ham Member QRZ Page

    FYI the behavior of the WiRES-X rooms has not changed recently. There have always been problems with hotspots and the like throwing bad data into the WiRES-X rooms and causing problems. To get around this I've had to produce a version of the YSF reflector that closely examines the contents of each packet to determine if retransmission should be permitted. Without these changes, the YSF reflector pretty much takes 155 bytes of anything and blows it out to all the connections.

    98% of the problems I've had running a YSF reflector have been from hotspots and the like throwing junk into the data stream. These is a result of bad software, bad configuration of the hotspot, and bad operators.

    The advantage of not allowing hotspots is that WiRES-X is a well defined and maintained system and all of its system components work well together. The farther Fusion strays from that system, the more problems there are going to be.

    It is essential that the operator of a popular room/reflector have the ability to filter individual sources to prevent one hotspot from taking down the network. (The other option is to isolate the hotspot network from the WiRES-X network.)

    Also its best if problem detection occurs automatically because NOBODY wants to monitor a room/reflector 24x7 waiting for trouble.

    In the past 9 months I've had to deal with:
    1. A Dude-star transmitting garbage continuously for over three hours. A buzzing noise was heard. Turns out these packets normally would have been dropped, but I had a configuration error on this reflectors incoming filters.

    2. Bridging of my network to Alabama Link without any way of figuring out who was doing it. (The YSF reflector now has even more diagnostic logging that allows me to nail down the source of troubles even if I'm not around to see it.)

    3. Bridging of my network to America Link (three times)

    4. Bridging of my network to Alabama Link (again).

    5. Network feed back where someone else, besides me, though it would be a good idea to do their own bridging.

    6. An MMDVM repeater that responded to the same WiRES-X commands that it's HRI-200 WiRES-X was responding to resulting in another feedback loop that made the network completely useless.

    At issue is that this "hotspot" system is not architected. It's just thrown together. That's fine for Ham stuff, but what we're seeing is that other peoples thrown-together stuff is causing harm to innocent networks. The problem is made worse because most of the software is poorly written, is not documented, and has no well defined APIs, and the testing is inadequate to catch many problems.

    Because of the lack of defined APIs and a system architecture, it is impossible for me as a YSF reflector operator to know anything about the source of the incoming data. This has forced me to go to extreme measures to filter some of these sources. I'd much prefer a mechanism where I could easily identify the source equipment, configuration, and operator. Many of the times when these issues occur, my only hope of contacting the offending stations is via QRZ. And it's not guaranteed I can get a callsign since I see gateway identifiers such as "BM-Bridge", and "REFLECTOR". So the station that's transmitting (and I have his callsign) most likely has nothing to do with the source of the problem. My general response is to ban the IP address (if nothing else is known) and also ban the callsign and/or gateway name. This is way too much work and it isn't at all fun.

    Yaesu Fusion has features that DMR doesn't have - such as transmitting callsigns instead of unit numbers. The issue with bridging to non-Yaesu radios is that we have to sink to the lowest common denominator of the radios used. (The bottom of the pit being FM.) It is critically important that people bridging DMR to Fusion be respectful of how Fusion and WiRES-X works! Don't just slam stuff together, give it a kerchunk, and call it good.

    Yaesu uses a unique transmitter ID for each radio made. I call it TxID, Yaesu calls it DG-ID. THIS is what WiRES-X uses to manage radios on the network. WiRES-X and Fusion doesn't care at all which callsign you've programmed in. (Dstar did and thus have a problem where you can't have two repeaters with the same callsign.) Since Fusion uses a unique ID, you can have an unlimited number of radios and repeaters using the same callsign.

    This TxID also provides the network with information regarding which model of radio is being used. This information is useful because it also provides the capabilities of that radio.

    The TxID is also handy if your Yaesu radio ever gets stolen. If the stolen radio shows up on a monitored network, BANG, we know where it went and (hopefully) the callsign of the station using it.

    It has been the habit of people writing software to bridge modes to make up a TxID and this program that into the transmitted stream. AD8DP mentions his use of H0000 which, BTW, is an invalid TxID but I'm not complaining.

    Regarding my previous comments on the lack of system engineering and design, there has never been a discussion about how TxIDs should be assigned to hotspots and other things doing DMR/D*/P25 translations to Fusion. Perhaps there should be and perhaps they should meet the original intent of Yaesu assigning unique TxIDs to each of their radios.

    As a network and reflector operator one of my goals is to determine if the source of a transmission is from a Fusion radio or if it is being generated without a radio (Dude Star) or via another type of radio. The reason I want to do this is because I want to be able to filter these sources. Although they shouldn't, most DMR radios sound awful. They also can't handle Yaesu's VW voice mode - they just hear a silence. (BTW if you want to do DMR and Fusion with one radio, buy a Yaesu. It doesn't everything DMR can do plus a lot more.)

    What can sound even worse than DMR is a cell phone. The microphones in cell phones ARE NOT noise cancelling communication quality microphones! The best microphone for something like Dude Star is a Blue Parrot Bluetooth headset. Often the mic gain is too high or the mic is too sensitive so one hears echos off the building's walls or chatter/TV in the background.

    I might seem a bit harsh, but WiRES-X and Fusion works nicely. Yes, we have our problems but they are manageable. But things can quickly get out of control with this huge influx of new connection solutions. Those of us who listen to WiRES-X networks can get a little tired of a constant stream of badly adjusted end-points. A lot of the Fusion users are not all that interested in helping DMR and Android users get their bugs worked out. A couple is fine, but WiRES-X IS NOT a hotspot/DMR focused network.

    These solutions have advantages. I've always liked the idea of hotspots because they allow hams to easily travel and stay in touch with the folks back home. They are also handy as it allows an individual to snoop around without tying up a local repeater. That's al good. But we're not looking at six or seven DIFFERENT "hotspot" networks capable of bridging to each other and Fusion. And the more stuff that gets added, the more problems there will be. Hence my desire to support YSF as the only hotspot network that WiRES-X bridges to and to not permit additional bridging.

    I also have a fundamental issue with not using a radio at all. I'm okay with the networking and all. Having an HT that talked to a hotspot was okay, especially because it did not color the transmissions and they remained faithful to the system's specification. However a non-RF solution is problematic. It seems like a stretch to me anytime you are not required by the FCC to use your callsign to talk on the radio. Using Android should not be your primary entry into the world of Amateur Radio. You should at least have to buy a damn radio!

    In the case of Dude Star I request that AD8DP give me some way to filter it and to uniquely identify each installation and associate it with a callsign. Note: I don't want to filter it, I'd rather do nothing. But I can see trouble on the horizon as this grows in popularity.

    Forcing the use of an amateur radio callsign and associating it with a specific installation of Dude-Star would allow me to track down sources of trouble and deal with them. If that doesn't work, then I flip the switch to ban Dude-Star.

    I can only talk about YSF reflectors and Fusion and Dude Star does a lot more than that. But I'd be happy to discuss with AD8DP, if willing, to open a discussion with the goal of developing an acceptable API between Dude-Star and YSF. Hopefully an iOS version will be available at some point and Dude Star can exist within the ecosystem without people like me having to spend unplanned Friday afternoons figuring out how to keep the network working.

    Chris, K9EQ
    N5HXR and K4YNZ like this.
  5. K4YNZ

    K4YNZ XML Subscriber QRZ Page

    Hummm. Seems like to build and write DUDESTAR you must follow the WiRES-X standard or rules. the unique transmitter ID is a challenge. I'm a radio or RF guy. To work in digital cellular I had to learn the standard. It was divided into layers. So you got to get each layer to work within the Wires-X standard. This will make Chris K9EQ and other trustees very happy. Even better you look like a pretty smart guy. It looks like this is within your skill set!
    Now if you do not follow the standard you should not be allowed to access. That is only logical.
    So each transmitter should TX an ID. You still need to use call signs on DIGITAL. I grew up in radio. Even the police and fire would ID on the hour.
  6. K4IHI

    K4IHI Ham Member QRZ Page

    I have enjoyed a lot of success hooking my D710 up to my PC and using DSD+ to decode all sorts of digital modes. I'm now curious about encoding and sending the encoded digital back into the D710 for transmit. DUDE-Star looks like it has the technology needed to accomplish this, but is focused on tunneling to reflectors out via the internet like a hotspot versus passing the encoded audio back out to an audio output to feed to the radio. Any advice for how I could accomplish this?
  7. K6EEN

    K6EEN Ham Member QRZ Page

    There was a time about 10 years ago when D-STAR adapters for analog radios with discriminator access for 9,600 baud packet were available, like the "FA-DV 2.0":

    Nowadays, you just buy a cheap DMR HT. Add a 25 watt "brick" external amplifier for working repeaters, or a Pi-Star hotspot if you want to work radio-over-IP (RoIP) reflectors.
    Last edited: Jan 26, 2021 at 11:06 PM
  8. K4IHI

    K4IHI Ham Member QRZ Page

    I have a hotspot but I am interested in my local repeaters. Unfortunately, there is no general consensus in my area for what digital mode is prevalent so I was hoping to loop them through my PC. I know the common path is using an HT or mobile that has a digital mode, but I'd prefer not to have to invest in a radio for each mode. I really like my D710 and having only one VHF/UHF radio to connect to my roof-mounted antenna. Juggling HT+antenna swaps isn't something I've set up but I also don't really look forward to that kind of a requirement.

    Would be super neat if it could be as simple as DSD+ is on the decode side, but for the transmit. Even if I needed to license various digital mode encoders I'd be fine with it. OpenSpot3 uses a vocoder chip to crossmode digital modes but sends it out over the internet instead of out of an audio out that I could plug into the D710. It's *almost* there. Would just like to do the same but going out into a rig that can put it on the air.
  9. K6EEN

    K6EEN Ham Member QRZ Page

    So, you have a digital radio of some sort already, probably a handie talkie? DMR or D-STAR? Buy a 25 watt "brick" amplifier and connect it to your external antenna and start working repeaters.

    This can be fixed with a 2-position coax switch, and a cheap (< $100) analog scanner to monitor the analog repeaters when the coax switch is flipped to the digital radio.

    The local digital repeaters here are either DMR or D-STAR. All of the DMR talk groups that you can access on the repeater are pretty much available as BrandMeister or other (TGIF) internet reflectors, so there's no difference if you go into the repeater over RF or via a HotSpot, because you end up on the same talk groups. For D-STAR, there's not a lot of local chatter on the D-STAR digital repeaters until the repeater is linked to a reflector for a 'net (REF series reflectors, typically), and at that point, you again might as well go into the reflector via the HotSpot rather than over-the-air.

    I have an OpenSpot3, and use it to operate cross-mode on several local (Mountain time zone) weekly digital nets, which these days are all linked to a reflector of some sort. I'm partial to Yaesu, so I have a System Fusion / C4FM radio, but work the DMR and D-STAR weekly digital nets via OpenSpot3.

    If you want, you can link into a D-STAR gateway (internet-connected D-STAR repeater) directly via the OpenSpot3, skipping any sort of reflector. This allows you to hang out on a repeater as you would if you were accessing it over-the-air.
    Last edited: Jan 26, 2021 at 11:48 PM
  10. K4IHI

    K4IHI Ham Member QRZ Page

    I do! But it only covers D-STAR but I also want to get access to DMR, C4FM, P25 repeaters and some of these don't have internet connected talk groups.
    I'll look into this but was worried about losses. One of the repeaters I talk on already I am borderline in the evenings with atmospheric interference. I've already looked at simplifying adapters/passthroughs to get the lowest line losses possible. Already using LMR400. So I'll want to find the highest quality switch I can and hope to minimize line loss/noise.

    I was just kind of hoping I could expand what I've already done with the D710 connections into my PC without having to add additional hardware. Just seemed kind of odd that with so many hotspot projects, there doesn't seem to be much that passes audio back out instead of sending through the internet.

    By the way, thanks for the replies! Really appreciate it!

Share This Page

ad: Alphaant-1