Polski Związek Krótkofalowców

 

Polski Klub Radiovideografii

Navigation:  AWARD_SECRETARY project and its purpose >

Control of mistakes made by users at various stages of the calculations

Print this Topic Previous page come-back to begin of chapter Next page
Expand all elements   Callapse all elements

Most errors produced at the interface Logger --> AWARD_SECRETARY. Unfortunately, many users do not care about the correctness and integrity of the data logger and then from there are many mistakes and misunderstandings. And enough to occupy approximately 10 sec after each QSO. Lack of this time when do QSO , then will be results in the cost of many hours to restore the proper data.  AWARD_SECRETARY is not the type program of "SESAME - open yourself - do me a notification for a diploma." Remember - "junk data input" - this will also receive "junk results."

For errors that controls the program AWARD_SECRETARY at different stages of creating award are:

1.Errors in the input data in the file imported from the logger's .
2.Errors in the calculating of entities and CQ and ITU zones in the file imported from Logger-a
3.Errors in the file for the state start for the award .
4.Errors may arise as a result of manipulation, ie, copying, and then restoring the main table QSOS_AWARDS or awards .
5.QSOs control when updating award, choice QSOs more optimal.
6.QSOs rejected due to the lack of such a QSO in the log and the lack of a QSO which would it replaced - in brown color
7. Alarm - lack QSOs which has already reached the state AWARDED . Lack QSO which would it replaced - Yellow color
8.Alarm - QSOs which has already reached the state AWARDED. There is QSO which can be replaces - the color purple

 

1. Errors in the input data in the file imported from the logger's

The description of these errors is described above. and where there are no errors and still the program stops in a some error . I recommend then proceeding as described in this place. At this point it will be possible selection for show QSO's in a window and then we'll see at what QSOs will stop the program and then in this QSO or before you can seek an incorrect value in a field. This is in this the case definitive method for seek where is error , when all other methods not show any errors.

2. Errors in the calculating of entities and CQ and ITU zones in the file  imported from Logger-a

The description of these errors described above. The calculation for  entities CQ and ITU zones can be taken from the Logger or calculated in a AWARD_SECRETARY under CLUBLOG . what has been described here .

3. Errors in the file for the state start  for the award .

These errors are relate to amateurs who have already obtained  award ,  and a further calculation (endorsement) entrust AWARD_SECRETARY program. Rules diplomas calculations based on a starting file and exceptions when it is not possible to calculate from the state start file prevously decribed. Below is described restoration  for award  SPPA from the state start file for counties (by polish powiaty) .From  one of my friend I  received his file of ADIF log produced by his  logger. Also received a file  xls for Excel or Open Office Calc. It is a form  recommended by the publisher award SPPA .  Unfortunately this is the file produced by hand, so you should expect a lot of mistakes. On the basis of this file was never made application for a diploma SPPA. In fact, I do not recommend the use of such a file  if it is not approved as a starter for my program. However, this file perfectly suited to show the problems and how AWARD_SECRETARY will solve such problems. First, I load the ADIF with QSOs collection to a table  QSOS_AWARDS . as decribing in this section. You should use button

.

Then you need to generate data for Polish awards based on IN_POLSKA.DLL module described here. The program AWARD_SECRETAY need the code and the name of the municipality. district and province, so can compare this data with  data given in a start file .

After loading the resulting start file received from a friend in XLS format by Open Office Calc I get this :

SPPA data for the diploma obtained in the format
XLS (Open Office Calc). Indicated corrections
and errors which should be corrected

After performing the operations described in the picture should still replace the column Band frequency band symbol eg. 3.5 (Mhz) to 80M according to the standard ADIF .. Performs this  by choosing from the menu EDIT - Find and Replace. Other data that is the wrong date and time format will be automatically corrected by AWARD_SECRETARY. Column County although is in a Polish signs not need  be converted to ASCII characters, since  program will convert the name to its own name. Important is only the column SPPA  Code. Why I use only ASCII characters in all  program. Well, so that the program will be used in a variety of different languages Windows tool. Polish signs were there that certainly appears badly, and that could cause it to malfunction and stop working

Search and Replace symbols
for bands

Similarly, we should convert 7 to 40M and also for other bands.

Then choose Save As from the menu, and as the output file type, select the type of CSV

Write output for
SPPA diploma in CSV format

Selecting write providing record
given in double quotes ""

After saving the data in CSV format of the form will look like this

"CODE_WOJEW","DESCRIPTION_WOJEW","QSO_DATE","CALL_","TIME_ON","Mode","Band","SPPA_CODES","DESCRIPTION_SPPA"

"B","LUBUSKIE","3.5.2007","SP3KCL",514,"SSB","80M","GP","Gorzów Wielkopolski (grodzki)"

"B","LUBUSKIE","23.12.2011","SQ3LLJ",2215,"PSK31","80M","KD","Krosno Odrzańskie"

"B","LUBUSKIE","24.3.2008","SP3BKM",648,"PSK31","80M","NL","Nowa Sól"

 

From this text you can copy the column names.

However, in an array in Open Office Calc data will look like

 

The final appearance of the data in the table
OpenOffice Calc

Now, these data should be read as the state start file . The procedure for loading the startup file is specified here.

May appear to us screen in this form :

Screen showing the QSOs that are not included
because of differences in relation to the log in
the table QSOS_AWARDS

We see that at 122 QSOs 14 QSO was not included. But it is as a result of this, and these data have never been used and approved in award  SPPA. Do not go out now from the program . We now need  look in the log for each QSO differences. To do this, go to the tab no. 1 Main database of QSOs . and look there by the callsign . If there is a difference here compared to the data from the state start file  , you must do corecting ,  the best in the Logger or in a file start. If the difference is due to different allocations SPPA_CODES then you need to find the difference in a module IN_POLSKA.dll as described here. Here we have the ability to look after you enter callsign in the box as shown below

The basic condition for the adoption the QSO from the state start file is :

QSO from the startup file must exist also in the main log table  QSOS_AWARDS.  Must match all of its parameters, ie. CALL,  DATA_QSO, BAND , MODE DXCC_NO, and in the case of a award for zones , also CQ_ZONE and ITU_ZONE.  When it is awards like polish SPPA, PGA_H, POLSKA_MIXED must also match the symbols and names of municipalities, counties and provinces

       

After all corecting and saving award we should  obtain screen like below

The screen after corecting the data for
all QSOs for award SPPA

 

4. Errors may arise as a result of manipulation, ie, copy and then reproduce the main table QSOS_AWARDS or awards  .

These errors occur if you call the existing award for the purpose of look  It is then in viewing mode.

These errors if you're running properly AWARD_SECRETARY and correctly  created a major table and make a  update the table in the correct manner , never will be show. As a result of some manipulation may change Identifier QSO , in short ID_QSO in the main table QSOS_AWARDS . It is recommended that in the  Logger never make QSOs renumber. It is true that AWARD_SECRETARY is protected against such situations and their ID_QSO not accept from Logger's . ID_QSO itself is not used to definitively conclude that it is the QSO, which is edited. . For this purpose another field called CRC strings - which is the sum of the critical fields QSO strings, so that ensures the uniqueness of the QSO. ID_QSO however, is used in other places in the program and must be correct. The way in which this condition can occur with a award that ID_QSO from the award for the previous calculation is incorrect and inconsistent with the current ID_QSO from an table  QSOS_AWARDS describe here in my example for award  SPDXC.

My first calculation for this award was made in 2008 year , and was made using program SPDXC_Baza by SP7DQR .  Testing this files to the fact that most of the QSO is marked in green and was made based on the state start file derived from this program.
.In 2009 year , also made next  supplement based also on SPDXC_Baza by SP7DQR.
On 23.11.2012 I made the update of this award but based on my program AWARD_SECRETARY. I used to update the file with QSOs from logger start my log until to date  21.11.2012 . Such a state of ID_QSO was recorded in a  MYSQL table for award  SPDXC.
Later, however, carried out the test on different test files ADI. However, the state for award  SPDXC I was copied using the function backup in the  AWARD_SECRETARY. Probably in the meantime I changed QSOs in Logger32 and would add QSO manually. This caused that the new data downloaded began having other ID_QSO.
Then after tests I restored  previous state award  SPDXC as it was approved by the manager diploma. Hence why almost for each QSO is different ID_QSO.

 

Errors in viewing mode for IDentificator_QSO   ID_QSO

 

So now I need to save the data by accepting OK within the message which show up on the screen.

 

5. QSOs control when updating award, choice  QSOs more optimal

With the update award by button     program is in a award update mode .  Very often, when you send award and check out QSL cards we see a QSO that have badly counted entity and bad DXCC_NO . So for example, I had a QSO with UI8IM classified as Assiatic Russia DXCC_NO = 15. Currently Logger32 this callsign count  as Assiatic Russia. But as I looked at the card from the QSO dated 1972-08-23 I  see , that  this was then Uzbekistan DXCC_NO = 292 . Sou . I  was  changed for this QSO DXCC_NO from 15 to 292 in Logger32. I produced a new file of adi, and I've done update table QSO_AWARDS.  It so unfortunately for many countries. The solution to this problem is to  recognition of belonging entitie not only by the prefix or the entire character , but also on the basis of the QSO_Date. And here we see the need for calculations from  CLUBLOG. Below are the update for the award DXCC_5BANDS. Obtain screen like as below

Appearance after completing the award - appeared QSO
swapped and not included

 

QSO control, swapping of QSO more optimal ,
check the countries belonging to the award
DXCC_5BANDS for update mode

 

Bellow is decribed possible variants of program behavior at the time of inspection and substitution QSO:

1.Replacing bad QSO previously classified or conversion to a more optimal - marked in aqua

There are possible  three variants :

 

1.1 Replacing QSOs badly  previously classified

OK - that's examine what has been swapped. At the bottom above table, we have shown QSO not included As a first QSO occurs there QSO with EA6AZ included then to the DXCC.  Therefore look to the 1st bookmark , ie Main base QSO and let's find there QSO with EA6AZ. We will get

QSO not included due to lack of confirmation<br>
QSL card. There is only confirmed by LOTW. <br>
Previously it was allowed, but not now not .<br>
If now this QSO had the status of a QSO approved<br>
GRANTED - then the program does not swapped this QSO

QSO not included due to lack of confirmation
QSL card. There is only confirmed by LOTW.
Previously it was allowed, but not now not .
If now this QSO had the status of a QSO approved
GRANTED - then the program does not swapped this QSO

As the second occurs QSO with RK2FWA RTTY in the bottom of the table. It has been replaced to  the QSO with UC2AAE    CW, which conforms better to the principles of optimization, because the change band is do also change the emission - see tactics Optimization

Replacement QSO more optimal, since changing band
also change emissions for the next

There may also be situations and previously QSO was classified as a wrong  entity that is NR_DXCC, and now is present correct result of its correct assessment because correct it on CLUBLOG. QSO was not included, and in return takes another QSO for example, as stated below

We see that UI8IM has DXCC_NO = 292,  and it is UZBEKISTAN and is consistent with the QSL card.<br>
Previously it was a QSO with UI8IM erroneously classified as DXCC_NO = 15 Assiatuc Russia.<br>
Therefore, I made changes in a Logger32 to DXCC_NO = 292

We see that UI8IM has DXCC_NO = 292,  and it is UZBEKISTAN and is consistent with the QSL card.
Previously it was a QSO with UI8IM erroneously classified as DXCC_NO = 15 Assiatuc Russia.
Therefore, I made changes in a Logger32 to DXCC_NO = 292

Do not be surprised, therefore, that it is now this QSO was not now recognized and now was turn to another QSO with a station UA9CAZ

QSO with UA9CAZ adopted in exchange for old QSO with UI8IM previously classified badly

1.2 Replacing QSO to more optimal at the time of the update

In the following screenshots due and they were made in a previous version program , the color aqua was changed to green color . The current version is the color aqua

Well - but  there are the question -  if at the time of the update  program does cost optimization and replaces the old QSO to the new QSO better fulfilling the terms of optimization. ?? . General can be said that with the change of the band should change emissions. It is not always possible. The principle of substitution described above.

First look the previous state  before you make the update .

 

State award BANDS DXCC_5 before updating
for DXCC_NO  = 21 and 27

After updating the state in the table looks.

BANDS DXCC_5 diploma state after the upgrade
for DXCC_NO (or NR_ADIF) = 21 and 27. We see
QSO that were changed to a more optimal

 

Total QSOs was changed = 70 -8 = 62 QSO .

Because I want in the next next section show exceptions to this rule optimization - not do now save award DXCC_5BANDS.

1.3 Exceptions to the principle of optimization

The overriding principle on this rule for optimize cost is a general rule that if you already have accepted status QSO as AWARDED, what mean , that for check this QSO  is has already incurred the cost , then this QSO  is not override - even if it was been found the QSO better fulfilling the terms of the optimization.

In order to check whether the program actually does this  - you would have to make for QSO swapped before for  a station EU1PA QSO on 40m SSB has reached the state  for  award DXCC_5BANDS   as  AWARDED (in my program D_AWARDED ) in a  another award. Here you need to select a diploma in  SSB, so DXCC_PHONE. When you select this award for calculate and save the final state get that state for this award .

 

Calculations for award DXCC_PHONE and causing
the state approval ie DATE_GRANTED
for all QSOs in this award .

Now we will update DXCC_5BANDS award , and saving this award . Will  get :

Perform the update for DXCC_5BANDS.
We see that the exception to the rule discussed optimization
for QSO of already approved working properly

 

Note that the program now exchanged 51 - 7 = 44 QSO and not 62 as it was previously

 

 

6. QSOs rejected due to the lack of such a QSO in the log and the lack of a QSO which would it replaced - in brown

Let's look at all that QSO was not now adopted - so totally rejected. Look at the bottom of the table scrolling bar until you see the brown row

QSO with UC2WAE - there Kazakhstan , was full rejected - brown color

QSO with UC2WAE  Kaliningrad on the band  80 M emission CW was now been rejected

Check in the tab Main QSO database , where this QSO  occurs

QSO z UC2WAE have anothers entity BELARUS not<br>
Kaliningrad as was previous

QSO z UC2WAE have anothers entity BELARUS not
Kaliningrad as was previous

.

7. Alarm - lack QSOs which has already reached the state AWARDED . Lack QSO which would it replaced - Yellow color

Alarm concerns QSO which has already reached the state AWARDED in the previous and despite the fact the current lack of it accrued. Should be regarded as an alarm that you have something wrong. To be sure, please check the QSL card. The reason may be the fact that after the completion of the adoption of the QSO and the award  delteted it , or you was changed the parameters so that it is a QSO with another country. This situation never during normal operation and use of the program should not happen, because QSOs before sending the application for a award should be checked with the QSL. For me this situation , in the time testing not happened..

 

 

8. Alarm - QSOs which has already reached the state AWARDED. There is QSO which can be replaces - the color purple

 Alarm, which refers to the QSO what is reached the state AWARDED  , but in a present calculation it is lack .  It is true that there are present another QSO , what can replacing the old  QSO but it does not justify this situation. Be sure to check with the QSL card. The reason may be,  the fact  of deleting this QSO from the log or the parameters have changed,  so that it is a completely different entity . This situation during normal operation and use of the program should not never happen, because QSOs before sending the application for a award should be checked with the QSL. For me, this situation occurred for diploma DXCC_MIXED (during testing), which had previously  put  DATE_GRANTED  , so QSO was approved (artificially by me)

 

The state-award DXCC_MIXED with QSO approved
- the state QSO AWARDED

Then I chose button Update award . I received.

Update DXCC_MIXED diploma. 3 QSO have the purple color QSO was already
the state AWARDED ,  but it was replaced with another. Besides being one QSO  in yellow, because it in a CLUBLOG QSO is now counted to another country

Look to QSO with station UL0P/UZ9FWA in the first bookmark

QSO with UL0P / UZ9FWA has now DXCC_NO = 130, ie Kazakhstan and previously had DXCC_NO = 292, <br>
Uzbekistan..I checked QSO QSL card and found that a previously was bad  account .<br>
So I had previously incorrectly set country. If I was checked QSL before shipment notification ,<br>
this I would certainly detected

QSO with UL0P / UZ9FWA has now DXCC_NO = 130, ie Kazakhstan and previously had DXCC_NO = 292,
Uzbekistan..I checked QSO QSL card and found that a previously was bad  account .
So I had previously incorrectly set country. If I was checked QSL before shipment notification ,
this I would certainly detected

 

Navigation:  AWARD_SECRETARY project and its purpose >

Control of mistakes made by users at various stages of the calculations

Print this Topic Previous page Come-back to the begin of chapter Następna strona
Expand all elements   Collapse all elements