safetyobc
Member
It would be nice to see a quality belt clip that could be completely removed, leaving little or no parts sticking out on the back. That would be great for everyone.
PSR-500 and PSR-600 Pre Release
- Thread starter KD4YGG
- Start date
- Status
Flat back, heavy duty mounting nuts for a clip moulded into a reinforced back... that would be great and give the most versatility to the most people. Reminds me a bit of old days with my HT220 Slimline -- clip, no clip (fit great into my jacket), or case.
GRE already included a plastic case around the electronics. Why should they be responsible for how you treat it?bc780l said:
And why should anyone who does not want a case (many people don't) be foreced to pay the price for one that is included? Why not purchase a case separately?
windigofer
Member
bc780l said:
In my own case, the one main time that I *do* use a belt clip on my Pro-96 tends to be at the racetrack, so my mileage may vary from some folks'...but yes, holsters/cases are nice if you can get them or make them. (In my own case, I look at this as an excuse for teaching myself leather stitching :3 Once the PSR-500 comes out, I can do measurements and work on stitching up a case.)
PanJurekMrJerry
Member
Object Oriented.
Object Oriented. That is what was typed on the picture of the radio scanner.
What does this mean?
KD4YGG said:
Object Oriented. That is what was typed on the picture of the radio scanner.
What does this mean?
JerryNone said:
It has been explained in this thread, go back and read the previous posts
windigofer
Member
JerryNone said:
It's been noted in the thread, and also probably in the Wiki by now, but essentially "object oriented" means that instead of operating in banks (like most scanners), things like talkgroups and control channels are assigned as a general "system object".
The term itself comes from the computer programming world--object oriented programming is where you can set up similar things as a general class and assign specific functions to that class. OOP is in fact so useful that practically all major programming languages in use today (yes, even including Java) are OOP languages (More in this Wikipedia article: http://en.wikipedia.org/wiki/Object_oriented).
(Yes, I am computer geek. So sue me :3)
The upshot of object-oriented scanner programming is that you can, for example, take all SAFE-T talkgroups (and SAFE-T is a pretty huge system) and all of the known control channels for SAFE-T in your area (there are about three receivable in my particular area) and put them together as a "SAFE-T Object". I can then work with the talkgroups themselves and put them in little groups like "Clark County Talkgroups" or "Police Agencies" or whatnot. (This is, as an aside, how you can program blinkenlights to go off for police agencies--you can set up a group of "police frequencies" as a specific object.) I can do likewise with Louisville's 800MHz Type IIi system (lots fewer users), and so on.
One of the really good things about this is that it saves a lot of memory with the scanner as well; among other things, you can have a V-Scanner containing only the frequencies you need.
Think of this as GRE's answer to Uniden's "Dynamic Memory" in the '996 (only expanded to trunking talkgroups as well) and you'll get the general idea :3
I am a little confused, how is this different than the dynamic memory aspect of the Uniden radios in reference to TG's? As a matter of fact, did I not read (somewhere) that the TG's are in a Scan List on the GRE's?windigofer said:
GRE: 5 Lists per system of 30 ID's each = 150 possible TG's limited to 5 lists
Uniden: 200 TG's per system in any number of groups assigned to any Group Quick Key (read lists) (10 available) or not at all (no GQK)
DonS
Member
The GRE info above seems to have come from the Wiki, which looks like a copy/paste from PRO-96 info. I haven't seen anything in this thread that indicates the PSR-500 uses this 5/30/150 scheme.loumaag said:
From reading this thread (esp. post #92 by cpunut), I had thought that the new GRE radio would let you create talk groups, associate them with a "system object" (which has all of the trunked system's CCs, etc.), then assign each talk group to one or more "scan lists". Apart from the Wiki, I haven't seen anything that indicates there's a limit on the number of talk groups per system or scan list.
EDIT: so, if I'm interpreting things correctly... I'd create the system object, then would start creating talk group objects, associating each with the system. Each of the talk group objects is also assigned to one or more scan lists. I could have a scan list for Police, one for Fire, and one for "everything". I could put all TGs, including things like "parks", "electric", etc. in the "everything" list. Police TGs would go in both the "Police" and "everything" lists. Similar for Fire TGs. I might normally scan just the "everything" list but, if something interesting happens, switch to just the Fire list - so I don't hear the garbage trucks during a big structure fire.
Last edited:
n4voxgill
Silent Key
Don, are you working on software for the GRE line of scanners? I sure hope so. Your software on previous models has been outstanding.
DonS
Member
Thank you.n4voxgill said:
When I can get some time away from my day job, I hope to write something for these new radios. They appear to be quite a bit different from previous models, though.
windigofer
Member
DonS said:
From what's been posted by folks who've had a chance to play about with the radio, the PSR-500 does *not* use the Pro-96 scheme. (Among other things, the maximum stored channel and talkgroup limits are drastically increased; 36,000 channels and 18,000 talkgroups and 20 V-Scanner banks.)
More info is in the "old thread":
http://www.radioreference.com/forums/showpost.php?p=527360&postcount=40 (thread includes a lot of discussion from folks who've been lucky enough to play with it)
Your impression (re talkgroups and how system objects work) would be correct; the best parallel here would be with how you can set up specific functions in a program library and set up specific variables in object groups, and from there call on program libraries and object groups for program functions. (I'm sure you're familiar with programming, so you know how that works)
As I understand it, that's pretty well how it'd work--instead of conventional system banks, you create a system object, then assign frequency and talk group objects to the main object; you can have multiple objects for police, fire, different trunked systems, and so on (this will work nicely for multisite trunked sites like SAFE-T in Indiana, for one).
As a minor aside, I do wonder how the new setup is going to affect a Win-PSR500 program versus the WinXX programs you've written before. (I know the WinXX family of scanner programs you've done do allow import/export to a common .csv format (and I've done so between Win97 demo, Win92, and Win96 quite successfully with a mild bit of massaging between Win97 and Win96 channels to account for differing number of channels per bank). I'm curious as to how object-oriented programs are going to break things (and yes, for the record, I'm quite willing to help beta on how well things *do* convert in practice). Reportedly, it was announced at Dayton Hamvention you were doing the programming program for the PSR-500, hence my morbid curiosity.)
windigofer
Member
DonS said:
Depending on how "object-oriented" channels do work in practice (as a previous programmer, odds are you could get info from GRE on how exactly this is meant to work), I would *think* the general import/export CSV format used for WinXX scanners would work to import/export data (my suggestion--use the "bank" field for the objects, have the channel numbers be the listing from frequency to frequency; that way, import/export shouldn't break too badly). But yeah, it's probably going to require GRE releasing info on the format to make sure how much things will in fact break...
(I myself have some curiosity in this as to how much info GRE releases re channel formats, data stream formats, etc. There are Tcl/Tk based open source programs for the Pro-92 based on reverse engineering of the data stream, but the Pro-95 onward had an encrypted data stream (when the scanner would send data to the PC) that made things kind of impossible to reverse engineer (hence no Linux-native programming tools). A Linux-native programming tool for the PSR-500 would be nice (or MacOS X-native, etc.)--but one needs to get the info from GRE first as to the data stream format and see what licensing may be required, etc. etc.)
windigofer
Member
DonS said:
Add me in the chorus encouraging you to make a bit of time (I know it's not THAT easy with a day job though, seriously). Failing that, you can always recruit folks to help out :3
PanJurekMrJerry
Member
rdale
Completely Banned for the Greater Good
What's the advantage of that group over the one with more members that's existed since the news?
http://groups.yahoo.com/group/PSR-500/
http://groups.yahoo.com/group/PSR-500/
This godsend comes immediately to mind.rdale said:
It isn't controlled by the authoritarian Joe M, mch, Voyager, NCC74656_USS_Voyager, or whatever screen name he chooses to go by at that particular moment. I'd say that is a DEFINITE advantage! One worth cheering about, even...!
Last edited:
Pacmonitor
Member
Lodis said:
Yes please tell GRE we need scanners with MPT1327 trunking.
It would be far more convenient than having to use a laptop and Mpt1327 trunking software and scanner for portable purposes we use presently!
Regards,
Pacmonitor New Zealand
pappy1
Member
Pacmonitor said:
- Status
Similar threads
