Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Beta released on 22h June 2022
15-06-2022, 09:17 AM, (This post was last modified: 22-06-2022, 06:51 PM by EA3GCV.)
#1
Beta released on 22h June 2022
Dear users,

I have released a beta including the following improvements (latest changes highlighted in boldface):
  • Corrected: S-Meter: Yaesu FT-920 didn't work.
  • Corrected: S-Meter: when windows was set standalone the window was not restored properly

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
15-06-2022, 03:44 PM,
#2
RE: Beta released on 14h June 2022
Hello Jordi

Can you tell me why if I start Swisslog and then start JTDX the UDP link is formed immediately and automatically but when I close JTDX and relaunch it, the UDP link does not start until I press the UDP button?

Erik.
Reply
16-06-2022, 11:05 PM, (This post was last modified: 16-06-2022, 11:20 PM by EA3GCV.)
#3
RE: Beta released on 14h June 2022
Hello Erik,

When Swisslog starts and the WSJT-X UDP settings are configured, Swisslog activates the UDP component of the compiler in the port selected for the main instance. The UDP button turns green as soon as it receives status packages from JTDX, meaning that the link is working well. When JTDX is closed or user presses the UDP button, the UDP component is still active but is not Accepting Data. UDP button turns red. If user starts again JTDX, user needs to manually press the UDP button in order to allow the UDP component to accept data again.

In previous versions the link was enabled automatically because I deactivated the UDP component when JTDX was closed or user pressed the UDP button. This was an excellent way but unfortunately this caused access violation errors often when reactivating again the UDP component or after compressing the database or restoring the desktop. In the best scenario the UDP link was not possible to be activated again after completing these operations unless Swisslog is restarted. It was a fact that activating/deactivating then activating again the UDP component was not reliable. 

I did a lot of changes in the code trying to find out a solution. Fortunately, I discovered that the UDP component had the "AcceptData" property. Setting this property to False the component is still active but it stops reading. Setting it to True the UDP component starts reading again from the selected port. This was the definitive solution! Of course the world is not perfect and the only drawback of this is that user needs to enable the UDP link manually if JTDX is closed after the first link or if user presses the UDP button to unlink from JTDX. But basically works the same way as the Digital mode program button to enable MixW, FLDIGI, etc. The only difference is that the UDP link is established automatically at Swisslog startup.

Now you know all the history behind this behaviour ;-)

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
17-06-2022, 12:30 PM,
#4
RE: Beta released on 14h June 2022
(16-06-2022, 11:05 PM)EA3GCV Wrote: Hello Erik,

When Swisslog starts and the WSJT-X UDP settings are configured, Swisslog activates the UDP component of the compiler in the port selected for the main instance. The UDP button turns green as soon as it receives status packages from JTDX, meaning that the link is working well. When JTDX is closed or user presses the UDP button, the UDP component is still active but is not Accepting Data. UDP button turns red. If user starts again JTDX, user needs to manually press the UDP button in order to allow the UDP component to accept data again.

In previous versions the link was enabled automatically because I deactivated the UDP component when JTDX was closed or user pressed the UDP button. This was an excellent way but unfortunately this caused access violation errors often when reactivating again the UDP component or after compressing the database or restoring the desktop. In the best scenario the UDP link was not possible to be activated again after completing these operations unless Swisslog is restarted. It was a fact that activating/deactivating then activating again the UDP component was not reliable. 

I did a lot of changes in the code trying to find out a solution. Fortunately, I discovered that the UDP component had the "AcceptData" property. Setting this property to False the component is still active but it stops reading. Setting it to True the UDP component starts reading again from the selected port. This was the definitive solution! Of course the world is not perfect and the only drawback of this is that user needs to enable the UDP link manually if JTDX is closed after the first link or if user presses the UDP button to unlink from JTDX. But basically works the same way as the Digital mode program button to enable MixW, FLDIGI, etc. The only difference is that the UDP link is established automatically at Swisslog startup.

Now you know all the history behind this behaviour ;-)

Best 73

Hello Jordi

Ok and I understand the necessity of the method. In Swisslog versions before the latest it did not really make much difference. Of course the user must remember to press the UDP button but once done then anything logged from JTDX was obviously queued and got logged. But in the latest Swisslog version the behaviour is problematic. 

So for example, I have been on CW and return to FT8. I open JTDX and forget to press the UDP button. As before, that becomes obvious when a QSO is started in JTDX because there is no QSO data in the Add QSOs window. So, as before, pressing the UDP button will start the transfer process. But the difference now is that when the 'log QSO' button is pressed in JTDX, that QSO and whatever else has been logged before and is in the queue is dumped by Swisslog and not logged. I have attached a zip file of a video showing stations coming to the Add QSO window that are being logged in JTDX but are not logged in Swisslog. I do not not see this issue in Swisslog 5.103 - in the same situation, that version logs the queue. So I think something has changed and surely the behaviour now is not as intended.

73 de Erik.


Attached Files
.zip   bandicam 2022-06-17 10-14-15-622.zip (Size: 1,3 MB / Downloads: 1)
Reply
19-06-2022, 10:24 PM, (This post was last modified: 20-06-2022, 02:31 AM by EA3GCV.)
#5
RE: Beta released on 14h June 2022
Hello Erik,

I have reproduced this scenario here and works well: I have disabled the UDP button and I have made somes dummy QSO's in JTDX. After pressing again the UDP button then all QSOs have been transferred and logged properly in Swisslog. Also note that I haven't changed anything related to this in version 5.104. In fact, I applied this internal change of the UDP button in version 5.103 (this is an excerpt from news and corrections):
  • Corrected: access violation errors when refreshing database connection/restoring desktop/compressing database/resequence QSO if DX Window was open or UDP link to WSJT-X was enabled.
  • Corrected: enabling/disabling WSJT-X UDP link sometimes didn't work and a program restart was needed.

Keep in mind that the UDP button enables or disables data reception from the UDP port (the DATAIN event triggered when it receives data). When enabling again data reception, depending how long you have been "off" some data may be lost. I have been reading throughly the UDP component documentation and there is a note that I think it could give an answer to this issue:

"Note that events are not re-entrant. Performing time consuming operations within this event will prevent it from firing again in a timely manner and may impact overall performance"

Probably you were more time with the UDP communication disabled and that's the reason you experienced this issue now. But version 5.103 implements exactly the same system. Technically, I can't do anything else. 

Now users need to be a little bit more aware when closing JTDX or disabling manually the UDP communication. In fact now works exactly the same as though you work with other digital mode programs such as FLDIGI, MixW, MultiPSK, etc. Users need to manually enable/disable the link whenever they want to work digital modes or not. In JTDX works in a semiautomatic manner because Swisslog links to it automatically only at startup if JTDX is running. Afterwards it works the same way.

In all my test here now and in my everyday radio activity, the queue has been always processed properly by Swisslog when enabling again the UDP communication. But as explained in the UDP component documentation there could be some issues under some scenarios which unfortunately are out of my control.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
20-06-2022, 08:47 AM,
#6
RE: Beta released on 14h June 2022
(19-06-2022, 10:24 PM)EA3GCV Wrote: Hello Erik,

I have reproduced this scenario here and works well: I have disabled the UDP button and I have made somes dummy QSO's in JTDX. After pressing again the UDP button then all QSOs have been transferred and logged properly in Swisslog. Also note that I haven't changed anything related to this in version 5.104. In fact, I applied this internal change of the UDP button in version 5.103 (this is an excerpt from news and corrections):
  • Corrected: access violation errors when refreshing database connection/restoring desktop/compressing database/resequence QSO if DX Window was open or UDP link to WSJT-X was enabled.
  • Corrected: enabling/disabling WSJT-X UDP link sometimes didn't work and a program restart was needed.

Keep in mind that the UDP button enables or disables data reception from the UDP port (the DATAIN event triggered when it receives data). When enabling again data reception, depending how long you have been "off" some data may be lost. I have been reading throughly the UDP component documentation and there is a note that I think it could give an answer to this issue:

"Note that events are not re-entrant. Performing time consuming operations within this event will prevent it from firing again in a timely manner and may impact overall performance"

Probably you were more time with the UDP communication disabled and that's the reason you experienced this issue now. But version 5.103 implements exactly the same system. Technically, I can't do anything else. 

Now users need to be a little bit more aware when closing JTDX or disabling manually the UDP communication. In fact now works exactly the same as though you work with other digital mode programs such as FLDIGI, MixW, MultiPSK, etc. Users need to manually enable/disable the link whenever they want to work digital modes or not. In JTDX works in a semiautomatic manner because Swisslog links to it automatically only at startup if JTDX is running. Afterwards it works the same way.

In all my test here now and in my everyday radio activity, the queue has been always processed properly by Swisslog when enabling again the UDP communication. But as explained in the UDP component documentation there could be some issues under some scenarios which unfortunately are out of my control.

Best 73

OK Jordi, I do not understand. In 5.103 it works no matter how long I am on another mode before returning to FT8. In 5.104  it does not and it is per my video every time. It is too much risk - lost QSOs in Swisslog. And the point is that the UDP button has gone green - it is not as if it is telling me there is no link, it says there is a link and to some extent there is because data is transferred to the Add QSOs window but then it is lost and not logged. Since 5.104 is better in other respects, I have made a .bat file that opens JTDX and then closes and opens Swisslog. So just on one press and I can be sure QSOs are logged. As long as Swisslog is launched after JTDX the UDP link is always re-formed and properly working.

73 Erik.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)