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.
Pro96COM Problems
- Thread starter Forts
- Start date
- Status
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.
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
Rock or Something
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
Member
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
Mike
N8OAY
Member
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
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
Rock or Something
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.
mikey60
Member
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
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
Last edited:
mikey60
Member
Easy fix. It will be fixed in the next Release.
Mike
Mike
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.
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.
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.
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
Member
Could be a memory leak there. I'll see if I can find something in the code.
Mike
Mike
mikey60
Member
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
alwayslookin
Member
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.
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.
Program is not responding
Mike, go down to "11/02 14:39:19" and you will see when the first problem started.
-
"11/02 14:02:34","Group","00-0093","138.46500"," 18","RCMP FtQuAppelle","2212103",""
"11/02 14:02:37","Group","00-0048","138.24000"," 18","RCMP FtQuAppelle","2212103",""
"11/02 14:32:46","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:18","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:23","Group (Enc)","00-0048","138.24000"," 18","RCMP FtQuAppelle","2212098",""
"11/02 14:33:26","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:30","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:38:47","Group (Enc)","00-0048","138.24000"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:38:53","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2211942",""
"11/02 14:38:55","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:39:13","Group (Enc)","00-0048","138.24000"," 26","RCMP Swift Current","2211727",""
"11/02 14:39:16","Group (Enc)","00-0219","139.09500"," 26","RCMP Swift Current","2211727",""
-
See the frequencies 138.4650 is now followed by (/5) and 138.2400 by (/04) and 139.0950 by (/43)
"11/02 14:39:19","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:39:28","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211727",""
"11/02 14:39:29","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 14:43:14","Group (Enc)","00-0219","139.09500/43"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:43:18","Group (Enc)","00-0093","138.46500/5"," 18","RCMP FtQuAppelle","2212557",""
"11/02 14:43:20","Group (Enc)","00-0048","138.24000/4"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:50:15","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:23","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2211742",""
"11/02 14:50:26","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:29","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2211744",""
"11/02 14:50:32","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:34","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211744",""
"11/02 14:50:39","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2219005",""
"11/02 14:56:52","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:56:56","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211780",""
"11/02 14:56:58","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 15:04:42","Group (Enc)","00-0219","139.09500/43"," 18","RCMP FtQuAppelle","2219004",""
"11/02 15:04:49","Group (Enc)","00-0093","138.46500/5"," 18","RCMP FtQuAppelle","2212100",""
"11/02 15:04:52","Group (Enc)","00-0048","138.24000/4"," 18","RCMP FtQuAppelle","2219004",""
This grant log is the only data that I saved from that day. No dump/Raw dump data.
This was the only time I have ever seen number 5 / 4 / 43 following the frequencies .
-
The second problem happens quite often.
I click on "Stop Decode" but it does not return to "Read Data From Radio"
I then try to close the Window but it will not close.
The program is not responding. Both Windows 7 Pro and XP Pro have this same problem.
Resource Monitor shows that the program is still running normally. I select "End Process"
That stops the program and the Window closes. This is the only way to close the Window.
Only the backup file is lost for that day. No other data is lost.
-
A view of problems to report showed more than a dozen for this program.
Problem signature:
Problem Event Name: AppHangB1
Application Name: Pro96Com.exe
Application Version: 1.11.2.194
Application Timestamp: 00000000
Hang Signature: a63d
Hang Type: 0
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Hang Signature 1: a63d8c93f0bba43d2740d65a984032f7
Additional Hang Signature 2: a93b
Additional Hang Signature 3: a93b6b5861ac4f247880dd9778546e65
Additional Hang Signature 4: a63d
Additional Hang Signature 5: a63d8c93f0bba43d2740d65a984032f7
Additional Hang Signature 6: a93b
Additional Hang Signature 7: a93b6b5861ac4f247880dd9778546e65
-
Mike, go down to "11/02 14:39:19" and you will see when the first problem started.
-
"11/02 14:02:34","Group","00-0093","138.46500"," 18","RCMP FtQuAppelle","2212103",""
"11/02 14:02:37","Group","00-0048","138.24000"," 18","RCMP FtQuAppelle","2212103",""
"11/02 14:32:46","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:18","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:23","Group (Enc)","00-0048","138.24000"," 18","RCMP FtQuAppelle","2212098",""
"11/02 14:33:26","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:33:30","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:38:47","Group (Enc)","00-0048","138.24000"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:38:53","Group (Enc)","00-0219","139.09500"," 18","RCMP FtQuAppelle","2211942",""
"11/02 14:38:55","Group (Enc)","00-0093","138.46500"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:39:13","Group (Enc)","00-0048","138.24000"," 26","RCMP Swift Current","2211727",""
"11/02 14:39:16","Group (Enc)","00-0219","139.09500"," 26","RCMP Swift Current","2211727",""
-
See the frequencies 138.4650 is now followed by (/5) and 138.2400 by (/04) and 139.0950 by (/43)
"11/02 14:39:19","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:39:28","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211727",""
"11/02 14:39:29","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 14:43:14","Group (Enc)","00-0219","139.09500/43"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:43:18","Group (Enc)","00-0093","138.46500/5"," 18","RCMP FtQuAppelle","2212557",""
"11/02 14:43:20","Group (Enc)","00-0048","138.24000/4"," 18","RCMP FtQuAppelle","2219004",""
"11/02 14:50:15","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:23","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2211742",""
"11/02 14:50:26","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:29","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2211744",""
"11/02 14:50:32","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:50:34","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211744",""
"11/02 14:50:39","Group (Enc)","00-0219","139.09500/43"," 26","RCMP Swift Current","2219005",""
"11/02 14:56:52","Group (Enc)","00-0093","138.46500/5"," 26","RCMP Swift Current","2219005",""
"11/02 14:56:56","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2211780",""
"11/02 14:56:58","Group (Enc)","00-0048","138.24000/4"," 26","RCMP Swift Current","2219005",""
"11/02 15:04:42","Group (Enc)","00-0219","139.09500/43"," 18","RCMP FtQuAppelle","2219004",""
"11/02 15:04:49","Group (Enc)","00-0093","138.46500/5"," 18","RCMP FtQuAppelle","2212100",""
"11/02 15:04:52","Group (Enc)","00-0048","138.24000/4"," 18","RCMP FtQuAppelle","2219004",""
This grant log is the only data that I saved from that day. No dump/Raw dump data.
This was the only time I have ever seen number 5 / 4 / 43 following the frequencies .
-
The second problem happens quite often.
I click on "Stop Decode" but it does not return to "Read Data From Radio"
I then try to close the Window but it will not close.
The program is not responding. Both Windows 7 Pro and XP Pro have this same problem.
Resource Monitor shows that the program is still running normally. I select "End Process"
That stops the program and the Window closes. This is the only way to close the Window.
Only the backup file is lost for that day. No other data is lost.
-
A view of problems to report showed more than a dozen for this program.
Problem signature:
Problem Event Name: AppHangB1
Application Name: Pro96Com.exe
Application Version: 1.11.2.194
Application Timestamp: 00000000
Hang Signature: a63d
Hang Type: 0
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Hang Signature 1: a63d8c93f0bba43d2740d65a984032f7
Additional Hang Signature 2: a93b
Additional Hang Signature 3: a93b6b5861ac4f247880dd9778546e65
Additional Hang Signature 4: a63d
Additional Hang Signature 5: a63d8c93f0bba43d2740d65a984032f7
Additional Hang Signature 6: a93b
Additional Hang Signature 7: a93b6b5861ac4f247880dd9778546e65
-
mikey60
Member
OK, I really need to see the raw data when this happens. The grant log really doesn't tell me what I need to know.
Mike
Mike
- Status
Similar threads
