I'm attempting to import an ADIF written from ACLOG (logger written by N3FJP for Windows).  In all of my records that have a "Y" in the QSL_SENT field, CQRLOG defaults to "B" for BURO.  Also in the QSL_RCVD field, a "Y" defaults to "Q" whatever that means (I couldn't find it in the documentation-help).  While I appreciate the extra flexibility built into this field by CQRLOG, it would help if it would at least recognize the more basic approach of other logging programs when importing.  Can anyone help me with this?  Or maybe tell me a way around it without having to go in and manually chang

Clublog now supports the QSL Verified feature of the ADIF Standard.. To quote G7VJR:
"..there are actually three QSL states defined in ADIF:
 
Worked (QSL_RCVD = N)
Confirmed (QSL_RCVD = Y)
Verified (QSL_RCVD = V)
 
Up to now, Club Log has only supported worked or confirmed (a paper QSL or LOTW QSL is sufficient). However, while we were chatting at the RSGB Convention, Alan 5B4AHJ proposed that it would be helpful if Club Log also supported the verified state, which is set when you have your QSL accepted and awarded by ARRL."

I noticed today, after setting the TX power in fldigi for logging, that that piece of information isn't imported as part of CQRLog's remote mode.  It would be great if it were, because otherwise I have to go back and change it manually.  Along those lines, are there any other things in the fldigi log (state, notes, etc.) that are ignored by CQRLog in that mode?

When I attempt to run CQRLog in remote mode, with fldigi logging I can't use the results.
This is what I am seeing:
 
* The following are copied from the last QSO in the database prior to going into remote mode:  qsodate, time_on, time_off, callsign, freq, mode, rst_s, rst_r, name, QTH, loc, state.
* pwr is not copied, and it uses the default value.  (Probably because fldigi is not providing a power value.)
 

I just migrated to CQRLog from Xlog, and I'm loving the power of this tool.  After import, I realized that my adif file had reversed the RST values, so that the valued I'd reported out was in the column for values coming in.  No problem:

UPDATE view_cqrlog_main_by_qsodate SET rst_r=rst_s, rst_s=@temp WHERE (@temp:=rst_r) IS NOT NULL;

and all of my RST values were swapped.  I would have had to have to swap the values for each QSO using my old logging program.  Very pleased.

Is there a get started tutorial for cqrlog and indeed logging in general?

Anyone know how to export the frequency instead of the default band when exporting QSL's for printing?

I changed to the XFCE desktop - better usage for me as in other KDE/Unity ...
Start of CQRlog (1.2.x and now 1.5.2) is not possible - it show only a yellow window and nothing more.
Do someone more have this behaviour?
The whole ubuntu 12.04LTS was reinstalled on a new laptop with Nvidia graphic card (duo Core 2.5 Ghz) - how to find the "problem"?
 
Greetings PEter DF1LX
(on my old laptop it was working using KDE Desktop - but only 1.6 Ghz Dell Laptop single core, standard laptop graphic card)

Hello everybody!
Hello Petr!
I use v.1.5.2 jn my Slackware 12 notebook. I can control my YAESU FT-897 using RigControl via rigctld (default port).
I made a SoftRock SDR recently, QUISK is the best choice for me by now. A QUISK software has its own port 4575 to control SDR. And it works with CQRLog's RigControl fine.
So, they both work, but separately as Rig #1 and Rig #2.
The question is how to to control two rigs (Rig $ SDR Soft at my instance) the same time. To avoid a concurrent situation, I think, one of them has to be "master", another one - "slave"

Let me start by saying this is not very urgent to me but may be useful to others as well.
Now you can choose the spots shown filtered by continent. This also means a lot of spots are shown spotted by Ham's from "far away" countries. I.e. PT0S spotted by North Americans in Europe's late evening on, say 15 meters.
Now if the continent of the SPOTTER could be chosen, I for instance, would choose Europe. Meaning I would only see spots spotted by a Ham in Europe. This would greatly improve the chance that I can hear (and work) the DX.
 

I had a failed upgrade to an Ubuntu 11.10 system, on which I had cqrlog installed, and I had to bail out and install a fresh 12.10 in place of the old 11.10 system. Fortunately I was able to recover my data beforehand, so I have the contents of ~/.config/cqrolg from the previous installation.

Hello,
is it possible to get an universal export of the QSO-Data, like a csv? But not the IOTA-csv, I mean a csv with all values like they appear in ADIF.
So it would be easier to work with the datas (for example including them on a web site or using them for any other issue)
73 de Andre, DL4UNY