When running pi-star 3.4.17 the following is not an issue, everything works just fine

When I flashed pi-star 4.1.0 and setup YSF2DMR I got the following issues

1. Transmissions from c4fm to dmr worked just fine
2. Transmissions from dmr to c4fm failed. RF was received by the radio but the audio was not decoded.
3. Wires X Pass through was ON
4. I ssh'd into pi-star and edited /etc/ysf2dmr and set EnableWiresX from 1 to 0, restarted ysf2dmr service and the radio came alive with audio, unfortunately wiresX no longer functioned on the radio
5. I reset the EnableWiresX tfrom 0 to 1 and the radio audio stopped.

I toggled this enablewiresx parameter back and forth many times and got the exact same results
Phil VE3RD

g++ -g -O3 -Wall -std=c++0x -pthread -c -o WiresX.o WiresX.cpp WiresX.cpp: In member function ‘CTGReg* CWiresX::findById(unsigned int)’: WiresX.cpp:887:10: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (id == atoi((*it)->m_id.c_str())) ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~

This happens wherever WiresX.cpp is compiled, its only a compiler warning, but needs to be cleaned up.

YSF2DMR is only showing numbers and not updating the DMR ID file. I have made no changes other than the .ini file. How to I correct this? Thank you!

It seems that Yaesu has recently released new server software that broke the DMR2YSF feature of MMDVM based hotspots like Pi-Star. DMR users can no longer be heard across Wires-X links that run this new server software, which is causing all kinds of confusion on various repeaters/reflectors because people have been hearing a lot of one sided conversations lately. I made some changes that overcome this problem, and posted a detailed description of the changes on the QRZ forum. A link to that post can be found on my QRZ page for AD8DP. I wanted to create that post on the Pi-Star forum, but I'm going on day 2 now waiting for manual activation.

My patch simply hard codes everything in the source code as sort of a proof of concept, but I think maybe it could be implemented in a way that would require the end user to specifically enable these changes by way of an ini/conf file which could be accessed by the Expert menu, for example.

diff --git a/DMR2YSF/DMR2YSF.cpp b/DMR2YSF/DMR2YSF.cpp
index ebec9ef..63e0502 100644
--- a/DMR2YSF/DMR2YSF.cpp
+++ b/DMR2YSF/DMR2YSF.cpp
@@ -33,6 +33,9 @@
 const unsigned char dt1_temp[] = {0x31, 0x22, 0x62, 0x5F, 0x29, 0x00, 0x00, 0x00, 0x00, 0x00};
 const unsigned char dt2_temp[] = {0x00, 0x00, 0x00, 0x00, 0x6C, 0x20, 0x1C, 0x20, 0x03, 0x08};
 
+// Added by AD8DP for FICH FT=6 transmissions
+const uint8_t dt1[10] = {0x01, 0x22, 0x61, 0x5f, 0x2b, 0x03, 0x11, 0x00, 0x00, 0x00};
+
 const unsigned char CONN_RESP[] = {0x5DU, 0x41U, 0x5FU, 0x26U};
 
 #define DMR_FRAME_PER       55U
@@ -48,6 +51,7 @@ const char* HEADER1 = "This software is for use on amateur radio networks only,"
 const char* HEADER2 = "it is to be used for educational purposes only. Its use on";
 const char* HEADER3 = "commercial networks is strictly prohibited.";
 const char* HEADER4 = "Copyright(C) 2018 by CA6JAU, G4KLX and others";
+const char ysf_radioid[] = {'H', '5', '0', '0', '0'};
 
 #include <functional>
 #include <algorithm>
@@ -649,17 +653,22 @@ int CDMR2YSF::run()
 				CYSFFICH fich;
 				fich.setFI(YSF_FI_HEADER);
 				fich.setCS(2U);
+				fich.setCM(1U);
+				fich.setBN(0U);
+				fich.setBT(0U);
 				fich.setFN(0U);
-				fich.setFT(7U);
+				fich.setFT(6U);
 				fich.setDev(0U);
-				fich.setMR(2U);
+				fich.setMR(0U);
+				fich.setVoIP(false);
 				fich.setDT(YSF_DT_VD_MODE2);
 				fich.setSQL(0U);
 				fich.setSQ(0U);
 				fich.encode(m_ysfFrame + 35U);
 
 				unsigned char csd1[20U], csd2[20U];
-				memset(csd1, '*', YSF_CALLSIGN_LENGTH);
+				memset(csd1, '*', YSF_CALLSIGN_LENGTH/2);
+				memcpy(csd1 + YSF_CALLSIGN_LENGTH/2, ysf_radioid, YSF_CALLSIGN_LENGTH/2);
 				memcpy(csd1 + YSF_CALLSIGN_LENGTH, m_netSrc.c_str(), YSF_CALLSIGN_LENGTH);
 				memset(csd2, ' ', YSF_CALLSIGN_LENGTH + YSF_CALLSIGN_LENGTH);
 
@@ -685,17 +694,22 @@ int CDMR2YSF::run()
 				CYSFFICH fich;
 				fich.setFI(YSF_FI_TERMINATOR);
 				fich.setCS(2U);
+				fich.setCM(1U);
+				fich.setBN(0U);
+				fich.setBT(0U);
 				fich.setFN(0U);
-				fich.setFT(7U);
+				fich.setFT(6U);
 				fich.setDev(0U);
-				fich.setMR(2U);
+				fich.setMR(0U);
+				fich.setVoIP(false);
 				fich.setDT(YSF_DT_VD_MODE2);
 				fich.setSQL(0U);
 				fich.setSQ(0U);
 				fich.encode(m_ysfFrame + 35U);
 
 				unsigned char csd1[20U], csd2[20U];
-				memset(csd1, '*', YSF_CALLSIGN_LENGTH);
+				memset(csd1, '*', YSF_CALLSIGN_LENGTH/2);
+				memcpy(csd1 + YSF_CALLSIGN_LENGTH/2, ysf_radioid, YSF_CALLSIGN_LENGTH/2);
 				memcpy(csd1 + YSF_CALLSIGN_LENGTH, m_netSrc.c_str(), YSF_CALLSIGN_LENGTH);
 				memset(csd2, ' ', YSF_CALLSIGN_LENGTH + YSF_CALLSIGN_LENGTH);
 
@@ -708,8 +722,9 @@ int CDMR2YSF::run()
 
 				CYSFFICH fich;
 				CYSFPayload ysfPayload;
+				unsigned char dch[10U];
 
-				unsigned int fn = (ysf_cnt - 1U) % 8U;
+				unsigned int fn = (ysf_cnt - 1U) % 7U;
 
 				::memcpy(m_ysfFrame + 0U, "YSFD", 4U);
 				::memcpy(m_ysfFrame + 4U, m_ysfNetwork->getCallsign().c_str(), YSF_CALLSIGN_LENGTH);
@@ -721,7 +736,9 @@ int CDMR2YSF::run()
 
 				switch (fn) {
 					case 0:
-						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, (const unsigned char*)"**********");
+						memset(dch, '*', YSF_CALLSIGN_LENGTH/2);
+						memcpy(dch + YSF_CALLSIGN_LENGTH/2, ysf_radioid, YSF_CALLSIGN_LENGTH/2);
+						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, dch);
 						break;
 					case 1:
 						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, (const unsigned char*)m_netSrc.c_str());
@@ -729,11 +746,16 @@ int CDMR2YSF::run()
 					case 2:
 						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, (const unsigned char*)m_netDst.c_str());
 						break;
+					case 5:
+						memset(dch, ' ', YSF_CALLSIGN_LENGTH/2);
+						memcpy(dch + YSF_CALLSIGN_LENGTH/2, ysf_radioid, YSF_CALLSIGN_LENGTH/2);
+						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, dch);	// Rem3/4
+						break;
 					case 6:
-						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, gps_buffer);
+						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, dt1);
 						break;
 					case 7:
-						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, gps_buffer+10U);
+						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, dt2_temp);
 						break;
 					default:
 						ysfPayload.writeVDMode2Data(m_ysfFrame + 35U, (const unsigned char*)"          ");
@@ -742,10 +764,14 @@ int CDMR2YSF::run()
 				// Set the FICH
 				fich.setFI(YSF_FI_COMMUNICATIONS);
 				fich.setCS(2U);
+				fich.setCM(1U);
+				fich.setBN(0U);
+				fich.setBT(0U);
 				fich.setFN(fn);
-				fich.setFT(7U);
+				fich.setFT(6U);
 				fich.setDev(0U);
-				fich.setMR(YSF_MR_BUSY);
+				fich.setMR(0U);
+				fich.setVoIP(false);
 				fich.setDT(YSF_DT_VD_MODE2);
 				fich.setSQL(0U);
 				fich.setSQ(0U);
diff --git a/DMR2YSF/YSFFICH.cpp b/DMR2YSF/YSFFICH.cpp
index d1c7468..07b07da 100644
--- a/DMR2YSF/YSFFICH.cpp
+++ b/DMR2YSF/YSFFICH.cpp
@@ -232,6 +232,12 @@ void CYSFFICH::setCS(unsigned char cs)
 	m_fich[0U] |= (cs << 4) & 0x30U;
 }
 
+void CYSFFICH::setCM(unsigned char cm)
+{
+	m_fich[0U] &= 0xF3U;
+	m_fich[0U] |= (cm << 2) & 0x0CU;
+}
+
 void CYSFFICH::setFN(unsigned char fn)
 {
 	m_fich[1U] &= 0xC7U;
diff --git a/DMR2YSF/YSFFICH.h b/DMR2YSF/YSFFICH.h
index 3b49a68..d349886 100644
--- a/DMR2YSF/YSFFICH.h
+++ b/DMR2YSF/YSFFICH.h
@@ -44,6 +44,7 @@ public:
 
 	void setFI(unsigned char fi);
 	void setCS(unsigned char cs);
+	void setCM(unsigned char cm);
 	void setFN(unsigned char fn);
 	void setFT(unsigned char ft);
 	void setBN(unsigned char bn);

P252DMR build error on rpi bullseye.

on rpi
Operating System: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 6.1.21-v8+
Architecture: arm64

pi@xlxd:~/MMDVM_CM/P252DMR $ 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 DelayBuffer.o DelayBuffer.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 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 DMRFullLC.o DMRFullLC.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 DMRLookup.o DMRLookup.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRNetwork.o DMRNetwork.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 P25Network.o P25Network.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 Reflectors.o Reflectors.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 SHA256.o SHA256.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 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 MBEVocoder.o MBEVocoder.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o P252DMR.o P252DMR.cpp
g++ BPTC19696.o Conf.o CRC.o DelayBuffer.o DMRData.o DMREMB.o DMREmbeddedData.o DMRFullLC.o DMRLC.o DMRLookup.o DMRNetwork.o DMRSlotType.o P25Network.o Golay2087.o Golay24128.o Hamming.o Log.o ModeConv.o Mutex.o QR1676.o Reflectors.o RS129.o SHA256.o StopWatch.o Sync.o Thread.o Timer.o UDPSocket.o Utils.o MBEVocoder.o P252DMR.o -g -O3 -Wall -std=c++0x -pthread -lm -lpthread -limbe_vocoder -lmd380_vocoder -o P252DMR -Xlinker --section-start=.firmware=0x0800C000 -Xlinker --section-start=.sram=0x20000000
/usr/bin/ld: skipping incompatible /usr/local/lib/libmd380_vocoder.a when searching for -lmd380_vocoder
/usr/bin/ld: cannot find -lmd380_vocoder
collect2: error: ld returned 1 exit status
make: *** [Makefile:15: P252DMR] Error 1

Just results in...

Feb 8 19:14:30 ubufdmr1 xlxd: Deleting oprhaned Last Frame Packet with StreamId 60021 from x.x.x.x.

Over and over on xlxd.

When YSF2DMR is connected to a XLX master I always get a short echo back after each tx:

M: 2018-09-21 19:02:55.148 Received YSF Header: Src: CT2HRB     Dst: **********
M: 2018-09-21 19:02:55.148 DMR ID of CT2HRB: 2683196, DstID: TG 4004
M: 2018-09-21 19:02:57.591 YSF received end of voice transmission, 2.2 seconds
M: 2018-09-21 19:02:58.170 DMR audio received from CT2HRB to TG 9
M: 2018-09-21 19:02:58.414 DMR received end of voice transmission, 0.3 seconds

Can't reproduce the problem when YSF2DMR is connected to a BrandMeister master. Also with MMDVMHost/DMRGateway connected to that same XLX I can't get similar problem.

Edit: I did also find that if I'm connected to XLX but not linked to a module (i.e. 4000) the problem doesn't happen, maybe this is in fact a XLX issue? but anyway it doesn't happen with MMDVMHost/DMRGateway connected to XLX.

I cross compiled the MMDVM suite to MT7688 (OpenWRT).

MMDVMHost is working,
YSFGateway is working.
YSFParrot is working.

I am trying to run YSF2DMR now.
It compiled fine.
It starts on the MT7688 router.
Audio from YSF(handheld) to hotspot to DMR (Brandmeister) is working fine.
Audio from DMR to hotspot to YSF(handheld) is not working. The hotspot sends and outputs digital data, but my handheld (FT70d) is not accepting the traffic as audiostream.

I can replace the YSF2DMR daemon with YSFParrot on the same port, that is working as expected.

Any ideas how to troubleshoot this ?

Thanks,
Harold.

...which causes every P25 TX after the first to send YSF frames with no header. In YSF full rate (VW) mode, that means no callsign info ever gets sent and the radio never displays any call sign data. This patch clears the YSF imbe buffer after receiving the P25 EOT.

My fork is full of M172DMR/DMR2M17 and unfinished DSTAR2xxx stuff right now, so I can't do a pull request but the patch is simple:

diff --git a/YSF2P25/ModeConv.cpp b/YSF2P25/ModeConv.cpp
index 3926108..8553cd0 100644
--- a/YSF2P25/ModeConv.cpp
+++ b/YSF2P25/ModeConv.cpp
@@ -247,6 +247,10 @@ unsigned int CModeConv::getYSF(unsigned char* data)
                        m_YSF.getData(tag, 1U);
                        m_YSF.getData(data, 11U);
                        m_ysfN -= 1U;
+                       if(tag[0U] == TAG_EOT) {
+                               m_YSF.clear();
+                               m_ysfN = 0;
+                       }
                        return tag[0U];
                }
        }

I am having trouble setting this system up,
I tried many combinations of the following
I need to connect to a private P25 DV Mega System over the Internet
DMR_Hosts,txt
Alt: DMR2P25 32000 127.0.0.4 none 62037
DMR2P25 32000 ?.?.?.? none 41000

P25Hosts.txt
32000 ?.?.?.? 41000
Ip address removed for security

/etc/dmr2p25
[P25 Network]
Callsign=VE3RD
LocalAddress=127.0.0.1
LocalPort=32010
DstAddress=?.?.?.? Alt: 127.0.0.4
DstPort=41000 Alt: 62037
Daemon=1
Debug=1

Any thoughts on what I am doing wrong
Phil VE3RD
[email protected]

I am currently putting a new Raspberry Pi image together (Buster), and after much head scratching I cannot get callsign/DMRid information to show on the YSF radio. I appreciate there are many configuration options that could affect the function of this and I have worked through them with no joy.
However, simply substituting the current YSF2DMR binary (and only the binary) for one borrowed from a Pi-Star 20200503 image all is well, there are no issues during the compilation process and I am compiling on the Pi.
Thanks in advance
Brian Wiegold

Hi,
using your latest version of YSF2DMR no problem with XLX link, but i have an "echo back" (short, 1 sec of ptt with latest callsign worked) when i connect YSF2DMR to IPSC2 server. If you need, link my TUSCANY server (ipsc.grupporadiofirenze.net) with your YSF. Thank you.
David IK5XMK

I think descriptions of README.md in USRP2M17 should be updated. At current, contain description about
"....a software for digital voice conversion from M17 to YSF digital mode .."

Any chance there is a way to block a user if the YSF ID is "openSPOT"? These things key up each time someone else talks, so what is happening is the bridge hits the Brandmeister timer and gets blocked due to too many transmissions in a short period of time. Just blocking this one YSF ID would solve 99% of the problem.

I can successfully search for YSF rooms and save them to my HT's memory through YSFGateway running on a pi-star (YSFGateway-20180802_Pi-Star), but if I attempt to access the saved rooms through the memory function, the radio transmits for a moment then fails. I select a category from the list, the radio TXs, but I am never shown the list of rooms to select from.

The logs show an Unknown Wires-X command I have reproduced below. This is an FT1XDR, firmware 13.01, DSP 4.15. To be clear, this occurs when holding down ENT, then selecting any category. I never even get to see the list of saved rooms – but I know they were properly saved because I can delete them from the HT's menu interface. I just can't seem to open the list/connect to one.

==> YSFGateway-2018-09-05.log <==
M: 2018-09-05 01:25:12.716 Unknown Wires-X command
M: 2018-09-05 01:25:12.718 0000:  06 5D 67 5F 24 30 30 20 20 20 30 32 30 32 30 33    *.]g_$00   020203*
M: 2018-09-05 01:25:12.719 0010:  34 36 34 32 33 30 03 6A 00 00 00 00 00 00 00 00    *464230.j........*
M: 2018-09-05 01:25:12.720 0020:  00 00 00 00 00 00 00 00                            *........*

In trying to use P252DMR with HBlink3, P252DMR will successfully connect to HBlink, but only remain connected for about 15 seconds and then drop the connection. HBlink reports that P252DMR is dropping the connection:

INFO 2020-08-26 14:30:54,271 (P25 Test) Repeater Logging in with Radio ID: 123456704, 1.2.3.4.131:33824
INFO 2020-08-26 14:30:54,272 (P25 Test) Sent Challenge Response to 123456704 for login: 3570369517
INFO 2020-08-26 14:30:54,290 (P25 Test) Peer 123456704 has completed the login exchange successfully
INFO 2020-08-26 14:30:54,309 (P25 Test) Peer b'N0CALL ' (123456704) has sent repeater configuration
INFO 2020-08-26 14:31:14,096 (P25 Test) Peer b'N0CALL ' (123456704) has timed out and is being removed
WARNING 2020-08-26 14:31:15,911 (P25 Test) Ping from Radio ID that is not logged in: 123456704

IP addr, callsign and DMR ID have been sanitized for public viewing, these are not the actual values used!

M172DMR (29867df) seems to work fine M17->DMR, but it segfaults shortly after starting a DMR->M17 transmission. This occurs on RPi4 (using either Raspberry Pi OS with kernel 5.10.63 or 32-bit Ubuntu 20.04 with kernel 5.4.0) and an XU4 (Ubuntu 20.04 with 5.4.156).

• md380_vocoder (35aa827)
• imbe_vocoder (551ade3)
• mbelib (9a04ed5)

Rather than run the arm dependent code under qemu on an x86 or on an RPi, I see potential advantage for being able to run some of these tools on an aarch64 Debian host. If this is not a heavy lift please consider.

Andy, you are likely to want to implement the same fix as this for your YSF2xxx modes.

g4klx/YSFClients@013de54

Many YSF radios are unable to handle lower case YSF lists, even if they do handle them, searches are always upper case.

If a network connection that USRP2M17 is running over is interrupted, or the reflector it's linked to is restarted, the reflector no longer recognises the connection and (correctly) issues a NAK, but USRP2M17 still believes it's connected. Only way to restore connectivity is to restart USrP2M17, once the network or server issue is resolved, or after restarting the reflector.

make -C DMR2NXDN

make[1]: Entering directory '/root/MMDVM_CM/DMR2NXDN'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/root/MMDVM_CM/DMR2NXDN'

make -C DMR2YSF

make[1]: Entering directory '/root/MMDVM_CM/DMR2YSF'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/root/MMDVM_CM/DMR2YSF'

make -C NXDN2DMR

make[1]: Entering directory '/root/MMDVM_CM/NXDN2DMR'

make[1]: Nothing to be done for 'all'.

make[1]: Leaving directory '/root/MMDVM_CM/NXDN2DMR'

make -C YSF2DMR

make[1]: Entering directory '/root/MMDVM_CM/YSF2DMR'

g++ -g -O3 -Wall -std=c++0x -pthread -c -o Conf.o Conf.cpp
In file included from Conf.cpp:21:0:

Conf.h:57:18: error: ‘unsigned char* CConf::getYsfDT1()’ cannot be overloaded
unsigned char* getYsfDT1();
^~~~~~~~~

Conf.h:54:30: error: with ‘std::vector CConf::getYsfDT1()’
std::vector getYsfDT1();
^~~~~~~~~

Conf.h:58:18: error: ‘unsigned char* CConf::getYsfDT2()’ cannot be overloaded
unsigned char* getYsfDT2();
^~~~~~~~~

Conf.h:55:30: error: with ‘std::vector CConf::getYsfDT2()’
std::vector getYsfDT2();
^~~~~~~~~

Conf.h:59:17: error: ‘char* CConf::getYsfRadioID()’ cannot be overloaded
char* getYsfRadioID();
^~~~~~~~~~~~~

Conf.h:56:16: error: with ‘std::__cxx11::string CConf::getYsfRadioID()’
std::string getYsfRadioID();
^~~~~~~~~~~~~

Makefile:20: recipe for target 'Conf.o' failed

make[1]: *** [Conf.o] Error 1

make[1]: Leaving directory '/root/MMDVM_CM/YSF2DMR'

Makefile:7: recipe for target 'YSF2DMR' failed

make: *** [YSF2DMR] Error 2

root@vps-4a62c445:~/MMDVM_CM#

Hi,

After few experiment, I am assuming this only works under ARM. I finished the compileing under pi-star system. How can I make it running? I dont see a service folder like YSR2DMR.
Also, is it possible to have this running on a arm cloud server?
Please advise.
73

I having trouble compiling P252DMR. I have the imbe_vocoder and md380_vocoder git's on my machine but not being a linux guri I'm stumped on this on. Can anyone help me please?

root@vps-bf6b6a83:/home/adrian/MMDVM_CM/P252DMR# make all
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 DelayBuffer.o DelayBuffer.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 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 DMRFullLC.o DMRFullLC.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 DMRLookup.o DMRLookup.cpp
g++ -g -O3 -Wall -std=c++0x -pthread -c -o DMRNetwork.o DMRNetwork.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 P25Network.o P25Network.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
In file included from ModeConv.h:23,
from ModeConv.cpp:22:
MBEVocoder.h:25:10: fatal error: imbe_vocoder_api.h: No such file or directory
25 | #include <imbe_vocoder_api.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:18: ModeConv.o] Error 1
root@vps-bf6b6a83:/home/adrian/MMDVM_CM/P252DMR#

Thanks in Advance for your help
Adrian M0GLJ

Hi everyone.
I would like to understand if it is possible to separate the Callsign between the YSF and DMR sections of the ysf2dmr.ini file.
Currently my callsign entered in the DMR section is used for authentication on BM and therefore I cannot change it.
It happens that if I connect to the Pysf3 reflector with my HotSpot, which therefore uses my call, I cannot take advantage of all the possibilities offered by the reflector via HotSpot so as not to also modify the parameters of the link to BM.
Same situation if I had to open 2 or more connections to DMR to collect other TGs.
On the DMR side I can create different SSID IDs to add to my ID code, but on the YSF reflector side I always show up only with my call which I cannot change.
If I try to modify the call, for example IK4NZD-1, IK4NZD_1, IK4NZD/1, RIK4NZD to present myself to YSF with different links, then BM does not authenticate me because it does not recognize the call.
Thanks for any explanation or clarification on the matter.
'73 de Adam, IK4NZD

I suspect that this is related to the change in commit 89a9dd6.

MBEVocoder.cpp: In constructor ‘MBEVocoder::MBEVocoder()’:
MBEVocoder.cpp:31:2: error: ‘md380_init’ was not declared in this scope
md380_init();
^~~~~~~~~~
MBEVocoder.cpp:31:2: note: suggested alternative: ‘md380_encode’
md380_init();
^~~~~~~~~~
md380_encode
make: *** [Makefile:18: MBEVocoder.o] Error 1

None of the utilities can establish a connection to an IPv6 enabled reflector. This is because UDPSocket.cpp uses gethostbyname() and AF_INET exclusively. The correct way to handle a dual-stack world is to call getaddrinfo() and iterate over the returned list of structs.

First discovered using USRP2M17 to connect to ref.m17.ink.

I have a raspberry pi 3B and pi version is
pi@raspberrypi:~/MMDVM_CM/DSTAR2YSF $ uname -a
Linux raspberrypi 5.10.103-v8+ #1530 SMP PREEMPT Tue Mar 8 13:06:35 GMT 2022 aarch64 GNU/Linux

DSTAR2YSF compiling error happens as follows;

pi@raspberrypi:~/MMDVM_CM/DSTAR2YSF $ sudo make
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 Golay24128.o Golay24128.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
ModeConv.cpp:28:10: fatal error: md380_vocoder.h: No such file or directory
28 | #include <md380_vocoder.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:16: ModeConv.o] Error 1

How can I overcome this error?

Hello, if you restart XLX (service xlxd restart) YSF2DMR can not always reconnect to XLX. The process is active but the data do not pass, so you need to kill the YSF2DMR process and restart the program.
Is it possible to check (for example every minute) if the connection between YSF2DMR and XLX is active and working, or does it automatically restart the connection?
Thank you, David

The code block for sendP25Ptt is currently empty, are there any plans to add this?
Is there anything I can do to help with this? - Although it might well take you longer to teach me than to add it in :)

Hi Andy, Is it intended or is there any specific reason for DMR2YSF startup TG being TG0? (i.e. before we transmit on DMR side for the 1st time)

I guess you may plan to add code on future to change rooms using TGs, anyway in the mean time maybe it would be better to startup it at TG1 or some other TG that can be heard by all radios?

Hello,
it´s a little bit suspect.
In my TG-YSFList.txt i have these entries.

26210;74154 #DE PEGASUS Multi-Bridge
262;62829 #DE Germany YSF262 BM263

When i make a GC on TG 262 on my TG 7 for DMR2YSF, it´s showing that i am using 256
MMDVMHost log

DMR2YSF log

The same problem is when im using my DMR2YSF TG7 it shows TG1 in the log.
DMR2YSF log

MMDVMHost log

Is it my config somewhere or is it a DMR2YSF issue??

BTW: when i´m using GC TG268 in the TG7 for DMR2YSF on my PD785, im on YSF ref. 62829 #DE Germany YSF262 BM263
Same when im getting voice via DMR2YSF from a ref. it shows TG13 not TG7 and in the radio i cant hear something. Which is christel clear why not.
It seems that all is +6

When using YSF2DMR to talk to a BM TG, I do not see the callsigns (or even DMR IDs) of talking users. Callsigns (not DMR IDs) do appear correctly on the pi-star webpage.

I'm using YSFGateway-20180802_Pi-Star, YSF2DMR-20180802_Pi-Star, and a Yaesu FT1XDR with the newish firmware 13.01/DSP 4.15.

There are no errors shown in the logs or anything suggesting anything is wrong, and callsigns do display correctly when talking just through YSFGateway to YSF rooms. It's only in YSF2DMR mode that I do not see callsigns displayed on the HT.

I'm happy to test/upload any logs/switch into any debug mode if I can provide additional data for troubleshooting.

audio volume from YSF to DMR is really ok but audio came from DMR is to much volume going to C4FM devices. Any help on this issue?
73 de Kurt
OE1KBC

DMR2NXDN - Works great, also have it working via DMRGateway too, no issues here, occasional ring buffer issues but that may also be happening on the NXDNGateway, I have not looked.

DMR2YSF - Can you do anything to add the ability to request reflector changes based on the DMR TG?

YSF2NXDN/YSF2DMR/YSF2P25 - All work nicely, again - any way to choose the target TG from the YSF radio?

Over-all - oustanding work, and all pulled into Pi-Star apart from NXDN2DMR

Good evening

Please advise regardin the automatic update of DMRIds.dat file

Thank you
Catalin
YO3CAT

No code is present for CRC 32 bit within the source code, That is applied on DMR Data Burst

Hi, My name is David Lardizabal HR2DDL, from the Radio Club de Honduras. We have had a YSFReflector with a YSF2DMR bridge working for serveral months. On the week of 9th of november somethign changed and the audio coming from DMR to C4FM was not coming out, only light can be seen on radios that transmission is been sent but no audio out through the bridge. From C4FM to DMR the audio is working fine. The light come on, from the C4FM radios that something is being transmitted but no audio is coming out, the radio seem to not decode. I check with other friends that are connected and they are observing the same thing with their C4FM radios, when connected to our YSFReflector.
When C4FM is transmitted and it goes to the YSFReflector, through the bridge, the audio transmition is coming out on DMR radios with no problem. I have check and recheck all parameters, but I can not see where I have a mistake. I would appreciate any help regarding this matter. I am enclosing a copy of my YSF2DMR.ini file and copy of log of YSF2DMR bridge that all is passing through as it should.

I am not sure if something changed in BM or an update has been done. I am aware that other bridges are working okay. I have a NanoSpot hotspot with pi-star and tested the YSF2DMR and it works.

YSF2DMR.ini

[Info]
RXFrequency=435000000
TXFrequency=435000000
Power=1
Latitude=0.0
Longitude=0.0
Height=0
Location=Nowhere
Description=Multi-Mode Repeater
URL=www.google.co.uk

[YSF Network]
Callsign=HR2RCH
Suffix=ND
#Suffix=RPT
DstAddress=127.0.0.1
DstPort=42000
LocalAddress=127.0.0.1
LocalPort=42012
EnableWiresX=0
RemoteGateway=0
HangTime=1000
WiresXMakeUpper=1
Daemon=0

[DMR Network]
Id=7087002
#XLXFile=XLXHosts.txt
#XLXReflector=950
#XLXModule=D
StartupDstId=708

For TG call: StartupPC=0

StartupPC=0
Address=3108.repeater.net
Port=62031
Jitter=500
EnableUnlink=0
TGUnlink=4000
PCUnlink=0

Local=62032

Password=passw0rd

Options=

TGListFile=TGList-DMR.txt
Debug=0

[DMR Id Lookup]
File=DMRIds.dat
Time=24
DropUnknown=0

[Log]

Logging levels, 0=No logging

DisplayLevel=2
FileLevel=2
FilePath=/home/pi/log/
FileRoot=YSF2DMR

[aprs.fi]
Enable=0
AprsCallsign=G9BF

Server=noam.aprs2.net

Server=euro.aprs2.net
Port=14580
Password=9999
APIKey=Apikey

LOG

pi@raspberrypi:~/Downloads/MMDVM_CM/YSF2DMR $ ./YSF2DMR YSF2DMR.ini
I: 2019-11-18 13:24:39.878 This software is for use on amateur radio networks only,
I: 2019-11-18 13:24:39.878 it is to be used for educational purposes only. Its use on
I: 2019-11-18 13:24:39.878 commercial networks is strictly prohibited.
I: 2019-11-18 13:24:39.879 Copyright(C) 2018,2019 by CA6JAU, EA7EE, G4KLX and others
I: 2019-11-18 13:24:39.879 Loaded 0 XLX reflectors
I: 2019-11-18 13:24:39.879 General Parameters
I: 2019-11-18 13:24:39.879 Remote Gateway: no
I: 2019-11-18 13:24:39.879 Hang Time: 1000 ms
M: 2019-11-18 13:24:39.879 Opening YSF network connection
M: 2019-11-18 13:24:39.879 DMR Network Parameters
M: 2019-11-18 13:24:39.879 ID: 7087002
M: 2019-11-18 13:24:39.880 Default SrcID: 7087002
M: 2019-11-18 13:24:39.880 Startup DstID: TG 708
M: 2019-11-18 13:24:39.880 Address: 3108.repeater.net
M: 2019-11-18 13:24:39.880 Port: 62031
M: 2019-11-18 13:24:39.880 Send TG 4000 Disconect: No
M: 2019-11-18 13:24:39.880 TGList file: TGList-DMR.txt
M: 2019-11-18 13:24:39.880 Local: random
M: 2019-11-18 13:24:39.880 Jitter: 500ms
M: 2019-11-18 13:24:39.884 Info Parameters
M: 2019-11-18 13:24:39.885 Callsign: HR2RCH
M: 2019-11-18 13:24:39.885 RX Frequency: 435000000Hz
M: 2019-11-18 13:24:39.885 TX Frequency: 435000000Hz
M: 2019-11-18 13:24:39.885 Power: 1W
M: 2019-11-18 13:24:39.885 Latitude: 0.000000deg N
M: 2019-11-18 13:24:39.885 Longitude: 0.000000deg E
M: 2019-11-18 13:24:39.885 Height: 0m
M: 2019-11-18 13:24:39.885 Location: "Nowhere"
M: 2019-11-18 13:24:39.886 Description: "Multi-Mode Repeater"
M: 2019-11-18 13:24:39.886 URL: "www.google.co.uk"
M: 2019-11-18 13:24:39.886 DMR, Opening DMR Network
I: 2019-11-18 13:24:40.584 Loaded 145759 Ids to the callsign lookup table
M: 2019-11-18 13:24:40.584 Starting YSF2DMR-20190204
I: 2019-11-18 13:24:40.584 Started the DMR Id lookup reload thread
M: 2019-11-18 13:24:50.725 DMR, Logged into the master successfully
M: 2019-11-18 13:26:32.932 Received YSF Header: Src: HR2DDL Dst: *****H53FB
M: 2019-11-18 13:26:32.932 DMR ID of HR2DDL: 7082001, DstID: TG 708
M: 2019-11-18 13:26:34.927 YSF received end of voice transmission, 1.9 seconds
M: 2019-11-18 13:26:43.744 DMR audio received from HR2DDL to TG 708
M: 2019-11-18 13:26:49.204 DMR received end of voice transmission, 5.3 seconds
M: 2019-11-18 13:27:05.094 DMR audio received from HR2DDL to TG 708
M: 2019-11-18 13:27:10.919 DMR received end of voice transmission, 5.7 seconds

P252DMR build from repo code today. Even when idle, process takes 100% of 1 core.

When passing voice from USRP to M17, the M17 frame counter will incorrectly exceed 0x7fff on long transmissions, causing receivers to perceive a flood of EOT frames.

The simplest fix looks like it would be to add a check after the counter increment on line 364 of USRP2M17.cpp. Something like:

m17_cnt++;
if (m17_cnt > 0x7fff) {
  m17_cnt = 1;
}

Unfortunately the test for this is to let the transmitter run for nearly 22 minutes. If I get some free time I'll try to test it and put a proper PR together.

Hi,

Not sure whether this is firmware related or not, but I am running a MMDVM duplex v1.3 (JumboSpot) with pistar Beta V4 RC3., firmware 1.4.16, TcXo 14 MHz.

I can get the hotspot to work fine, but after some time I loose communication with the pistar web interface. The hotspot is still functional, I can ping it fine, I can use DMR to Tx and Rx OK, but I cannot cooonect to its IP address anymore, Receiving GATEWAY error messages 502 or 504 when I try it form the component nginx web server. When I restart the hotspot I can again regain access to the pistar web interface, until it is gone again in a few minutes. Any hints? Thanks

Hello. After installation on RPI3 B+ I make test program and md380_init() return -1. If run
md380_encode function program crush with Segmentation Fault.

This very well may be intentional, and I've patched it on my end, but want to toss this out there before I consider a pull request in case this is entirely intentional.

If a startup DMR talk group is set for YSF2DMR, a * disconnect takes it back to TG 9 (local by convention) instead of the startup talk group.

Part of me agrees with this behavior as a disconnect should be a disconnect, however, considering '9' is still just another talk group outside of convention, the other part of me thinks it should just go back to the programmed startup.

In our case, our default talk groups is 6 digits (based on repeater DMR ID), so the only way to get back to it is through the startup (unless there's another direct entry way I'm not aware of). So for us, it makes sense to default it back there or you won't be able to get it back there again remotely. I get that is not the case for everyone.

My local solution was to just set it back to m_conf.getDMRDstId() on disconnect.

Thoughts as to if this is a bug or not?

Trying to get P252DMR working with my XLX. When I add the XLX parms to the .ini, running always results in a seg fault. Here is the [DMR Network] stanta:

[DMR Network]
Id=1234567
XLXFile=/usr/local/etc/XLXHosts.txt
XLXModule=B
XLXReflector=020
#StartupDstId=4002
#StartupPC=1
#Address=xlx020.k2ie.net
Port=62030
Jitter=500
Password=PASSWORD
Debug=0

If I take out the XLX parms and uncomment the address, P252DMR will run, it will connect to the XLX, but not to any module.

Andy, can you have a look at this: g4klx/YSFClients#142

The same search limitation appears in at least YSF2DMR, but probably the other YSF2xxx modes too, searches only match the start of the reflector name, and not anywhere in the string.

My PR against the YSFGateway code may not be suitable for you but it might give you a starting point.

Andy

Hi Andy, I'm using YSF2DMR to bridge a YSF reflector to a XLX, all is working fine so far except that when there is some small interruption in a YSF transmission then YSF2DMR is apparently unable to recover (despite it shows on YSF2DMR log) and continue passing the audio after interruption to the XLX, until user stops and starts a new transmission. I did confirm that other users connected on the YSF are able to correctly get my audio after the interruption, YSF2DMR just doesn't seem to pass it to the XLX.

See logs below, I made a single continuous YSF transmission and during it I did intentionally interfere on it with a 2nd (analog) radio just to cause the interruption, very easy to reproduce:

MMDVMHost:
M: 2019-01-11 19:19:03.215 YSF, received RF header from CT2HRB     to ALL       
M: 2019-01-11 19:19:11.608 YSF, transmission lost, 8.4 seconds, BER: 4.2%, RSSI: -66/-47/-64 dBm
M: 2019-01-11 19:19:16.215 YSF, received RF late entry from CT2HRB     to ALL       
M: 2019-01-11 19:19:24.816 YSF, received RF end of transmission, 8.7 seconds, BER: 1.5%, RSSI: -66/-65/-65 dBm

YSFReflector:
M: 2019-01-11 19:19:03.240 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:13.032 Network watchdog has expired
M: 2019-01-11 19:19:16.242 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:24.838 Received end of transmission

YSF2DMR:
M: 2019-01-11 19:19:03.242 Received YSF Header: Src: CT2HRB     Dst: *****E03qG
M: 2019-01-11 19:19:03.242 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:16.243 Received YSF Header: Src: CT2HRB     Dst: **********
M: 2019-01-11 19:19:16.243 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:24.843 YSF received end of voice transmission, 8.6 seconds

XLX:
Jan 11 19:19:03 s4 xlxd: Opening stream on module D for client CT2HRB  B with sid 27186
Jan 11 19:19:13 s4 xlxd: Closing stream of module D

And another example doing it faster (YSFReflector didn't even "notice" the cut on this one):

MMDVMHost:
M: 2019-01-11 19:19:47.727 YSF, received RF header from CT2HRB     to ALL       
M: 2019-01-11 19:19:49.919 YSF, transmission lost, 2.2 seconds, BER: 14.6%, RSSI: -65/-47/-61 dBm
M: 2019-01-11 19:19:50.327 YSF, received RF late entry from CT2HRB     to ALL       
M: 2019-01-11 19:19:58.827 YSF, received RF end of transmission, 8.6 seconds, BER: 1.4%, RSSI: -66/-63/-64 dBm

YSFReflector:
M: 2019-01-11 19:19:47.755 Received data from CT2HRB     to ALL        at CT2HRB    
M: 2019-01-11 19:19:58.850 Received end of transmission

YSF2DMR:
M: 2019-01-11 19:19:47.759 Received YSF Header: Src: CT2HRB     Dst: *****E03qG
M: 2019-01-11 19:19:47.759 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:50.352 Received YSF Header: Src: CT2HRB     Dst: **********
M: 2019-01-11 19:19:50.352 DMR ID of CT2HRB: 2683149, DstID: TG 4004
M: 2019-01-11 19:19:58.855 YSF received end of voice transmission, 8.5 seconds

XLX:
Jan 11 19:19:47 s4 xlxd: Opening stream on module D for client CT2HRB  B with sid 20160
Jan 11 19:19:51 s4 xlxd: Closing stream of module D

++ -g -O3 -Wall -std=c++0x -pthread -c -o MBEVocoder.o MBEVocoder.cpp
MBEVocoder.cpp: In constructor ‘MBEVocoder::MBEVocoder()’:
MBEVocoder.cpp:33:2: error: ‘md380_init’ was not declared in this scope
33 | md380_init();
| ^~~~~~~~~~
make: *** [Makefile:18: MBEVocoder.o] Error 1

On request on fellow DMR partners, I had this request to filter out users unknown to the DMR side.

My patch adds a new parameter to the DMR ID lookup config section:
DropUnknown=1/0