On 9/2/21 12:33 PM, Alan via wsjt-devel wrote:
> Thanks, all seems promising to me and I look forward to seeing it!
>
> So far as I'm aware a mag loop, particularly on a lower HF band, could
> well need retuning for a 3kHz change as might a heavily electrically
> loaded antenna.
I knew loops
On 9/2/21 2:26 AM, alan2--- via wsjt-devel wrote:
>
> Hi, I've been following this thread with interest and have a few
> questions/comments please:
>
> If the proposed protocol frequency changes are set to use the wider
> bandwidth of a SDR receiver linked to a T/R switch with a standard
> voice
On 9/2/21 1:35 AM, Jim Brown via wsjt-devel wrote:
> On 9/1/2021 11:32 PM, Phil Karn via wsjt-devel wrote:
>> I don't see that that necessarily follows.
>
> At this point, I think it is appropriate to note that the developers
> of this software are VERY bright, have care
On 8/29/21 12:30 PM, Gordon Weast via wsjt-devel wrote:
> Ed,
>
> When I look at decodes on 20m today, I've seen multiple times when
> signals offset by as little as 1 Hz are decoded just fine.
> Basically, the protocol works fine with lots of overlap. There is NO
> need to channelize
On 8/28/21 11:04 PM, Claude Frantz via wsjt-devel wrote:
> Hi all,
>
> These references are interesting, but we have to remember that we are
> speaking about HF communication on short-wave bands, in half duplex
> mode. None of the actors (the stations on the band) has a full
> knowledge of the
On 8/28/21 6:30 AM, Black Michael via wsjt-devel wrote:
> 50Hz channels won't work due to skirts on the 50hz spread, rig
> frequency inaccuracies and sound card non-linearity effects (e.g.
> 2000Hz is not the same real freq offset as 200Hz). 60 Hz would be a
> better channel width or 55Hz might
On 8/28/21 5:50 AM, jan0--- via wsjt-devel wrote:
> If a channelized scheme is introduced to avoid recurrent channel collisions,
> care should be taken not to reduce the network throughput. As anyone who
> has visited 14.074 lately can attest, for much of the day there is more
> channel demand
On 8/28/21 3:56 AM, William Smith via wsjt-devel wrote:
> Interesting idea, a couple of thoughts come to mind (not that you haven't
> already considered them):
>
> When you are only listening, you have a good idea of who else is transmitting
> when/where, but as soon as you start transmitting,
On 8/27/21 22:23, Adrian via wsjt-devel wrote:
Probably in future more 3KHz slots will be allocated, with the user
relying on spot reports to hone into signals desired.
It is the law of the jungle now, with experienced operators looking
for clear space to hold TX.
The whole idea here is to
On 8/27/21 16:20, Stan Gammons via wsjt-devel wrote:
Band planning is good idea. I've failed to understand why a given
segment of the bands were agreed on for JT65, JT9, FT4, FT8 and so
forth. Seems better to operate with any of those mode on any part of the
RTTY and data segments of the bands.
On 8/27/21 15:55, Grant VK5GR via wsjt-devel wrote:
Phil,
As part of a multi-region IARU Band planning sub-committee we are working on
getting agreement to expand the FT8 band to enable at least 2-3 FT8 "3kHz"
channels per band.
Could your frequency hopping idea be expanded so that the
On 8/27/21 1:23 PM, H.Shrikumar KA6Q wrote:
> I've had such ideas also, so adding to this:
>
> Do the hashing only when starting a CQ, not in the midst of a QSO.
Why not change it in the middle of a QSO? Any transmission (CQ or
otherwise) can potentially collide with another, and since the
While composing another message I had an idea that might help reduce
FT-8 congestion.
Every FT-8 receiver listens to an entire "band" (approximately 1 SSB
bandwidth) and it will hear and decode every station transmitting
anywhere in it. This makes each station's exact transmit frequency
On 8/14/21 06:55, Bill Somerville via wsjt-devel wrote:
Hi Mike,
it is not cleared automatically. TBH it's not a big deal as hash
collisions that cause incorrect decodes are rare since the vast
majority of WSPR transmissions are Type 1 messages. We normally
suggest deleting it if someone
The hash function used in wspr is 15 bits wide, i.e., there can be
32,768 values. This may seem like a lot, but the "birthday paradox" says
that the probability of a collision grows faster than you might expect
as the set size grows. It comes from the fact that you only need ~23
people to have a
On 8/11/21 03:24, Bill Somerville via wsjt-devel wrote:
On 11/08/2021 04:04, Phil Karn via wsjt-devel wrote:
In wsprd.c/writec2file() the output file is opened for writing but never
closed.
--Phil
Hi Phil,
Thanks! Repaired for the next release.
You're welcome!
A general suggestion
On 8/11/21 06:04, Bill Somerville via wsjt-devel wrote:
another option that requires no code changes is as follows:
1) Create wisdom as above but without the '-T 1' option,
2) Rename the newly created wisdom to wspr_wisdom.dat in the expected
directory,
3) Make the wspr_wisdom.dat file
On 8/11/21 05:35, Bill Somerville via wsjt-devel wrote:
thanks for your considered suggestions. One wrinkle is that on MS
Windows it appears that there is no system wisdom:
https://github.com/FFTW/fftw3/blob/master/api/import-system-wisdom.c
Not a show-stopper but will complicate things
I'd like to make another suggestion. Somewhere near the top of
wsprd.c/main(), insert the following code:
// FFTW plan files without threads are incompatible with plan files
with threads (even 1 thread)
// To keep compatibility with system wisdom created by other
programs that use FFTW
In wsprd.c/writec2file() the output file is opened for writing but never
closed.
--Phil
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
On 8/9/21 02:39, William Smith wrote:
Personally I want my stuff to be _able_ to operate independently of
the Internet, though I'm happy to have it around for normal operation,
and to detect (for a recent instance) things like my external GPS
antenna on my local Pi4-based NTP server failing.
On 8/8/21 6:41 PM, H.Shrikumar KA6Q wrote:
> Comments inline, old-school (the way it was meant to be) ...
Right!!
> Indeed. But loosing SNR in the decoder denies the Gods of Propagation
> their due offerings, ... so lets count that out. And then there is the sync
> vector itself, of which you
On 8/8/21 15:20, Phil Karn wrote:
Phil, have you tried playing with the c2 input instead of wav? You could
feed it I-Q from your SDR signal chain, in that case. Would perform
better, no? Its mentioned in the man page, but I havent tried it yet.
I've noticed the c2 file stuff, and yes I
On 8/8/21 13:20, H.Shrikumar KA6Q wrote:
A side question related to wsprd which I've been meaning to ask for a while
-- it is not clear from the documentation/examples that come with wsprd,
how wsprd deals with time-sychronization.
Is it the case that wsprd expects the WSPR pkts to start
Hi. I've gotten wsprd working with my own SDR. I wrapped a program
around it that receives a RTP (Real Time Protocol) stream over the
network from my SDR, creates a 2-minute long .wav file, and invokes
wsprd on it. Works great once I realized that it ignores the .wav header
and expects a mono file
On 6/12/20 10:33 AM, Steven Franke via wsjt-devel wrote:
> You’ll notice that the number of Fano iterations is limited to only 500.
> Testing here indicated that this virtually eliminated false decodes from the
> Fano decoder which, in turn, results in a much cleaner hashtable.txt file.
How
On 5/16/21 09:15, Nico Palermo wrote:
> Hi Phil,
>
> I don't know what Joe used in WSPR but, for instance, he told me that
> he generated the sync sequence used in Q65 by means of direct optimization
> of its autocorrelation function, not in an algebraic way, so that its
> lateral peaks
> were
On 5/16/21 09:57, Joe Taylor wrote:
> Hi Phil,
>
> There was no generator polynomial, as such. Rather, the sync vector
> was chosen for its good autocorrelation properties simply by looking
> at a very large number of randomly generated bit patterns of the
> required length and weight.
>
> --
Does anyone have the PN generator polynomial for the WSPR sync vector?
The source code seems to have only the generated (sub)sequence, not the
algorithm for generating it.
Thanks!
Phil
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
On 3/6/18 08:05, Bill Somerville wrote:
>
> Our experience of users using the Elecraft remote kit using IP streaming
> is that latency and delay are a problem, this being because of our
> dependence on external wall clock synchronization. Can RTP provide
> absolute time-stamp information that we
On 3/7/18 01:33, Игорь Ч via wsjt-devel wrote:
> Playing out silence in place of the lost packets is not a good idea:
> it will distrurb sychronization and will bring wrong Delta Time values
> to the weak signals at demodulation. I would suggest usage of some
> averaging instead of the silence.
To Bill (and Joe),
It just occurred to me that I could multicast my receiver output to you
in the frequency domain. UDP already provides the necessary framing. We
just define that as a new RTP "codec type".
I use fast convolution with overlap-and-save for filtering, so as long
as I tell you the
On 3/6/18 08:05, Bill Somerville wrote:
> not very hard at all. The audio in WSJT-X is via a Qt I/O Device
> abstraction and making a UDP server that joins a multicast group to
> receive and send audio would only require a thin layer to manage
> datagram reception and transmission converting
On 3/6/18 06:48, Joe Taylor wrote:
> Hi Phil,
>
> Your idea sounds reasonable. It might be a good way to enable wideband
> receiving -- that is, reception (of FT8, say) over a passband
> significantly greater than 5 kHz, currently the practical limit. The
> popularity of FT8 on the HF bands
On 3/5/18 23:24, Borja Marcos wrote:
> That would be really awesome, defining some standard “audio bus” for
> radio applications.
Well, there's really not much to define since the work has already been
done for us by the IETF (Internet Engineering Task Force). Multicasting
is heavily used on
How hard would it be for WJST to accept receive audio from a RTP (Real
Time Protocol) multicast network stream?
RTP is *the* standard for voice over IP (VoIP). It runs over UDP/IP,
usually as unicast IPv4 but also as multicast IPv4 or IPv6. It's just a
streaming protocol that identifies and
Hi guys, I've been subscribed to this list only since late April, so I'm
a newcomer. (I retired from Qualcomm after 20 years in late 2011 and had
a time- and energy-consuming bout with lymphoma in 2014, so I'm
belatedly discovering how much has gone on in the ham digital world. I
have some
Has anyone installed or rebuilt wsjtx on the new Debian release 9.0,
codename "stretch"?
Stretch dropped some packages that weren't being supported upstream,
apparently including libreadline6 that wsjtx has as a dependency.
libreadline5 is still present in stretch.
Log of install attempt
38 matches
Mail list logo
