Unitrunker Release 31

[SCPD]

1) is there a log/text file where the exception would have been recorded?

No, but you may have a crash dump.

Crash Dumps

3) would it make sense to implement a configurable timed auto-save feature?

There is an Auto Save check box on the main program window Options tab. It saves once an hour.

 

[dooshorama]

No, but you may have a crash dump.

Crash Dumps

got it.

There is an Auto Save check box on the main program window Options tab. It saves once an hour.

ooh, hello! i'm embarrassed to say i've been to the options tab a total of once.

thank you on both counts.

Assuming you have now set the values to 13.000 instead of 12.500, have you noticed any improvements in decoding?

the short answer is no.
i get occasional errors in the P25 LDUx frames. i thought it may improve if i eliminate the clipping (discussed in this thread). i ended up increasing the BW to 15.000, but neither clipping nor decoding improved.

 

[dooshorama]

From the Archive tab click the icon to the left of the folder icon. I would describe it as looking like the front of an old external hard drive.

i forgot to acknowledge your post and to say that i learned something new

i missed the Archive tab completely. i must be getting old. that and i know what an external HD looks like.

 

[thegriff]

the short answer is no.
i get occasional errors in the P25 LDUx frames. i thought it may improve if i eliminate the clipping (discussed in this thread). i ended up increasing the BW to 15.000, but neither clipping nor decoding improved.

At the risk of confusing things I thought I'd mention my experience with UT, DSD+ and P25. My guess is the clipping seen in the Scope tab is different from actual audio clipping.

I have always had overdriven with UT supplying DSD+ and as a result installed a program that allows me to control the level going to DSD+. I did this after not being able to control the audio using Windows 8.1 sound properties. Since I use VB-Cable I opted to use VoiceMeeter by the same developer.

While P25 decoding is not error free it is working most of the time whereas it would never work prior to VoiceMeeter.

What confuses me is whether the clipping seen in the Scope tab is related to the overdriven audio I've noticed.

 

[Adraenyse]

I love the new VCO on RTL-SDR dongles!

However, I'm having two somewhat related issues with the latest release.

While listening to a local EDACS96 system. Mostly listening to one specific talkgroup for fire dispatch.

What will happen is either

1. The talkgroup will silent for a while, a call will come out, and if the next party to transmit comes on very quickly, the TG jumps to the next frequency, but is muted. Seems to be respecting the lockout of the previous TG that just cleared on that channel.

2. The talkgroup will be operating normally, but immediately after the party finishes transmitting, if another call jumps on the frequency right behind it, it will not respect the lockout and broadcast out the audio, and it's usually a ProVoice TG so it comes out blasting garbage of course. It looks like the program is thinking the audio is following the previous call.

So similar issue, just in reverse directions where the calls are so close together they seem to respect the settings of the previous TG instead of the current TG.

Any way to work around this? Any clarification required?

 

[nlurker]

Adraenyse, see my message #90 from a few weeks ago. It sounds like you have the same problem as I do. The developer has so far been unable to reproduce it.

 

[Adraenyse]

Figures, since I didn't read the entire thread someone else did have the same problem

I've been looking at this but, so far, not found a way to recreate this.

Any additional information is most welcome.

What receivers are you using? How are they configured? What systems do you monitor? What were the rankings of the wanted vs. unwanted talkgroups?

Look at the Users tab. What is the rank / priority of most of your users?

I am using one RTL-SDR stick with 3 VCOs. I tuned the bandwidth downwards a couple times thinking I might be overdriving the tuner with no effect.

The VFOs are all set to rank 50.

I monitor the Edmonton Public Safety EDACS96 system. All groups are set to 50 and locked out with the exception of police at 30, EMS at 20, and fire at 10. The unwanted groups are coming through on priorities 50. But it's not just unwanted coming through, it's wanted ones being killed as well, based on the trunk group that was locked out and previously just transmitting on the same LCN.

New group template is set to pri 50 and lock out as well.

I can make logs available, or remote desktop, phone patches, join.me, whatever you need to help diagnose this. It is quite reproducible on my end, probably once every couple minutes during busy fire events. There was a real fire earlier and that's when it was the worst.

The most reproducible event is when fire dispatch initially calls a truck and the truck responds real quick but they get muted due to whatever was on the LCN just before them. The garbage unmute doesn't happen as often for me, but I suspect both events are driven by the same logic.

Guh, it happened while I was posting this.

"Fire command, does anyone need AHS?"
--- muted reply visible on LCN 11 but TG is clearly not locked out --
"OK thanks"

 

[bama9999]

I have what appears to be muted replies/transmissions regularly showing on various LCN's as well. No idea why it does that, but I can relate to your problem.

 

[Adraenyse]

Short of setting all talkgroups to not be locked out, give them all high priority and then set the VCOs to only allow the low rank, I don't know how else to deal with it. I can repeat the issue every 30 seconds or so right now while this fire event is going on.

Turned on logging and got a pile of this... related?

PLL LO 870982500 prescale 1 Quotient 60 SDM 31540 error 69.
gain BF FC FC E6
PLL LO 870245000 prescale 1 Quotient 60 SDM 28184 error 15.
PLL LO 870245000 prescale 1 Quotient 60 SDM 28184 error 15.
gain 9F FC FC E6
PLL LO 870495000 prescale 1 Quotient 60 SDM 29321 error 171.
PLL LO 870495000 prescale 1 Quotient 60 SDM 29321 error 171.
gain B5 FC FC E6
PLL LO 870107500 prescale 1 Quotient 60 SDM 27558 error 73.
PLL LO 870107500 prescale 1 Quotient 60 SDM 27558 error 73.
gain B3 FC FC E6
PLL LO 870857500 prescale 1 Quotient 60 SDM 30971 error 101.
PLL LO 870857500 prescale 1 Quotient 60 SDM 30971 error 101.
gain B3 FC FC E6
PLL LO 871107500 prescale 1 Quotient 60 SDM 32109 error 37.
PLL LO 871107500 prescale 1 Quotient 60 SDM 32109 error 37.
gain 96 FC FC E6
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
gain B1 FC FC E6
PLL LO 870245000 prescale 1 Quotient 60 SDM 28184 error 15.
PLL LO 870245000 prescale 1 Quotient 60 SDM 28184 error 15.
gain 81 FC FC E6
PLL LO 870107500 prescale 1 Quotient 60 SDM 27558 error 73.
PLL LO 870107500 prescale 1 Quotient 60 SDM 27558 error 73.
gain AE 7C FC E6
PLL LO 870607500 prescale 1 Quotient 60 SDM 29833 error 165.
PLL LO 870607500 prescale 1 Quotient 60 SDM 29833 error 165.
gain 81 FC FC E6
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
gain 8F FC FC E6
PLL LO 869995000 prescale 1 Quotient 60 SDM 27046 error 79.
PLL LO 869995000 prescale 1 Quotient 60 SDM 27046 error 79.
gain B3 FC FC E6
PLL LO 870132500 prescale 1 Quotient 60 SDM 27672 error 22.
PLL LO 870132500 prescale 1 Quotient 60 SDM 27672 error 22.
gain 82 FC FC E6
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
PLL LO 870357500 prescale 1 Quotient 60 SDM 28696 error 9.
gain BF FC FC E6
PLL LO 870370000 prescale 1 Quotient 60 SDM 28752 error 203.
PLL LO 870370000 prescale 1 Quotient 60 SDM 28752 error 203.
gain 86 FC FC E6
PLL LO 870495000 prescale 1 Quotient 60 SDM 29321 error 171.
PLL LO 870495000 prescale 1 Quotient 60 SDM 29321 error 171.
gain A0 FC FC E6
PLL LO 870745000 prescale 1 Quotient 60 SDM 30459 error 108.
PLL LO 870745000 prescale 1 Quotient 60 SDM 30459 error 108.
gain BF FC FC E6
PLL LO 870482500 prescale 1 Quotient 60 SDM 29264 error 197.
PLL LO 870482500 prescale 1 Quotient 60 SDM 29264 error 197.

Edit: Changing the rank of the VCOs so they would exclude everything I don't want to hear doesn't fix the muting, but I haven't heard any more garbage. Could be coincidence though since it's getting later. I can see the VCO showing the target and audience, everything visually is correct, just the audio is missing.

 

[Adraenyse]

More related to muting issues. I lost my control channel just now. It moved but didn't chase for some reason (it has been working well). So I unmuted the first VCO (signal) and it refused to give me audio until I changed the frequency, then it unmuted.

 

[Adraenyse]

Well I can shed some light on this bug, it appears the TGs that are 'jumping' their lockout and putting audio out on an LCN that was just broadcasting audio - they have higher priorities than the TG that was just on the LCN. It won't happen with a TG with an equal or lower priority.

So flow is:
1. TG that meets priority for rank on VCO transmits
2. TG is heard on X LCN
3. TG stops transmitting
4. Another TG which is locked out but has a priority > than the previous TG starts a call on the same LCN right behind
5. The locked out TG is heard

At this point I can only assume the scenario is happening in reverse, where a locked out TG with a high priority is on an LCN and is muted, and the wanted TG appears immediately behind, but gets muted due to the lower priority.

I am going to remove all priorities above 10 to test this theory. If both the muting and garbage go away then I've found a the reproduce method.\\

Edit: So far it has been success. If there is no locked out TG with a higher priority, the muting issue appears to have gone away. The lockout channel transmitting behind an unlocked TG remains.

Also, I've found two more things. If you set a Call sound (such as whoop or gong) to a channel, it comes out on the primary sound driver instead of the sound channel specified for the audio. It doesn't follow. Might be intentional.

With respect to multiple VCOs, if I have two TGs with equal priority, and two open VCOs available, they will take one VCO each and transmit. If I have two VCOs available, and one TG transmitting on the first VCO, and a call of higher priority comes in, it overrides the first call VCO instead of going to the next free one. It might not do this everytime, I just noticed it doing it while paying close attention. I had one fire call override another one (priorities 1 and 10) and yet a police call (priority 30) went over to the available VCO, being lower.

The higher priority TG should only interrupt an existing call if there are zero open VCOs.

 

[SCPD]

I lost my control channel just now. It moved but didn't chase for some reason (it has been working well). So I unmuted the first VCO (signal) and it refused to give me audio until I changed the frequency, then it unmuted.

This sounds like squelch is working correctly. I'm assuming you switched from the inactive control channel (dead air) to the active control channel.

So flow is:
1. TG that meets priority for rank on VCO transmits
2. TG is heard on X LCN
3. TG stops transmitting
4. Another TG which is locked out but has a priority > than the previous TG starts a call on the same LCN right behind
5. The locked out TG is heard

Thank you! This is extremely useful. I'll run some tests over the weekend.

 

[SCPD]

I had one fire call override another one (priorities 1 and 10) and yet a police call (priority 30) went over to the available VCO, being lower. The higher priority TG should only interrupt an existing call if there are zero open VCOs.

You're right. It should not do that. I'll investigate this weekend.

 

[Adraenyse]

Thanks for checking into this.

More observations. Even though I've set staggering priorities on my fire TGs, they refuse to go to the available VCO. They just wait and transmit on the first one now when it frees up. Before when they were equal priority they would hunt to an empty VCO.

I have rank 49 and 48 set on my VCOs for voice, but the 'garbage' TG that jumps on the channel just used for a legit TG, is set to 50 and locked out, and it still will transmit audio. So not only is the lockout being ignored, so is the rank on the voice VCO. This is when a locked out TG happens to land on a LCN that was just (literally JUST) used for broadcasting an unlocked TG. If there is so much as a half a second between them, then it won't happen.

So the control channel decoding is keeping up, but the logic to mute is not somehow.

However! I haven't noticed anymore unintentional muting after lowering the priorities on the locked out channels. Having the highest rank on unlocked channels only results in desired behavior there. So that should help locate the issue.

 

[nlurker]

Adraenyse, what you describe is exactly what I have been experiencing (constantly, every day).

And what you call 'garbage' TG, for me it literally IS garbage. An exciting fire/rescue in progress is suddenly blocked by mundane status reports from garbage truck drivers. The fire TGs are all ranked around 11-19, while the garbage TG is ranked 79, well below my listen threshold of 50.

 

[Adraenyse]

Heh. Well it's provoice digital for me so it comes blasting out, but actual garbage, that's funny.

I'm sure it's just some misplaced logic in the code when the multiple VCOs were added, being that there's a whole bunch of things that seem to tie together. Priorities being ignored, VCOs not taking ranks correct, audio on lockout, mute on no lock. It's like opposite day. It'll be a < instead of > somewhere.

 

[Adraenyse]

Update, the changes I made have no impact, once the system is busy the muting problem comes back again.

Plus I have no idea what I did to upset the VCOs because now I can't get more than 1 voice to work simultaneously at all, they all want to override the first voice VCO and ignore the others.

Edit: Bah, the VCO switch back to Signal when I decremented/incremented the VCO count. That one is on me.

 

[Adraenyse]

In a desperate attempt to rid muting, I unlocked every single TG in the system, gave a priority of >30 to what I wanted to hear, and set the VCOs to a rank of 29. It does keep out the things I don't want, but I'm _still_ getting muting even though the lockouts are completely gone.

 

[Adraenyse]

I should be ashamed to call myself a ham! I think I just figured out what may be wrong here.

The LCN list and the frequencies don't follow the same natural order. I think the channels that are muting might JUST be high enough to be out of the range of the 2 MSPS bandwidth of the dongle.

Yep, quick math tells me that I need 2.75 MHz of coverage, and the dongle, at best, can only give 2.5, which it doesn't fully, so that must be why I am muting channels. It might also explain the behaviour of getting random channels as UT tries to do what is it told but just can't because of the bandwidth.

It is 3 AM, so I will verify tomorrow. That would also make sense why previously using a separate dongle for control worked so well, since I've seen the control channel anywhere from LCN 1 to 7. At least if I have a dedicated voice dongle, the worst I can miss is the top most 1 or 2 LCN.

If this is the case, I don't think I can solve without buying a wider bandwidth SDR. I don't think you can split LCNs across two dongles can you? If you could, then I could just give 10 channels to each dongle and problem solved.

Will experiment more tomorrow.

Edit: I think this also explains why I'm hearing clipped voices and garbage digital like noises, I think that's the center freq of the dongle being thrashed around in order to try to catch the all the channels. GAH! It's like hitting a brick wall of logic, it all makes sense now.

It's no wonder you couldn't duplicate the behavior. Feel so dumb!

 

[satboy8888]

I still nominate you for one 'point' for figuring it out yourself... Physical wires and issues are so much easier to trace then adding software to the mix.

Sent from my SGH-I337M using Tapatalk