Re: [wsjt-devel] Suggestions for the UI

[Edson W. R. Pereira]

Hi Bill,

Thanks for the thorough reply. GUI changes are quite hard since we get used
to the layout and people have different use patterns. But I think there are
some improvements we could do on wsjtx UI.

My comments follows inline below.

On Thu, Mar 9, 2017 at 3:37 PM, Bill Somerville <g4...@classdesign.com>
wrote:

> HI Edson,
>
> some comments in line below.
>
> On 09/03/2017 16:54, Edson W. R. Pereira wrote:
>
>
>1. The band selector can go up to the menu before the mode menu.
>
> This will be difficult, on Mac and some Linux Desktops the menu is not
> rendered by Qt and cannot contain non-traditional UI components like line
> edits and combo boxes. What is the reasoning for moving this control onto
> the menu?
>

Good point. Being a Linux XFCE user, I often forget about some of the
nuances on different OS'es. My suggestion was not to move the selector, but
use a menu to "select" the desired band. My reasoning is that if the mode
is a menu, perhaps the band should also be. I have nothing against the
selector itself. Although currently the information displayed when the
selector is clicked is truncated due to the width of the selector.



>
>
>1. The rig status light can be turned into a QLabel and should go to
>the status bar with the text "Rig" in it. Colors should be the same as the
>current light indicator. Plus grey if no rig is currently selected.
>
> This is a good idea. The current button, yes it is click-able, takes up
> more UI space than is necessary. If it were changed to a simple indicator
> in the status bar then I would suggest adding a menu action to reset the
> rig control.
>

Ok. The menu action is a good idea.


>
> The input level slider can be eliminated
>
> This has had some recent discussion. Keeping it does have some merit but
> perhaps not with the current functionality which is a master level control
> for the waterfalls. It could be come an adjuster for the o/s audio device
> level although adjusting that level away from 0dB FS has no advantage.
> Maybe remove it and add the o/s audio device fader level in dB to the
> status bar -- this is not totally straightforward as there is no
> notification of changes available.
>

The audio device fader could be a problem as some sound devices do not have
a fader or if they do have, they have no effect. Case in point, I use an
audio loopback device on Linux to route the audio from a SDR app to wsjtx.
Pulseaudio shows a fader for the device, but it has not action since the
native ALSA loopback device has no mixer.


>
> The level meter can be flipped horizontally with the same width as the
> frequency indicator, replacing where the DX Call and DX Grid labels and
> text inputs are currently located.
>
> Due to the decodes windows requiring as much vertical space as possible we
> must be careful not to add extra height to the bottom sections. Are you
> proposing to drop the Call and grid labels from the UI?
>

One of my intentions is actually see if the vertical space for the lower
part of the main window can be reduced slightly. The flipping of the meter
level would be just to have a clearer and consistent layout. But I need to
implement and "look" at it to feel if it is ok. I am considering dropping
the call and grid labels and format the call, grid, azimuth and distance in
a group box. But again, I need to implement it and see if it looks ok.



>
> The DX info widgets and log buttons should be moved to the bottom of the
> center area in dedicated widget group (next to the QSO area).
>
> What are the "log buttons"? It should be noted that the lower centre area
> is very full, this does not become apparent until a a mode like fast JT9 is
> selected. This change would probably reduce the space available for decodes.
>

By log buttons I mean the "lookup" and "add" buttons. I thing they should
remain close to the dx information (call, grid, etc). With the
reorganization of the widgets there should be more space in the central
part of the layout for the mode-specific controls. One future change we may
consider is having separate controls for each mode using a StackedWidget.
This may simplify implementing controls for new modes, ease the switching
between modes and have the UI layout adjusted for each mode instead of
hiding unused control widgets.

Do we need the "Report" SpinBox? If so, in what circumstances should it be
used? I ask because I've used it (and I hope it was not used by none of the
stations that have replied to my cq).



>
> The frequency label, horizontal level meter, and time label should be
> moved to the right border of the main window.
>
> This would be reasonably intuitive if the band selector/frequency input
> was there too but I believe thi

[wsjt-devel] Suggestions for the UI

[Edson W. R. Pereira]

I have a few suggestions for polishing the lower part of the UI. I will
enumerate them so that we can discuss each separately. I can implement the
ones that Joe and the group give a thumbs up.


   1. The band selector can go up to the menu before the mode menu.
   2. The rig status light can be turned into a QLabel and should go to the
   status bar with the text "Rig" in it. Colors should be the same as the
   current light indicator. Plus grey if no rig is currently selected.
   3. The input level slider can be eliminated
   4. The level meter can be flipped horizontally with the same width as
   the frequency indicator, replacing where the DX Call and DX Grid labels and
   text inputs are currently located.
   5. The DX info widgets and log buttons should be moved to the bottom of
   the center area in dedicated widget group (next to the QSO area).
   6. The frequency label, horizontal level meter, and time label should be
   moved to the right border of the main window.
   7. The QSO TabWidget should be replaced by a StackedWidget. The
   selection of which QSO interface to use will be in the general settings
   window. This will free up the space currently being occupied by the
   TabWidget "ears".
   8. The time bar graph in the status bar seems redundant and should be
   removed as it looks strange to have a bar graph in the status bar. Or it
   can be replaced by a QLabel indicating that audio is being recorded.

73, Edson PY2SDR
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Edson W. R. Pereira]

Hi Keith,

The audio codec used int he FT-991 is a Burr Brown (Texas Instruments)
PCM2903B. The PCM290x chips suffers from a spur at every one kHz when the
input level is low. I have built a few home made audio interfaces with
these chips and all of them suffer from this spur. The only way to mitigate
the problem is to increase the audio level.

73, Edson PY2SDR


On Mon, Mar 6, 2017 at 4:45 PM, Keith Laaks  wrote:

> HI Joe,
>
> On my MacBook with direct USB interface to an FT-991, by adjusting Menu 73
> ‘DATA OUT LEVEL’ right down to 0, I can get the bar to show the yellow with
> the meter at around 5dB level.  Against the grey background the yellow does
> somewhat appear white and I suspect some users may miss the fact that the
> color is trying to draw their attention to the too-low audio level. Maybe
> should be red also?
>
> (By the way, at the zero setting I also get solid ‘birdie' spectrum lines
> at 1K, 2K, 3K and 4K on the graph, with traces of some louder stations just
> showing between these).
>
> When I adjust the Menu 73 up to 1, the audio jumps to around 20db and he
> bar color to normal green (birdies disappear).
>
> Radio Data Out Level -> Meter Audio
> 25.  -> 45db
> 50 (default) -> 55dB
> 75   -> 60dB
> 100 -> 67db
>
> On my setup I am not able to ‘overdrive’ audio input.
>
> By the way, I am using Qt5.8 and I just noticed that the band selection
> dropdown is now working 100% again.
> When I switched to 5.8 originally last month (to sort my audio issue), I
> noticed the dropdown did not drop - but I could still just enter the band
> manually.
>
> Lots of activity on 7.076 this evening….
>
>
> 73s.
>
> Keith
> Zs6tw.
>
>
>
>
>
>
> --
> Please let us know what you think of the changes made in r7597 to the
> audio level meter.  In particular, to the color(s) used for the
> thermometer bar.
>
> For a trial period, we now have red indicating A/D saturation, green
> "normal" levels, and yellow noise levels so low that quantization errors
> are significant.  One should "almost never" see the warning colors
> unless something is significantly wrong, so my feeling is that the color
> changes should not be distracting in normal operation.
>
> Should we stay with the three-color arrangement?  If yes, could we
> choose a better set of three colors?
>
> -- Joe, K1JT
>
>
>
> 
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Cumulative patch

[Edson W. R. Pereira]

Hi Bill,

The concern I have is if the control of the OS fader would be OS agnostic.
Also, some multi input/output soundcards have a collection of controls --
some independent some not. Also, some soundcards have no hardware fader
control (the best ones).

The way WXJT-X works today seems quite adequate. It empowers the user to
have full control on the sound levels. The way the signal level meter works
is also very good as it measures the signal at the wxjt-x input in relation
to the ADC floor. This, in my view, is the best indicator to correctly set
the audio levels (at ~ 30 dB).

73, Edson PY2SDR


On Fri, Mar 3, 2017 at 2:49 PM, Bill Somerville 
wrote:

> On 03/03/2017 15:38, Joe Taylor wrote:
> > 2. The slider should not affect the meter reading.
> >
> HI Joe & all,
>
> we have another enhancement possibility available to us. WSJT-X could
> set the operating system/driver fader to 0 dB as well. This may cause
> some consternation amongst users who have tweaked the levels because we
> have said the best place for the WSJT-X slider is in the middle. Those
> who have done this are probably doing more harm than if they had tweaked
> the WSJT-X slider to get to 30 dB on background noise.
>
> Another option is that we could also switch the WSJT-X level control to
> actually change the o/s / driver fader but note the value is in the
> range 0.0 to 1.0 and I assume that 1.0 is 0 dB FS so maybe only
> attenuation is available.
>
> Related to this, I have never been sure if the operating system level is
> more than just digital manipulation of the 16-bit PCM stream. For
> example it could have access to a 24-bit sample stream at a high sample
> rate on the input side (for example my laptop is capable of 192 kHz
> 24-bit audio input) and therefore has more resolution available than a
> gain control on a 16-bit sample stream would have.
>
> 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
>
--
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] FreqCal Mode

[Edson W. R. Pereira]

Hello everyone:

I got across this paper some time ago. The algorithm suggested could
perhaps be applied to FreqCal.

https://mgasior.web.cern.ch/mgasior/pap/FFT_resol_note.pdf

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Tue, Jan 10, 2017 at 2:08 PM, Bill Somerville 
wrote:

> On 09/01/2017 23:57, Joe Taylor wrote:
>
> Still, it will probably be best to put a window on the FFT.
>
> Hi Joe,
>
> the new sin^2 window function improves accuracy most of the time, here
> are some sample measurements using identical tones synthesised by another
> WSJT-X instance:
>
> 15:23:57   5000  1  1500  1500.000 0.000  -39.4   78.8
> 15:24:06   7850  1  1501  1501.022 0.022  -39.5   78.0
>
> 15:24:41  1  1  1502  1501.979-0.021  -39.3   78.5
>
> 15:25:06  14670  1  1503  1503.018 0.018  -39.4   78.6
>
> 15:25:34  15000  1  1505  1504.976-0.024  -22.2   59.9
>
> 15:26:06  2  1  1506  1506.025 0.025  -39.4   78.2
>
> 15:26:46660  1  1507  1506.977-0.023  -39.4   78.5
>
> 15:27:09880  1  1508  1508.014 0.014  -39.4   78.8
>
> 15:27:36   1210  1  1509  1508.991-0.009  -39.5   77.7
>
> 15:28:04   2500  1  1510  1509.991-0.009  -39.1   78.5
>
> without the window:
>
> 15:48:55660  1  1500  1500.000 0.0002.8   77.5
>
> 15:49:09660  1  1501  1501.010 0.010   12.6   64.1
>
> 15:49:20660  1  1502  1501.956-0.044   19.5   60.1
>
> 15:49:43880  1  1503  1503.037 0.037   18.0   61.9
>
> 15:49:55880  1  1504  1503.946-0.054   23.4   54.1
>
> 15:50:06   1210  1  1505  1504.991-0.0096.5   73.8
>
> 15:50:18   1210  1  1506  1506.061 0.061   22.6   55.9
>
> 15:50:50   2500  1  1507  1506.949-0.051   20.9   58.5
>
> 15:51:09   3330  1  1508  1508.029 0.029   16.0   64.1
>
> 15:51:20   3330  1  1509  1508.966-0.034   23.5   53.3
>
> 15:51:39   5000  1  1510  1509.983-0.017   11.7   68.5
>
> I note that the SNR figures are roughly the same but the "Level" column
> has changed dramatically.
>
> 73
> Bill
> G4WJS.
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fwd: Window repaint issue on wsjt-x v1.7.0

[Edson W. R. Pereira]

Hi Robin,

I may have missed the message when I looked at the archives. I didn't
include the attachment in my second message suspecting that the attachment
was the cause for the message not being realyed. Thanks for confirming that
the first message did go through.

Michael, I will try getting a dev environment on my Windows machine over
the holidays to check if the issue is still present on the head of the dev
branch. Why do you think it should be resolved?

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Tue, Dec 27, 2016 at 9:03 PM, G8DQX (WSJT developers on SF) <
wsjtde...@gape.me.uk> wrote:

> Edson,
>
> your original message *was* relayed by the mailing list, and was received
> here with a time stamp of 18:17 UTC, complete with an attached image
> *wsjtx-repaint.png* (not included with your retransmission).
>
> I can't help with the W7 issue though, no matter how amazing this human
> is! (Mostly a Linux operation, and none of the W7 machines are currently in
> commission.)
>
> 73,
>
> Robin, G8DQX
>
> On 27/12/16 12:49, Edson W. R. Pereira wrote:
>
> Hello all,
>
> I'm resending the message below as the original one was not relayed by the
> sourceforge reflector somehow.
>
> 73, Edson PY2SDR
>
> ---
> - We humans have the capability to do amazing things if we work together.
> - Nós seres humanos temos a capacidade de fazer coisas incríveis se
> trabalharmos juntos.
>
> -- Forwarded message --
> From: Edson W. R. Pereira <ewpere...@gmail.com>
> Date: Thu, Dec 22, 2016 at 4:17 PM
> Subject: Window repaint issue on wsjt-x v1.7.0
>
>
>
> 
> --
> 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

[wsjt-devel] Fwd: Window repaint issue on wsjt-x v1.7.0

[Edson W. R. Pereira]

Hello all,

I'm resending the message below as the original one was not relayed by the
sourceforge reflector somehow.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

-- Forwarded message --
From: Edson W. R. Pereira <ewpere...@gmail.com>
Date: Thu, Dec 22, 2016 at 4:17 PM
Subject: Window repaint issue on wsjt-x v1.7.0
To: WSJT <wsjt-devel@lists.sourceforge.net>


Hello everyone,

I am observing some strange repaint issue with v1.7.0 (r7405) on Windows 7.
If I resize the main window, some of the widgets in the main window become
white or partially white (don't get repainted correctly). The issue only
happens with vertical sizes above around 770 pixels. With v.1.7.0-rc3, I am
unable to replicate the issue.

Has anyone observed this? Were there any recent changes in the layout code
for the mainwindow?

73, Edson PY2SDR



---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.
--
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] Window repaint issue on wsjt-x v1.7.0

[Edson W. R. Pereira]

Hello everyone,

I am observing some strange repaint issue with v1.7.0 (r7405) on Windows 7.
If I resize the main window, some of the widgets in the main window become
white or partially white (don't get repainted correctly). The issue only
happens with vertical sizes above around 770 pixels. With v.1.7.0-rc3, I am
unable to replicate the issue.

Has anyone observed this? Were there any recent changes in the layout code
for the mainwindow?

I'm attaching an image showing the issue.

73, Edson PY2SDR



---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Windows build issue

[Edson W. R. Pereira]

Thank you, Greg! The enable-rcfg and enable-clean did resolve the issue.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Sun, Oct 16, 2016 at 3:03 PM, Greg Beam <ki7m...@gmail.com> wrote:

> Hi Edson,
>
> A build environment issue is possible, but not likely if you've not
> changed anything recently. I've seen these type of errors in the past
> for couple of different reasons: the build tree getting corrupted
> somehow or the computer itself not handling parallel builds properly.
> Why the latter happens I've never been able to determine.
>
> To ensure it is not the build tree causing the issue, I would:
>
> enable-rcfg
> enable-clean
> build-wsjtx rinstall
>
> if that fails, try separating the builds:
>
> enable-separate
> build-wsjtx rinstall
>
>
> If both the methods above fail, then I would start to suspect the build
> environment or the box is somehow contributing to the problem. I doubt
> the WSJT-X source code is the issue or others would be reporting similar
> issues, but it is possible.
>
>
> 73's
> Greg, KI7MT
>
>
> On 10/16/2016 9:09 AM, Edson W. R. Pereira wrote:
> >
> > While trying to compile the svn head today, I've got some missing
> > references:
> >
> > [...]
> > Linking CXX executable jt65.exe
> > [ 87%] Built target jt65code
> > libwsjt_fort.a(jt65_decode.f90.obj):jt65_decode.f90:(.text+0x30c1):
> > undefined re
> > ference to `qra64a_'
> > libwsjt_fort.a(sync65.f90.obj):sync65.f90:(.text+0x2d0): undefined
> > reference to
> > `pctile_'
> > libwsjt_fort.a(sync65.f90.obj):sync65.f90:(.text+0x66d): undefined
> > reference to
> > `peakup_'
> > c:/jtsdk/qt5/tools/mingw48_32/bin/../lib/gcc/i686-w64-
> mingw32/4.8.0/../../../../
> > i686-w64-mingw32/bin/ld.exe: libwsjt_fort.a(sync65.f90.obj): bad reloc
> > address 0
> > x20 in section `.eh_frame'
> > c:/jtsdk/qt5/tools/mingw48_32/bin/../lib/gcc/i686-w64-
> mingw32/4.8.0/../../../../
> > i686-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
> > collect2.exe: error: ld returned 1 exit status
> > CMakeFiles\jt65.dir\build.make:143: recipe for target 'jt65.exe' failed
> > mingw32-make.exe[2]: *** [jt65.exe] Error 1
> > CMakeFiles\Makefile2:261: recipe for target 'CMakeFiles/jt65.dir/all'
> failed
> > mingw32-make.exe[1]: *** [CMakeFiles/jt65.dir/all] Error 2
> > mingw32-make.exe[1]: *** Waiting for unfinished jobs
> > [ 87%] [ 87%] Building Fortran object
> > CMakeFiles/jt65sim.dir/lib/jt65sim.f90.obj
> >
> > Building RC object CMakeFiles/jt65sim.dir/wsjtx.rc.obj
> > [ 87%] Building CXX object CMakeFiles/jt65sim.dir/
> jt65sim_automoc.cpp.obj
> > Linking CXX executable jt65sim.exe
> > [ 87%] Built target jt65sim
> > makefile:136: recipe for target 'all' failed
> > mingw32-make.exe: *** [all] Error 2
> > [...]
> >
> >
> > My Windows JTSDK info is:
> >
> > SVN Check
> > 
> >
> > Update from SVN Before Building? ( y/n )
> >
> > Type Response: y
> >
> > 
> >  Folder Locations
> > 
> >
> >  JTSDK Option: Folder Separation Disabled
> >  JTSDK Option: QT55 Disabled
> >
> >  Build ...: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\build
> >  Install .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install
> >  Package .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\package
> >
> > 
> >  Build Information
> > 
> >
> >  Name : wsjtx Release Candidate
> >  Version .: 1.7.0
> >  SVN .: r7185
> >  Type : Release
> >  Target ..: install
> >  Tool Chain ..: qt52
> >  SRC .: C:\JTSDK\src\wsjtx
> >  Build ...: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\build
> >  Install .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install
> >  Package .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\package
> >  SVN URL .: http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
> >  TC File .: c:/JTSDK/scripts/wsjtx-toolchain.cmake
> >
> > [..]
> >
> > COMPILER INFO ( Mingw 48_32 )
> > -
> >  C++ : 4.8.0
> >  GFortran ...: 4.8.0
> >  GNU Make 

[wsjt-devel] Windows build issue

[Edson W. R. Pereira]

While trying to compile the svn head today, I've got some missing
references:

[...]
Linking CXX executable jt65.exe
[ 87%] Built target jt65code
libwsjt_fort.a(jt65_decode.f90.obj):jt65_decode.f90:(.text+0x30c1):
undefined re
ference to `qra64a_'
libwsjt_fort.a(sync65.f90.obj):sync65.f90:(.text+0x2d0): undefined
reference to
`pctile_'
libwsjt_fort.a(sync65.f90.obj):sync65.f90:(.text+0x66d): undefined
reference to
`peakup_'
c:/jtsdk/qt5/tools/mingw48_32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../
i686-w64-mingw32/bin/ld.exe: libwsjt_fort.a(sync65.f90.obj): bad reloc
address 0
x20 in section `.eh_frame'
c:/jtsdk/qt5/tools/mingw48_32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../
i686-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
CMakeFiles\jt65.dir\build.make:143: recipe for target 'jt65.exe' failed
mingw32-make.exe[2]: *** [jt65.exe] Error 1
CMakeFiles\Makefile2:261: recipe for target 'CMakeFiles/jt65.dir/all' failed
mingw32-make.exe[1]: *** [CMakeFiles/jt65.dir/all] Error 2
mingw32-make.exe[1]: *** Waiting for unfinished jobs
[ 87%] [ 87%] Building Fortran object
CMakeFiles/jt65sim.dir/lib/jt65sim.f90.obj

Building RC object CMakeFiles/jt65sim.dir/wsjtx.rc.obj
[ 87%] Building CXX object CMakeFiles/jt65sim.dir/jt65sim_automoc.cpp.obj
Linking CXX executable jt65sim.exe
[ 87%] Built target jt65sim
makefile:136: recipe for target 'all' failed
mingw32-make.exe: *** [all] Error 2
[...]


My Windows JTSDK info is:

SVN Check


Update from SVN Before Building? ( y/n )

Type Response: y


 Folder Locations


 JTSDK Option: Folder Separation Disabled
 JTSDK Option: QT55 Disabled

 Build ...: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\build
 Install .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install
 Package .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\package


 Build Information


 Name : wsjtx Release Candidate
 Version .: 1.7.0
 SVN .: r7185
 Type : Release
 Target ..: install
 Tool Chain ..: qt52
 SRC .: C:\JTSDK\src\wsjtx
 Build ...: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\build
 Install .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\install
 Package .: C:\JTSDK\wsjtx\devel\qt52\1.7.0\Release\package
 SVN URL .: http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
 TC File .: c:/JTSDK/scripts/wsjtx-toolchain.cmake

[..]

COMPILER INFO ( Mingw 48_32 )
-
 C++ : 4.8.0
 GFortran ...: 4.8.0
 GNU Make ...: 3.82.90

CRITICAL APP INFO
-
 Asciidoctor..: 1.5.3
 Cmake ...: 3.0.2
 Cpack ...: 3.0.2
 QT5 .: 5.2.1
 QMake ...: 3.0
 NSIS : v3.0b1
 InnoSetup ...: 5.5.5a
 Pkg-Cfg .: 0.28

(JTSDK-QT 5.2 ) C:\JTSDK)

Could the issue be something in build environment?

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.
--
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] [wsjtgroup] JTSDK Win32 v2.0.4-1 Upgrade Available - (minor update)

[Edson W. R. Pereira]

On Win 7 32 bits, after update/upgrade, the JTSDK-QT window closes
immediately after started. I've uninstalled and reinstalled the JTSDK
environment and the issue persists (after update/upgrade). Has anyone
experienced this?

73, Edson PY2SDR


> On Tue, Mar 8, 2016 at 3:24 PM, Greg Beam ki7m...@gmail.com [wsjtgroup] <
> wsjtgroup-nore...@yahoogroups.com> wrote:
>
>>
>>
>> Hello All,
>>
>> Minor update fixing a typo in the Hamlib3 cmd build script.
>>
>> *CHANGE-LOG*
>> * Fixed call to BUILD-ERROR message
>> * Updated Changelog
>> * Updated version.jtsdk file
>>
>> *TO-UPGRADE*
>> - Close All JTSDK Windows
>> - Open JTSDK-Maint, then type:
>>
>> update
>> upgrade
>>
>> - Close and re-open JTSDK-Maint, type: version
>> - You should see the following:
>>
>> -
>> * Version: JTSDK-Win32 v2.0.4-1 Release
>> * Last Changed Rev: 672
>> * URL:
>> https://svn.code.sf.net/p/jtsdk/jtsdk/jtsdk-win/tags/jtsdk-win-2.0.4
>> * Last Changed Date: 2016-03-08 11:10:05 -0700 (Tue, 08 Mar 2016)
>> -
>>
>> 73's
>> Greg, KI7MT
>> __._,_.___
>> --
>> Posted by: Greg Beam 
>> --
>> Reply via web post
>> 
>> • Reply to sender
>> 
>> • Reply to group
>> 
>> • Start a New Topic
>> 
>> • Messages in this topic
>> 
>> (1)
>> To unsubscribe, send an email to:
>> wsjtgroup-unsubscr...@yahoogroups.com
>> Visit Your Group
>> 
>>
>>- New Members
>>
>> 
>>10
>>
>> [image: Yahoo! Groups]
>> 
>> • Privacy 
>> • Unsubscribe 
>> • Terms of Use 
>>
>> .
>>
>> __,_._,___
>>
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Raspberry PI

[Edson W. R. Pereira]

Hi Richard,

Ok! My apologies. I must have misunderstood what you wrote.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jan 15, 2016 at 2:39 PM, Richard Bown <rich...@g8jvm.com> wrote:

> On Fri, 15 Jan 2016 14:23:48 -0200
> "Edson W. R. Pereira" <ewpere...@gmail.com> wrote:
>
> > On Fri, Jan 15, 2016 at 11:31 AM, Richard Bown <rich...@g8jvm.com>
> wrote:
> >
> > >
> > > You can feed a SDR with just an single audio feed and you will see the
> > > local ocillator and a
> > > positive spectrum on the right and a negative on the left, using a I
> > > input allows you to remove
> > > the unwanted sideband , ie the negative image to the left. or vice
> versa
> > > if you select that.
> > >
> > >
> > Richard,
> >
> > I'm afraid this is incorrect. If you use only one of the channels and
> run a
> > real to real FFT on it you will see a mirrored spectrum. The negative
> > spectrum will be an exact mirror of the positive one. In order to see
> > negative and positive frequencies you will need both audio channels (I
> and
> > Q) and run a complex FFT.
> >
> > 73, Edson PY2SDR
>
>  Thats what I said Edson :)
>
> --
> --
> Best wishes /73
> Richard Bown
>
> Email : rich...@g8jvm.com
> HTTP  :  http://www.g8jvm.com
> nil carborundum a illegitemis
>
> ##
> Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W &
> 3cms 5W
> Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
> QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
> OS: Linux Mint 17.3 x86_64 on a Dell Inspiron N5030 laptop
>
> ##
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Raspberry PI

[Edson W. R. Pereira]

Hello Nick,

I am glad to see that sdr-shell is still useful and is still being used ten
years after I first released it.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jan 15, 2016 at 11:32 AM, nick  wrote:

> On 15/01/16 12:42, Bill Somerville wrote:
> > I suggest that you investigate using HDSDR or similar as an intermediary
> > between the receiver (and transmitter) and WSJT-X
>
> Paul
>
> I use dttsp/sdr-shell/jack running on Mint linux for this purpose.
>
> It works well.
>
> 73
>
> Nick G3VNC
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Raspberry PI

[Edson W. R. Pereira]

On Fri, Jan 15, 2016 at 11:31 AM, Richard Bown  wrote:

>
> You can feed a SDR with just an single audio feed and you will see the
> local ocillator and a
> positive spectrum on the right and a negative on the left, using a I
> input allows you to remove
> the unwanted sideband , ie the negative image to the left. or vice versa
> if you select that.
>
>
Richard,

I'm afraid this is incorrect. If you use only one of the channels and run a
real to real FFT on it you will see a mirrored spectrum. The negative
spectrum will be an exact mirror of the positive one. In order to see
negative and positive frequencies you will need both audio channels (I and
Q) and run a complex FFT.

73, Edson PY2SDR
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Raspberry Pi

[Edson W. R. Pereira]

I think the wsjt-x will run well on a R-Pi 2, but I am not sure it will run
on a R-Pi 1 Compiling wsjt-x may take some effort though. I have Steve's
wspr stand alone decoder (C implementation) running on a R-Pi 1 and it
works very well.

For JT65/JT9 and other QSO modes on small devices, I think there could be a
separation of the JT DSP core from the user interface. The core could run
on a R-Pi or other computer and the user interface could either run on the
same computer or on a separate one. Communication could be done over TCP
sockets. This could open a number of possibilities. User interfaces could
be implemented for tablets, smart phones, etc. It could also open the
possibility for remote operations.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, Jan 13, 2016 at 9:15 PM, Richard Bown  wrote:

> On Wed, 13 Jan 2016 22:23:48 +
> Bill Somerville  wrote:
>
> > On 13/01/2016 22:10, Richard Bown wrote:
> > > I'm not going to get in to argument over it Bill.
> > > But if you want to open WSJTX up to everyone with a tablet cross
> compile and hope wont work.
> > > The old argument that tablets cant be used due to audio drivers is
> extinct.
> > Whoa! Where did tablets come from?
> >
> > Qt has excellent support for Andriod and iOS but I would agree that we
> > would need to do some work to support gesture driven keyboard-less
> > systems like tablets and phones. You might want to contribute to such an
> > effort if you have teh relevant Qt experience but currently I'm not
> > aware of any need from users aside from off-hand comments from a few
> > that queried if WSJT-X could run on a tablet.
> >
> > My requirement is on behalf of users that have little or no development
> > experience and want to use a SoC type boards like the
> Companies like Freescale and TI
> > PI2/BeagleBlack/fill in your preference of ARM based hardware in their
> > shacks or portable stations with a keyboard mouse and perhaps a USB
> > sound device. We have plenty of those and more would join since the cost
> > of entry is so small. They just need something to install and go. Greg
> > has enabled the armhf builds for Debian AFAIK and they may appear in the
> > repos in time but for now a DEB or RPM package is a convenient stepping
> > stone.
> >
> > 73
> > Bill
> > G4WJS.
> >
> > 
>
> The production of the Rasp PI2 and all its clones are a direct result of
> the development of the
> call phone and tablet.
> |Without the mass production of the ARM processors and GPU/Mali used in
> cell phone tablets, set top
> TV boxes, TV's ect, the growth of the use of PI clones would never have
> happened ,
> Companies like TI and Freescale who are also producing processors have not
> yet managed to tap into
> the hobby market with SBC as their devices are expensive compared to
> companies like Samsung.
> Touch screens are already available for the PI2 clones
> the latest tablets, quad core processors, are the same as the PI2 clones ,
> the PI2 clones have
> greater interface capability, but most tablets have one audio i/p, two
> audio o/p, USB and HDMI, plus
> wifi and bluetooth.
> Android uses the same kernel as linux, its only the file structure is
> different.
> Linux can be run over the Android system, I've haven't tried it yet but I
> suspect with a little
> playing WSJTX could be run on an Android tablet, and put a USB socket on a
> smartphone , and that
> becomes open to use as well.
> There is a lot happening and it would be shame to ignore it
> --
> --
> Best wishes /73
> Richard Bown
>
> Email : rich...@g8jvm.com
> HTTP  :  http://www.g8jvm.com
> nil carborundum a illegitemis
>
> ##
> Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W &
> 3cms 5W
> Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
> QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
> OS: Linux Mint 17.3 x86_64 on a Dell Inspiron N5030 laptop
>
> ##
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance

Re: [wsjt-devel] wsjtx 1.7.0 r6346 Hangs....

[Edson W. R. Pereira]

Hi Bill,

I agree. The warning about the lock file is benign. The crash however is
strange. I am not convinced it is a wsjt-x issue, but an environment one. I
am asking him to try observing what wsjt-x is dowing when it crashes. If it
is at the end of a recording cycle, middle of processing, what else the
machine is doing, etc.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, Jan 6, 2016 at 1:35 PM, Bill Somerville <g4...@classdesign.com>
wrote:

> On 06/01/2016 15:29, Edson W. R. Pereira wrote:
> > it fails saying that there is another instance already running.
>
> Hi Edson,
>
> that is not a failure, it is just a warning saying that the application
> lock file exists, the message offers to delete the stale lock file and
> continue.
>
> 73
> Bill
> G4WJS.
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjtx 1.7.0 r6346 Hangs....

[Edson W. R. Pereira]

Today a ham friend also reported that wspr freezes and crashes after a
while in wsjt-x 1.6.0 r6263 on Win 7. On jt65/jt9 he finds no issue. If he
kills wsjt-x and restarts, it fails saying that there is another instance
already running.

I will try getting more info.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, Jan 6, 2016 at 12:34 PM, Bill Somerville 
wrote:

> On 06/01/2016 14:22, Black Michael wrote:
> > Does WSPR send CW id at end of transmission?  Could that be a higher
> > power event?
>
> Hi Mike,
>
> CW IDs are sent in all the "slow" modes according to the CW ID settings.
> So on WSPR that means at the CW interval since there is no "end of QSO"
> state for WSPR.
>
> The CW ID is synthesised at 100% audio level so it is the same power as
> the normal transmissions. Although steps are taken to soften the keying
> transitions, some extra bandwidth is going to be used due to the AM
> nature of CW.
>
> 73
> Bill
> G4WJS.
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Feature Request, JT9 to SNUS

[Edson W. R. Pereira]

I do some balloon experiments from time to time and am considering using
JT9 on HF and also JT65 on VHF for telemetry. It would be nice to feed the
telemetry data to spacenear. However, we would need to verify with them if
it would be ok to feed non balloon data to their servers. The current
implementation for the feed interface in the modified version of wsjt-x has
a couple of check boxes that are used to enable the uploads. But in the
main release of wsjt-x there is a risk that many stations could leave the
upload enabled -- thus feeding non balloon data to spacenear. With the
current popularity of wsjt-x, the volume of data could be considerable.

Ideally there could be some sort of identifier in the JT9 telemetry data
from balloons that wsjt-x could detect and act accordingly. Mal, do you
know if there is any type of "signature" in the balloon data?

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Tue, Jan 5, 2016 at 12:16 PM, Bill Somerville 
wrote:

> On 05/01/2016 08:29, Mal Good wrote:
> > Can you add options that allow for 1) the uploading of JT9 telemetry
> > from balloons to the SNUS (spacenear.us) website and 2) the reporting
> > of the ground stations location to the same site?
>
> Hi Mal,
>
> where is the server URL and data format documented?
>
> 73
> Bill
> G4WJS.
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Feature Request, JT9 to SNUS

[Edson W. R. Pereira]

Just thinking out loud...

Another approach could be a three-tier system using the pskreporter site as
a proxy and using Bill's suggestion about a JSON file with the registered
flight callsigns. Since a bolloon flight needs to be registered with SNUS,
the pskreporter site would fetch the JSON file and use callsigns listed as
the filtering criteria. If a spot matches the criteria, pskreporter would
then forward the spot to SNUS. The implementation of this approach would
need to the done by pskreporter and SNUS maintainers.

Just a thought...

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Tue, Jan 5, 2016 at 3:47 PM, Bill Somerville 
wrote:

> On 05/01/2016 15:57, Black Michael wrote:
> > I could do this if I can be assured the patch would be accepted.  I
> > need a project right now that would be accepted since I'm a touch
> > frustrated my last couple patches were rejected.
>
> Hi Mike,
>
> you are asking an unanswerable question. Contributions are judged on
> content, quality and how valuable they are to the community. Until we
> know the mechanics of the data required at the SNUS server i.e. the
> message specification, how, if and if we need to filter received
> messages before uploading. The answers to these questions determine if
> the effort is practical, worthwhile and valuable to the community. For
> example if we would have to make a special version of WSJT-X or include
> complex configuration settings then I doubt it would be acceptable. OTOH
> if we could simply add a check box that enabled automatic uploading of
> spots to the SNUS server when normal WSJT-X users happen to be on the
> relevant HF frequencies it would probably be acceptable.
>
> 73
> Bill
> G4WJS.
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] native pulseaudio removed?

[Edson W. R. Pereira]

Hello Iban,

Pulseaudio support is part of Qt. There is no pulseaudio code in WSJT-X.
Most likely your Qt instalation was not compiled with pulseaudio support or
pulseaudio was not detected during compilation of the Qt libs.

I agree with you 100% on the audio baseband IQ via network. There are
already some SDR hardware implementing it (Flex, HPSDR, Cloud-IQ, etc).
Unfortunately there isn't a standard yet. Each vendor is implementing their
own solution. Hopefully it is just a matter of time until the tecnology
converges. We could implement support for one of these systems or some
particular audio transfer mechanism over the network, but we would need to
have the hardware.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Tue, Jan 5, 2016 at 9:27 AM, Iban Cardona  wrote:

> Hi,
>
> just downloaded and compiled the last wsjtx and wsprx for linux and the
> native pulseaudio support looks that has been removed.
>
> The native pulseaudio is very important to hock sdr's and another special
> setups.
>
> For example in my case I have a MF/LF setup that consists in a sdr
> receiver tuned at 250kHz and sampling at 500kHz, then I get multiple
> virtual receivers to send the audio to wsprx using pulseaudio null sinks.
> Now I'm looking to put a multiple wsprx in different HF bands at the same
> time using a ettus n210.
>
> Personally I believe that in the 2016 all the ham programs have to support
> audio baseband or IQ via tcp/ip socket, because the physical soundcards are
> the past. Until it not be possible please maintain the native pulseaudio.
>
> Thanks for all
>
> 73! Iban
> eb3frn
>
>
>
>
> --
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r6330 jt65 decoding performance

[Edson W. R. Pereira]

Joe and Frank,

Happy New Year!

For the last few days I have been monitoring the JT65, JT9 and WSPR
activity on 15m and am observing that the performance enhancements in the
decoders are very impressive. Not only in speed, but also in sensitivity
and ability to dig signals from the noise or in-band QRM.

A sincere thank you to both of you. This is amateur radio at it's best.

Please consider, time permitting, a QEX article. This type of technology
milestone deserves to be published.

73, Edson PY2SDR




---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jan 1, 2016 at 3:09 PM, Joe Taylor  wrote:

> Hi Steve,
>
> On 1/1/2016 11:25 AM, Steven Franke wrote:
> > All-in-all - across-the-board improvements are evident and, based on my
> test
> > results, r6330 has the best jt65a decoder performance of any version
> that we
> > have produced to date.
>
> Thanks for sharing your latest test results.  They're fully consistent
> with mine.
>
> Others should know: Steve is too kind with his attributions of credit.
> None of these improvements would have happened without Steve's critical
> insights about a way to implement a soft-decision Reed Solomon decoder,
> and most importantly, a way to assign symbol erasure probabilities in
> the algorithm's inner loop.
>
>   I think we're very close to an appropriate "let's ship it" stage for
> the latest-and-greatest JT65 decoder.
>
> -- Joe, K1JT
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r6330 jt65 decoding performance

[Edson W. R. Pereira]

Hi Joe and Steve,

Excellent news about the QEX article. Looking forward to it!

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jan 1, 2016 at 4:44 PM, Joe Taylor <j...@princeton.edu> wrote:

> Hi Edson,
>
> Thanks for your message -- and HNY!  I'm happy to hear that you, too,
> find the new decoders to be performing very well.
>
> As for the QEX article: it's already somewhat more that half done, in
> draft form. :-)   We'll be happy to send you an advance copy when it's
> done.
> -- Joe
>
> On 1/1/2016 1:33 PM, Edson W. R. Pereira wrote:
> > Joe and Frank,
> >
> > Happy New Year!
> >
> > For the last few days I have been monitoring the JT65, JT9 and WSPR
> > activity on 15m and am observing that the performance enhancements in the
> > decoders are very impressive. Not only in speed, but also in sensitivity
> > and ability to dig signals from the noise or in-band QRM.
> >
> > A sincere thank you to both of you. This is amateur radio at it's best.
> >
> > Please consider, time permitting, a QEX article. This type of technology
> > milestone deserves to be published.
> >
> > 73, Edson PY2SDR
> >
> >
> >
> >
> > ---
> > - We humans have the capability to do amazing things if we work together.
> > - Nós seres humanos temos a capacidade de fazer coisas incríveis se
> > trabalharmos juntos.
> >
> > On Fri, Jan 1, 2016 at 3:09 PM, Joe Taylor<j...@princeton.edu>  wrote:
> >
> >> Hi Steve,
> >>
> >> On 1/1/2016 11:25 AM, Steven Franke wrote:
> >>> All-in-all - across-the-board improvements are evident and, based on my
> >> test
> >>> results, r6330 has the best jt65a decoder performance of any version
> >> that we
> >>> have produced to date.
> >>
> >> Thanks for sharing your latest test results.  They're fully consistent
> >> with mine.
> >>
> >> Others should know: Steve is too kind with his attributions of credit.
> >> None of these improvements would have happened without Steve's critical
> >> insights about a way to implement a soft-decision Reed Solomon decoder,
> >> and most importantly, a way to assign symbol erasure probabilities in
> >> the algorithm's inner loop.
> >>
> >>I think we're very close to an appropriate "let's ship it" stage for
> >> the latest-and-greatest JT65 decoder.
> >>
> >>  -- Joe, K1JT
> >>
> >>
> >>
> --
> >> ___
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >>
> >
> >
> >
> >
> --
> >
> >
> >
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Signal Strength in v1.7.0

[Edson W. R. Pereira]

Hello everyone,

I have been monitoring using wsjt-x v1.7.0 r6286 and am noticing that the
JT65 decoder is not showing signal strengths stronger than -1 dB. Even with
very strong signals the decoder shows -1 dB. The JT9 decoder does show
signal strengths above 0 dB.

Has anyone noticed this?

73 and season's greetings,

Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Fortran Error

[Edson W. R. Pereira]

Compiled ok and running without any immediate apparent issues.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Thu, Dec 17, 2015 at 8:44 AM, Bill Somerville 
wrote:

> On 17/12/2015 05:27, Michael Black wrote:
> > jt65.f90 has the wrong# of arguments to jt65a
> > It's missing mycall, hiscall, hisgrid
> >
> > So I think the attached patch fixes it.
> Hi Mike & Scott,
>
> Joe fixed the issues earlier for the main application. I have just
> committed a change for the standalone jt65 test utility.
>
> 73
> Bill
> G4WJS.
>
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] snd-aloop subdevices

[Edson W. R. Pereira]

Hi Steve,

What device names for the virtual devices do you see in wsjt-x? I suspect
you are facing an old bug in Qt. Qt insists in not displaying the correct
audio device names in Linux.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Sat, Nov 28, 2015 at 11:30 AM, Steven Franke 
wrote:

> Hi Bill, Joe, and all,
> I have an 8-channel sdr, implemented using Gnuradio, that writes 8 audio
> streams to the 8 subdevices associated with the snd-aloop Loopback device.
> I was playing around with the idea of running 8 instances of wsjt-x, with
> each instance connected to one of the 8 subdevices. The problem that I
> encountered is that the subdevices are not explicitly listed in the list
> provided in the wsjt-x setup dialog. How would I tell wsjt-x which
> subdevice to use? I should note that I do see the loopback device, and I
> can connect to it and everything works OK, but I seem to get the "next
> available" device, making it hard to be sure what subdevice is actually
> being used.
>
> I tried setting up an .asoundrc file that assigns unique names to each
> subdevice. I can see all of the subdevices from within fldigi, and can
> connect to any one of them, so I am convinced that the basic pieces are all
> working.
>
> The overall idea is to run with the 8 instances minimized, showing only
> the 8 waterfalls, and to use the UDP client to view the combined set of
> spots.
> Steve k9an
>
> --
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] high sensitivity of decoder vs TRX AGC handling

[Edson W. R. Pereira]

Hello Igor,

I agree with your analysis of the AGC issue. I have tested a few HF
transceivers that can have AGC turned off and all have issues with audio
distortion. As you have mentioned, using the attenuator alleviates the AGC
problem a little, but decreases the sensitivity of the receiver -- witch
could be necessary in certain conditions. When I am working a DX station,
often there are very strong signals in the passband that dominates the AGC
-- in some cases blanking out the DX station completely. Using an
attenuator in these cases would not help since the signal from the DX
station was already very weak.

The solution I am using is to use an SDR receiver. It provides me with
complete control of the RX bandwidth and have zero issues with AGC turned
off.

In my case I use an SDR-IQ. For TX, I, for now, use the TX in the HF
transceiver, but I am working on a homebrew project of a simple HF
transmitter designed specifically for WSPR and the JT modes on HF.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Thu, Nov 12, 2015 at 7:15 AM, Игорь Ч  wrote:

> Hi Steve and Joe,
>
> I mostly agree with all your statements but one: dynamic range. I am sure
> there is enough headroom in sound card and WSJT-X to upper border of the
> dynamic range.
>
> What makes me worry is that when RF gain is used (some people do use
> attenuator) to get to more linear band of the AGC operation, it supresses
> receiver sensitivity putting very weak signals out of scope of the decoder.
>
> As RF gain control in action is similar to input attenuator signal coming
> with -24 dB with maximum RF gain position will be forever lost in receiver
> AF output if RF gain decrease is applied.
>
> For instance, in one of my shacks in countryside I have on 15m band such
> low noise from antenna that I can not hear it by ears under the input
> circuits noise of my receiver which has 0.11 uV sensitivity. When band is
> open I get very strong signals from Europe and this antenna is working very
> well on TX. Just imagine how many weak signals would disappear if I will be
> using RF gain control with AGC turned on... Of course I always keep AGC
> turned OFF in my transceiver.
>
> Another concern that worries me as owner of classic transceiver: when AGC
> turned off I getting IMD in transceiver AF line output starting from signal
> levels that correspond S7 on my S-meter (it does not reflect real signal
> strength as I have modified 1st IF in receiver with extra low noise and
> narrow bandwidth regenerative amplifier). I have also modified AF line
> output to get it more linear but still have dynamic range there that is far
> below of the soundcard one or WSJT-X.  Of course IP connected DDC SDR have
> not got AF path, and IP DDC SDR is perfect solution for keeping AGC off.
> But all classic transceivers have heavy AF IMD with many IMD products in AF
> output in presence of the strong signals if AGC is OFF. These IMD products
> plaing the same trick with WSJT-X creating spurious candidates as does it
> the AGC.
>
> 73,
>
> Igor UA3DJY
>
>
> *Re: [wsjt-devel] high sensitivity of decoder vs TRX AGC handling
> *
> From: Joe Taylor  - 2015-11-12 01:24:21
>
>
> Hi Igor and Steve,
>
> Perhaps it's worth mentioning that our advice for all WSJT-related
> programs has always been to disable the receiver AGC (if possible) and
> turn the RF gain control well down, thereby minimizing AGC action.  If
> you do this and follow instructions in the User Guide about setting the
> signal level coming into the sound card (or equivalent device), there's
> plenty of dynamic-range "headroom" still available for nearly all
> situations.
>
> The decoders know how to handle widely different signal levels, and they
> appreciate having a reliably constant baseline noise level during an Rx
> sequence.
>
>   -- Joe, K1JT
>
>
>
> Среда, 11 ноября 2015, 18:32 -06:00 от Steven Franke <
> s.j.fra...@icloud.com>:
>
>
> Hi Igor,
>
> Since this may be of interest to others, I’m copying this reply to the
> list. First, I’d like to echo what Joe said earlier. If you are running in
> JT65A mode and if your search range is the same for all cases, then you
> should see identical results on all platforms and operating systems with
> the only difference being execution time.
>
> Having said that, I agree that r6052 and r6058 should perform differently
> on different types of files. In fact, your most recent results are as I
> would expect. Recall that r6052 uses a standard floating-point correlation
> function for identifying candidates for further processing. If there are no
> impairments to the data, then the algorithm used in r6052 should be the
> most sensitive and the most accurate. As such, it is no surprise that you
> see better results with r6052 for your 

Re: [wsjt-devel] WSPR decoder: Jelinek vs Fano

[Edson W. R. Pereira]

Hello Joe, Steve, and all,

With the experiments I have been doing with WSPR on the Raspberry-Pi, I
have implemented a simple spot feeder to wsprnet and have been thinking
about adding a mechanism to check if a spot just received is in the
ALL_WSPR.TXT before sending the spot to wsprnet. This would perhaps filter
off most false spots. The draw back is that the first reception of a valid
spot would no be forwarded. But since the likelihood of receiving only a
single spot is unlikely, once the fist spot is received for a call, all
subsequent spots would be sent to wsprnet.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jul 31, 2015 at 11:11 AM, Joe Taylor j...@princeton.edu wrote:

 Hi Steve,

 Interesting results.  We should definitely pay a bit more attention to
 the false decodes.  Maybe setting bias as low as 0.42 is not a good idea?

 -- Joe

 On 7/30/2015 11:25 PM, Steven Franke wrote:
  Joe,
  Here are my results for your data set. I ran 3 cases. The execution
 times are the average of two runs.
 
  Cases
  1. wsprd
  2. wsprd_exp (Fano, 1 cycles)
  3. wsprd_exp (Jelinek, 5000 cycles)
 
  Results
  1. 2657 (2) decodes in 359s
  2. 2760 (13) decodes in 359s
  3. 2749 (3) decodes in 346s
 
  The interesting part is the number in parentheses. This time, I paid
 attention to the number of obviously bad decodes. It’s not easy to find the
 bad decodes that show up as type 1 callsigns - but it is easy to find and
 count the ones that show up as type 2 or 3 callsigns with a forward slash
 “/“. The number in parentheses is the number of bad decodes with a slash in
 the callsign. It needs to be said that we see only the bad decodes that
 aren’t trapped by a sanity check in the unpacking routines.
 
  There is something funny going on with the Fano decoder in case 2. Here
 is the result of doing a grep for “/“ in the ALL_WSPR results from the
 three cases:
 
  Case 1. wsprd
  $ grep / Results_wsprd
  0342 -28 0.5 0.001523 0 PH6/OK1SCE 10
  0630 -14 -0.8 0.001518 0 M0N/BX6IJG 30
 
  Case 2. wsprd_exp Fano
  $ grep / Results_Fano.txt
  0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33
  0148 -22 -0.9 0.001523 0 C4S/U23 27
  0512 -12 -1.4 0.001544 -1 EYJ/BD3OWF 43
  0526 -5 -1.1 0.001515 -1 J28/JH9VOA 10
  0530 -10 -1.3 0.001527 -1 XIR/L12IRI 57
  0534 -21 0.1 0.001451 0 5EY/588TIB 53
  0540 -9 -1.3 0.001498 -1 286/CI7RCI 13
  0614 -8 -1.2 0.001523 -1 W64/CZ9IYO 13
  0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13
  0704 -10 -1.3 0.001550 -1 KN4OHP/44 53
  0746 -8 -1.4 0.001525 -1 ATD/012KCR 27
  0856 -19 -0.8 0.001523 0 I02/VK3PNP 20
  1400 -17 -0.5 0.001459 0 P2INE/2 53
 
  Case 3. wsprd_exp Jelinek
  $ grep / Results_Jelinek5000.txt
  0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33
  0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13
  0654 -12 -1.3 0.001523 -1 1LY/GH4 40
 
  Note the large number of bad decodes coming out of the Fano decoder in
 case 2. There is only one bad decode that is common to cases 2 and 3. If
 you look at the times, it appears that the bad decodes in case 2 are coming
 in bursts. I have to wonder if this corresponds to special noise
 conditions, e.g. lightning storm.
 
  It’s hard to reconcile the large difference in bad decodes between pairs
 1-2 and 2-3. In 1-2 the decoding algorithm is the same and in 2-3 the
 candidates are the same.  Strange, eh?
 
  I’ve just gone back and looked at bad decodes using the same
 “forward-slash” criterion on two groups of my own wav files and in each
 case I see either 2 or 3 bad decodes out of about 2000 for Fano and
 Jelinek. There are no big differences between the number of bad decodes in
 cases 1-3 for my test data. Still strange.
 
  Steve k9an


 --
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Sourceforge SVN repository is down

[Edson W. R. Pereira]

Interesting and rather strange that they were trying to put web services up
before the repositories.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jul 24, 2015 at 4:20 AM, Alan VK2ZIW bea...@unixservice.com.au
wrote:

 Hi all,

 In case you are having trouble.

 July 24 2015 07:17:00

 svn: E000111: Unable to connect to a repository at URL
 'svn://svn.code.sf.net/p/wsjt/wsjt'
 svn: E000111: Can't connect to host 'svn.code.sf.net': Connection refused

 And, by Sourceforge's blog, they are having trouble:

 https://twitter.com/sfnet_ops?lang=en

 Alan VK2ZIW

 Man's greatest waste of time: Worshipping the wrong God.
 Consider Jesus.
 ---
 Alan Beard   Unix Support Technician from 1984 to today
 70 Wedmore Rd.   Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS
 Emu Heights N.S.W. 2750  Routers, terminal servers, printers, terminals
 etc..
 +61 2 47353013 (h)   Support Programming, shell scripting, C,
 assembler
 0414 353013 (mobile) After uni, electronics tech



 --
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem

[Edson W. R. Pereira]

Steve and Joe,

Just started running wsprd_exp on my Raspberry Pi. Compilation went clean
and I am decoding spots. Over the weekend I will do some more tests with
some recorded wspr audio files.

The recent improvements on wsprd are simply remarkable. The techniques
employed are novel and would make a excellent topic for a QEX article!

Many thanks and congratulations for the achievements.

73, Edson PY2SDR



---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jun 26, 2015 at 1:31 PM, Steven Franke s.j.fra...@icloud.com
wrote:

 Hi Joe,

 I’m glad to see that you were able to confirm the improved performance of
 the two-pass decoder. I’m guessing that your dataset includes a more
 representative mixture of bands and conditions than the group of 20m files
 that I used. Hence the smaller, but still significant, increase in the
 number of decodes over the default wsprd.

 I am surprised by your observation that the two-pass decoder is faster
 than the default one. That’s not what I see here. Are you using your
 wspr_timer.out times? Or some other measure of execution time? The numbers
 that I reported were the “Total” times from wspr_timer.out.

 I just ran the analysis of my 20m files using the current default wsprd.
 It was slightly slower than running wsprd_exp with the -s (single-pass
 option):

 wsprd: 1315 decodes in 163s
 wsprd_exp -s: 1315 decodes in 159s (taken from Table 1 in the .pdf writeup)

 But in my case, both of these single-pass times are much shorter than the
 two-pass execution time, which was 270s. I wonder if there is some compiler
 optimization setting that was different between your wsprd and wsprd_exp
 instances?

 Steve k9an


  On Jun 26, 2015, at 11:00 AM, Joe Taylor j...@princeton.edu wrote:
 
  Hi all,
 
  I have committed a Makefile.win32 for building wsprd_exp.exe during
  testing.
 
  I have now run compartson tests of wsprd.exe and wsprd_exp.exe using a
  group of 410 *.wav files, with the following results:
 
  -
 Decoder   Decodes Time
(s)
  -
  1. wsprd   2291   524
  2. wsprd_exp   2551   418
  3. wsprd_exp   2653   434
  -
 
  Run #1 used the default wsprd.exe now built along with WSJT-X v1.6.0.
  Run #2 uses Steve's wsprd_exp with incoherent (symbol-by-symbol) signal
  subtraction; #3 used his fully coherent subtraction routine.
 
  Important note: to make the coherent subtraction work in Windows I had
  to increase the stack size -- see LDFALGS in Makefile.win32.
 
  So, with these example files I got 11% more decodes with
  symbol-by-symbol subtraction and 16% more decodes with coherent
  subtraction.
  The two-pass decoder appears to be faster than the single-pass one.  (I
  don't yet know why, but in a couple of runs this seems to be repeatable.)
 
  I think these results are very impressive!  We should certainly make
  wsprd_exp (renamed to wsprd) the default WSPR decoder.
 
-- 73, Joe, K1JT
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel



 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem

[Edson W. R. Pereira]

Hello Steve,

Can you confirm that this is the right path for wsprd_ext source?

https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/lib/wsprd/

I will compile it on the R-Pi and run some tests.

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Fri, Jun 26, 2015 at 10:10 AM, Steven Franke s.j.fra...@icloud.com
wrote:

 Hi Greg,
  On Jun 25, 2015, at 11:10 PM, KI7MT ki7m...@gmail.com wrote:
 
  Hi Steve,
 
  Just so I am clear on this. The Makefile (Linux) has three targets,
  wsprd, wsprsim and wspr_exp. All we need to build is wspr_exp as the
  wsprd is being dealt with by Cmake yes?
 Yes, the regular wsprd and the simulation program wsprsim are built by
 Cmake, but not wsprd_exp.
 
  I'll be adding this to JTSDK Nix to build and cp the wspr_exp decoder to
  install/bin location on each turn.
 
  I had brief look at the Windows Makefile.MinGW but did not see the
  wsprd_exp target listed, so I am assuming this is only being tested on
  *Nix ??
 I have only tested wsprd_exp on linux and OS X. I don’t have a Windows
 machine.

 Thanks for adding wsprd_exp to the WSJT-X build script. Some time soon I
 think that we’ll want to just rename wsprd_exp to wsprd and have it replace
 the current decoder. Before we do that, Id like to see that at least a
 couple of people besides me have been able to use wsprd_exp without
 problems.

 Steve k9an

 
  73's
  Greg, KI7MT
 
  On 06/24/2015 07:30 PM, Steven Franke wrote:
  For those testing wspr mode in wsjt-x, I have placed a .pdf file
 containing information on the current status of the experimental two-pass
 decoder wsprd_exp at this link:
 
  https://dl.dropboxusercontent.com/u/33211132/signal_subtraction.pdf
 
  I have been running the two-pass decoder with wsjt-x and with my
 8-channel gnuradio-based setup for the past several days without any
 problems.
  If you would like to play with the new decoder, the Makefile in the
 wsjt-x/lib/wsprd directory will compile it. For testing with wsjt-x, I
 renamed the executable wsprd and copied it into the wsjt-x install/bin
 directory.
 
  While testing this new decoder I used a batch of .wav files and also a
 separate batch of .c2 files that were written by the latest wsjt-x. I
 eventually realized that all of the .c2 files that were written by wsjt-x
 were contaminated by signal dropouts. See “Case 3” in the pdf document for
 an example and more details. After discovering the problem with the .c2
 files, I saved a batch of .wav and .c2 files using wsjt-x and found that
 the .wav files were fine, but that the .c2 files were contaminated. This
 makes me wonder if the problem lies in the writec2 routine in wsjt-x. I
 welcome input/opinion on this from those who are more familiar with the
 code. Could this problem somehow be specific to my setup?
 
  Steve k9an
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel



 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Displayed fonts

[Edson W. R. Pereira]

Joe,

Fonts across different platforms is a major source of headaches in making
software portable. Even fonts of the same family can vary across operating
systems. But it is possible.

The problem you are seeing is likely to be due to Qt not finding the chosen
font, trying to search for something equivalent, failing, and defaulting.
One way I did find to mitigate the problem is to use CSS (style sheets) for
the widgets I need more tight control and use a list of fonts that I have
tested on the various OSes. Another possibility is to use a #ifdef for each
OS and specify the font using CSS for a given widget. A configuration
parameter would permit the user to chose the point-size of a font, but not
the type or family.

This is the list of style-sheets for the various Qt widgets:
http://doc.qt.io/qt-5/stylesheet-reference.html

73, Edson PY2SDR







---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, Jun 10, 2015 at 3:36 PM, Joe Taylor j...@princeton.edu wrote:

 Can anyone help me to understand how to make the on-screen appearance of
 WSJT-X look more uniform, across platforms and OS settings?

 To see one example that bugs me, look at the Astronomical Data windows
 in screen shots of Echo mode at my station and G3WDG:

 http://physics.princeton.edu/pulsar/K1JT/EchoTest_4.png
 http://physics.princeton.edu/pulsar/K1JT/100Wechomode.jpg

 The first one evidently uses the fonts I intended it to use (Courier
 14, bold), and the numbers are aligned as intended.

 In the second picture, taken at G3WDG, some other font has been
 substituted.  Judging from the WSJT-X main window in Charlie's screen
 shot, I guess he has told Windows to use larger fonts (125%) than the
 default.  In this instance, the substituted fonts are not even
 monospaced, which with the present code does not work well.

 The larger system fonts also have the effect of making some labels not
 fit the size of the control they're on.

 Can we do anything in this area to make out on-screen appearance better?

 -- Joe, K1JT


 --
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Refactoring of mainwindow.cpp

[Edson W. R. Pereira]

Hello Joe and everyone,

Recently I have been experimenting with the new C implementation of the
WSPR decoder on a Raspberry Pi SBC and am getting excellent results in
terms of stability and performance. I am now implementing transmitting the
code for transmission and for monitoring/controlling the setup remotely. On
this regard, I have been thinking that the JT modes, in general, are
excellent for remote operations. I believe it would be a very useful and
welcome feature if wsjt-x could support remote operations. This could be
done in a number of ways, but I believe that one elegant way would be
detaching the UI from the control, I/O, and codecs functions.

In a local station setup, the UI coould start a daemon that performs all
the current functions and communicate with the daemon using TCP/IP sockets.
On a remote station the daemon could be automatically started and a UI
could connect to the remote station from anywhere in the world where an
Internet access is available.

Initially the setup could be implemented for a single user and later
multi-user could be considered. For security reasons, some sort of
authentication would be required for remote access. A shared key could be
an option.

Since we are about to start refactoring the wsjt-x code, I thought it would
be a good time to present this proposal.

Any thoughts?

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Dial calibration errors

[Edson W. R. Pereira]

Hello Joe,

I just checked some of the common received spots between my station and
Steve's on 15m and I am 9 Hz off (down). This makes me think that having a
standard station in WSPR like Steve's could allow an automatic calibration
by performing a query on the wsprnet database for our station and a
standard one and compare the results The difference could be converted into
the A and B values. Could this work?

73, Edson PY2SDR


---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Mon, May 18, 2015 at 11:09 AM, Joe Taylor j...@princeton.edu wrote:

 A few more thoughts about dial calibration errors.

 A couple of days ago I put my TS-2000 radio through the calibration
 procedure described in Appendix C of the WSPR 4.0 User's Guide
 http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf

 The procedure takes about half an hour, end to end, yielding the values
 of two constants A and B.  These constants appear in the equation

d = A + B*f

 where d is the radio's dial error in Hz and f is the received frequency
 in MHz.  In my case the constants are A = 2.14 Hz and B = 1.6254.  I
 note that the value of A has remained constant, but several years ago B
 was somewhat smaller (B = 1.2885 in 2011), so the master oscillator in
 my TS-2000 has aged a bit.

  From the values of A and B I computed the dial error for each amateur
 band and entered those values (expressed in MHz) in the Offset column
 of the WSJT-X Settings | Frequencies tab.  Frequencies reported for my
 WSPR decodes now agree with those reported by Steve, K9AN, to within 1
 Hz.  (Steve's receiver uses GPS-disciplined oscillators, so his WSPR
 reports are a good standard for comparison.)

 It might be handy to permit a user of WSJT-X to enter values for A and B
 and have the program calculate the resulting Offset values for the
 Frequencies tab.  The resulting system behavior is very sensible, in my
 opinion.  When WSPRing on 20 meters, for example, my TS-2000 dial now
 reads 14.09562 MHz.  WSJT-X intentionally sets the radio about 24 Hz
 high on  this band, to compensate for its dial error.

 The dial frequency displayed on the WSJT-X main window is the corrected
 value, 14.095 600 MHz.

 -- 73, Joe, K1JT

 On 5/13/2015 10:48 AM, Joe Taylor wrote:
  Hi all,
 
  One of the fun things about WSPR is the frequency accuracies that
  are involved.  Having WSPR mode in WSJT-X motivates some serious thought
  about how best to handle frequency calibration errors in transceivers.
 
  Typical dial readout errors in modern radios are a few parts per million
  -- for example, a 20 Hz error at 14 MHz.  For JT65 or JT9 such
  discrepancies are not very important.  But the WSPR sub-bands in
  conventional use since 2008 are only 200 Hz wide, and we'd like to use
  all of that range effectively.  If my transceiver's dial reads 20 Hz
  low, and yours reads 20 Hz high, and we both set our dials to the
  conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx
  frequencies at random within the 200 Hz sub-band there's something like
  a 20% chance that we won't decode one another.
 
  Earlier production versions of WSPR have handled these issues in a
  rather sophisticated way.  The User's Guide includes detailed
  instructions for determining calibration constants for your transceiver
  using over-the-air signals (see Appendix C of
  http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ).  The
  resulting accuracies can be better than 1 Hz.
 
  If CAT control is in use and  Enable frequency correction is ticked on
  WSPR's Advanced Setup window, frequencies sent to the radio are
  adjusted so as to compensate for the dial errors.  For example, if
  14.0956 MHz has been requested, the command for 14095620 Hz may be sent
  to the radio.
 
  I picture this being implemented in WSJT-X in a similar way.  In this
  example, the radio dial would read 14.096520.  I'm suggesting that the
  frequency readout on the WSJT-X screen would read 14.095600, the
  supposedly true frequency.
 
  Comments and suggestions would be welcome.
 
-- 73, Joe, K1JT
 
 
 --
  One dashboard for servers and applications across Physical-Virtual-Cloud
  Widest out-of-the-box monitoring support with 50+ applications
  Performance metrics, stats and reports that give you Actionable Insights
  Deep dive visibility with transaction tracing using APM Insight.
  http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring 

Re: [wsjt-devel] Dial calibration errors

[Edson W. R. Pereira]

Hi Joe,

Would it add too much complexity to have the frequency error correction in
the audio base band of the decoders? This would prevent having to re-tune
the rig and would also allow crystal controlled transceivers to also have
frequency error correction.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, May 13, 2015 at 11:48 AM, Joe Taylor j...@princeton.edu wrote:

 Hi all,

 One of the fun things about WSPR is the frequency accuracies that
 are involved.  Having WSPR mode in WSJT-X motivates some serious thought
 about how best to handle frequency calibration errors in transceivers.

 Typical dial readout errors in modern radios are a few parts per million
 -- for example, a 20 Hz error at 14 MHz.  For JT65 or JT9 such
 discrepancies are not very important.  But the WSPR sub-bands in
 conventional use since 2008 are only 200 Hz wide, and we'd like to use
 all of that range effectively.  If my transceiver's dial reads 20 Hz
 low, and yours reads 20 Hz high, and we both set our dials to the
 conventional 14.0956 MHz for 20 meters, after setting our WSPR Tx
 frequencies at random within the 200 Hz sub-band there's something like
 a 20% chance that we won't decode one another.

 Earlier production versions of WSPR have handled these issues in a
 rather sophisticated way.  The User's Guide includes detailed
 instructions for determining calibration constants for your transceiver
 using over-the-air signals (see Appendix C of
 http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf ).  The
 resulting accuracies can be better than 1 Hz.

 If CAT control is in use and  Enable frequency correction is ticked on
 WSPR's Advanced Setup window, frequencies sent to the radio are
 adjusted so as to compensate for the dial errors.  For example, if
 14.0956 MHz has been requested, the command for 14095620 Hz may be sent
 to the radio.

 I picture this being implemented in WSJT-X in a similar way.  In this
 example, the radio dial would read 14.096520.  I'm suggesting that the
 frequency readout on the WSJT-X screen would read 14.095600, the
 supposedly true frequency.

 Comments and suggestions would be welcome.

 -- 73, Joe, K1JT


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSPR in WSJT-X

[Edson W. R. Pereira]

Hello Joe,

It would be quite nice to have WSPR integrated in WSJT-X. However, I think
we should try to preserve modularity as much as possible (high cohesion and
low coupling in Object Oriented Programming semantics). Separating the GUI
from the audio threads, rig control and the various decoders.

There are a few benefits having high modularity. Testing being the first
one for us developers. But modularity also fosters experimentation. A
specific module could be used separately in some experimental project. In
this regards, the GUI would know nothing about audio, decoding, rig
control, etc. Each of these modules should be a stand alone library or
program (like the way the decoders of wsjt-x and wspr are already
implemented).

We already have a WSJT-X implemented with modularity in mind. This message
is just an appeal for us to keep it in mind and preserve it.

73, Edson PY2SDR





---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Wed, Apr 22, 2015 at 3:41 PM, Joe Taylor j...@princeton.edu wrote:

 Hi Claude, Richard, Greg, and all,

 KI7MT wrote:
  FWIW, I think this is a good Idea. I addition to the Hamlib updates, I
  would think the Qt Audio subsystem would also be of benefit.
 
  I like Python, but keeping the tool-chains and frameworks similar would
  surely be a plus and may even draw more developers to the project(s).
 
  There seems to be allot of folks that like the RTW (Real Time Water
  Fall) WSPR-X provides. I'm not sure about IQ support, but I see a fare
  number of questions asked about that also.

 We seem to agree that WSPR capability in WSJT-X is potentially a good
 idea.

 I will look into it as time permits, to see if there are any show-stoppers.

 -- Joe, K1JT


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Low cost WSJT transceiver

[Edson W. R. Pereira]

Hello Bill,

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Thu, Feb 19, 2015 at 11:21 AM, Bill Somerville g4...@classdesign.com
wrote:


  I would like insert some code on WSJT-X to interface it with a software
 that will drive the DDS. For this I am thinking of writing the TX symbols
 to a file and have the file monitored. When a change to the file is
 detected the driver software reads the symbols and activate the TX.

 While it might be very easy to convert the symbol stream directly to MFSK
 output, I would have thought that the extra work to accept a generic 16-bit
 LE sample stream would be of far greater use in many applications? Do you
 gain anything in performance by direct synthesis from symbols as opposed to
 modulating from a sample stream?


 Consuming the raw samples would make things unnecessarily complicated. All
that I need is the 85 symbols. I read each symbol one-by-one and map each
one to the correct DDS frequency word for direct RF synthesis. This will
generate a very clean RF signal.


  Do you think it would it be of interest to have the changes committed to
 WSJT-X repository? The only addition will be the creation and update of one
 file when the TX is activated. No other changes will be necessary.

 How are you going to maintain the required time synchronization?



There will be a very small delay between the TX event in WSJT-X and reading
the file and triggering the actual TX. But I expect this to be in the order
of a few milliseconds. I don't think this will have any significant impact.
The important sync work will be done by the QFIleSystemWatcher class in Qt.
I intend to perform some instrumentation to measure the actual times.

73, Edson PY2SDR
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] [wsjtgroup] 80 m frequency for JT65 and JT9

[Edson W. R. Pereira]

Hello Joe,

The IARU has recently released new bandplans and a lot of though has been
put into them in order to attempt consolidation between all three regions
as much as possible. I think it would be good for us if the JT modes
activity would happen in the proposed segments. Besides the issue on 80m,
we may also encounter the same in 40m where digital modes are now allocated
in the 7040~7053 kHz segment.

73, Edson PY2SDR

---
- We humans have the capability to do amazing things if we work together.
- Nós seres humanos temos a capacidade de fazer coisas incríveis se
trabalharmos juntos.

On Thu, Nov 13, 2014 at 2:36 PM, Joe Taylor j...@princeton.edu [wsjtgroup] 
wsjtgroup-nore...@yahoogroups.com wrote:



 Hi all,

 I have been advised that the default 80-meter frequency compiled into
 WSJT-X, 3.576 MHz, is not compliant with the current IARU recommendation
 for region 1 and 2. Frequencies 3.580 or 3.586 MHz were suggested as
 possible alternatives.

 Comments on this possible change would be appreciated.

 -- Joe, K1JT
  __._,_.___
   --
 Posted by: Joe Taylor j...@princeton.edu
 --
 Reply via web post
 https://groups.yahoo.com/neo/groups/wsjtgroup/conversations/messages/13489;_ylc=X3oDMTJxMW81bGhiBF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BG1zZ0lkAzEzNDg5BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQxNTg5NjU3Ng--?act=replymessageNum=13489
 •  Reply to sender
 j...@princeton.edu?subject=Re%3A%2080%20m%20frequency%20for%20JT65%20and%20JT9
 •  Reply to group
 wsjtgr...@yahoogroups.com?subject=Re%3A%2080%20m%20frequency%20for%20JT65%20and%20JT9
 • Start a New Topic
 https://groups.yahoo.com/neo/groups/wsjtgroup/conversations/newtopic;_ylc=X3oDMTJlbWVrMDZiBF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQxNTg5NjU3Ng--
 • Messages in this topic
 https://groups.yahoo.com/neo/groups/wsjtgroup/conversations/topics/13489;_ylc=X3oDMTM2aXIwc2s2BF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BG1zZ0lkAzEzNDg5BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQxNTg5NjU3NgR0cGNJZAMxMzQ4OQ--
 (1)
 To unsubscribe, send an email to:
 wsjtgroup-unsubscr...@yahoogroups.com
  Visit Your Group
 https://groups.yahoo.com/neo/groups/wsjtgroup/info;_ylc=X3oDMTJlY2V1MmZxBF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQxNTg5NjU3Ng--

- New Members

 https://groups.yahoo.com/neo/groups/wsjtgroup/members/all;_ylc=X3oDMTJma2hibm1xBF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0MTU4OTY1NzY-
1

  [image: Yahoo! Groups]
 https://groups.yahoo.com/neo;_ylc=X3oDMTJkcW03YXRkBF9TAzk3MzU5NzE0BGdycElkAzU3NjQyNTQEZ3Jwc3BJZAMxNzA1MDYzMTA4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDE1ODk2NTc2
 • Privacy https://info.yahoo.com/privacy/us/yahoo/groups/details.html •
 Unsubscribe wsjtgroup-unsubscr...@yahoogroups.com?subject=Unsubscribe • 
 Terms
 of Use https://info.yahoo.com/legal/us/yahoo/utos/terms/

.

  __,_._,___

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Performance and application structure.

[Edson W. R. Pereira]

Hello Bill, Joe, et al,

Bill, I think your suggestion for a callback function would be very good.
It would simplify things. Putting the decoder on a lib is also very good.
This brings back an idea I have been thinking about recently: The
possibility of detaching the DSP and audio engine from the GUI in WSJT-X
for a new application. The engine would be accessible via TCP/IP in order
to enable remote operations. This could also enable the development of
clients for portable phones, tablets, etc.

On the audio issue, a while back I recall Joe mentioning that the main
reason shared memory was used in wsjt-x was because the amount of data
needed to be passed around for the slower (longer) modes. Since we no
longer have the longer modes, would it make sense to revisit the idea of
saving the audio in a wav file and passing the path to the file for the
decoder? This could help running wsjt-x on devices with small memory
footprints (RAspberry Pi comes to mind). The wav file concept could also be
used for TX. Instead of generating the tones in real-time, a wav file could
we written and at TX time, it could be played. Would there be drawbacks on
this approach?

73,

-- Edson PY2SDR



On Tue, Apr 1, 2014 at 10:49 AM, Bill Somerville g4...@classdesign.comwrote:

 On 01/04/2014 14:34, Joe Taylor wrote:
  Hi Bill,
 Hi Joe,
 
  1. First, a few words about the icons.  I haven't had time to trace down
  the exact cause, but I established that if I start WSJT-X from the
  directory into which it was installed by cmake, the proper icon is shown
  on the Windows taskbar.  If, however, I copy the *.exe and *.dll files
  to another place and start WSJT-X from there, a generic icon is shown on
  the taskbar.
 Ah, that's a sequence I hadn't tried. I should be able to find out what
 is going on there, surprising since the Icon is embedded in the exe file.
 
  2. I have not noticed the effect you mention, that Tx audio glitches are
  far more prevalent near the beginning of a transmission.  I'll try to be
  alert for this in future.
 
  I do still notice occasional Tx audio glitches, and they are almost
  always clearly associated with heavy activity of some other Windows
  program -- a browser loading a new page, 7-zip unpacking a big file, etc.
 
  I have been inclined to blame the glitches on the Qt audio package,
  mostly because I am pretty sure they did not occur when we were using
  PortAudio. I believe they don't occur now in our other programs, either.
 MAP65, WSJT, WSPR, and WSPR-X all use PortAudio.
 The Qt audio framework on Windows is a fairly thin layer on top of the
 MS WaveAudio framework but of course the devil is in the detail, perhaps
 some profiling of the Qt audio code is a good place to start looking.

 
  Some tests and experimentation in this area is surely desirable.
 I will carry on investigating.
 
  3. As I've mentioned before, the decision to run the decoder as a
  separate process rather than a separate thread was done first in MAP65,
  as an experiment.  It worked well, and it obviated some issues I had
  struggled with in WSJT, which uses the separate-thread approach.  The
  separate-process approach was then carried over over from MAP65 to
 WSJT-X.
 
  There are, of course, some potential advantages to having everything in
  one process, and it's certainly reasonable to try that approach again.
  As you suggest, a callback could be used to receive decoded text for
  display; or the decode thread could send Qt signals to the GUI thread,
  for this purpose.  By all means, you should feel free to experiment with
  alternative (and potentially better) ways of doing these things.
 I think that Qt specific code (sending signals for example) is probably
 best kept out of the decoder, a simple callback mechanism keeps the code
 highly portable and would remove all Qt dependencies from the decoder
 library, the others being related to the shared memory.

 Although a small point, I think that having a decoder callback with
 numeric arguments is important. Aggregating the decoded data as a string
 prematurely denies us a lot of flexibility in processing and displaying
 decodes.
 
  Reminder: I'll be traveling and mostly incommunicado from tomorrow
  through April 8.
 
-- Joe, K1JT
 Have a good trip
 73
 Bill
 G4WJS.
 
  On 4/1/2014 7:22 AM, Bill Somerville wrote:
  Hi Joe,
 
  Two things on my mind related to WSJT-X.
 
  1) Like you I am concerned about TX synthesizer glitches on Windows
  which seem to be down to some low level stall in the o/s or audio
  framework servicing the DAC. This issue is far more prevalent at the
  beginning of a transmission so it seems reasonable to conclude that not
  having full output buffers is part of the problem. So I think it might
  be worth investigating some synthesizer optimizations. Two strategies
  occur to me:
 
  a) a micro optimization where samples are buffered in a local cache
  until a repeat condition occurs (N full audio oscillations) and from
  

Re: [wsjt-devel] WSJT-X qmake builds.

[Edson W. R. Pereira]

Bill,

Have you tried qmake system() funcion?

73,

-- Edson



On Sun, Mar 30, 2014 at 10:49 PM, Bill Somerville g4...@classdesign.comwrote:

 Hi All,

 I have been struggling to find a way to get the CMake build and the
 qmake build to coexist without success so far.

 The problem is a file that the CMAke build generates in the build tree.
 It is called 'svnversion.h' and is included by C or C++ files that need
 to know the current svn revision. But in a qmake build no such file gets
 generated.

 I tried checking in a file called svnversion.h making sure that the
 CMake builds don't pick it up but that, I've just discovered, breaks the
 CMake build dependencies.

 So if anyone knows how to get qmake to generate a header file I would be
 most appreciative. The file doesn't have to contain anything, it just
 needs to exist somewhere sources compiled by qmake makefiles will
 include it.

 I suppose I could check one in in a subdirectory and change the qmake
 include paths to see it, does anyone have a better idea?

 73
 Bill
 G4WJS.


 --
 ___
 wsjt-devel mailing list
 wsjt-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel