I will ask the author of PSTRotator. If I find out anything I will let you know.
On Sat, Jun 13, 2020 at 11:04 AM Dave AA6YQ < aa6yq@...> wrote: + AA6YQ comments below
I see PSTRotator is listed under the Bridges, Gateways, and Extenders section. There is no documentation listed there.
+ No documentation has ever been provided by the author of PSTRoratorAZ
How is PSTR integrated into DXL so I can just double click a SpotCollector and have PSTR move my antenna?
+ See
<>
? ? ? ? 73,
? ? ? ? ? ? ? ? Dave, AA6YQ
|
Re: DXLabs, WSJT-X (ft8) and Yaesu FT-950
On 14/06/2020 01:39, Jerome Sodus
wrote:
Hello Dave,
Relative to Bill G4WJS's reply, I'm making a command sequence to
put VFO-A in USB and VFO-B at USB-PKT; both set at 7074000 Hz.
It is not working; perhaps you can spot my error(s) or
omission(s).
Here is my code per Yaesu's CAT-manual and your email about
'split':
FA7074000;
MD02;
FB7074000;
MD0C;
FT3;
TIA for any help.
73 jerry km3k
PS..it is a great feeling to be 'coding' again.
Jerome,
you don't need to set any frequencies or SPLIT. Try this:
'VS1;
'MD0C;
'VS0;
'MD02
<END>
This is assuming that the FT-950 does limit the Rx passband in
USB-DATA mode, the user manual doesn't make it clear. If it
doesn't then just check the WSJT-X option
"Settings->Radio->Mode->Data/Pkt" and let WSJT-X sort it
out for you.
-- 73
Bill
G4WJS.
|
I tried several times to capture a screen shot of the fast closing QRZ error screen. After 8 attemps, I got successful.
There was a window which stated the wrong verification code was entered.? Then it dawn on me.
?
I had to remove the 2 step verification code that QRZ put on my account.
All is working great now.
Tim - N8NEU
DMR ID 3158619
FN00ah
toggle quoted message
Show quoted text
-------- Original message --------
From: Dave AA6YQ <aa6yq@...>
Date: 6/13/20 19:56 (GMT-05:00)
Subject: Re: [DXLab] Pathfinder
+ AA6YQ comments below
Pathfinder does not auto log into my QRZ account.
The name and password are correct. Both "Atuomatic login" and "Warn if not logged in" are checked.
When I click on the "Login" button from the Configuration window the QRZ web page opens then closes.
I get a second window entitled "QRZ.COM Login" with the statement "not loggged-in to QRZ.com".
Is there anything that needs to be done?
+ Confirm that you've specified the correct QRZ.com password on Pathfinder's Configuration window. You can test this by using it to log in to QRZ.com via a web browser.
Does Commander need to be running?
+ No other applications need be running.
????? 73,
??????????? Dave, AA6YQ
?????
|
Re: DXLabs, WSJT-X (ft8) and Yaesu FT-950
+ AA6YQ comments below
Here is my code per Yaesu's CAT-manual and your email about 'split':
FA7074000;
MD02;
FB7074000;
MD0C;
FT3;
+ When specifying CAT instructions in a Command Sequence, instructions specified in ASCII (as opposed to hexadecimal) must be preceded by a single apostrophe:
' FA7074000;
'MD02;
'FB7074000;
'MD0C;
'FT3;
<END>
+ Some advice: proceed one instruction at a time. In this case, start with a sequence that just issues
' FA7074000;
+ Then add the
'MD02;
+ This quickly exposes cases where adding the second command causes the first command to malfunction. For example, some radios require that the mode be changed before changing the frequency, and some vice versa. And in some cases (cough Elecraft cough), it may be necessary to insert <WAIT> instructions between commands.
73,
Dave, AA6YQ
|
Re: DXLabs, WSJT-X (ft8) and Yaesu FT-950
Hello Dave,
Relative to Bill G4WJS's reply, I'm making a command sequence to put VFO-A in USB and VFO-B at USB-PKT; both set at 7074000 Hz.
It is not working; perhaps you can spot my error(s) or omission(s).
Here is my code per Yaesu's CAT-manual and your email about 'split':
FA7074000;
MD02;
FB7074000;
MD0C;
FT3;
TIA for any help.
73 jerry km3k
PS..it is a great feeling to be 'coding' again.
|
+ AA6YQ comments below
But logging into eqsl.cc shows that eQSL considers them a match and thereby represents a confirmed QSO.
Although somewhat questionable, I therefore propose DXKeeper considers MFSK without submode and FT4 as the same mode for eQSL confirmations.
+ That would be propagating a defect in eQSL to DXKeeper. No thanks.
+ I will alert Dave N5UP of eQSL.cc.
73,
Dave, AA6YQ
|
+ AA6YQ comments below
He might be referring to the fact that some QSO's in eQSL come through as just MFSK, while the majority comes through as MFSK(FT4).
+ Sounds like one or more logging applications are not correctly submitting FT4 QSOs to eQSL. If you submit a QSO to eQSL.cc whose mode is MFSK (instead of FT4), it will believe you.
If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO that is logged as FT4 in DXKeeper
+ That's correct.
73,
Dave, AA6YQ
|
+ AA6YQ comments below
Pathfinder does not auto log into my QRZ account.
The name and password are correct. Both "Atuomatic login" and "Warn if not logged in" are checked.
When I click on the "Login" button from the Configuration window the QRZ web page opens then closes.
I get a second window entitled "QRZ.COM Login" with the statement "not loggged-in to QRZ.com".
Is there anything that needs to be done?
+ Confirm that you've specified the correct QRZ.com password on Pathfinder's Configuration window. You can test this by using it to log in to QRZ.com via a web browser.
Does Commander need to be running?
+ No other applications need be running.
73,
Dave, AA6YQ
|
Pathfinder does not auto log into my QRZ account.
The name and password are correct. Both "Atuomatic login" and "Warn if not logged in" are checked.
When I click on the "Login" button from the Configuration window the QRZ web page opens then closes.
I get a second window entitled "QRZ.COM Login" with the statement "not loggged-in to QRZ.com".
Is there anything that needs to be done?
Does Commander need to be running?
Normally I just run DXKeeper, DXView and now I am trying Pathfinder.
I am not into DX, I dont have a rotating beam and only work with 100 watts on voice and 30 watts on digital. My antennas are a Butternut HF6V and a 130 foot end fed.
Tim - N8NEU
DMR ID 3158619
FN00ah
|
Re: Commander loosing control of radios
+ AA6YQ comments below
Every time I did an error log it was too large to email so I just ran 14.3.1.
I didn't change any radio settings from 14.3.1 but all the proceeding updates lost connection until 14.6.2.
+ A wild guess: one of your anti-malware applications was interfering.
73,
Dave, AA6YQ
|
Re: Commander loosing control of radios
Every time I did an error log it was too large to email so I just ran 14.3.1.
I didn't change any radio settings from 14.3.1 but all the proceeding updates lost connection until 14.6.2.
Tom
toggle quoted message
Show quoted text
On 6/13/2020 4:04 PM, Dave AA6YQ wrote: + AA6YQ comments below
Commander 14.6.2 solved the problem.
I installed Commander 14.6.2 on 6/4 and it found my FT-2000? and it has not lost control of it since and I run my computer 24/7. All
updates of Commander after 14.3.1 have lost control so I have been running 14.3.1. I did not change anything just installed 14.6.2
and it worked.
One of the intermediate upgrades lost my FT-847 and my computer does not talk to it so now I have to trouble shoot that.
+ When you first reported this behavior back in early April, I asked you to send me an errorlog.txt file:
< /g/DXLab/message/192901>
+ I have no record of receiving an errorlog.txt file from you in response to this message.
+ None of the changes made in Commander 14.6.2 (compared to its predecessor) had anything to do with radio interaction: the changes
were limited to extending user-defined Command Sequences and RadioInfo UDP messages:
< >
73,
Dave, AA6YQ
|
Although somewhat questionable, I therefore propose DXKeeper
considers MFSK without submode and FT4 as the same mode for eQSL
confirmations. Absolutely not! MFSK without a sub-mode can be any of number of "modes" including MFSK8, MFSK16, and JS8 each of which are recognized for various award programs. Accepting MFSK as equivalent to MFSK(FT4) is equivalent to accepting PSK as equivalent to PSK(PSK31) or PSK(PSK63) or PSK(PSK125), etc. The proper solution is to get the station that uploaded the QSO with MODE=MFSK SUBMODE=<none> to fix his/her upload as either MODE=FT4 (not ADIF compliant) or as MODE=MFSK SUBMODE=FT4 (correct). eQSL *should* refuse to accept QSOs with MODE=MFSK SUBMOD=<none> or treat them as "data only". 73, ... Joe, W4TV On 2020-06-13 4:03 PM, Bj?rn Ekelund, SM7IUN wrote: Yes.
But logging into eqsl.cc shows that eQSL considers them a match and thereby
represents a confirmed QSO.
Although somewhat questionable, I therefore propose DXKeeper considers MFSK without?submode
and FT4 as the same mode for eQSL confirmations.
Bj?rn
Den l?r 13 juni 2020 kl 21:57 skrev Bernd - KB7AK <bernd1peters@... <mailto:bernd1peters@...>>:
He might be referring to the fact that some QSO's in eQSL come
through as just MFSK, while the majority comes through as MFSK(FT4).
If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO
that is logged as FT4 in DXKeeper, I usually have one of 2 each week.
|
Re: Commander loosing control of radios
+ AA6YQ comments below Commander 14.6.2 solved the problem. I installed Commander 14.6.2 on 6/4 and it found my FT-2000? and it has not lost control of it since and I run my computer 24/7. All updates of Commander after 14.3.1 have lost control so I have been running 14.3.1. I did not change anything just installed 14.6.2 and it worked. One of the intermediate upgrades lost my FT-847 and my computer does not talk to it so now I have to trouble shoot that. + When you first reported this behavior back in early April, I asked you to send me an errorlog.txt file: < /g/DXLab/message/192901> + I have no record of receiving an errorlog.txt file from you in response to this message. + None of the changes made in Commander 14.6.2 (compared to its predecessor) had anything to do with radio interaction: the changes were limited to extending user-defined Command Sequences and RadioInfo UDP messages: < > 73, Dave, AA6YQ
|
Re: Commander loosing control of radios
Dave,
Commander 14.6.2 solved the problem.
I installed Commander 14.6.2 on 6/4 and it found my FT-2000? and it has not lost control of it since and I run my computer 24/7. All updates of Commander after 14.3.1 have lost control so I have been running 14.3.1. I did not change anything just installed 14.6.2 and it worked.
One of the intermediate upgrades lost my FT-847 and my computer does not talk to it so now I have to trouble shoot that.
Tom WN?DRC
toggle quoted message
Show quoted text
On 4/13/2020 5:06 PM, tgzuber wrote:
I been having trouble with commander loosing control of my radios and sent an email earlier about it. At that that time I checked all ports to make sure they would not turn off automatically and set Windows Defender (the only anti-virus program on my computer) to accept the DXLabs folder as well as all the individual folders within the main folder.
After doing some checking around, I have found that Commander 1426 works without a glitch. All versions after that produce the connection loss problem. Commander versions 1431 and up will loose contact after 1/2 hour or there abouts. Last week when Version 1455 became available I installed it and upon running it discovered it looses contact every 5 minutes.
I'm happily running 1431 but am curious why later versions are causing the problem. My radios are Yaesu FT-2000 and Ft-847 and my computer is a 6 month old intel i5 with Windows 10Pro..
Any clues would be appreciated.
Tom WN?DRC
|
Re: Windows Defender Deleted Commander and Cannot Reinstall
In my opinion the method of telling defender to consider anything in the FOLDER with your DXLABS as safe is much easier and MUCH MUCH cheaper. Why pay the price of NOD#@ which is not a one time either? A good backup, care of what you click, and the order to defender will make all well I have a lot of programs om different systems and Defender has not been a problem with any others. The DXLABS program gets many updates and it is hard for Defender to keep up. There is no guarantee whatsoever that AMY AV will catch everything FALSE Positives WILL OCCUR AND EVEN WORSE false NEGATIVES WHICH ARE WORSE AND nnods32 IS O MOR3E CERTAIN TO PREVENT ZERO DAY DEFECTS TAN ANY POTHER.
Backup and do not run anything you are not certain is good.
Outlook Laptop Gil W0MN
Hierro candente, batir de repente
44.08226N 92.51265W EN34rb
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Salvatore Besso Sent: Saturday, June 13, 2020 13:58 To: [email protected]Subject: Re: [DXLab] Windows Defender Deleted Commander and Cannot Reinstall the permanent fix is to use a serious product (I'm more than happy with NOD32) which disables windows "offender". 73 de Salvatore (I4FYV) -- W0MN EN34rb 44.08226 N 92.51265 W Hierro candente, batir de repente HP Laptop
|
Hi Bj?rn,
that is very questionable. Accepting an
electronic QSL with a mode of 'FT4' as an FT4 QSO is acceptable,
although not ADIF compliant. Accepting an electronic QSL with a
mode of 'MFSK' and sub-mode of 'FT4' is perfectly acceptable and
ADIF compliant. Accepting an electronic QSL with a mode of 'MFSK'
and no sub-mode *may* be acceptable as a "DATA" QSL match to a
local FT4 QSO record, but really there is a problem upstream that
needs resolving. It is not the gift of DXKeeper to guess if a QSO
2-way match was in FT4 mode if there is no information to back
that up.
73
Bill
G4WJS.
On 13/06/2020 21:03, Bj?rn Ekelund,
SM7IUN wrote:
toggle quoted message
Show quoted text
Yes.?
But logging into eqsl.cc shows that eQSL considers them a
match and thereby?
represents a confirmed QSO.
Although somewhat questionable, I therefore propose
DXKeeper considers MFSK without?submode?
and FT4 as the same mode for eQSL confirmations.
Bj?rn
He
might be referring to the fact that some QSO's in eQSL come
through as just MFSK, while the majority comes through as
MFSK(FT4). If a QSO is logged as MFSK in eQSL it cannot be
matched to a QSO that is logged as FT4 in DXKeeper, I usually
have one of 2 each week.?
|
Yes.?
But logging into eqsl.cc shows that eQSL considers them a match and thereby? represents a confirmed QSO.
Although somewhat questionable, I therefore propose DXKeeper considers MFSK without?submode? and FT4 as the same mode for eQSL confirmations.
Bj?rn
He might be referring to the fact that some QSO's in eQSL come through as just MFSK, while the majority comes through as MFSK(FT4). If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO that is logged as FT4 in DXKeeper, I usually have one of 2 each week.?
|
He might be referring to the fact that some QSO's in eQSL come through as just MFSK, while the majority comes through as MFSK(FT4). If a QSO is logged as MFSK in eQSL it cannot be matched to a QSO that is logged as FT4 in DXKeeper, I usually have one of 2 each week.?
|
Thank you,, sorry i should not have put it here.
|
Re: Windows Defender is quarantiing Commander again
Hi Dave and the Group,
For while Windows Defenders was the recommended virus protection software but all things change especially when M$ is involved.? Any recommendations for a replacement product that only needs to be told once that a program is safe to use?
73, George
W2GS
toggle quoted message
Show quoted text
On 6/13/2020 12:44 PM, Dave AA6YQ wrote: As stated in Note #1 in
<>
I submitted Commander to Microsoft's "Submit a file for malware analysis" page
<>
with "Microsoft Defender Antivirus (Windows 10)" as the selected security product to scan the file.
The "Client" and "Cloud" results at the time (June 10) were both "no malware detected", but when I check the status today, the
"Client" status is still "No malware detected", but the "Cloud" status has changed to "Trohan:Win32/Azden.Blcl".
As shown in the above release note, all 80 online virus scanners accessible via the "Virus Total" and "Jotti" web sites found no
malware in Commander 14.6.2.
Windows Defender is clearly broken. If you choose to continue using it, you should expect it to quarantine your DXLab applications
from time-to-time.
Control your computing environment, or it will control you!
73,
Dave, AA6YQ
|
Kent N6WT
Tim
Gilbert Baron W0MN
Bj?rn SM7IUN