I'll submit these one at a time again...
Fixes 60M JT9 offset. Line on waterfall was switched to 0 but offset box was
not.
https://www.dropbox.com/s/3zvyv2idl89v6p0/60mJT9.patch?dl=1
Changes TIME_ON to use simpler and more reliable transmit
logichttps://www.dropbox.com/s/0r32o1yz8ph3q04/timeon
Hi Pino,
On 02/03/2017 22:33, Pino Zollo wrote:
write_block(): TX 7 bytes
fe fe 94 e0 1c 00 fd... <-- Wrong
command
read_string(): RX 7 characters
fe fe 94 e0 1c 00 fd... <-- wrong
command echoed
read_string
El 02/03/17 a las 19:11, wsjt-devel-requ...@lists.sourceforge.net escribió:
>
> I'm no expert, but is this command legit?
>
>
> fe fe 94 e0 1c 00 fd
>
>
> According to the manual
> http://www.icom.co.jp/world/support/download/manual/pdf/IC-7300_ENG_CD_0.pdf
> and this site http://w
On 02/03/2017 20:40, Black Michael wrote:
We've got 90dB of space to work with. Why would we NOT want the
dynamic range? I'm finding more decodes with the higher level...more
dynamic range means more accurate FFTs and such, doesn't it?
30dB RMS is 40+dB of peak value so I rounded up to 50dB an
On 02/03/2017 20:37, David Tiller wrote:
I'm no expert, but is this command legit?
fe fe 94 e0 1c 00 fd
Hi David,
yes it is. Many Icom CAT commands come in set and query versions, the
difference is that the query version leaves off the value. So
1c 00
is the query command, and in t
I'm no expert, but is this command legit?
fe fe 94 e0 1c 00 fd
According to the manual
http://www.icom.co.jp/world/support/download/manual/pdf/IC-7300_ENG_CD_0.pdf
and this site http://www.plicht.de/ekki/civ/civ-p42.html there's a byte missing
for the TX off command.
The whole exc
Peak meter is much clearer to set...would be similar to the RMS if one didn't
have the slider attached to it. But I've always set my data collections on
other systems for peak values to not clip.
We've got 90dB of space to work with. Why would we NOT want the dynamic range?
I'm finding more d
Peak meter-- what does change is what the dB is measuring...peak vs RMS...it's
about 12dB more or so for peak. The peak meter should quell all the question
about how to set audio...with whatever level we determine is best. I don't
know why we need more then 30dB head room above peak level...is
Mike --
More questions about your suggested changes to the noise-level metering
function and the associated widget.
Why should we prefer a peak-reading to average-power-reading meter?
The preferred level of 30 dB is for average, not peak. That's the
average noise level with no significant sig
Hi Bill,
I'm not certain as to how other developers manage their commits, but, I
typically run a separate checkout using svn:// when using SVN that
adds the developer username to the url. Before running separate
checkouts, I just committed from the src directory using my SF credentials.
Joe ma
On 02/03/2017 19:42, Pino Zollo wrote:
> rigctl(d): t 'currVFO' '' '' ''
> write_block(): TX 7 bytes
> fe fe 94 e0 1c 00 fd...
> read_string(): RX 7 characters
> fe fe 94 e0 1c 00 fd...
> read_string(): RX 8 cha
El 02/03/17 a las 16:36, wsjt-devel-requ...@lists.sourceforge.net escribió:
> #4 You still haven't sent us enough of the log to see what was going on
> what it stopped...
>
> I will do it tonight
---
write_block(): TX 7 bytes
fe fe 94 e0 1a 03 fd.
Mike --
> Peak signal meter shows when clipping occurs. Based on my testing
> recommending 50-60dB on peak meter...subject to change.
Unless your patch changes what "0 dB" means, the recommended level for
background noise --no signals present -- should remain 30 dB.
Why do you recommend 20-30
El 02/03/17 a las 15:26, wsjt-devel-requ...@lists.sourceforge.net escribió:
> #4 You still haven't sent us enough of the log to see what was going on
> what it stopped...
>
> I will do it tonight
>
>> I suspect a computer problem on your part right now.
> maybethe behavior is the same on th
Hi Bill
Sorry for delay.
Here's what svn info gives here:
(JTSDK-QT 5.2 ) C:\JTSDK\src\wsjtx)svn info
Path: .
Working Copy Root Path: C:\JTSDK\src\wsjtx
URL: http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
Relative URL: ^/branches/wsjtx
Repository Root: http://svn.code.sf.net
On 02/03/2017 18:04, Greg Beam wrote:
> If users want to test svn:// v.s.http://, they can edit the top of:
Hi Greg,
thanks for filling the details for the JTSDK Subversion URLs. Since
SourceForge no longer advertise Subversion access via HTTP I would
suggest we either use an HTTPS or SVN schem
Since I'm continuing development this is my cumulative patch now.
New peak signal meter to replace RMS meter. RMS value is now in status bar.
Tooltip updated.Peak signal meter shows when clipping occurs. Based on my
testing recommending 50-60dB on peak meter...subject to change.Slider bar no
Hi Bill,
I can't recall exactly what the reason was, but, in the past there were
various checkout issues from SF when using the svn:// prefix, which is
why I opted for using the http:// prefix.
For what it's worth, since SF came back up after their last major down
period, I've not had any trou
El 02/03/17 a las 11:21, wsjt-devel-requ...@lists.sourceforge.net escribió:
> #1 Try reducing the poll interval on WSJT-X in File/Settings/Radio in the
> upper right corner.
Tried polling from 1 to 2 secondsno change.
#2 What OS are you on?
Linux Mint 17.3
#3 Have you tried uninstalling
On 02/03/2017 16:06, Dan Malcolm wrote:
Seems the offending module is: Faulting module path:
C:\JTSDK\msys\bin\msys-perl5_8.dll.
The problem seems to be inability to find a file
It appears I am using Perl5_8. If memory serves, there was a
discussion about which Perl version should be used.
Hi Patrick,
>> With these conditions, the CPU load is around 40% so I have the feeling that
>> I have plenty. But, I wanted to try George's recommandations, so I reduced
>> the FTol to 100Hz.
>> Now, the CPU load dropped to 32%, but the graphics fills up to 30s.
> Reducing the decoding depth onl
Bill,
Seems the offending module is: Faulting module path:
C:\JTSDK\msys\bin\msys-perl5_8.dll.
The problem seems to be inability to find a file
It appears I am using Perl5_8. If memory serves, there was a discussion
about which Perl version should be used. Could 5.8 be the problem?
__
On 02/03/2017 14:55, Dan Malcolm wrote:
Just tried to recompile Hamlib3 using JTSDK-MSYS and this is the result:
CDPATH="${ZSH_VERSION+.}:" && cd ../src && /bin/sh
/c/JTSDK/src/hamlib3/src/build-aux/missing --run aclocal-1.12 -I
macros --install
0 [main] perl 18760 fork_copy: linked d
Just tried to recompile Hamlib3 using JTSDK-MSYS and this is the result:
CDPATH="${ZSH_VERSION+.}:" && cd ../src && /bin/sh
/c/JTSDK/src/hamlib3/src/build-aux/missing --run aclocal-1.12 -I macros
--install
0 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E7
Hi Patrick,
some comments in line below.
On 02/03/2017 14:24, f1...@free.fr wrote:
> The following is only to help the team, so do not see any negative idea in it.
>
> I am using an Intel Core 2 Duo CPU (E8400) at 3GHz, this is not the latest
> I7, but not too old... Not an AMD anyway.
The Core
Hi All,
First, I would like to thank Bill and George for their answers.
The following is only to help the team, so do not see any negative idea in it.
I am using an Intel Core 2 Duo CPU (E8400) at 3GHz, this is not the latest I7,
but not too old... Not an AMD anyway.
FYI my test conditions are
#1 Try reducing the poll interval on WSJT-X in File/Settings/Radio in the upper
right corner.#2 What OS are you on?#3 Have you tried uninstalling USB drivers
and reinstalling?#4 You still haven't sent us enough of the log to see what was
going on what it stopped...
I suspect a computer problem o
On 02/03/2017 13:11, Wolfgang wrote:
> (JTSDK-QT 5.5 ) C:\JTSDK\src\wsjtx)svn info
> Path: .
> Working Copy Root Path: C:\JTSDK\src\wsjtx
> URL:http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
> Relative URL: ^/branches/wsjtx
> Repository Root:http://svn.code.sf.net/p/wsjt/wsjt
> Repository UUID:
Hello Bill,
(JTSDK-QT 5.5 ) C:\JTSDK\src\wsjtx)svn info
Path: .
Working Copy Root Path: C:\JTSDK\src\wsjtx
URL: http://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx
Relative URL: ^/branches/wsjtx
Repository Root: http://svn.code.sf.net/p/wsjt/wsjt
Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79
El 02/03/17 a las 05:28, wsjt-devel-requ...@lists.sourceforge.net escribió:
> Do you have a dummy load you can test with?One question is does it fail only
> when you transmit and on certain bands?
> de Mike W9MDB
Hi Mike
The problem shows also in RX only...
Any how I did wound the USB cable
On 02/03/2017 08:27, Charles Suckling wrote:
Wolfgang is not alone in having these problems.
My Vista machine has been having trouble for some time, with update
from svn hanging up halfway through, and then on trying again
getting the ‘Sourceforge may be down’ error.
Today I was able to
Hi Bill, Wolfgand and Mike
Wolfgang is not alone in having these problems.
My Vista machine has been having trouble for some time, with update from svn
hanging up halfway through, and then on trying again getting the
'Sourceforge may be down' error.
Today I was able to do a build succ
32 matches
Mail list logo
