• Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

Pro96 Mixed Band Extended Table

Status
Not open for further replies.

wlmr

Member
Joined
Apr 26, 2004
Messages
412
Anyone have any idea how I can program the extended tables (or if I need to) for a P25 system with the following table? (captured via Pro96com)

-Tables
#Format:
Table ID,Base Freq, Spacing, Input Offset, Assumed/Confirmed, BandWidth
00,851.00625, 0.00625, -45.00000, "Confirmed", 0.00625
01,762.00625, 0.00625, 30.00000, "Confirmed", 0.00625
02,136.00000, 0.01250, 6.77500, "Confirmed", 0.01250
03,136.00000, 0.01250, 5.96250, "Confirmed", 0.01250
04,136.00000, 0.01250, 5.70000, "Confirmed", 0.01250
05,136.00000, 0.01250, 6.83750, "Confirmed", 0.01250
06,136.00000, 0.01250, 4.67500, "Confirmed", 0.01250

I see two problems right away, Win96 shows 6 entry lines (I'm looking @ 7 above) & don't know what the scanner will do with the 700Mhz portion.
 

FPO703

Member
Joined
Jan 19, 2001
Messages
2,624
Location
Planet Earth
what type of system are you trying to program in? If it's 800 MHz, you don't need the extended tables. If it's 700 MHz of hi-band, I don't know.
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
One system, mostly 800 (can scan those sites fine), one site mixed 800/700 channels (too far away to play with), two sites VHF (would just build extended table but have first two entries in table confusing the matter).
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
Pardon me for being cryptic but it's not in Ohio. I'll wait & see who identifies the system. Won't be hard if done the way I did.

The VHF sites are currently to test/demonstrate crossband interoperability in one system. No traffic other than testing being transmitted @ this time.

I can (if in the right locations) receive the VHF control channels but without programming the offset info I know it won't play the talkgroups.

I'll worry about receiving the mixed 800/700 site another day.
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
For the site(s) that use the VHF just use the VHF referenced entries. You will need to set all of them up because of the math involved. Below see the math as explained by Mike (the Pro96Com author) and Don Starr.

Code:
Ch lo = Channel Identifier * 4096
Ch hi = Ch lo + 4095
Offset = Ch lo
Base = Shown Value for Channel Identifier
Spacing = Shown Value for Channel Identifier

So for Channel Identifier 3...

Ch lo = 3 * 4096 = 12288
Ch hi = 12288 + 4095 = 16383
Offset = 12288

Example:

00,851.00625,0.00625,-45.00000,"Confirmed",0.00625
02,450.00000,0.01250,5.00000,"Confirmed",0.01250

Ch Lo = 02 * 4096 = 8192
Ch Hi = 8192 + 4095 = 12287
Base = 450.0000
Spacing = 12.5
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
Actually looking at your table again, I see the only reason they are using multiple tables is because the input offset is changing by table, this does not concern you so in this instance you can take the lowest one and the highest one and combine them in one entry.

That is:
Ch Lo = (2 * 4096) = 8129
Ch Hi = (6 * 4096 + 4095) = 28671
Base = 136.0000
Spacing - 12.5 KHz

That should have you going.
By any chance have we already removed this system from the DB?

If you use the math above for the first two tables you can put all of this in one bank (assuming they are the same system) and it will work with three table entries although adding the 700 will be fruitless since it can't go there on a trunking command.
 
Last edited:

wlmr

Member
Joined
Apr 26, 2004
Messages
412
Doesn't the table # being broadcast by the system need to match the extended table # in Win96? All the sites are broadcasting the entire table, it's not segmented by what Freqs the site has. I'll feel foolish if the scanner just needs the offsets, make my life much easier.
I've seen/used the South Dakota table, fewer offsets, all VHF.
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
We overlapped, I was typing when you responded.

No, hasn't ever been deleted from database. Most of it is very much in there. (Some errors with the control channels & other info but functionally ok.) The VHF sites have been mentioned before, shortly after they were turned on.

I'll try your suggestion on programming. To be continued ...
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
wlmr said:
Doesn't the table # being broadcast by the system need to match the extended table # in Win96? All the sites are broadcasting the entire table, it's not segmented by what Freqs the site has. I'll feel foolish if the scanner just needs the offsets, make my life much easier.
I've seen/used the South Dakota table, fewer offsets, all VHF.
First, SD is a Motorola system, (Type II); what you are looking at is a Project 25 system, has nothing to do with the way a Moto system operates. (The scanner manufacturers continue to foster this incorrect perception.)

No the table number has no bearing on what position that you put it in the multi-table entry area. As pointed out, you could put this in one entry (if you only wanted the VHF stuff). The important thing is that the math is done correctly (which does require the use of the table number) but the Pro-96/2096 does not care about the table number itself. This is where the Uniden radios outshine the GRE, because they read the table entries directly the way they are sent, whereas the GRE require you to supply the math because they do the math before checking for an base/offset in a table.
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
loumaag said:
Actually looking at your table again, I see the only reason they are using multiple tables is because the input offset is changing by table, this does not concern you so in this instance you can take the lowest one and the highest one and combine them in one entry.

That is:
Ch Lo = (2 * 4096) = 8129
Ch Hi = (6 * 4096 + 4095) = 28671
Base = 136.0000
Spacing - 12.5 KHz

That should have you going.
By any chance have we already removed this system from the DB?

If you use the math above for the first two tables you can put all of this in one bank (assuming they are the same system) and it will work with three table entries although adding the 700 will be fruitless since it can't go there on a trunking command.

So, - although the 800 Mhz portion doesn't need a table entry for 9600 P25 systems, if I have sites from all 3 bands (separated by conventional freqs) in one bank I'll need to create 3 table entries bacause of the VHF?
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
wlmr said:
So, - although the 800 Mhz portion doesn't need a table entry for 9600 P25 systems, if I have sites from all 3 bands (separated by conventional freqs) in one bank I'll need to create 3 table entries bacause of the VHF?
Well actually you can ignore the 700 since it won't work anyway. The reason you need to add the 800 table is because you are changing the default from the internal table to what you are entering, hence you have to put the 800 table in there because you are ignoring the internal one. As far as the conventional between CCh's in the bank, that is up to you sometimes it makes it work better, sometimes it makes not difference but that has been hashed over a lot here so I won't continue.
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
loumaag said:
Well actually you can ignore the 700 since it won't work anyway. The reason you need to add the 800 table is because you are changing the default from the internal table to what you are entering, hence you have to put the 800 table in there because you are ignoring the internal one. As far as the conventional between CCh's in the bank, that is up to you sometimes it makes it work better, sometimes it makes not difference but that has been hashed over a lot here so I won't continue.
Agreed on the conventional channel divider statement.

In the interests of sanity control, I'll probably be trying the VHF sites in their very own bank to start.

Now for the free time & right reception conditions to test this!
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
Okay, now where is that embarrassed icon we used to have.....

Look, my brain went into a senior moment when I first looked at this and I gave you the 180º wrong answer here. :eek:

Because of the way the Pro-96/2096 counts from the offset you specify, each table must be accounted for separately. So assuming you just want to do the VHF portion of the thing the table would look like this:
Code:
Ch Lo    Ch Hi     Base      Offset      Step
 8192    12287    136.000     8192       12.500
12288    16383    136.000    12288       12.500
16384    20479    136.000    16384       12.500
20480    24575    136.000    20480       12.500
24576    28671    136.000    24576       12.500
Sorry for the foul-up...I've got to start thinking more and reacting less...:(
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
Glad to hear it actually 'cause the other way didn't work. Look, two apostrophes - wait, that's another thread! I could hear traffic in "conventional mode" so knew something wasn't right. I'll try the new setup as soon as I can & let you know.

BTW, can you point me at the old thread that went into detail about how to calculate all this? Had a senior moment of my own trying to remember what was done how & why. I appreciate the effort you've put into this already but understanding what I'm doing is always best in the long run.
 

loumaag

Silent Key - Aug 2014
Joined
Oct 20, 2002
Messages
12,911
Location
Katy, TX
wlmr said:
BTW, can you point me at the old thread that went into detail about how to calculate all this? Had a senior moment of my own trying to remember what was done how & why. I appreciate the effort you've put into this already but understanding what I'm doing is always best in the long run.
Glad to, it is in the thread which announced (a little early) the Pro96Com software to begin with:
http://www.radioreference.com/forums/showthread.php?t=4049

Mostly it was early on stuff, especially the posts traded back and forth between Don and Jose about the ALMR system.
 

wlmr

Member
Joined
Apr 26, 2004
Messages
412
Thanks for the info, I'll smile while I read it. You're correction was successful! The VHF reception was very picky. Either I had a poor location for reception (didn't seem so most of the time) or a too many other signals blinding the poor scanner. Kind of leaning toward the latter. 800 is much more rock solid.

Time to test the other VHF site & then on to create the 800MHz portion in the same bank!

Update - - looked at the thread you mentioned, lightbulb time part way down the first page both for calculating the tables & for why I needed multiple tables. Thanks!

Second VHF site also very marginal where I've tried. At least I'm getting a TG indicator & some digital noise even with 60% max on the control channels.
 
Last edited:
Status
Not open for further replies.
Top