Discuss DMR Upgrade Here

[W4ELL]

I understand that, however UPMan had indicated they would likely be releasing a second dmr pre-release firmware file. was just wondering if this was the one.

Just keep an eye on this thread... When it gets locked, that will be a good sign that a new firmware has been released.

According to this comment, anyway:

Since this thread has gotten so long, when I put out the next pre-release version, I'll start a new thread and ask that this one be locked, so that issues in this version are not confused with future operational issues (of which I sincerely hope there are none, but am pragmatic in my actual expectations). That will also allow me to put the link to the f/w, along with instructions for applying the update, in Post #1 of the thread.

 

[john56]

Disregard my last post....got it working!

John KD8BIN

 

[bearcat]

While I agree that the scanner should move on in scan mode, i disagree for search mode... in search mode, the scanner should stop on ANY activity, no matter whether it is data or voice... it is on the user to decide, whether it shall be stored as channel or avoided...

i agree. I would much rather make my own decisions about what the scanner stops on in a custom search. I would not want it to pass anything on it's own.

 

[bearcat]

I am really glad to hear that they may have a second pre-release. In the ham radio world Elecraft has been doing these types of beta firmware updates. I think in the long run it works out for everyone.

 

[Minus1]

Actually, I am sure that Whistler got caught off guard by our announcement. I was surprised that they had DMR ready so soon, but in looking at it, it is really more pre than our pre-release.

Competition is a good thing. Sadly that does not appear to apply to Uniden's choice of card credit processor. Their inability to process non-US/Canada cards is a absurdity in this day and age.

 

[rumcajs_tr]

Competition is a good thing. Sadly that does not appear to apply to Uniden's choice of card credit processor. Their inability to process non-US/Canada cards is a absurdity in this day and age.

I had no problems paying with VISA card issued in Czech Republic, Europe...

 

[ColonelMike]

Does anyone know why the LCN is constantly changing when I do an LCN search? It's showing CON on this system on the frequencies but almost all of them switch LCN each time I do a LCN search.

 

[sibbley]

Does anyone know why the LCN is constantly changing when I do an LCN search? It's showing CON on this system on the frequencies but almost all of them switch LCN each time I do a LCN search.

I have the same problem every time I run LCN finder. I know one of the frequencies has to be LCN 2, then run LCN finder again to try to locate the others, and bam, that frequency gets another LCN. When this happens, the TGID's on that frequency go quiet until I change that frequency back to LCN 2.

 

[ST-Bob]

Aren't the channel grants on a Connect+ system being controlled by the MotoTRBO controller? If so, then the LCN would change as it really has no predefined order nor control channel (unless I'm totally off-base here). So if that's the way it works, the Logical Channel Number doesn't matter as each radio is informed where each TGID is going next in the data stream. So there's no reason for LCN to be maintained - it just jumps to the next frequency for the next conversation and LCN is not a valid data field and could be randomized.

 

[sibbley]

That makes sense. I'm working off one particular site, 6 frequencies. One of those frequencies, if not programmed as Con+, has constant signal and has to be avoided during search or if it's programmed conventional. I'm assuming that is the control channel. Also, without that frequency being programmed in a Con+ system, the frequency with the TGID's I'm trying to monitor shows the TGID but no audio.

 

[bearcat]

Aren't the channel grants on a Connect+ system being controlled by the MotoTRBO controller? If so, then the LCN would change as it really has no predefined order nor control channel (unless I'm totally off-base here). So if that's the way it works, the Logical Channel Number doesn't matter as each radio is informed where each TGID is going next in the data stream. So there's no reason for LCN to be maintained - it just jumps to the next frequency for the next conversation and LCN is not a valid data field and could be randomized.

I believe that in Con+ the freq must be assigned the correct LCN #. Using DSD+ to decode the data steam provides the correct LCN information and that never changes. Example LCN1 is ch 1&2, LCN 2 is ch 3&4 and so on. At least I think it works this way. I think the issue is that the LCN finder is not working properly in the pre-release.

 

[Anderegg]

My Connect Plus Motorola codeplug, contains a frequency file for the system............there are check boxes next to each repeater, and on my system, at least two of them are checked off as control channels, typically the first two.

Paul

 

[IAmSixNine]

Can someone in the Dallas area help test something for me.
Im doing a custom search, 454 to 455 mhz. I have tried using Auto and NFM for Modulation. I have set channel step to Auto, 6.25khz and 12.5khz and i get nothing. And tried different variations of the two together. I get a hit on 454.0 every now and then DMR. BUT i can confirm a channel on 454.25 that is a CON plus control channel. During the search it never finds it.
I also have an LTR system and a DMR system or two using frequencies in this range and it picks them up just fine. In fact 454.25 is one of the frequencys with a constant signal, control channel for DMR CON. I can hold the search, tune it to that frequency and it finds it no problem full signal. But search finds nothing.
Doing a similar search in 935mhz to 940mhz finds all sorts of hits. So i know i have search set up right.
IF it matters custom serach 0 is the UHF and custom search 9 is my 900mhz.
As im typing this im getting another hit on 454.0 but thats all it has ever hit on.

 

[KevinC]

Can someone in the Dallas area help test something for me.
Im doing a custom search, 454 to 455 mhz. I have tried using Auto and NFM for Modulation. I have set channel step to Auto, 6.25khz and 12.5khz and i get nothing. And tried different variations of the two together. I get a hit on 454.0 every now and then DMR. BUT i can confirm a channel on 454.25 that is a CON plus control channel. During the search it never finds it.
I also have an LTR system and a DMR system or two using frequencies in this range and it picks them up just fine. In fact 454.25 is one of the frequencys with a constant signal, control channel for DMR CON. I can hold the search, tune it to that frequency and it finds it no problem full signal. But search finds nothing.
Doing a similar search in 935mhz to 940mhz finds all sorts of hits. So i know i have search set up right.
IF it matters custom serach 0 is the UHF and custom search 9 is my 900mhz.
As im typing this im getting another hit on 454.0 but thats all it has ever hit on.

Is your broadcast screen for "Paging" turned on?

 

[W5JCK]

Odd TGID displaying for DMR One-Frequency Systems

I used the freeware logging app Scanner Monitor to log my BCD536HP RX hits over a 16 hour period. It logged some strange looking TGIDs. Many of these I saw displayed on the BCD536HP screen, so it is not the Scanner Monitor app going nuts. I'm wondering if these strange TGIDs or a result of a glitch in the FW, the result of bad programming of repeaters and/or individual radios that or TXing, perhaps connected to simplex operation, or some kind of data TX. All the systems I monitored were amateur radio repeaters. Here are a few of the log entries:

FREQ/TGID, CHANNEL
TG:i8979477, TGID:i8979477 (SRC) i6046241 (DST) TG:i8979477
TG:i9945166, TGID:i9945166 (SRC) i15068917(DST) TG:i9945166
TG:i12026863, TGID:i12026863(SRC) i6160610 (DST) TG:i12026863
TG:i2704132, TGID:i2704132 (SRC) i14698469 (DST) TG:i2704132
TG:i684619, TGID:i684619 (SRC) i6356490 (DST) TG:i684619

These were all one time only hits and they were all from unknown departments so safe to assume they were discovered in search mode. I have no clue what SRC and DST stand for, these are the only logbook entries with those terms appended. Perhaps they stand for source and destination? Any clues as to why these strange TGIDs are being seen?

ETA: Sorry about the lack of colums in the log entries, but the RadioReference forum software is really lacking in editing ability with next to no formatting capability.

 

[UPMan]

iCalls.

 

[Jay911]

SRC and DST are source and destination and are private calls.

 

[KevinC]

And SRC is source and DST is destination.

 

[IAmSixNine]

Is your broadcast screen for "Paging" turned on?

Thank You. I went to the setting after you mentioned it and turned ALL to OFF and now im getting what i think should be normal hits.
I have to agree with what someone said earlier, having this pre release firmware and no sentinel support has made me learn again how to program by hand. Its been a great refresher course.

Looking forward to the next version of beta.

 

[tyytor]

BCDx36HP: Discuss DMR Upgrade Here

how do i do a fcc query for 7k60fxe emissions like UPMan did for my area,
i tried to open his file in exel and openoffice and both froze (locked up)
the prerelease is working great
thanks