The world's best linux logging program!

You are here

CQ Monitor Data Source

Hi, is there a way that I can program where the CQ Monitor goes to get data for stations?, I've noticed that CQ Monitor is displaying certain stations as located in a particular state in the US and when the qso is made I see that they are in a different location. As soon as I begin the qso, in the New Qso Window the correct information is displayed and often differs from what is shown in Cq Monitor.

CQ-monitor uses same ctyfiles as cqrlog itself. So you see the same problem with manual enter of New Qso.
us_states.tab in ~/.config/carlog/ctyfiles holds the information, but it fails as US stations need not to change their call any more when they move.
Same here in Finland. Previously country was clearly divided to counties OH0...OH9 and you had to ask for new call from telecommunication author if you moved. Not any more.

That makes precise county definition from callsign prefix impossible.
Only way, in question of US states, would be to make database holding all calls and counties from FCC databases and update it on regular basis.

if I understand correctly, now a station from Helsinki can use OH9 prefix. Hmmm...
What about OH0? Must be they on Aland? And Market Reef? Still OJ0?
Can you tell me the date when your authorities gave up the prefix alocation?
It would help me to keep the country files fresh and useful.

I'm not sure how long this has been on. But quite long. One source says that selling callsigns started in mid of 1990's ( http://oh2mp.ham.fi/kutsut.html , in Finnish :use google translate)
The provinces were abolished on 1 January 2010 and I think that at least that time also prefixes by provinces finally lost their original status.
How ever authorities still try to give a new call following the old province formula. How ever yo can buy a callsign that is not in use.

I could buy OH9SAKU and use it here (in old province formula of OH1).

So you can not specify area by prefix any more for sure.

Except OJ0, and I think OH0 is also quite sure (but I do not know if it is just a gentlemen agreement).
Mainland prefixes may be mixed as in U.S.A.

Still thinking about this US county finding.
If we forget callsign prefix as unreliable county recognize source, what else we have?

At least with wsjt modes it could be easy to use locator grid as approximate county indicator.
With 4 char grid it is not very accurate but gives good direction.
With 6 char, or more, the it would be great.

If just someone would do a list of counties with grids they have. At level of 6 char would be very usable even when we could search from it with only 4char grids in most cases.
And this list would be rather stable, I think so :-)
No need to upgrade very often...

I tried to make few quick google search with this subject, but did not find any ready made list:
So if someone is wiling to do it, or knows a ready made list or database somewhere, it could maybe be used as US county recognize source for cqrlog.

The only reliable data source is the FCC Database. FCC made it available to the public (they have no stupid Data Protection measures like here in EU). Simply hit F11 (in Preferences MUST be the Callbook support pointed to HamQTH.com) and the State and County columns are automatically filled with the data from the FCC Database.

The State and County can be determined also from the ZIP code, CQRlog has a VERY RELIABLE algorithm for ZIP code extraction from the address and a database allowing county determination by finding the ZIP there. The ONLY problem is the reliable callbook - but, again, the FCC Database can be used. Actually, no need to use the ZIP_code/County database (although this option still exists and works) because the direct County/State reading from the FCC Database works.

HI!
We have discussed this before.
US counties, or states if you wish to use that word, are not reliable as in US (as in Finland) callsign change is not any more required when you move. So states by perfixes do not work.

Routine that is in cqrlog and used in CQ-monitor as well as in NewQSO gives very often wrong state.
When callsign data fetch from HamQTH or QRZ you find out that state is different than cqrlog offers.

So CQmonitor gives (may give) different state when just monitoring. If call is selected for qso and transferred to newQSO callsign field and HamQTH/QRZ fetch is done you notice that it is not the state you are looking for!

In WSJT modes the locator (4chr) is sent with CQ and if we just could have database that list locators by states (or states by locators) we get the real state (or near by with 4chr) already at CQmonitoring phase.

And if station calling CQ is not in his normal qth (portable or something) the locator send with CQ is the only way to try to dig out what state he is in. FCC databases or HamQTH/QRZ does not right work then.

This works only with wsjt modes as "preview of state", not with other modes as locator is normally not included into CQ.