I use DXLabs commander and HDSDR (RSP1a)? at the same time? with my TS590sg, Commander talks to the USB port and HSDR talks to the RS 232 port, using the Omni-Rig driver in HDSDR.? This worked better than the Secondary CCAT Port in Commander.? (was more responsive and works with other software without changing anything, like N1MM, WriteLog - etc).? This allowed clicking on the signals in HDSDR and having the radio tune to the signal.

I don't know if the TS-590sg specification states that this is acceptable or not, but it works great!? I don't know if it will work as good with the TS-590s, don't have one, just have the sg version.
Gordon - N1MGO

The FFMA report is a good starting point, but I would respectfully
suggest going further with this concept for needs in general.

The FFMA script was written before DXKeeper provided a built-in
FFMA report. Notice that the script calls the VUCC Report.

Using "add needed" doesn't work properly either since it's selecting
LoTW users as well as non-LoTW users (and multiple non-6m QSOs with
those who I also need to confirm on 6).

If one uses the same SQL as the "Filter" statement in the FFMA script
to filter the DXKeeper log display then does an "Add Needed" for CARDS/LABELS without removing the filter it will certainly add any
QSOs that are not confirmed via LotW.

it's selecting LoTW users as well as non-LoTW users

If you don't want LotW users add "and App_DXKeeper_LotW_User <> 'Y'"
to the SQL used in the FFMA Script.

(and multiple non-6m QSOs with those who I also need to confirm on
6)

Well then don't tell DXKeeper you want the extra QSOs ... *CLEAR* the
"Add Needed requests" boxes in the QSL Config dialog.

I'm current with my FFMA grids so I can't check *but* one should
actually be able to accomplish what you want by:

1) Filter the DXKeeper Log display with:
App_DXKeeper_LotW_User <> 'Y'
2) Clear the "Add Needed requests" boxes
3) Clear the Awards boxes in Add Needed
4) Select *only* FFMA

73,

... Joe, W4TV


On 2020-06-18 9:18 AM, Peter Dougherty wrote:

The FFMA report is a good starting point, but I would respectfully suggest going further with this concept for needs in general.
If someone who uses LoTW goes in to that report it's almost certainly not to see what's confirmed/verified (he can do that via LoTW after all), but rather, to try and figure out what's still outstanding; to determine who will need to be sent a physical card.
Using "add needed" doesn't work properly either since it's selecting LoTW users as well as non-LoTW users (and multiple non-6m QSOs with those who I also need to confirm on 6). I'm willing to give LoTW users a couple of years before I mark those Qs as needed for paper card (or, more likely, not in their log or otherwise unconfirmable).

Well crap. I guess that did happen. I was getting hits on the call in Spot Collector, but JT Alert-X wasn't tweaking to whatever he was reporting. As I sit here and watch every other region getting these fantastic long-haul openings knowing NJ seems to get the dregs 99 times out of 100, then I see this. Shaping up to be One Of Those Mornings. If he was roving in EM43, though, I have to wonder why JTAlert-X?didn't pick up on it, since it's usually VERY reliable in flagging new grids.

I guess I never really worried about domestic grids in the past, figuring they were a dime a dozen. But now that I'm over 500 (still wet behind the ears compared to many here, I'm sure) new grid flags are getting increasingly difficult, especially domestically. And it's funny how, when I look at my 6m grid worked/confirmed map in DX Atlas, everything falls off a cliff west of EM. I only have about 30% of grids worked in DM70-DM99, but about 95-98% of EM00-EM30. It's like the DM/EM divide is a DX wall. And the Canadian border is a much bigger DX wall. Looks like most Canadian hams don't pay much attention to 6m. My EN and FN grids all basically stop at the US-Canada border. Put down the maple syrup and the Timmies double-doubles and get up on six, eh? (I can say this...I'm also VE3THX; born and raised in the land of moose-and-elk).

Dave,

I do not unfortunately.?

The FFMA report is a good starting point, but I would respectfully suggest going further with this concept for needs in general.

If someone who uses LoTW goes in to that report it's almost certainly not to see what's confirmed/verified (he can do that via LoTW after all), but rather, to try and figure out what's still outstanding; to determine who will need to be sent a physical card.

Using "add needed" doesn't work properly either since it's selecting LoTW users as well as non-LoTW users (and multiple non-6m QSOs with those who I also need to confirm on 6). I'm willing to give LoTW users a couple of years before I mark those Qs as needed for paper card (or, more likely, not in their log or otherwise unconfirmable).

That's correct.? AC0RA was in EM43 on Tuesday/Wesnesday this week.? I hope you didn't think it was false and got one of your two remaining EM grids.

Chad WE9V

开云体育

[Edited Message Follows]

I'm having a problem with false FT8 positives firing off alerts.

?

I grid chase (and DXCC chase) on 6m. With my cluster connections up and WSJT and JTAlert-x connected, I get frequent hits for stations where the grid information is incorrect. I'm not talking about "gibberish spots" here, but legitimate spots that trigger incorrectly.

?

The source, according to Spot Collector, is my own copy of WSJT-x. There have been numerous examples of a spot arriving via WSJT-X with one (ostensibly) correct grid, but it shows up in the DX Grid column in S.C. with a different grid, causing alerts to sound. I could understand if this was a station I'd worked previously and an old grid was being auto-populated, but this happens even with stations I've never worked before.

?

One such station CQs on FT8 from grid EM31, a grid I have previously worked, confirmed via LoTW, and verified for VUCC credit. The station shows up correctly in WSJT and JTAlert-X, but in Spot Collector it's showing this particular station as EM43, one of only two EM grids I've never worked. This isn't the only circumstance, but since the op in question (AC0RA) is an avid 6m operator with a good signal to me, alerts on his call are frequent.? But with many others the same thing is happening. JTAlert-x/WSJT has the grid correct according to the CQ sent by the originator, but S.C. gets it wrong.

AC0RA is an AVID Rover and has recently been in EM43...

AL, K0VM

?

Now, if this isn't already the case, I would respectfully suggest than any incoming spot for a station previously worked that has grid information populated by the FT8 software, that information needs to override any previous grid info from past QSOs in DXKeeper. Obviously this would be especially needed for Rovers. I have a suspicion that this is already the case, but I wanted to mention it here just in case. But with that said, I'd really like to understand why I'm getting so many false positives.

?

And speaking of false positives, when the inevitable gibberish print from WSJT causes a "need" alert is JTAlert (and subsequently in Spot Collector), is there any way to maybe put in a lookup or truth table, etc, within S.C. so I won't get woken up by a badly interpreted FT8 "spot"?

?

Or some way to say "only alert if X number of "new grid" or "new zone" (etc) spots are received within Y minutes? I'd typically want to set that at 3 within 1 or 2 minutes personally.

+ AA6YQ comments below

+ AA6YQ comments below

+ AA6YQ comments below

If you ever do find yourself with some free time, the feature to alert only if X spots are received within Y time would be most welcome. I leave everything running overnight with my antenna beamed towards Europe, so any early-morning trans-Atlantic activity to a new zone or entity will trip the alarm bells, but if only one spot, legit or bogus, arrives there's no need to crawl bleary-eyed into the shack on 3 hours' sleep. If I get 3 in 2 minutes, or even 2 in 30 seconds, then it's likely the start of a legit opening and it's time to caffeinate and get going. I'd say a similar condition for DXpeditions or needed entities would weed out fake spots.

+ Why not put a tablet next to your bed and use SpotCollector's web interface so you can directly determine whether it's worth getting up? See

<>

+ and

<>

73,

Dave, AA6YQ

On Wed, Jun 17, 2020 at 07:48 PM, Dave AA6YQ wrote:

((BAND='6M') AND (App_DXKeeper_LotW_Member<>'Y') AND (QSO_BEGIN > #2015-01-01#))

OK, that syntax worked with 353 results. Now to narrow it down to do what I need.?

Good to see the Fishy Script--took me a moment to figure out what it did. But can I use this in conjunction with and SQL filter to display only?QSOs with stations who will definitely?not?be able to confirm via LoTW? Display the grids and populate the log page so I can print off labels and start sending out cards?

I meant Spot Collector, of course. I had been chatting about my days with DX Base with a friend earlier tonight and I typed that unintentionally. I have corrected it in my original question, above.

I will test this out tomorrow (or whenever the band opens enough to see the usual flood of spots).

If you ever do find yourself with some free time, the feature to alert only if X spots are received within Y time would be most welcome. I leave everything running overnight with my antenna beamed towards Europe, so any early-morning trans-Atlantic activity to a new zone or entity will trip the alarm bells, but if only one spot, legit or bogus, arrives there's no need to crawl bleary-eyed into the shack on 3 hours' sleep. If I get 3 in 2 minutes, or even 2 in 30 seconds, then it's likely the start of a legit opening and it's time to caffeinate and get going. I'd say a similar condition for DXpeditions or needed entities would weed out fake spots.?

+ AA6YQ comments below

I just picked up a Yaesu FT-891 for POTA/SOTA use. It easily configured with the DXLabs Suite. I am curious if anyone has any User-defined Controls or sliders they would be willing to share. I looked in the Files section and did not see any for the 891.

+ Since Yaesu switched to a more Kenwood-like CAT instruction set, there's more commonality among the radios. The FT-2000 Audio Gain Slider, for example, should work with your FT-891. Some of the FTDX-3000 controls should also work with some or no modification.

+ Do you have a copy of the FT-891 CAT Operation Reference Book?

73,

Dave, AA6YQ

I just picked up a Yaesu FT-891 for POTA/SOTA use. It easily configured with the DXLabs Suite. I am curious if anyone has any User-defined Controls or sliders they would be willing to share. I looked in the Files section and did not see any for the 891.

Thanks in advance.
Scott - KN3A

+ AA6YQ comments below

I'm starting to get serious about confirming grids within North America that I have worked, but who never confirmed (usually because they're not on LoTW). I'm especially anxious to confirm any that are needed for "Fish points."

Is there a filter syntax that could select band=6m, grid worked/not-confirmed, LoTW User=No, and DXCC country in W, VE? And for good measure, age <= 5 years? I've tried a few different filters but I get stuck with grid worked but not confirmed. And even the relatively simple filter of "((BAND='6M') AND (App_DXKeeper_LotW_Member='N') AND (QSO_BEGIN > #2015-01-01#))" only turns up one result out of over 2800 QSOs on 6m.

+ As a first step, try

((BAND='6M') AND (App_DXKeeper_LotW_Member<>'Y') AND (QSO_BEGIN > #2015-01-01#))

<> means "not equal"

+ You might also take a look at the FFMA.txt script in DXKeeper's Scripts folder.

73,

Dave, AA6YQ

+ AA6YQ comments below

I'm having a problem with false FT8 positives firing off alerts.

I grid chase (and DXCC chase) on 6m. With my cluster connections up and WSJT and JTAlert-x connected, I get frequent hits for stations where the grid information is incorrect. I'm not talking about "gibberish spots" here, but legitimate spots that trigger incorrectly.

+ If you're using JTAlert, then JTAlert is the source of the gird information.


The source, according to Spot Collector, is my own copy of WSJT-x. There have been numerous examples of a spot arriving via WSJT-X with one (ostensibly) correct grid, but it shows up in the DX Grid column in S.C. with a different grid, causing alerts to sound. I could understand if this was a station I'd worked previously and an old grid was being auto-populated, but this happens even with stations I've never worked before.

One such station CQs on FT8 from grid EM31, a grid I have previously worked, confirmed via LoTW, and verified for VUCC credit. The station shows up correctly in WSJT and JTAlert-X, but in DX Base it's showing this particular station as EM43, one of only two EM grids I've never worked.

+ I can't help you with DX Base, Peter.


This isn't the only circumstance, but since the op in question (AC0RA) is an avid 6m operator with a good signal to me, alerts on his call are frequent. But with many others the same thing is happening. JTAlert-x/WSJT has the grid correct according to the CQ sent by the originator, but S.C. gets it wrong.

+ SpotCollector receives spots from JTAlert, but also from your other spot sources. If you have SpotCollector configured to capture location information from spot notes, then it's possible that a Spot Database entry created by JTAlert with one grid square gets updated with a different grid square from a subsequent cluster spot. To see if this is happening,

1. enable "Record individual spot information" (Configuration window, "Spot Database" tab)

2. when encounter a Spot Database Entry with what appears to be an incorrect grid square, right-click it, and select "Display spots of"; a window bearing all spots of the Entry's station will appear.


Now, if this isn't already the case, I would respectfully suggest than any incoming spot for a station previously worked that has grid information populated by the FT8 software, that information needs to override any previous grid info from past QSOs in DXKeeper. Obviously this would be especially needed for Rovers. I have a suspicion that this is already the case, but I wanted to mention it here just in case. But with that said, I'd really like to understand why I'm getting so many false positives.

+ Most users do not have a computer fast enough query their log for previous QSOs with each incoming spot.


And speaking of false positives, when the inevitable gibberish print from WSJT causes a "need" alert is JTAlert (and subsequently in Spot Collector), is there any way to maybe put in a lookup or truth table, etc, within S.C. so I won't get woken up by a badly interpreted FT8 "spot"?

+ No:

1. there is no database that specifies an award-accurate grid square for amateur radio station (DXLab's USAP database only contains callsigns issued by the US FCC, and the grid squares are not award-accurate because they are computed from the centroid of the station's zip code)

2. even if such a database existed, some stations operate from non-home locations


Or some way to say "only alert if X number of "new grid" or "new zone" (etc) spots are received within Y minutes? I'd typically want to set that at 3 within 1 or 2 minutes personally.

+ The mechanism required to implement this would require significant development effort, but most users want to be immediately notified if a needed station might be QRV and thus would not utilize it.

73,

Dave, AA6YQ

+ AA6YQ comments below

I don't know whether I am doing something wrong to make this happen, but lately whenever I import a contact with a Quebec (VE2 or VA2) amateur from an ADIF file that does not contain CQZ fields, DXKeeper is assigning the CQ zone in those contacts to be zone 2. This is almost invariably wrong. The vast majority of Quebec amateurs live in zone 5.

If there is grid square information in the ADIF file, as there usually is for FT8/FT4 contacts, then If the grid square is in FN and the province is QC, the zone is 5. Zone 2 is north of 50 degrees latitude, which means the second letter of the grid square is O (or P or Q or R), never N.

+ Thanks for sending me an illustrative ADIF record, Rich. It revealed that DXKeeper was incorrectly employing the specified grid square to disambiguate the CQ zone when importing a QSO with a Canadian station in the QC province. I have sent you a corrected version of DXKeeper to test. Please let me know how it goes.

73,

Dave, AA6YQ