Database Submission Corrections

[W4ELL]

I am having an issue getting my database submission submitted accurately. I submitted this system:

https://www.radioreference.com/apps/db/?sid=9952

My initial submission, along with my 2 followup submissions to correct the entry, contained LCN numbers and TGID information for the system. After getting notification that these had been completed, the information remains inaccurate.

In the database, there are no LCNs at all and the TGIDs are incorrect. It makes me wonder if the information submitted is being formatted automatically with a template or something? I would be happy to submit the corrections again but I wanted to bring this to your attention first.

Thanks,

 

[troymail]

I am having an issue getting my database submission submitted accurately. I submitted this system:

https://www.radioreference.com/apps/db/?sid=9952

My initial submission, along with my 2 followup submissions to correct the entry, contained LCN numbers and TGID information for the system. After getting notification that these had been completed, the information remains inaccurate.

In the database, there are no LCNs at all and the TGIDs are incorrect. It makes me wonder if the information submitted is being formatted automatically with a template or something? I would be happy to submit the corrections again but I wanted to bring this to your attention first.

Thanks,

I do see LCNs - you have to drill into (click on) the "site" name (Alcoa) to see them.

What do you believe is incorrect about the TGIDs?

 

[W4ELL]

I do see LCNs - you have to drill into (click on) the "site" name (Alcoa) to see them.

What do you believe is incorrect about the TGIDs?

Thanks, I do now see the LCN information in the site info. In the past, the LCN information was listed with the frequencies on the main page, which threw me off.

The TGIDs are IDAS TGs and all begin with 5 instead of 0:

5-1 Plant Operations
5-37 Plant Operations
...

I guess the ultimate test will be to import the system into a scanner and see if it works.

 

[troymail]

Thanks, I do now see the LCN information in the site info. In the past, the LCN information was listed with the frequencies on the main page, which threw me off.

The TGIDs are IDAS TGs and all begin with 5 instead of 0:

5-1 Plant Operations
5-37 Plant Operations
...

I guess the ultimate test will be to import the system into a scanner and see if it works.

I do agree that if your radio is showing the TGIDs as 5-1 and they are listed in the database as 0-1, the radio will probably scan but won't hear anything (unless it's in ID Search mode).

Are you using a Uniden scanner? If so, I assume you are using other than Sentinel (which, unless I missed something) to download and program your radio?

 

[W4ELL]

I do agree that if your radio is showing the TGIDs as 5-1 and they are listed in the database as 0-1, the radio will probably scan but won't hear anything (unless it's in ID Search mode).

Are you using a Uniden scanner? If so, I assume you are using other than Sentinel (which, unless I missed something) to download and program your radio?

Yes, I am using ProScan to program and I am using Uniden scanners exclusively.

Tonight, I will import the system from the database and see what happens. I agree that the TGIDs probably won't work as they are listed but I am more curious to see if the LCNs make it over.

I guess my other concern is for those who program the system manually. Will they know to look for the LCNs under the site info? IMO, keeping the LCNs on the main page would be optimal:

 

[troymail]

I guess my other concern is for those who program the system manually. Will they know to look for the LCNs under the site info? IMO, keeping the LCNs on the main page would be optimal.

That's just one of the issues people will need to consider when programming manually.... they could just as easily miss the LCNs if they were listed directly next to the frequencies if they don't understand what they are doing.

As I understand it, these types of things are at least part of the reason the NXDN option is half price right now... Unfortunately, lots of folks only look at the price and don't consider the complexity of manually programming a scanner (particularly when for nearly all other cases the software does everything for them).

On the other hand, Uniden is still making money -- and so are the 3rd party software vendors.... I suspect those 3rd party vendors would love to see Uniden not fix Sentinel (at least, not any time soon).

 

[W4ELL]

That's just one of the issues people will need to consider when programming manually.... they could just as easily miss the LCNs if they were listed directly next to the frequencies if they don't understand what they are doing.

I totally agree.

Since we are still in the early days of NXDN/IDAS, I expect issues like this to arise as far as getting the information into the DB in a usable format and with accuracy. It is a work in progress and I am willing to help them toward their goal in any way I can. In the end, getting all of this figured out will benefit us all.

 

[ProScan]

I suspect those 3rd party vendors would love to see Uniden not fix Sentinel (at least, not any time soon).

Not me, I would like to see Sentinel support NXDN. I'll volunteer to update Sentinel for free if UPMan wants.

 

[kma371]

Fixed. 500 must preceed the talkgroup to display correctly.

 

[W4ELL]

Fixed. 500 must preceed the talkgroup to display correctly.

Thanks, but I think I figured out what we are missing and it may be something that has to change in the schema of the frequency database.

It looks like the TGIDs in the database are expected to be decimal values, which is NOT how IDAS TGIDs are formatted (in both the x36 scanners and in DSDPlus). The scanner lets you choose between IDAS TGs (In the format 5-xx in the system I am monitoring) OR Nexedge TGs... (which appear to be in decimal format).

I imported the system (using ProScan) into my 536 which defaults the system to using Nexedge TGs. The current TGIDS that are in the DB for this system get translated to decimal (Nexedge) in the scanner and they are not correct.

When I import the system (using Proscan) and edit the TGs into decimal format before uploading to the scanner, the system tracks just fine with the decimal values. I can then go into the scanner menu and switch the TGID format to IDAS and it converts them correctly without issue.

I think to rectify the problem in the database,for IDAS systems:

1. The TGID column needs to be formatted specifically to accept the IDAS TG format xx-xxx (Kind of like you do for LTR systems presently).

2. The importing software needs to tell the scanner to use IDAS TGs when the TGIDS in the database are in said format.

Another option, with the database as is, is to submit the TGID information in Nexedge format (decimal) which I think would only muddy the waters and cause mass confusion.

On a side note, the LCNs were correctly imported during each of my test imports into my 536..

II hope this makes sense as I tend to ramble a bit.

Thanks,

 

[kma371]

1. The TGID column needs to be formatted specifically to accept the IDAS TG format xx-xxx (Kind of like you do for LTR systems presently).

We do the same thing for LTR systems. There are leading zeros, that aren't visible on the public side, which make it display correctly.

NXDN Icom IDAS decimal talkgroup format is XXYYYY where XX is Home Repeater (1-30) and YYYY is group ID (0001-2047)

All the other stuff is above my pay grade

 

[W4ELL]

We do the same thing for LTR systems. There are leading zeros, that aren't visible on the public side, which make it display correctly.

NXDN Icom IDAS decimal talkgroup format is XXYYYY where XX is Home Repeater (1-30) and YYYY is group ID (0001-2047)

All the other stuff is above my pay grade

Thank you for the explanation, that makes sense.

It appears that the issue is somewhere in the import process.

If I enter the TGIDS manually as I see them in the DB (xx-yyyy), they work fine. If I import them via ProScan, they show up as a Nexedge (decimal) formatted TGs that are not valid TGs at all. It seems that the import doesn't know to use the IDAS TG format as opposed to the Nexedge (decimal) format. It may be as simple as adding some logic to parse the System Type for 'IDAS' when importing?

I don't have any way to test the import using other programming software yet so I can't say it is a ProScan issue specifically.

 

[wa8pyr]

Thank you for the explanation, that makes sense.

It appears that the issue is somewhere in the import process.

If I enter the TGIDS manually as I see them in the DB (xx-yyyy), they work fine. If I import them via ProScan, they show up as a Nexedge (decimal) formatted TGs that are not valid TGs at all. It seems that the import doesn't know to use the IDAS TG format as opposed to the Nexedge (decimal) format. It may be as simple as adding some logic to parse the System Type for 'IDAS' when importing?

I don't have any way to test the import using other programming software yet so I can't say it is a ProScan issue specifically.

This looks to be an issue with how your software interprets what it's receiving from the RR web service.

In the database, the system is listed specifically as IDAS, and that information is made available to requesting software through the web service API.

If you can, please download a trial copy of the appropriate Butel software, test the download that way, and report the results here; we can use that information to help nail down whether the problem is database related, or software related.

 

[W4ELL]

If you can, please download a trial copy of the appropriate Butel software, test the download that way, and report the results here; we can use that information to help nail down whether the problem is database related, or software related.

It looks like they both import them the same way... the imported TGIDs don't translate to valid ones at all even though they appear as though they are decimal. (Top is ARC536, Bottom is ProScan)

When the TGs are correctly entered (not via import), if I flip between IDAS and Nexedge TG formats in the scanner, the TGs translate as follows:

The question is: Is the database TGID format invalid or is the way the software interprets/imports that value invalid?

Thanks,

 

[troymail]

I suspect it is the software itself and not the database.

Try this one:

https://www.radioreference.com/apps/db/?sid=8005

It imports properly into Whistler's EZ Scan.....

 

[ProScan]

This looks to be an issue with how your software interprets what it's receiving from the RR web service.

In the database, the system is listed specifically as IDAS, and that information is made available to requesting software through the web service API.

If you can, please download a trial copy of the appropriate Butel software, test the download that way, and report the results here; we can use that information to help nail down whether the problem is database related, or software related.

The fix can be done on either side. The root cause is the RR Web Service http://api.radioreference.com/soap2/?wsdl&v=15 defines the tgDec field as integer meaning all non numeric characters are stripped.

I'll look at formating NXDN IDAS talk groups on the ProScan import side.
{edit} Is it both IDAS Type C & D needs formatting?

 

[W4ELL]

I suspect it is the software itself and not the database.

Nail on the head. Both ARC536 and ProScan exhibit the same issue when importing that IDAS system also. Looks Like Bob already has a fix in mind. I will see about submitting this to Gommert at Butel too.

Thanks for everyone's help on this... I am glad we got it all figured out.

 

[W4ELL]

I'll look at formating NXDN IDAS talk groups on the ProScan import side.
{edit} Is it both IDAS Type C & D needs formatting?

I can only confirm Type D for sure... When I get a few minutes, I'll see if I can test a Type C import. Thanks for the quick response on a fix by the way.

 

[W4ELL]

I can only confirm Type D for sure... When I get a few minutes, I'll see if I can test a Type C import..

I don't have any Type C IDAS near me and upon searching the database, it looks like all the Type C IDAS TGs are decimal only. I imported this one successfully and the TGIDs look fine (as I would expect):

https://www.radioreference.com/apps/db/?sid=9218

 

[ProScan]

I don't have any Type C IDAS near me and upon searching the database, it looks like all the Type C IDAS TGs are decimal only. I imported this one successfully and the TGIDs look fine (as I would expect):

https://www.radioreference.com/apps/db/?sid=9218

Thanks. Saved me a little time so just Type D needs formatting.