i thought the re-broadcast was to be 2234 ( or I use 2239).  unless you had a typo, the port 2334 may be used sometimes by something else

I use 2239 to get to gridtracker, running on a Raspberry pi

Dave Garber

VE3WEJ / VE3IE

On Thu, Mar 5, 2020 at 6:04 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:

I have been using DXLab Suites of late and one of the things that I really missed was being able to use JTAlert at the same time I was using DXLab SpotCollector, because JTAlert wants exclusive control or use of the UDP info coming out of WSJT-X.

There are things that JTA does much better than SpotCollector. It is more immediate in its alerts. It tabulates information in a very intuitive way, so that a quick glance or listen gives information efficiently.

There are other things that SpotCollector does, too many to mention, that JTA does not do and will never do. They complement each other, but running them together is not easily or obviously done. (at least to me)

I stumbled on a way that works:

1. Leave WSJT-X in its standard UDP reporting configuration:

127.0.0.1 and Port 2237

2. Use the recommended settings for WSJT-X to log to DXKeeper.

3. Set JTAlert to log to its own ADIF log. (do not use DxKeeper as your JTA logger) or you will get double entries in your DXKeeper log.

4. In JTA:

Manage Settings > Applications >  WSJT-X/JTDX:

Check Rebroadcast WSJT-X  UDP Packets (rx'd only)

Port 2334

IP: 127.0.0.1

5. In SpotCollector:

Config > Spot Sources > WSJT-X:

Check CQ Color, MyCall color, Port 2334

Check Lookup, Callbook LoTW (as needed)

Finally, check ENABLE WSJT-X

The Resulting Operations:

JTAlert gets decoded UDP Packets directly from WSJT-x on Port 2237

JTAlert Rebroadcasts those UDP packets to SpotCollector which is listening on 2334.

If things are working correctly, the Spot Source Status light at the top of SpotCollector window (row of red/green lights) will show green at the far right, indicating it is getting spots from WSJT-X (which in reality it is not, it is getting them from the rebroadcast of JTAlert

If this doesn't happen, you might have to try it more than once (enable/disable WSJT-X in SpotCollector config), or stop/restart either or both JTA or SpotCollector or WSJT-x. Once it "takes" and the green light is lit, it will stay working just fine.

If needed, export your DXKeeper log in adif format and place it in JTAlert's logging location for ADIF log. This will make sure your two logs are in sync and give proper Worked B4, STATE and DX summaries. As each new qso comes in, it is logged to DXKeeper in its file and and to JTAlert's ADIF log file. No dupes! You should only have to import / replace the JTA adif file one time, when setting this up the first time. (All this assumes that DXKeeper is your master log and has more qsos than you might have in your ADIF log in JTAlert.

I found placing the ADIF log file in a more accessible directory worked better as you can import it more easily than inside the AppData subdirectories. I put mine in the Download directory and made sure to rename it properly  so it would be easy to see which file to import. (Choose select when in the ADIF log setup in JTA)

Now:

JTAlert is fully functional  and stays current

DxLab SpotCollector is nearly fully functional and stays current.

No conflicts, no dupes. 

CAVEAT:

You can call stations in JTA by double clicking as normal and WSJT-X will follow.

You cannot double click in SpotCollector and have WSJT-X  move to the spot.

SpotCollector does not remember Port 2334 in it's configuration for WSJT-X as a spot source. Every time you stop/restart SpotCollector you will need to go in and set the Port to 2334 if you want it to work with JTAlert as described above.

Seems like the best of both worlds.

If there's a better way to do this, I'm sure someone will point it out and I'll learn from it. If there's something wrong on dangerous with doing things the way I have outlined, please speak up.

You can return to "normal" Spot Collector operation by closing JTAlert and :

SpotCollector > Config > Spot Sources > Change Port back to 2237 from 2334.

73, N0AN

Hasan

I have been using DXLab Suites of late and one of the things that I really missed was being able to use JTAlert at the same time I was using DXLab SpotCollector, because JTAlert wants exclusive control or use of the UDP info coming out of WSJT-X.

There are things that JTA does much better than SpotCollector. It is more immediate in its alerts. It tabulates information in a very intuitive way, so that a quick glance or listen gives information efficiently.

There are other things that SpotCollector does, too many to mention, that JTA does not do and will never do. They complement each other, but running them together is not easily or obviously done. (at least to me)

I stumbled on a way that works:

1. Leave WSJT-X in its standard UDP reporting configuration:

127.0.0.1 and Port 2237

2. Use the recommended settings for WSJT-X to log to DXKeeper.

3. Set JTAlert to log to its own ADIF log. (do not use DxKeeper as your JTA logger) or you will get double entries in your DXKeeper log.

4. In JTA:

Manage Settings > Applications >  WSJT-X/JTDX:

Check Rebroadcast WSJT-X  UDP Packets (rx'd only)

Port 2334

IP: 127.0.0.1

5. In SpotCollector:

Config > Spot Sources > WSJT-X:

Check CQ Color, MyCall color, Port 2334

Check Lookup, Callbook LoTW (as needed)

Finally, check ENABLE WSJT-X

The Resulting Operations:

JTAlert gets decoded UDP Packets directly from WSJT-x on Port 2237

JTAlert Rebroadcasts those UDP packets to SpotCollector which is listening on 2334.

If things are working correctly, the Spot Source Status light at the top of SpotCollector window (row of red/green lights) will show green at the far right, indicating it is getting spots from WSJT-X (which in reality it is not, it is getting them from the rebroadcast of JTAlert

If this doesn't happen, you might have to try it more than once (enable/disable WSJT-X in SpotCollector config), or stop/restart either or both JTA or SpotCollector or WSJT-x. Once it "takes" and the green light is lit, it will stay working just fine.

If needed, export your DXKeeper log in adif format and place it in JTAlert's logging location for ADIF log. This will make sure your two logs are in sync and give proper Worked B4, STATE and DX summaries. As each new qso comes in, it is logged to DXKeeper in its file and and to JTAlert's ADIF log file. No dupes! You should only have to import / replace the JTA adif file one time, when setting this up the first time. (All this assumes that DXKeeper is your master log and has more qsos than you might have in your ADIF log in JTAlert.

I found placing the ADIF log file in a more accessible directory worked better as you can import it more easily than inside the AppData subdirectories. I put mine in the Download directory and made sure to rename it properly  so it would be easy to see which file to import. (Choose select when in the ADIF log setup in JTA)

Now:

JTAlert is fully functional  and stays current

DxLab SpotCollector is nearly fully functional and stays current.

No conflicts, no dupes. 

CAVEAT:

You can call stations in JTA by double clicking as normal and WSJT-X will follow.

You cannot double click in SpotCollector and have WSJT-X  move to the spot.

SpotCollector does not remember Port 2334 in it's configuration for WSJT-X as a spot source. Every time you stop/restart SpotCollector you will need to go in and set the Port to 2334 if you want it to work with JTAlert as described above.

Seems like the best of both worlds.

If there's a better way to do this, I'm sure someone will point it out and I'll learn from it. If there's something wrong on dangerous with doing things the way I have outlined, please speak up.

You can return to "normal" Spot Collector operation by closing JTAlert and :

SpotCollector > Config > Spot Sources > Change Port back to 2237 from 2334.

73, N0AN

Hasan