Unitrunker GUI version questions

[dwc]

Hello,

Recently I migrated from using Retro but am stumped on a couple of things here.

1. With scanning a EDACS system (site lock aside) is it normal for when I restart the program for my EDACS system to automatically get dumped into a Limbo system? Every time I restart the software this requires me to "re-insert" all of my frequencies and such so that I can continue tracking the system with a voice radio. Ideally it should open up, recognize that this is an existing system in the software and continue tracking under that system.

2. I apologize if this has been asked before. Do the remote capabilities work at all? I see check mark boxes for it but have no way of remotely connecting with another instance of Unitrunker. If this isnt a public feature yet, I would like to beta test it. Our group has a few needs for just a feature.

Thanks,

dwC

 

[mobile1]

Just click on each of the other voice channels and another window will open like you do with the control channel then enter the channel and click on the confirm box for each voice channel. Unitrunker will remember all this info for the next time you open it .

 

[offsite]

re: item 1, below --- For now, it is normal to have to re-enter the CC frequency each time the EDACS system is encountered, but it is not normal to have to re-enter all of the other stuff, too.

Once a system is populated and saved, UT will recognize it in future encounters just from the CC... and will pull up all your other value added entries for that system once the CC frequency is entered.

Since this is not happening for you, some additional subtlety must be in play here... such as the CC is being rotated between your encounters with the system.

The way I found to get around this is to label ALL the system frequencies as CCs... then, no matter which one is active, amazing UT will recognize the system and resurrect all your previous hard work.

Even if a frequency carries the CC label, it will still be recognized as a voice frequency if that is its role... so UT will still switch your voice following receiver to that frequency when its LCN is active.

-rb-

Hello,

Recently I migrated from using Retro but am stumped on a couple of things here.

1. With scanning a EDACS system (site lock aside) is it normal for when I restart the program for my EDACS system to automatically get dumped into a Limbo system? Every time I restart the software this requires me to "re-insert" all of my frequencies and such so that I can continue tracking the system with a voice radio. Ideally it should open up, recognize that this is an existing system in the software and continue tracking under that system.

dwC

 

[dwc]

Thanks for the reply. I will give all that a shot.

I am using separate control and signal/voice radios here. I find on occasion the volume on the signal/voice radio gets automatically reset down to 0 (zero) every once in a while. Has anyone encountered this?

One more thing, I know this has been beaten over and over again but the EDACS beeps on the signal/voice radio are fscking annoying. If these scanners can figure out how to Park/Mute the LCN before the beeps then software and two radios should be capable as well.

Related to this I notice once in a while that UT won't put the signal/voice radio back into Park mode before a provoice transmission starts on the same LCN that was opened up for a analog transmission. So you get to hear a whole voice transmission and a entire provoice digital crap transmission. Quite annoying indeed. I was under the impression that the voice radio was opened/closed on a LCN depending when a talkgroup is activated/deactivated. So essentially should'nt the transmission be ended as soon as that analog talkgroup stops on the CC?

</end-ramble>

Thanks for everyone's help. Keep up the good work Mr. Unitrunker.

dwC

 

[dwc]

Ok so check this out.

I am really starting to notice this issue pop up more now when the EDACS system is busy.

when a analog transmission ends and usually when its the end of the conversation and there are no further analog transmissions to be heard the voice radio will stay open on the same LCN (as per the software) and be left open for the duration of the next call, which is usually Provoice.

Please see this video:

Unitrunker EDACS Trunk Tracking Issue #1 - Screen Capture

Open it in full screen so you can see what is going on... The issue occurs around 00:40 when the digital provoice racket is heard. You can clearly see by the green LCN highlight that the voice radio was told to hang on to that voice LCN longer than it should have.

Bug perhaps?

 

[SCPD]

It is either a bug or just enough noise to miss the call grant that followed on the same channel (which is part of the reason why the voice radio lingers on the voice channel - in case you've missed a control channel message confirming the call is still active).

 

[dwc]

It is either a bug or just enough noise to miss the call grant that followed on the same channel (which is part of the reason why the voice radio lingers on the voice channel - in case you've missed a control channel message confirming the call is still active).

Thanks for the reply.

My bet is that its a bug. This particular setup is extremely close to the EDACS site. The signal radio is a Maxtrac 800.

I can give you remote access to the box if you would like to debug these issues.

Thanks,

 

[SCPD]

2. I apologize if this has been asked before. Do the remote capabilities work at all? I see check mark boxes for it but have no way of remotely connecting with another instance of Unitrunker. If this isnt a public feature yet, I would like to beta test it. Our group has a few needs for just a feature

My apologies - I missed this question the first time around. It's not yet a public feature. I hope to get the infrastructure running (ported from BSD to Linux) soon.

The idea is to "publish" your decoding receiver's control channel data stream in a peer-to-peer network by announcing your availability through the Unitrunker.com host (the machine - not the web server). That's the purpose of the "Publish" checkbox. From the Feeds tab, other peers issue queries to locate signals of interest by system type, system ID, and so on. From there, a "remote" type receiver is created that subscribes to the control channel feed. From that point on a bandwidth friendly UDP stream is delivered from publisher to subscriber. A hole punch is used to get around NAT gateways commonly found in home networks.

 

[dwc]

It is either a bug or just enough noise to miss the call grant that followed on the same channel (which is part of the reason why the voice radio lingers on the voice channel - in case you've missed a control channel message confirming the call is still active).

Ok so what is the next step here. If this is identified as a bug then is there a proper bug reporting process I need to go through or how can I help get this fixed ?

Thanks again...


d