Pro96COM Problems

[FlashP]

I get the "can't stop" action about every tenth time. Hit the "Stop..." button, and it goes grey rather than switching to "Read...", and the program starts hogging a CPU. It seems to still respond to menu commands while waiting be killed. WinXP. Just kind of a running nuisance.

[kruser]

Originally Posted by FlashP

I get the "can't stop" action about every tenth time. Hit the "Stop..." button, and it goes grey rather than switching to "Read...", and the program starts hogging a CPU. It seems to still respond to menu commands while waiting be killed. WinXP. Just kind of a running nuisance.

I get the same ever so often. I can't exit the program when it happens and must use task manager to stop it.
It will then restart and work fine.
Odd as no error logs are logged.

[wbigcount]

Mine does the same thing, the only difference is it will erase all my talkgroups and radio id's when it happens.

[kruser]

Originally Posted by wbigcount

Mine does the same thing, the only difference is it will erase all my talkgroups and radio id's when it happens.

Mine retains the TG's and RID's in the log files but they are lost whenever the program restarts and the program must rebuild them as the data comes across.

I also see odd things when I forget to stop reading from radio and I change the CC frequency to another CC on the same system. It will sometimes leave some of the voice channels in the System Activity screen from the CC I'd just switched away from. When that happens, it saves those unused voice channels in the Towerxxxx.txt file and I must then go in and edit that towers txt file and remove the incorrect frequency listings.
I've seen it do the same with the CC and Alternate CC frequencies also but not as often as it does with the voice channels.
Of course if I tell it to stop reading from radio before I switch frequencies, I don't have those problems.

And the deal with it freezing when you tell it to stop reading only happens maybe one in 30 to 50 times so it is pretty rare that I see it.
Maybe it only happens if certain data is coming across the Packet Dump tab at the moment you hit the stop button.

Not really a big deal though being a rare problem for me anyway.

I've seen the problem with any supported radio as the data radio (GRE or Uniden).

[Wilrobnson]

Any more ideas? I downloaded a new copy of the program, trashed everything else save for the actual data on various systems, and started up the new version only to be hit with the exact same Access Violation message quoted above.

[mikey60]

It may be something in the actual data that's corrupted. Try renaminng the system folder and starting from scratch to see if it works. The stop the program and copy the talkgroups.txt file into the new system folder and try again. If that works, stop the program again and copy in the radios.txt file and see if it errors again. If it crashes on one of those files, please ZIP that file and send it to me (mike@psredit.com) to look at and I'll see if I can figure out what's happening.

Mike

[N8OAY]

Another thing to check when having COM Port problems is duplicate COM Ports or other problems in Device Manager. If you see a COM Port with a big yellow "?" on it, that could be the problem. Verify that you have the driver CDs or downloaded driver files for the COM Ports you have installed, then delete the port(?) with the yellow question marks and restart the computer. If Windows finds new hardware, reload the driver.

I had this problem a few years ago with WinXP. I had been using the cable that came with software for a Yaesu portable ham radio, then bought a cable from Radio Shack and installed the driver that came with the new cable. Turned out that both cables used the same driver and I did not need to install the driver for the Radio Shack cable.

You can fix a lot of problems when you see those yellow question marks in Device Manager.

Dave

[Wilrobnson]

I've tried everything I can think of, down to downloading and running the program off a thumb drive after trashing anything and everything related to P96C (after safely copying my system notes onto another thumb drive). Today I began suspecting bad com ports after my external fan starting running intermittently. Will advise.

[mobile_1]

Please have a look at this file. Thanks

[mikey60]

I'll look at this. It's obviously decoding off by one byte on the third part.

Also note that Pro96Com is not designed to decode the ISP messages, do what it shows there is not likely to be correct on most messages.

Mike

[mikey60]

Easy fix. It will be fixed in the next Release.

Mike

[Jay911]

LCNs are represented in TSBKs by hexadecimal numbers as you clearly already understand. 02CD = 717, as you've stated, but technically that's 00-0717. The first number is the "iden" or identifier number, and the second number will be 0 to 4095 decimal (0 to FFF hex).

In the TSBK, instead of being transmitted in two blocks like our radios, scanners, and programs translate them (i.e. "12-3328"), it's transmitted as a whole number. More precisely, the first "digit" is translated into the iden, and the last three "digits" are the decimal value for that iden. 12-3328 translates to "CD00". 7-2816 translates to "7B00".

It would appear that PRO96COM is picking octets 1 and 2 of block 3 as the LCN, instead of octets 0 and 1.

As for the ISP messages at the end of that text file... ISPs don't request channel numbers. You won't find LCNs nor frequencies in ISPs. It's the duty of the system, the part that generates the OSPs, to allocate the channels/frequencies - the system tells the radios (the devices which generate ISPs) what channel to use, not the other way around.

The ISP opcode is 10, Individual Data Service Request. Octet 2 is Service Options (04 in this position is a plain-jane default-priority call) and Octet 3 is "reserved" (generally blank). Octets 4-6 and 7-9 are the target address and source address respectively.

[Jay911]

Mike - my long-winded explanation took longer to type out than your quick assessment. My apologies for butting in.

While I'm here - is there a possibility of a memory leak in the new "read from HomePatrol log" function (or maybe I'm overloading it)? I have some pretty substantial logs (tens of megabytes) which I've tried to run thru the software, and intermittently I get "out of memory" errors and hard crashes from the program. Sometimes it's after/during only one log being processed, and sometimes it's after I have tried to process several of these large logs one after the other.

[mikey60]

Could be a memory leak there. I'll see if I can find something in the code.

Mike

[mikey60]

Originally Posted by Jay911

While I'm here - is there a possibility of a memory leak in the new "read from HomePatrol log" function (or maybe I'm overloading it)? I have some pretty substantial logs (tens of megabytes) which I've tried to run thru the software, and intermittently I get "out of memory" errors and hard crashes from the program. Sometimes it's after/during only one log being processed, and sometimes it's after I have tried to process several of these large logs one after the other.

Yes, there was one there. It would leak each time a new file was decoded. There was also a memory leak when decoding from a Uniden scanner or the Anritsu machine. These have all been corrected for the next release.

I don't have my scanner here at work to do any testing on the updates, so I'll wait until later this evening when I get a chance to test them a bit before I release it.

Mike

[mobile_1]

Incorrect RX channels on tower page. Thanks for the data grant update.

[alwayslookin]

I ran into the same problem I deleted all files and restated brand new went into my docs folder into pro 96 folder then into the pro96.ini file open it with notepad the put in ShowAllPorts=Yes
HighPort=255 right under the communications listing and saved. then open pro96 up all works perfect hopes this helps anyone. Big thanks to MIKEY60 for the info.

[mobile_1]

Originally Posted by mobile_1

Incorrect RX channels on tower page. Thanks for the data grant update.

Thanks for the update. Will test/try it out this week.