开云体育

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

+ 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.

+ DXKeeper does not employ grid squares to disambiguate CQ zones.

+ What boxes do you have checked in the Options panel at the top of DXKeeper's "Import QSOs" tab?

+ Please place an ADIF record that illustrates this behavior in an email message, and send it to me via

aa6yq (at) ambersoft.com

+ Thanks!

73,

Dave, AA6YQ

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.

73,
Rich VE3KI

+ AA6YQ comments below

I use the sota cluster at cluster.sota.org.uk port 7300 with Spot Collector. Normally this works great but today, after 1603Z, I get no updates although SotaWatch3 on the web is working with no issues. Is it reasonable to assume a problem at the cluster end in situations like this?

+ On the "Spot Sources" tab of SpotCollector's Configuration, uncheck that cluster's Hide and the Ann/Talk boxes to display a window that shows SpotCollector's interaction with the cluster. Click this window's Disconnect button, and then click its Connect button; does an error message appear?

+ If you see no interaction with the cluster, then either the cluster is offline or unreachable, or something is preventing SpotCollector from interacting with it (anti-malware being a likely candidate).

73,

Dvae, AA6YQ

I use the sota cluster at cluster.sota.org.uk? port 7300 with Spot Collector. Normally this works great but today, after 1603Z, I get no updates although SotaWatch3 on the web is working with no issues.
Is it reasonable to assume a problem at the cluster end in situations like this?
K7TP

On 17/06/2020 08:44, John Merrill N1JM wrote:

I don't know, but I can control frequency on my MacBook Pro using the 590s USB port with RumLogNG and run and control the 590 with SDR Console on it's db9 com port with a PC. Of course when you change the frequency on one it changes to the same on the other; and other combinations. I've done this for a long time. That's a great feature of a TS-590. You don't have to use VSP or some similar program to control a radio through it's only comport with more than one program.

John N1JM

John,

have you tried Dave's solution of using the secondary CAT port in Commander to control SDR Console?



--
73

Bill

G4WJS.

I don't know, but I can control frequency on my MacBook Pro using the 590s USB port with RumLogNG and run and control the 590 with SDR Console on it's db9 com port with a PC. Of course when you change the frequency on one it changes to the same on the other; and other combinations. I've done this for a long time. That's a great feature of a TS-590. You don't have to use VSP or some similar program to control a radio through it's only comport with more than one program.

John N1JM

In de PST rotator DXLAB tracker setup choose the bands you want to control.
PSTrotator uses Commander to query the frequency.
DXView is used to point PST rotator to the direction.
If you click on SpotCollector it will track dxview.

73 Henk PA5KT

+ AA6YQ comments belolw

When I change the UDP port number in the Spot Source Config it works.
When I close SpotCollector? and start it again it defaults back to 2237.

Can it be changed that it remembers the port?

+ Already corrected in the next version of SpotCollector.

73,

Dave, AA6YQ

Dave,

When I change the UDP port number in the Spot Source Config it works. When I close SpotCollector? and start it again it defaults back to 2237.

Can it be changed that it remembers the port?

73 Henk PA5KT

+ AA6YQ comments below

I can run Spectraview okay connected to the 590s comport and DXlabs Commander to the 590s USB port no problems. SDR Console must be a different animal :-).

+ Where in the TS-590S specification does it state that independent CAT instruction streams can be simultaneously sent to its COM and USB ports?

73,

Dave, AA6YQ

On Tue, Jun 16, 2020 at 05:03 PM, Dave AA6YQ wrote:

https://www.dxlabsuite.com/dxlabwiki/SDRTopics>

I can run Spectraview okay connected to the 590s comport and DXlabs Commander to the 590s USB port no problems. SDR Console must be a different animal :-).

+ AA6YQ comments below

I run SDR Console on the comport and DXLabs on the USB port but they don't like each other for some reason even though they are on different comports. SDR Console just freezes up and DXlabs loads extremely slow. I don't have that problem say with N!MM and SDR Console. Has anyone seen this? Maybe they are trying to share some common files.

73, John N1JM