Test Firmware for DMR OFT and Band Plan Issue logging

[crash1]

I`m still missing comms and on one freq I see the slot come up but no audio its not tracking correctly
someone will say something and I won`t get the reply by putting the freq in conventionl I hear everything
fine.

 

[Phillipsc84]

OK, so here is an observation from today. I created a single system with one site, one frequency, and just the group I wanted to heat that I knew was on that frequency. I held on the system, department, and channel. So no scanning at all. Side by side with a MD380 radio and I still missed some transmissions. I could see that the scanner saw the signal since I had a full signal meter. I was maybe a mile from the site I was monitoring. This was a repeater channel not simplex. Also this is a second scanner so this happened in more than one unit. I did get some transmissions so I know I had the info programmed correctly.

This was for a single frequency NON trunked, conventional "system". Using the 1.11.21 firmware.

 

[JamesO]

Seems that a simple test for this would be a set up with a split antenna feeding multiple scanners/radios.

For a single user, single channel DMR system you could configure a different scanner as a standard FM channel to the DMR frequency.

Then have the DMR radio configured to monitor the user/channel.

The radio set to FM would be used to detect channel activity to then compare if the DMR radio is capturing the comms.

Just a sanity check for a very specific DMR test.

 

[sibbley]

Upman, I guess I spoke too soon regarding the TGID's. I'm getting TGID's for known systems showing up in totally different systems. However, the TGID that is showing is not for the voice I hear.

Example: TGID 5027200 is for an EMS service. This TGID will show as a new found TGID, in another system for a grocery warehouse. I can tell from the voice received it's the grocery folks talking. Both systems have completely different frequencies and are not even in the same FL. This happens with every system I have programmed.

Would a log file help to show what's going on?

Most likely won't help, but I attached a ProScan log. The highlighted rows are the TGID's that don't belong in those systems.

 

[UPMan]

Regarding N0BDW Log, engineering comments/questions:
1. How many site frequencies are programmed for that system?
2. If you open squelch all the way, does it affect the band plan capture? (i.e. w/o going into analyze mode).
3. Try manually setting the threshold to an optimum value and seeing if it affects band plan capture.

Generally, control channel reception is unstable before analyze mode. Trying to figure out why.

 

[UPMan]

Since we've received no further feedback on the band plan issue (which may or may not be an issue, as there seems to be no one complaining of it at the moment), this research is suspended.

 

[N0BDW]

Regarding N0BDW Log, engineering comments/questions:
1. How many site frequencies are programmed for that system?
2. If you open squelch all the way, does it affect the band plan capture? (i.e. w/o going into analyze mode).
3. Try manually setting the threshold to an optimum value and seeing if it affects band plan capture.

Generally, control channel reception is unstable before analyze mode. Trying to figure out why.

My apologies -- I missed this reply.

Everyone in Livingston County that I've talked to that has this line of scanners (536/436) has this issue -- unfortunately not all of them are here to participate in these forums or have the ability to run the test firmware.

In my scanner there is only one frequency programmed for the site and that is the control channel on 155.7975. Others have imported the system from RadioReference and as such have all of the frequencies listed for the system:

Livingston County Trunking System, Livingston County, New York - Scanner Frequencies

The squelch makes no difference and was not adjusted in the time before/after the tests.

The digital threshold makes no difference, and has typically been set to manually around 7-9 and was not adjusted in the time before/after the tests.


Please don't drop this issue yet -- it is very real for those of us in Livingston County.

 

[N0BDW]

I was able to program this system into a 996P2 and it works fine there, no analyze needed (and of course there isn't one if it were). Just for another point of reference.

 

[jonwienke]

I'd also like to point out that the adjusted firmware made no difference in the huge discrepancy in scan speed scanning as One Frequency vs a collection of conventional channels. One Frequency is still about 4x slower to scan.

 

[bravo14]

I have updated to this firmware on both radios. I'm picking up 1-4 bars on a DMR channel for a school is like 1 block over they are not on a repeater. Before this firmware update I couldn't get nothing. Unless the weather is right I'm getting some signal I'll do some tests today before and after this firmware.

 

[UPMan]

We've got an additional firmware version to test against:
1) Improved One-Frequency Trunking for DMR speed.
2) DT3 modification to change the way LCNs are handled.
3) Modified XPT trunking.

You might have to reset the LCNs of any DT3 systems you've programmed.

http://info.uniden.com/twiki/pub/PartnerWeb/BCD536HPBeta/BCDx36HP_V1_11_22.zip

 

[KevinC]

We've got an additional firmware version to test against:
1) Improved One-Frequency Trunking for DMR speed.
2) DT3 modification to change the way LCNs are handled.
3) Modified XPT trunking.

You might have to reset the LCNs of any DT3 systems you've programmed.

http://info.uniden.com/twiki/pub/PartnerWeb/BCD536HPBeta/BCDx36HP_V1_11_22

The requested URL /twiki/pub/PartnerWeb/BCD536HPBeta/BCDx36HP_V1_11_22 was not found on this server.

 

[Ghstwolf62]

404 not found for me too

 

[trido]

http://info.uniden.com/twiki/pub/Par...P_V1_11_22.zip

not sure if Paul changed it but works fine for me.
strange when i go to this link it AUTO downloads the zip file
oops well when i click the link above I posted I do get that error, however click the link in Pauls post works

 

[tumegpc]

We've got an additional firmware version to test against:
1) Improved One-Frequency Trunking for DMR speed.
2) DT3 modification to change the way LCNs are handled.
3) Modified XPT trunking.

You might have to reset the LCNs of any DT3 systems you've programmed.

http://info.uniden.com/twiki/pub/PartnerWeb/BCD536HPBeta/BCDx36HP_V1_11_22.zip

is there a test version for the 996P2/325P2 ?

 

[Ghstwolf62]

http://info.uniden.com/twiki/pub/Par...P_V1_11_22.zip

not sure if Paul changed it but works fine for me.
strange when i go to this link it AUTO downloads the zip file
oops well when i click the link above I posted I do get that error, however click the link in Pauls post works

Okay that's weird.

Now Paul's link auto downloads it like you said without taking me to a new page with the 404 bit. The other links included in others replies do not work though. Maybe he changed it in his post or something.

 

[cg]

First of all, this system was being received poorly but did get much of the traffic.

I tried the updated firmware on an XPT trunking system but ran into a snag right away.
How does the XPT LCN get programmed into the scanner?
Are the LCN simple numbers like 1, 2, 3, 4 or are they frequency related, 451.0000=001, 452.0500=085, etc?
So I created a MOTOTRBO Trunk system and then created 4 Sites. All 3 frequencies were repeated at each site with the difference being the LCN. Site 1 had all 3 channels as LCN 1, Site 2 had the LCNs as 2, etc.
Running the 536 with that setup got me hits on only one of the frequencies but on multiple LCNs. Some calls would be 453.3500 as LCN 1, some as LCN 2, some LCN 3 and some LCN 4.

I did not get any invalid TGIDs like I got last night with the 996P2 on the same system (or older versions of firmware on the 536) where the scanner calculated the TG incorrectly. For example, TGID 226 (11100010) would sometimes show up as 3145954 (1100000000000011100010).

chris

 

[UPMan]

Try LCN finder on the system.

 

[k3fs]

I have noticed an increase in false talk groups, especially on OFT.

 

[jonwienke]

No solution to the issue of OFT systems scanning 4x slower than the same freqs set up as conventional.