TrunkSniffer feedback

[Mike_P]

Hi all,

I just wanted to know if there is interest in TrunkSniffer, I have quite a few new features in mind, but I'm not sure if it will be worth doing - so far, many downloads, but almost zero feedback. I really don't know if the software is working out for people, if it's too complicated, problems, features you'd like to see? Any kind of feedback is appreciated, be it positive or negative.

Some of the features I'm thinking of are:

- Automatic gathering of all networks with their TSCs on a given frequency range (kindof an "extra" hunt), and profile generation.
- Automatic network profile generation, with identification of channel structure, etc.
- Recording of audio in dual-receiver mode, via stereo recording (one channel for the TSC, the other to record audio).
- Dual-TSC monitoring, or TSC forward and reverse channels, using stereo recording.
- A PocketPC version (the newer iPAQs have microphone input!).

Let me know what you think, best regards,

Mike
www.trunksniffer.com

 

[morfis]

Mike,

Automatic hunting of TSCs and profile generation (with a format suitable for export to spreadsheet or similar) are very worthwhile.
iPaq version...dunno, not using one. Is that a major programming change or just a case of compiling differently?

 

[Kasmus]

I downloaded your evaluation version and I'm impressed!
I've got a couple of questions now:

Is it correct that the network preferences cannot be edited while tracking is in progress? Would be great, if I could edit the newly aquired CC names without having to stop tracking...

What do the toolbar buttons do if I just click them and do not use the drop-down next to it?

Is it possible to name individual units?


Kasmus

 

[Mike_P]

Hi Kasmus,

Thanks for the feedbak

To answer your questions:

Is it correct that the network preferences cannot be edited while tracking is in progress?

Yes, they cannot be edited - however, I could add a tool button to rename the currently tracked TSC. Editing the network profile while tracking could mess up a few settins, I'll see if I can "protect" it somehow, and allow editing while tracking instead of the rename tool.

What do the toolbar buttons do if I just click them and do not use the drop-down next to it?

Nothing Basically they are icons to be more visually-appealing, and easy to interpret. If popular demand is high, I could change them to text buttons. This was a discussion we had with beta-testers, but feelings were mixed, so we thought we'd leave the icons unless people complained.

Is it possible to name individual units?

Yes. Until individual unit naming is implemented (work in progress), you can create a fleet definition with just one RU in it. Give it the name you want, enter the unit's Ident in the IBI field, number of units 1, and GBI and number of groups to 0000 and 0. This will create the fleet for just that one unit (sometimes useful for filtering out traffic from one particular ident).

Regards,

Mike
www.trunksniffer.com

 

[Kasmus]

Hi Mike.

An option for renaming TSCs on-the-fly would be great indeed.

IMHO you should not change the icons to text-options. Try to make the button itself pop up the menues instead. Since I quit playing Quake a long time ago my aiming is quite bad and I'm getting tired having to hit the small pop-up arrows...

Another thing I'd like to see in future versions (when an individual RU database is implemented) is auto-tracking of a certain fleet or even single RUs.

Since the needed audio input is mono only, you could use one channel for each receiver and provide decoding of a CC and the currently tuned TC (call maintenance, pressel, return to CC, etc.) at the same time.
The monitoring of the TC in use would require a second text-output window, though.

A last word on grafics:
I really like your idea of (fake) metal dials and dot-matrix VFDs.
But i certainly would not immediately connect three colorful cubes to a TSC.
What does the icon of the tracking toggle button symbolize?!
Another thing that bothers me is the design of the OK/Cancel buttons. They just do not fit into the plain black background. Maybe you should use a background image that integrates the buttons nicely & smooth...


Kasmus

 

[Mike_P]

Hi Kasmus,

Thanks for your ideas!

Try to make the button itself pop up the menues instead

Done!

Another thing I'd like to see in future versions (when an individual RU database is implemented) is auto-tracking of a certain fleet or even single RUs.

You can track individual fleets or RUs (with the method before described), by checking off the Filter marks to the fleets you don't want to track. Then, in the Fleets menu, check "Filter GTCs" - this will prevent any GTCs not directed to fleets with the filter checked from being followed. However, traffic directed to other fleets will still be seen, and can be sepparately turned off by also checking "Filter codewords". With both checked, only traffic and GTCs to the fleets passing the filter will be shown.

Since the needed audio input is mono only, you could use one channel for each receiver and provide decoding of a CC and the currently tuned TC (call maintenance, pressel, return to CC, etc.) at the same time.

Yes, this is the general idea, to feed audio from each scanner into the left and right channels of the soundcard, and have sepparate decoding threads, or one decoding the TSC and the other recording call audio to disk. Work in progress

But i certainly would not immediately connect three colorful cubes to a TSC

It's a BeOS network controller icon. Maybe too computer nerd-ish. Will look for a better one - seemed good at the time.

What does the icon of the tracking toggle button symbolize?!

It's a power plug. Again, I will replace it when I find a better icon.

Another thing that bothers me is the design of the OK/Cancel buttons.

Yes, that is one thing that I don't really like how it came out, and it's on the list for changing once suitable graphics are made. Probably will make a gray button with a smaller graphic and text.

Best regards, keep'em coming!

Mike
www.trunksniffer.com

 

[Kasmus]

Another thing I'd like to see in future versions (when an individual RU database is implemented) is auto-tracking of a certain fleet or even single RUs.

You can track individual fleets or RUs (with the method before described), by checking off the Filter marks to the fleets you don't want to track. Then, in the Fleets menu, check "Filter GTCs" - this will prevent any GTCs not directed to fleets with the filter checked from being followed. However, traffic directed to other fleets will still be seen, and can be sepparately turned off by also checking "Filter codewords". With both checked, only traffic and GTCs to the fleets passing the filter will be shown.

So the TC Receiver actually is automatically tuned to the channel included in each displayed GTC message? I thought I had to tune it manually by clicking the TC list. (I do not currently have a RC receiver handy for testing)

But i certainly would not immediately connect three colorful cubes to a TSC

It's a BeOS network controller icon. Maybe too computer nerd-ish. Will look for a better one - seemed good at the time.

Well I must confess I have never seen BeOS in action. How about a NeXT network icon? (see attachment) That would be kinda nerdish as well but one could actually identify it as a network icon...

What does the icon of the tracking toggle button symbolize?!

It's a power plug. Again, I will replace it when I find a better icon.

How about a lightning? Or simply a play button like on a music player?


Another issue that bothers me: On the download page it says the demo would run for 40 minutes before shutting itself down.
IMHO it quits much earlier.


Cheers,
Kasmus

 

[Kasmus]

...and yet another question:

Does TrunkSniffer actually decode the call maintenance and clear down messages used on traffic channels?
I tracked the TSC my radios are registered with, set up a voice call and got a traffic channel assigned. I then tuned the scanner to that frequency and TrunkSniffer (of course) kept saying "No FSK". It did not decode any pressel, maintenance or clear down messages, though.

The "Lock autoscroll" checkbox does not seem to lock the automatic scrolling, it just slows down a bit, BTW.


Cheers,
Kasmus

 

[Mike_P]

Hi Kasmus,

I'll condense the two replies into one,

So the TC Receiver actually is automatically tuned to the channel included in each displayed GTC message?

Yes - you have to check (enable) the TSC menu -> Dynamic tracking -> Voice GTCs and/or Data GTCs. With these checked, TrunkSniffer will automatically tune the call's traffic channel.

If you are using the single-receiver mode, the call's audio is buffered and passed through the decoder, so any in-call signalling will also be decoded (for example, presence checks, pressel on/off, end of channel use and clear down messages). If you let TrunkSniffer do the tuning, when it decodes the clear down messages it re-tunes the control channel automatically and carries on tracking.

In dual-receiver mode, the call's end is found by either the busy signal from the receiver going low, or when the call timeout expires. In this case, the control channel is continuously tracked, so the second (traffic) receiver is "parked" on a quiet frequency until the next call. You can also check in the above menu Wait for call end, which will prevent following GTCs that arrive while the traffic receiver is in a call - in busy systems, your traffic receiver would be bouncing to new GTCs every few seconds, which is not good.

Another issue that bothers me: On the download page it says the demo would run for 40 minutes before shutting itself down.
IMHO it quits much earlier.

How much earlies? Could you time it somehow? In theory, a simple time adding function is used, so it shouldn't be a problem. I will look into it anyway, just in case.

The "Lock autoscroll" checkbox does not seem to lock the automatic scrolling, it just slows down a bit, BTW.

The Lock autoscroll is meant to enable you to move through the decoder window without it jumping to new entries as they are received. What you are seeing is probably the effect of removing old entries as new ones arrive - this is done to avoid hogging a lot of RAM. All that happens is that the first line is removed, and the new one added at the end - but the window should not scroll to this last entry if you have the box checked, and are looking at an older entry.

Best regards,

Mike

 

[Kasmus]

Yes - you have to check (enable) the TSC menu -> Dynamic tracking -> Voice GTCs and/or Data GTCs.

Allright, I missed that one.

If you are using the single-receiver mode, the call's audio is buffered and passed through the decoder, so any in-call signalling will also be decoded (for example, presence checks, pressel on/off, end of channel use and clear down messages). If you let TrunkSniffer do the tuning, when it decodes the clear down messages it re-tunes the control channel automatically and carries on tracking.

So when I'm using only one receiver, TrunkSniffer listens into the CC and on GTC it switches to the corresponding TC. On clear down it re-tunes to the CC. Isn't that what I did manually? Why didn't I get the in-call signalling text output? Is it only beeing decoded for internal use and not displayed?

How much earlies? Could you time it somehow?

I will use my stop watch and let you know.

What you are seeing is probably the effect of removing old entries as new ones arrive - this is done to avoid hogging a lot of RAM.

Argh, you are right - I could have figured this one out myself.
But as I (and heaps of other people) got 1gig of RAM an option to change the number of buffered lines would be useful.


Cheers,
Kasmus

 

[Mike_P]

Hi Kasmus,

So when I'm using only one receiver, TrunkSniffer listens into the CC and on GTC it switches to the corresponding TC. On clear down it re-tunes to the CC. Isn't that what I did manually? Why didn't I get the in-call signalling text output? Is it only beeing decoded for internal use and not displayed?

What happens when Dynamic tracking is enabled is that when a GTC is followed, TrunkSniffer sets a special flag that tells it it's actually in a traffic call. This flag is reset when it returns to the CC, be it because the call ends, or you manually make it return.

If instead you manually tune a traffic channel by clicking the channel number, TrunkSniffer makes no assumption that you are actually following a GTC, and does not set the "in traffic" flag - you could in fact manually tune any channel, be it in a GTC or not. Thus, manual tuning will not have TrunkSniffer decode what goes on in that traffic channel, or treat it as if it were a GTC. Maybe this could be added as an option in the future.

Regards,

Mike

 

[Kasmus]

Maybe this could be added as an option in the future.

What issues do you expect from being ready to decode CC & TC signalling at the same time = all the time)?


Cheers,
Kasmus

 

[Mike_P]

Hi Kasmus,

Decoding both channels simultaneously will be implemented, but first I want to see what the response to the software is. No point in spending a few more hundred hours if nobody is going to end up keeping it

The features I plan for the next release, pending popular response, are:

- Simultaneous decoding of both the TSC, and either a second TSC, or the traffic channel signalling.
- Comprehensive hunt of all TSCs, grouped by network ID, between two arbitrary frequencies (this would let you generate all the network profiles in one go).
- Support for more receivers: Icom CI-V, WinRadio, VR5000, and Yaesu rigs that support remote control.
- Upload all the traffic channels under one TSC into memories of the receiver, for independant scanning of that TSC (for example, program an AR8200 with the traffic channels, and take it away with you).
- Only track GTCs to known good traffic channels.
- Allow creation of arbitrary network profiles, specifying each logical channel and it's corresponding frequency, for those "odd" networks.
- Statistics and reports about traffic activity per channel, fleet, etc.
- Using the traffic receiver to scan the traffic channels repeatedly, to show channel occupation in real-time.

And many others...

Best regards,

Mike

 

[Kasmus]

Hi again.

My demo version runs approximately 20 or sometimes about 25 minutes before it quits.

Are you aware that the "Bad codewords" ratio in the status bar sometimes raises above 100%?


Cheers,
Kasmus

 

[Mike_P]

Hi Kasmus,

The time should be longer than that, I will look into it. Regarding the codeword error %, I must have slipped the upper-bound limit - will be fixed in the next release.

Regards,

Mike
www.trunksniffer.com

 

[Kasmus]

Another thing I do not quite understand:

When you operate in single receiver mode (you have selected the CC receiver as 'DUMMY' that is) and a GTC on the CC is received, TrunkSniffer is tuning the (only) receiver to the corresponding traffic channel and - as you said - after reception of a clear down, it retunes to the control channel again.
The optimum solution IMHO.

BUT: If you are operating in dual receiver mode (both, CC & TC receiver selected and COM ports specified or you even are using just a non-RC receiver for CC) and a GTC is decoded, TrunkSniffer of course changes to the TC but switches to in-call signalling as well. As only the audio from the CC receiver is decoded and therefore TrunkSniffer cannot analyze the TC data, how would you automatically tell the call is over? So you have to click the "TSC" LED-button to return to CC signalling mode. As long as you do not yet have implemented synchronous split-channel decoding, you should let TrunkSniffer simply stay in CC signalling mode, as user interaction for end-of-call recognition is needed anyway.

It might be that my theory is terribly wrong, as I do not have two RC scanners for testing. And please do not misunderstand me: TrunkSniffer is the far most comfortably piece of software for decoding MPT1327 but there also is a lot of space for improvements - I only want to help you (+the community) to make it even better...


Cheers,
Kasmus

 

[Mike_P]

Hi Kasmus,

In dual-receiver mode, TrunkSniffer uses the busy channel indication from the receiver in order to guess when the call ends - thus, you have to adjust the squelch on the scanner appropriately. If the busy signal stays on because the squelch remains open, the receiver will be tuned to the quiet frequency when the call timer expires.

Obviously, it would be better to have signalling control over both scanners, and this is what I am working on

Regards, and thanks for your comments,

Mike
www.trunksniffer.com

 

[toontje]

Would like to evaluate but it's impossible.

Hi Mike!

I would like to evaluate TrunkSniffer, but you know my situation with the failed setup and such. I mailed you a couple of times about this.

Please respond. Can you help me?

Thanks,

Ton.