Hi Sandro,
I'm not sure why your having that situation. Using the file is not best
way to get the revision, if anything changes, it gets busted. Maybe
there is a DOS/*Nix translation happening or something, other than that,
I'm not sure why the extra space is in there.
73's
Greg, KI7MT
On 9/6/2
On 06/09/2014 00:53, Michael Black wrote:
Hi Mike,
OK...current run with rev 4255 but I am running with 10 second socket
timeout modification.
I ran WSJT-X for a while.
I then started HRD Logbook at 13:10.Port 56169 is WSJT-X and Port
56193 is HRD Logbook.
Takes a few seconds for Logb
KI7MT writes:
>
> Hi Sandro,
>
> Couple questions.
>
> 1. Are you trying to build ( WSPR ) or ( WSJT )?
> 2. Have you updated JTSDK-PY to the latest versions?
> 3. Have you updated wsjt.py or wspr.py to the latest SVN as there were
> some changes.
>
> Here's my output:
> Open C:\JTSDK=PY\jtsd
OK.current run with rev 4255 but I am running with 10 second socket timeout
modification.
I ran WSJT-X for a while.
I then started HRD Logbook at 13:10.Port 56169 is WSJT-X and Port 56193
is HRD Logbook.
Takes a few seconds for Logbook to get going..
13:10:07.064095 WSJT-X does "get f
Not a crash (yet). I removed the build tree. Did a "wsjtx build rconfig",
edited the file, then "wsjtx build wsjtx".
That cmake rebuild worked though.
Now on to figuring out what's going on with HRD.
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday,
On 05/09/2014 23:47, Michael Black wrote:
Hi Mike,
> I turned on
> //Debugging option that turns on full Hamlib internal diagnostics.
> WSJT_HAMLIB_TRACE:BOOL=ON
>
> //Leave Qt debugging statements in Release configuration.
> WSJT_QDEBUG_IN_RELEASE:BOOL=ON
>
> //Redirect Qt debuging messages to a t
I turned on
//Debugging option that turns on full Hamlib internal diagnostics.
WSJT_HAMLIB_TRACE:BOOL=ON
//Leave Qt debugging statements in Release configuration.
WSJT_QDEBUG_IN_RELEASE:BOOL=ON
//Redirect Qt debuging messages to a trace file.
WSJT_QDEBUG_TO_FILE:BOOL=ON
//Debugging option that t
A very nice-to-have feature would be to have a % spinner for the Tune
button. I'd put it right next to it.
For example I just keep my radio at a fixed power level and use software to
adjust power.
But that level is far too high for tuning. So a 0-100% spinner to set the
power level for tuning w
On 05/09/2014 23:04, Michael Black wrote:
Hi Mike,
How do we set compile flags now?
WSJT_TRACE_CAT and WSJT_QDEBUG_TO_FILE for example?
Now? This has not changed.
Either use:
cmake-gui
or directly edit the CMakeCache.txt in the build tree.
Then rebuild:
cmake --build --target install -
How do we set compile flags now?
WSJT_TRACE_CAT and WSJT_QDEBUG_TO_FILE for example?
Mike W9MDB
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/___
Hi Sandro,
Couple questions.
1. Are you trying to build ( WSPR ) or ( WSJT )?
2. Have you updated JTSDK-PY to the latest versions?
3. Have you updated wsjt.py or wspr.py to the latest SVN as there were
some changes.
Here's my output:
Open C:\JTSDK=PY\jtsdk-pyenv.bat
--
cd src\trunk
C:\J
Hi All,
I start to work with SDK to try some experiments.
Working with JTSDK-PY on windows 7 I notice that
command: build wsjt
After build files are copied to
C:\JTSDK-PY\wspr\wspr-r$
If in jtsdk-python.bat I change line 213 from:
grep "$Revision:" %APP_NAME%.py |awk "{print $12}" > r.txt
to:
On 05/09/2014 18:36, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> When you get a chance, could you modify CMakeLists.txt so that the
> executables jt65code[.exe] and jt9code[.exe] are once again built as
> part of the WSJT-X build procedure.
Done.
>
> These utility programs are described in the User
Hi Bill,
> No problem, what about jt9sim ?
No need to include jt9sim. It was (and might still be) useful to me for
optimizing the JT9 decoder, but has little use for anyone else.
-- Joe
--
Slashdot TV.
Vide
On 05/09/2014 18:36, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> When you get a chance, could you modify CMakeLists.txt so that the
> executables jt65code[.exe] and jt9code[.exe] are once again built as
> part of the WSJT-X build procedure.
>
> These utility programs are described in the User Guide
Hi Bill,
When you get a chance, could you modify CMakeLists.txt so that the
executables jt65code[.exe] and jt9code[.exe] are once again built as
part of the WSJT-X build procedure.
These utility programs are described in the User Guide (currently in
Section 14), so the executables should also
On 05/09/2014 17:09, Joe Taylor wrote:
> Hi all,
Hi Joe & All,
>
> I've posted a new v1.4 WSJT-X User Guide at
> http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
> and changed the URL compiled into WSJT-X (r4251) so that it points to
> this new location.
In the interests of no
Yes.5 second default socket_wait_time on line#14 in HRDTransceiver.cpp which
I changed to 10 seconds
If I start WSJT-X with HRD Logbook running the menu is greyed out. It still
decodes and runs.just can't use the menu to bring up settings for example.
With the timeout at 5 seconds I never see
Hi all,
I've posted a new v1.4 WSJT-X User Guide at
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main.html
and changed the URL compiled into WSJT-X (r4251) so that it points to
this new location.
This effort is aimed at having a reasonable User Guide available when we
post a can
On 05/09/2014 16:29, Michael Black wrote:
Hi Mike,
Still having problems with the HRD tcp bug.
What's of interest to me is that I can run HRD Logger and DM780 both
of which use port 7809 too and they don't seem to have any problems.
So I'm going to try and compare these to hopefully figure o
Still having problems with the HRD tcp bug.
What's of interest to me is that I can run HRD Logger and DM780 both of
which use port 7809 too and they don't seem to have any problems. So I'm
going to try and compare these to hopefully figure out what's going on. If
you want I can capture the netwo
21 matches
Mail list logo
