Hmmmm.... Let me check this out. Thanks, Jack
----- Original Message ----- From: "Sergei" <[EMAIL PROTECTED]> To: "'Jack'" <[EMAIL PROTECTED]>; "'DXbase Reflector'" <[email protected]> Sent: Wednesday, June 16, 2004 3:51 PM Subject: RE: [Dxbase] Many, many more Dxbase LoTW import-related dupes found > Jack, > > One thing seems to be DXbase problem. The Non-DXbase Import always put > USB instead of LSB on 160m band QSO. I always correct the DXbase log > after import WL contest logs. Why? > > Regards, > Sergei UX1UA aka UV5U,EN1U > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jack > Sent: Wednesday, 16 June, 2004 18:58 > To: [EMAIL PROTECTED]; DXbase Reflector > Subject: Re: [Dxbase] Many, many more Dxbase LoTW import-related dupes > found > > > Bill, > > I've been watching your many posts to the DXbase Reflector about your > LoTW saga. I hope that you are directing all of these data integrity > issues to the LoTW folks since none of the issues you speak about are > DXbase problems. They all involve invalid data coming from the LoTW data > source. In fact, it's only because DXbase incorporates a rigorous set > of validations that these issues are being detected and allowing you the > opportunity to realize that LoTW is injecting errors into some of your > QSO database. > > 1. Invalid IOTA formats. > 2. Invalid Mode designations. > 3. Canadian provinces in the US State field. > 4. Invalid grid designators. > 5. Invalid zone information. > > We, along with the makers of several other logging software products, > voiced our strong concern to the LoTW development team long ago that it > was critical for them to apply the ADIF standards and to implement some > data integrity checks. It's pretty obvious that our concerns have not > been addressed in the current deployment of the LoTW process. As time > goes by, data integrity problems will no doubt have a detrimental impact > on the entire LoTW effort for the ARRL since they are ultimately going > to have to face the fact that the LoTW database is full of erroneous > data. The LoTW process may well be the most secure and tamper proof > system ever known to mankind, but if the data it protects is prone to > error.... > > We do not mind folks using the DXbase Reflector to make others aware of > LoTW data integrity issues originated by LoTW, but please be careful > that you do not imply that these are deficiencies in DXbase because they > are not. Maybe there ought to be a reflector for LoTW where folks can > go and voice their issues to whomever is representing the LoTW system to > the public. We have lots of prospective customers review the DXbase > Reflector archives and we don't want them to walk away with a feeling > that these are DXbase issues when they are LoTW database problems. > > I would be very interested to know what the LoTW folks have told you > about these issues and what their plan is for addressing them. > > Thanks, > Jack > > > ----- Original Message ----- > From: "William H. Hein" <[EMAIL PROTECTED]> > To: "DXbase Reflector" <[email protected]> > Sent: Wednesday, June 16, 2004 9:47 AM > Subject: [Dxbase] Many, many more Dxbase LoTW import-related dupes found > > > As I scan thru my log book, I am finding lots of these (dupe QSOs > created during a LoTW import procedure), all seemingly from the 1995 CQ > WW 160m SSB contest, where I made a big effort (over 1000 QSOs). Just > noticed that the original loggings all have the exact frequency noted > (note frequency, not band which is 160 in both cases) and the mode as > LSB. The dupe QSOs, and there are at least a few dozen of them, don't > have the frequency field filled in and are all listed as USB. > > Perhaps this LSB vs. USB thing is the key? The imported QSOs are all > noted as USB, which is of course wrong. And LoTW does not distinguish > between USB and LSB, listing all SSB QSOs as simply SSB (is this an ADIF > standard?). > > 73, > Bill NT1Y > > > __ > >
