[wsjt-devel] Multithreading FT8 decoder in WSJT-X and DX-pedition mode

[Игорь Ч via wsjt-devel]

Hello Joe and all,
.
Multithreading FT8 decoder in WSJT-X can provide workaround to the latency 
issues being observed at the DX-pedition mode tests.
.
Multithreading FT8 decoder is already implemented in JTDX and this approach 
might be taken from the latest JTDX source code.
.
73 Igor UA3DJY


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Audio input from RTP stream?

[Phil Karn]

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 implies that wider sub-bands would be
> very desirable.

Great. I hadn't thought of that, but you're right. Not only would this
free up your computer's sound system for other uses, it would avoid all
of the usual computer audio system limitations.

It would be very easy to give you a "stereo" (complex I/Q) audio stream.
I did use a complex-to-real IFFT in my fast correlator for SSB mode but
I simplified the program by just using complex-to-complex for everything
and throwing the imaginary part away in SSB/CW mode. That'd be an easy
way to double bandwidth without increasing the sample rate.

If you use complex signals internally, giving you complex audio could
let you avoid the Hilbert transform (or equivalent) necessary to
regenerate the analytic signal from a purely real one (not that that's
particularly difficult).

Zero frequency isn't a problem in a purely digital format, but neither
have I had any significant analog 0 Hz problems with my AMSAT UK Funcube
SDR dongle. There's a DC offset but it's easy to remove. This leaves a
small mound of phase noise maybe 1-2 kHz wide, probably from reciprocal
mixing. I only notice it with the antenna disconnected and normally it's
completely buried. In any event, I do my own frequency translations so
DC from the front end isn't necessarily DC in my output signal.

> With MAP65 we already have significant experience with wideband
> reception of JT65 EME signals.  It works very well, and is a big
> advantage.  It can be set up to decode all JT65 signals over a 90 kHz
> range.

Yeah, why not? If your SDR front end can cover an entire band, and if
you have enough CPU cycles, you could easily extract everything in an
entire band. One program would look for JT65, a completely independent
program looks for WSPR, a third one for Winlink or Domino or PSK31 or
whatever, and so on. These independent programs can run on the same
computer or on a collection of computers, all processing a single input
stream.

> When receiving WSJT-X currently acquires audio data via the C++ class
> defined in Detector.cpp.  Your best contact person is probably Bill,
> Somerville, G4WJS.  Fair warning: Bill is in the middle of some major
> contract work, so his available time is limited.

I'll look at it, thanks.

73, Phil


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 DXpedition mode test

[Gary McDuffie]

> On Mar 6, 2018, at 10:06 PM, Mike Lavelle  wrote:
> 
>  But I did not get my RR73 until ***20 minutes*** after I sent my signal 
> report !

This explains why I never saw any responses.  Since I was fighting other 
gremlins, I didn’t wait long enough to get a response after the initial one.  I 
also saw the continuous RR73 strings pouring out.

The whole thing was a little confusing, to say the least.  I hope another test 
will be done in the near future when things are more organized here.

Gary - AG0N
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT8 DXpedition mode test

[Mike Lavelle]

It appears that when the fox gets busy, its response can be greatly delayed, 
which leads to wasted extra calls from the hounds trying for a roger from the 
fox. 
As others mentioned, perhaps the fox should give rogers higher priority than 
signal reports to newer hounds. 
(Also, maybe the hounds should be able to send some 73's so the fox knows to 
stop sending RR73.) 

Here's my example: 

I joined the 20M test at about the 20 minute mark and was seeing about 30 
callers in one time slot here on the opposite coast. 
I got my signal report (-10, piggybacked on someone else's RR73) in the very 
next slot after just 3 consecutive calls, 
and then proceeded to send my R-07 report 9 times before it timed out. 

But I did not get my RR73 until ***20 minutes*** after I sent my signal report 
! 

In the mean time, I sent another 5 bursts of 4 calls off and on during that 
time, adding to the pileup, trying to provoke an RR73. 
These later seemed to eventually cause another 5 delayed RR73 responses, 
running about 18 to 12 minutes after the re-calls to the fox. 
The backlog seemed to be decreasing as the pileup eased, but it was seemingly a 
deep hole to dig out of. 


On the other hand, the 40M test went very well for me... 
I joined the test in the first few minutes, got my signal report immediately 
after my 4th consecutive call. 
I replied with my report immediately and got an immediate RR73. 
My program didn't shut off in time, so I sent one more signal report 
immediately and got another immediate RR73, then things shut down. That's the 
way it should be. 


I only occasionally heard the fox on 30M and then in the minus twenties, so 
only a handful of calls to the fox and no replies to me. 
The fox was strong enough (as high as -7) out here on 80M, but he did not seem 
to be hearing the Left Coast well. Again, no soap for me after many calls to 
the fox. 


Finally, a small complaint ... 
I found that had to exit the program after each hour to get it to accept the 
new DX Call... 
simply typing it in to the window and/or clicking on it didn't work, the 
program wanted to keep sending the previous DX call until I exited and 
restarted wsjt-x. 


Mike, K6ML 

(session "trace" files and notes attached) 
Summary:

- 2300z 14.080 - k1jt (fn20, NJ, ~2500 mi, 40 to 50 dB SNR VOACAP) was 
about -4 to -6 here

summary: deep pileup (i saw 30 callers here in one time slot!!) may have 
delayed RR73 response...
I joined about 1/3 of way in to test and it was 20M ...
I got my sig report after just 3 calls, on next cycle, but then had to wait 
another 20 min for RR73.   
This caused me to send 27 replies to the sig report. 
Appears the response to extra calls is extra RR73s without sig report.


(note: need to exit and reenter to get it to stop sending k1jt, even after 
updating DX Call)

- z 10.141 - w1/kh7z (n1dg, fn42, MA, ~ 2700 mi, ~ 35 dB SNR VOACAP)

only saw him occasionally, very weak (-22, -20) for a few slots at a time
never made contact

had to exit, reenter, again to change call...


- 0100z 7.080 -- w7/kh7z (aa7a, dm43, AZ, 620 mi, ~40 dB SNR VOACAP)

this time I got into test earlier and sigs were good again,,, got immed sig rpt 
on 4th consec call, 
i reply and he replies in next two slots,,, bing badda boom ... like it should 
be


had to exit, reenter, again to change call...

- 0200z 3.585 -- k9an (en50, IL, 1800 mi, appx 10-15 dB SNR VOACAP)   
use 120W Tx 

 didnt seem to be hearing very well out this far ... on a few qsos
 he never came back to me, even tho i had him in the low teens most of time 
and as high as -7








- 2300z 14.080 - k1jt (fn20, NJ, ~2500 mi, 40 to 50 dB SNR VOACAP) was 
about -4 to -6 here

232245  Tx  2146   called  3x
232315  Tx  2146   called  3x
232345  Tx  2146   called  3x

232400  -7  299   ZF1EJ RR73; K6ML -10  (1)

232415  Tx   876sent R-07  9x   (1)
232445  Tx   876sent R-07  9x
232515  Tx   876sent R-07  9x
232545  Tx   876sent R-07  9x
232615  Tx   876sent R-07  9x
232645  Tx   876sent R-07  9x
232715  Tx   876sent R-07  9x
232745  Tx   876sent R-07  9x
232815  Tx   876sent R-07  9x

232915   Tx 1393   called 4x   (2)
232945   Tx 1393   called 4x
233015   Tx 1393   called 4x
233045   Tx 1393   called 4x

233415   Tx 1393   called 4x   (3)
233445   Tx 1393   called 4x
233515   Tx 1393   called 4x
233545   Tx 1393   called 4x

233745   Tx 3601   called 4x   (4)
233815   Tx 3601   called 4x
233845   Tx 3601   called 4x
233915   Tx 3601   called 4x

234022   Tx 3601   called 4x   (5)
234045   Tx 3601   called 4x
234115   Tx 3601   called 4x
234145   Tx 3601   called 4x
234215   Tx 3601   called 4x

234325   Tx 3601   called 2x   (6)
234345   Tx 3601   called 2x
234415   Tx 3601   called 2x

234430  -6  359   K6ML K1JT  RR73(20:15-16:15 after 1)

234730  +1  419   K6ML K1JT  RR73(18:15 after 2)

235100K6ML K1JT  RR73(16:45 after 3)

235230K6ML K1JT  RR73

[wsjt-devel] Band change patch

[Black Michael via wsjt-devel]

This patch was submitted Nov 2 but never applied.It comes from the bug 
identified in this thread where changing the rig freq from the rig does not 
adjust to the remembered power levels.

https://sourceforge.net/p/wsjt/mailman/message/36101238/


Index: mainwindow.cpp
===
--- mainwindow.cpp  (revision 8534)
+++ mainwindow.cpp  (working copy)
@@ -1925,6 +1925,7 @@
   ui->bandComboBox->setCurrentText (band_name);
   m_wideGraph->setRxBand (band_name);
   m_lastBand = band_name;
+  band_changed(dial_frequency);
 }

   // search working frequencies for one we are within 10kHz of (1 Mhz

de Mike W9MDB
  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] DXpedition mode test results

[Alex, VE3NEA]

There was no propagation on 20m and 30m, but on 40m and 80m I worked DX quickly and without problems. There were a few glitches 
that are hopefully not difficult to fix.


1. When the Fox answered my call at 01:02:00 (see the attached screenshot), his message appeared on the left panel but not on 
the right one.


2. Two or three blank messages were received during the test.

3. Repeated RR73 have already been reported, but here is an interesting case: two RR73's were sent to me in the same time slot, 
on 313 Hz and 433 Hz (visible on the same screenshot):


010300 -13 -0.7  313 ~  VE3NEA RR73; N4EFS  -10
010300 -12 -0.7  372 ~  AB3CV RR73; W5TKZ  -10
010300 -13 -0.7  433 ~  VE3NEA RR73; K4SO  -05
010300 -14 -0.7  493 ~  AB3CV RR73; K1WSN  -09

My apologies if this is a feature rather than a bug. After all, the second VE3NEA RR73; has zero cost because the same message 
starts another QSO, so it makes sense to include it and improve the chances of RR73 being copied.



4. Probably not a glitch, just an observation: sometimes the Fox has more QSO in progress than it has slots. Below, the Fox 
answers my call at 02:07:00, then at 02:07:30 it does not RR my report but finishes three other QSO (and starts three new ones), 
and only at 02:08:00 sends RR73 to me:


180307_020645  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA FN03

020700  -6  0.1  304 ~  W9EQ RR73; VE3NEA  -06
020700  -4  0.1  364 ~  AF3I RR73; KC4JNW  -05
020700  -3  0.1  424 ~  W3RJW RR73; WA4MIT  -05

180307_020715  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA R+04

020730  -4  0.1  304 ~  VE2EBK RR73; KF0QR  -05
020730  -1  0.1  364 ~  W9EQ RR73; W8BAR  -05
020730   0  0.1  424 ~  AF3I RR73; K4DSP  -04

180307_020745  Transmitting 3.585 MHz  FT8:  K9AN VE3NEA R+04

020800  -2  0.1  304 ~  KC4JNW RR73; WW8RT  -04
020800   0  0.1  364 ~  W7AH RR73; KG4W   -04
020800   0  0.1  424 ~  VE3NEA RR73; N2ADV  -04

It is not clear if this behavior increases or decreases the QSO rate.

73 Alex VE3NEA


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] FT8 DXPedition mode test

[David Fisher]

Do you guys want reports of odd things seen during the DXPedition test today on 
this list?

Dave / NX6D


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MessageBox patch

[Gilbert Baron]

I use the same cables on my TS590SG and my Winkeyer. They are cheap and they 
work.

NOW  if someone could get a fix for every TV in the house things would be 
better. Even on 100 Watts it causes some trouble but on 800 it is total 
destruction. TV Cable boxes and TVs are just not make the way they should be. 
On < 50 W FT8 is ok 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

From: Black Michael via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Tuesday, March 6, 2018 15:10
To: WSJT Software Development 
Cc: Black Michael 
Subject: [wsjt-devel] MessageBox patch

 

Change title of messageboxes so JTAlert won't try to dock to them.

 

The new devel warning causes JTAlert to dock to it since the window title 
matches.  All we need to do is remove the version info.

 

https://www.dropbox.com/s/ljtfcbkawn160p9/messagebox.patch?dl=1 
 

 

de Mike W9MDB

 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Public test of FT8 DXpedition mode March 6-7

[Daniel Ekman]

Too bad, I was QRV at SK2AT and running a bit of FT8 with NA/SA @20m until
about 30min ago when some aurora came along and transformed the signals to
jingle bells and wasn't heard since.
Looking forward to another try, either another test or for DXpedition.
73's and good luck with the test!
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Status patch

[Bill Somerville]

Hi Mike,

that was exactly my concern as NA is a valid, if somewhat cold, grid field.

I will apply shortly as discussed. Thanks for the patch.

73
Bill
G4WJS.

On 06/03/2018 22:05, Black Michael via wsjt-devel wrote:
Yeah...that works too...anything that doesn't look like a grid or is 
at least distinct.



---
Michael D. Black


On Tuesday, March 6, 2018, 3:59:35 PM CST, Bill Somerville 
 wrote:



On 01/03/2018 23:05, Black Michael via wsjt-devel wrote:

I sent this about 4 days ago but haven't heard anything about it
Is this OK to apply?

Add hisGrid to wsjtx_status.txt so programs like PstRotatorAZ can use 
actual grid. Assigns "NA" if not available.


https://www.dropbox.com/s/rbibasioq6io8nd/status.patch?dl=1 



de Mike W9MDB


Hi Mike,

is the choice of "NA" for grid not available for any firm reason? I 
would prefer something less ambiguous like "n/a" if that is ok.


73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Status patch

[Bill Somerville]

On 01/03/2018 23:05, Black Michael via wsjt-devel wrote:

I sent this about 4 days ago but haven't heard anything about it
Is this OK to apply?

Add hisGrid to wsjtx_status.txt so programs like PstRotatorAZ can use 
actual grid. Assigns "NA" if not available.


https://www.dropbox.com/s/rbibasioq6io8nd/status.patch?dl=1 



de Mike W9MDB


Hi Mike,

is the choice of "NA" for grid not available for any firm reason? I 
would prefer something less ambiguous like "n/a" if that is ok.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] MessageBox patch

[Bill Somerville]

On 06/03/2018 21:10, Black Michael via wsjt-devel wrote:

Change title of messageboxes so JTAlert won't try to dock to them.

The new devel warning causes JTAlert to dock to it since the window 
title matches.  All we need to do is remove the version info.


https://www.dropbox.com/s/ljtfcbkawn160p9/messagebox.patch?dl=1 



de Mike W9MDB


Hi Mike,

similar patch already applied.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] HF Voyager project with FT8

[Brian Moran]

Here's a link to a project that has Amateur Radio built into an autonomous
vehicle on the high seas.

http://www.jrfarc.org/hf-voyager/


It's possible to work the vehicle using FT8, as described in this note on
the Elecraft reflector by Jim, K9YC:
https://marc.info/?l=elecraft=152036765825717=2

If you're already familiar with this, sorry about the bandwidth. Sounds
like an interesting project!

-Brian N9ADG
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] MessageBox patch

[Black Michael via wsjt-devel]

Change title of messageboxes so JTAlert won't try to dock to them.
The new devel warning causes JTAlert to dock to it since the window title 
matches.  All we need to do is remove the version info.

https://www.dropbox.com/s/ljtfcbkawn160p9/messagebox.patch?dl=1
de Mike W9MDB


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Add ft8d and ft8sim to makefile?

[Rockwell Schrock]

Hi folks,

I am interested in integrating some software with FT8 by passing audio
files into and out of the FT8 modem as provided by WSJT-X. I'm no FORTRAN
developer, but it appears that I could utilize the `ft8d` command-line
utility to decode WAV files, and `ft8sim` to generate them. Is that a
reasonable approach?

If so, could we get `ft8d` and `ft8sim` executables added to the WSJT-X
outputs, alongside jt9, jt65code, etc.?

Thanks,

Rockwell WW1X
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Memory Leak in jt9 Process

[Black Michael via wsjt-devel]

Can you run "ldd" on the jt9 executables?  That may point out what's different. 
 
de Mike W9MDB



 

On Tuesday, March 6, 2018, 1:26:40 PM CST, Doug Collinge 
 wrote:  
 
 I have done a fair amount of work to try to isolate the circumstances that 
produce the leak.- I used some spare partitions to build clean Ubuntu systems 
of various vintages. I installed the deb of 1.9.0-rc2, tested, then removed 
that and built it from the source using the libraries provided by the 
distribution, whatever version they were.- 16.04 LTS: the deb installed, no 
leak. Built from source, no problem, no leak.- 17.10: the deb installed, no 
leak. Built from source, it leaks.- 18.04 (Daily): deb won't install because 
the repo does not have readline6, just readline5 and readline7 for some reason. 
The source builds and runs but I haven't got the sound working yet so I can't 
tell if leaks or not.
I am not finished here. I am tabulating the versions of the dependencies of the 
jt9 executable to try to see if there is a particular version that is causing 
the problem. I think the results above suggest that the problem exists in 
something that is statically compiled into jt9 because the deb works but the 
compiled version does not.
By the way, the build instructions could use an update. I found several 
dependencies that are not mentioned there.

On Tue, Mar 6, 2018 at 8:29 AM, Joe Taylor  wrote:

Hi Doug,

On 2/20/2018 2:59 PM, Doug Collinge wrote:

There seems to be a memory leak in the jt9 process started by wsjtx. I have 
included a chart showing the memory use growing from about 20MiB to over 300MiB 
in the course of 11 hours. I set wsjtx to monitor 40m overnight and recorded 
the memory stats produced by /proc/*/statm at one minute intervals. The change 
in slope of the curves indicates the band opening and more signals being 
decoded.

The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates USB, 
filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.

Doug VE7GNU


Just checking in.  Have you figured out why your build of the executable "jt9" 
shows a significant memory leak, but ours does not?

        -- 73, Joe, K1JT

-- -- --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
__ _
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.n et
https://lists.sourceforge.net/ lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Memory Leak in jt9 Process

[Doug Collinge]

I have done a fair amount of work to try to isolate the circumstances that
produce the leak.
- I used some spare partitions to build clean Ubuntu systems of various
vintages. I installed the deb of 1.9.0-rc2, tested, then removed that and
built it from the source using the libraries provided by the distribution,
whatever version they were.
- 16.04 LTS: the deb installed, no leak. Built from source, no problem, no
leak.
- 17.10: the deb installed, no leak. Built from source, it leaks.
- 18.04 (Daily): deb won't install because the repo does not have
readline6, just readline5 and readline7 for some reason. The source builds
and runs but I haven't got the sound working yet so I can't tell if leaks
or not.

I am not finished here. I am tabulating the versions of the dependencies of
the jt9 executable to try to see if there is a particular version that is
causing the problem. I think the results above suggest that the problem
exists in something that is statically compiled into jt9 because the deb
works but the compiled version does not.

By the way, the build instructions could use an update. I found several
dependencies that are not mentioned there.

On Tue, Mar 6, 2018 at 8:29 AM, Joe Taylor  wrote:

> Hi Doug,
>
> On 2/20/2018 2:59 PM, Doug Collinge wrote:
>
>> There seems to be a memory leak in the jt9 process started by wsjtx. I
>> have included a chart showing the memory use growing from about 20MiB to
>> over 300MiB in the course of 11 hours. I set wsjtx to monitor 40m overnight
>> and recorded the memory stats produced by /proc/*/statm at one minute
>> intervals. The change in slope of the curves indicates the band opening and
>> more signals being decoded.
>>
>> The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates
>> USB, filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.
>>
>> Doug VE7GNU
>>
>
> Just checking in.  Have you figured out why your build of the executable
> "jt9" shows a significant memory leak, but ours does not?
>
> -- 73, Joe, K1JT
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Memory Leak in jt9 Process

[Black Michael via wsjt-devel]

I found out there's no leak on Ubuntu 16.04.3 but there is on 17.10.  I 
upgraded 17.10 to gcc 7.3 thinking it might be a library leak and that didn't 
fix it either.  It only shows up on the multi iterationS that jt9 does under 
wsjtx.  

de Mike W9MDB



 

On Tuesday, March 6, 2018, 10:31:35 AM CST, Joe Taylor  
wrote:  
 
 Hi Doug,

On 2/20/2018 2:59 PM, Doug Collinge wrote:
> There seems to be a memory leak in the jt9 process started by wsjtx. I 
> have included a chart showing the memory use growing from about 20MiB to 
> over 300MiB in the course of 11 hours. I set wsjtx to monitor 40m 
> overnight and recorded the memory stats produced by /proc/*/statm at one 
> minute intervals. The change in slope of the curves indicates the band 
> opening and more signals being decoded.
> 
> The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates 
> USB, filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.
> 
> Doug VE7GNU

Just checking in.  Have you figured out why your build of the executable 
"jt9" shows a significant memory leak, but ours does not?

    -- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Memory Leak in jt9 Process

[Joe Taylor]

Hi Doug,

On 2/20/2018 2:59 PM, Doug Collinge wrote:
There seems to be a memory leak in the jt9 process started by wsjtx. I 
have included a chart showing the memory use growing from about 20MiB to 
over 300MiB in the course of 11 hours. I set wsjtx to monitor 40m 
overnight and recorded the memory stats produced by /proc/*/statm at one 
minute intervals. The change in slope of the curves indicates the band 
opening and more signals being decoded.


The configuration here is Ubuntu 17.10 with an RTL-SDR. gqrx demodulates 
USB, filters and feeds the audio to wsjt-x 1.9.0-rc1 using pulseaudio.


Doug VE7GNU


Just checking in.  Have you figured out why your build of the executable 
"jt9" shows a significant memory leak, but ours does not?


-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Audio input from RTP stream?

[Bill Somerville]

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 
receive and send audio would only require a thin layer to manage 
datagram reception and transmission converting into/out of a stream 
in/out of respective QIODevice sub-classes is about the whole 
requirement. The Modulator and Detector classes in WSJT-X are pretty 
much agnostic about which QIODevice derivative they talk to for PCM 
sample streams.


Can you point me to somewhere I can get information about gathering RTP 
datagrams and combining as a continuous stream? Do I need to work with 
RTCP as well?


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 can leverage to capture UTC time 
sync relative to the source? Is there a recovery mechanism to "unbuffer" 
when delays accumulate?


I assume the RTP payload formats are usually compressed, can we use 
uncompressed PCM at 48000Hz 16-bit (actually 12000Hz 16-bit is all we 
require unless we go to wider bandwidths) and still expect timely 
delivery? If not, are we heading for a world of pain with proprietary 
codecs?


I have some experience as I used to work on a set top box application 
that streamed MPEG-4 over ADSL Internet, we used the Intel IPP libraries 
for codecs rendering to a Linux frame buffer and sending either 
web-camera or Ethernet based stand-alone camera streams.


73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Audio input from RTP stream?

[Michael Besemer]

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 license to 
rain on everyone else's parade.

Mike
WM4B
On Mar 6, 2018 9:49 AM, 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 implies that wider sub-bands would be 
> very desirable. 
>
> With MAP65 we already have significant experience with wideband 
> reception of JT65 EME signals.  It works very well, and is a big 
> advantage.  It can be set up to decode all JT65 signals over a 90 kHz range. 
>
> When receiving WSJT-X currently acquires audio data via the C++ class 
> defined in Detector.cpp.  Your best contact person is probably Bill, 
> Somerville, G4WJS.  Fair warning: Bill is in the middle of some major 
> contract work, so his available time is limited. 
>
>  -- 73, Joe, K1JT 
>
> On 3/6/2018 1:29 AM, Phil Karn wrote: 
> > 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 sequence numbers packets. It can 
> > carry any codec you want. 
> > 
> > I've been writing my own SDR from scratch over the past year or so. A 
> > core design feature is the use of IP multicasting for all inter-module 
> > communications, e.g., I/Q sample streams, uncompressed PCM audio, 
> > Opus-compressed audio, decoded digital data frames, hardware status, 
> > metadata, etc. 
> > 
> > I've found this to be remarkably versatile and practical. Any number of 
> > receivers can listen to a multicast stream without any prior 
> > arrangement. The various modules can be on the same system, on different 
> > systems on the same LAN, or systems in different locations connected by 
> > a multicast-capable IP network. Modules can be individually stopped and 
> > restarted without killing others (though some real-time data will of 
> > course be lost.) 
> > 
> > My receiver outputs uncompressed audio as a standard RTP/UDP/IP 
> > multicast stream containing mono or stereo 16-bit linear PCM audio at 48 
> > kHz. To now get this into WSJT on OSX, I run my RTP receiver/player 
> > program, intercept the OS X audio with Soundflower, and then tell WSJT 
> > to take its input from Soundflower. 
> > 
> > This sort of works, but it causes problems. You have to be careful to 
> > keep system sounds out of Soundflower, and you can't run any unrelated 
> > sound applications. 
> > 
> > It would be great if WSJT could natively process an incoming RTP audio 
> > stream without touching the local machine's audio subsystem. It would 
> > not have to echo to the system audio output; if want to monitor it I can 
> > simply run an instance of my RTP audio player that will join the same 
> > multicast stream and WSJT doesn't need to know. 
> > 
> > As a follow-on project, it would also be nice to give WSJT the option of 
> > generating a RTP stream with transmit PCM audio. 
> > 
> > I'm willing to do the work myself, but I'd like to know if anybody else 
> > is already working on something like this, or if anyone has advice for 
> > how to minimize my changes to the WSJT program structure. (I've not 
> > looked at the source yet.) 
> > 
> > 73, Phil 
> > 
> > 
> > --
> >  
> > Check out the vibrant tech community on one of the world's most 
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> > ___ 
> > wsjt-devel mailing list 
> > wsjt-devel@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
> > 
>
> --
>  
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> ___ 
> wsjt-devel mailing list 
> wsjt-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Audio input from RTP stream?

[Joe Taylor]

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 desirable.


With MAP65 we already have significant experience with wideband 
reception of JT65 EME signals.  It works very well, and is a big 
advantage.  It can be set up to decode all JT65 signals over a 90 kHz range.


When receiving WSJT-X currently acquires audio data via the C++ class 
defined in Detector.cpp.  Your best contact person is probably Bill, 
Somerville, G4WJS.  Fair warning: Bill is in the middle of some major 
contract work, so his available time is limited.


-- 73, Joe, K1JT

On 3/6/2018 1:29 AM, Phil Karn wrote:

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 sequence numbers packets. It can
carry any codec you want.

I've been writing my own SDR from scratch over the past year or so. A
core design feature is the use of IP multicasting for all inter-module
communications, e.g., I/Q sample streams, uncompressed PCM audio,
Opus-compressed audio, decoded digital data frames, hardware status,
metadata, etc.

I've found this to be remarkably versatile and practical. Any number of
receivers can listen to a multicast stream without any prior
arrangement. The various modules can be on the same system, on different
systems on the same LAN, or systems in different locations connected by
a multicast-capable IP network. Modules can be individually stopped and
restarted without killing others (though some real-time data will of
course be lost.)

My receiver outputs uncompressed audio as a standard RTP/UDP/IP
multicast stream containing mono or stereo 16-bit linear PCM audio at 48
kHz. To now get this into WSJT on OSX, I run my RTP receiver/player
program, intercept the OS X audio with Soundflower, and then tell WSJT
to take its input from Soundflower.

This sort of works, but it causes problems. You have to be careful to
keep system sounds out of Soundflower, and you can't run any unrelated
sound applications.

It would be great if WSJT could natively process an incoming RTP audio
stream without touching the local machine's audio subsystem. It would
not have to echo to the system audio output; if want to monitor it I can
simply run an instance of my RTP audio player that will join the same
multicast stream and WSJT doesn't need to know.

As a follow-on project, it would also be nice to give WSJT the option of
generating a RTP stream with transmit PCM audio.

I'm willing to do the work myself, but I'd like to know if anybody else
is already working on something like this, or if anyone has advice for
how to minimize my changes to the WSJT program structure. (I've not
looked at the source yet.)

73, Phil


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Audio input from RTP stream?

[Phil Karn]

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 LANs, mainly for resource discovery (especially by
Apple's Bonjour, which is also an IETF standard).

But IMHO IP multicasting hasn't lived up to its full potential, mainly
because few ISPs support it natively so you have to set up ad-hoc
tunnels. It's the basis of AT's U-verse service, and I'm looking hard
at using it for "smart" wide area roundtables and repeater links in ham
radio, but that's getting off topic.

RTP can be used with any audio format (or video, for that matter). I use
Opus (a fairly new and very nice lossy audio compression format) for
stuff I'm going to listen to by ear, but I still use PCM for anything
I'm going to feed to a demodulator program. They can easily coexist in
the same network. E.g., I wrote a simple server task that 'bridges'
multicast PCM to Opus to make it easy to listen remotely to the output
of a receiver module that produces only PCM.

> Making it multi platform and multi tooklit can be 
> tricky, though. WSJT-X is based on Qt audio. But, what about other apps?

The whole idea is to completely AVOID the audio subsystem on the host
computer running WSJT-X (or any other demod program, for that matter).
So there's no need for audio patching utilities like Jack or
Soundflower. A program like WSJT-X simply reads and processes (and/or
writes) multicast streams that just happen to contain digital audio. But
they're handled as ordinary data packets by the operating system.

But if I want to monitor the audio input to (or output from) a program
like WSJT-X, I can simply fire up a completely independent "multicast
monitor" program that joins the appropriate multicast group and streams
the audio to the local sound system. Otherwise I could listen to music,
watch a video, whatever, while WSJT-X quietly runs in its own window.

Phil

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel