connection to jAlert lost

[EI4KF]

Hello Roland,

This case is really strange... Have tried to run Swislsog, WSJT-X and JT Alert as administrator? You don't have to worry to give administrator rights to a known software like these ones.

If you still have the same issues running all as admin, please disable HAMQTH reading and try. we have to found out whch is causing this but the TAB key not working is very strange.

Please I know I insist a lot but make sure you have added exceptions to WSJT-X, JT Alert and Swisslog in your antivirus, firewall and all other antispyware software.

I would need to do a remote session with you via Teamviewer to check carefully what may happen but this is a very strange issue.

Best 73

I do not want to interrupt Roland's thread and search for a solution, however in thinking about the issue I have that seems similar, though not necessarily the same, I did not think it appropriate to start a new thread that could well be duplication. So, this is what the problem for me is in the latest versions. I do not use JTAlert, only JTDX attached to Swisslog via UDP. Sometimes, maybe once in 5 sessions, Swisslog stops updating the QSO input window as I initiate calling a station in JTDX. It is as if some kind of synchronisation is lost. I have stable but slow internet. Sometimes it will right itself if there is enough time (for example I have been CQing for some minutes and no other call has been sent to Swisslog) but then if any logging takes place it is without the dB reports - RST-S and RST-R get the value of 0. But usually is it simply stuck and I have to add my QSOs manually to Swisslog at the end of a session. It does not help that the mode starts with RTTY even though in WSJTx/JTDX RTTY is not possible. I always see RTTY change to FT8, back to RTTY and then again to FT8. Why is this? During these operations, Swisslog appears to not do anything else so therefore queuing the next actions instead of moving briskly on. If JTDX or WSJTx is attached, Swisslog cannot know the mode initially but it sure is not going to be RTTY. I believe the UDP link should force the mode at FT8, only to be changed if a new mode notification is received (such as FT4). I too have checked internet activity and can see the requests to the online database but not necessarily in sync with the callsign reaching Swisslog and when the issue starts these requests are well out of time. Closing and restarting JTDX does not help. Only restarting Swisslog clears the issue. For me, this problem started with 5.99f.

[EA3GCV]

Hello Erik,

Seems the UDP connection is unstable in such case. But I'm unabled to reproduce this issue here. I use JTDX everyday with no problems. The only issue I experience from very time to time is the UDP link broken suddenly and I need to restart Swisslog. But when this happen there is no communication at all, is not as you related which seems a partial link failure. 

This is how the WSJT-X works:

- When the QSO Entry window is started (either at Swisslog atartup or when closing and open the QSO Entry window again) I need to read the following settings (user parameters) :
- Realtime entry
- Do not set transceiver mode

After linking to WSJT-X and receiving a callsign clicked in WSJT-X (that is, DX Call filled out) Swisslog enables the "Do not set transceiver mode" automatically (if not checked). This is mandatory if using transceiver control to set the current WSJT-X mode. Callsing and Locator is set in the QSO entry as well. If you are reading the locator from callbook databases and maidenhead matches from the one read from WSJT-X, Swisslog will set the 6 digits locator. If maidenhead doesn't match then the locator from WSJT-X is set.

When Log QSO button is pressed in WSJT-X or QSO is saved automatically in JTDX, Swisslog sets the Realtime entry off to allow set date/time from WSJT-X. Then all other fields are filled out then QSO is saved. After QSO has been saved, Swisslog restores the "user parameters" read when the QSO Entry is started (see my first explanation). This way Swisslog is set again with the initial user parameters even if the UDP link is active. That's why the mode field reads the transceiver mode again (if user have the Do not set mode from transceiver unchecked normally) and in your case shows RTTY because it should be the radio mode.if RTTY is not your radio mode, make sure you don't have checked the "Set mode according QRG Otherwise it will read mode according to band plan! 

It hay happen sometimes that these settings remain enabled (specially the Do not set mode from transceiver) in the next Swisslog session. The solution is, simple: uncheck this option, close and open, again the QSo entry window. This is the way to tell Swisslog: this is, my default setting to restore it when the UDP link if deactivated or after saving a QSO from WSJT-X. 

During status changes of WSJT- Swisslog reads Callsing, mode and locator from WSJT-X. When logging QSO Swisslog always read callsign,mode, date, time, QRG, Mode, RSTS, RSTR, Comments from WSJT-X then saves the QSO. This is all what happens if the UDP communication is right. That's why is very very important to add exceptions to Swisslog and WSJT-X (or JTDX) in your antivirus, firewall and similar programs. This is the only way to ensure these programs are not supervising and interfering the normal functioning of these programs and their communications. Otherwise there will be unexpected results.

Now I want to explain how the logging process works in Swisslog when saving a QSO, either when user press the Save QSO button or when it receives this order from external programs:

Swisslog starts all saving procedures but before finishing the save procedure, needs to process the realtime saving to the selected online services. At this point, I use multi-threading to speed up this process: Swisslog runs a separate thread for every online service enabled by the user. This means that even if you save in realtime in all online services supported by Swisslog, these operations are performed at once, because every online services uses a different thread. 
But before finishing the logging procedure, Swisslog needs to received the reply for every enabled online service to set the appropiated fields. If internet connection is slow or not consistent, the timeout defined on every online service comes into scene! If an error occurs or timeout is expired then Swisslog won't set the appropiated fields informing the QSO has not been saved in the affected online service. So if your internet connection is not stable or fast, I suggest to:

- Always disable error messages from all online services. This is a must when working linked to externañ programs such WSJT-X, to avoid dialogs which will interfere the logging process. I'm planning to display these error messages (if any) in a separate window instead a dialog window. This will show error messages without inteefering the logging process.
 - Set a, low, timeout value on the enabled online services. 15 seconds is the default value. 
- Disable realtime logging and upload your QSOs at the end of your session. This will speed up the saving procedure and maybe is the best way to know whether this is causing this issue or not. 

Excuse me for the long message but I wanted to explain how all processes work internally. Maybe this will help you to find out the source of this issue. Unfortunately I haven't received reports like this from other users and myself I use Swisslog with JTDX with no issues. If I can't reproduce here the reported issues, it's very difficult to me  to solve them. That's why I have explained you how the whole thing works. Maybe it will help. 

Some things are out of my control (such adding exceptions in antivirus) and must be performed manually by the user to ensure none of these programs are interfering the normal functioning of Swisslog and all programs linked with it. 

73

[EI4KF]

Hello Erik,

Seems the UDP connection is unstable in such case. But I'm unabled to reproduce this issue here. I use JTDX everyday with no problems. The only issue I experience from very time to time is the UDP link broken suddenly and I need to restart Swisslog. But when this happen there is no communication at all, is not as you related which seems a partial link failure. 

This is how the WSJT-X works:

- When the QSO Entry window is started (either at Swisslog atartup or when closing and open the QSO Entry window again) I need to read the following settings (user parameters) :
- Realtime entry
- Do not set transceiver mode

After linking to WSJT-X and receiving a callsign clicked in WSJT-X (that is, DX Call filled out) Swisslog enables the "Do not set transceiver mode" automatically (if not checked). This is mandatory if using transceiver control to set the current WSJT-X mode. Callsing and Locator is set in the QSO entry as well. If you are reading the locator from callbook databases and maidenhead matches from the one read from WSJT-X, Swisslog will set the 6 digits locator. If maidenhead doesn't match then the locator from WSJT-X is set.

When Log QSO button is pressed in WSJT-X or QSO is saved automatically in JTDX, Swisslog sets the Realtime entry off to allow set date/time from WSJT-X. Then all other fields are filled out then QSO is saved. After QSO has been saved, Swisslog restores the "user parameters" read when the QSO Entry is started (see my first explanation). This way Swisslog is set again with the initial user parameters even if the UDP link is active. That's why the mode field reads the transceiver mode again (if user have the Do not set mode from transceiver unchecked normally) and in your case shows RTTY because it should be the radio mode.if RTTY is not your radio mode, make sure you don't have checked the "Set mode according QRG Otherwise it will read mode according to band plan! 

It hay happen sometimes that these settings remain enabled (specially the Do not set mode from transceiver) in the next Swisslog session. The solution is, simple: uncheck this option, close and open, again the QSo entry window. This is the way to tell Swisslog: this is, my default setting to restore it when the UDP link if deactivated or after saving a QSO from WSJT-X. 

During status changes of WSJT- Swisslog reads Callsing, mode and locator from WSJT-X. When logging QSO Swisslog always read callsign,mode, date, time, QRG, Mode, RSTS, RSTR, Comments from WSJT-X then saves the QSO. This is all what happens if the UDP communication is right. That's why is very very important to add exceptions to Swisslog and WSJT-X (or JTDX) in your antivirus, firewall and similar programs. This is the only way to ensure these programs are not supervising and interfering the normal functioning of these programs and their communications. Otherwise there will be unexpected results.

Now I want to explain how the logging process works in Swisslog when saving a QSO, either when user press the Save QSO button or when it receives this order from external programs:

Swisslog starts all saving procedures but before finishing the save procedure, needs to process the realtime saving to the selected online services. At this point, I use multi-threading to speed up this process: Swisslog runs a separate thread for every online service enabled by the user. This means that even if you save in realtime in all online services supported by Swisslog, these operations are performed at once, because every online services uses a different thread. 
But before finishing the logging procedure, Swisslog needs to received the reply for every enabled online service to set the appropiated fields. If internet connection is slow or not consistent, the timeout defined on every online service comes into scene! If an error occurs or timeout is expired then Swisslog won't set the appropiated fields informing the QSO has not been saved in the affected online service. So if your internet connection is not stable or fast, I suggest to:

- Always disable error messages from all online services. This is a must when working linked to externañ programs such WSJT-X, to avoid dialogs which will interfere the logging process. I'm planning to display these error messages (if any) in a separate window instead a dialog window. This will show error messages without inteefering the logging process.
 - Set a, low, timeout value on the enabled online services. 15 seconds is the default value. 
- Disable realtime logging and upload your QSOs at the end of your session. This will speed up the saving procedure and maybe is the best way to know whether this is causing this issue or not. 

Excuse me for the long message but I wanted to explain how all processes work internally. Maybe this will help you to find out the source of this issue. Unfortunately I haven't received reports like this from other users and myself I use Swisslog with JTDX with no issues. If I can't reproduce here the reported issues, it's very difficult to me  to solve them. That's why I have explained you how the whole thing works. Maybe it will help. 

Some things are out of my control (such adding exceptions in antivirus) and must be performed manually by the user to ensure none of these programs are interfering the normal functioning of Swisslog and all programs linked with it. 

73

Hello Jordi, I operated this morning in the early hours with no internet and everything was smooth. I turned Internet on and eventually the problem started. At night my internet is download 20+Mbits/sec and upload 15+Mbits/sec so no issue with speed. I have the low timeout and error messages suppressed. I am now using 5.99b and not a hint of any trouble. Also I do not see the RTTY>FT8>RTTY>FT8 mode change in that version - it is much faster. Unfortunately I cannot continue with 599b because the DX Messages windows are too slow! Cannot win. It might be that computer speed has a bearing on it - my other computer has a problem but I will get it fixed and try it. It is a lot faster than my MB1.

[EA3GCV]

Hello Erik,

Did you check the Set mode by QRG setting? Which mode is your radio set when working FT8? Seems is serting mode by reading in the band plan otherwise I, don't understand.. I'm unabled to reproduce this issue here. I use SSB as radio mode and when linked to JTDX and a QSO is traspassed mode is set to the current JTDX mode.

Ok about internet conmection. In order to find out if the, realtime logging is, causing this in your internet scenario, please, try to disable realtime logging (with internet0on) and check if the issue is gone. Maybe I, will have to set a fixed timeout in the realtime routine when saving qso for these specific cases. Which timeout valie have you set? . But before applying any fix I, need, to ensure this part of code is, causing this.

Best 73

[EI4KF]

Hi Jordi,

My timeout is 5 seconds. The SDR mode for digital is DIG. My band plan is correct. BUT I may have found an error in the setup. It makes no difference whether Set Mode by QRG is checked or not when Do Not Set Mode From TX is unchecked. So I now have both checked and the mode starts at FT8 and no longer at RTTY. That may well help. I will need to test later. Thanks for your help.

[EA3GCV]

Hello Erik,

Just a reminder: I think you have some Dx windows open. Although I improved a lot the Dx window refreshing, if there is lot of traffic it still locks up other functions. Probably this affects all other communication and window and may slow down everything after a while. I only have a Dx window (filtered to display only worked, needed and new). This window must be used with care because it has this bad side effect due to its design. I hope to succeed some day implementing the v6 DX window...

Regarding the "Do not set mode from TX", normally this option must be unchecked. Swisslog enables it/disables it automatically when Logging QSO from external programs. It's transparent for user. If you keep it checked, if not working linked with WSJT-X and you are on CW, it won't set the right mode. Keep this in mind.

Best 73

[EA3GCV]

Hello,

I have been reading the HTTP component documentation used in Swisslog and I can see that by default, timeouts are "inactivity timeouts". That is: the timeout period is extended by Timeout seconds when any amount of data is successfully sent or received. According to this, even setting 5 seconds, if some data is sent or received it adds the timeout period again. I can change this behaviour to absolute timeouts, so if operation does not complete within Timeout seconds will be aborted. I think this is the behaviour I should set for the Timeout option in all HTTP operations.

I have uploaded a beta where I have applied this to all realtime logging operation:

www.swisslogforwindows.com/Beta/SwisslV5.exe

Download and replace the EXE in the Swisslog folder. Please let me know if it solves this issue or if you observe any enhancement.

In this beta you will see that the FST4 mode and 5m and 8 m bands are added automatically according to new ADIF 3.1.1 specs which have been published on 2nd September.

Best 73

[EI4KF]

Hello,

I have been reading the HTTP component documentation used in Swisslog and I can see that by default, timeouts are "inactivity timeouts". That is: the timeout period is extended by Timeout seconds when any amount of data is successfully sent or received. According to this, even setting 5 seconds, if some data is sent or received it adds the timeout period again. I can change this behaviour to absolute timeouts, so if operation does not complete within Timeout seconds will be aborted. I think this is the behaviour I should set for the Timeout option in all HTTP operations.

I have uploaded a beta where I have applied this to all realtime logging operation:

www.swisslogforwindows.com/Beta/SwisslV5.exe

Download and replace the EXE in the Swisslog folder. Please let me know if it solves this issue or if you observe any enhancement.

In this beta you will see that the FST4 mode and 5m and 8 m bands are added automatically according to new ADIF 3.1.1 specs which have been published on 2nd September.

Best 73

Hello Jordi,

My database is compressed. All in all, everything is as optimised as it can be. I have installed the beta. It can take several sessions before the issue shows up but it has not done so yet. However, it does seem much better. I no longer get the RTTY > FT8 mode changes and the logging procedure seems far more smooth than before. Currently my internet is stable but slow. I will test further but I would say that your change is for the better.

[dk4rh]

Hi Jordi,

sorry - also with the new version issue was two times.
Have ordered a hamcall subscribtion and changed to those. Will see, if it is running in those way.
Is e quite nice feature to load the detail data of the user...

[EI4KF]

Hi Jordi,

sorry - also with the new version issue was two times.
Have ordered a hamcall subscribtion and changed to those. Will see, if it is running in those way.
Is e quite nice feature to load the detail data of the user...

In my case, the beta does improve things but not solve them and eventually I get the same failure. One thing I have found: if I set in Options 'Do Not set Mode From TX' and 'Set Mode from QRG' then everything is perfect on SSB and CW. When I change to DIG mode on a FT8 frequency, Swisslog shows FT8 in the mode box. But when I launch JTDX, it forces both those settings unchecked and the mode box then incorrectly shows RTTY. Then the lottery starts: mode has to change from RTTY to FT8 (and occasionally it does this multiple times) and whilst usually Swisslog survives the stopping of all other functions during this, somethimes it loses sync and that is the end. The beta has reduced the number of instances of this but it happens still. After closing JTDX, those two settings do not revert to my choice and so affect future operation of Swisslog even on other modes.