mikea7531 said:
I've tried it out with my Uniden BC796D and my GRE PSR-600 and it won't control either one of them.
I expect to make more voice following progress for the next release.
mikea7531 said:
Other than that, the program is fantastic - it's been running 24 hours straight without a single crash.
Thanks Mike.
cg said:
Unitrunker seems to be adding a Control Channel for an adjacent Site when I run it on the Ct SP Omnilink system. I have deleted every file, reloaded the newest UT files and imported the info from my v1.0.57 Unitrunker files. Within a few seconds, it adds the adjacent Site CC and marks/colors it as a control channel.
Weirdness. Open your signal receiver's window and turn the decode Logging on. Let that run for a minute or so. Please send me the resulting log (you can turn logging back off to save disk space). I'll sort through the messages. Usually this is caused by switching the receiver rapidly between two control channels (the program adds the information before it realizes the monitored system has changed).
bneilson said:
under the "Groups" tab, I am unable to sort by 'Hits'. The column order changes but is not ordered by hits. When I try this same thing under the "Users" tab it works just fine.
Good find. I'll fix that.
Viper43 said:
it pulls up the callsign but not the NAC, even adding it manually it reverts to zero
The NAC is readonly. It isn't meant to be edited. The NID (which includes the NAC) is stripped from the data coming from your PSR-500 or PSR-600 so there is no way to infer modulation type or NAC. The radio does display the NAC so I might be able get at it by reading the display but this is a lot of extra work for a minor detail making this a low priority.
Viper43 said:
if you check the "confirmed" box it's gone the next day and hits reset as well. Not sure if thats what you intended but I'd prefer not loose the the confirmation at the very least, and actually wouldn't mind if it kept the count going but thats no big deal.
It should be there.
Viper43 said:
Is there a hit count for RID and TGID? That may be helpfull too but I hadn't found any.
Look for "Hits", groups, radios and channels all have hit counters.
Jay911 said:
Works great on my setup now, though I gave up on the Eee PC's internal sound input and am using a USB SBLive sound "card".
That sucks. The ASUS has some nice specs - despite the odd screen geometry.
Jay911 said:
Still getting Windows error upon trying to shut down Uniform though.
Does the program (at least) crash *after* saving your data? Send me an email if you can get a crash dump of this.
Jay911 said:
Also the RR download that crashed yesterday and was mentioned, also crashes trying to download P25 systems without sysids in the DB, i.e. SID 4632. Wonder if systems with incomplete information are being unkind to your download procedures (or vice versa)?
I'll test out the offending systems to see what's up. The XML code is probably not behaving defensively enough to unexpected input.
Jay911 said:
When a download is successful into a "new system" (i.e. a blank system entry), should it not overwrite the "ID" field if possible and update the "Type" to what is stored in the RRDB? I'm not sure I'm consistently seeing that on downloads either.
It should update the system's RR DB ID with the RR DB SID number from the download. The program can determine type directly from the control channel (though it may take time). The RR database's type / category system is different from what Unitrunker needs to fingerprint a system. Band plans and fleet maps sometimes change - as do channel assignments. I try to rely on the control channel as much as possible (and remember what was learned from previous decoding sessions).
Jay911 said:
Also, please refresh my memory - is it true that an MPT1327 system when found will create a new system even if that system ID is already in the DB? That's the behavior I'm seeing. I seem to recall being told previously that this was the case because of the inability to know the frequency on the signal-providing scanner (or other audio source).
Some "default" system IDs are reused often enough that the system ID can't be reliably used to distinguish two systems. This is almost as bad as EDACS and LTR (but not quite). The frequency is an easy way to distinguish two systems that have similar control channel traits.
Jay911 said:
And one final thing - it appears that certain characters in text fields are not being carried through in RR downloads, i.e. & and - and so on, and are being replaced with spaces. Example: "Edmonton Public Safety & Public Works" becomes "Edmonton Public Safety(three spaces)Public Works". Is this intentional?
I though I was handling all the built-in XML special characters like less-than, greater-than and ampersand. I'll check this out.
When I reopen unitrunker and turn to that controller channel, a new LIMBO systems comes up.
As rdale suggests - you need to fill in the control channel frequency. The program will search your data file for an existing site that matches (same site number and control channel frequency) and ditch the "limbo" site. EDACS does not have strong identity so this is the only way I've found for the program to accurately match previously logged data with a new control channel decoding session. You'll have to do this extra step each time you start decoding a new EDACS system.
There's a similar issue with decoding / ID'ing LTR and - to a lesser extent - MPT1327.
nickel9111 said:
I would think the software would know what control I am listening to, and find that in the saved file.
If only that were true. In the future - I may be able to eliminate this manual step IF the signal radio is also a computer controlled model (and can report it's tuned frequency directly to the program). That's a ways off. Currently - all receivers are treated as if they are blind (eg. they can't report the currently tuned frequency).
