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