Welcome to the FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR or 4O3A Genius Product Software?
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
wsjt-x field day 2019
Options
Tom Worthington
Member ✭✭
WSJT-x has support for Field Day this year, but not everyone will be operating in FD mode.
We always work a lot of DX stations who are not in FD. At night we point a 20m beam to Asia and take advantage of the propagation. In SSB and CW we just log these stations as 1D DX.
That is going to be a problem with WSJT-x in FD mode. It does not send the expected signal report message and will not log the QSO.
During a recent test contest it was very difficult to deal with stations responding to a CQ in non contest mode. This is sure to be much worse during FD when the bands are completely swamped with stations. One solution that I have tested for this is to run two separate instances of WSJT-x, using the same radio (both physical and logical and slice), one set for FD contest mode and the other for standard mode. I added a 2nd TCP port and PTT port for the second instance. Both instances send log data to a single instance of N1MM+. There are some issues. The standard instance of WSJT-x logs a contact with the correct call sign and mode, but leaves the class and section empty. This is not really a problem because all that is required to remove the DUPS is the call sign and mode. Since FD does not include log checking, is does not matter what is in the class and section fields. The FD instance of WSJT-x will (presumably since I haven't gotten any live testing data) correctly fill in the Class and Section information in the log.
The only issue I've run into so far is that the system is perfectly happy carrying on two QSO's simultaneously, transmitting two signals on different audio offsets. I've seen DX stations do this but it is, I believe, a violation of FD rules. I suspect it will take some practice but if I give preference to working FD stations it may be a good solution with dealing with non-FD stations.
What could possible go wrong? :-)
Please look for us during Field -- KH6RS
73 and Aloha, Tom, NH6Y
We always work a lot of DX stations who are not in FD. At night we point a 20m beam to Asia and take advantage of the propagation. In SSB and CW we just log these stations as 1D DX.
That is going to be a problem with WSJT-x in FD mode. It does not send the expected signal report message and will not log the QSO.
During a recent test contest it was very difficult to deal with stations responding to a CQ in non contest mode. This is sure to be much worse during FD when the bands are completely swamped with stations. One solution that I have tested for this is to run two separate instances of WSJT-x, using the same radio (both physical and logical and slice), one set for FD contest mode and the other for standard mode. I added a 2nd TCP port and PTT port for the second instance. Both instances send log data to a single instance of N1MM+. There are some issues. The standard instance of WSJT-x logs a contact with the correct call sign and mode, but leaves the class and section empty. This is not really a problem because all that is required to remove the DUPS is the call sign and mode. Since FD does not include log checking, is does not matter what is in the class and section fields. The FD instance of WSJT-x will (presumably since I haven't gotten any live testing data) correctly fill in the Class and Section information in the log.
The only issue I've run into so far is that the system is perfectly happy carrying on two QSO's simultaneously, transmitting two signals on different audio offsets. I've seen DX stations do this but it is, I believe, a violation of FD rules. I suspect it will take some practice but if I give preference to working FD stations it may be a good solution with dealing with non-FD stations.
What could possible go wrong? :-)
Please look for us during Field -- KH6RS
73 and Aloha, Tom, NH6Y
0
Comments
-
I don't believe this is a violation as long as you count it as two transmitters.0
-
Tim, The rules state:
6.7. The use of more than one transmitter at the same time on a single band-mode is prohibited. Exception: a dedicated GOTA station may operate as prescribed in Rule 4.1.
So you can't just add a transmitter to your class.
The question is: what constitutes a transmitter? The instance of WSJT-x or the physical radio?
Anyway I think trying to work two stations at the same time would stress my cpu beyond its capabilities.
0 -
I see. I would expect a transmitter to be the hardware itself (physical radio), regardless of what software is interfaced to it.0
Leave a Comment
Categories
- All Categories
- 328 Community Topics
- 2.1K New Ideas
- 593 The Flea Market
- 7.8K Software
- 6.2K SmartSDR for Windows
- 168 SmartSDR for Maestro and M models
- 396 SmartSDR for Mac
- 260 SmartSDR for iOS
- 246 SmartSDR CAT
- 179 DAX
- 369 SmartSDR API
- 9.1K Radios and Accessories
- 15 Aurora
- 159 FLEX-8000 Signature Series
- 7.1K FLEX-6000 Signature Series
- 909 Maestro
- 51 FlexControl
- 854 FLEX Series (Legacy) Radios
- 873 Genius Products
- 446 Power Genius XL Amplifier
- 312 Tuner Genius XL
- 115 Antenna Genius
- 278 Shack Infrastructure
- 196 Networking
- 438 Remote Operation (SmartLink)
- 135 Contesting
- 721 Peripherals & Station Integration
- 136 Amateur Radio Interests
- 942 Third-Party Software