I know it's been rather quiet lately. Mike and I have been working
on a number of Digital and Analog projects. Some will be
demonstrated at Dayton, so we are coming down to the wire. I have
been configuring DMRGateway on a Micro-Node DPAC for the show. It's
built on the next revision of DIAL for the RPi. Though most of the
underlying Asterisk, DMRGateway and DMRlink code is mostly unchanged
I ran in to something "interesting"
Consider the DPAC. It's a dual node AllStar server with 2 radio
ports, hardware real time clock, serial console port and dual TFT
displays. it mounts in a 1 RU box. For the demo, I set it up with 2
analog repeaters and a DMRGateway. The idea is that the DMRGateway
is a "private" node (1997) if either of the 2 analog repeaters
wanted DMR access they could just connect to 1997 and they would be
on DMR. Pretty much the same way that anyone might setup a tightly
controlled ASL <---> DMR Gateway. Using the remote control
ability built into ambe_audio a analog user can change to
pre-defined TS / TG configurations with DTMF. This can also be done
from Allmon2. There is also a standalone client coming called
DMRGui. Think a DMR node with a local mic and speaker.
Now comes the issue. We know that a DMRGateway node should be setup
with duplex = 0 and comment out the idrecording and idtalkover
entries so no ID goes out over DMR. With a duplex = 0 there should
be no hang time or telemetry. Or so would one think. Turns out that
the USRP channel driver still uses the hangtime and possibly the alt
hangtime values. If you just comment them out, you get the default
values of 5000 ms. Set hangtime and althangtime to 0 !!!
Otherwise there is a hang time between the drop of the input analog
signal and the drop of the outbound DMR signal.
We are checking the code now, and we THINK it's in the USRP channel
driver. Not sure it's a negative yet. There is a small hang built in
DMRGateway on purpose.
For INAD, 73 Steve N4IRS
--
"Anything is possible if you don't know what you are talking about."
1st Law of Logic