Bill,
> On Jul 2, 2015, at 1:46 PM, Bill Somerville wrote:
>
> On 29/06/2015 15:00, Bill Somerville wrote:
>
> Hi Steve & others who build gnuradio and WSJT-X on Mac,
>
> ...
>
>>
>> OK, the problem wasn't quite what I thought. It is an include directive
>> ordering issue but it stems from th
On 29/06/2015 15:00, Bill Somerville wrote:
Hi Steve & others who build gnuradio and WSJT-X on Mac,
...
>
> OK, the problem wasn't quite what I thought. It is an include directive
> ordering issue but it stems from the use of FFTW3 from MacPorts, this in
> itself is not an issue but it has the s
Hi Bill,
> On Jul 1, 2015, at 8:39 AM, Bill Somerville wrote:
>
> On 01/07/2015 14:25, Steven Franke wrote:
>> Bill, Joe, Michael, and all,
> Hi Steve,
>> Do we know what change caused the larger stack requirement?
>> Yes, I caused this problem by being lazy when I added the arrays used for
>> s
Goodmorning Bill,
Using the JTS-QT environment I did build-wsjtx rinstall and successfully
completed r5647 which is behaving just fine. I can only suspect the diff since
r5644 and r5647 has resolved my issue. Thanks for the response.
Bob Kalkwarf w7wo
> On Jul 1, 2015, at 3:19 AM, Bill Somerv
opped
(windows message)
-Message d'origine-
De : Bill Somerville [mailto:g4...@classdesign.com]
Envoyé : mercredi 1 juillet 2015 12:20
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
On 01/07/2015 06:16, Robert Kalkwarf wrote:
&g
let 2015 12:20
À : wsjt-devel@lists.sourceforge.net
Objet : Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
On 01/07/2015 06:16, Robert Kalkwarf wrote:
> Steve,
Hi Bob,
>
> Win7 32 bit
>
> I get an Error running or starting c:/WSJT/wsjtx/bin/wsprd
That looks like you ha
On 01/07/2015 14:25, Steven Franke wrote:
> Bill, Joe, Michael, and all,
Hi Steve,
> Do we know what change caused the larger stack requirement?
> Yes, I caused this problem by being lazy when I added the arrays used for
> signal subtraction. I’m at work this morning, but will be able to look at
Bill, Joe, Michael, and all,
> On Jul 1, 2015, at 8:02 AM, Bill Somerville wrote:
>
> On 01/07/2015 13:54, Joe Taylor wrote:
>> Hi Steve, Bill, and all,
> Hi Joe,
>>
>> On 6/30/2015 6:18 PM, Steven Franke wrote:
>>> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
>>> wh
lto:g4...@classdesign.com]
Sent: Wednesday, July 01, 2015 8:02 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
On 01/07/2015 13:54, Joe Taylor wrote:
> Hi Steve, Bill, and all,
Hi Joe,
>
> On 6/30/2015 6:18 PM, Steven Frank
On 01/07/2015 13:54, Joe Taylor wrote:
> Hi Steve, Bill, and all,
Hi Joe,
>
> On 6/30/2015 6:18 PM, Steven Franke wrote:
>> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
>> which makes decoder #5 from Joe’s table, below, the default decoder in
>> wsjt-x ver 1.6. It is no
Hi Steve, Bill, and all,
On 6/30/2015 6:18 PM, Steven Franke wrote:
> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
> which makes decoder #5 from Joe’s table, below, the default decoder in
> wsjt-x ver 1.6. It is no longer necessary to separately compile
> wsprd_exp to g
On 01/07/2015 06:16, Robert Kalkwarf wrote:
> Steve,
Hi Bob,
>
> Win7 32 bit
>
> I get an Error running or starting c:/WSJT/wsjtx/bin/wsprd
That looks like you have installed using an installer generated by the
package build option. Have a look in the installed folder and see if
wsprd.exe is ther
Interesting results with with "decoder #5" on 20M this evening:
2015-06-30 22:52 PA0MLC 14.097121 -4 0 JO31aw 5
NO3M EN91 6335 297
2015-06-30 22:52 G6KIZ 14.097121 -16 4 JO02fu
0.2 NO3M EN91 5949 293
20
Steve,
Win7 32 bit
I get an Error running or starting c:/WSJT/wsjtx/bin/wsprd
Tried build-wsjtx install
Tried build-wsjtx package
Answered y both times to update. HELP says I am running r5644
Clue Please?
73 Bob w7wo
> On Jun 30, 2015, at 3:18 PM, Steven Franke wrote:
>
> For those
For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644 which
makes decoder #5 from Joe’s table, below, the default decoder in wsjt-x ver
1.6. It is no longer necessary to separately compile wsprd_exp to get the
benefits of two-pass decoding.
Steve k9an
> On Jun 29, 2015, at 6
Hi Steve,
>> The test runs all used the same set of 386 *.wav files, processed with
>> the following decoders:
>>
>> 1. wsprd, from WSPR-X (baseline decoder)
>> 2. wspr4
>> 3. wsprd, as built for WSJT-X v1.6.0 r5636
>> 4. wsprd_exp, signal subtraction using symbol-by-symbol coherence
>> 5. wsprd_e
Hi Joe,
> On Jun 29, 2015, at 11:53 AM, Joe Taylor wrote:
>
> Hi Steve and all,
>
> I have run a new series of tests of various WSPR decoders, with results
> that may be of interest to others.
>
> The test runs all used the same set of 386 *.wav files, processed with
> the following decoders:
Hi Steve and all,
I have run a new series of tests of various WSPR decoders, with results
that may be of interest to others.
The test runs all used the same set of 386 *.wav files, processed with
the following decoders:
1. wsprd, from WSPR-X (baseline decoder)
2. wspr4
3. wsprd, as built for W
On 28/06/2015 22:08, Steven Franke wrote:
> Thanks Bill,
Hi Steve,
>
> For what it’s worth, here a link to the VERBOSE build capture:
> https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt
>
> Here’s the CMakeCache.txt:
> https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt
OK
Hi Steve,
I use a script to make life easy. The working part of the script is this:
cmake -D CMAKE_BUILD_TYPE=$ctype -D CMAKE_INSTALL_PREFIX=~/G4KLA/Rev$1/$rel \
-D CMAKE_PREFIX_PATH="~/Qt5.4.0;/usr/local/hamlib" \
-D CMAKE_OSX_DEPLOYMENT_TARGET=10.9 \
-D CMAKE_C_COMPILER=clang -D CMAKE
Thanks Bill,
For what it’s worth, here a link to the VERBOSE build capture:
https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt
Here’s the CMakeCache.txt:
https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt
Steve k9an
> On Jun 28, 2015, at 4:01 PM, Bill Somerville wrote
On 28/06/2015 21:51, Bill Somerville wrote:
> On 28/06/2015 21:41, Steven Franke wrote:
>> John and Bill,
> Hi Steve,
>>> On Jun 28, 2015, at 2:24 PM, John Nelson wrote:
>>>
>>> Steve,
>>>
>>> Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing
>>> the improved decodes. Now
On 28/06/2015 21:41, Steven Franke wrote:
> John and Bill,
Hi Steve,
>
>> On Jun 28, 2015, at 2:24 PM, John Nelson wrote:
>>
>> Steve,
>>
>> Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing the
>> improved decodes. Now using .c2 files offline to compare wsprd and
>> wsp
John and Bill,
> On Jun 28, 2015, at 2:24 PM, John Nelson wrote:
>
> Steve,
>
> Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing the
> improved decodes. Now using .c2 files offline to compare wsprd and
> wsprd_exp. Good stuff….
Thanks, John. I’ve been meaning to as
Steve,
Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing the
improved decodes. Now using .c2 files offline to compare wsprd and wsprd_exp.
Good stuff
--- John g4KLA
--
Monitor 25 network dev
On 28/06/2015 16:40, Steven Franke wrote:
> Hi Bill,
Hi Steve,
> Thanks. I will study up on threading and how it might apply here. Steve.
It basically boils down to how you can break the work to be done into
independent chunks that can be processed in parallel.
The independence is key here, if
Hi Bill,
> On Jun 28, 2015, at 9:59 AM, Bill Somerville wrote:
>
> On 28/06/2015 15:46, Steven Franke wrote:
>
> Hi Steve,
>
> ...
>> It is dog-slow as it stands. But I’m sure that there are things that we can
>> do to speed it up significantly. This might be a good application for
>> openmpi
real signals and with simulations) that we are not going to decode
anything weaker than this.
>
> 73
> Mike W9MDB
Steve k9an
>
> -Original Message-
> From: Steven Franke [mailto:s.j.fra...@icloud.com]
> Sent: Sunday, June 28, 2015 9:47 AM
> To: WSJT software develo
It is interesting to see how far we’ve come. I just analyzed my favorite .wav
file with several versions of the decoder:
1. wspr0 from python-based wspr: 7 decodes
2. current wsprd from wsjt-x 1.6: 10 decodes
3. wsprd_exp with sub
nsuccessful decodes? Maybe there's a better value to be had there.
73
Mike W9MDB
-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com]
Sent: Sunday, June 28, 2015 9:47 AM
To: WSJT software development
Subject: Re: [wsjt-devel] wspr two-pass decoder status and .c2 file
On 28/06/2015 15:46, Steven Franke wrote:
Hi Steve,
...
> It is dog-slow as it stands. But I’m sure that there are things that we can
> do to speed it up significantly. This might be a good application for
> openmpi, no?
There is fairly major technical issue with this suggestion. On Mac we
do
Joe,
Frequency-sorting has now been committed.
It dawned on me that it is no longer really appropriate to insist that a
decoding candidate correspond to a local maximum in the average spectrum. I
tried this simple change:
$ diff wsprd_exp.c ~/Builds/wsjtx/lib/wsprd/wsprd_exp.c
848,850c848,849
<
Joe
> On Jun 27, 2015, at 8:18 PM, Steven Franke wrote:
>
> Joe,
>> On Jun 27, 2015, at 8:03 PM, Joe Taylor wrote:
>>
>> One more point, while I think of it.
>>
>> Since all WSPR-mode decodes are displayed at nearly the same time,
>> anyway, wouldn't it be a good idea to sort them in order of
Joe,
> Pending further work to correct the bug, at least, let's just do without
> timf2 and downsample from x0 into c0 -- as you have done.
I’ve just committed r5635 which removes the call to timf2. I’ve also confirmed
that the resulting .c2 files are clean.
Steve k9an
>
> -- Joe, K1JT
Joe,
> On Jun 27, 2015, at 8:03 PM, Joe Taylor wrote:
>
> One more point, while I think of it.
>
> Since all WSPR-mode decodes are displayed at nearly the same time,
> anyway, wouldn't it be a good idea to sort them in order of increasing
> frequency before writing them out? Having them in fr
One more point, while I think of it.
Since all WSPR-mode decodes are displayed at nearly the same time,
anyway, wouldn't it be a good idea to sort them in order of increasing
frequency before writing them out? Having them in frequency order makes
it much easier to compaere decodes with signals
Hi Steve,
On 6/27/2015 8:36 PM, Steven Franke wrote:
> I just captured a .c2 file after commenting out the call to timf2
> in wspr_downsample and replacing x1 with x0 in the call to mixlpf.
> The dropouts are gone. So it looks like the problem is in timf2.
Good work!
As far as I can remember: si
I put the call to timf2 back in and initialized nb to zero just before the nblk
loop. Dropouts are there.
> On Jun 27, 2015, at 7:36 PM, Steven Franke wrote:
>
> I just captured a .c2 file after commenting out the call to timf2 in
> wspr_downsample and replacing x1 with x0 in the call to mixlp
I just captured a .c2 file after commenting out the call to timf2 in
wspr_downsample and replacing x1 with x0 in the call to mixlpf. The dropouts
are gone. So it looks like the problem is in timf2.
Steve k9an
> On Jun 27, 2015, at 6:36 PM, Bill Somerville wrote:
>
> On 27/06/2015 23:58, Steven
Hi Bill, Steve, and all,
> That's some funky custom filtering going on there! One thing that looks
> wrong to me is that the variable 'nb' in wspr_downsample.f90 really
> ought to be initialized, I'd guess to '0'. Having said that a quick
> glance thought the code seems to imply that if 'nb' is ze
On 27/06/2015 23:58, Steven Franke wrote:
Hi Steve,
> Hi Joe -
> Yes, I am comfortable with making wsprd_exp the official wsprd. It has been
> working very well here. I had a couple of 16-decode cases again last night on
> 20 meters.
>
> Say, I just happened to be sitting here working on tracki
Hi Joe -
Yes, I am comfortable with making wsprd_exp the official wsprd. It has been
working very well here. I had a couple of 16-decode cases again last night on
20 meters.
Say, I just happened to be sitting here working on tracking down the signal
dropouts. When you get a chance, would you p
Hi Steve,
Sorry to be slow in getting back to you. After my post about wsprd_exp
I got involved in chasing a bug in the ISCAT decoder ...
On 6/26/2015 12:31 PM, Steven Franke wrote:
> I’m glad to see that you were able to confirm the improved performance
> of the two-pass decoder. I’m guessing
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 mak
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 th
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 Ti
Hi Steve,
I have compiled the two-pass decoder in Windows, and am running it now.
To make it work I had to change line 1062 so that it calls
subtract_signal() rather than subtract_signal2(). Haven't yet tried to
determine what's amiss in the fully coherent subtraction routine.
I will report b
Edson,
Yes, that’s it (the name is wsprd_exp.c, and the Makefile in that directory
will compile it on linux). I look forward to hearing about your tests.
Thanks,
Steve k9an
> On Jun 26, 2015, at 8:24 AM, Edson W. R. Pereira wrote:
>
>
> Hello Steve,
>
> Can you confirm that this is the right
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 togethe
Hi Greg,
> On Jun 25, 2015, at 11:10 PM, KI7MT 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 p
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?
I'll be adding this to JTSDK Nix to build and cp the wspr_exp decoder to
install/bin location on each turn.
I
51 matches
Mail list logo
