Hi
When a call sign is entered into the call sign field QLog reports the short path distance in the Info box. This information is sent to the rotator control panel. By clicking the "QSO" button in the rotator control panel, the antenna will rotate to the short path for that station.
Is it possible to offer both short path and long path options in the rotator control box as not every contact is via the short path?
73 Adam VK4IM
|
Re: Integration with other software via inbound connections
Use blue or red which may work on both black and white themes. Black is a bad idea because expertsdr default background is black or dark Grey. .?
toggle quoted message
Show quoted text
El s¨¢b, 16 mar 2024, 18:00, ok1mlg < ok1mlg@...> escribi¨®: Many thanks for sending the log from SDC. It was very helpful. It confirms my assumption. Just one additional question. I assume that the Spots were black. The Thetis theme is dark. Is it readable to have a dark theme with black Callsings? Please, could you send me a screenshot of what it looks like?
Regards Ladislav
Hi Ladislav,
?
I can try recompiling it but the last time I
compiled?something?I used?Borland C and the Euro was not yet a
currency.
?
I've been comparing the spot format from with those sent by QLog. I think this?will provide you the information
you need.?
?
These
are spots sent from SDC and properly shown on the panorama
spot:CE0YHF,CW,50313000,4278190080,CE0YHF;
spot:W2GGI,CW,28400000,4278190080,W2GGI;
spot:CA4WLD,CW,28497000,4278190080,CA4WLD;
spot:command ,CW,0,4278190080,command ;
spot:de ,CW,0,4278190080,de ;
spot:KE5RJJ,CW,14320000,4278190080,KE5RJJ;
spot:LU3HV,CW,28500000,4278190080,LU3HV;
?
And these are spots sent by Qlog and not shown in the
panorama
SPOT:J38R,LSB,7180000,2012390,;
MODULATION:0,LSB;
VFO:0,0,7180000;
SPOT:CE3QY,USB,14255000,2012390,;
SPOT:N4WFU,LSB,7128000,15790320,;
SPOT:N4WFU,LSB,7128000,15790320,;
?
Regards,?
On Fri, Mar 15, 2024 at 8:22?PM ok1mlg < ok1mlg@...> wrote: Unfortunately, I think it's a QLog issue. I analyzed your screenshot and QLog code and I think I misunderstood the SPOT command specification. It seems that the information about the color is being sent incorrectly, and as you can see, even your SW that you are using is sending this information incorrectly
I'm not sure if you are able to recompile QLog from source, but the fix is probably simple. Please let me know if you can recompile QLog, I would send you the patch for testing.
Regards Ladislav
Hi, I can see the messages in the TCI inbound debug log of the ExpertSDR2, so it is not a Qlog problem.? Other software is sending spots in the same way and they aren't there?neither.? I'll dig deeper. For now you can consider it a false positive bug :-)
Regards,
On Fri, Mar 15, 2024 at 3:15?PM ok1mlg < ok1mlg@...> wrote: Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Problem with OmniRig V2.1
Hi Latislav, This release now works as expected with OmniRig V2.
Many thanks for the quick turnaround on this fix.
As FYI Hamlib for the FT2000 still doesn't work, no problem for me, just letting you know.
-- 73's de Dave, G8FXM
|
Re: Integration with other software via inbound connections
Many thanks for sending the log from SDC. It was very helpful. It confirms my assumption. Just one additional question. I assume that the Spots were black. The Thetis theme is dark. Is it readable to have a dark theme with black Callsings? Please, could you send me a screenshot of what it looks like?
Regards Ladislav
toggle quoted message
Show quoted text
Hi Ladislav,
?
I can try recompiling it but the last time I
compiled?something?I used?Borland C and the Euro was not yet a
currency.
?
I've been comparing the spot format from with those sent by QLog. I think this?will provide you the information
you need.?
?
These
are spots sent from SDC and properly shown on the panorama
spot:CE0YHF,CW,50313000,4278190080,CE0YHF;
spot:W2GGI,CW,28400000,4278190080,W2GGI;
spot:CA4WLD,CW,28497000,4278190080,CA4WLD;
spot:command ,CW,0,4278190080,command ;
spot:de ,CW,0,4278190080,de ;
spot:KE5RJJ,CW,14320000,4278190080,KE5RJJ;
spot:LU3HV,CW,28500000,4278190080,LU3HV;
?
And these are spots sent by Qlog and not shown in the
panorama
SPOT:J38R,LSB,7180000,2012390,;
MODULATION:0,LSB;
VFO:0,0,7180000;
SPOT:CE3QY,USB,14255000,2012390,;
SPOT:N4WFU,LSB,7128000,15790320,;
SPOT:N4WFU,LSB,7128000,15790320,;
?
Regards,?
On Fri, Mar 15, 2024 at 8:22?PM ok1mlg < ok1mlg@...> wrote: Unfortunately, I think it's a QLog issue. I analyzed your screenshot and QLog code and I think I misunderstood the SPOT command specification. It seems that the information about the color is being sent incorrectly, and as you can see, even your SW that you are using is sending this information incorrectly
I'm not sure if you are able to recompile QLog from source, but the fix is probably simple. Please let me know if you can recompile QLog, I would send you the patch for testing.
Regards Ladislav
Hi, I can see the messages in the TCI inbound debug log of the ExpertSDR2, so it is not a Qlog problem.? Other software is sending spots in the same way and they aren't there?neither.? I'll dig deeper. For now you can consider it a false positive bug :-)
Regards,
On Fri, Mar 15, 2024 at 3:15?PM ok1mlg < ok1mlg@...> wrote: Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Problem with OmniRig V2.1
Dave,
a new installation package fixes the issue. You can find the package in the QLog's Release section.
just make sure the omnirig doesn't take too long to start. This can be achieved by reducing the number of loaded INI files. Otherwise, QLog reports that the connection to Rig cannot be established. You can also optimize it by starting Omnirig manually before QLog.
I hope it will work now.
Regards Ladislav
so 16. 3. 2024 v?11:39 odes¨ªlatel Dave, G8FXM < webmaster@...> napsal:
toggle quoted message
Show quoted text
Many thanks Latislav. -- 73's de Dave, G8FXM
|
Re: Integration with other software via inbound connections
Hi Ladislav,
?
I can try recompiling it but the last time I
compiled?something?I used?Borland C and the Euro was not yet a
currency.
?
I've been comparing the spot format from with those sent by QLog. I think this?will provide you the information
you need.?
?
These
are spots sent from SDC and properly shown on the panorama
spot:CE0YHF,CW,50313000,4278190080,CE0YHF;
spot:W2GGI,CW,28400000,4278190080,W2GGI;
spot:CA4WLD,CW,28497000,4278190080,CA4WLD;
spot:command ,CW,0,4278190080,command ;
spot:de ,CW,0,4278190080,de ;
spot:KE5RJJ,CW,14320000,4278190080,KE5RJJ;
spot:LU3HV,CW,28500000,4278190080,LU3HV;
?
And these are spots sent by Qlog and not shown in the
panorama
SPOT:J38R,LSB,7180000,2012390,;
MODULATION:0,LSB;
VFO:0,0,7180000;
SPOT:CE3QY,USB,14255000,2012390,;
SPOT:N4WFU,LSB,7128000,15790320,;
SPOT:N4WFU,LSB,7128000,15790320,;
?
Regards,?
toggle quoted message
Show quoted text
On Fri, Mar 15, 2024 at 8:22?PM ok1mlg < ok1mlg@...> wrote: Unfortunately, I think it's a QLog issue. I analyzed your screenshot and QLog code and I think I misunderstood the SPOT command specification. It seems that the information about the color is being sent incorrectly, and as you can see, even your SW that you are using is sending this information incorrectly
I'm not sure if you are able to recompile QLog from source, but the fix is probably simple. Please let me know if you can recompile QLog, I would send you the patch for testing.
Regards Ladislav
Hi, I can see the messages in the TCI inbound debug log of the ExpertSDR2, so it is not a Qlog problem.? Other software is sending spots in the same way and they aren't there?neither.? I'll dig deeper. For now you can consider it a false positive bug :-)
Regards,
On Fri, Mar 15, 2024 at 3:15?PM ok1mlg < ok1mlg@...> wrote: Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Problem with OmniRig V2.1
Many thanks Latislav. -- 73's de Dave, G8FXM
|
Re: Problem with OmniRig V2.1
Dave,
I did some research and found out that this is a QLog issue. To be precise, it's not an issue in the source code, but it is an issue in the process of preparing the QLog package for Windows - I compiled it against the wrong version of the QT library on Windows platform.
I will try to release a new exe file by the end of the day.
Regards Ladislav
p¨¢ 15. 3. 2024 v?22:42 odes¨ªlatel Dave, G8FXM < webmaster@...> napsal:
toggle quoted message
Show quoted text
Hi Latislav, I have;
- Launched Omnirig before QLog
- Attempted to connect the Rig from QLog.
However the problem persists. I can connect to OmniRig using the OmniRig Client successfully.
Please let me know how I can assist in debugging this issue?
-- 73's de Dave, G8FXM
|
Re: Problem with OmniRig V2.1
Hi Latislav, I have;
- Launched Omnirig before QLog
- Attempted to connect the Rig from QLog.
However the problem persists. I can connect to OmniRig using the OmniRig Client successfully. Please let me know how I can assist in debugging this issue? -- 73's de Dave, G8FXM
|
Re: Problem with OmniRig V2.1
Hi Dave, I apologize for the inconvenience. Unfortunately, it seems the solution isn't working as expected. When I attempted it, I did not see this issue. Please, could you perform the following sequence?
- Launch Omnirig before QLog
- Attempt to connect the Rig from QLog.
Kindly let me know the outcome of these steps. If the issue persists, I can provide instructions for generating a debug log, which may help me diagnose the problem more accurately.
Regards Ladislav
p¨¢ 15. 3. 2024 v?20:06 odes¨ªlatel Dave, G8FXM < webmaster@...> napsal:
toggle quoted message
Show quoted text
I'm having a problem connecting the latest version QLog to OmniRig v2.1.
9 times out of 10 connection attempt cause QLog to crash i.e. close unexpectedly. On the odd occasion it doesn't crash, connection hangs.
Anyone else seeing this issue? -- 73' s de Dave, G8FXM
|
Re: Integration with other software via inbound connections
Unfortunately, I think it's a QLog issue. I analyzed your screenshot and QLog code and I think I misunderstood the SPOT command specification. It seems that the information about the color is being sent incorrectly, and as you can see, even your SW that you are using is sending this information incorrectly
I'm not sure if you are able to recompile QLog from source, but the fix is probably simple. Please let me know if you can recompile QLog, I would send you the patch for testing.
Regards Ladislav
toggle quoted message
Show quoted text
Hi, I can see the messages in the TCI inbound debug log of the ExpertSDR2, so it is not a Qlog problem.? Other software is sending spots in the same way and they aren't there?neither.? I'll dig deeper. For now you can consider it a false positive bug :-)
Regards,
On Fri, Mar 15, 2024 at 3:15?PM ok1mlg < ok1mlg@...> wrote: Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Problem with OmniRig V2.1
I'm having a problem connecting the latest version QLog to OmniRig v2.1.
9 times out of 10 connection attempt cause QLog to crash i.e. close unexpectedly. On the odd occasion it doesn't crash, connection hangs.
Anyone else seeing this issue? -- 73' s de Dave, G8FXM
|
Re: Integration with other software via inbound connections
Hi, I can see the messages in the TCI inbound debug log of the ExpertSDR2, so it is not a Qlog problem.? Other software is sending spots in the same way and they aren't there?neither.? I'll dig deeper. For now you can consider it a false positive bug :-)
Regards,
toggle quoted message
Show quoted text
On Fri, Mar 15, 2024 at 3:15?PM ok1mlg < ok1mlg@...> wrote: Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Integration with other software via inbound connections
Juanma, - have you enabled this feature and no spots are displayed?
- Does mode is incorrectly detected?
Keep in mind, according to the QLog wiki, only "filtered" DX spots are
sent to the rig. If you have enabled the DXC filter, then QLog sends to
the rig only those spots that match your filter criteria. In other words, only QSOs that are displayed on the Bandmap are sent to the rig.
toggle quoted message
Show quoted text
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Integration with other software via inbound connections
Hi Ladislav and all,?
1) There are good reasons to accept ADIF from other software in the days of JTAlert, Gridtracker and other companion software to JTDX/WSJT-X, but don't worry I managed to get it to work. I explain below.? 2) N1MM, understood. It is not a priority and a manual import of ADIF after a contest is acceptable.?
I wanted to make Qlog work with JTDX?+ JTALERT but I had some issues using UDP forward (unicast) so I could fix it enabling multicast on all three softwares (JTDX, JTAlert and Qlog) and now everything is working great.?
I've published a blog post in case it helps other Qlog users. Feel free to use the content on the Wiki if you think that will be helpful for others.?
I take the opportunity to report a small bug. Qlog 0.33.1 - Software closes after failed cluster authentication.?
toggle quoted message
Show quoted text
On Wed, Mar 13, 2024 at 4:13?PM ok1mlg < ok1mlg@...> wrote: Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: Integration with other software via inbound connections
Juanma,
QLog already accepts QSO Log records from WSJT-X and can also forward packets from WSJT-X via QLog to the 3rd party software.
I thought about the integration of N1MM, but did not implement it because there are several things
1) As I wrote, currently I see no reason to receive messages from another log via another format that imports ADIF
2) Unfortunately, the N1MM UDP message format is not well-specified. There is a sample message, but it does not contain the specification of field values. With all respect to the N1MM authors, they have done a lot of work, probably most users cannot imagine how much work they have done, but when specifying the protocol, it is necessary to specify the field values as well. What does RadioInterfaced, IsRunQSO, etc. mean? What values can contain?
3) The N1MM UDP message contains only a very small amount of information.
4) It is possible to export from N1MM and import to QLog
Based on these points, I made a decision that QLog will not accept these N1MM online messages now.
I'm always writing. Everything can change, but currently there are other priorities in Qlog development.
Regards Ladislav
toggle quoted message
Show quoted text
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Integration with other software via inbound connections
Hi all,
Following from the previous thread and how to integrate N1MM by accepting UDP messages sent from that software to Qlog, I've been reviewing the Wiki and I can see the documentation for the "Notifications" option in the setup is to send out/forward udp packets from Qlog to other software.? My doubt is, Is there a feature to listen to and parse inbound UDP packets? That is how other loggers integrate with different?software for qso logging purposes. Not just N1MM but JTAlert, GridTracker, JTDX/WSJT-X, all work that way (in some cases these other loggers also parse in real-time the third party log but I think UDP listeners are more convenient than log file parsing.?
For instance, I see there's an integration developed for WSJT-X that allows to see within Qlog stations calling CQ, but I'm not sure is that integration allows WSJT-X to log the QSO on Qlog once completed if the qso has been initiated and completed from WSJT-X and not from within Qlog.?
I think an important improvement that will increase Qlog adoption is the possibility to receive and parse different types of messages via UDP.?
Regards, Juanma - EA3IFV
|
Re: First Impressions and feedback
Hi Ladislav,
ADI import issues fixed by importing again without checking the box in the import dialog. All fine.
Regarding "Spot to Rig", it is not working. Can't see any message debugging TCI input on the ExpertSDR side. I can see the messages for changing frequency, mode, etc, which all work fine. If you tell me where can I find the debug log for TCI in QLog I'll try to send it to you.
WSJT-X/JTDX integration. I will check the configuration as soon as?possible this week.
N1MM - It is the default contest logging software but is not a good "generic/main" logging?tool, for that reason many people use N1MM during contests and forwards QSOs logged on n1mm to their main logger (QLog in our case). That simply avoid the manual task of importing the resulting ADI file from N1MM to your main logger after the contest. Not a big issue but it is welcome. Here is the specification:?
Regards, Juanma - EA3IFV
toggle quoted message
Show quoted text
On Sun, Mar 10, 2024 at 7:29?PM ok1mlg < ok1mlg@...> wrote: Hi Juanma,
Many thanks for your feedback.
TCI was implemented without using a real rig, so I only estimated everything using the simulator. I assume that it will still need to be fine-tuned. I don't know if you use the "Spot to Rig" function. So I'm not sure if the spots are sent and displayed correctly.
Otherwise, my answers to your questions are below.
Regards Ladislav
Hi,?
I installed Qlog 0.33.1 yesterday after realizing that TCI is now supported. It is working fine with my SunSDR2 Pro and Expert SDR 2 1.3.1.
I love the look and feel and user experience so far.?
Minor issues found, probably my fault: 1.- Importing ADI file from Log4OM contains DXCC that are not counted in awards. For instance 6O1OO (Somalia), is there, confirmed by QSL and Lotw but QLog Awards is not counting it and shows and non worked. VP8PJ was classified as Falkland Is. instead of South Orkney but editing?the QSO manually did the trick. I think I have a similar issue with Marquesas Is. Nothing serious in any case.
if QSOs are not counted in awards, then it is necessary to verify. It would be best if you send me a specific QSO in ADI format as it looked before import.
VP8PJ was classified as Falkland Is. instead of South Orkney:
Unfortunately, It is correct. I looked in the CTY file, which is the source of the DXCC Entity information, and VP8PJ was deleted on Feb 15, 2024. See detail
if you don't want DXCC to be recalculated when importing to QLog, you need to define this in the Import dialog.
What I miss: I miss (or maybe is there but I haven't found the?way) the ability to log QSOs from other software (JTDX/WSJTX, JTAlert, Gridtracker or N1MM). Is there any option that creates a listener on QLog to send QSO data and log them?
WSJTX is supported and tested. You can define listen port and other options. See You can forward the packet to JTAlert too.
N1MM - the question is what support means in this case. If you want to receive messages from N1MM, then QSO can be exported and imported. Why have 2 log applications running? By the way, N1MM provides very little information via the messages.
I think everything?else is just perfect and very promising. Not sure how can I help given my bad development skills but I'll be happy to take a look to the mailing list from time to time and keep testing new releases.
Everyone can contribute their ideas, help with translations (if necessary). QLog should be a community project. Even a well-thought-out and well-specified problem and its solution provide help for the project.
?
|
Re: First Impressions and feedback
Hi Juanma,
Many thanks for your feedback.
TCI was implemented without using a real rig, so I only estimated everything using the simulator. I assume that it will still need to be fine-tuned. I don't know if you use the "Spot to Rig" function. So I'm not sure if the spots are sent and displayed correctly.
Otherwise, my answers to your questions are below.
Regards Ladislav
Hi,?
I installed Qlog 0.33.1 yesterday after realizing that TCI is now supported. It is working fine with my SunSDR2 Pro and Expert SDR 2 1.3.1.
I love the look and feel and user experience so far.?
Minor issues found, probably my fault: 1.- Importing ADI file from Log4OM contains DXCC that are not counted in awards. For instance 6O1OO (Somalia), is there, confirmed by QSL and Lotw but QLog Awards is not counting it and shows and non worked. VP8PJ was classified as Falkland Is. instead of South Orkney but editing?the QSO manually did the trick. I think I have a similar issue with Marquesas Is. Nothing serious in any case.
if QSOs are not counted in awards, then it is necessary to verify. It would be best if you send me a specific QSO in ADI format as it looked before import.
VP8PJ was classified as Falkland Is. instead of South Orkney:
Unfortunately, It is correct. I looked in the CTY file, which is the source of the DXCC Entity information, and VP8PJ was deleted on Feb 15, 2024. See detail
if you don't want DXCC to be recalculated when importing to QLog, you need to define this in the Import dialog.
What I miss: I miss (or maybe is there but I haven't found the?way) the ability to log QSOs from other software (JTDX/WSJTX, JTAlert, Gridtracker or N1MM). Is there any option that creates a listener on QLog to send QSO data and log them?
WSJTX is supported and tested. You can define listen port and other options. See You can forward the packet to JTAlert too.
N1MM - the question is what support means in this case. If you want to receive messages from N1MM, then QSO can be exported and imported. Why have 2 log applications running? By the way, N1MM provides very little information via the messages.
I think everything?else is just perfect and very promising. Not sure how can I help given my bad development skills but I'll be happy to take a look to the mailing list from time to time and keep testing new releases.
Everyone can contribute their ideas, help with translations (if necessary). QLog should be a community project. Even a well-thought-out and well-specified problem and its solution provide help for the project.
?
|
First Impressions and feedback
Hi,?
I installed Qlog 0.33.1 yesterday after realizing that TCI is now supported. It is working fine with my SunSDR2 Pro and Expert SDR 2 1.3.1.
I love the look and feel and user experience so far.?
Minor issues found, probably my fault: 1.- Importing ADI file from Log4OM contains DXCC that are not counted in awards. For instance 6O1OO (Somalia), is there, confirmed by QSL and Lotw but QLog Awards is not counting it and shows and non worked. VP8PJ was classified as Falkland Is. instead of South Orkney but editing?the QSO manually did the trick. I think I have a similar issue with Marquesas Is. Nothing serious in any case.
What I miss: I miss (or maybe is there but I haven't found the?way) the ability to log QSOs from other software (JTDX/WSJTX, JTAlert, Gridtracker or N1MM). Is there any option that creates a listener on QLog to send QSO data and log them?
I think everything?else is just perfect and very promising. Not sure how can I help given my bad development skills but I'll be happy to take a look to the mailing list from time to time and keep testing new releases.
Regards, Juanma - EA3IFV
|