Hi Alex,
These sound like good ideas to me. A mechanism for sending I/Q data
into WSJT-X has been on our back-burner "To Do" list for some time. But
as you can probably guess, I'm only superficially familiar with the
protocols you're considering. Bill will probably have a more useful
respo
Hello developers,
I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I want to do this in a way compatible with other software,
including WSJTX. RTP seems to be the best way of exchanging the I/Q data between the programs, but it needs to be complemented
with another protocol
Hello Phil,
.
>Igor, the whole point of playing out silence is to maintain
>synchronization. If, for example, the sampling rate is 48 kHz and your
>RTP packets each contain 240 samples (5 milliseconds), then I would
>replace a single missing packet with 240 samples of binary zeroes. Your
>signal bl
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.
Hello Phil,
>I implemented RTP in about a page of C code, not counting all of the
>UNIX/Linux system calls needed to set up multicast sockets. That's
>actually the only hard part. With RTP I just check that the next packet
>is in sequence, drop any old duplicates, and play out silence in place
>of
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 p
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 into/
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 impl
On 06/03/2018 06:29, Phil Karn wrote:
How hard would it be for WJST to accept receive audio from a RTP (Real
Time Protocol) multicast network stream?
Hi Phil,
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
FT8 is already encroaching on the PSK subbands (or in the case of 17 meters
right on top of the PSK subband) and probably others too. PLEASE be a good
neighbor and don't do anything to make it worse. Everyone needs to share a
very limited resource. Just because FT8 is popular does not provide
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 implies that wider sub-bands would be
very des
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 LAN
> On 6 Mar 2018, at 07:29, Phil Karn wrote:
>
> How hard would it be for WJST to accept receive audio from a RTP (Real
> Time Protocol) multicast network stream?
>
> My receiver outputs uncompressed audio as a standard RTP/UDP/IP
> multicast stream containing mono or stereo 16-bit linear PCM a
14 matches
Mail list logo
