locked HBLINK ECHO-PARROT and DudeSTAR #hblink #closed #echo #dudestar #parrot


Heitor Mercaldi
 

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 ?


Corey Dean N3FE
 

What do you logs show you?

 


On 2021-03-17 11:44, Heitor Mercaldi wrote:

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 ?


Heitor Mercaldi
 

from parrot.log

# TX (1) - from radio (ID:1000007)
INFO 2021-03-17 13:02:43,529 (PARROT) *START RECORDING* STREAM ID: 2539034976 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2
INFO 2021-03-17 13:02:48,746 (PARROT) *END   RECORDING* STREAM ID: 2539034976
# ECHO (1) from radio TX
INFO 2021-03-17 13:02:50,748 (PARROT) *START  PLAYBACK* STREAM ID: 2539034976 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2, Duration: 5.217082977294922
INFO 2021-03-17 13:03:02,272 (PARROT) *END    PLAYBACK* STREAM ID: 2539034976
# ECHO (1) playback END

# TX (2) - from Radio (ID:1000007)
INFO 2021-03-17 13:03:13,947 (PARROT) *START RECORDING* STREAM ID: 2358276375 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2
INFO 2021-03-17 13:03:20,251 (PARROT) *END   RECORDING* STREAM ID: 2358276375
# ECHO (2) from radio TX
INFO 2021-03-17 13:03:22,253 (PARROT) *START  PLAYBACK* STREAM ID: 2358276375 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2, Duration: 6.303557872772217
INFO 2021-03-17 13:03:28,407 (PARROT) *END    PLAYBACK* STREAM ID: 2358276375

# TX (3) - from DudeStar (ID: 7242164) 
INFO 2021-03-17 13:03:37,227 (PARROT) *START RECORDING* STREAM ID: 4198236160 SUB: 7242164 (7242164) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2
# NO *END RECORDING for this TX 

# TX (4) - from radio
INFO 2021-03-17 13:04:16,520 (PARROT) *START RECORDING* STREAM ID: 3887657222 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2
INFO 2021-03-17 13:04:22,108 (PARROT) *END   RECORDING* STREAM ID: 3887657222
# END RECORDING is OK now

# ECHO STREAM ID shows only the last Record, but the listened audio comming with last 2 records concatenated like a FIFO.
INFO 2021-03-17 13:04:24,110 (PARROT) *START  PLAYBACK* STREAM ID: 3887657222 SUB: 1000007 (1000007) REPEATER: 9999 (9999) TGID 9999 (9999), TS 2, Duration: 5.58738112449646
INFO 2021-03-17 13:04:35,813 (PARROT) *END    PLAYBACK* STREAM ID: 3887657222



Heitor Mercaldi
 
Edited

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


Randy AA6RH
 

I thought BM Parrot was 9990, not 9999

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


Heitor Mercaldi
 
Edited

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


Randy AA6RH
 

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) 😁


Steve N4IRS
 
Edited

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


Randy AA6RH
 

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) 😁


Randy AA6RH
 

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) 😁


Randy AA6RH
 

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) 😁


Randy AA6RH
 
Edited

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) 😁


Heitor Mercaldi
 

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
Yes, i am using playback.py for PARROT.
I read the source code of playback.py, but i am have not enough skills in Python for test any modifications.

About my server configs i get instructions from
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"
 
BRIDGES = {
    'HBLink-Peer-TG13': [
            {'SYSTEM': 'MASTER-1',            'TS': 2, 'TGID': 13,       'ACTIVE': True,  'TIMEOUT': 30, 'TO_TYPE':'NONE',  'ON': [],       'OFF': [],    'RESET': []},
        ],
    'HBLink-EchoTest-TG9999': [
            {'SYSTEM': 'ECHOTEST',            'TS': 2, 'TGID': 9999,     'ACTIVE': True,  'TIMEOUT': 1,  'TO_TYPE':'NONE', 'ON': [],         'OFF': [],      'RESET': []},
            {'SYSTEM': 'MASTER-1',            'TS': 2, 'TGID': 9999,     'ACTIVE': True,  'TIMEOUT': 1,  'TO_TYPE':'NONE, 'ON': [],         'OFF': [],      'RESET': []},
        ]
}

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.


Heitor Mercaldi
 

That is the ugly solution that i think for playback.py

#line 112
def dmrd_received(self, _peer_id, _rf_src, _dst_id, _seq, _slot, _call_type, _frame_type, _dtype_vseq, _stream_id, _data):
...
#line 142
else:
                call_duration = pkt_time - self.STATUS['RX_START']
if (self.CALL_DATA and call_duration < 60):
                self.CALL_DATA.append(_data)
else:
logger.info('(%s) *END   RECORDING* STREAM ID: %s', self._system, int_id(_stream_id))
                sleep(2)
                logger.info('(%s) *START TIMEOUT PLAYBACK* STREAM ID: %s SUB: %s (%s) REPEATER: %s (%s) TGID %s (%s), TS %s, Duration: %s', \
                                  self._system, int_id(_stream_id), get_alias(_rf_src, subscriber_ids), int_id(_rf_src), get_alias(_peer_id, peer_ids), int_id(_peer_id), get_alias(_dst_id, talkgroup_ids), int_id(_dst_id), _slot, call_duration)
                for i in self.CALL_DATA:
                    self.send_system(i)
                    #print(i)
                    sleep(0.06)
                self.CALL_DATA = []
                logger.info('(%s) *END  TIMEOUT  PLAYBACK* STREAM ID: %s', self._system, int_id(_stream_id))
 
            # Mark status variables for use later
            self.STATUS[_slot]['RX_RFS']       = _rf_src


Randy AA6RH
 

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) 😁


Eric - KF7EEL
 

Perhaps the addition of a timeout condition in line 128 could work? I'll play with this idea a little later.


On Fri, Mar 19, 2021, 11:23 Randy AA6RH <aa6rh@...> wrote:
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) 😁


Randy AA6RH
 

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) 😁


Randy AA6RH
 

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) 😁


Heitor Mercaldi
 

Thank you Randy,

73 from PU2XTL.