Date   

Re: P25 North America reflector

Steve N4IRS
 

Updated patch.

void CP25Network::clock(unsigned int ms)
{
    unsigned char buffer[BUFFER_LENGTH];

    sockaddr_storage address;
    unsigned int addrLen;
    int length = m_socket.read(buffer, BUFFER_LENGTH, address, addrLen);
    if (length <= 0)
        return;

    if (!CUDPSocket::match(m_addr, address)) {
        LogMessage("P25, packet received from an invalid source");
        return;
    }

    if (!m_enabled)
        return;

    if (m_debug)
        CUtils::dump(1U, "P25 Network Data Received", buffer, length);

    while (length > 0) {
        unsigned char addBytes = 0;
        int recSize[] = {22, 14, 17, 17, 17, 17, 17, 17, 16, 22, 14, 17, 17, 17, 17, 17, 17, 16};
        unsigned char recType = buffer[0];
        if ((recType >= 0x62) && (recType <= 0x73))
            addBytes = recSize[recType - 0x62];
        else if (recType == 0x80)
            addBytes = 17;
        else {
            if (recType != 0xF0)   // its a poll, don't say anything
                LogMessage("Got a network byte I did not expect %0X, %d", buffer[0], length);
            addBytes = 0;
            length = 0; // Don't add it and don't continue
        }
        if ((addBytes > 0) && (addBytes <= length)) {
            m_buffer.addData(&addBytes, 1U);
            m_buffer.addData(buffer, addBytes);
        }
        length -= addBytes;
    }
}


On 9/18/21 10:29 AM, Miguel wrote:

ah ok. Thanks. That is helpful. (was writing my other response before seeing yours)

Don't want to change a lot of variables so will see if I can compile and replace in one of the hotspots.

thx



Re: P25 North America reflector

Steve N4IRS
 

This seems the confirm the difference in the mode usage; <https://www.repeaterbook.com/stats/>



On 9/18/21 10:26 AM, Miguel wrote:

Not sure but maybe this msg should say "net queue" ? Have not yet studied this code enough... https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L766

Also.... this number may grow too big? https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L560

My intuition (which could be wrong) tells me that there has not been as much traffic/usage on p25 over mmdvmhost code as there has been with dmr/ysf/dstar and thus there may be "issues" lurking in there... You already know about the two that I found last month.... one of those was pretty bad but it does expose the "maturity" and "time-tested-ness" of the code base.

For what is worth though... I had a qso with a station at one point on 10200 then immediately switch to another reflector and no issues.... same hotspot, radios, etc... I guess people can do that test just the same by going to 10201 and see.... Some had said that the number of stations to which the packets need to be reflected may be an influence (the reflector I have only has about 30 active signed on hotspots...). Not sure myself...

KC1LKO



Re: P25 North America reflector

Robert Bretzman
 

Thanks for the explanation. This is now making sense.
Robert
K4WZV


On Sat, Sep 18, 2021 at 11:27 AM Steve N4IRS <szingman@...> wrote:
For people watching this thread, This patch was derived for a change we made to Quantar Bridge when we started seeing the "overflow in the P25 RF queue" and hearing the issue on the resulting Quantar transmission. That is why a user listening to a DVSwitch based node does not experence the same bad audio that a unmodified MMDVMHost hears.

On 9/18/21 10:02 AM, Steve N4IRS via groups.io wrote:
So,
I have had NO response from anyone who can test a change to MMDVMHost. I'll make it a little easier. I will provide a ARM or x86 binary. I can't provide a binary for anyone running Pi-Star at this time. 
For people reporting packet loss from the Pi-Ster dashboard, check your raw MMDVMHost log for the error message:
E: 2021-09-18 13:40:19.719 P25, overflow in the P25 RF queue
This is a good indication of what is happening.

Here is a comparison of 2 logs:
Stock Pi-Star
M: 2021-09-18 13:55:21.540 P25, received network transmission from KB0AJQ to TG 10200
M: 2021-09-18 13:55:27.401 P25, network end of transmission from KB0AJQ to TG 10200, 6.5 seconds, 5% packet loss

Modified MMDVMHost
M: 2021-09-18 13:55:21.549 P25, received network transmission from 3129130 to TG 10200
M: 2021-09-18 13:55:27.406 P25, network end of transmission from 3129130 to TG 10200, 6.1 seconds, 0% packet loss

I am running a STM32-DVM modem on a CDM repeater. I am listening on a Kenwood  NX-5300 This is running the modified code.
 


Re: ZUM Radio-MMDVM Support?

Steve N4IRS
 

On 9/18/21 11:20 AM, Tim WD6AWP via groups.io wrote:
I'm having a heck of a time getting a ZUM Radio-MMDVM 1.0.0 to receive using Pi-star and CDMs. I find lots of old and conflicting information out there. Is there an active list where I can ask for help? 


ZUM Radio-MMDVM Support?

 

I'm having a heck of a time getting a ZUM Radio-MMDVM 1.0.0 to receive using Pi-star and CDMs. I find lots of old and conflicting information out there. Is there an active list where I can ask for help? 


Re: P25 North America reflector

Steve N4IRS
 

For people watching this thread, This patch was derived for a change we made to Quantar Bridge when we started seeing the "overflow in the P25 RF queue" and hearing the issue on the resulting Quantar transmission. That is why a user listening to a DVSwitch based node does not experence the same bad audio that a unmodified MMDVMHost hears.

On 9/18/21 10:02 AM, Steve N4IRS via groups.io wrote:
So,
I have had NO response from anyone who can test a change to MMDVMHost. I'll make it a little easier. I will provide a ARM or x86 binary. I can't provide a binary for anyone running Pi-Star at this time. 
For people reporting packet loss from the Pi-Ster dashboard, check your raw MMDVMHost log for the error message:
E: 2021-09-18 13:40:19.719 P25, overflow in the P25 RF queue
This is a good indication of what is happening.

Here is a comparison of 2 logs:
Stock Pi-Star
M: 2021-09-18 13:55:21.540 P25, received network transmission from KB0AJQ to TG 10200
M: 2021-09-18 13:55:27.401 P25, network end of transmission from KB0AJQ to TG 10200, 6.5 seconds, 5% packet loss

Modified MMDVMHost
M: 2021-09-18 13:55:21.549 P25, received network transmission from 3129130 to TG 10200
M: 2021-09-18 13:55:27.406 P25, network end of transmission from 3129130 to TG 10200, 6.1 seconds, 0% packet loss

I am running a STM32-DVM modem on a CDM repeater. I am listening on a Kenwood  NX-5300 This is running the modified code.
 


Re: P25 North America reflector

Steve N4IRS
 

I don't have any usage stats between the different modes so you could be correct that P25 usage is lower so not as fully vetted.
The switching from reflector to reflector can be a valid test since 10201 is running on the same host as 10200, running the exact same binary (3 instances) on the same network. The ONLY difference is the number of connected gateways.  The interesting report is that on the very same transmission, 2 listening stations can report different results. One reports bad audio while the other reports no issue. Testing continues....

On 9/18/21 10:26 AM, Miguel wrote:

Not sure but maybe this msg should say "net queue" ? Have not yet studied this code enough... https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L766

Also.... this number may grow too big? https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L560

My intuition (which could be wrong) tells me that there has not been as much traffic/usage on p25 over mmdvmhost code as there has been with dmr/ysf/dstar and thus there may be "issues" lurking in there... You already know about the two that I found last month.... one of those was pretty bad but it does expose the "maturity" and "time-tested-ness" of the code base.

For what is worth though... I had a qso with a station at one point on 10200 then immediately switch to another reflector and no issues.... same hotspot, radios, etc... I guess people can do that test just the same by going to 10201 and see.... Some had said that the number of stations to which the packets need to be reflected may be an influence (the reflector I have only has about 30 active signed on hotspots...). Not sure myself...

KC1LKO



Re: P25 North America reflector

Miguel
 

ah ok. Thanks. That is helpful. (was writing my other response before seeing yours)

Don't want to change a lot of variables so will see if I can compile and replace in one of the hotspots.

thx


Re: P25 North America reflector

Miguel
 

Not sure but maybe this msg should say "net queue" ? Have not yet studied this code enough... https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L766

Also.... this number may grow too big? https://github.com/g4klx/MMDVMHost/blob/master/P25Control.cpp#L560

My intuition (which could be wrong) tells me that there has not been as much traffic/usage on p25 over mmdvmhost code as there has been with dmr/ysf/dstar and thus there may be "issues" lurking in there... You already know about the two that I found last month.... one of those was pretty bad but it does expose the "maturity" and "time-tested-ness" of the code base.

For what is worth though... I had a qso with a station at one point on 10200 then immediately switch to another reflector and no issues.... same hotspot, radios, etc... I guess people can do that test just the same by going to 10201 and see.... Some had said that the number of stations to which the packets need to be reflected may be an influence (the reflector I have only has about 30 active signed on hotspots...). Not sure myself...

KC1LKO


Re: P25 North America reflector

Steve N4IRS
 

I have not yet forked and patched Jonathan's code. Here is the change to P25Network.cpp Let me know results.

void CP25Network::clock(unsigned int ms)
{
    unsigned char buffer[BUFFER_LENGTH];

    sockaddr_storage address;
    unsigned int addrLen;
    int length = m_socket.read(buffer, BUFFER_LENGTH, address, addrLen);
    if (length <= 0)
        return;

    if (!CUDPSocket::match(m_addr, address)) {
        LogMessage("P25, packet received from an invalid source");
        return;
    }

    if (!m_enabled)
        return;

    if (m_debug)
        CUtils::dump(1U, "P25 Network Data Received", buffer, length);

    unsigned char c = length;
    m_buffer.addData(&c, 1U);

    m_buffer.addData(buffer, length);
}

becomes......

void CP25Network::clock(unsigned int ms)
{
    unsigned char buffer[BUFFER_LENGTH];

    sockaddr_storage address;
    unsigned int addrLen;
    int length = m_socket.read(buffer, BUFFER_LENGTH, address, addrLen);
    if (length <= 0)
        return;

    if (!CUDPSocket::match(m_addr, address)) {
        LogMessage("P25, packet received from an invalid source");
        return;
    }

    if (!m_enabled)
        return;

    if (m_debug)
        CUtils::dump(1U, "P25 Network Data Received", buffer, length);

    while (length > 0) {
        unsigned char addBytes = 0;
        int recSize[] = {22, 14, 17, 17, 17, 17, 17, 17, 16, 22, 14, 17, 17, 17, 17, 17, 17, 16};
        unsigned char recType = buffer[0];
        if ((recType >= 0x62) && (recType <= 0x73))
            addBytes = recSize[recType - 0x62];
        else if (recType == 0x80)
            addBytes = 17;
        else
            LogMessage("Got a network byte I did not expect %0X, %d", buffer[0], length);
        if ((addBytes > 0) && (addBytes <= length)) {
            m_buffer.addData(&addBytes, 1U);
            m_buffer.addData(buffer, addBytes);
           
        }
        length -= addBytes;
    }
}
 

On 9/18/21 10:18 AM, Miguel wrote:

What is the change? Have a github branch?

thx



Re: P25 North America reflector

Miguel
 

What is the change? Have a github branch?

thx


Re: P25 North America reflector

Steve N4IRS
 

So,
I have had NO response from anyone who can test a change to MMDVMHost. I'll make it a little easier. I will provide a ARM or x86 binary. I can't provide a binary for anyone running Pi-Star at this time. 
For people reporting packet loss from the Pi-Ster dashboard, check your raw MMDVMHost log for the error message:
E: 2021-09-18 13:40:19.719 P25, overflow in the P25 RF queue
This is a good indication of what is happening.

Here is a comparison of 2 logs:
Stock Pi-Star
M: 2021-09-18 13:55:21.540 P25, received network transmission from KB0AJQ to TG 10200
M: 2021-09-18 13:55:27.401 P25, network end of transmission from KB0AJQ to TG 10200, 6.5 seconds, 5% packet loss

Modified MMDVMHost
M: 2021-09-18 13:55:21.549 P25, received network transmission from 3129130 to TG 10200
M: 2021-09-18 13:55:27.406 P25, network end of transmission from 3129130 to TG 10200, 6.1 seconds, 0% packet loss

I am running a STM32-DVM modem on a CDM repeater. I am listening on a Kenwood  NX-5300 This is running the modified code.
 


Re: P25 to DMR troubles. error at MMDVM_Bridge - Cannot bind UDP address, err: 98 -and- Cannot open listener port 34103

Todd, KB7RQQ
 

Got it running! USRP audio ports were crossed on the P25 side of Analog_Bridge.  Thanks!

Todd KB7RQQ



On 9/16/2021 9:51 AM, Todd, KB7RQQ wrote:

OK sounds good. Thank you.

On 9/16/2021 9:18 AM, Steve N4IRS wrote:
One suggestion, DVSwitch.ini should need little to no modification. You will be editing the AB ini files so, make your changes there and leave DVswitch.ini stock.

Steve

On 9/16/2021 11:30 AM, Todd, KB7RQQ wrote:

Great diagram! Think I saw that at one point early on and forgot about it.  I think I'm armed with the tools I need to figure this out.  Still learning and even though this is challenging (for me)... I'm having fun. Thanks again for the tools and all the help.

Todd KB7RQQ

On 9/16/2021 8:23 AM, Steve N4IRS wrote:
<https://dvswitch.groups.io/g/main/wiki/9379>

On 9/16/2021 10:43 AM, Todd, KB7RQQ wrote:
OK... going through it again. 



Re: Macro result was 512 #analog_bridge

Geoff
 

Steve,

Don't quite understand what you mean. Not from a Linux background and my knowledge is very limited. Sorry for that.

I tried to add one more TG in the macro D script, and it failed to execute.
As soon as I removed a TG, it started to work as normal.
So there is something that has something to do with the length of the script.

Thank you.
Geoff

On Fri, Sep 17, 2021 at 09:21 AM, Steve N4IRS wrote:
I don't know of a limitation on size, but it's possible. Put the command in a script and cal teh script from dvsm.macro

On 9/16/21 6:17 PM, Geoff wrote:
Steve,

To answer your question, the latest version of MMDVM_Bridge (V1.6.8) installed to /opt/MMDVM_Bridge.
dvswitch.sh is in /opt/Analog_Bridge not in /opt/MMDVM_Bridge so it is in one location only.
The version of dvswitch is v1.6.1.

What I have tried a few different things this morning :-
 
C=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=450;TS2_2=518"
D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS1_1=5;TS2_1=505;TS2_2=3802;TS2_3=3803"

Above two macro scripts are the original in dvsm.macro file.
I have renamed C to D and D to C and tried to execute the macro D connects buit not C.

It seemed that there is something wrong with the macro D script.
I then tried to shorten the macro D script to :-

D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=505;TS2_2=3802"

Now, I don't have any issues and connects to D. I have tried multiple times and every time it connects.

What does this tell?

I don't think there was any syntax error in my original macro D script.
I just had to remove a couple of TGs to get the D working.

Is there any restriction as to how long a script can be?

Thank you.

 Steve,

"I don't know of a limitation on size, but it's possible. Put the command in a script and cal teh script from dvsm.macro"


Re: Macro result was 512 #analog_bridge

Steve N4IRS
 

I don't know of a limitation on size, but it's possible. Put the command in a script and cal teh script from dvsm.macro

On 9/16/21 6:17 PM, Geoff wrote:
Steve,

To answer your question, the latest version of MMDVM_Bridge (V1.6.8) installed to /opt/MMDVM_Bridge.
dvswitch.sh is in /opt/Analog_Bridge not in /opt/MMDVM_Bridge so it is in one location only.
The version of dvswitch is v1.6.1.

What I have tried a few different things this morning :-
 
C=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=450;TS2_2=518"
D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS1_1=5;TS2_1=505;TS2_2=3802;TS2_3=3803"

Above two macro scripts are the original in dvsm.macro file.
I have renamed C to D and D to C and tried to execute the macro D connects buit not C.

It seemed that there is something wrong with the macro D script.
I then tried to shorten the macro D script to :-

D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=505;TS2_2=3802"

Now, I don't have any issues and connects to D. I have tried multiple times and every time it connects.

What does this tell?

I don't think there was any syntax error in my original macro D script.
I just had to remove a couple of TGs to get the D working.

Is there any restriction as to how long a script can be?

Thank you.


Re: Macro result was 512 #analog_bridge

Geoff
 

Steve,

To answer your question, the latest version of MMDVM_Bridge (V1.6.8) installed to /opt/MMDVM_Bridge.
dvswitch.sh is in /opt/Analog_Bridge not in /opt/MMDVM_Bridge so it is in one location only.
The version of dvswitch is v1.6.1.

What I have tried a few different things this morning :-
 
C=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=450;TS2_2=518"
D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS1_1=5;TS2_1=505;TS2_2=3802;TS2_3=3803"

Above two macro scripts are the original in dvsm.macro file.
I have renamed C to D and D to C and tried to execute the macro D connects buit not C.

It seemed that there is something wrong with the macro D script.
I then tried to shorten the macro D script to :-

D=sudo /opt/Analog_Bridge/dvswitch.sh tune "PASSWORD@...:55555:StartRef=4570;RelinkTime=120;UserLink=1;TS2_1=505;TS2_2=3802"

Now, I don't have any issues and connects to D. I have tried multiple times and every time it connects.

What does this tell?

I don't think there was any syntax error in my original macro D script.
I just had to remove a couple of TGs to get the D working.

Is there any restriction as to how long a script can be?

Thank you.


Re: P25 to DMR troubles. error at MMDVM_Bridge - Cannot bind UDP address, err: 98 -and- Cannot open listener port 34103

Todd, KB7RQQ
 

OK sounds good. Thank you.

On 9/16/2021 9:18 AM, Steve N4IRS wrote:
One suggestion, DVSwitch.ini should need little to no modification. You will be editing the AB ini files so, make your changes there and leave DVswitch.ini stock.

Steve

On 9/16/2021 11:30 AM, Todd, KB7RQQ wrote:

Great diagram! Think I saw that at one point early on and forgot about it.  I think I'm armed with the tools I need to figure this out.  Still learning and even though this is challenging (for me)... I'm having fun. Thanks again for the tools and all the help.

Todd KB7RQQ

On 9/16/2021 8:23 AM, Steve N4IRS wrote:
<https://dvswitch.groups.io/g/main/wiki/9379>

On 9/16/2021 10:43 AM, Todd, KB7RQQ wrote:
OK... going through it again. 



Re: P25 to DMR troubles. error at MMDVM_Bridge - Cannot bind UDP address, err: 98 -and- Cannot open listener port 34103

Steve N4IRS
 

One suggestion, DVSwitch.ini should need little to no modification. You will be editing the AB ini files so, make your changes there and leave DVswitch.ini stock.

Steve

On 9/16/2021 11:30 AM, Todd, KB7RQQ wrote:

Great diagram! Think I saw that at one point early on and forgot about it.  I think I'm armed with the tools I need to figure this out.  Still learning and even though this is challenging (for me)... I'm having fun. Thanks again for the tools and all the help.

Todd KB7RQQ

On 9/16/2021 8:23 AM, Steve N4IRS wrote:
<https://dvswitch.groups.io/g/main/wiki/9379>

On 9/16/2021 10:43 AM, Todd, KB7RQQ wrote:
OK... going through it again. 



Re: P25 to DMR troubles. error at MMDVM_Bridge - Cannot bind UDP address, err: 98 -and- Cannot open listener port 34103

Todd, KB7RQQ
 

Great diagram! Think I saw that at one point early on and forgot about it.  I think I'm armed with the tools I need to figure this out.  Still learning and even though this is challenging (for me)... I'm having fun. Thanks again for the tools and all the help.

Todd KB7RQQ

On 9/16/2021 8:23 AM, Steve N4IRS wrote:
<https://dvswitch.groups.io/g/main/wiki/9379>

On 9/16/2021 10:43 AM, Todd, KB7RQQ wrote:
OK... going through it again. 


Re: P25 to DMR troubles. error at MMDVM_Bridge - Cannot bind UDP address, err: 98 -and- Cannot open listener port 34103

Steve N4IRS
 

On 9/16/2021 10:43 AM, Todd, KB7RQQ wrote:
OK... going through it again. 

161 - 180 of 9925