Wishlist for channel monitoring

[Wowbagger]

OK, time to do a bit of market research:

Assume you had a box which could monitor an APCO-25 system and record information about what it saw to a database.

What would YOU want to see recorded?

Here are some examples to get you started:

Control channels seen.
Adjacent control channels seen.
Secondary control channels seen.
Traffic channel assignments seen.
Mobiles seen.
Groups seen.

What else would you want to see? What don't you care to see?

[Rayjk110]

How often which group gets used the most, for how long, and during what times of day would be cool. I suppose it could then log that same information per/radio, too.

[Hightower]

Radio ID aliasing.

[Wowbagger]

Radio ID aliasing.

Please elaborate.

[Twisted_Pear]

Everything, and then an option to turn whichever event on or off.

[Hightower]

Radio ID aliasing.

Please elaborate.

In conventonal P-25, if you transmit a digital ID of 50, using the Astro call list, it aliases ID 50 to what ever I want it to display. So when radio with ID 50 transmits, it displays "Dispatch" or whatever I want ID 50 to show. Does that make sense?

Or for P-25 trunked systems, a radio with the ID of lets say 715265 keys up, the radio can be programmed to alias 7152665 to show "Trooper Jones".

After re-reading your original post, I now realize your system is ment to record and forward that info to a database. It would be neat however to have a small box that you could decode radio ID's and have ththose IDs aliased to information the "P-25 box" owner adds to it.

[Wowbagger]

In conventonal P-25, if you transmit a digital ID of 50, using the Astro call list, it aliases ID 50 to what ever I want it to display. So when radio with ID 50 transmits, it displays "Dispatch" or whatever I want ID 50 to show. Does that make sense?

That information is not available over the air - that is set by the programming of the radio. I wouldn't have that information by monitoring the control channel.

Everything, and then an option to turn whichever event on or off.

That's not really helpful - "everything" doesn't give me anything I can design for, it's the sort of answer I'd expect from a marketing/sales guy.

I really want specifics - preferably in the form of "I'd like $FOO, so that I can do $BAR". The more specific the use case you give me, the better I can insure the design matches this.



Folks, this isn't for some garage project: I'm asking this in my capacity as one of the principal software engineers at Aeroflex - you know, the folks who make the current reference standard test equipment for APCO-25? What you give me will be used to write the specs for an optional feature for one of our service monitors. You've found the lamp and been given a chance to make a wish - use it wisely.

[RKG]

Patches set and released.

[Batwings21]

Site / wide area status for a site.

[Wowbagger]

Patches set and released.

Again, please elaborate.

[alex]

What I believe Hightower is getting at is it's great to see ID 123456 - but the ability to have the users be able to drop an alias in there to say 123436 - Alex instead is more what I think he's getting at. Or when console X does Y, it says NORTH DISPATCH kinda thing. Just something to aid people so that they don't have to remember every single ID on the system, and what it translates back to.

I would assume most of the admins out there know the ID's and configurations of their systems pretty well, but I'd imagine with a huge network, it would be impossible to do all the lookups/cross references in ones head...

-Alex

[Wowbagger]

What I believe Hightower is getting at is it's great to see ID 123456 - but the ability to have the users be able to drop an alias in there to say 123436 - Alex instead is more what I think he's getting at. Or when console X does Y, it says NORTH DISPATCH kinda thing. Just something to aid people so that they don't have to remember every single ID on the system, and what it translates back to.

I would assume most of the admins out there know the ID's and configurations of their systems pretty well, but I'd imagine with a huge network, it would be impossible to do all the lookups/cross references in ones head...

-Alex

And as I said, that information is not available over the air - it would have to be entered by some means other than snooping the control channel.

[N4DES]

Everything that these guys have :

http://www.genesisworld.com/NV/

[Wowbagger]

Everything that these guys have :

http://www.genesisworld.com/NV/

That, at least, is a starting point - however, they are watching the backhaul from the base radios and site controllers to the system controllers.

What I am describing will be watching the outbound control channel *over the air* - so anything that ISN'T transmitted over the air won't be available.

[tvsjr]

What I believe Hightower is getting at is it's great to see ID 123456 - but the ability to have the users be able to drop an alias in there to say 123436 - Alex instead is more what I think he's getting at. Or when console X does Y, it says NORTH DISPATCH kinda thing. Just something to aid people so that they don't have to remember every single ID on the system, and what it translates back to.

I would assume most of the admins out there know the ID's and configurations of their systems pretty well, but I'd imagine with a huge network, it would be impossible to do all the lookups/cross references in ones head...

-Alex

And as I said, that information is not available over the air - it would have to be entered by some means other than snooping the control channel.

I think the idea is to have an alias list in the service monitor, preferably that can be updated via computer. That way, if you're a big system administrator, you can dump your site ID/talkgroup ID/system ID/individual ID database into the monitor, and it would do the aliasing in the same way a properly-configured XTS5000 would.

[Wowbagger]

I think the idea is to have an alias list in the service monitor, preferably that can be updated via computer. That way, if you're a big system administrator, you can dump your site ID/talkgroup ID/system ID/individual ID database into the monitor, and it would do the aliasing in the same way a properly-configured XTS5000 would.

The data we capture would be made available via ODBC to an external program - so any such matching would be done by the external program.

[tvsjr]

I think the idea is to have an alias list in the service monitor, preferably that can be updated via computer. That way, if you're a big system administrator, you can dump your site ID/talkgroup ID/system ID/individual ID database into the monitor, and it would do the aliasing in the same way a properly-configured XTS5000 would.

The data we capture would be made available via ODBC to an external program - so any such matching would be done by the external program.

I guess it depends on how this program will work... are you planning to allow capture and analysis of the datastream on the front panel, or is this application simply going to capture raw data and make it available for the end user to do whatever post-processing he desires? Is this going to be something like Trunker on steroids, or merely a capture tool?

I'd surmise that more information about what the application will actually do, how it will interact with the monitor, etc. would be helpful.

[alex]

With what Terry is saying, something like a simple low level protocol which breaks down the packets to show you the actual data flowing across the network - much like ethereal, may be worth doing.

That way - you could go through and filter out or otherwise specify what packets you want to collect, inspect, etc.

-Alex

[Astro Spectra]

Definitely want a log file feature able to record the raw TSBK octets. The recording facility should have a flexible trigger capability to start, end or centre the capture on any combination of bits in the block. I'm thinking along the lines of a hardware logic analyser trigger, see:

http://www.home.agilent.com/upload/cmc_ ... V4I3A5.pdf

Similarly for conventional and packet data. Would be useful to debug ARS and location/LRRP issues.

The database needs to be able to export to Access and Excel.

With test equipment I don't think it’s always possible to think of everything someone might want to do, it's better to give them a rich set of tools that can be built on.

[Wowbagger]

There are some limits on what I can go into with outsiders at this point in the design, so bear with me on that.

We already have a very detailed logging to XML of the physical transport layer, logging both raw symbols as well as broken-out protocol information. These logs can then be accessed and post-processed using standard XML tools (and we have both a DTD and a RelaxNG schema available for them, so that the files can be validated against them.)

However, looking at even a couple of minutes of log data can generate some pretty large files.

What I'm asking about is a separate entity from that logging - it's more of the idea of "I don't know much about this system - go scan it, and give me a report on what you find." By storing it in a database, you don't have to go sifting through gigabytes of XML to find out what mobile IDs were seen during the time, as it would already have been entered into the database and would be a simple SQL query away.

So the question is, what data goes into the database? *Everything* goes into the XML log, but what should be in the database?

More importantly, what sorts of queries and reports should it be possible to generate from that database?

As for questions of what level of user interface would be on the instrument, and what level would be provided by external equipment (i.e. a computer) - well, that to some extent depends upon what's useful. Just remember that the size of screen (both physical and logical), the number of keys, the availability of a pointing device, etc. are all much smaller on a service monitor than on a laptop, so trying to have too complex a program on the instrument wouldn't be as useful as you might think.

I guess you can phrase what I'm asking like this:

What sorts of information do you need to accumulate in the field?
What sorts of information do you want to analyze "back home"?
What sorts of questions do you need answered in the field?
What sorts of questions do you want to be able to answer "back home"?

and the biggie:

How much are those answers worth to you?

[Twisted_Pear]

That's not really helpful - "everything" doesn't give me anything I can design for, it's the sort of answer I'd expect from a marketing/sales guy.

I really want specifics - preferably in the form of "I'd like $FOO, so that I can do $BAR". The more specific the use case you give me, the better I can insure the design matches this.

Well your question is rather vague since you obviously have limits or a desired specific purpose for the tool. What exactly are your limits? Is this to diagnose system problems? Monitor calls? If troubleshooting you want access to all the information. There's a ton of useful stuff there for a technician. Is this for call monitoring/statistical generation or....?

[Wowbagger]

Well your question is rather vague since you obviously have limits or a desired specific purpose for the tool. What exactly are your limits? Is this to diagnose system problems? Monitor calls? If troubleshooting you want access to all the information. There's a ton of useful stuff there for a technician. Is this for call monitoring/statistical generation or....?

Now, that is a very good question, and that's exactly the sort of thing I need: Use cases.

Why don't YOU give me your use cases: what sorts of things can you imagine doing? If you have experience in those categories, give me examples of the sorts of things you did: i.e.

diagnose system problems:
I've had to track down problem $FOO, and if I could have accumulated information $BAR, $BAZ, and $NARF and done $POIT on it, I could have tracked this down instantly.

statistical generation:
I'd like to gather $INFORMATION about my running system, over $TIMESCALE, and then generate $REPORTS from it - here's an example report I'd like to generate.

[AEC]

I'd opt for Channel Steering, for Fleets, subfleets and groups with individual IDs and fleet IDs and things of that nature.

Possibly even failure tones that indicate a failsoft condition with channel steering in this condition as well.

Two cents sure doesn't go very far these days...DOH!