HI !
Sorry if this is "known bug", but today I managed first time make a test
with DXpedition mode (TY7C / 17m)
and I have been lazy to read all messages through as there were them so
many after first official test.
As working DX is "a single event" I can not repeat this. Unless I hear
him
Tue, 13 Mar 2018 13:30:39 + (UTC)
Black Michael via wsjt-devel
kirjoitti:
> I believe perhaps we should have "Default" as an option on Data Bits,
> Stop Bits, Hand Shake, and Force Control Lines. That would prevent a
> lot of operator errors since hamlib already has defaults for all rigs
> t
On 13/03/2018 15:28, Rich - K1HTV wrote:
Yes Bill, I saw that but only the single suffix KG4 call was
mentioned. Just wanted to make sure that the KG4xxx triple suffixes
were also included.
HI Rich,
the defect you and Pino are reporting was nothing to do with which KG4
calls are not gitmo b
Yes Bill, I saw that but only the single suffix KG4 call was mentioned. Just
wanted to make sure that the KG4xxx triple suffixes were also included.
Thanks for all you continue to do to improve the already great WSJT-X FT8
software. Worked 3D2EU on Routma and H40YM on 60M at this morning's sunri
This change would be made such that it won't affect current settings at all.The
idea is simple enoughhamlib already has good defaults for most rigs...so
rather than force users to figure out what to do the 1st time they select their
rig with data bits, stop bits, and handshake it will use th
On 13/03/2018 15:19, Rich - K1HTV wrote:
Bill,
Not only KG4x but also KG4xxx calls need to identified as USA and
NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter
suffix should be identified as the Guantanamo Bay DXCC entity.
Presently KG4x or KG4xxx callsign show up as USA
Bill, Not only KG4x but also KG4xxx calls need to identified as USA and NOT Guantanamo Bay call signs. Only KG4 callsigns with a 2 letter suffix should be identified as the Guantanamo Bay DXCC entity. Presently KG4x or KG4xxx callsign show up as USA as they should, but are highlighted in purple.7
Hello,
To be useful, bug reports should include at least the following information:
Program version
1.9rc2 or 1.80
Operating system
raspbian on RaspberryPi2
Concise description of the problem
Monitoring Mode stops without notice.
Frequently monitoring Mode (green Button is on ) stops without noti
On 03/13/2018 03:30 PM, Bill Somerville wrote:
Hi Bill & All,
> very few rigs allow changes to stop bits or data bits so nobody should
> care as the defaults will just work.
While using the Yaesu FT2000, I could only get stable working conditions
when setting timeout=500,retry=2,write_delay=5,po
On 13/03/2018 14:51, John wrote:
I should have been specific: I was thinking about handshake..Default for
TS870s is None but mine doesn’t like that…
Not everyone is conversant with rigctl nor which -m number is required for
their rig…
Hi John,
RTS/CTS handshaking cannot be disabled on the
Hi Bill,
I should have been specific: I was thinking about handshake..Default for
TS870s is None but mine doesn’t like that…
Not everyone is conversant with rigctl nor which -m number is required for
their rig…
— John G4KLA
-
On 13/03/2018 14:27, John wrote:
Hi BIll and Mike,
As long as the Default settings are known - somewhere…
— John G4KLA
Hi John,
very few rigs allow changes to stop bits or data bits so nobody should
care as the defaults will just work.
Defaults can be listed using rigctl -L -m .
73
Bill
Hi BIll and Mike,
As long as the Default settings are known - somewhere…
— John G4KLA
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
On 13/03/2018 13:30, Black Michael via wsjt-devel wrote:
I believe perhaps we should have "Default" as an option on Data Bits,
Stop Bits, Hand Shake, and Force Control Lines. That would prevent a
lot of operator errors since hamlib already has defaults for all rigs
that generally work other th
I believe perhaps we should have "Default" as an option on Data Bits, Stop
Bits, Hand Shake, and Force Control Lines. That would prevent a lot of
operator errors since hamlib already has defaults for all rigs that generally
work other than COM port and Baud rate which most everybody understands
I have seen request to DXpedition-mode happen also two times.
Happened with "guess-decode" result (having "a2" at the end of decoded
line).
I assume that signal was so weak that decode was not clean, not that
someone was actually using DXpedition on conventional FT8 freq.
Perhaps DXpedition-
16 matches
Mail list logo
