Re: Spectrum window crash / spot persistence


Patrick Herborn
 

On Tue, 23 Jul 2019 07:07:44 -0400
"Tom Wagner (N1MM)" <n1mmtomwagner@...> wrote:

Hiya Tom!

Many thanks for your reply.

There is a bug on transmit. Try right-click reset radios to start it
going again.
I can definitely give that a try, many thanks for the tip - I didn't
realise this would work for the Spectrum Window's SDR as well.

The DLL for SDRPlay can crash when restarted. Don't keep closing and
opening the spectrum window.
Apologies if I gave the wrong impression here. To be clear, I only
tried closing and re-opening AFTER the spectrum had frozen / stopped
working, in an effort to try to get it to go again - NOT before the
freeze in an effort to "break" it. Once frozen/crashed, there is
nothing that can be done - it ALWAYS ends up with having to quit N1MM+,
it's just the route to that point can differ. Sometimes you just get a
pop-up saying N1MM+ has stopped working, do you want to look online
for a solution, quit etc... that is less likely to happen if you
just leave the spectrum window alone once frozen / crahsed - the Task
Manager shows that window as Not Responding, but the rest of N1MM+
keeps working. If you try to close the spectrum window then IIRC it
does normally result, eventually, in the N1MM+ has stopped working
error. I believe I have seen that also when the spectrum window is left
alone after it has frozen/crashed, perhaps that just takes more
time. The long and short of it WAS that there was no way to
re-start the spectrum without restarting N1MM+ and then of course
you lose your spots (hence the request for persistence). Now
with your suggestion of Reset Radios, there is perhaps a chance.

If you insist on trying to crash the window by opening and closing, you
can make spots persist in the telnet window.
Many thanks for that tip - but perhaps I can ask for clarification ?
Will this make them persistent across N1MM+ exit-restart cycles,
or across Spectrum Window close-reopen cycles ? If it is the former
then that helps a lot :) As explained above, I don't deliberately
close-open the spectrum to try to break it, so the latter is useful
to know, but less helpful in the resolution of the problem.

The db scale is not accurate.  Hiding it to provide more spectrum
display area is intentional.
Right, OK, fair enough and many thanks for the clarification. The manual
makes reference to the scale for the mouse wheel and when looking for it
I thought "what scale?" - but then did see it with the config window
open. It might be worth addressing that in the manual to avoid
confusion :)

In some configurations, I prevent the spectrum from displaying during
transmit. This is intentional. Transmitting overloads the SDRPlay and
wipes out signals near the transmit frequency.
Yes, that is indeed the case - or the ADC AGC loop drops the front
end gain to avoid ADC saturation, and thus those signals disappear
due to the "limited" dynamic range. You can see this in SDRConsoleV3,
SDRUno etc - I even have a request in with SDRPlay for a feature in
SDRUno to drop the LNA gain when TX is detected so that the ADC
saturation splatter doesn't lead you to falsely thinking you have
modulation issues with your TX.

For the avoidance of doubt, since this is in preparation for IOTA,
most of the testing has been on SSB, and that is with the PTT
directly on the rig, ergo the only way that N1MM+ knows that the
rig has gone to TX is via the CAT interface. I suppose it is
possible that this could be related, depending on the TX behaviour
and whether your receiving CAT data indicating TX would cause the
spectrum window to pause during that TX, but then when it goes to
RX again it is for some reason not un-pausing. The fact that
WB is also freezes is info that might be useful to you - if,
for example, N1MM+ tells WB to "pause whilst TX is ongoing"
then this theory works out well, but if there is no such
comms between the spectrum data source and N1MM+ then we can
be confident that the problem lies elsewhere.

I know there is a possibility to route the PTT via the Footswitch
"through" N1MM+ - then it would know that we are in TX since it
made the rig change. The reason that I have not done that yet is
the audio routing - the PTT out of the computer goes via a data
mode cable to the back of the rig (Yaesu FT-950) and right now
a rear panel PTT forces the audio to come in via the rear panel - it
mutes the mic. A Mic socket PTT uses the mic and mutes the rear panel.
[I will re-check the manual to see if that behaviour can be changed.]

That then means that we would need to connect the headset to the
computer, but if we do that, then the manual left me with some
doubts - for example playing the F1 CQ file SHOULD mute the mic
(and I believe it is possible to configure the audio so that it
does), but then if we hit the Footswitch then the mic must NOT be
muted, otherwise we can't talk - the manual wasn't that clear if
this is what happens - perhaps you can confirm ? Also, since it is
a club station, routing PTT for the radio through N1MM+ means
that the rig can only be used WITH N1MM+ and not all members are
contesters / au fait with N1MM+, hence the existing setup with
PTT on the rig itself - hope that makes sense.

SDR Console is a much better SDR receiver & display.
It is a lovely piece of software, yes, and I very much like its display.

 It does not integrate finding *signals* (the red dots), keyboard
(shift up/down to jump signals),
Indeed - those I could live without for now.

radio control
That is possible with OmniRig :) SDRCV3 can do bidirectional rig
interaction (ie SDR tracks VFO, VFO tracks clicks in spectrum)
with OmniRig.

Additionally one can then use com0com to implement a serial "loopback"
to N1MM+ because SDRCV3 emulates a TS-2000 for the purposes of loggers
etc. N1MM+ is then configured to TS-2000 on the other end of the com0com
loop and hey presto - rig, SDR and N1MM+ all in sync - indeed you can
click in the Bandmap and the SDR and VFO will QSY. This is how we
have been running.....

and spot display.
That's be biggie for me - when operating S&P it is invaluable
to have spots (and worked entries) in the Spectrum / Waterfall -
you can immediately see if you are likely to have worked a
QRG before (of course sometimes people QSY, but that's life
and nothing is perfect). It's the thing that "pushed me over
the edge" and try to abandon SDRCV3 (for now, IIRC spot display
was on the ToDo list).

That brings me on to one final feature request - it would be GREAT
if one could edit the QRG of a spot WITHOUT changing its timestamp.
Right now if a run station QSYs we "Store" it again at its new QRG,
but that also wipes out the time delta between when that was originally
spotted or worked and now - and THAT information is actually quite
useful. We often run mulltiple operators and multiple logs from the
same QTH on the same contest and there are time constraints under those
circumstances. Eg new operator cannot work stations the last one did
until at least 15 minutes have passed. Since you cannot have two logs
open at the same time, the spots are really useful to know how long
ago you worked someone, but NOT if the time delta is wrong - so right
now you're damned if you do, damned if you don't - QSY the spot and
lose the time, or leave but then re-find the same signal again and again
only to find it's a dupe. The loss of spots on spectrum freezes /
crashes (necessitating an N1MM+ restart) is a problem here since
we then lose the time delta info - and as mentioned it's not
like we can have two logs open at the same time in order to
check the timestamp of the last QSO with a given station.

Tom - N1MM
Many thanks for your time, help and patience,

Pat. (M0MGO)

On 7/22/2019 9:11 PM, Patrick Herborn wrote:
Evening All!

Some further updates on this, still using the 18Jul release.

So far I have not been able to replicate the crash with IC-7300, it
looks like the current release is OK for the moment. It does occasionally
reset the waterfall but that is not an issue - the spots stays.

I have had more time with the RSP1A and have more info on that :

With N1MM+ driving the RSP1A, the spectrum display will hang at
occasions around a transmit event. Sometimes it is at the start,
sometimes it is at the end, but it seems to be stable so long
as you don't TX.... if you do, and if it freezes, then it is not
possible to close and re-open the Spectrum window, nor is it
possible to open the SDRPlay ExtIO config window. The only way
to recover is to exit and re-start N1MM+ as a whole - sometimes
this might need Task Manager to kill hung processes. Other times
the frozen Spectrum window will cause a full N1MM+ crash.

Thinking this was a hardware issue I proceeded to add a ferrite
to the USB cable. Unfortunately that did not help, but it did lead
me down a different path. Thinking that the issue was a software
one rather than hardware, and that it was related to the magnitude
of the returned data from the SDR, I tried using Waterfall Bandmap
to provide a spectrum data source to N1MM+....

With WB running, the problem moved. N1MM+ faithfully reported what
WB was sending it, BUT WB itself would hang. It is possible (sometimes
with the help of Task Manager) to restart WB and get the spectrum
going again without having to restart N1MM+ - which is a step in
the right direction, but tedious when WB frequently hangs during TX.

The fact that WB and N1MM+ both freeze is perhaps related to the
fact that WB was "merged" into N1MM+ and hence the source may be
very similar. That could help narrow things down a bit.

As a sanity check, and to "prove" the point that this issue is
most unlikely to be hardware, I tried running with no spectrum
display in N1MM+ and instead used SDRConsole V3 to display the
waterfall. I can confirm that, despite trying quite hard, I was
unable to "break" SDRConsole V3 - no matter how many times I
went to TX, no matter what power or mode, the spectrum data carried
on without any issues at all. WB and N1MM+ could be made to
hang with just 5W in CW! In SDRCV3 one could see the signal
strength rise from -110dBm to -37dBm with 5W, climbing to
-27dBm at 50W as expected, and getting all the way up to
-21dBm at times (the ADC AGC was targetting around -30dBm
so the -21 was brief until the outer AGC loop brings it down).
Thinking about that..... the scale on the Spectrum window
is "limited" to 50dB, so again I wonder if it's possible
that with a signal at least 80dB above the noise floor, could
that cause issues with the spectrum code ? SDRCV3 is setup
to span -140dBm up to somewhere around -20dBm - not much
point in going over that when the ADC AGC loop tries to
keep it down to -30dBm.... but that's a range of 120dB,
more than twice what's in the Spectrum window.

As a further aside - for some reason, unless I open the
config using the < in the top right, the dB scale on the
left, and the key on the right do not get rendered. Doubt
it is related, but it's not working as I suspect it is
supposed to do. When I close the config using > then the
dB scale and the key disappear again. For the avoidance
of doubt, this is in the Landscape mode.

It is possible, I guess, that SDRConsole is initialising the
RSP1A and its driver in a manner which differs from what WB
and N1MM+ do - I have a feeling that SDRCV3 doesn't use the
ExtIO dll - I guess I could verify if it is an ExtIO dll
issue by using the SDRPlay ExtIO dll with HDSDR - if that
breaks then it's an SDRPlay issue, not N1MM+/WB, but if
HDSDR works fine with the ExtIO dll then it narrows it
down further to 1) the hardware config set as the programs
start, or 2) N1MM+/WB getting themselves in a twist with
some aspect of the IQ data.

I'll keep digging - in the meantime if anyone has any further
suggestions for things to try in order to narrow it down, that
would be much appreciated!

Whilst I was hoping to use this setup for IOTA this coming weekend
I am slowly resigning myself to the fact that we will have to use
the older setup with N1MM+ talking to SDRCV3 and SDRCV3 using
OmniRig to talk to the radio. That setup has worked well in the
past, BUT you don't get spots on the spectrum, which is useful
for an S&P station.

Best regards,

Pat. (M0MGO)

--
Patrick Herborn <pat@...>

Join N1MMLoggerPlus@groups.io to automatically receive all group messages.