Hi Bill and Greg,
> Of course you are correct but I see Greg's point too. I expect he is
> concerned about the complexities of delivering an application on Linux
> for example where the whole thing must be built from sources plus
> existing packages. A statement like "Building the library would be
On 18/10/2014 00:56, Joe Taylor wrote:
Hi Joe,
> Hi Greg,
>
> About a possible common library:
>
>>> I would like to see any common libraries built with CMake, this is
>>> because CMake has powerful tools for exporting library code for use in
>>> other CMake built projects. This doesn't make them a
On 18/10/2014 00:38, Joe Taylor wrote:
> Hi Bill and all,
>
> Of course, a savvy user would edit the automatically generated message
> so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL"
> is one of the 339 "standard" prefixes defined in pfx.f90. They are
> legit
Hi Greg,
About a possible common library:
>> I would like to see any common libraries built with CMake, this is
>> because CMake has powerful tools for exporting library code for use in
>> other CMake built projects. This doesn't make them any less useful for
>> non-CMake projects.
> Unless you p
Hi Bill and all,
Of course, a savvy user would edit the automatically generated message
so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL"
is one of the 339 "standard" prefixes defined in pfx.f90. They are
legitimate for the compound-callsign messages we ca
That's what I figure...it's just that little blue line doesn't exactly jump
out and slap you in the face... I could stand a warning box when you're
close to the cutoff. Just a friendly "Be aware you are close to the JT9
cutoff frequency".
Mike W9MDB
-Original Message-
From: Bill Somervi
I'll try it again and start savinv the wav files. If I can repeat it I'll
let you know. I suspect the incoming might have been a touch under 2600 as
some like to frequency walk.
All I know is I was receiving responses to my CQ and nothing decoded even
with a pretty strong signal.
Mike W9MDB
-
On 17/10/2014 23:48, Joe Taylor wrote:
> Mike --
>
> On 10/13/2014 5:50 PM, Michael Black wrote:
>> I just made a boo-boo which I think could have been prevented.
>>
>> I had the JT9 frequency range set to "JT65 2600 JT9". I had my offset set
>> to 2600 also. I couldn't decode anything.
>>
>> So
Mike --
On 10/13/2014 5:50 PM, Michael Black wrote:
> I just made a boo-boo which I think could have been prevented.
>
> I had the JT9 frequency range set to "JT65 2600 JT9". I had my offset set
> to 2600 also. I couldn't decode anything.
>
> So perhaps WSJT-X shouldn't let you transmit JT9 at o
On 17/10/2014 22:19, Michael Black wrote:
Hi Mike,
I know you and add/remove buttons but that removes them from the radio
interface too? Yuck
Yeah, not very comfortable with that myself. Fortunately I implemented
the WSJT-X interface as a trivial compiler that parses the available H
I know you and add/remove buttons but that removes them from the radio
interface too? Yuck
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, October 17, 2014 4:17 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] HRD error
On 17/10/2014 22:12, Mich
On 17/10/2014 22:12, Michael Black wrote:
Hi Mike,
I wonder if you want to keep the HRD Information file in the
repository version too…just imagining there might be at least one
other radio with quirks that might need addressed. I guess it
shouldn't add much overhead.
I plan to do that at
Hello All,
On 10/17/2014 02:05 PM, Bill Somerville wrote:
> On 17/10/2014 20:25, Joe Taylor wrote:
>> Hi all,
> Hi Joe,
>> Bill responded to a recent query on wsjtgroup about the use of compound
>> callsigns.
>>
>> As we all know, these are bit of a nuisance in JT65, JT9, and JT4, in
>> part becau
On 17/10/2014 21:52, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
>>> Of course, a savvy user would edit the automatically generated message
>>> so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL"
>>> is one of the 339 "standard" prefixes defined in pfx.f90. They are
>>> legitimate fo
I wonder if you want to keep the HRD Information file in the repository
version too.just imagining there might be at least one other radio with
quirks that might need addressed. I guess it shouldn't add much overhead.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, October
Here ya' go:
Mike W9MDB
Id: Ham Radio Deluxe
Version: v6.2.72.303 b303
Radios:
865:TT-OMNI VII (Radio)
Current radio: TT-OMNI VII (Radio)
VFO count: 2
Buttons: {ATT, Slow, Medm, Fast, Notch, NR, A~<>~B, A~=~B, B~=~A}
Dropdowns:
Mode A: {AM, USB, LSB, CW,
Hi Bill,
>> Of course, a savvy user would edit the automatically generated message
>> so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL"
>> is one of the 339 "standard" prefixes defined in pfx.f90. They are
>> legitimate for the compound-callsign messages we call "Type 1" in t
On 17/10/2014 21:40, Michael Black wrote:
Hi Mike,
OK…first two transmits went with flying colors so that looks like it
fixed the problem.
I don't recall enabling USB mode recently…but guess it's a good thing
it did get selected to find the bug.
Thanks for that, committed change to trunk
OK.first two transmits went with flying colors so that looks like it fixed
the problem.
I don't recall enabling USB mode recently.but guess it's a good thing it did
get selected to find the bug.
Thanks
Mike W9MDB
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Friday, October
On 17/10/2014 20:51, Michael Black wrote:
Hi Mike,
I guess I was getting trace output…hadn't realized it moved to the new
location…
It's appears the SPLIT mode is causing it. HRD still hasn't added
SPLIT to the OMNI VII yet (it's purportedly on their TODO list along
with fixing their TCP C
On 17/10/2014 20:25, Joe Taylor wrote:
> Hi all,
Hi Joe,
>
> Bill responded to a recent query on wsjtgroup about the use of compound
> callsigns.
>
> As we all know, these are bit of a nuisance in JT65, JT9, and JT4, in
> part because of the need to maintain backward compatibility with the
> origin
I guess I was getting trace output.hadn't realized it moved to the new
location.
It's appears the SPLIT mode is causing it. HRD still hasn't added SPLIT to
the OMNI VII yet (it's purportedly on their TODO list along with fixing
their TCP CAT control bug)
Mike W9MDB
Fri Oct 17 19:44:38 2014 G
Hi all,
Bill responded to a recent query on wsjtgroup about the use of compound
callsigns.
As we all know, these are bit of a nuisance in JT65, JT9, and JT4, in
part because of the need to maintain backward compatibility with the
original JT65 protocol specification, defined more than ten year
Hello All,
Just FYI, there is a rescent OmniRig.exe Installer included in JTSDK-QT,
or you can download the very latest from:
http://www.dxatlas.com/omnirig/
73's
Greg, KI7MT
On 10/17/2014 12:26 PM, Bill Somerville wrote:
> Hi Matthias,
>
> a quick answer is that you need to install OmniRig
Hi Matthias,
a quick answer is that you need to install OmniRig on the development
machine because a tool runs in the build to generate the interface to
OmniRig from the registered OmniRig server. Both the recommended CMake
build and the old and obsolete qmake project should do this generation
Hi Matthias,
You are correct that Omnirig.h is included not in the tarfile. It is
created during the build procedure using CMake.
If you need help in building WSJT-X, you might want to join the
wsjt-devel email list.
-- 73, Joe, K1JT
On 10/17/2014 1:58 PM, Matthias Buchwald wrote:
>
On 10/17/2014 12:59 PM, Michael Black wrote:
> Is showing up all at once a problem?
None of this is a problem, as far as I'm aware.
Is showing up all at once undesirable? Yes, if that means that the
first decode shows up later than it otherwise would have. The first
decode is always the one
I should also have said that the compiler is even allowed to change the
order of execution of expressions and statements when the order is
defined by the Standard so long as the resulting state is the same as if
it were executed in the defined order. This has lead to some very nasty
concurrency
I'm out to lunch and will test when i get back.
Mike W9MDB
Sent on a Virgin Mobile Samsung Galaxy S® III
Original message From: Bill Somerville
Date:10/17/2014 12:17 PM (GMT-06:00)
To: WSJT software development
Subject: Re: [wsjt-devel] HRD error
On 17/10/2014 17:33, Mic
On 17/10/2014 17:33, Michael Black wrote:
Hi Mike,
Running r4524 with Tentec Omni VII through HRD 6.2.72.303 I'm getting
"Ham Radio Deluxe: rig doesn't support mode" every time WSJT-X transmits.
OK, that'll be because I checked in a fairly large change to deal with
some Yaesu vagaries via H
On 17/10/2014 17:59, Michael Black wrote:
Hi Mike,
> Is showing up all at once a problem?
> At the moment the decodes show up quicker in WSJT-X than before.
> That flush could be adding 10's of MS per decode.
> JTAlert is also monitoring that file for changes so one flush seems like the
> best idea
Hi Bill,
>> Ralf Koetter's code used a number of constructions like the following:
>>
>> for (y = m2-1-x; y; ) d[y--] = p[y];
>>
>> The clang compiler flagged these with warnings like this:
>>
>> warning: unsequenced modification and access to 'y'
> Yes, that is undefined behaviour.
Yes
Is showing up all at once a problem?
At the moment the decodes show up quicker in WSJT-X than before.
That flush could be adding 10's of MS per decode.
JTAlert is also monitoring that file for changes so one flush seems like the
best idea for it.
Mike W9MDB
-Original Message-
From: Joe Tay
On 17/10/2014 17:54, Joe Taylor wrote:
> Mike --
>
> As a speed freak, you should pay attention to what timer.out can tell you.
>
> As for the "call flush(6)" at line 171 of decoder.f90: it's there
> (inside the loop) so that the GUI will display each decode immediately,
> when it occurs, rather th
On 17/10/2014 17:11, Joe Taylor wrote:
> Hi Diane,
>
>> O!! Perhaps we can get a version compiled up for FreeBSD now? This
>> is exactly what we saw the last time you compiled up kvasd for FreeBSD.
>> No output except 0's.
> By all means -- let me know how best to proceed!
A 64-bit version for
Mike --
As a speed freak, you should pay attention to what timer.out can tell you.
As for the "call flush(6)" at line 171 of decoder.f90: it's there
(inside the loop) so that the GUI will display each decode immediately,
when it occurs, rather than when the loop is finished. If you remove
tha
On 17/10/2014 16:29, Joe Taylor wrote:
Hi Joe,
> I have spent 1.5 days trying to understand why kvasd[.exe], the
> Koetter-Vardy algebraic soft-decision decoder, compiled correctly with
> versions 4.6.1 and 4.6.3 of gcc and gfortran, but fails with versions
> 4.8.1 and 4.8.2.
>
> With the code as
Running r4524 with Tentec Omni VII through HRD 6.2.72.303 I'm getting "Ham
Radio Deluxe: rig doesn't support mode" every time WSJT-X transmits.
If I click "retry" it does continue transmitting. Perhaps the error message
should say what mode it was trying?
Was running fine up to r4514 - I upd
Well..yeah...speed..I would expect the "decode" phase to max out CPU until
all decodes are done...hate to see idle electrons. I'm a speed freak.
It doesn't appear to use 100% CPU (of even one core). Though I'm waiting
for a really busy band to really see what it does.
One thing I'm testing is I'v
Hi Diane,
> O!! Perhaps we can get a version compiled up for FreeBSD now? This
> is exactly what we saw the last time you compiled up kvasd for FreeBSD.
> No output except 0's.
By all means -- let me know how best to proceed!
-- Joe, K1JT
On Fri, Oct 17, 2014 at 11:29:14AM -0400, Joe Taylor wrote:
> I have spent 1.5 days trying to understand why kvasd[.exe], the
> Koetter-Vardy algebraic soft-decision decoder, compiled correctly with
> versions 4.6.1 and 4.6.3 of gcc and gfortran, but fails with versions
> 4.8.1 and 4.8.2.
>
> W
Hi Mike,
On 10/16/2014 4:12 PM, Michael Black wrote:
> Has any thought or attempt been given to multi-threading the decoding
> process?
To what end? Are you concerned about decoding speed? Have you looked
at the statistics in file 'timer.out', results from the built-in
execution profiler for
I have spent 1.5 days trying to understand why kvasd[.exe], the
Koetter-Vardy algebraic soft-decision decoder, compiled correctly with
versions 4.6.1 and 4.6.3 of gcc and gfortran, but fails with versions
4.8.1 and 4.8.2.
With the code as it has been for some years, the build appears
successfu
On 16/10/2014 21:12, Michael Black wrote:
Hi Mike,
Has any thought or attempt been given to multi-threading the decoding
process?
The decoding is almost exclusively Fortran code. Multi threading isn't
really the way Fortran code is parallelized (is that a word?), normally
a special compiler
44 matches
Mail list logo
