Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
01-05-2020, 11:14 PM,
#11
RE: IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
Hi Jordi,
Thank you for the reply.
I did read all the instructions and I am aware of the Telnet support you are referring to. You are correct it is easy. Nowadays I am most of the time at home because of the pandemic and in the last week I spent quit some time to learn about Swisslog. It is great!! Love it! Several of the features are great. Nevertheless I am having my problems with running it smoothly. I was using in the past HRD and N3FHP ACLog but now I would like to switch to Swisslog.
I am having lot of crashes and that worries me. Often after I close the program voluntary or involuntary I have to reboot the computer to be able to restart Swisslog. There were times but more with the previous version when I had to reload the program. I am not a programmer, but sometimes I had the feeling Swisslog would be overloaded and I would see some of the windows flickering. I thought when I turn off CW Skimmer, Swisslog would calm down, but I would still have to restart the program to work well again.
I was playing with the clusters and I did see your warning about RBNs. Does it mean that a program like the Aggregator cannot be run together with Swisslog?
I love CWSkimmer. It gives me imminently information of the stations my antenna can hear and decodes the callsigns before they show up on a cluster. Integrating CWS with Swisslog was a great idea. I was asking Scott N3FJP and Alex VE3NEA to do this with other programs in the past before I knew about Swisslog, but was not successful. I wish Tom N1MM would interface it. If you have an idea how one could do it please let me know.
I downloaded SV2AGW and I followed your instructions "Configure Packet Program. I think it is working. I see that SV2AGW is connected to UNpronto. I also connected DXTelnet to Swisslog but found that this was overwhelming the program and it would after a while no work. The WinKeyer would start to stutter. After I discontinued DxTelnet from Swisslog and it seems to do better. However I don't really understand what feeds the DX Messages window. When I open the Packet Monitor Window is says Disconnected on the top. If I press on the con button a small window opens up asking for a correct string of the DX Cluster, but it seem it does not matter if there is anything in that field. Sometimes I was not able to open the Packet Monitor Window and it would refer me to SV2AWG that controls it evidently.

On a other subject I tried to do LOTW and eQSL synchronization. However it completely destroyed my databases. There are now about 3K more QSOs in my LOTW database than I truly have. My QRZ data base which downloads everything from LOTW us now doubled. There must be duplicates, but I cannot figure it out because they don't look like duplicates. Some of the fields are different and some not. How do I know which is correct and which not. The staff at QRZ cannot help. UTC time difference is -5 in Boston but because of summer savings time it is now -4. I saw that Swisslog does not consider it. Regarding my QSO databases I don't know what to do. I was keeping it up regularly but now it looks they are destroyed. LOTW does not delete anything.

Tahk you,
73, Alex
Reply
02-05-2020, 12:23 AM, (This post was last modified: 02-05-2020, 01:02 AM by EA3GCV.)
#12
RE: IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
Hi Alex,

First of all, it's really very important to add exceptions to Swisslog to your antivirus and your firewall! Unfortunately there are many of them blocking or slowing down regular functioning of Swisslog. Also add exceptions to CW Skimmer and all ham radio programs! You will avoid many issues! Ham radio programs do many things: TCP/UDP communications, DDE links, internet outgoing/incoming connections, etc. Antivirus look out too much this activity. Moreover, most free ham radio applications are not digitally signed (a digital certificate cost a lot every year!) and antivirus look out much more unsigned applications. That's the reason you have to add exceptions. Also add exceptions if you have any Antimalware software.

Secondly, install latest Swisslog version 5.99g (in case you still use 5.99f).

Why do you use SV2AGW? If you use the integrated Telnet support, that's all!! This is the source of spots for the DX message / band maps windows. Go to Options / Connection to packet programs and select NONE in the Selection tab. This option is intended to connect to clusters via radio. Nowadays we all have internet connections so there is no need to use these programs. The Disconnect button will disappear in the Dx message window.

Regarding the LoTW/eQSL synch: if you performed the synchronization by using the LoTW/eQSL synch functions of Swisslog, it's impossible to add new QSO into your database!!! The Lotw/eQSL synch functions are absolutely safe. Uploads the existing QSOs in your Swisslog database into LoTw/eQSL and compare your QSOs with the confirmations received in LoTW/eQSL (to set the appropiated LoTW/eQSL Recevied fields). But it doesn't add any QSO!! If you have lots of new QSOs, I guess you have imported the LoTW/eQSL ADIF file into Swisslog and you don't have to do this. Keep in mind that when importing QSOs into Swisslog, Swisslog doesn't import dupes (the import function will give you a detailed report). But dupe means: same call, same date, same time (at exact time including seconds!!), exact band and exact mode. Look this example:

-You already have this QSO in your Swisslog database:  EA3GCV 01/05/2020 22:33:45 14MHz FT8
-You are importing an ADIF file containing the same QSO but time doesn't contain seconds (time in ADIF file is 22:33). Swisslog won't detect it as dupe because time is different!. The same would happen if time would be 22:33:40. Summing up: Time must be "exact" in order to detect QSOs as dupe, otherwsie a new entry will be added into the database.

Unfortunately it's a common problem because not all contest/logging applications uses hh:mmConfuseds as time format (many still uses hh:mm, ignoring seconds). The same happens with online services! LoTW uses time format including seconds while eQSL doesn't! This will create a big bundle if you import the LOTW ADIF file and also the eQSL Outbox ADIF because it will create 2 entries for common QSO in both files! The only QSOs that will be marked as dupe would be those having 00 as seconds (i.e.: 22:01:00 against 22:01) because is the same time although time format is different.

Fixing this will require you have to delete manually the "extra" QSO. Don't care too much if you have 3K more QSOs in LoTW. You can't delete them and practically it won't create any issues. eQSL allows QSO deletion but it's a big work! So the only place I recommend to do the clean-up is in your logbook database. Send me your Swisslog database and I would check if I can find a semi-automatic way to delete those "extra" QSOs. But I can't promise you anything.

Regarding UTC difference: although you have to set a time difference while defining your MyQTH, Swisslog will always check at startup the UTC difference defined in Windows with the time difference defined in your MyQTH. So when summer time is applied, Swisslog will release a warning informing user that the time difference defined in your MyQTH doesn't match with the one defined in Windows, and will prompt user to choose which one to use. Normally you have to use the UTC time difference defined in Windows. So don't worry about this and use the Windows Time difference when asked.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
02-05-2020, 11:26 AM,
#13
RE: IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
Hi Jordi,

It works Smile Thanks... and sorry for not find the solution by my self.

Best regards
Lucas
Reply
02-05-2020, 03:49 PM,
#14
RE: IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
Hi Jordi,
Thank you very much for your reply.
I have followed your recommendations and added exceptions for Swisslog and any other ham programs I am using to my antivirus soft ware. I don't have a fire wall installed on my computer.
I am using the latest version of Swisslog. 5.99g
I discontinued in Connect to Packet Program everything and removed SV2AGW . Initially as instructed I was reading your manual and one of the options was Packet trafficking. I had no experience in it and wanted to try it out. Spent a lot of time and exchanged many emails with SV2AGW, but was never sure what was going on and which part was working. Well now it's off. Waisted another $50.
Last night few contests were on. I use N1MM for contesting and it works great. I am using Telnet and receive spots and I have WintelnetX from K1TTT where I have several clusters connected like W1VD, W3LPL, K1TTT, W1NR and my local CWSkimmer. They all feed through WintelnetX into my N1MM. Unfortunately CWSkimmer is not interfaced like in your program so I have to use copy/paste when a spot shows up on my Skimmer before it comes up from one of the clusters.
I don't use your program for contesting. Last night I turned it on after I made all the corrections that you suggested because I wanted to look up the ITU number of one of the stations in Europe.
Unfortunately to my disappointment Swisslog was not doing well. WintelnetX was off. N1MM was off. I used your Telnet Control window and connected Swisslog to W1VE. There were many spots coming from W1VE. There are many stations on the air on a busy weekend. It was very soon evident that Swisslog was overwhelmed with the W1VE input. The windows would flicker, and I could not move any of the windows. Swisslog would shut down. It looks that the DX Message window in Swisslog is eating up all the energy of Swisslog to be able to function. Please understand I am not a programmer and I cannot explain it to you in a programmer language what is happening, but it is obvious. When I disconnect Telnet server in Swisslog everything works well. Also, I had 4 Band windows open to be able to see what is the activity on each band. When under Band/Mode Selection I choose All Swisslog would go down even faster. If I click on any of the other options in Band/Mode Selection only few spots on each band would show up, while my Skimmer would have more spots at the same time. Another thing that I don't understand.
I don't know if there is a solution to all of this?
Thank you for your help.
73, Alex
Reply
04-05-2020, 06:24 PM, (This post was last modified: 04-05-2020, 06:30 PM by EA3GCV.)
#15
RE: IMPORTANT!!! READ THIS BEFORE YOU UPDATE SWISSLOG
Hi Alex,

Yes, I'm aware of the problems of the DX message window when lots of spots are coming. That's the reason I explicitly indicate in the documentation that you can't use Reverse Beacon servers. 

The reason to use Dx message windows and band maps are to apply filters to the traffic to only see what you need (Needed, New and worked is probably the best option). The "all" option when lots of spots are coming are not practical at all. Firstly because you allow entering lots of spots not needed (the ones which are already confirmed) and secondly you won't have time to pay attention on them because window will scroll too quickly. So why overloading CPU unneccesarily? If band is very crowd, is a must to disable the "All" option in the DX message window, otherwise you will experience problems like you describe. Band maps are able to handle much data even if you have many of them. This also depends on the number of QSO in your logbook and your computer. I have tried to improve in the code the performance of the Dx window as much as possible. But there is this "limitation" when band is very crowd. Once you know this, it's easy to solve: select "New, Needed and worked". Dx window offers the advantage of being able to display statistic status for several statistics at once. On band maps you can use only one statistic but it offers a better graphical view of the selected band. But the real goal of these functions is to display what "user needs" for a specific statistic (award). If you don't mind the statistic status and prefer to display all spots, then you have to use the Telnet windows. These windows won't be overloaded because it's plain text and any spot is checked against your logbook to know the statistic status. This is what Dx window offers (despite other interesting function such tuning, turning antenna or entering QSO directly from spots). But this extra function to display the statistic status needs lot of CPU power and the DX window grid component has it own limitations.

Most logging programs only allow a single band map (if they provide this function) and a Dx window. This is perfect to avoid overloading your computer. Swisslog offers the possiblity to have as many as you like but always according how powerful is your computer, the number of QSOs in your logbook and the filters applied. Once you know this, you have to keep a balance of what you want and what your computer supports to decide the filter to be applied on every function. Use band maps for better performance. I use 4 band maps (monitoring 4 different bands, displaying ALL spots) and only one DX menssage window, but filtered to "Needed, new and worked" and works very well. I have a 1st generation i7 (from 2007) and 8Gb. I also have a WSJT-X Band Map which also needs a powerful computer because it has to handle and check data very quickly on FT8 (much more on FT4!). So here it's also a must to select "Neeeded, new and worked" if band is very crowd.

For contesting, use a good contest software (like N1MM). After the contest, export contest QSOs into ADIF then import them into Swisslog. This way you will take profit of the best options.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)