Unitrunker - Smartzone Omnilink

[mtindor]

Rick,

For a long time I have noticed something "unusual" to me. I am not sure if it is something you are aware of.

I listen to the Ohio MARCS statewide system. I live near the boundary of two zones (6F10 is my home zone with 6F0F being the other zone).

On 6F10 sites where there are site neighbors from the 6F0F zone (and on 6F0F sites where there are site neighbors from the 6F10 zone) I'll find that the particular bordering site ends up getting "corrupt" channel data. Well, I don't know if it's "corrupt" or not - perhaps it is how you have intended it to be - or perhaps it is something you are aware of but which isn't a priority for you.

When I say "corrupt" I mean that the 6F10 site that I might be monitoring will eventually gain channels that I know are not its own channels but rather are control channels of neighboring sites in different zones.

In the images below, notice that I am monitoring 6F0F Site 31. Notice it's neighbors (and the reported LCNs of their active control channels).

LCNs 682, 817, 823 and 969 are the correct channels for this site.

LCNs 672 and 693 are _not_ channels on this site. Rather, they are the LCNs of the active control channels of two neighboring sites (6F10 site 63 and 64 respectively). But yet they are reported as being channels on this site.

NOTE #1: The "erroneous" channels will not instantly show up. They show up after an undertermined amount of time - could be hours or could be days.

NOTE #2: Ignore 6F10 Site 46 listed in the PEERS. This likely got polluted when I switched the scanner from one site (6F0F 31 Salem) to another one (6F10 61 Dellroy) without stopping the receiver first. I have tried VERY hard to not do that since I started running UT again on this system - and I didn't do it until tonight when I was trying to gather these screenshots. Dummy me.

Do you understand the "problem" I'm describing? I wish I could give you logs, but UT doesn't seem to be dumping the receiver logs in my Vista 32-bit for some reason. Logging is selected (unless I was a dumbass and overlooked some other place to select it).

Mike

 

[SCPD]

When I say "corrupt" I mean that the 6F10 site that I might be monitoring will eventually gain channels that I know are not its own channels but rather are control channels of neighboring sites in different zones.

That is typical problem of monitoring one site and then switching to another. The program will attempt to back-out the unwanted channels but this isn't guaranteed.

NOTE #1: The "erroneous" channels will not instantly show up. They show up after an undertermined amount of time - could be hours or could be days.

This may be a result of bad data due to noise. Some messages are ambiguous.

Do you understand the "problem" I'm describing?

I think so.

I wish I could give you logs, but UT doesn't seem to be dumping the receiver logs in my Vista 32-bit for some reason. Logging is selected ...

Make sure the Decode / Logging option is checked, as opposed to the receiver Control / Logging (which doesn't work).

After you enable logging, you may need to re-start the receiver for the change to take effect. Clean your data (delete the unwanted channels), let it run. After the offending channels reappear, please email the log files that overlap with the "First Seen" timestamp of the offending channel(s). I can skim the decode logs to see if this is a noise issue or a genuine bug.

 

[mtindor]

That is typical problem of monitoring one site and then switching to another. The program will attempt to back-out the unwanted channels but this isn't guaranteed.

This may be a result of bad data due to noise. Some messages are ambiguous.

I'd buy that - except that I"m running Inline to a PSR-197 - and I thought in the past that you weeded out any ERR data on the PC/IF. So if it didnt' make it because of noise it would have gotten an ERR and thus wouldnt' get stuffed into UT (Im guessing).

Make sure the Decode / Logging option is checked, as opposed to the receiver Control / Logging (which doesn't work).

Ok - I exerted a little extra effort and found it.

Clean your data (delete the unwanted channels), let it run. After the offending channels reappear, please email the log files that overlap with the "First Seen" timestamp of the offending channel(s). I can skim the decode logs to see if this is a noise issue or a genuine bug.

Ok will do. Thanks!

Mike

 

[mtindor]

Ok - got the data. Will email you shortly.

Thanks

Mike

 

[SCPD]

I'd buy that - except that I"m running Inline to a PSR-197 - and I thought in the past that you weeded out any ERR data on the PC/IF. So if it didnt' make it because of noise it would have gotten an ERR and thus wouldnt' get stuffed into UT (Im guessing).

If only it were that easy. Motorola decoding is a pain - particularly for SZ systems - because (a) the error detection is at the word level and (b) messages may span 1, 2 or 3 words (or "OSWs" as some like to call them). Encountering a bad word mixed in with good ones leaves the dilemma of whether the good words are valid messages or fragments that must be discarded. I have logic to deal with this but there may be combinations or circumstances I haven't yet conceived.

Ok - got the data. Will email you shortly.

Wow - that was fast. Thanks Mike!

 

[mtindor]

If only it were that easy. Motorola decoding is a pain - particularly for SZ systems - because (a) the error detection is at the word level and (b) messages may span 1, 2 or 3 words (or "OSWs" as some like to call them). Encountering a bad word mixed in with good ones leaves the dilemma of whether the good words are valid messages or fragments that must be discarded. I have logic to deal with this but there may be combinations or circumstances I haven't yet conceived.

That makes sense to me. I'll try to log something from a less 'fringe' system. If you notice the signal in those images, the signal appears great. But it's a 3 out of 5 bar signal on my PSR and thus it isn't always 99% decode. If a gnat flies in between me and the tower site it might degrade for a second or two, increasing the error rate. I'll let it sit on a 5 / 5 strength tower site that has neighbors from another zone and we'll see if that'll produce anything.

Thanks again Rick!

mike

 

[mtindor]

Rick,

I was watching again during one of these events. I was monitoring 6F0F-34. One of it's neighbors is 6F10-63 with a CC LCN of 672. At 11:57:08 I got a "First Seen" on channel 672 (867.8125) which showed up in my channel list for 6F0F-34.

I grabbed the Unitrunker logs and snipped them from so that I only evaluated data between 11:57:07 and 11:57:10.

I grepped the abbreviated logfile for '2A0' - which is LCN 672.

The only reference I got was after the 11:57:08 timestamp and it was:

2009-02-07 11:57:08 40 of 48 (83%)
62A0 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2A0 867.8125

At 12:12:53 I got another erroneous channel added - It was LCN 693 (868.3375) belonging to site neighbor 6F10-64. I again grabbed a snippet of logs between 12:12:52 and 12:12:55 and grepped it for the instance of '2B5', which is LCN 693. here is what I had:

2009-02-07 12:12:53 40 of 43 (93%)
62B5 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2B5 868.3375


I then and grabbed a log from 11:55:45 to 12:20:05 timestamp. I grepped the instance of that log (again monitoring only 6F0F-34) and see the only instances of PeerInfo lines are:

2009-02-07 11:57:08 40 of 48 (83%)
62A0 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2A0 867.8125

2009-02-07 11:58:16 42 of 43 (98%)
63D0 G 30B Smartzone PeerInfo, SysId=6F0F, DChan=3D0 867.8000

2009-02-07 11:59:59 42 of 43 (98%)
63D0 G 30B Smartzone PeerInfo, SysId=6F0F, DChan=3D0 867.8000

2009-02-07 12:00:55 41 of 44 (93%)
63D0 G 30B Smartzone PeerInfo, SysId=6F0F, DChan=3D0 867.8000

2009-02-07 12:12:53 40 of 43 (93%)
62B5 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2B5 868.3375

2009-02-07 12:14:37 41 of 45 (91%)
62B5 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2B5 868.3375

2009-02-07 12:14:43 41 of 45 (91%)
62B5 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2B5 868.3375


So in the course of ~25 minutes I only got eight PeerInfo instances in the logfile. There is no rhyme or reason as to when they occur or why they are transmitted. Notice there are two sites in an adjacent zone mentioned and one site in the same zone (6F0F) mentioned - and one has to wonder why only one site in 6F0F was mentioned when there are actually 5 neighboring sites in 6F0F.

I don't know if any of this helps, or if the PeerInfo lines are related to the erroneous channels being added or not - But something doesn't seem right here.

Mike

 

[SCPD]

One of it's neighbors is 6F10-63 with a CC LCN of 672. At 11:57:08 I got a "First Seen" on channel 672 (867.8125) which showed up in my channel list for 6F0F-34.

The only reference I got was after the 11:57:08 timestamp and it was:

2009-02-07 11:57:08 40 of 48 (83%)
62A0 G 30B Smartzone PeerInfo, SysId=6F10, DChan=2A0 867.8125

Thank you Mike. The good news is it appears to be decoding correctly but not properly applying the decoded information to the site / system data. This is a much easier problem to fix.

-rick

 

[mtindor]

Thank you Mike. The good news is it appears to be decoding correctly but not properly applying the decoded information to the site / system data. This is a much easier problem to fix.

-rick

That's what I like to hear. You know where to find me if you need me to test any fix down the road. I appreciate your willingness to accept my input man. Take it easy.

mike