L'Isle-aux-Allumettes DMR 1 Frequency System
- Thread starter IdleMonitor
- Start date
- Status
- Joined
- Nov 5, 2002
- Messages
- 8,342
Now correct me if in wrong. You can't input this as a 1 frequency system unless we have more then 1 talk group right? Looks like I have more then 1 now.
So it is considered a 1 freq. Conventional Networked type system. This is how I'm logging radio IDs and talkgroups.Active talkgroups so far are tg 11 and 13 both of which are fire related. Still just trying to figure out names or areas for these talkgroups.
Definitely covers Pontiac West area though.
Pontiac Ouest Fire Department serves the municipal territories of Chichester and Sheenboro. and L'Isle-aux-Allumettes
I may have to submit a change for another frequency in the area as well. 151.700 pl 100.0 is an on scene channel for the whole Pontiac region by the looks of it not just Shawville-Clarendon. I've heard a few different depts on there checking in on scene.
Also a note. This is the first DMR type of radio communication I've found in my area for any fire Dept.
I'm actually suprised I can hear it considering this area is directly across from Pembroke ON and I'm in Renfrew.
Sounds good though so far, and they're all in English too.
Last edited:
Now correct me if in wrong. You can't input this as a 1 frequency system unless we have more then 1 talk group right? Looks like I have more then 1 now.
Networked means more than one site. Since there's only one site, it's not networked.
Ok then yes that's what I mean. It's a DMR 1 frequency site then. In the database it should be entered in as such but not as conventional frequency.
I've also found a website that may actually help me in identifying the area talk groups and radio IDs. Service de Sécurité Incendie de Pontiac Ouest
I know we've had this discussion in the past. Yes. In my radio I have it setup as a one frequency system. Not conventional. But I guess the database doesn't recognize though one frequency dmr systems? I thought it did.
It's a conventional channel and RadioReference treats it as a conventional channel. End of story.
Uniden decided to ignore the slot and group information and came up with their concept of One Frequency Trunking which RadioReference doesn't support.
The simple solution is to have Sentinel convert the conventional channels in the database to OFT but Uniden hasn't done this. Instead, you can program it by hand, use ProScan or get a Whistler scanner which does use all the information in the database.
DaveH
Member
TAFL shows 151.700 as MRC de Pontiac, TX at Campbell's Bay (digital), all others RX for some reason.
I've heard stuff in french on that frequency but pretty sure it's from Mont Tremblant area.
Not all FS in east of Pontiac are on MRC des Collines system 2088, have heard activity on 410.9625
and 412.5875 repeaters in the Luskville/Quyon area, often Hwy. 148 incidents.
Good info, keep it coming...
Dave
Not really an end of story issue here Mike. I get what your saying and I'm not trying to argue with you on this. However it really isn't just a conventional channel. It's a one frequency trunked channel. There is a difference. Sure you can manually program it 'properly' into your radio as a trunked type system for which it is.
The sad part is when people download this from RR to put into there radio it's done as a conventional channel. Where the problem is are the folks that don't know any better especially when they all have radios that are already preprogrammed for them and all they have to is download it to the radio and boom it's there.
For those of us that know how to customize things in our own radio know enough to change it from conventional to 1 frequency trunked. Sure you can still listen to it on your radio as a conventional channel. But let's be real here, that's not the type of frequency it is. And it really is too bad that it can't be put into the database this way and have RR support it. Because systems like this are quite simply being put into people's radios wrong. Again, sure you can listen and track things this way but its not correct.
The sad part is when people download this from RR to put into there radio it's done as a conventional channel. Where the problem is are the folks that don't know any better especially when they all have radios that are already preprogrammed for them and all they have to is download it to the radio and boom it's there.
For those of us that know how to customize things in our own radio know enough to change it from conventional to 1 frequency trunked. Sure you can still listen to it on your radio as a conventional channel. But let's be real here, that's not the type of frequency it is. And it really is too bad that it can't be put into the database this way and have RR support it. Because systems like this are quite simply being put into people's radios wrong. Again, sure you can listen and track things this way but its not correct.
151.700 PL 100.0 is what ya need to listen to this on scene channel. I haven't seen any other PLs on it just the one however multiple depts. use this frequency.
No, it's a conventional channel. Just because Uniden makes up a name for it and treats it differently than a conventional channel still doesn't make it anything else other than a conventional channel. Motorola and other manufacturers call these conventional channels. Whistler calls these conventional channels. RadioReference calls these conventional channels.
You're living in a Uniden world. You forget that Whistler correctly treats these as conventional channels when their software downloads the database.
One of the database policies is that the database will not cater to any specific scanner. If Uniden wants to treat conventional channels as trunking systems, they need to adapt their software. ProScan can do it, why can't Uniden figure it out?
I know using ARC536 you can't program any talkgroups for a conventional channel. You can only select slots. I haven't looked into how ProScan handles it. Are you able to program talkgroups on a conventional channel? I don't know. I haven't played around with ProScan enough yet an I don't bother with sentinel or any other programming software.
All I know is if it were a system with many talkgroups which I suppose is possible even on 1 frequency I wouldn't want to program in multiple channels of the same frequency all with different talkgroups. But programming it as a 1 frequency trunked with multiple talkgroups is much easier.
You are right in the uniden way of thinking. That's pretty much all I've ever owned. So I don't know how the others treat these.
It's too bad everyone couldn't be on the same page about this though as far as programming is concerned. Are you saying that Sentinal doesn't offer 1 freq. Trunked programming like the other software does and therefore it must be programmed as a conventional channel if that's all you were to use was sentinal?
All I know is if it were a system with many talkgroups which I suppose is possible even on 1 frequency I wouldn't want to program in multiple channels of the same frequency all with different talkgroups. But programming it as a 1 frequency trunked with multiple talkgroups is much easier.
You are right in the uniden way of thinking. That's pretty much all I've ever owned. So I don't know how the others treat these.
It's too bad everyone couldn't be on the same page about this though as far as programming is concerned. Are you saying that Sentinal doesn't offer 1 freq. Trunked programming like the other software does and therefore it must be programmed as a conventional channel if that's all you were to use was sentinal?
In reality, it's a conventional channel. I assume Uniden decided to treat it as a trunking system for efficiency. Quicker to scan the channel once and look for activity then to scan it multiple times. Makes sense to me. Whistler decided to honour the slot and group information in the database and treat it as multiple conventional channels.
Sentinel tosses the slot and group information and treats the channel as carrier squelch which is extremely frustrating. That's why Butel won't let you enter slot and group info.
So....
Should RadioReference turn all these conventional channels into OFT systems so Uniden scanners can handle it right? What about Whistler scanners? Should they use Uniden's OFT system? Does Uniden have a patent on OFT which Whistler will need to licence?
Should Uniden respect the slot and group information in the database and let people who are more advanced create OFT systems?
Should Sentinel automatically create OFT systems from the conventional data? ProScan can do it so why can't Uniden?
When you import a conventional channel into ProScan, it asks if you want to create an OFT system. It does this for every conventional DMR channel even if they have the same frequency. Once things are imported, you can cut and paste and create a proper OFT system.
Perhaps one day Uniden will handle conventional channels like ProScan does but heck, I'm still waiting for them to fix Siren.
Sentinel tosses the slot and group information and treats the channel as carrier squelch which is extremely frustrating. That's why Butel won't let you enter slot and group info.
So....
Should RadioReference turn all these conventional channels into OFT systems so Uniden scanners can handle it right? What about Whistler scanners? Should they use Uniden's OFT system? Does Uniden have a patent on OFT which Whistler will need to licence?
Should Uniden respect the slot and group information in the database and let people who are more advanced create OFT systems?
Should Sentinel automatically create OFT systems from the conventional data? ProScan can do it so why can't Uniden?
When you import a conventional channel into ProScan, it asks if you want to create an OFT system. It does this for every conventional DMR channel even if they have the same frequency. Once things are imported, you can cut and paste and create a proper OFT system.
Perhaps one day Uniden will handle conventional channels like ProScan does but heck, I'm still waiting for them to fix Siren.
3 talkgroups so far on here.
11, 13 and 21
11, 13 and 21
Some more talkgroups on here.
14
22 public works
23
14
22 public works
23
- Status
Similar threads
SDS100/SDS200:
Unknown Department with Unknown TGID
