a facility to call a user_hardware script before each 2-minute
window should be no problem: earlier versions of WSPR do that, and it
works well.
-- Joe, K1JT
On 5/13/2015 10:45 PM, Steven Franke wrote:
Hi Joe,
I tried the latest wsjt-x_exp this evening on Ubuntu 14.04
Hi Joe,
I tried the latest wsjt-x_exp this evening on Ubuntu 14.04 and it worked great!
My regular hopping setup uses gnuradio to read the TS-480's audio from a sound
card and write it to a .wav file. I send xmlrpc commands to stop and start
recording. I was surprised to find that I could start
imagine that such a procedure might increase the number of decodes
in a particular 2-minute interval by a few, when the band is crowded.
-- Joe
On 5/17/2015 12:26 PM, Steven Franke wrote:
For my purposes, I like the idea of using automatically calculated
sunrise/sunset as the pre-defined
Bill,
Give it a try and see if you can map your new code into the new class.
Obviously ask here or directly if you need any help understanding any of
my code or for help with how it might best be extended.
I just checked in WsprTxScheduler.cpp and have it patched in to replace the
schedule
Hi Bill,
On Jun 5, 2015, at 8:33 AM, Bill Somerville g4...@classdesign.com wrote:
The point of call of Steve's new Tx scheduler needs to be moved into the
WSPRBandHopping::next_hop() function so that the logic to decide when to
tune and to block transmission on Rx only bands can be applied.
Bill,
It is only a small change. If you move the call of next_tx_state() from
MainWindow::bandHopping() into WSPRBandHopping::next_hop() just after
the call to FC_hopping(). The member variable m_-tx_percent_ tracks the
current value of the UI Tx Pct spin box.
Something like:
On Jun 5, 2015, at 11:05 AM, Bill Somerville g4...@classdesign.com wrote:
On 05/06/2015 16:41, Steven Franke wrote:
Bill,
Hi Steve,
It is only a small change. If you move the call of next_tx_state() from
MainWindow::bandHopping() into WSPRBandHopping::next_hop() just after
the call
I note that there appears to be a time offset somewhere in the WSPR
round trip, I see decodes always with a -1.0 DT when both ends are
running with the same wall clock time.
I encountered this when I was writing the decoder. Most programs start TX at 1
second in, whereas the decoders define
:37 AM, Joe Taylor j...@princeton.edu wrote:
Yes. Probably we should add 1 s to the DT reported by wsprd.
-- Joe
On 6/5/2015 8:34 PM, Steven Franke wrote:
I note that there appears to be a time offset somewhere in the WSPR
round trip, I see decodes always with a -1.0 DT when both
Bill,
I really like what you’ve done with the Band Hopping scheduler!
Before checking any boxes in the active-band scheduler I checked to see if it
would automatically transmit on a single-band (Band Hopping unchecked) that was
not active in the scheduler. No problem! I also noticed that there
Bill,
While you are on a roll, I’ll just mention another wish-list item. We
already have a Tx Next button — it would be nice to have a Next Band
selector that would override the band-picking algorithm. This could just be
a box with up-down arrow to cycle through the bands… This could be
Bill,
Single band WSPR and band hopping WSPR should now be doing what I think
we have agreed.
Yes, single band operation now seems to work. Thanks!
Steve k9an
--
___
Joe, I suppose for those who want to use a narrow (e.g. 30 minutes or less)
grayline duration to try to catch a true grayline opening (when the entire path
is aligned along the sunrise/sunset terminator), then it should probably be
D-region sunset. In my case, at 40deg N, I am using 120 minute
Bill,
I noticed that callsigns retrieved from the hashtable are not being displayed
in the spots window. The callsign is visible in ALL_WSPR.TXT, with the
customary callsign notation, however the callsign field is blank in the spots
window.
Steve k9an
Bill,
I think that what you describe is consistent with the following:
Suppose that the the Tx Pct is set to 25%, some number of coordinated bands are
active, and no bands are selected as Rx only. Then we will be transmitting 25%
of the time and we also transmit on about 25% of the visits to
wrong with the generation
of the hashcode for the 2nd message to be sent. Before I get to deep
into this perhaps one of you, who knows the message generation code, can
say quickly why this is failing.
73
Bill
G4WJS.
On 10/06/2015 13:56, Bill Somerville wrote:
On 10/06/2015 13:19, Steven
Hi Bill,
There was some discussion about picking any random band from the users
configured bands when the scheduled band is not configured. This is
potentially tricky because the user specified tune up is only
specified for the 10 standard hopping bands. It would perhaps be better
to
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
Hi Bill,
After your recent C/Fortran fixes to nhash.c, I can no longer compile because
size_t is not defined. This change got it to compile:
Index: lib/wsprd/nhash.h
===
--- lib/wsprd/nhash.h (revision 5576)
+++ lib/wsprd/nhash.h
On Jun 10, 2015, at 3:02 PM, Bill Somerville g4...@classdesign.com wrote:
On 10/06/2015 20:57, Steven Franke wrote:
Hi Bill,
Hi Steve,
After your recent C/Fortran fixes to nhash.c, I can no longer compile
because size_t is not defined. This change got it to compile:
Index: lib/wsprd
r5603
I am not seeing the Astro Data crash (Ubuntu 14.04).
On a separate item, it looks like the new WSPR_history.txt is reporting the
number of spots on the wrong band (it is reporting the band as the _next_ band,
not the “just decoded” band). You can see this by comparing the entries for
Hi Mike and Bill,
On Jun 13, 2015, at 12:33 PM, Bill Somerville g4...@classdesign.com wrote:
On 13/06/2015 18:25, Michael Black wrote:
Hi Mike,
You can adjust the left edge of the waterfall in the WSPR instance That's
the Start XXX Hz entry. Just set it to 700 Hz. Then you can adjust
Joe, Eric, Bill,
I can reproduce similar behavior as follows. I am using a TS-480.
Let 0:00 (m:ss) be the beginning of a cycle.
Start the program (i.e. issue the command ./wsjtx) some time after 1:00.
Some time between 1:00 and 1:30, press Tune, then press Tune again.
Some time after 1:30, do Tx
Hi Bill,
On Jun 10, 2015, at 9:53 AM, Bill Somerville g4...@classdesign.com wrote:
On 10/06/2015 13:19, Steven Franke wrote:
Bill,
Hi Steve,
I noticed that callsigns retrieved from the hashtable are not being
displayed in the spots window. The callsign is visible in ALL_WSPR.TXT
This is a report of early results from my first attempt at implementing 2-pass
decoding.
The idea was suggested by Joe a few weeks ago. The motivation is to try to
squeeze out a few more decodes on crowded bands where there are a number of
otherwise decodable signals being covered up by
I attach a .diff file that fixes the “GrayLineDuration not remembered on
startup” problem.
Steve k9an
k9an_150528_patch.diff
Description: Binary data
On May 27, 2015, at 4:25 PM, Steven Franke s.j.fra...@icloud.com wrote:
I have been running an instance nonstop for several days. I
What are you using for the grayline bands and duration?
Joe -
Right now I have it set up as follows:
Sunrise: 80 40 30 20 17 15 12 10
Day: 30 20 17 15 12 10
Sunset: 40 30 20 17 15 10
Night: 160 80 40 30 20
Gray Time: 120
On a couple of occasions I’ve felt like the grayline duration was not
Joe,
FYI, r5482 is an attempt to iteratively massage the tx(10,6) table so that it
has maximum number of consecutive transmissions of 2 and also satisfies
“minimum number of transmissions per 2 hour period constraint…
Steve k9an
On May 31, 2015, at 8:29 AM, Joe Taylor j...@princeton.edu
.
On 05/31/2015 04:25 PM, Steven Franke wrote:
What are you using for the grayline bands and duration?
Joe -
Right now I have it set up as follows:
Sunrise: 80 40 30 20 17 15 12 10
Day: 30 20 17 15 12 10
Sunset: 40 30 20 17 15 10
Night: 160 80 40 30 20
Gray Time: 120
On a couple
As for the other case that Eric mentioned (band hopping _not_ selected, band
set to 630m, TX enabled). For this case, my proposal was to still use the
same 10x6 tx table to control whether or not to TX. In fact, I tested this
here over the weekend using 40m (band hopping not selected, band
. Probably it has something to
do with the changes Bill made to the way frequency/mode combinations are
stored and used, and my code around line 4164 in mainwindow.cpp.
-- Joe
On 5/29/2015 8:04 PM, Steven Franke wrote:
Bill, Joe and all,
Running r5467 which incorporates Bill’s recent
Bill, Joe and all,
Running r5467 which incorporates Bill’s recent repairs to bandhopping.
Hopping seems to be working, but I have seen 4 successive transmissions already
after running for only an hour or so. FWIW, I noticed that the line of code
that should prevent successive transmissions
I can confirm that it looks like 80m was “skipped” at 0302, even though it was
in my “Night” list. On the other hand, 160m and the other bands do seem to
“work”.
Steve k9an
On May 30, 2015, at 8:46 PM, Josh Rovero josh.rov...@gmail.com wrote:
I am noticing that the lowest band, 80m, that I
Joe,
I think that it’d be very helpful to have more input to help guide the WSPR
efforts.
For the record, here is a situation that I’ve encountered 3 times now that
should be addressed eventually:
If EnableTX is started very late in the 2-minute window _and_ if the window
happened to be a
Joe and wspr in wsjtx testers:
I’ve significantly improved the efficiency of the sync-search in the current
version (r5668) of wsprd_exp.c. On a large (1953 files) batch of files
representing all bands and the entire diurnal cycle the r5668 wsprd and
wsprd_exp compare as follows:
wsprd:
5083
Hi Joe,
On Jul 3, 2015, at 10:18 AM, Joe Taylor j...@princeton.edu wrote:
Hi Steve,
On 7/3/2015 9:29 AM, Steven Franke wrote:
Joe and wspr in wsjtx testers:
I’ve significantly improved the efficiency of the sync-search in the current
version (r5668) of wsprd_exp.c. On a large (1953
Claude,
On Jul 2, 2015, at 9:22 AM, Bill Somerville g4...@classdesign.com wrote:
On 02/07/2015 11:33, Claude Frantz wrote:
What is the format of the *.c2 files ? How can they be converted to a
more common format, e.g. using a tool like sox ?
AFAIK it is an internally defined format. The
Joe,
On Jul 3, 2015, at 10:43 AM, Joe Taylor j...@princeton.edu wrote:
Hi Steve,
Hmmm. That’s interesting and surprising. I tested it separately on 40m and
20m files and saw 35% and 17% reduction in execution time, respectively. So
when I got 25% reduction for the large batch containing
with subtraction and two-passes:16 decodes
4. no-peak-requirement modification to wsprd_exp: 19 decodes
Steve k9an
On Jun 28, 2015, at 9:46 AM, Steven Franke s.j.fra...@icloud.com wrote:
Joe,
Frequency-sorting has now been committed.
It dawned on me that it is no longer really
Hi Bill,
On Jun 28, 2015, at 9:59 AM, Bill Somerville g4...@classdesign.com 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
...@classdesign.com 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 j...@rmnjmn.demon.co.uk wrote:
Steve,
Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing
Hi Bill,
On Jul 1, 2015, at 8:39 AM, Bill Somerville g4...@classdesign.com 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
Bill,
On Jul 2, 2015, at 1:46 PM, Bill Somerville g4...@classdesign.com 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
Hi Bill,
Thanks for the comments!
IMHO any setting that increases the number of bad decodes is not worth
the time saved unless that time is in danger of being longer than the
available time before the next decode cycle. I say this because
unfiltered bad decodes cause erroneous outliers,
Joe -
I have it running here now. I’m having a couple of problems:
1. I am not seeing the WSPR frequencies in the Frequencies tab or in the
Dropdown menu on the GUI. Do I need to enter these manually somewhere? Perhaps
this will explain the next two issues:
2. I can control the radio (TS-480)
of the manual pull-down list.
-- Joe
On 5/21/2015 7:44 PM, Steven Franke wrote:
Thanks Bill!
After deleting the “frequencies” line from the .INI file I now see
the WSPR frequencies (as well as the WSJT frequencies). Now, band
hopping appears to be working. It still looks like the user_hardware
I should add that there is no frequency offset on received signals. Signals
received simultaneously on the WSJT-X/TS-480 setup and on a separate receiver
using my own software are always within 0.1 Hz of each other.
On May 21, 2015, at 10:40 PM, Steven Franke s.j.fra...@icloud.com wrote:
I
% 10,1% 9,0% 2,2%
2,2% 3,4% 0,0% 0,0% 0,0% 2,2% 2,2% 0,0% 0,0% 1,1% 0,0% 0,0%
2,2% 100,0%
Apologies in advance , not sure if table will be very readable !!!.
Best 73
Jean Louis
-Message d'origine-
De : Steven Franke [mailto:s.j.fra
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Hi Joe,
On Jun 29, 2015, at 11:53 AM, Joe Taylor j...@princeton.edu 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
Bill,
On Jun 29, 2015, at 4:43 PM, Bill Somerville g4...@classdesign.com wrote:
On 29/06/2015 22:30, Steven Franke wrote:
Bill,
Hi Steve,
On Jun 29, 2015, at 4:26 PM, Bill Somerville g4...@classdesign.com wrote:
On 29/06/2015 22:17, Steven Franke wrote:
Bill,
On Jun 29, 2015, at 3:57
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
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
set of WSPR .wav files that your
using to compare with? Would be nice to be able to use a standard set
for testing.
73's
Greg, KI7MT
On 07/29/2015 07:36 PM, Steven Franke wrote:
Greg -
The windows Makefile has not been updated for the stack decoder. I’ve only
tested it on linux
Hi Greg and Joe,
As Joe said, the stack decoder is only in wsprd_exp and it requires a
command-line argument (-J) to activate it, as the default algorithm in
wsprd_exp is the Fano algorithm.
The tests conducted by me and Joe show that my implementation of Jelinek’s
stack-bucket algorithm
On Aug 2, 2015, at 12:49 PM, Joe Taylor j...@princeton.edu wrote:
Hi Steve, Edson, and all,
I had forgotten that wsprd_exp is currently using a different sync
algorithm. Thanks for the explanations. I, too, am happy with the way
the modified fano.c is behaving. By all means, go
Bill,
On Jul 23, 2015, at 5:16 AM, Bill Somerville g4...@classdesign.com wrote:
On 23/07/2015 03:13, Steven Franke wrote:
Hi all,
Hi Steve,
While playing with an alternative to the Fano decoder over here I discovered
that using -O3 -ffast-math significantly decreases execution time
It appears that we are back in business on SourceForge.
Yep!
I just committed an update to the experimental wspr decoder (wsprd_exp) that
can use the tried-and-true Fano decoder or a new experimental “stack” decoder.
My initial experiments indicate that the stack decoder as currently
Hi all,
While playing with an alternative to the Fano decoder over here I discovered
that using -O3 -ffast-math significantly decreases execution time of the
decoder on my linux and OS X platforms. Near as I can tell, cmake is currently
using -O2 for Debug and -O3 for Release versions. I need
Hi Joe and all,
I’ve done some preliminary work on signal subtraction for jt65. The routine
subtract65 is intended to be called in jt65a within the “icand” loop. I have
commented out the call for now - but I have done enough tests to convince
myself that the math is basically correct and that
Hi Joe,
> In the WSJT slow modes PTT is nominally asserted at t=0 s and audio
> starts at t=1 s in a UTC minute. SimJT generates wav files in which the
> noise starts at t=0 and signal starts at t=1. I guess this is
> essentially what you observed?
Perhaps this is what I’m seeing. I
Hi George,
At the moment, the two-pass decoding scheme is implemented only in the
command-line test program jt65. The differences that you were seeing between
v1.5 and v1.6.1 would be due to different synching schemes and also slight
differences between kvasd and sfrsd2 performance.
73 Steve
Hi Joe and all -
I’m glad that you’ve incorporated the two-pass decoding into 1.6.1 Joe!
I’ve done a couple of tests. First, a summary of my own results on my batch of
333 hf files. Cases 6 and 7 are from the latest 1.6.1 with two-pass decoding:
1. v1.5 with kvasd: 3128 (2 bad)
2. v1.5 with
Hi Joe and all,
Thanks Joe for implementing the fft-based convolution. It makes a big
difference in execution time.
It might save even more time if we calculated the averaged complex amplitude
at, say, 1/100’th or even 1/1000’th as many points enabling us to use a much
smaller fft for the
Joe and all:
I can’t resist posting this example that shows what two-pass decoding can do on
a crowded band. The first pass yields 12 decodes (as does the current 1.6.1
r6014). The second pass, after subtraction, yields 8 more decodes for a total
of 20 from a single wav file and within about a
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
Igor,
This is likely due to the very strong burst of interference at about 21 s into
the file. It looks like a chirpsounder swept through the band at that time.
This interference is about 40 dB larger than the noise floor. The 1-bit
correlation will be relatively immune to this spike, whereas
Hi Bill and John,
I’m using qt 5.4.2. Perhaps that explains why I see this and John doesn’t?
Steve k9an
> On Nov 3, 2015, at 5:38 AM, Bill Somerville <g4...@classdesign.com> wrote:
>
> On 03/11/2015 02:23, Steven Franke wrote:
>> This is to document a minor aes
Hi Igor, Sandro and all,
I’m at a loss as to why or how the same revision would give such different
decoding results on different machines. So far, I am not able to reproduce that
here.
In r6058 I’ve committed another change that is designed to reduce the number of
false syncs. I implemented
Wait. What? Very cool example, but I’m confused.
When the user changes messages in mid-stream, my assumption was that the
program would jump to the beginning of the new message symbol-stream, i.e.
start at the beginning of a new message. But then the second message would
decode with a big dt,
a bit.
Enjoy the conference!
Steve k9an
> On Nov 2, 2015, at 3:10 PM, Joe Taylor <j...@princeton.edu> wrote:
>
> Hi Steve,
>
> On 11/2/2015 3:59 PM, Steven Franke wrote:
>> Wait. What? Very cool example, but I’m confused.
>>
>> When the user change
Hi Joe and all,
I’ve just committed a batch of modified routines associated with my attempts to
improve the low-SNR performance of wsjt-x.
I did a number of experiments aimed at identifying why wsjt-x was not
performing as well as wsjt on our low-snr test files. I used the jt65 test
program
Joe -
For reference, here is the bash script that I used to convert my JTSim files to
16-bits at 12kS/s. You’d have to change the directory name, of course.
Steve
#!/bin/bash
for i in $( cd ../JT65-24db; ls A*.WAV); do
echo $i;
sox --ignore-length ../JT65-24db/$i -r 12000 -b 16 ./$i;
done
nfb=3000
>
> If you try to run the -24dB data using the hf settings, it becomes
> intolerably slow.
> Steve k9an
>
>
>> On Oct 31, 2015, at 3:47 PM, Steven Franke <s.j.fra...@icloud.com> wrote:
>>
>> Joe -
>> For reference, here is the bash scri
This is to document a minor aesthetic issue. On OS X, but not on linux, the
Monitor button is smaller than the other buttons when it is off (not Green):
Steve k9an--
___
Joe,
> I conclude that for these files the candidate selection is OK
> (preferably with a somewhat higher threshold for ntest), but sfrsd is
> not decoding as many as it "should". I suspect that for marginal
> signals either different metrics or different values in the probability
> matrix
I have attached the sfrsd2.c that I used to produce the results reported below.
Steve k9an
sfrsd2.c
Description: Binary data
> On Oct 15, 2015, at 9:03 PM, Steven Franke <s.j.fra...@icloud.com> wrote:
>
> Joe,
> Reporting on results of this evening’s tests on -24db gaussian
me to
drop the same sfrsd2.c into whatever version you used to generate the
s3_1000.bin file. Do you remember what version that was?
Steve k9an
> On Oct 15, 2015, at 6:32 PM, Steven Franke <s.j.fra...@icloud.com> wrote:
>
> Joe,
>
>> I conclude that for these files th
Joe -
> Do you think we may need to use
> different erasure probabilities for HF and EME-like conditions?
Sorry, I didn’t answer this question. Working in between appts and meetings
here.
My aim is to come up with erasure probabilities that will work reasonably well
for both situations and,
d you please give me details on exactly how you built rsdtest? In
> what directory, in our SVN tree? With what Makefile?
>
> -- Joe
>
>
> On 10/15/2015 10:03 PM, Steven Franke wrote:
>> Joe,
>> Reporting on results of this evening’s tests on -24db gaussian
lsar/K1JT/decodes_vs_ntrials3.pdf
> suggests that this is not the issue. Do you think we may need to use
> different erasure probabilities for HF and EME-like conditions?
>
> -- Joe
>
> On 10/11/2015 5:11 PM, Steven Franke wrote:
>> Hi Joe and all,
>>
>> This mes
Hi Neil,
I have committed an update which may squelch the error that you observed.
But…. be advised that the 1.6.1 branch is not in a stable state at this time.
We are experimenting with a completely new scheme for detecting and selecting
signals that are candidates for submission to the jt65
Hi Joe and all,
This message summarizes my recent work on jt65 decoding in 1.6.1.
I’ve added 3 new entries to the table summarizing JT-65a decoding results on my
batch of 333 20m .wav files.
Program Good Bad SoftDecoder
> On Oct 11, 2015, at 4:11 PM, Steven Franke <s.j.fra...@icloud.com> wrote:
>
> Hi Joe and all,
>
> This message summarizes my recent work on jt65 decoding in 1.6.1.
>
> I’ve added 3 new entries to the table summarizing JT-65a decoding results on
>
implementing it…)
-- Joe
On 7/7/2015 3:58 PM, Steven Franke wrote:
Joe and Jean Louis,
I don’t see what’s wrong with the distribution that Jean Louis measured. In
fact, I’m happy with it!
It looks like a geometric distribution, which is exactly what you get for
the run-length
Bill,
I just updated back to r5700 and the problem that I described yesterday
occurred after the first transmission. I captured the following from the trace
file:
Wed Jul 8 18:35:53 2015
GMT(/home/radio/Builds/wsjtx/HamlibTransceiver.cpp:41)Critical: Hamlib:
kenwood_transaction: Unknown
Mike and Bill,
On Jul 8, 2015, at 6:58 PM, Bill Somerville g4...@classdesign.com wrote:
On 08/07/2015 19:43, Steven Franke wrote:
Bill,
Hi Steve,
I just updated back to r5700 and the problem that I described yesterday
occurred after the first transmission. I captured the following from
this change, but the problem occurred after the first transmission.
I will respond to Bill’s latest separately.
Steve k9an
73
Mike W9MDB
-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com]
Sent: Wednesday, July 08, 2015 4:04 PM
To: WSJT software development
Subject
Mike,I ran your change on top of Bill’s patch. See the attached diff file for the difference between r5700 and my current dirty version.It did not solve the problem.The trace results are here:https://dl.dropboxusercontent.com/u/33211132/WSJT-X_trace_5.logThe trace starts when I started the
Bill,
On Jul 11, 2015, at 2:40 PM, Bill Somerville g4...@classdesign.com wrote:
On 11/07/2015 20:35, Steven Franke wrote:
Hi Steve,
I’m running the latest wsjt-x 1.6 on a mac, and I have set
WSJT_QDEBUG_TO_FILE and WSJT_QDEBUG_IN_RELEASE, but I cannot find
WSJT-X_trace.log. It appears
In r5715 I have comitted changes WsprTxScheduler.cpp which address the
following issues:
- force first slot in the 2-hour tx schedule to always be a receive slot to
eliminate the possibility of a double tx when the last (visited) slot of the
old table and first slot of the new table are both
Hi Bill and Mike,
On Jul 11, 2015, at 5:55 PM, Bill Somerville g4...@classdesign.com wrote:
On 08/07/2015 02:13, Steven Franke wrote:
Bill,
Hi Steve,
In the past couple of hours since updating to r5700 I have had four rig
control error events after many weeks of flawless operation
with a bone here...
Mike W9MDB
-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com]
Sent: Saturday, July 11, 2015 2:50 PM
To: WSJT software development
Subject: Re: [wsjt-devel] trace file location on mac
Bill,
On Jul 11, 2015, at 2:40 PM, Bill Somerville g4
I should also note that although r5685 works fine with the TS480, it throws a
sequence of errors when the program is terminated with “Quit”. The latest
revision (5700) does this too.
On Jul 11, 2015, at 3:38 PM, Steven Franke s.j.fra...@icloud.com wrote:
Mike,
Here:
https
-
De : Steven Franke [mailto:s.j.fra...@icloud.com]
Envoyé : mardi 7 juillet 2015 02:17
À : WSJT software development
Objet : Re: [wsjt-devel] WSPR-2 - Scheduler in no band hopping mode
Jean Louis, Joe -
Does this happen only if you have never touched TX Pct since starting the
program
r5685 and r5700. The former (5685) works and the latest (5700)
doesn’t work. These were changes to the logic surrounding the decision to
transmit.
Steve k9an
-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com]
Sent: Wednesday, July 08, 2015 5:10 PM
To: WSJT
Victor,
On Jul 8, 2015, at 5:29 PM, Victor Batchelor hs0...@yahoo.com wrote:
Hi Guys,
I am running r5690 with TX% set to 18. # times in the last 10 hours it has
transmitted twice in succession.
While testing this afternoon I saw this once, too and I realized that it is
possible for
.
Let’s stand down on this for now. No one else is reporting a problem, and I’m
able to run using VOX. I suggest that we see if it affects anyone else before
we spend more time on it.
Steve k9an
-Original Message-
From: Steven Franke [mailto:s.j.fra...@icloud.com]
Sent: Wednesday, July
Hi Bill,
On Jul 8, 2015, at 11:09 PM, Bill Somerville g4...@classdesign.com wrote:
On 08/07/2015 23:10, Steven Franke wrote:
Hi Steve,
On Jul 8, 2015, at 4:42 PM, Bill Somerville g4...@classdesign.com wrote:
On 08/07/2015 22:03, Steven Franke wrote:
Mike and Bill,
Hi Steve,
I deleted
On Jul 9, 2015, at 7:04 AM, Bill Somerville g4...@classdesign.com wrote:
On 09/07/2015 05:16, Michael Black wrote:
Hi Mike,
I noticed in that log that PTT=true comes before the frequency change and
PTT=false afterwards. Was probably in the prior log too just didn't notice
it. I'm
1 - 100 of 376 matches
Mail list logo
