Hi Phil,
some comments in line below.
On 08/02/2017 13:24, Phil Frost wrote:
Well, I'm happy to report I was able to get a local build from the
most current version in SVN, and it now rig control works. Previously,
the softrock rig wasn't available in the hamlib configuration (that's
why I was trying to use the net backend), but now it is and it works
fine. It may be because I built a fresher hamlib when building the
fork as described in INSTALL.
I am still thinking about how we can address the design issues with the
Hamlib NET rigctl driver. This is a fundamental issue in the design of
Hamlib which will probably need some fairly large scale surgery to
address. I have posted an RFC to the Hamlib developers list to see if
anyone else had any input. I have a few ideas for workarounds in WSJT-X
but it is non-trivial.
I do notice some new issues, unfortunately.
Firstly, wstjx would segfault at start. I traced this to the memset()
in main() which initializes the shared memory, around line 300 or so.
It was attaching to an existing shared memory segment at start, which
I suppose had a different size and so memset overran it. I "fixed" it
by changing the application key, but I'm not sure what led to this
condition in the first place.
This should not be happening. There are two possible explanations:
Firstly an older version of WSJT-X may be attached to the shared memory
section with the same key, if the two instances request different sizes
and the smaller request is first then because there is no easy way of
negotiating a larger section while it is open this will happen.
When the last process closes it should release and destroy the shared
memory section, this can go wrong and leave a stale shared memory
section hanging around. This can be fixed by simply running WSJT-X with
the same --rig-name option and then shutting it down normally and the
shared segment should be released and destroyed. If this is not
happening then you can list shared memory with `lsipc -m`. A stale
section will have 0 for NATTACH like this:-
KEY ID PERMS OWNER SIZE NATTCH STATUS CTIME CPID LPID COMMAND
0x5100001b 2064398 rw------- bill 7.6M 0 14:04 5178 5178
You can delete it with `ipcrm -m <id>` but that should not be necessary
as Linux should scavenge it automatically after a while.
Secondly, although decode works and the level meter in the lower-left
shows around 20dB, the waterfall is black.
pasted1
I've tried twiddling the range and zero adjustments to no avail. (You
can also see in this screenshot the "smashed" GUI, probably a
consequence of my HiDPI display settings.)
If you are only getting a 20dB level meter indication when signals are
present then your input audio level is very low, around 30dB for noise
on a dead band is about optimal. You can use the slider next to the
indicator to boost it but be aware that settings away from the mid point
are trivial digital gain or attenuation and they do not improve the
signal, in fact they degrade the signal if too extreme. Your best action
would be to try and get more input to the SDR ADC so the output is
nearer full scale for the maximum received signals.
Do not extend the waterfall display wider than 5000Hz, the code does not
check fully for such a wide setting and there are bugs. The first stage
of input processing is an LPF with cut off at <6000Hz, this is necessary
as we process internally at 12000Hz and have to remove anything that
would cause DFT wrap around aliases.
Lastly, the band hopping "Schedule..." button doesn't seem to open any
window when I click it. I had this problem with the previous build
also, which I got from a PPA:
This issue has been reported before, it is window manager limitation.
Does your widow manager have a task bar or equivalent on the desktop, if
so is there any indication there that the band hopping schedule window
is open?
73
Bill
G4WJS.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
