Hello,

I have sucessfully configured a HBlink3 private server ( http://vps29637.publiccloud.com.br) with PARROT just for learning purposes.
I use just 2 TGs:  13 for Local and 9999 for ECHO - parrot.
This week i was testing the PC version of DroidStar (DudeStar) connected my server and realize that i can use it at my local TG 13, however its doesn't work at PARROT 9999.
Other tests shows that the same issue happens in any HBlink or FreeDMR servers.
Additionally i get the following behavior in my server: 
1) TX from RADIO to 9999 -> Everything works fine and all nodes (repeaters, hotspots, DudeStar) receive the transmision and ECHO return;
2) TX from DudeStar to 9999 -> Everyone receive the transmision but no return, additionaly the PARROT call shows a TX time of a hundreds seconds;
3) TX from Radio to 9999 after DudeStar tx to same TG - > Everyone receives the radio TX and the ECHO returns to all connected nodes  with the last 2 transmissions like a FIFO.

Anyone could explain me this behavior ?

What do you logs show you?

At the " Call log window"

 

 ## TX (1) - from radio (ID:1000007)
 13:02:43 VOICE START SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:02:48 VOICE END   SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 5s 
 13:02:50 VOICE START SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:02:57 VOICE START SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:03:02 VOICE END   SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 5s 
 ## TX (2) - from Radio (ID:1000007)
 13:03:13 VOICE START SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:03:20 VOICE END   SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 6s 
 13:03:22 VOICE START SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:03:28 VOICE END   SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 6s 
 ## TX (3) - from DudeStar (ID: 7242164) 
 13:03:37 VOICE START SYS: MASTER-1 SRC: 724216410; 724216410 TS: 2 TGID: 9999    Papagaio          SUB: 7242164  ; 7242164           
 13:03:48 VOICE END   SYS: MASTER-1 SRC: 724216410; 724216410 TS: 2 TGID: 9999    Papagaio          SUB: 7242164  ; 7242164            Time: 6s 
 ## TX (4) - from radio
 13:04:16 VOICE START SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3
 13:04:22 VOICE END   SYS: MASTER-1 SRC: 724216401; 724216401 TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 5s 
 13:04:24 VOICE START SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 7242164  ; 7242164  -----------------------------> DudeStar audio ECHO
 13:04:30 VOICE START SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3  ------------------> Radio audio ECHO
 13:04:35 VOICE END   SYS: ECHOTEST SRC: 9999     ; 9999      TS: 2 TGID: 9999    Papagaio          SUB: 1000007  ; Heitor,  heitor h3 Time: 5s 

I thought BM Parrot was 9990, not 9999

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Yes it is, but its not the point. The point is that the DudeStar crashes the ECHO service in HBlink3.

I'm not entirely convinced it's HBLink that is at issue here, since BM eventually delivers the audio. It's not like HBLink is storing it somewhere until a DMR subscriber radio actually tries the talk group again (at least that's the way you described this).

DudeStar being a terminal access client, and BM going through the process of requiring such clients to connect in a different way than repeaters and hotspots leaves me thinking there's some strangeness happening there. It may ultimately come down to "don't connect DudeStar to HBLink until we can implement the connection protocol in the same way that BM does" (if that is even possible).

HBLink simply doesn't have a sophisticated way to store traffic for later delivery, so I am looking for more data to support the claim that HBLink is the source of the problem here.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

DudeStar and DroidStar like all currently released mobile / PC software use the MMDVM protocol to connect to a DMR Master. BM is requiring this type of software to use the Open DMR Terminal Protocol. From comments I've seen from the author, he is not moving to ODMRTP. He is going to continue supporting HB based systems. I think he is pretty motivated to make things work. I suggest you contact him to help resolve the issue with HBlink. 

As a side note, DVSwitch is beta testing our implementation of ODMRTP called Simple Terminal Feature Update to allow users to continue connecting to BM. Simple Terminal Feature Update is our answer to BM. If all goes well, we will release on March 31. 

Steve N4IRS

On Thu, Mar 18, 2021 at 11:50 AM, Steve N4IRS wrote:

Open DMR Terminal Protocol

ODMRTP

That's quite a mouthful there, isn't it.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

On Thu, Mar 18, 2021 at 11:50 AM, Steve N4IRS wrote:

DudeStar and DroidStar like all currently released mobile / PC software use the MMDVM protocol to connect to a DMR Master. BM is requiring this type of software to use the Open DMR Terminal Protocol. From comments I've seen from the author, he is not moving to ODMRTP. He is going to continue supporting HB based systems. I think he is pretty motivated to make things work. I suggest you contact him to help resolve the issue with HBlink. 

As a side note, DVSwitch is beta testing our implementation of ODMRTP called Simple Terminal Feature Update to allow users to continue connecting to BM. Simple Terminal Feature Update is our answer to BM. If all goes well, we will release on March 31. 

Steve N4IRS

Clever acronyms aside, I get your meaning. I'll see if I can contact him and figure out what's going on between DroidStar/DudeStar and HBLink

--R 
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Wait a second. The parrot you're using here, is it playback.py from this repository?

I need to see your config file for HBLink. Please copy/paste it in a reply or attach it, redacted if necessary.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Yeah, it's like the lightbulb went on here.

Playback.py is dead simple as far as a parrot application goes. It's also not particularly well-designed or executed (no slight on Cort or Steve for writing it that way, I think it was put in the repo as a proof-of-concept, not a complete parrot/echo app.)

Playback.py relies entirely on seeing a voice terminator packet come in as the trigger to play out the audio. There really should be some kind of timer that expires after a few hundred milliseconds of not receiving any more voice packets from the stream, but no such timer exists in the app as written (which is what I mean by the app being proof-of-concept rather than a robust app for end-user enjoyment).

No voice terminator packet, no echo. It took the subscriber radio on the second transmission to knock playback.py loose and allow it to play out the stored audio.

Another checklist item, I suppose. If we're going to have a playback.py app in the repo, it should be robust enough to deal with a badly-behaving subscriber, or a network where the voice terminator packets get lost or never arrive.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

On Fri, Mar 19, 2021 at 06:58 AM, Randy AA6RH wrote:

or a network where the voice terminator packets get lost or never arrive

https://www.chrishoodblog.com/make-your-own-dmr-server/
and
http://sp2ong.noip.pl/pl/blog/stworz-swoj-wlasny-serwer-dmr

with some modifications only in "rultes.py"

However, based on your last 2 messages i believe that my first question was answered.
The idea to put a timer after no packet reception is great.
When you get the code for that i can run the tests in my server, if you want.
It is already online and i can send the configs for client conections and  do the tests.
I have signed a VPS until Abril 10, so its my dead line to help with this task.

I wish it were that simple.

The problem stems from the following: the app, as written, only does processing when it receives network traffic. That's what the dmrd_received() function is all about.

So what does it mean if the network traffic the app is looking for never arrives? You can't just delay() and expect it to work. The only time this function gets called is when there's network traffic coming in.

I'll have to devise something else. I'll look at other parts of the code base to see if and what Cort did to address this, because this isn't the only situation where this might happen. Pretty sure bridge.py has something.

I'll let you know what I find.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

I don't think line 128 factors into this. The playback.py script is pretty stripped down, so it's easy to see what's going on.

• Sets up the Twisted reactor object based on configuration
• The only thing added to this app is the dmrd_received() method, which only gets called when network traffic comes in. <<==== THIS RIGHT HERE is the reason timers and timeouts inside of dmrd_received will not work. The method can't sit around waiting to see if a voice terminator packet shows up. That's because this is UDP and there's no connection per se. The playback.py app processes whatever comes in, and nothing else.
• There are other things we can leverage in Twisted, including timers that will dispatch regularly where in-process voice streams can be swept up and handled. That's where I'm looking to make changes. I don't think there's necessarily any change needed in dmrd_received() in the code as it is written right now. That conclusion might change, but it won't be a huge rewrite of the method, just tweaks.

Thanks for looking into it. Read up on LoopingCall (https://twistedmatrix.com/documents/current/api/twisted.internet.task.LoopingCall.html) in Twisted if you want to understand what I'm thinking about here.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

The latest from nostar (maintainer of DudeStar):

Ah yes, the terminator frame was not being sent correctly. Try the latest git.

So Heitor, I would suggest you take a look at the latest code drop for DudeStar and try your setup again.

In the meantime, we will take up the task of hardening playback.py so that it is more robust and able to recover cleanly from a situation like this in the future.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁

Thank you Randy,

73 from PU2XTL.