Greetings.
While ago worked AH0U on 14MHz band.
JTDX-2.2.0-rc152 displays this callsign as U.S.A.
CQRLog - as Mariana Islands.
BIG cty.dat lists this callsign correctly,
as U.S.A. and NOT as Mariana Islands.
Best regards.
Tom - SP2L
Fri, 2020-09-11 17:12
#1
SP2L
AH0U - CQRLog list this as Mariana Islands.
HI Tom!
That is "forever question" with US states (as well as OH districts) because the old system where prefixes were given by location is not any more used. Not in US, not in OH.
So you can not know where station is by looking at prefix. Only country can be defined.
You will find more discussion of this subject from this forum in earlier threads.
If you download and compile my alpha test version from github it has checkbox "USt" in CQ-monitor.
Alpha is branch "loc testing". The state addition alone can be found from branch "new_states" and should be quite easy to merge to official source. The first version branch "states" needs more work when merge it to current official source.
When selected "USt" it does not use cqrlog's country files for precise definition. It takes just USA from that one and then uses its own "fcc_states.tab" to define US state.
"fcc_states.tab" is defined by downloading callsign information file from FCC. There is all information of US callsigns now, and past. But only callsign=state pairs is created from that information to be used with CQ-monitor.
I did peek callsign given by you from "fcc_states.tab" and result is:
[saku@hamtpad ctyfiles]$ grep -ni ah0u fcc_states.tab
31112:AH0U=CA
So the call is from mainland, California.
I do not know how JTDX does this. Another solution would be to fetch every callsing decoded from QRZ.com or HamQTH.com but that would mean a lot for internet traffic and long delays if the connection is low speed.
That's why I made local callsign=state pair file.
More clever solution would be to make own database table. Then also other information (Name address etc) could be easily stored and queries would be easier. Maybe some day....
This property is not included in official version of cqrlog.
--
Saku
OH1KH
Hello Saku et al.
I appreciate very much your detailed response.
Generally, I am perfectly aware where the culprit sits.
That's why Jim Reisert's webpage is very usefull:
https://www.country-files.com/
JTDX uses builtin copy of latest available
(at new JTDX version release date) cty.dat file.
All users can simply override this functionality
by manually adding latest (newest)
cty.dat file in JTDX configuration directory.
Quick, simple and works perfectly.
From the other hand, I am greatly astonished that
QRZ.com is not up do date in this regard,
displaying AH0U as Mariana Islands. Weird....
Here, in my country, rules governing callsign allocation
also changed and now same suffix can be used in all
local radio amateur regions from "0" to "9". It's a mess...
Wil give a try to your suggestion.
Take care.
Best regards.
Tom - SP2L
https://www.sp2l.ampr.org
Hello Tom,
just press F11 and the entry correctly changes to USA, California. Also you will see the County field filled with CA, Contra Costa. This works with Callbook support defined, pointing to HamQTH.com which is connected to the FCC database and should be always actual. I highly recommend to check any call from US posessions with F11!
73,
Martin, OK1RR
Hi Martin!
Good point!
I had forgotten F11 as I have always used automated HamQTH/Qrz info fetch.
Unfortunately it helps only if owner of callsign has updated his information to HamQTH or Qrz. And that user of cqrlog has initiated that one of those two where user has done his update.
If information is fetched from FCC it is always up to date and includes also old call holders. ftp://wirelessftp.fcc.gov/pub/uls/complete/l_amat.zip
It should be assigned to own database table to get full benefit. I have only used states information to sting list at the moment for wsjtx monitor.
How ever it would solve only US callsigns. For example there is a list of valid OH callsigns available from our telecommunication authorities but it holds only callsing, nothing else as it is against law to publish personal information here. No in US.
So we are depending on what people will add to HamQTH or Qrz. And that we select to use the right one.
--
Saku
OH1KH
Saku,
very true. Thank you for your comment.
The FCC strategy totally ruined my intial concept to have most accurate country files as possible. Literally, hundreds of hours of my work was devaluated...
I don't see any problem with OH calls because it is still OH (ADIF #224), there is no bunch of different DXCC entities (also from another continent!) bound to OH prefix. I know that now is possible (or will be very soon) to use OH5 prefix from Aland Islands or even Market Reef but assuming that such case will be rare enough to cover it in individual callsign database CallResolution.tbl.
The biggest problem now are the U.S. 1x1 calls (N8S, K5K etc.). They may be operated from anywhere and the changes are very fast. It is possible to work a 1x1 call from continental USA and Alaska within a week. The connection to the FCC database is the only solution however an "automated F11" will introduce an unacceptable delay so I would ask to press F11 on any "suspicious" call from USA & posessions. Here I gave up to enter every exception to the CallResolution.tbl.
Just another problem are Russian special (read irregular) calls. RP99AA can be EU Russia, RP99AB AS Russia, RP99AC Kaliningrad etc. Unfortunately there is no qualified guide like FCC, info from Russia are very hard to obtain, the Russians themselves mostly don't know what DXCC is a particular call. Also here I gave up to enter every exception to the CallResolution.tbl.
Similar to Russia are 9M4 calls and any 9M## (two numerals) call. Similar mess is the France DOM Overseas Dept. calls using TO an TX prefixes. Unfortunately the French authorities now preferring to assign TO or TX calls to any expedition, organized mostly by a non-french applicant. Also there are infreqent exceptions (4U, VK9, VK0, VP8 and so on) which can be covered in my usual way.
Every CQRlog user should know that the country files maintenance is a very high demand task!
Hello Martin, Saku.
I hope that I did not made very big noise on that field.
Just wanted to express my great astonishment,
_NOT_ complaints...
It's very rare that volunteer work is rewarded at least in part.
Myself I'm not IT professional, but I am Linux and HamRadio enthusiast.
I know many things and I know how to do many things,
but I do not know everything and I do not know how to do everything
Best regards.
Tom - SP2L
https://www.sp2l.ampr.org