HP-1 EE / LCN Finder

[b52hbuff]

I wanted to start a thread about the LCN finder. I took my HP-1EE to the local sports arena (Oakland Coliseum) to try and map out an LTR used by the facility. The last time I tried mapping out an LTR system, I used one of the techniques here:
Mapping an LTR System - The RadioReference Wiki

Anyway, I have some questions and concerns about how the feature works.

What data is used to determine LTR LCN order? From the articles, 'home' channels are easy to find. How are 'goto' channels determined?

Is there anyway to save a system where not all of the LCN's have been determined?

In the example in the users guide, there is a SAVE dialog that pops up once all LCNs have been determined. During the analysis phase, there are soft keys for 'End' and 'Save'. The 'Save' is always greyed out.

Consider a case where you are trying to determine the LCN order of a system where you are unsure of all of the frequencies. The LCN finder will never finish. So it would be useful to save the current work in progress. Without a save, you have to manually write down all of the LCNs found up to that point…

Would it be possible to allow a save before all LCNs are found? Ideally, it would save all of the found LCNs and mark the other LCNs in some way that would let you know they were never found.

Another request is to simplify modification of an LTR system. Consider a mythical system with three frequencies:
LCN 1: 460.100
LCN 2: 460.200
LCN 3:460.300

But you have them programmed reverse in the radio as:
LCN 1:460.300
LCN 2:460.200
LCN 3:460.100

In the edit site menu, all you see is:
460.3000
460.2000
460.1000
...they are not necessarily in LCN order. They are in the order in which they were programmed. So you press the '460.3000' button. Press the 'next' to get to the LCN entry. It shows a 1. You try and enter a 3, and it tells you that there is a duplicate LCN.

I know LCN's can't be duplicated. But since I can't duplicate during data entry. And since I can't see the LCN's from the entry screen, there is no way to know what order to edit the system to get the LCN's right.

When I was trying to do this in the field, I gave up and just created a new system from scratch. It worked for what I was doing. But it would have been less desirable, if I had a large number of TGIDs I wanted to save from the original system...

 

[JASII]

I am interested in this as well.

 

[DaveIN]

What data is used to determine LTR LCN order?

I believe the data burst from the home channel reporting.

How are 'goto' channels determined?

They are not in the LCN discover mode. The goto channel is used during the TrunkTracking mode.

Is there anyway to save a system where not all of the LCN's have been determined?

No, only when you have all the LCN's which means you may be missing some frequencies. You could do a conventional discovery mode with search limits to see if you find repeater outputs in a pattern. Maybe a missing LTR frequency will show up.

In the example in the users guide, there is a SAVE dialog that pops up once all LCNs have been determined. During the analysis phase, there are soft keys for 'End' and 'Save'. The 'Save' is always greyed out.

Because that was when it was screen captured. Maybe you should try running a LCN find on a known complete system to see if all LCN's are found.

Consider a case where you are trying to determine the LCN order of a system where you are unsure of all of the frequencies. The LCN finder will never finish. So it would be useful to save the current work in progress. Without a save, you have to manually write down all of the LCNs found up to that point…

That's a good point, but you could just set them correctly in Sentinel or send the correct LCN data to the database admin.

Would it be possible to allow a save before all LCNs are found? Ideally, it would save all of the found LCNs and mark the other LCNs in some way that would let you know they were never found.

There is no provision for saving the current data before the LCN search is complete with just the channels provided. there must be additional data that suggests an additional LCN that is missing.

<Snip>...they are not necessarily in LCN order. They are in the order in which they were programmed. So you press the '460.3000' button. Press the 'next' to get to the LCN entry. It shows a 1. You try and enter a 3, and it tells you that there is a duplicate LCN.

I know LCN's can't be duplicated. But since I can't duplicate during data entry. And since I can't see the LCN's from the entry screen, there is no way to know what order to edit the system to get the LCN's right.

I think that was a programmers idea. This is carred over in the EDACS LCN programming as well. Maybe to prevent a software/firmware crash when two LCN's are identified as the same channel. This method appears to be the same all the way back to the BC246T. Not saying it's not a pain, but it's consistent.

When I was trying to do this in the field, I gave up and just created a new system from scratch. It worked for what I was doing. But it would have been less desirable, if I had a large number of TGIDs I wanted to save from the original system...

Did it complete the LCN find and allow you to save the system when you created the system yourself?

 

[b52hbuff]

I believe the data burst from the home channel reporting.

If this is true, then (correct me if I'm wrong), the LTR Finder doesn't add much over the LTR functionality in the older GRE radios (e.g. Pro-92/96). In those radios, you didn't need to provide LCN order. So it was easy to find the Home channels, but much harder to find the goto channels.

I don't think this is actually the case, because I've seen the Event Monitor show decodes of the OSWs. But I'm still learning on this one. Thanks for helping.

No, only when you have all the LCN's which means you may be missing some frequencies. You could do a conventional discovery mode with search limits to see if you find repeater outputs in a pattern. Maybe a missing LTR frequency will show up.

You have a mighty fine question. What conditions cause the LCN Finder to think that it has found all of the LCNs and it can stop looking? Clearly in my case, I had some 'extra' frequencies that never came active in the list.

But what about the other case, where there is a missing frequency? I just happen to have discovered a new LTR system in my area that my HP-1 claims to have found all of the LCNs. Maybe I'll try one of the runs again with a known frequency missing and see if the search still terminates...

Because that was when it was screen captured. Maybe you should try running a LCN find on a known complete system to see if all LCN's are found.

Yup, that's what I'm trying. Ironically, working a known system in my area has discovered that these systems have changed. Hopefully some of the local expertise will direct me to a particularly 'challenging' LTR system so we can see how good Uniden's discovery algorithm really is.

That's a good point, but you could just set them correctly in Sentinel or send the correct LCN data to the database admin.

You are correct, that is always an option when you have time and space to do. I often find myself 'out in the field' where this isn't an option. In my first outing with LCN Finder, I was in a sports stadium, sitting in the stands. The more the radio allows me to do and store on the radio, the better it is 'out in the field'.

 

[DaveIN]

If this is true, then (correct me if I'm wrong), the LTR Finder doesn't add much over the LTR functionality in the older GRE radios (e.g. Pro-92/96). In those radios, you didn't need to provide LCN order. So it was easy to find the Home channels, but much harder to find the goto channels.

I don't think this is actually the case, because I've seen the Event Monitor show decodes of the OSWs. But I'm still learning on this one. Thanks for helping.

Well, the Pro-92 (and Pro-2053), which was a great advancement at the time, was a little buggy on Regular LTR. In Open or Closed mode you hear the data burst from the home channel and would cause it to, miss some of the conversations at times. As I recall the problem was addressed somewhat on the A and B updated model, but was not the LTR tracking we have today. The Pro-96 did not include LTR tracking. The Pro-97 has a home repeater finder, as does the PSR-300/400. When you advance to the next tier, the PSR-310/500/410/600 (and Radio Shack equivalents), the auto-repeater ordering feature was a great addition. I like the LTR (and EDACS) LCN graphical display as it does the search algorithm and it also helps you identify when you don't have all the system frequencies with a possible pattern that you can't see on the GRE models.
The LTR data output should show the home channels, Goto channels, as well as the TGID's, using the activity log and current activity display on the HPE.

You have a mighty fine question. What conditions cause the LCN Finder to think that it has found all of the LCNs and it can stop looking? Clearly in my case, I had some 'extra' frequencies that never came active in the list.

I would say that the data burst would trigger for each home channel in turn. Then, when all the frequencies in the system list have been identified for their home channel it would let you save the order unless one of the home channels is still unidentified, causing the HPE to continue to keep looking until complete. I wonder if the LTR system has some noise on the data burst creating an error, or an unassigned LCN causing the finder not to complete the search.

But what about the other case, where there is a missing frequency? I just happen to have discovered a new LTR system in my area that my HP-1 claims to have found all of the LCNs. Maybe I'll try one of the runs again with a known frequency missing and see if the search still terminates...

That would be a good test. Let us know how that turns out.

You are correct, that is always an option when you have time and space to do. I often find myself 'out in the field' where this isn't an option. In my first outing with LCN Finder, I was in a sports stadium, sitting in the stands. The more the radio allows me to do and store on the radio, the better it is 'out in the field'.

I see. The HP is not really too portable in that respect, but I guess if Scannermaster can make a Hamsexy pouch for the belt, it must be.

 

[KE4ZNR]

For those with a 396XT/996XT/BCT15X along with an HP-1 one option
to help you make sure you are on the right track is to use Eric Carlson's
LTRLogger program. I know, it is not the most portable option but it does
help corroborate what the HP-1 sees as far as an LTR system.
I have used it with the HP-1 to map out a couple of 400Mhz LTR systems in the
area.
Just tossing out another way to verify info
Happy Monitoring
Marshall KE4ZNR

 

[b52hbuff]

Just tossing out another way to verify info
Happy Monitoring
Marshall KE4ZNR

Thanks Marshall. My first question is to figure out just how reliable the hardware and algorithms are in the HP-1. If the Analyze and/or Event monitor are robust enough to identify a system autonomously or provide enough information manually, then why not stick with the Uniden solution?

I saw on the Homepatrol forum you posted some experience with LCN Finder. Have you developed enough history with the feature to feel comfortable with the data it provides?

 

[KE4ZNR]

Thanks Marshall. My first question is to figure out just how reliable the hardware and algorithms are in the HP-1. If the Analyze and/or Event monitor are robust enough to identify a system autonomously or provide enough information manually, then why not stick with the Uniden solution?

I saw on the Homepatrol forum you posted some experience with LCN Finder. Have you developed enough history with the feature to feel comfortable with the data it provides?

My experience that I shared here and on the Uniden HP forums had to deal with
a local EDACS system that the LCN finder helped me map out the LCNs on.
Which, as we all know, mapping out an EDACS LCN order is different than an LTR LCN order.
I have had extensive experience using the LCN finder on both LTR and EDACS systems
and trust it.
My post was more along the lines of run both the HP-1 LCN finder and Eric's LTRLogger
and you will see that both agree on LTR LCNs which should back up the reliability of the HP-1's findings.
I know I probably did not make that entirely clear in my initial post and my apologies for having to explain it.
I know it can be frustrating to have almost all of the LCNs mapped out but one and have to wait for that final LCN # to drop in place but this is where I go real old fashioned when I am doing radio system sleuthing when out and about: I take a notebook and write down what the HP-1 is seeing for my reference. I write down what has been figured out so far and what is still a mystery. That way once I get home I can look over my notes to make sure I have accurate info.
Granted my way is "old school" but it gets the job done
Happy Monitoring
Marshall KE4ZNR

 

[DaveIN]

I have an interesting, but frustrating new LTR system I'm trying to discover with multiple methods. The HP-E is working great for the problem however. I have one home repeater LCN identified using the LTR finder. Next the Trunked Discovery mode has found three TGID's all associated with this one home repeater. And finally the Trunked Activity Display is showing three LCN's, 2 - the active home repeater, 20 - that must have been active as an overflow LCN at some point, followed by an LCN of 30 which is out of the regular LTR, LCN range, but cycles when the primary LCN 2 begins and ends the voice traffic. It looks like it may be sending it to a conventional repeater to extend range to another tower or system, and the FCC data supports that with two control points. Thank goodness for the CW ID recording, and I even saw a CTCSS tone show up on the Conventional Discovery. Without the HP-E, I would really be getting nowhere fast on this system, even with LTR Finder.