Oneida County DMR

[Disp46]

Ok Ive done that. I'll let you know how it goes. Thank you!

I'm curious to see about your findings. I found the multi-site, single frequency method definitely performed better for me than single site, multi-frequency when both were programmed for MotoTRBO Trunk all with LCN's of 1.

 

[nacsr]

Im receiving nothing. I programmed as DMR One Frequency as some one mentioned and no LCN. Maybe I'll try your suggestion next

 

[k2hz]

Im receiving nothing. I programmed as DMR One Frequency as some one mentioned and no LCN. Maybe I'll try your suggestion next

For either type of system programming, be sure to enable "ID Search" since there seems to be a question if the RRDB TGIDs are correct for Uniden.

 

[nacsr]

I'm curious to see about your findings. I found the multi-site, single frequency method definitely performed better for me than single site, multi-frequency when both were programmed for MotoTRBO Trunk all with LCN's of 1.

Ok I tried this and it does work. Only catch is the talk groups dont show up which is not a show stopper for me. Thank you, I appreciate the help!

 

[R0am3r]

While hunting through the UHF band today, I found one of the Turning Stone DMR Hytera XPT channels. I was surprised I could see this signal, and decided to add it to my SDS200. After reading through this thread, I settled on adding three sites (for the 3 freqs) all as MotoTRBO. This works fine and the scanner checks all three frequencies for activity.

Now the challenge - how do I configure my DSDPlus Fastlane so it checks all three frequencies? Here is my latest (non-working) attempt at configuring my DSDPlus.frequencies file:

XPT, 0, 1, 1, 454.1125, 0, 1
XPT, 0, 1, 3, 454.3125, 0, 3
XPT, 0, 1, 5, 454.5125, 0, 5

As a side note - my initial check of this site returns three digit talk groups (e.g. 100, 133). I'm guessing the TGs listed on RR are from an older system?

 

[R0am3r]

To follow up on my previous post and a little evidence for proof of the changes to the talk groups, here are a few files for all.




Here is a snippet from the 1R-DSDPlus.SRT file:
1
00:00:00,000 --> 00:00:01,000
2020/11/28 15:43:06
454.312500 +DMR DCC=7
Slot 1 TG=134 [Slot Machine Attendants] RID=1438
Slot 2 TG=140 [Bingo Operations] RID=1283

2
00:00:01,000 --> 00:00:02,000
2020/11/28 15:45:28
454.312500 +DMR DCC=7
Slot 1 TG=141 [Operations] RID=1313

3
00:00:02,000 --> 00:00:03,000
2020/11/28 15:45:29
454.312500 +DMR DCC=7
Slot 1 TG=141 [Operations] RID=1313

4
00:00:03,000 --> 00:00:04,000
2020/11/28 15:46:10
454.312500 +DMR DCC=7
Slot 1 TG=140 [Bingo Operations] RID=1299
Slot 2 TG=134 [Slot Machine Attendants] RID=1435

5
00:00:04,000 --> 00:00:05,000
2020/11/28 15:46:11
454.312500 +DMR DCC=7
Slot 1 TG=140 [Bingo Operations] RID=1299
Slot 2 TG=134 [Slot Machine Attendants] RID=1435

 

[R0am3r]

I forgot to mention this in my previous posts. I confirmed with the wonderful DSDPlus Fastlane (FL) program authors that DMR Hytera XPT is not currently supported. But, they did tell me that my approach of using a ScanList file will work to force FL to cycle through the site frequencies. Simply add the three Turning Stone XPT frequencies to a DSDPlus.ScanList text file and then put your FMPx tuner into scan mode (use the letter s to start the scanning). This forces FL to check each frequency for activity.

As mentioned in an earlier post, my SDS200 also has issues trunk tracking the Turning Stone DMR Hytera XPT system. The fix is to add the three sites (one site for each of the 3 freqs) all as MotoTRBO. The color code is 7, but you can let the system figure this out. Thanks to the good folks (in this thread) who worked this out before me!

@GTR8000 Please note that FL and my SDS200 agree on the talk groups I submitted.

 

[GTR8000]

Uniden scanners don't display Hytera XPT TGID's correctly. For some reason they add 1048576 to the DEC TGID, which accounts for the mismatch with this system in the RRDB.

 

[R0am3r]

Uniden scanners don't display Hytera XPT TGID's correctly. For some reason they add 1048576 to the DEC TGID, which accounts for the mismatch with this system in the RRDB.

What Uniden model are you referencing? My SDS200 displays the TGIDs correctly and they match the DSDPlus FL TGIDs. Also, when I review the recorded files, the TGIDs are correct.

 

[GTR8000]

Perhaps it's no longer the case, but at one time the x36HP scanners would display the 7 digit TGID's, which are clearly incorrect. Hytera XPT apparently only allows for a maximum TGID of 255.

I'm going to try to verify that, and if accurate, will see if Lindsay can put a restriction on the valid TGID value in the RRDB.

In any events, the database has been updated.

 

[nacsr]

I get TG such as 133 or 111 on my SDS200.

 

[Disp46]

Uniden scanners don't display Hytera XPT TGID's correctly. For some reason they add 1048576 to the DEC TGID, which accounts for the mismatch with this system in the RRDB.

Whistler scanners and the Chinese DMR HT’s all display the talk groups in the seven digit format. Uniden appears to have it correct. To make things more interesting, the Whistlers and Chinese DMR HT’s apparently can’t handle something in the data string when they decode because one time they’ll decode seven digit talk groups beginning with 1 (1000000) then they display the same talk group beginning with a 2 (2000000) and lastly they display the same talk groups with a 3 (3000000) then they roll back to 1. Very odd.

 

[R0am3r]

@GTR8000 What happened to the Turning Stone Casino database entry? I can't find it in the Monday update.

 

[GTR8000]

@GTR8000 What happened to the Turning Stone Casino database entry? I can't find it in the Monday update.

If you're referring to the Sentinel update, then that's a question for Uniden. The system is obviously still in the RRDB.

 

[R0am3r]

So is this a normal thing where a system that is listed in the RRDB just disappears when Uniden downloads the database? This seems really strange to me. Is there any sort of protocol to check for corrupt fields in the RRDB that may not translate to the Uniden database? Maybe a simple fix would be to delete the system and then add it back to the RRDB? Yah, I'm reaching here because I don't want to see my research lost when it hits the Uniden site.

 

[GTR8000]

So is this a normal thing where a system that is listed in the RRDB just disappears when Uniden downloads the database? This seems really strange to me. Is there any sort of protocol to check for corrupt fields in the RRDB that may not translate to the Uniden database? Maybe a simple fix would be to delete the system and then add it back to the RRDB? Yah, I'm reaching here because I don't want to see my research lost when it hits the Uniden site.

None of the fields are corrupt in the RRDB. I suspect there is something on Uniden's end that it doesn't like. No, I won't be deleting it and recreating it, as there is nothing wrong with the RRDB listing. I just imported it into ProScan without any issue.

 

[GTR8000]

So it seems that the issue is that Uniden insists on seeing an LCN value other than 0 for these Hytera XPT system repeaters, otherwise it will ignore them during the weekly RRDB pull. Since Uniden appears to be a rudderless ship at this point with the unfortunately passing of Paul last year, I wouldn't hold my breath that any of this stuff will ever get fixed...frankly, it was tough enough at times getting Paul to address some of these issues. I've given each repeater a bogus LCN, so it should show back up next Monday.

 

[R0am3r]

Thank you for your efforts. I truly appreciate that you looked into this issue a bit further. You have my gratitude.

Time to send another message to Uniden asking for support (e.g. bug fixes, firmware updates, etc.) for their flagship scanners. Yes, I know I may be wasting my time.

 

[R0am3r]

Yesterday I discovered that Turning Stone Casino added a fourth frequency (454.2625 MHz) to their Hytera XPT system. This frequency is the strongest of the four XPT frequencies (as monitored from my station). Two additional talk groups have been discovered on this frequency: 125 Shuttles and 170 Golf Courses. There may be additional TGs using this new XPT frequency.

Please note - it appears the JPJ Communications MPT-1327 site for Turning Stone is no longer transmitting on 454.0125 MHz. I simultaneously monitored the Scribner Corners MPT-1327 site and the new XPT frequency and there doesn't seem to be any overlap for the Turning Stone Shuttles. This makes sense, but I wanted to be sure before I submitted the Turning Stone MPT-1327 site for removal from the RR database

Bottom line - I submitted the addition of the new XPT frequency and TGs as well as the removal of the Turning Stone MPT-1327 site and TG.

Scott
KG2S