eQSL download

[DF5WW]

I´ve seen some differences between the download from the LotW and the download from eQSL ...... LotW downloads all incoming gso´s after the last download, so i only have to set the date of the last LotW download. When downloading from eQSL i have to use the QSO date. That means if in Mai 2013 a card arrives for a QSO from 1984 i have to download from this date on. Lot of download time. In HRD´s logbook the eQSL download only "grabs" the incoming QSO´s after the last inbox download. Is it possible to change this in Log4Om too ????

[K7PT]

Hi Juergen,
Firstly, LOTW downloads beginning with a start date and all LOTW matches from that date will be downloaded. It's the match date, not QSO date.

An example: If I set the start date as May 01, 2013, I'll get all matches from that date through the current date, nothing before the start date. This means you can miss matches if you don't check on a regular basis.

If I downloaded last on March 30, 2013 and then set the start date as May 1, 2013, I could miss all matches in between, the entire month of April.

So, what I'm saying for your 1984 match you might have to download beginning then unless the match was recent.

[k3dcw]

I was just going to make a post about this too, Juergen. The difference in implementation between the two is interesting.

As you said, in LoTW, we can get a download of all QSLs received since the last download, but in eQSL we have to do a complete download of all QSOs from a set period (it defaults to 6 months), and so you end up repeatedly downloading the same QSLs over and over.

It would be nice if they both could be made to function the same way (like LoTW now, only QSLs received since the last download) so that you'll know right away how many NEW QSLs you have received. I know other software does this, so it can be done.

73,

Dave
K3DCW

[k3dcw]

I'd like to post on this again to bring this back to light for the developers.

The difference in implementation between downloading eQSL and LoTW is puzzling to me. eQSL downloads confirmation for QSOs held in the last 6 months, while LoTW downloads QSLs received in the last 7 days (those are the defaults and can be changed). Wouldn't it be easier and clearer to have both function the same; in other words have both download QSLs received in the last 7 days?

I know eQSL can support this as I've seen it with other programs where you don't have to download a whole bunch of QSLs, just the new ones. Also, the current system of limiting the search to QSOs from the last six months (or whatever the user chooses) prevents the user from seeing a QSL that is received for a QSO held 18 months ago. With new people joining eQSL and LoTW everyday, this kind of thing happens often. Ultimately, it shouldn't matter when the QSO was held, as long as the QSL has been received in the time frame selected in the download window.

I would like to suggest that the developers take a look at the logic of this again and see if the two systems can be unified in the way they handle incoming QSLs (preferably unified to match the way LoTW is handled).

73

Dave
K3DCW

eQSL download dialog

eQSL.JPG (52.9 KiB) Viewed 8314 times

LoTW download dialog

LoTW.JPG (50.54 KiB) Viewed 8314 times

[G4POP]

Also, the current system of limiting the search to QSOs from the last six months (or whatever the user chooses) prevents the user from seeing a QSL that is received for a QSO held 18 months ago.

If I understand this correctly you are saying that the earliest date that can be set is only 6 months ago, if so then I believe that I need to point out to you how to set the start date using the standard Windows calendar method.

If you click the month/year title at the top of the calendar a number of times you can select any year back to 1753, yes I know we did not have ham radio in those days

When the desired year is selected the user can then drill down to the exact day of the month by a couple more clicks.

Same applies to all date choosers in the program

See the images below

[G4POP]

I would like to suggest that the developers take a look at the logic of this again and see if the two systems can be unified in the way they handle incoming QSLs (preferably unified to match the way LoTW is handled)

I agree about having a uniform format but I believe we need both the 'From' and 'To' dates because some users may need to update a specific section of a logbook so the end date is very important.

However this may not be possible due to the constraints of LOTW and eQSL developer download facilities, I am sure Daniele will know?

[k3dcw]

Terry,

I guess I wasn't too clear in my explanation...it is too easy to confuse the Q-sigs QSL and QSO when reading a paragraph, so I tried to bold and underline in this response.

When checking LoTW, it checks for "QSLs received" during a set period of time (default is the last 7 days). Of course, that can be made to cover any period of time, but the default is the past 7 days.

When checking eQSL, it checks for matches for "QSO made from" a date "to" a date. Those dates are set for a default of 6 months (from today, back 6 months), and can be changed to cover any period of time.

However, in these two options, Log4OM is comparing apples (QSLs received) and oranges (QSOs made), to steal an idiomatic phrase.

There is a big difference between "QSLs received" and "QSOs made". Here is an example scenario:

Say I had a QSO with you (G4POP) on 01 January 2012 and you were just this week uploading your logs to eQSL and LoTW having just recently signed up for both services; and our QSO is matched on both services almost immediately. Using the LoTW download in QSL Management, that QSL from LoTW will show up as having been received in the last 7 days and will be downloaded and will populate the database correctly. However, it won't show up in eQSL since the QSO was more than 6 months old; UNLESS I change my start date and force Log4OM to download over 18 months of QSLs and QSO data from eQSL. That's a lot of extra bandwidth for 1 QSL.


Within QSL Management, I don't think Log4OM should be checking for QSOs made during a set period (as it does with eQSL) but rather it should be checking for QSLs received during the time period selected, REGARDLESS of when the QSO was actually made (as it does with LoTW). It shouldn't matter whether the QSO took place today, yesterday, last week, or 10 years ago, the tools should be able to search for QSLs received within the user-selected time window, which happens to be 7 days for LoTW. (but could be any number selected by the user). I don't know of any other logbook program with eQSL support that doesn't search for QSLs received, but instead searches for matches for QSOs made. Wouldn't searching for QSLs received within a window save some bandwidth from eQSL????

I've been using eQSL and LoTW since day one as a ham (which for me was in April 2009). I still get QSLs via LoTW dating back to that time, but I would have to download my ENTIRE eQSL logbook each and every time to see any new QSLs that may come in from that period of time on eQSL.

And yes, ideally we could search for either QSL received during a time frames OR QSLs received for QSOs conducted during a set period; but if I had to choose one or the other for QSL Management, I'd think QSLs received is more logical.

Hope this helps clarify a bit.

73

Dave
K3DCW

[G4POP]

I just checked the developers download parameters for both LOTW and EQSL

The download parameters that we have to send to eQSL and LOTW are different

LOTW parameter is qso_qslsince date (YYYY-MM-DD)

this returns QSL records received on or after the specified date. Will also accept date/time in "YYYY-MM-DD HH:MM:SS" format. Ignored unless qso_qsl="yes".

Whereas EQSL requires us to send

Get-> from date (YYYY-MM-DD) to date (YYYY-MM-DD)

I beleive this is the reason that it is different! but Daniele will confirm

[k3dcw]

Terry,

Thanks for looking into that. I know that other logbook programs don't have this issue for some reason (maybe they filter the downloaded ADIF file to remove "dupes"), so that's why I was asking.

If that is the way Danielle was told to handle it, and that's what the team decides, I'll just have to live with it; although I think there must be a more elegant solution than a brute-force mass-download each and every time.

Thanks again!

73

Dave
K3DCW

[G4POP]

I know that other logbook programs don't have this issue for some reason (maybe they filter the downloaded ADIF file to remove "dupes"), so that's why I was asking.

We can only download using the protocol provided by LOTW and eQSL this applies to all developers.

We don't need to "Remove Dupes" because we merge the data we do not overwrite the logbook

If that is the way Danielle was told to handle it

Daniele is the boss he decides

I think there must be a more elegant solution than a brute-force mass-download each and every time.

What we do is update any 'Changed' data not overwrite everything, this is a merge function.

So if a QSO in the ADIF says QSL received = Y and the QSO in the logbook says QSL Received = N we update the logbook to Y and enter the date the QSL was received and by what method.

Conversely if a QSO in the ADIF contains the same QSL data we ignore it

We feel that this is straightforward and user friendly?