>I find that the start with ¨LoTW:¨ in notes is very usefull in dx4win >Because with F8 looking up ¨LOTW: STATE¨ will only show up those qso´s where > >Both are present, same for other items.
This points out the need for a filter dropdown choice of "Not blank" in the State, Grid and Zone (and other?) fields, similar to that provided in Microsoft Excel. The fact that the record has been updated from LOTW is already denoted by the setting of the Upl Cnf flag. Use of the F8 filtering function to filter on a combination of Upl Cnf = Y and State = (notblank) would do the same job without requiring extra text in the log file. Inserting extra text in the log file to make up for a deficiency in the program's native search function is a less than optimum approach. Another feature that would be "really nice" for troubleshooting LOTW problems would be to provide an extra field in the log record for a date stamp when the Upl Cnf flag was set. This would require altering the structure of the log file, however, and is almost certainly not worth the complication. > >"LOTW: State=GA County=Harris Grid=EM72 CQZone<>5" is written in the notes >for this call because one of the items was incorrect-- in this case it is >CQZone 5 >like you explained. When all downloaded data is correct and put in the >correct >field there is NO LOTW: in the notes for this call. >I am sure that Paul is reading this and will probably come up with something >That for instance only shows the corrupt items like LOTW: CQZone<>5, wrong >Grid >This part needs the user his attention because there is a difference between >the log >And the import. Actually, the point of picking this particular example was that DX4WIN was wrong in selecting zone 4 and didn't correct the error on LOTW import. KU8E is actually in Georgia, which is zone 5. Of course there is no way for the software to know that, but the update after the LOTW record import should have picked this up when the State field was populated with GA. I also found plenty of records where there was no zone problem, just the updated State and County fields. Each of these got the "LOTW:" treatment too. So the "LOTW:" notation is not indicative of a just a conflict between existing log data and imported data. It simply indicates that there was information, correct or not, in the imported LOTW report record that wasn't in the original log record. I completely agree that imported data that conflicts with data already in the log should definitely be flagged so the conflict can be resolved. As I see it, the main problem with the "LOTW:" text insertion is that it blurs the distinction between updated information and conflicting information in the import record. In the case where imported information disagrees with information in the log, I'd prefer to see the same "ERROR:..." message that's used for flagging zone and country prefix differences. This alerts the user that there really is some sort of problem that needs to be looked at. In the case where the LOTW import simply filled previously blank fields, it's up to the user to verify the new information if he chooses to. The search procedure discussed above seems to be the best way to select the records that need to be examined. >I agree that with massive import this is a big job to correct but I prefer >To have it in my log then somewhere on a report sheet. This get lost or >deleted And your log stays bugged. I prefer to work from an import change list, especially one in comma-delimited format that I can drop into Excel and manipulate to pop out the changes that I care about. Then I can go to the log itself and fix only the records I've selected. To each his own. >...181 where gridlocators because in my log was JO21ba and the upload showed >JO21 only Which brings up another point. The program does wonders with pattern searches in looking for callsigns. Surely figuring out that JO21ba and JO21 are the same grid square can't be that difficult. The structure of grid square nomenclature is well-defined. If the first four characters match, it's the same grid. Requiring a literal string match in the Grid field seems rather primitive. >100 others where LOCATORS that didn´t match some of them there shack is in >the middle >Of the ocean, fixed it with QRZ.com when states and county were equal. >Now I am still stucked with 40 problems and these ARE USER FAULTS because in >my log >They lived in CO - DENVER county in 1991 and moved to a new qth in NY but >uploaded >There FULL log with data from the new qth and not from 18 years ago, >Never received paper qsl so can´t check it. I've gotten a few of those myself. Unfortunately, we can't expect the software to correct for mistakes at the supply end of the LOTW chain. When we get information from the guy on the other end of the QSO we have to assume he's providing good information. With humans involved in this operation sometimes that doesn't happen. And to open up another can of worms, see what happens when the same call shows up with two (or more) different names. Since DX4WIN assumes (wrongly, in my estimation) that each callsign will map to a single name, bizarre things happen. I imported a lot of contest QSO records from the North American QSO Party (NAQP) and the North American Sprint, where a name is part of the exchange. Jim's software picked up the name and inserted it in the Name field. The only problem is that sometimes the same station will use different names in these contests, so for one QSO you will get DWEEB and for another you will get VAL, etc. I don't remember exactly how the program behaved, but I think it ended up updating the name field in all QSOs with that particular callsign with the name in the last record inserted. This didn't bother me a whole lot, but it does point out a flaw in assuming that each call must always have the same name -- club stations, any one? >A multiple QSO operation with cleanup ¨LOTW: comments¨ would be an option >but will >This be a good option ? you remain with an incorrect log. Like any tool, if it's misused it can create more problems than it fixes. If it's used only after true problems have been identified and fixed I'm all for using a tool that will ease the burden of rote mechanical find, select, delete for dozens or hundreds of log records. This is why I am contra the 1 button LOTW upload/download some people may >wish, > From time to time you make a small expedition or have a special prefix/call >etc >And you want to upload them to lotw, creating a unique name log is not a >problem >Having a certificate isn´t a problem also, Lets say that Paul should ad this >feature >With a setup in preferences.(TQSL password etc) but >afterwards.................. >Just wondering how many times this 1 button upload will be incorrect if you >forgot to change >to the correct certificate? I agree totally. The biggest problem with the LOTW process is that it's, shall we say, somewhat less than user-friendly. For those users who are lucky enough to have made QSOs only from one location and/or callsign, a one-button function might be OK. For those of us who have a more complicated situation, the chances of getting things wrong are much, much greater. To do the entire LOTW upload process right from within DX4WIN would basically involve wrapping a shell around the TQSL application and it probably wouldn't look all that different from TQSL anyway. I don't think it's worth the programming effort. Thanks for the comments. It's always good to discuss ideas that can make a fine software product even better. 73... Randy, W8FN ______________________________________________________________ Dx4win mailing list Home: http://mailman.qth.net/mailman/listinfo/dx4win Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
