Hi Stefan,
Your feedback is pretty appreciated because in some way demonstrates that this
is not a local issue in my environment.
I bet that there are many more cases like these around but supposedly the users
are ignoring to have it just because they aren't using such ref spec feature.
On
Hi Marco & group
On 19.10.21 20:00, Marco Calistri via wsjt-devel wrote:
My doubt now is that same issue could happens to others colleagues which
are using WSJT-X for Linux, for this reason I would like to have some
feedback on this topic.
I have the same issue and had reported it a few
Hi Joe,
Conrad may know more than I do, but the short answer is yes, Lance has been
making QSOs with his compound call despite issue #3, and yes, he does have some
intermittent internet access - he's been on the ON4KST EME chat today, and also
on email. Whether his internet is good enough to
Hello,
As reported by previous messages, I'm facing problem whenever I have
the "refspec.dat" file saved into the WSJT-X folder and I select it
in the wide-graph.
If I rename that file or delete it, then I can use the wide-graph
with Ref Spec enabled.
Hi Conrad,
What is the status of the FO/W7GJ expedition? Is Lance making 6m EME
QSOs as planned? I am concerned that he may not have adequately tested
use of a compound callsign in JT65 and Q65 modes with WSJT-X 2.5.0.
We have identified four problems that are likely affecting Lance's
On 14/10/2021 18:44, ON4PB via wsjt-devel wrote:
Hi,
I encountered this subprocess error when receiving an EME signal. The
sequence is as follows :
- Received mode is Q65 60B
- Nothing is decoded, changed to JT65B mode
- Clicked on the received signal in the waterfall and the following
Hi Lance,
On 10/17/2021 12:05 AM, Lance Collister, W7GJ via wsjt-devel wrote:
As I am currently on an EME DXpedition without any access to internet or
a reliable GPS puck that runs on Windows 10, it occurred to me that it
should be very easy to add a very helpful item to the Astronomical Data
On 10/19/2021 09:10, Reino Talarmo via wsjt-devel wrote:
Its there already, labelled as Delay.
Hi Charlie,
You may talk about totally different issue. User Guide states: delay
of your own EME echoes in seconds
The problem is accurate time. A correct DT is only possible, when a
time
MNI TNX!
On 10/19/2021 09:10, Reino Talarmo via wsjt-devel wrote:
Its there already, labelled as Delay.
Hi Charlie,
You may talk about totally different issue. User Guide states: delay
of your own EME echoes in seconds
The problem is accurate time. A correct DT is only possible, when a
That has been fixed in the latest hamlib.
You can download the appropriate 32-bit or 64-bit zip file from
herehttp://n0nb.users.sourceforge.net/
Extract the libhamlib-4.dll and replace the one in the WSJTX directory.
Mike W9MDB
On Tuesday, October 19, 2021, 05:11:40 AM CDT, Barry Jackson
The only note we have in hamlib is the Linux sets RTS/DTR high on opening and
we set it low.
We obviously can't debug your code for you but it sounds like you have the
wrong port when you deassert RTS. You should be able to create a test which
just toggles ptt on/off every second or so to
There seems to be a regression in hamlib-4.3.x which I have been testing
for our dev branch.
I maintain the wsjtx package for Mageia (Linux) and do all my testing
with my Kenwood TS-450S.
We use the system hamlib.
Fake-it works, but any attempt to use RIG for split now fails with the
Its there already, labelled as Delay.
Hi Charlie,
You may talk about totally different issue. User Guide states: delay of your
own EME echoes in seconds
The problem is accurate time. A correct DT is only possible, when a time
reference is available in some form. One less accurate
13 matches
Mail list logo
