Date   

locked Re: WSJT-X UDP -- piggyback messages to WSJT-X

g4wjs
 

On 29/01/2020 14:52, Erik Icket wrote:
Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.

Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB
Hi Erik,

what you are requesting is not as easy as you state. The reply datagrams would need to be correctly addressed to the instance of WSJT-X they are intended for, that would require JTAlert to keep a table of WSJT-X clients along with their service port numbers to reply to. That table probably already exists within JTAlert so that it can itself send reply datagrams, but it is hard to see how reply datagrams from your application can be allocated to the correct WSJT-X instance when routing them through, since JTAlert does not know to which original outgoing message the reply is to. More specifically, JTAlert has no knowledge of which sender service port of incoming reply datagrams belongs to which application.

All of this is elegantly handled if each application interoperating with WSJT-X is capable of listening on a UDP multicast group address, and each application need do no more than that, over and above what they would do using unicast addressing. It is unfortunate that the support libraries provided with AutoIT (the original implementation language of JTAlert) do not directly support listening for UDP traffic on a multicast group addresses. Someone with moderate AutoIT programming skills and some systems programming knowledge on MS Windows could write the necessary add-on for AutoIT to do what is required. Until that happens, or until Laurie is in a position to roll out the next generation of JTAlert, it is not practical to try and spoof multicast UDP handling in any way that meets your requirement.



--
73
Bill
G4WJS.


locked JTDX*JTALERT*GRIDTRACKER all together

D Visser
 

Hello,

Now running here all these 3 programs together.
This are my settings:

1 JTDX
settings*reporting:
ip adress udp server 127.0.0.1
udp server port 2237
acc udp request thicked
notify          thicked
acc udp restore windows thicked
 
2 JTALERT via JTDX
 
manage settings*applications wsjt-x/jtdx
ip adress 224.0.0.1
port 2238
rebroadcast thicked
 
3 Gridtracker
general*received udp messages from jtdx:
multicast thicked
ip adress 224.0.0.1
port 2238
forward upd messages
ip adress 127.0.0.1
port 2237
 
BTW start first program JTDX than JTALERT (JTDX) and last Gridtracker

David Visser


locked WSJT-X UDP -- piggyback messages to WSJT-X

Erik Icket
 

Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.
 
Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB


locked Re: Logging Issue

g4wjs
 

On 29/01/2020 06:01, w7osg2@... wrote:
The I just disable WSJT-X from sending info to HRD Log Book and now I am just getting the one entry from JTAlerts. Thanks fo rthe Help Mike


Mike C.  Boise, ID
Mike,

just for clarity, WSJT-X does not send QSOs to HRD. The HRD developers decided, without asking, to take a feed designed for, and contributed by, the N1MM Logger+ developers, and used that to import logged QSOs from WSJT-X. That feed is deprecated and also HRD incorrectly interprets mode data from that feed. I strongly recommend that the HRD "feature" to misused this feed is not used.



--
73
Bill
G4WJS.


locked Re: JTAlert 2.15.8 - Scan log of Log4OM V2 (2.2.0.0) not working with MySQL database.

Matt M0LMK
 

Laurie,

I'm using MySQL backend for Log4OM V2.

My QSO all log fine and the JTAlert test shows no issues.

Thanks,

Matt
M0LMK / KI5GXV


locked Re: Logging Issue

Mike Cooper
 

UNDER: Logging/last qso API/udp transmission....I turned off "enable transmission of last qso" and that stopped the logging of the entry that was missing the QSO date etc.

The I just disable WSJT-X from sending info to HRD Log Book and now I am just getting the one entry from JTAlerts. Thanks fo rthe Help Mike


Mike C.  Boise, ID


locked Re: Logging Issue

Mike Cooper
 

Only UDP receive is turned on


locked Re: Logging Issue

Michael Black
 

Also make sure you don't have QSO Forwarding turned on in HRD Logbook -- you may be forwarding it to yourself.
Tools/Configure/QSO Forwarding




On Tuesday, January 28, 2020, 11:21:58 PM CST, w7osg2@... <w7osg2@...> wrote:


It is turned off, i.e. not checked


locked Re: Logging Issue

Mike Cooper
 

It is turned off, i.e. not checked


locked Re: Logging Issue

Michael Black
 

Make sure you don't have rebroadcast turned on...

Inline image





On Tuesday, January 28, 2020, 10:49:41 PM CST, w7osg2@... <w7osg2@...> wrote:


I currently have WSJT-X configured to log to the HRD Logbook and since bringing JTAlert on line I have it configured to log to HRD Logbook, also. So, when I make a successful contact the Logbook reminder in WSJT-X pops up and I click OK and it puts that QSO in the HRD Logbook, then JTAlerts put it in the HRD Logbook also with a few added details that WSJT-X doesn't as well. But, a third entry is made but it lacks a QSO date and a few other items, where did it come from?

I have tried this yet, but I assume that I will need to disable the link between WSJT-X and HRD Logbooks to take full advantage of JTAlerts logging capabilities without the duplication issue, but what about that third entry why is it there? It must come from JTAlerts because I dont see it happen  when JTAlerts is offline.

Any advice or observation would be helpful thank you

Mike C. W7OSG


locked Logging Issue

Mike Cooper
 

I currently have WSJT-X configured to log to the HRD Logbook and since bringing JTAlert on line I have it configured to log to HRD Logbook, also. So, when I make a successful contact the Logbook reminder in WSJT-X pops up and I click OK and it puts that QSO in the HRD Logbook, then JTAlerts put it in the HRD Logbook also with a few added details that WSJT-X doesn't as well. But, a third entry is made but it lacks a QSO date and a few other items, where did it come from?

I have tried this yet, but I assume that I will need to disable the link between WSJT-X and HRD Logbooks to take full advantage of JTAlerts logging capabilities without the duplication issue, but what about that third entry why is it there? It must come from JTAlerts because I dont see it happen  when JTAlerts is offline.

Any advice or observation would be helpful thank you

Mike C. W7OSG


locked Re: JTAlert 2.15.8 - Scan log of Log4OM V2 (2.2.0.0) not working with MySQL database.

HamApps Support (VK3AMA)
 

On 29/01/2020 8:28 am, Doug Munday wrote:

No, I had not recently done a LotW download, maybe a week ago.  I will send you an adif export of my MySQL log.  On its way in a few minutes. 

Thanks!

Doug - W7DRM
Doug,

Please run a Scan Log again, restart JTAlert then use the "Help" (or "? ") -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA


locked Re: JTAlert 2.15.8 - Scan log of Log4OM V2 (2.2.0.0) not working with MySQL database.

HamApps Support (VK3AMA)
 

On 29/01/2020 8:28 am, Doug Munday wrote:
Hi Laurie,

No, I had not recently done a LotW download, maybe a week ago.  I will send you an adif export of my MySQL log.  On its way in a few minutes. 

Thanks!

Doug - W7DRM
Doug,

Initially I was suspicious that an LoTW update had altered the Json qsoconfirmation data in the log causing JTAlert to break.
My tests proved otherwise.
I can't fault it here, both Sqlite & MySQL logs working fine.

Something unusual is happening.

Rather than an ADIF export (which by its nature tends to alter data), are you able to do an SQL dump of the log table so I can see the raw data?

Please also send a support request, use the "Help" (or "? ") -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA



locked Re: Unsuccessful Logging warning in LOG40M2

KF5WGB <ralfvoepel@...>
 

Hi Laurie,
Weird thing over here with LOG4OM V2. (Maybe I am not the only one experiencing this)
I followed the instructions in the Help and created an UDP_Inbound port 2235 [Adif_message] (JTAlert QSO), checked that Remote control port  2241 was checked, Path to SQlite Log was set and tested and set the Check QSO log record to 20 sec. No success. It does not log.

Here comes the strange weird part.
To see if WSJT-x would log to LOG4Om itself, I added a second UDP_Inbound port 2236 [Adif_message] WSJT Log Contact. In WSJT-x I enabled the Secondary UDP Server and it takes 25~27 seconds to be logged. If I check both created UDP_inbound ports, the QSO is logged and JTAlert tells me success. However the QSO is logged twice, one from JTAlert and one from WSJT-x... I think. The difference is the second logged QSO date/time shows a 20~23 sec difference to the first one.
If I uncheck UDP_inbound port 2236 - the one from WSJT-x- , no contact is logged at all and I get the error message from JTA that the QSO is not logged (I guess timed out)
It is either both (double entry) or just WSJT-x. Shouldn't my  PC, Windows 7 Pro, 64Bit, 4GB Ram, Dual Core be fast enough?
I think I have to go to the LOG4OM forum to see if there is a timing issue with the logging and if there is a fix.
For now it is back to LOG4OM V1 and JTA which works perfectly together.

73,
de KF5WGB


locked Re: JTalerts #DXLAB

Mike Cooper
 

Name is Mike,
You are correct that was the problem all along I dont know how docking got turned on as this was my initial install.The ALT version works best for me. All is well now.

Mike C.
Boise, ID


locked Re: JTAlert 2.15.8 - Scan log of Log4OM V2 (2.2.0.0) not working with MySQL database.

Doug Munday
 

Hi Laurie,

No, I had not recently done a LotW download, maybe a week ago.  I will send you an adif export of my MySQL log.  On its way in a few minutes. 

Thanks!

Doug - W7DRM


locked Re: JTalerts #DXLAB

HamApps Support (VK3AMA)
 

On 29/01/2020 7:34 am, w7osg2@... wrote:
Once I got access to the JTAlerts(ALT) program I undocked it from WSJT-X  and so far is working, Evidently when it is installed docking to WSJT-X is enabled and that is what causes the issue with not being able to find it. 
OM (What is your name? I don't want to go onto QRZ just to find out)

If JTAlert is docked to WSJT-X and part or all of the JTAlert window is off-screen, just move the WSJT-X window until JTAlert comes into view. Once the menus are visible, you can turn off docking.

The default behavior for docking is off. This applies to new installs.

If docking was enabled for you, then either you enabled it or you had a previous JTAlert install (it doesn't matter how old) that had docking enabled. JTAlert will not turn it on unless instructed by the user.

de Laurie VK3AMA


locked Re: I need SQLite log

Michael Black
 

Just import the ADIF into Log4OM2.  The V2 database is completely different so export/import is needed.
File/Import ADIF

de Mike W9MDB






On Tuesday, January 28, 2020, 02:30:35 PM CST, afa1yy <arthur@...> wrote:


In upgrading to LOG4OM V2, My logs in SQLite  are no longer there.  Besides the new format, I do have my complete log saved as an ADIF.  In setting up LoG4om2 in  JTalert, I am required to provide my log in SQLite format.  How can I convert ADIF into SQLite?
--
Art  K0AY


locked Re: I need SQLite log

HamApps Support (VK3AMA)
 

On 29/01/2020 7:30 am, afa1yy wrote:
In upgrading to LOG4OM V2, My logs in SQLite  are no longer there.  Besides the new format, I do have my complete log saved as an ADIF.  In setting up LoG4om2 in  JTalert, I am required to provide my log in SQLite format.  How can I convert ADIF into SQLite?
--
Art  K0AY
Art,

Please post these Log4OM howto questions over on the Log4OM support forum.

de Laurie VK3AMA


locked Re: JTalerts #DXLAB

HamApps Support (VK3AMA)
 

On 29/01/2020 7:08 am, w7osg2@... wrote:
Turns out it is a screen sizing issue if I drop the display setting to 100% I can just barely see it the alt mode but cannot drag it out onto the full screen. And if I try
it the dragging process disrupts the rest of the screen. 
OM (Name?),

I run with 175% scaling without issue.

Please post an image of the JTAlert window (not your entire desktop!) showing the effect your describing.

de Laurie VK3AMA