Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
BanMap (D)
01-05-2018, 01:09 AM,
#1
BanMap (D)
Hello Jordi,

Is very good to have the sign (D) to identify dup calls, however I think that it could be more evident if we could change the (D) into a highlight color only.

Sometimes the (D) could create some "noise" especially when the band is crowded with several calls.
Have a nice week.

73 Manuel Fernando
Reply
02-05-2018, 08:59 AM, (This post was last modified: 02-05-2018, 09:25 AM by EA3GCV.)
#2
RE: BanMap (D)
Hello Manuel,

This is, again, a matter of user preferences. When I added this option I was thinking about all possibilities and what was the easiest and best way to implement it in the code. There are already too many colours to show the statistics status (Confirmed, Worked, Needed, New and not needed). Adding a new colour it's not such easy as could be considered from an user point of view. Even in a crowded band map, the (D) highlights over the rest of spots. I think you can see better a dupe this way instead of changing the spot color. It's very difficult to make everybody happy! But I think as it is now it's the best solution (and easiest solution from a programmer's point of view) instead of creating another colour. I can't change the colour of the (D) only because it's a label cointaining the spotted callsign and I add the (D) when dupe. To do this I would have to create a separated label and due to the complexity of the Band Map code I would have to rewrite the whole function (which I spent more than 9 months to write it).

You know I hear all user's suggestions and I try to implement as much as I can. Only if many users request this, I would consider to add another colour for dupe spots in the future. But this will require to rewrite the band map code which it's not an easy task at all. I think the big effort it's not worthwhile when as it is now fulfills this need for most users.

Currently I prefer to focus my efforts to other more interesting (and time consuming) functions now such full eQSL synch supporting multicallsign/stations (the same as LoTW synch does). This function has been requested by many many users! But it's really complex to integrate in the Swisslog code. Remember that I'm not the original programmer. I'm trying to adapt the LotW synch function to eQSL which it's not easy at all. Just to have an idea: I started to build this function 3 years ago. Little by little, I have been adding more "bricks" as soon as I have had more knowledge of the Swisslog code and how Walter programmed the whole thing. Now I'm totally focused working on this function and having lots of headaches! When I started to develop Swisslog, my main goal was to add the eQSL full automatic synch in the future. Without any doubt, this has been the function required by most users. I think now I have all the knowledge to afford this big challenge to me and I would like to release a new version this year implementing this unique function you won't find in any other logging program ;-) I'm sure many users will like this function, if i'm able to succeed! Afterwards, if i suceeded, I have another big challenge which is to release version 7. Version 7 will be the final result of mixing all what i have done in version 5 but in the version 6 code (which I was able to restore, because it was corrupted). This, that sounds very nice, it's like building a puzzle of 25000 pieces! As you can see I have very challeging and interesting projects for the future of Swisslog and this requires looooot of time and effort.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
02-05-2018, 12:18 PM,
#3
RE: BanMap (D)
Hello Jordi

Many thanks for your explanation! 

Yes you're right, sometimes we think about little things, without seeing the complete and complex reality of the  project. Because SwissLog is so good, sometimes we try to go a little far... so my excuses.

About your present challenge it is a very big one! 
Thanks to your effort that I deeply respect, Swisslog got  a good stage.

I am afraid to be inconvenient, however I would like to refer one point, now that you are working on this challenge, (LOTW/EQSL) perhaps it would help for future... I am talking about the credits DXCC and also IOTA, perhaps the code you are developing now, and in case you think to implement it in future, perhaps is a good time to look at it...

Only a thought for future purpose, just in case it can help…
Have a nice week and thanks, thanks very much for your work

73 Manuel Fernando
Reply
02-05-2018, 02:06 PM, (This post was last modified: 02-05-2018, 02:09 PM by EA3GCV.)
#4
RE: BanMap (D)
Hello Manuel,

Suggestions are always welcome, just I wanted to inform you about the whole thing so that you can understand me better.

Regarding credits, if the downloaded file from LoTW would contain the credits fields, Swisslog is now able to read them. However, credits are contained in a separated file that must be downloaded apart with important lack of information. This is a real QSO record of this file:

<CALL:6>VE1BLX
<QSO_DATE:8>19900101
<APP_LoTW_MODEGROUP:4:S>DATA
<APP_LoTW_MODE:4:S>DATA
<BAND:3>10M
<DXCC:1>1
<COUNTRY:6>CANADA
<APP_LOTW_DELETED_ENTITY:2>No
<CREDIT_GRANTED:24>DXCC,DXCC_MODE,DXCC_BAND
<APP_LoTW_CREDIT_GRANTED:65:S>DXCC-M,DXCC-M-HR,DXCC-RTTY,DXCC-RTTY-HR,DXCC-10,DXCC-CHAL,DXCC-5B
<APP_LoTW_DXCC_APPLICATION_NR:5:S>00000
<APP_LoTW_DXCC_PROCESSED_DTG:19:S>1998-02-04 06:01:00

As you can see QSO record contains QSO date, band but mode is PHONE, CW or DATA. This is an important problem! for PHONE is easy to match because I can assign PHONE = SSB, CW is OK but what about all digital QSO where LoTW assign DATA as mode? Which was the real mode of operation?

Let's see and example: Just suppose that I worked the same station VE1BLX on the same date and band but at different time, one QSO on RTTY and other on FT8 (at different time). Which Swisslog QSO is the real credited? The one worked on RTTY or FT8? I know there won't be lot of cases like this. That's why I think that these fields should be included in the LoTW downloaded output file where all QSO data is included. If QSO time is included in this file it would be perfect to match.

I left my feedback in the LoTW developers group on 22nd february asking the possibility to add the credit/submitted fields as an option in the LoTW query. But I didn't get any answer... However, I will add it to my wish list and I will try to work on it when I finish the eQSL synch function to see if I found a solution.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)