Date   

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



Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi Steve and all, 

i've a dedicated MMDVM DMR RPT to connect our XLX reflector,

this is MMDVM.ini configuration for DMR section to use DMRGateway software:


[DMR Network]
Enable=1
Address=127.0.0.1
Port=62031
Jitter=300
Local=62032
Password=passw0rd
Options=
Slot1=1
Slot2=1
Debug=0

This is DMRGateway.ini configuration, to connect XLX039 for trascoding module B (Italy (TG 4002 to link and TG 222 to speak)) on SLOT 1 and XLX077 (Module R (4018 and TG 22251 to speak), Tuscany Region) on SLOT 2 


[General]
Timeout=10
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

[XLX Network 1]
#*************************************
# CONNESSIONE SLOT 1 A NAZIONALE DSTAR
#*************************************
Enabled=1
Name=XLX039
Port=62030
Slot=1
TG=222
Base=4000
Startup=4002
Relink=10
Password=passw0rd
Debug=0

[XLX Network 2]
#***************************************
# CONNESSIONE SLOT 2 A REGIONALE R DSTAR
#***************************************
Enabled=1
Name=XLX077
Port=62030
Slot=2
TG=22251
Startup=4018
Relink=10
Password=passw0rd
Debug=0

All is working very well, with a good audio (using 2 ThumbDV USB to transcode).

Our RPT dashboard: http://185.109.24.70:8080/


Our DMR MASTER (where i do tests) dashboard: http://dmrmaster.grupporadiofirenze.net/

Thank you

David IK5XMK



2017-10-02 23:55 GMT+02:00 Steve N4IRS <szingman@...>:

David,
That was as I expected. We are looking at this. I will say that the HBlink client instance has no trouble connecting to BM, DMR Master, DMRGateway and HBlink server instance. We are still going to see if we can isolate the issue. I do have a request, to make our lives easier can someone supply us with the login info needed to connect to a existing XLX DMR?

Thanks, Steve N4IRS

On 10/02/2017 06:24 AM, david bencini ik5xmk wrote:
Hi Steve,

i'm making some tests, to dmr master server no problem to connect to, 
but on xlx side i've this error:

DEBUG 2017-10-02 06:13:39,719 Logging system started, anything from here on gets logged
INFO 2017-10-02 06:13:39,720 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2017-10-02 06:13:39,721 (REPEATER-1) Client maintenance loop started
INFO 2017-10-02 06:13:39,722 (REPEATER-1) Sending login request to master 185.203.118.66:55555
DEBUG 2017-10-02 06:13:39,722 CLIENT instance created: REPEATER-1, <__main__.HBSYSTEM instance at 0x7fbf0433aab8>
DEBUG 2017-10-02 06:13:39,723 (REPEATER-2) Client maintenance loop started
INFO 2017-10-02 06:13:39,723 (REPEATER-2) Sending login request to master 5.249.151.111:62030
DEBUG 2017-10-02 06:13:39,723 CLIENT instance created: REPEATER-2, <__main__.HBSYSTEM instance at 0x7fbf040fb878>
INFO 2017-10-02 06:13:39,724 (REPEATER-1) Repeater Login ACK Received with 32bit ID: 2225069
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Authentication Accepted
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Configuration Sent
DEBUG 2017-10-02 06:13:39,726 (REPEATER-1) MSTPONG Received. Pongs Since Connected: 1
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Repeater Configuration Accepted
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Connection to Master Completed
INFO 2017-10-02 06:13:39,768 (REPEATER-2) Repeater Login ACK Received with 32bit ID: 1228258867
ERROR 2017-10-02 06:13:39,813 (REPEATER-2) Master ACK Contained wrong ID - Connection Reset




Re: Current status DMRlink, HBlink DVSwitch

Matthew 2E0SIP
 

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
 

David,
That was as I expected. We are looking at this. I will say that the HBlink client instance has no trouble connecting to BM, DMR Master, DMRGateway and HBlink server instance. We are still going to see if we can isolate the issue. I do have a request, to make our lives easier can someone supply us with the login info needed to connect to a existing XLX DMR?

Thanks, Steve N4IRS

On 10/02/2017 06:24 AM, david bencini ik5xmk wrote:
Hi Steve,

i'm making some tests, to dmr master server no problem to connect to, 
but on xlx side i've this error:

DEBUG 2017-10-02 06:13:39,719 Logging system started, anything from here on gets logged
INFO 2017-10-02 06:13:39,720 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2017-10-02 06:13:39,721 (REPEATER-1) Client maintenance loop started
INFO 2017-10-02 06:13:39,722 (REPEATER-1) Sending login request to master 185.203.118.66:55555
DEBUG 2017-10-02 06:13:39,722 CLIENT instance created: REPEATER-1, <__main__.HBSYSTEM instance at 0x7fbf0433aab8>
DEBUG 2017-10-02 06:13:39,723 (REPEATER-2) Client maintenance loop started
INFO 2017-10-02 06:13:39,723 (REPEATER-2) Sending login request to master 5.249.151.111:62030
DEBUG 2017-10-02 06:13:39,723 CLIENT instance created: REPEATER-2, <__main__.HBSYSTEM instance at 0x7fbf040fb878>
INFO 2017-10-02 06:13:39,724 (REPEATER-1) Repeater Login ACK Received with 32bit ID: 2225069
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Authentication Accepted
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Configuration Sent
DEBUG 2017-10-02 06:13:39,726 (REPEATER-1) MSTPONG Received. Pongs Since Connected: 1
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Repeater Configuration Accepted
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Connection to Master Completed
INFO 2017-10-02 06:13:39,768 (REPEATER-2) Repeater Login ACK Received with 32bit ID: 1228258867
ERROR 2017-10-02 06:13:39,813 (REPEATER-2) Master ACK Contained wrong ID - Connection Reset



Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk
 

Hi Steve,

i'm making some tests, to dmr master server no problem to connect to, 
but on xlx side i've this error:

DEBUG 2017-10-02 06:13:39,719 Logging system started, anything from here on gets logged
INFO 2017-10-02 06:13:39,720 HBlink 'HBlink.py' (c) 2016 N0MJS & the K0USY Group - SYSTEM STARTING...
DEBUG 2017-10-02 06:13:39,721 (REPEATER-1) Client maintenance loop started
INFO 2017-10-02 06:13:39,722 (REPEATER-1) Sending login request to master 185.203.118.66:55555
DEBUG 2017-10-02 06:13:39,722 CLIENT instance created: REPEATER-1, <__main__.HBSYSTEM instance at 0x7fbf0433aab8>
DEBUG 2017-10-02 06:13:39,723 (REPEATER-2) Client maintenance loop started
INFO 2017-10-02 06:13:39,723 (REPEATER-2) Sending login request to master 5.249.151.111:62030
DEBUG 2017-10-02 06:13:39,723 CLIENT instance created: REPEATER-2, <__main__.HBSYSTEM instance at 0x7fbf040fb878>
INFO 2017-10-02 06:13:39,724 (REPEATER-1) Repeater Login ACK Received with 32bit ID: 2225069
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Authentication Accepted
INFO 2017-10-02 06:13:39,725 (REPEATER-1) Repeater Configuration Sent
DEBUG 2017-10-02 06:13:39,726 (REPEATER-1) MSTPONG Received. Pongs Since Connected: 1
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Repeater Configuration Accepted
INFO 2017-10-02 06:13:39,727 (REPEATER-1) Connection to Master Completed
INFO 2017-10-02 06:13:39,768 (REPEATER-2) Repeater Login ACK Received with 32bit ID: 1228258867
ERROR 2017-10-02 06:13:39,813 (REPEATER-2) Master ACK Contained wrong ID - Connection Reset
DEBUG 2017-10-02 06:13:44,725 (REPEATER-1) Client maintenance loop started
DEBUG 2017-10-02 06:13:44,726 (REPEATER-1) RPTPING Sent to Master. Pings Since Connected: 1
DEBUG 2017-10-02 06:13:44,726 (REPEATER-2) Client maintenance loop started
INFO 2017-10-02 06:13:44,726 (REPEATER-2) Sending login request to master 5.249.151.111:62030
INFO 2017-10-02 06:13:44,771 (REPEATER-2) Repeater Login ACK Received with 32bit ID: 1228258867
ERROR 2017-10-02 06:13:44,816 (REPEATER-2) Master ACK Contained wrong ID - Connection Reset
^CINFO 2017-10-02 06:13:45,300 SHUTDOWN: HBLINK IS TERMINATING WITH SIGNAL 2
INFO 2017-10-02 06:13:45,300 SHUTDOWN: DE-REGISTER SYSTEM: REPEATER-1
INFO 2017-10-02 06:13:45,301 (REPEATER-1) De-Registeration sent to Master: 185.203.118.66:55555
INFO 2017-10-02 06:13:45,301 SHUTDOWN: DE-REGISTER SYSTEM: REPEATER-2
INFO 2017-10-02 06:13:45,302 (REPEATER-2) De-Registeration sent to Master: 5.249.151.111:62030
INFO 2017-10-02 06:13:45,302 SHUTDOWN: ALL SYSTEM HANDLERS EXECUTED - STOPPING REACTOR

form xlx log:

root@superciuk:~# tail -f /var/log/messages
Oct  2 12:19:55 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:19:55 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:00 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:00 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:05 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:05 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:10 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:10 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:15 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:15 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:20 superciuk xlxd: DMRmmdvm connect packet from IZ5ILG  B at 185.177.59.72
Oct  2 12:20:20 superciuk xlxd: DMRmmdvm authentication packet from IZ5ILG  B at 185.177.59.72

I tried with some callsigns and ids, but i think there is a problem in the code linking to xlx...
can you help me ?

thank you

David






2017-09-29 11:39 GMT+02:00 Steve N4IRS <szingman@...>:

David,
Your next step is to make sure HBlink can login to the 2 servers.
I suggest you test each connection separately by disabling one of the clients.
Rename or copy hblink-SAMPLE.cfg to hblink.cfg.
Run hblink.py in the foreground and watch the console to verify valid login.
You can then reduce the log level by changing LOG_LEVEL: DEBUG to LOG_LEVEL: INFO

Once that works, enable both clients, run hblink.py  and watch the console for errors.
If everything looks good you can run hb_bridge_all.py and test for traffic passing between the 2 servers.

73, Steve N4IRS

 

On 09/29/2017 04:54 AM, david bencini ik5xmk wrote:
Hi Steve, i'm looking for hblink-SAMPLE.cfg to work with this software.

Can you help me to understand how to handle this link?

In practice hblink should be able to connect as mmdvm client to the XLX dstar reflector, so act in configuration in this way?

[REPEATER-1]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP:
PORT: 62030
MASTER_PORT: 62030
PASSPHRASE: homebrew
CALLSIGN: IK5XMK
RADIO_ID: 2225013
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
...

and then, on the other side, to DMR MASTER server as mmdvm client repeater:


[REPEATER-2]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP:
PORT: 55555
MASTER_PORT: 55555
PASSPHRASE: passw0rd
CALLSIGN: IK5XMK
RADIO_ID: 2225013
RX_FREQ: 449000000
TX_FREQ: 444000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
...

on [MASTER-1]
ENABLED: False

What else do you need to hblink to work?
Is this a way to think about a collector between the two networks? This is for the first step to try the link...

Thank you,
David

... must i to open a new topic for this?

2017-09-28 21:26 GMT+02:00 Steve N4IRS <szingman@...>:
David,
Since both "endpoints" speak HBR protocol (MMDVM) it might be as simple as using HBlink:
dmrmaster <---> HBlink <---> XLX.
The problem that you might run into that HBlink does omore checking of the source ID. That is where DMRGateway came in.
Cort or Mike may chime in will a more detailed answer. Since it's only software (did I really say that?) It's worth a try. Take it one side at a time and build into the middle.

Steve

On 9/28/2017 3:15 PM, david bencini ik5xmk wrote:
Thank you Steve. It can be a way to try. Good!

At the end (only me ?) i need a software that side A it connects an xlx module (like standard mmdvm repeater) and
side B it connects a dmrmaster server (like standard mmdvm repeater), so when i hit  a TG i can hear me on dstar and viceversa.
Transcoding is fully working on my xlx.
I think (wrong tinking?) that it is not difficult to bring a data flow from a system to other, with same homebrew protocol.

by the way, thank you and best 73 to you and to all guys on group

David IK5XMK

2017-09-28 20:59 GMT+02:00 Steve N4IRS <szingman@...>:
David,
I do not know of a way to connect DMR+, IPSC2 or DMRMaster to XLX. If, and it's a BIG if, IPSC2 can connect to IPSC_Bridge (DMRlink) it might go something like this:
IPSC2 <---> IPSC_Bridge <---> HB_Bridge <---> DMRGateway <---> XLX. I think I remember someone posting that he needed DMRGateway from G4KLX to connect HB_Bridge to XLX.
Sorry I could not be of more help.

73, Steve N4IRS

On 9/28/2017 2:50 PM, david bencini ik5xmk wrote:
Hi Steve, great work !! Thank you.

Please, where can i find informations/which software/configuration about linking my dmr server (dmrmaster.webandcloud.net or ipsc2.webandcloud.net
to my xlx dstar server (http://vpngrf.webandcloud.net/db/dashboard/index.php) that it has an hardware transcoder server (2 USB ThumbDV)  into? I need a dmr flow to put into my
dstar system so i can join my dstar/dmr repeaters in my region. Now i can link my mmdvm repeater directly to xlx via dmrmmdvm protocol, and it works
very well with good audio, but a lot of friends are on dmr servers and i need a "connector" from dmr world to dstar one :)

Thank you for any infos
73, David IK5XMK






Re: DV3000

Bob N1XBM <N1XBM@...>
 

Ya I'm running the older version and ambe_audio.

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

On Sep 29, 2017 6:48 PM, "Steve N4IRS" <szingman@...> wrote:
Am I correct you are running the older DMRGateway and ambe_audio? Not saying that's it, just making sure what we are looking at.

Steve

On 09/29/2017 06:45 PM, Bob N1XBM wrote:
I noticed when talking from Allstar to BM, when I look at my zum spot running the pi-star image that my loss numbers are quite high. It seems to sound fine. I understand this is not the pi-star group or zum spot, but I've only noticed the problem when talking from analog to dmr.

Anyone eles notice this?

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


Re: DV3000

Steve N4IRS
 

Am I correct you are running the older DMRGateway and ambe_audio? Not saying that's it, just making sure what we are looking at.

Steve

On 09/29/2017 06:45 PM, Bob N1XBM wrote:
I noticed when talking from Allstar to BM, when I look at my zum spot running the pi-star image that my loss numbers are quite high. It seems to sound fine. I understand this is not the pi-star group or zum spot, but I've only noticed the problem when talking from analog to dmr.

Anyone eles notice this?

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

9441 - 9460 of 9891