Log4OM

W7MGB wrote: ↑06 Feb 2018, 16:01 Just a tad bit more info, FWIW.....

I was wondering if maybe this was something that happened in one of the later versions. I'm guessing that you have been a user all along, so you probably have a version from a long time ago, with updates applied to it over time.

I went back to the earliest version I could find, which was 1.20. I uninstalled my version and installed 1.20. I still had the same issue. However, I do not think the uninstall was clean. I did the best I could to delete any reference to log4om, but I must have missed something - as soon as I loaded up version 1.20, all the configurations were still there. I went ahead and connected to the MYSql server and made a new database with version 1.20, hoping that the field defs for "Freq" would have been different - they were the same as the current version.

Just so you know, I am really okay with all of this. I am only providing information on my insignificant situation. Please do not assume this to be a troubling situation....

Can you confim that your Windows 10 numbers format is exactly as shown below please

Identical except for measurement system - Mine was set to US, I just made the change to metric, otherwise, everything matches perfectly.

I'll go enter a contact now and see what I get.... I will find it very interesting if the US vs Metric makes the difference.....

Same result.... I sure hope you are not losing sleep over this!! I'm okay with it.....

But did you restart the computer and log4om after changing it?

We need to know why your set up is reacting differently to the other 40,000 plus users

Not at first - totally overlooked that, but the outcome ended up the same anyway. Still does not log like we think it should.

Humor me though, let's make sure, really, that we are comparing apples to apples......

If I look at the raw data in the MySQL DB, it shows as "7074.123" When I enter the data in log4OM, just typing straight through -- 7074 then a "dot" it shoots me to the Hz where I enter 123. Then I look at the QSO Archive, and I see it as shown above in the screen snippet I attached.

How is it displayed in your QSO Archive? You (and, assumingly, everyone else), they see;

7.074.123

What is your backend? Is it MySQL Lite or MySQL?

Thanks for all the time and attention you have put in on this....

(BTW - I completely updated MYSql and Server OS [Ubuntu Linux] last night).

And.... If I am 1 out of 40,000, then it really is just my problem. I don't think we should worry about it too much more....

Les

I use the standard SQLite database and my QSO archive manager results are as shown below, same result in all other windows.

That really makes me lean towards the MySQL Database then. It seems that everything else we have is the same, with the DB of choice being the variable, possibly (remember, I did experiment with SQL Lite to see what would happen.....). I chose MySQL as I already have it configured, running, and I am a little familiar with it. I have a few other databases there too - naturally though, nothing logs like a radio frequency, so I am going to see what happens if I try that on the other DBs.

I'm also going to try and remember, later today, post a forum question asking that very thing - "Who uses MySQL as the DB and what is your experience with it" - unless you are already gathering that data?

Log4OM stores frequencies in KHZ. After decimal point indicates Hz (144555.678)

ADIF protocol requires frequencies are expressed in MHZ. So everything after MHZ is after a decimal point (14.555678), driving up to 6 decimals to save until single Hertz.

CAT software like Omnirig reports frequencies in Hz (144555678)

Due to several problems with local user number formats, decimal separators and other similar issues we decided to "force" the format into database that way.

Despite the local display of the number, you should see in DB frequencies like 144MHz 600KHz (R0 VHF) represented as 144600.000 This will be exported into ADIF as: 144.600000

The format shown on Log4OM is using the user local configuration, so comma or dots for decimal, and vice-versa for thousand separators.

Internally the format is ALWAYS without thousand separators and with DOT as decimal separator.

The field format in the database is a STRING for several reasons (mainly related to portability and precision up to 6 decimal points) and it is internally converted into decimal when needed

Some software doesn't comply with those rules, and exports ADIF as KHZ.

When Log4OM reads numbers "over some reasonable values" it tries to correct them assuming those frequencies are KHz instead of MHz

Generally speaking this is a very complex thing to deal with due some "environment discrepancies" when talking with other systems

Hello friends !

Short , but for me , important question ...
I am a begginer user and i'd like to know - if I download the e-qls using "qsl tools/menagement "
- will the statistics of my qsos be automaticly updated as "confirmed" ? Should I do something more
manually to update, for e.x SQ2ZE as "confirmed" after receiving e-qsl ?
Thank you in advance for any help /answer .

Regards
MaC SQ2ZE

SQ2ZEE wrote: ↑02 Jul 2019, 05:55 Hello friends !

Short , but for me , important question ...
I am a begginer user and i'd like to know - if I download the e-qls using "qsl tools/menagement "
- will the statistics of my qsos be automaticly updated as "confirmed" ?

Yes - See the user guide or watch our YouTube tutorials

Should I do something more
manually to update, for e.x SQ2ZE as "confirmed" after receiving e-qsl ?

No