Why no DMR2YSF users are being heard anymore, and how to get around it

General support for the Pi-Star System
Post Reply
AD8DP
Posts: 8
Joined: Mon Sep 09, 2019 4:58 pm

Why no DMR2YSF users are being heard anymore, and how to get around it

Post by AD8DP » Tue Sep 17, 2019 2:49 am

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 about this 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 H5000 in this example. A great explanation of the Yaesu radio ID format is detailed in this document from K9EQ:
http://www.hamoperator.com/Fusion/Fusio ... cation.pdf

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)
  • cd MMDVM_CM (enter source dir)
  • 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:
http://www. removed.

AE5JO
Posts: 18
Joined: Thu Feb 07, 2019 2:30 am

Re: Why no DMR2YSF users are being heard anymore, and how to get around it

Post by AE5JO » Sun Sep 22, 2019 8:56 pm

I can see where random radio ID may cause issues in the future if someone else already has a radio with that ID. Yaesu already uses the radio ID to control repeaters and some DM functions. I expect in the future they will utilize the radio IDs for call routing for radio to radio QSOs and this practice is likely to interfere should there be duplicate radio IDs in the WIRES-X network. All is not fair with closed repeater systems and I think that is how WIRES-X would be considered should independent development cause issues with the system and Yaesu put their foot down.

User avatar
MW0MWZ
Site Admin
Posts: 917
Joined: Wed Apr 04, 2018 9:15 pm
Location: Wales, UK
Contact:

Re: Why no DMR2YSF users are being heard anymore, and how to get around it

Post by MW0MWZ » Sat Sep 28, 2019 8:55 am

Replying here and I have also replied to your e-mail (thank you), as I have said each time this comes up, the very best route forwards is to submit pull requests to Jonathan (G4KLX) and Andy (CA6JAU) for these changes, that way *everyone* will get them, Pi-Star supports the huge effort that goes into all of this software and uses the repositories of the originating developers, and while we encourage the work you are doing and appreciate the effort you put in, it is unlikely that we will diverge from the original repositories.

So, the very best thing to do, once you know your patches are stable and don't cause issues outside of your intended changes (and from the brief look I have taken they wont) then submit the patches up-stream.

If you don't have time for this - let me know and I will see if I can submit your work upstream for you.
Andy

73 de MW0MWZ
http://pistar.uk

WX0MIK
Posts: 1
Joined: Sat Aug 10, 2019 1:14 am

Re: Why no DMR2YSF users are being heard anymore, and how to get around it

Post by WX0MIK » Tue Nov 19, 2019 12:56 am

Has anything else been done with this in pi-star? I am running into this issue which trying to join a Fusion net. I didn't know why until now. I think this makes sense because some can hear me and some can't.

AD8DP
Posts: 8
Joined: Mon Sep 09, 2019 4:58 pm

Re: Why no DMR2YSF users are being heard anymore, and how to get around it

Post by AD8DP » Tue Dec 10, 2019 1:49 am

Right now the only option available is for you to apply the software changes manually.

Post Reply