On 18/07/2021 03:31, Alex Lelievre via wsjt-devel wrote:
Hi there,
I’m running into an error in the fortran portion of the WSJT-X project
on MacOS X. I’m reaching out to see if anyone has bumped into this:
[ 17%] Built target record_time_signal
[ 17%] *Automatic MOC for target fort_qt*
[ 17
Thankyou, however I see, to be compatible with install instructions ;
git clone git://git.code.sf.net/p/wsjt/wsjtx src
,however I adapted to suit, I note that linquist requires qttools5-dev
installed.
Also ; cmake --build . --target install
should really show ; sudo cmake --build . --
Every ham with a modern HF rig has a simple, accurate, and reliable way of
getting the correct time. It's called WWV. If you can't hear WWV on at least
one frequency you either need to do some more antenna work or the bands are in
such bad shape you won't make many contacts anyway.
Other parts
Yes, there is a utility http://www.dxshell.com/jtsync.html that willdo exactly what you want. It syncs either via ntp or if there is nonetwork it is using a very clever methode do average received FT8/FT4signals to set your clock. Extreme late or early transmissions intime are ignored.73sWolfgang O
Like you said the issue here is getting an accurate reference time.
Two options you might consider:
1. If you’re internet connected you could get time a trusted over network time
protocol (NTP)
2. In outdoor setting (sounds like it is more applicable) you can get a trusted
time from a GPS recei
Hi there,
I’m running into an error in the fortran portion of the WSJT-X project on MacOS
X. I’m reaching out to see if anyone has bumped into this:
[ 17%] Built target record_time_signal
[ 17%] Automatic MOC for target fort_qt
[ 17%] Built target fort_qt_autogen
[ 17%] Built target fort_qt
[
OM,
On 18.7.2021 6.30, Adrian via wsjt-devel wrote:
What is the correct url for the git repo please ?
vk4tux
Try this: git clone git://git.code.sf.net/p/wsjt/wsjtx wsjt-wsjtx
IMHO it's much easier to use the source tarball from the WSJT-X page
https://physics.princeton.edu//pulsar/k1jt/ws
What is the correct url for the git repo please ?
vk4tux
On 18/7/21 12:20 pm, Paul Bramscher via wsjt-devel wrote:
I don't download from the git repo, though, and instead just get the
current source .tgz from SourceForge. Have you had success with that
method?
73, KD0KZE / Paul
I have been compiling WSJT-X for a number of years now on Debian
(including Buster 10 now), occasionally with help from G4WJS, and have
had no troubles in a long while.
I don't download from the git repo, though, and instead just get the
current source .tgz from SourceForge. Have you had success
I was at a monthly outdoor ham event in the greater St. Paul/Minneapolis
area that's drawn loyal attendance the past few years. An operator
setup FT8 outdoors, but had some issues getting it to decode. We could
tell it was getting sound from his port, but there was no decoding.
He was using Wind
Hi Joe,
Is that a new requirement for the tx offset to move to the calling station tx
offset ?As far as I know, that is not the behavior in 2.4 and earlier versions.
73,
Sam W2JDB
-Original Message-
From: Joe Taylor via wsjt-devel
To: WSJT software development
Cc: Joe Taylor
Sent: S
If you want your Tx frequency to change to that of the CQ caller, hold
CTRL down when you double-click on the CQ message.
On 7/17/2021 4:44 PM, Rory Bowers via wsjt-devel wrote:
I just noticed that rc3 is behaving the same as rc1 did with respect to
double clicking a station calling CQ TEST in
Hi Rory,
WSJT and WSJT-X are weak-signal communication tools. They have never
attempted to be like mature contesting software. It's easy to do what
you need, but it's not automatic. If you're using WSJT-X by itself in a
contest, wthout N1MM+ or other contesting software, start the contest
I just noticed that rc3 is behaving the same as rc1 did with respect to
double clicking a station calling CQ TEST in NA VHF mode. The transmit
frequency stays where you last were and the receive frequency moves to the
station calling CQ TEST. Hold TX Freq is not checked therefore shouldn't
both t
This one is going to be difficult to explain Joe but I am going to give it
a try. I am now running rc3 and working the CQ WW VHF contest in NA VHF
mode. I am finding a lot of stations working the contest that I have
worked before non-contest. For the sake of the contest I would like to
work then
Sorry Joe,
I guess I need to get caught up! I really like Q65 Joe... pure genius!
73,
Rory, K5CKS
On Sat, Jul 17, 2021 at 2:40 PM Joe Taylor via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:
> Rory --
>
> Release candidates for WSJT-X 2.5.0 are now up to -rc3, released two
> weeks ago.
Hi Claude,
This may not comfort you much, but just for fun and giggles I installed
Debian Buster onto a virtual machine
and then cloned Hamlib and WSJT-X from git. Compiled, and got a working
WSJT-X.
So *something* may not be right in your system. I have no idea what that
could be though, so
Rory --
Release candidates for WSJT-X 2.5.0 are now up to -rc3, released two
weeks ago. RC4 will be out soon.
When involved in beta testing, please keep up with new releases. We are
always especially interested in comments on the latest one.
-- 73, Joe, K1JT
On 7/17/2021 3:20 PM,
I found two new issues with 2.5.0 rc1 today.
1. In MSK144 mode when you double click on a station heard the timeslot is
changed to the same as the calling station.
2. In NA VHF Contest mode double clicking on a station calling CQ TEST in
the Band Activity window moves only the RX Frequency not both
I recommend adding sid to source & update, I found it very beneficial
with wsjtx on Debian 10 here.
# deb cdrom:[Debian GNU/Linux 10.6.0 _Buster_ - Official amd64 xfce-CD
Binary-1 20200926-10:17]/ buster main
# deb cdrom:[Debian GNU/Linux 10.6.0 _Buster_ - Official amd64 xfce-CD
Binary-1 20
On 7/16/21 6:38 PM, Bill Somerville via wsjt-devel wrote:
Hi Bill and all,
I'm not sure why you are getting that error. The libthread_db library is
used by debuggers to access thread information so I am surprised it is
being referenced. Is this a debug configuration build?
I don't have set e
Guesswork, but it looks like the two streams are conflicting somehow?
Maybe if the USB hubs are external and not independently powered try using
direct connections?
Otherwise you could try running the 890 using RS232 and separate audio
connections?
No idea on debugging software, search engi
This is a showstopper; the USB hubs are set so that power saving is not active.
Does anybody have any ideas?
Regards
Conrad PA5Y
From: Conrad PA5Y via wsjt-devel
Sent: 17 July 2021 07:52
To: wsjt-devel@lists.sourceforge.net
Cc: Conrad PA5Y
Subject: [wsjt-devel] wsjt-x v2.5.0-rc3
Good mornin
Jim,
Exactly. The openings may last 30-60 minutes, in general, but the path between
any two specific stations is typically short-lived. The geographic footprint
may have a radius of 100 km or so at either end, and moves with time.
The reason I'm continuing this seemingly off-topic discussion
On 7/17/2021 2:59 AM, jan0--- via wsjt-devel wrote:
It is characteristic of this propagation phenomenon between NA and AS on
6m that the opening between any given pair of stations is brief: One or
two minutes is not uncommon.
That depends a LOT on which part of the US and which DX country. He
It is characteristic of this propagation phenomenon between NA and AS on 6m
that the opening between any given pair of stations is brief: One or two
minutes is not uncommon. For this reason, stations on both sides, NA and AS,
typically start QSOs by calling with the Tx2 message, thereby increa
On 7/16/2021 11:33 PM, Derek Turner via wsjt-devel wrote:
Is it just coincidental that of the 33 log records only two contain
Maidenhead locators.
Nope. I've probably worked close a hundred JAs, and I count count the
ones who call with their grid without taking my shoes off. But JA hams
are n
27 matches
Mail list logo
