Date   

Smartphone apps

Bob N1XBM <N1XBM@...>
 

I honestly sometimes miss things while doing research for "whats out there" With all of the tools for building networks. Has anyone come up with a way to peer a smartphone to an ipsc network?

I know there is some commercial offerings that require some server software.

Thank you 

N1XBM
Apparare Scientor
Paratus Communicare
Allstar Node # 27086, 41540, 41812, 42086, 42658, 42657
www.radioguysrepeaternetwork.com


Re: Analog_Bridge Source

Mike Zingman - N4IRR
 

Chris,

I am sorry, at the moment the source is still being cleaned up from many hacks over the years.  I will release it ASAP.  In the mean time, if all you need to do is backup your configurations, rsync is a great tool.

Best regards
Mike N4IRR


Analog_Bridge Source

Chris Andrist, KC7WSU
 

I am trying to run Analog_Bridge on FreeBSD. Is the source available that I can download and compile it?

I am getting the following error:

root@dmrgateway:/srv/Analog_Bridge # ./Analog_Bridge.x64
ELF binary type "0" not known.
./Analog_Bridge.x64: Exec format error. Binary file not executable.

My goal is to separate Analog Audio and the USRP Node. This way if the node dies I can just setup app_rpt again and not have to setup Analog_Bridge, HB_Bridge, and app_rpt.

Regards,
Chris Andrist, KC7WSU
DMR-UTAH


Re: New Set Up MMDVM to IPSC

Steve N4IRS
 

Correct,
I tried to use the correct terminology.
In HB Protocol MMDVMHost is the "Client" and HBlink is the "Server"
In IPSC (Motorola) DMRlink is the "Peer" ant your 8300 is the "Master"

HB_Bridge and IPSC_Bridge are referred to as "Partners" Partners talk to each other.
Other Partners are:
Analog_Bridge for connecting to AllStar and EchoLink
DummyRepeater is from G4KLX and has been modified to connect to D-Star. Not really a Partner, but it acts like one.

Other Partners to come...

73, Steve N4IRS  

On 10/11/2017 12:56 PM, stevecast2024@... wrote:
Thank You Steve,

This is exactly the info I'm looking for. My confusion was with HBlink in the process. So essentially I will run HBbridge which will be used to connect MMDVM with  DMlink then DMlink will be a peer to the 8300 master.

I'll assemble everything over the next week or so.

Thank you again,
Steve
_._,_._,_




Re: New Set Up MMDVM to IPSC

stevecast2024@...
 

Thank You Steve,

This is exactly the info I'm looking for. My confusion was with HBlink in the process. So essentially I will run HBbridge which will be used to connect MMDVM with  DMlink then DMlink will be a peer to the 8300 master.

I'll assemble everything over the next week or so.

Thank you again,
Steve


Re: New Set Up MMDVM to IPSC

Steve N4IRS
 

Steve,
Based on your post it's a pretty simple config. It will look like this:
MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> XPR8300

HB_Bridge (HBlink) will be a Server for MMDVM
IPSC_Bridge (DMRlink) will be a Peer for your XPR8300.

HB_Bridge is a HBlink application. you will configure hblink.cfg to create the Server.
IPSC_Bridge is a DMRlink application. you will configure dmrlink.cfg to create the Peer.

Start hblink.py in the forground, you should see the MMDVM login.
Start dmrlink.py in the foreground, you should see it login to your Master

Stop both programs

You will now configure HB_Bridge.cfg and IPSC_Bridge.cfg to talk to each other.

Start HB_Bridge in the foreground (it will run hblink.py for you) Watch MMDVM login
Start IPSC_Bridge (it will run dmrlink.py for you) Watch it login to your master.

You should now see any traffic from MMDVM "flow" to your XPR8300 Master.

Hope this helps,

73, Steve N4IRS



On 10/10/2017 11:13 PM, stevecast2024@... wrote:
Hello All,

If I am wrong in asking this here please feel free to blast me or point me to the correct location. I have read the readme as well as the CFG files but I may be missing a key piece of information that will make this all click for me.

I have an XPR8300 that I would like to run as an IPSC master. This replaced a Kenwood TKR-850 when I switched the site over to DMR. I was going to purchase a second XPR8300 or 8400 for a new site that I am hoping to add but I have also been in the process of adding MMDVM to the Kenwood repeater. I would like to configure the Kenwood with MMDVM to act as a peer to the XPR8300 master. Can I simply connect MMDVM to DMRLINK and configure DMRLINK as a peer to connect to XPR8300 IPSC? Would I have to connect to HBLINK first, and then connect to DMRLINK? Right now I want to link just these 2 repeaters without going to BM or any other network. A basic IPSC Master with one Peer setup.

Thank You Much... You are all a huge asset to the community!
Steve


Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi guys are there any news?

I know Luc is very busy at this time but source codes are available and if anyone knows the c ++ I think it's not difficult to understand what XLX asks and responds.

If there is a chance to do some test I am very happy, as mentioned above it is very important to get a hblink collector that takes the dmr flow from a server and sends it to XLX.

Important: On XLX, you must indicate, via a TG, which module connects at startup.

Thanks to everyone
David

2017-10-05 16:36 GMT+02:00 Cort N0MJS <n0mjs@...>:

I guess I should have said “Before we bug him again”.


On Oct 5, 2017, at 8:33 AM, Steve N4IRS <szingman@...> wrote:

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206



New Set Up MMDVM to IPSC

stevecast2024@...
 

Hello All,

If I am wrong in asking this here please feel free to blast me or point me to the correct location. I have read the readme as well as the CFG files but I may be missing a key piece of information that will make this all click for me.

I have an XPR8300 that I would like to run as an IPSC master. This replaced a Kenwood TKR-850 when I switched the site over to DMR. I was going to purchase a second XPR8300 or 8400 for a new site that I am hoping to add but I have also been in the process of adding MMDVM to the Kenwood repeater. I would like to configure the Kenwood with MMDVM to act as a peer to the XPR8300 master. Can I simply connect MMDVM to DMRLINK and configure DMRLINK as a peer to connect to XPR8300 IPSC? Would I have to connect to HBLINK first, and then connect to DMRLINK? Right now I want to link just these 2 repeaters without going to BM or any other network. A basic IPSC Master with one Peer setup.

Thank You Much... You are all a huge asset to the community!
Steve


Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

I guess I should have said “Before we bug him again”.


On Oct 5, 2017, at 8:33 AM, Steve N4IRS <szingman@...> wrote:

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206


Cort Buffington
785-865-7206


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Agreed,
I just wanted to report where we stood. If I hear from him before Monday, I'll let everyone know.

Steve

On 10/5/2017 10:31 AM, Cort N0MJS wrote:
Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206

_._,_._,_




Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

Luc may be busy like us…. Give him through the weekend?

On Oct 5, 2017, at 8:24 AM, Steve N4IRS <szingman@...> wrote:

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve

Cort Buffington
785-865-7206


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

As of today 10/5/2017 I do not have a reply from Luc nor do I see any change to the XLX source.

Steve


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Will,
We are discussing the protocol of the communications between the client (MMDVMGost, DMRGateway HBlink) and the server (BM, HBlink, DMR+).

Thanks, Steve


Re: Current status DMRlink, HBlink DVSwitch

Will - W4WWM <w4wwm@...>
 


Steve,

John - K6KD and Bob- W6KD and his group has XLX313 transcoding server and it returns DMR ID's and call sign. 

Will / W4WWM


On 10/3/2017 11:21 AM, Steve N4IRS wrote:
David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

I have sent Luc a E-Mail requesting a change to XLX to provide the repeater ID along with the ACK. I'll post when I get a reply.

73, Steve N4IRS

On 10/3/2017 12:30 PM, Cort N0MJS wrote:
Guys,

With your help, I now have a functioning config with hblink.py connecting to XLX and have isolated what is happening.

The real fix isn’t likely as simple as making whatever the easiest code modification to hblink.py is to get XLX to work. We also don’t know what (if any) other changes to the protocol exist in XLX. It’s going to take just a little big longer to try and fix this the right way as opposed to fixing it the fastest way.

Please give us a few days to get this sorted. It’s a hobby for us. Steve, Mike and I all have day jobs and lives to juggle here. Our commitment to “free and open” comes with a price — and that price is usually giving us a bit of space to work. We’ll get it soon — but the goal here is the right fix, not the fastest thing we can do to make hblink.py connect to XLX.

0x49 DE N0MJS


On Oct 3, 2017, at 11:21 AM, Steve N4IRS <szingman@...> wrote:

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.

Cort Buffington
785-865-7206



Re: Current status DMRlink, HBlink DVSwitch

Cort N0MJS <n0mjs@...>
 

Guys,

With your help, I now have a functioning config with hblink.py connecting to XLX and have isolated what is happening.

The real fix isn’t likely as simple as making whatever the easiest code modification to hblink.py is to get XLX to work. We also don’t know what (if any) other changes to the protocol exist in XLX. It’s going to take just a little big longer to try and fix this the right way as opposed to fixing it the fastest way.

Please give us a few days to get this sorted. It’s a hobby for us. Steve, Mike and I all have day jobs and lives to juggle here. Our commitment to “free and open” comes with a price — and that price is usually giving us a bit of space to work. We’ll get it soon — but the goal here is the right fix, not the fastest thing we can do to make hblink.py connect to XLX.

0x49 DE N0MJS


On Oct 3, 2017, at 11:21 AM, Steve N4IRS <szingman@...> wrote:

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.

Cort Buffington
785-865-7206


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

David,
That is true that MMDVMHost does not have a problem connecting to XLX. MMDVM host does not have a problem connecting to XLX because it ignores the response. Just as HB does not have a problem connecting to DMRGateway, BM, and DMR Master.
As Matthew pointed out, "XLX950 is not returning the Repeater ID after the RPTACK" Which I believe it should.

Steve

On 10/3/2017 11:42 AM, david bencini ik5xmk wrote:
Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:
Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP



_._,_.


Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi Steve, you are right, but MMDVM repeaters have no problems to connect to XLX servers at the moment, so can we find a solution/patch to hblink project ?
Can i help you in any ways? Have you a code to test "on the fly" ? :)
It is very import to have finally a dmr data flow from a dmr net to an xlx reflector with transcoder on board.
My systems are available for any test

Thank you very much guys

David

2017-10-03 16:08 GMT+02:00 Steve N4IRS <szingman@...>:

Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP




Re: Current status DMRlink, HBlink DVSwitch

Matthew 2E0SIP
 

Hi Steve,

No problem. I was reading the specification and scratching my head because as you say it has been implemented differently in various projects.
I think the application of RFC2119 to the specification would be a good idea in future.

Cheers,

Matthew


Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS
 

Matthew,
Thank you for the captures and comments. That's consistent with what we think are the inconstancy of HB Protocol. The published document, The source code without comments and multiple servers do it "their way" Maybe a effort to create a true protocol document would be worthwhile. Something that actually documents what is happening. We could use it to convince the different parties to come to some agreement.  

Thanks, Steve

--
The nice thing about standards is that there are so many to choose from!


On 10/2/2017 7:12 PM, Matthew 2E0SIP wrote:

Hi Steve,

Heres the login details for XLX950-

Address=xlx950.epf.lu
Port=62030
Password=passw0rd

I performed some packet captures direct from MMDVMHost and it looks as though XLX950 is not returning the Repeater ID after the RPTACK. I've checked the source and it doesn't look like MMDVMHost or DMRGateway are validating the repeater ID but HBLink is, causing it to fail. Interestingly enough, DMRGateway does include the Repeater ID when it ACK's the MMDVMHost login. 


I've attached the packet captures-

mmdvm_bm.pcap (successful BM login, showing RPTACK with Repeater ID)

mmdvm_xlx.pcap (succesfull XLX login, showing RPTACK without Repeater ID)

 

I guess to be inline with MMDVMHost and DMRGateway, HBlink shouldn't validate the repeater ID when it receives an RTPACK from a master, but should include the ID when it sends a RPTACK to a master.

I hope that helps,

Matthew

2E0SIP


10101 - 10120 of 10557