Trunker odd behaviour

[DaveH]

While trying to log the Clinton Cty. NY 800MHz system 3A34, Trunker M Tr3.8.3 beta ec1 (Eric Cottrell's VHF/UHF version) did not seem to be able to display or log the control channel! It was obviously decoding, displaying the SysID, connect tone etc, and voice channels as they came up, but not the CC. The system file did not get saved, when the "save" keystroke was executed (as a result, there is no "evidence").

The regular Trunker m3.8.3 had a similar problem. At one point it started spitting out raw hex channel numbers instead of 800MHz frequencies.

I am not up to date with all the ramifications of re-banding, but is it possible this system is re-banded, and Trunker is getting confused?

Dave

 

[SCPD]

Rebanding should not effect the program. The worst thing that could happen from rebanding is the program displays the wrong frequency for a given channel number.

What is the signal quality reported by trunker?

Also, try running "dumper" to dump raw control channel activity and see what comes out of the log. ( This program should have been included with either version of Trunker. ) This may report "Unknown single OSW" or similar message indicating something funky on the control channel. Please post your findings here or on the trunker Yahoo! Groups mailing list.

Also, if you have the opportunity, please run UniTrunker against this system. I'd like to hear how well it handles whatever might be different on this system.

-rick

 

[DaveH]

The signal quality varied because I normally can't receive this system, except during enhanced conditions (ducting). The SS was strong enough at one point to decode VCs so I don't think weak signal could account for any of this (normally you'd would just not get a SysID decode, although the first thing to pop up is the Connect Tone).

The VC frequencies looked OK in the case they were displayed. Things happened fast so I didn't get a change to do much else (plus had to leave for work).

There might be something else odd with this system because I'm sure I've picked it up before, but can't find any Trunker records saved. I had the same problem recently. It must require a CC to save the system file. I'd have to drive a hour S/E to receive 3A32; may do that in the next month or so, but would probably run Treport.

I ran T4Win in its earlier phases but it stopped working at some point. I'm running Win98 and had to install a dll (which you pointed to at the time) to make it work. I've seen discussion about UniTrunker but not followed closely. Perhaps I could get it set up, although not immediately, and at least try it on local systems (there's lots, from Moto Type I, II, IIi, VHF, UHF, EDACS).

Dave

 

[SCPD]

The signal quality varied because I normally can't receive this system, except during enhanced conditions (ducting). The SS was strong enough at one point to decode VCs so I don't think weak signal could account for any of this (normally you'd would just not get a SysID decode, although the first thing to pop up is the Connect Tone).

I think this does affect the program's decision of whether to commit the data received. Under poor conditions - like those just described - the program does not "trust" the data received. Imagine tracking a distant system at a low decode rate - but enough to see activity - when the signal from some other system briefly overpowers the first. The events received just before a new system was ID'd - those events cannot be trusted as to which system they came. The program avoids mixing data from two different systems by discarding this recent data. Under very poor signal conditions, the program is struggling to determine what to save and what to throw away. I'm afraid you're just to far away from this particular system. If you hit a strong - and sustained - period of ducting then you might be lucky enough to come away with some usable data.

The other rusty edge to this blade is the problem with completely random noise passing as a valid frame of data. This will confuse most programs - including Trunker. BTW, there are for me some distant EDACS systems that fade in and out of reception - so I understand your situation.

There might be something else odd with this system because I'm sure I've picked it up before, but can't find any Trunker records saved. I had the same problem recently. It must require a CC to save the system file. I'd have to drive a hour S/E to receive 3A32; may do that in the next month or so, but would probably run Treport.

I think you've got it. Please let us know if Treport squawks at anything unusual.

I ran T4Win in its earlier phases but it stopped working at some point. I'm running Win98 and had to install a dll (which you pointed to at the time) to make it work. I've seen discussion about UniTrunker but not followed closely. Perhaps I could get it set up, although not immediately, and at least try it on local systems (there's lots, from Moto Type I, II, IIi, VHF, UHF, EDACS).

UniTrunker is must simpler - plain text files. There have been reports of the program not running on Windows 95 but Win98 should be okay. Included in the bundle is a program called "Packets". This program works much like "Dumper" which is a cousin to Trunker. The differences are (1) it does multiple protocols in one program and (2) it will display and format as much data as possible - including bad data (marked as such). This is useful for those situations where MOST of the bits are correct and you want to see what the best guess is for interpreting the garbled data. This is completely useless for programs like Trunker or Uni-Trunker, which need to impose a high level of integrity to the data displayed. However, for situations like the one you just described, this can be useful to dig out "over the horizon" signals. There will often be enough valid data that a human reader can parse through and pick out useful information.

Look for a new UniTrunker release this weekend.

-rick