Unitrunker Release 31

[KD8DVR]

Is there a way to configure the "users" screen to only display units the suer wants to see.

In other words, only display users in my police zone, so I can easily see if a certain police car is online or offline?

If not, is it planned for a future feature?

Thanks.

I got it set up by using the "use" field.

 

[Adraenyse]

I feel like I do nothing but complain, but I found another one .. after going away from the PC for a while, I come back and there is no voice audio. Looking at the mixer shows the application is no longer attached to an output. If I stop and re-start the dongle in Unitrunker, it reappears in the mixer and voice works fine.

If it means anything, I am using a realtek based audio chipset with front and rear outputs split - so the scanner voice is directed at the 2nd output, not the main mix.

I'm trying the latest preview edition now to see if it reoccurs.

 

[Adraenyse]

Running the latest preview version with two dongles, 1 for signal, 1 with 3 VCO for voice, and I am having great results. No muting issues and no 'extra' transmissions, sound card hasn't detached, VCO priorities are being honored, multiple voice streams work. So far so good! Keeping my toes crossed.

I will add though I have nothing locked out, I am prioritizing based on priority/rank settings only. Will try the lock outs in a couple days if this stays stable.

 

[KD8DVR]

I feel like I do nothing but complain, but I found another one .. after going away from the PC for a while, I come back and there is no voice audio. Looking at the mixer shows the application is no longer attached to an output. If I stop and re-start the dongle in Unitrunker, it reappears in the mixer and voice works fine.

If it means anything, I am using a realtek based audio chipset with front and rear outputs split - so the scanner voice is directed at the 2nd output, not the main mix.

I'm trying the latest preview edition now to see if it reoccurs.

Today I started mine up, had to crank the gain up to 400.. still sounds like crap. Analog system. Bizarre. Worked great last night.

I wonder if Windows is doing something weird to prepare for Windows 10 release. It did attempt to update this morning. My dongle drivers were untouched, although I reinstalled them. Even did a dongle swapout to verify I had no hardware failure.

 

[KD8DVR]

At any rate, everything is working fine. I *did* detect a strong signal right smack dab in the middle of where the affected system is. No idea what it was, where it came from, or where it went. It's gone. 858.600 or thereabouts.

 

[Adraenyse]

When the system got busy during the daytime, my extra transmission problems came back.

As nlurker did, I went back to .30 and the issues go away. I just lose the multiple voice channels which was handy, but it seems that the feature must be carrying the bug somehow.

 

[bassjunkie]

Bit of feedback to chuck in with the rest - I just moved my gear to another laptop, fresh install of Windows 10, single R820T dongle powering an MPT1327 system. Sounds good but there seems to be a clicking sound in the background - can't tell if it's from two VCOs or from running the USB cable past a few power cables, will do some more testing on the weekend to confirm. Noted that the clicking disappeared when tuned to a voice channel that was out of range from the signal channel, indicating it may be due to multiple VCOs. Have a second tuner coming soon, so that will eliminate that variable too.

The other thing to note is that the signal seems to drop away pretty frequently, shows as a little choppy in the scope but just drops away to 0, haven't been able to correlate with anything there. May be due to AGC, playing with some settings there.

Did have some of the issues mentioned by others where the device needed to be stopped and started a few times, and gain had to continuously be tweaked, but stable at the moment (fingers crossed).

Using the latest build from the website.

Edit: Ended up switching back to two receivers, one E4000 piping audio via SDRSharp for the control channel, and the R820T with a single VCO for voice channels. Clicking sound is gone, no other changes were made so looks like it's most likely related to the dual VCO configuration.

 

[slicerwizard]

Hmm. Well, back when Motorola trunking was being "reversed engineered" the statement was made

By someone who didn't have a clue.

that two receivers would be necessary in order to perform trunk following as the commercial equipment was able to do it. I took that to mean that said equipment had two receivers.

Yeah, this is what uninformed jibber jabber on the Internet leads to. Years later, and the "two receivers" meme still isn't dead...

Misunderstandings obviously send erroneous information out into circulation, as in this case. If commercial trunking transceivers contain only a single receiver, then I stand corrected. However, to coin a phrase, "citation required."

Actually, a citation is not required to counter the original claimant's fantasy. It's his statement that needs proof and none has ever been presented.

IMO, this is one of those "you should be able to figure it out yourself" deals. Why would a trunking radio need two receivers? Obviously, one would be parked on the control channel and the other on voice channels. But why? Why does the radio need to monitor the control channel while it's transmitting or receiving voice? What is the control channel going to tell it that it needs to know? "Oh, hi there. Control channel here. I see you're listening to user xxx, but I just thought you should know that ..." What goes in at the end there? What could be so important that manufacturers would build in two receivers into every radio? If anyone can answer that, we might have a clue as to why this idea came about and still lingers to this day.

And since that likely won't convince everyone, here's what you do - take any trunking radio and pull the flat, unmuted audio out of it - what will you hear? As the radio follows a call, control channel, then voice channel, then back to CC, then off to the next VC, and back to CC, and...

I guess you could also peruse some service manuals. Some of them are out on the 'net. No mention in any of them of two receivers. Nor will you find any repair techs who've located the elusive secondary receiver silicon.

 

[KD8DVR]

When the system got busy during the daytime, my extra transmission problems came back.

As nlurker did, I went back to .30 and the issues go away. I just lose the multiple voice channels which was handy, but it seems that the feature must be carrying the bug somehow.

The latest preview version addresses this. It seems to detect the intruding signal and stops it in a second or two. It doesn't eliminate the problem; but it helps significantly.

 

[DaveNF2G]

IMO, this is one of those "you should be able to figure it out yourself" deals. Why would a trunking radio need two receivers? Obviously, one would be parked on the control channel and the other on voice channels. But why? Why does the radio need to monitor the control channel while it's transmitting or receiving voice? What is the control channel going to tell it that it needs to know?

I would surmise that there must be some way for an engaged suscriber unit to be informed that a higher priority call has been made for its attention. How is that done? Subaudible data on the voice channels? That would work for the original Project 16 or Project 36 Motorola systems, but what about other types?

Perhaps trunking does not include a "priority" function? Well, that's easy enough to figure out - it does. The manufacturers say so. So how is it implemented in the absence of a second receiver?

I'm not disputing the fact that these radios actually contain only one receiver. I am (now) taking that as established. But the original assertion about separate receivers was a logical, if incorrect, response to the priority question.

 

[ddanz]

My understanding is that priority is used by zone/system controller to arbitrate competing requests to transmit from PTT of multiple users on more talkgroups than the number of voice channels that are currently available. It's not to interrupt a current channel grant because some high priority user needs the channel. Any unit transmitting an emergency signal has very high priority on getting resources.

Sent from my Nexus 7 using Tapatalk

 

[slicerwizard]

I would surmise that there must be some way for an engaged suscriber unit to be informed that a higher priority call has been made for its attention. How is that done? Subaudible data on the voice channels?

That's how Moto3600 systems do it. But they only transmit 11 MSBs of the 12 bit talkgroup number, hence the whole "you can only use odd talkgroup numbers if you want to use the priority monitoring feature (or a scanner that only uses the 300 bps datastream)"

That would work for the original Project 16 or Project 36 Motorola systems, but what about other types?

Perhaps trunking does not include a "priority" function? Well, that's easy enough to figure out - it does. The manufacturers say so. So how is it implemented in the absence of a second receiver?

Digital trunking systems send more than just voice on traffic channels. P25 voice (for example) is sent in superframes, each comprised of an LDU1 and LDU2 (logical link data unit 1 & 2); each LDU carries 9 20ms IMBE audio frames plus extra data. LDU2 carries encryption information, while LDU1 has a link control message. Link control message number 2 is:

Group Voice Channel Update
This indicates the updates of other group voice traffic on a trunked system and
which channels the other traffic is using. This is used on outbound messages
only and on trunked system only.

So every 360 ms, the system has the opportunity to make such an announcement.

I guess that's your citation.

 

[DaveNF2G]

OK, the Project 25 explanation is a good one. However, what about the other Project 36-based systems, like EDACS and LTR-MultiNet?

 

[slicerwizard]

What about them? Don't bother answering - I think we've more than overstayed our welcome in this Unitrunker Release 31 thread already.

 

[Mike_G_D]

OK, the Project 25 explanation is a good one. However, what about the other Project 36-based systems, like EDACS and LTR-MultiNet?

As someone who has worked on a trunked digital LMR system as well as cellular systems I can attest that quite a lot can be done with a single receiver with the proper design considerations; quite a lot more than what I believe most hobbyists not professionally trained in RF, analog, and digital electronic design believe is possible.

You have actually answered your own questions if you think about it regarding so-called "analog trunked systems".

What I believe many fail to grasp is that these "analog" systems were far from strictly "analog". The control channels sent and received truly digital data that had to be coded and modulated and then demodulated and decoded. True, that did not include voice data but the data was digital in nature nonetheless. That data certainly included simple instructions regarding priority assignments and such.

When not parked on a control channel, say during extended voice channel activity, there are other ways to send relevant data. On the Motorola systems that I understand best, use of the subaudible data present on the voice channel was sufficient. Such a system did not yield huge bandwidth, of course, but it did yield more than sufficient "data space" for simple priority channel status messages. I am far less proficient in EDACS style systems and I have heard that they did not use subaudible voice channel data on their "analog voice" channels so, if that is the case, then I am not sure how such data was sent during active voice channel activity.

It is my understanding that the GRE scanners that can handle true trunked priority calls do actually use the subaudible voice channel data, if only for that purpose alone at least.

With the proper attention to designing for the best compromise between switching speed and phase noise you can design PLL synthesizers to work quite well in terms of sufficiently fast channel switching to "move back and forth" between voice channels and control channels and even between multiple FDMA voice channel assignments without the users even noticing - all with a single receiver design. I know, I have worked on such systems directly.

One system I worked on was designed to compete with Nextel systems. It not only was trunked and used TDMA digital voice it also frequency hopped during voice calls and adjusted power dynamically in the subscriber units based on instructions from the controller. All of this using only one receiver in the subscriber units. The system worked fine (or would have eventually) but did not succeed due to other factors involving the usual mix of marketing and business issues.

Never assume that simply because you cannot understand how something could be done based on your knowledge alone it could not be done at all. And, given that understanding, I believe it best to not make absolute statements such as " it IS this way or that" rather, it may be better to state something like: "it is MY UNDERSTANDING that it is this way or that...".

-Mike

 

[nd5y]

EDACS systems do have low speed subaudible data on voice channels. It sounds about like Motorola's. (sounds similar to LTR or DCS) I don't know what it is used for.

 

[DaveNF2G]

Sometimes even the "experts" give different answers to the same questions. My original question is answered, and the very old misinformation upon which I was relying has been refuted. I thank everyone who shed light on the matter.

It is apparent to me that the inexpensive R820T-based dongles are unlikely to be useful for fully functional single-receiver trunking. It might matter how much of the burden for fast, accurate switching falls on the hardware versus the software. If it can be turned into a (mainly) software issue, then the computer being used could be more of a limiting factor than the dongle itself. It remains to be seen whether those who are capable of designing such software can come up with something that works well.

 

[bassjunkie]

It is apparent to me that the inexpensive R820T-based dongles are unlikely to be useful for fully functional single-receiver trunking.

I disagree, simply because the dongles are capable of receiving multiple channels within its bandwidth - they already beat commercial scanners in that respect, it's just a matter of software catching up to the new technology.

That's assuming that your system is within the bandwidth of the tuner of course, but still, show me a commercial scanner that can receive multiple frequencies simultaneously!

It's an exciting time to be a radio nerd - between the solid groundwork done by Unitrunker and the amazing open source efforts by the various communities, we're set to see software based radio as the norm in 5-10 years. I just wish Unitrunker would go open source too, then we'd see some real movement.