Topics

Spectrum window crash / spot persistence

Patrick Herborn
 

Good afternoon All!

I have noticed on a number of occasions now that N1MM+ has crashed, to
the point of having to exit and re-start, when used with the Spectrum
window. I have thus far not experienced this issue with the Spectrum
window closed, hence suspect it is related. Unfortunately it is a
Heisenbug and difficult to replicate. I will keep trying to narrow it
down to a Bohrbug.

The last time it happened was during a VHF contest operating S&P, where
I had initially got the wrong end's locator. I then got the callsign of
the station calling CQ, and went to change the locator, at which point
it bombed out.

The computer is a Windows 7 64 bit machine with an i7 processor, with
the latest updates to Windows and also the latest version of N1MM+
available at the time (last Thursday). The spectrum data source was an
Icom IC-7300, with its spectrum display set to fixed, using CI-V as a
transport at 115,200bps.

Previously I have had similar crashes with the IC-7300 and also with an
SDR Play RSP-1A. The previous occasion the spectrum crashed on the
IC-7300 I also lost VFO readback on the same evening - I suspect this
was down to knocking a bad USB socket. It was possible to re-establish
comms by unplugging and re-plugging the IC-7300 USB - I cannot be sure
whether it was a USB issue that time.

The times where N1MM+ has crashed when connected to the RSP-1A was also
with a potentially suspect USB socket. It was for this reason that the
IC-7300 was plugged into a different port on Thursday, one that could
not get knocked. I can confirm it did not, and that upon re-starting
N1MM+, it was able to read the VFO - it's not like the USB crashed on
that occasion. Once again I elected not to run the Spectrum window and
got to the end of the contest without further issue(s).

I know this is quite vague right now and I will try to find a sequence
of events that provokes it, but on Thursday, it was over an hour into
the contest (plus at least half an hour before) at the point it died.
Thankfully the log was intact - and since we were paper logging as well
we had the QSO details that were in the entry boxen but not yet logged.
No major harm done.

The only "harm" is that a re-start of N1MM+, as necessitated by such a
crash, causes all of the spots in the bandpap and spectrum window to
disappear. This is most likely intentional and/or desirable in normal
operation - typically you'de be opening a new log and don't want your
old spots in there, BUT when it is due to a crash, and if you're mostly
S&P rather than Run, then losing your spots can be most frustrating -
you can't immediately tell if you've probably worked a given QRG
before!

I'm not sure how simple it would be to add some persistence to the spots
(even if only grey ones) - perhaps a feature that is off by default. If
memory serves there is a way to flush spots already in existence, so it
would be possible to re-use that feature to clear previous spots when
a contest is completed without a crash.

Many thanks in advance,

Pat (M0MGO).

--
Patrick Herborn <pat@...>

Chuck Dietz
 

I had similar problems before I upgraded my computer to one with more memory. I found that with more programs running, FT8 decoded fewer stations and there were more crashes.

Chuck W5PR

On Mon, Jul 15, 2019 at 2:08 PM Patrick Herborn <pat@...> wrote:
Good afternoon All!

I have noticed on a number of occasions now that N1MM+ has crashed, to
the point of having to exit and re-start, when used with the Spectrum
window. I have thus far not experienced this issue with the Spectrum
window closed, hence suspect it is related. Unfortunately it is a
Heisenbug and difficult to replicate. I will keep trying to narrow it
down to a Bohrbug.

The last time it happened was during a VHF contest operating S&P, where
I had initially got the wrong end's locator. I then got the callsign of
the station calling CQ, and went to change the locator, at which point
it bombed out.

The computer is a Windows 7 64 bit machine with an i7 processor, with
the latest updates to Windows and also the latest version of N1MM+
available at the time (last Thursday). The spectrum data source was an
Icom IC-7300, with its spectrum display set to fixed, using CI-V as a
transport at 115,200bps.

Previously I have had similar crashes with the IC-7300 and also with an
SDR Play RSP-1A. The previous occasion the spectrum crashed on the
IC-7300 I also lost VFO readback on the same evening - I suspect this
was down to knocking a bad USB socket. It was possible to re-establish
comms by unplugging and re-plugging the IC-7300 USB - I cannot be sure
whether it was a USB issue that time.

The times where N1MM+ has crashed when connected to the RSP-1A was also
with a potentially suspect USB socket. It was for this reason that the
IC-7300 was plugged into a different port on Thursday, one that could
not get knocked. I can confirm it did not, and that upon re-starting
N1MM+, it was able to read the VFO - it's not like the USB crashed on
that occasion. Once again I elected not to run the Spectrum window and
got to the end of the contest without further issue(s).

I know this is quite vague right now and I will try to find a sequence
of events that provokes it, but on Thursday, it was over an hour into
the contest (plus at least half an hour before) at the point it died.
Thankfully the log was intact - and since we were paper logging as well
we had the QSO details that were in the entry boxen but not yet logged.
No major harm done.

The only "harm" is that a re-start of N1MM+, as necessitated by such a
crash, causes all of the spots in the bandpap and spectrum window to
disappear. This is most likely intentional and/or desirable in normal
operation - typically you'de be opening a new log and don't want your
old spots in there, BUT when it is due to a crash, and if you're mostly
S&P rather than Run, then losing your spots can be most frustrating -
you can't immediately tell if you've probably worked a given QRG
before!

I'm not sure how simple it would be to add some persistence to the spots
(even if only grey ones) - perhaps a feature that is off by default. If
memory serves there is a way to flush spots already in existence, so it
would be possible to re-use that feature to clear previous spots when
a contest is completed without a crash.

Many thanks in advance,

Pat (M0MGO).

--
Patrick Herborn <pat@...>



Patrick Herborn
 

On Mon, 15 Jul 2019 14:34:14 -0500
"Chuck Dietz" <w5prChuck@...> wrote:

Hiya Chuck,

I had similar problems before I upgraded my computer to one with more
memory. I found that with more programs running, FT8 decoded fewer stations
and there were more crashes.
The computer is used only for logging, so it has N1MM+ running and
nothing else. IIRC it is 8GB of memory, will check next time I am
at the computer (it's at a club). I would have hoped this to be
enough, but I can try it on another that has 16GB....

As a further update, I can report that with the version released
yesterday, N1MM+ ran flawlessly for the entire evening last night,
but since it was connected to an IC-9700 rather than an IC-7300
at the time, it's not a direct apples-to-apples comparison. Thursday
should provide an opportunity to try it again with the IC-7300,
with fingers crossed :)

Chuck W5PR
Cheers,

Pat (M0MGO).

On Mon, Jul 15, 2019 at 2:08 PM Patrick Herborn <pat@...> wrote:

Good afternoon All!

I have noticed on a number of occasions now that N1MM+ has crashed, to
the point of having to exit and re-start, when used with the Spectrum
window. I have thus far not experienced this issue with the Spectrum
window closed, hence suspect it is related. Unfortunately it is a
Heisenbug and difficult to replicate. I will keep trying to narrow it
down to a Bohrbug.

The last time it happened was during a VHF contest operating S&P, where
I had initially got the wrong end's locator. I then got the callsign of
the station calling CQ, and went to change the locator, at which point
it bombed out.

The computer is a Windows 7 64 bit machine with an i7 processor, with
the latest updates to Windows and also the latest version of N1MM+
available at the time (last Thursday). The spectrum data source was an
Icom IC-7300, with its spectrum display set to fixed, using CI-V as a
transport at 115,200bps.

Previously I have had similar crashes with the IC-7300 and also with an
SDR Play RSP-1A. The previous occasion the spectrum crashed on the
IC-7300 I also lost VFO readback on the same evening - I suspect this
was down to knocking a bad USB socket. It was possible to re-establish
comms by unplugging and re-plugging the IC-7300 USB - I cannot be sure
whether it was a USB issue that time.

The times where N1MM+ has crashed when connected to the RSP-1A was also
with a potentially suspect USB socket. It was for this reason that the
IC-7300 was plugged into a different port on Thursday, one that could
not get knocked. I can confirm it did not, and that upon re-starting
N1MM+, it was able to read the VFO - it's not like the USB crashed on
that occasion. Once again I elected not to run the Spectrum window and
got to the end of the contest without further issue(s).

I know this is quite vague right now and I will try to find a sequence
of events that provokes it, but on Thursday, it was over an hour into
the contest (plus at least half an hour before) at the point it died.
Thankfully the log was intact - and since we were paper logging as well
we had the QSO details that were in the entry boxen but not yet logged.
No major harm done.

The only "harm" is that a re-start of N1MM+, as necessitated by such a
crash, causes all of the spots in the bandpap and spectrum window to
disappear. This is most likely intentional and/or desirable in normal
operation - typically you'de be opening a new log and don't want your
old spots in there, BUT when it is due to a crash, and if you're mostly
S&P rather than Run, then losing your spots can be most frustrating -
you can't immediately tell if you've probably worked a given QRG
before!

I'm not sure how simple it would be to add some persistence to the spots
(even if only grey ones) - perhaps a feature that is off by default. If
memory serves there is a way to flush spots already in existence, so it
would be possible to re-use that feature to clear previous spots when
a contest is completed without a crash.

Many thanks in advance,

Pat (M0MGO).

--
Patrick Herborn <pat@...>





--
Patrick Herborn <pat@...>

Patrick Herborn
 

Quick update on this front...

Last night I was once again able to use N1MM+ on the laptop with the
IC-7300 which had previously caused a crash to happen, even when in
the good USB socket.

Whilst it did not crash per se (yay!) it did on three occasions reset
the spectrum window - ie not just pause it during TX, but actually
wipe it clean of waterfall data. This was not an issue per se, the
spots remained so no harm done.

These three resets ALWAYS happened either during, or just after TX.
The IC-7300 is set to EDGE mode not CENTER, so it doesn't output
any spectrum data during TX, but I would have thought that the
spectrum code would already be aware of / know how to deal with
an IC7300/7610/9700 saying "can't give you that right now".

Best regards,

Pat. (M0MGO)

--
Patrick Herborn <pat@...>

Patrick Herborn
 

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@...>

Tom Wagner (N1MM)
 

There is a bug on transmit. Try right-click reset radios to start it going again.

The DLL for SDRPlay can crash when restarted. Don't keep closing and opening the spectrum window.

If you insist on trying to crash the window by opening and closing, you can make spots persist in the telnet window.

The db scale is not accurate.  Hiding it to provide more spectrum display area is intentional.

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.

SDR Console is a much better SDR receiver & display.  It does not integrate finding *signals* (the red dots), keyboard (shift up/down to jump signals), radio control and spot display.

Tom - N1MM

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
 

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@...>

Steve London
 

Patrick,

You have a few misconceptions. See below.

73,
Steve, N2IC

On 07/22/2019 07: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.
I have both a RSP1 and RSP1A. In the IARU contest I used them both in a SO2R configuration. I used two instances of WB, each driving it's own N1MM+ spectrum display. Ran absolutely solid for the 24 hour contest. The antenna input for the RSP's is from each TS-590SG RX ant output. The level of RF going to the RSP while transmitting is quite low - the RSP's are not overloading.

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.
Fact ? I am the author of WB. I am also on the N1MM+ development team. There is nothing "merged" about WB and N1MM+. WB is written in C#, while N1MM+ is in VB.Net. They communicate with each other over UDP. The only commonality is that they both use the SDRPlay-supplied ExtIO. If you like, I can send you the ExtIO that I am currently using with WB.

73,
Steve, N2IC

Patrick Herborn
 

On Tue, 23 Jul 2019 08:39:11 -0600
"Steve London" <n2ic@...> wrote:

Patrick,
Hiya Steve!

Many thanks for your response.

You have a few misconceptions.
Always happy to be corrected :)

See below.
Righty ho... answered below...

73,
Steve, N2IC

On 07/22/2019 07: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.
I have both a RSP1 and RSP1A. In the IARU contest I used them both in a SO2R
configuration. I used two instances of WB, each driving it's own N1MM+ spectrum
display. Ran absolutely solid for the 24 hour contest.
That's great news because it means what we are trying to do is
definitely achievable - many thanks for confirming.

The antenna input for the RSP's is from each TS-590SG RX ant output.
Yes, that feature was added from the TS-590S -> TS590SG update. It's
a great rig and a great feature!

The level of RF going to the RSP while transmitting is quite low -
the RSP's are not overloading.
Yes, you are lucky with that. We don't have such an RX out, hence we
use a RX/TX switch in the antenna feedline. This connects the RSP1A
to the antenna during RX (with just over 3dB insertion loss, 3dB for
the power sharing, and a little more for the impedance mismatch).
During TX the RSP1A's output from the box is grounded, but a fair bit
of RF still comes through - as mentioned we see up to -21dBm but
only shortly, presumably because the ADC AGC loop targetting -30dBm
drops it back down.... that's in SDRCV3.

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.
Fact ?
I based this assertion on an N1MM Logger+ Facebook post :

https://www.facebook.com/N1MMLogger/photos/n2ic-has-integrated-waterfall-bandmap-with-the-n1mm-spectrum-display-wb-shown-jo/1388327364570220/

Apologies if I misconstrued that - no offence intended! I read it
as your code getting merged into N1MM+, but with hindsight perhaps
it was meant to mean that WB can now supply spectrum data to N1MM+.

I am the author of WB. I am also on the N1MM+ development team. There is
nothing "merged" about WB and N1MM+.
OK, many thanks for the clarification - and that information does help
point in the direction of the ExtIO dll...

WB is written in C#, while N1MM+ is in VB.Net.
Given that they display a *similar* freeze (N1MM+ shows nothing at all,
but WB spectrum freezes, stays visible and continually gets copied to
the waterfall), it suggests that the common item (assuming this is not
just a coincidence) is further upstream.

They communicate with each other over UDP.
WB acts as a Named Source to N1MM+....

The only commonality is that they both use the SDRPlay-supplied ExtIO.
That is definitely looking like the most likely culprit at the moment!

Doesn't explain the IC-7300 issue, but HOPING that was a USB oops.

If you like, I can send you the ExtIO that I am currently using with WB.
Yes, that would be a very good test! Also, if you happen to know, or can
find out, what settings you are using in the SDRPlay config window, that
would help a lot as well.

Furthermore I had two additional ideas to try, when near a rig and SDR
I can try it on....

1) Unplug the SDR from the RX/TX box and see if that helps. If it then
does not crash, then it is almost certainly related to the data coming
back from the SDR.

2) Try tuning the SDR far away from the TX frequency and see what
happens. The strong TX signal should not get past the IF filters and so
the SDR should not "see" the high ADC counts.

I'll try those, and any other suggestions others may have at the
earliest opportunity.

73,
Steve, N2IC
Many thanks for your time, help and patience,

Pat. (M0MGO).



--
Patrick Herborn <pat@...>

Patrick Herborn
 

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

Had an opportunity to do some testing tonight, so reporting results.

There is a bug on transmit. Try right-click reset radios to start it
going again.
I tried this method, on the 18Jul release, and the latest release, but
it does not reset the SDR - it is still necessary to exit and restart
N1MM+ - sometimes with Task Manager to clear out a zombie process.

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.
I can confirm that with the existing setup, using a PTT footswitch
direct to the radio, the spectrum does keep rolling during TX, BUT
it is slower. I don't know if it is supposed to.... but thought I'de
report what I observed. Both releases seem to react the same.

Now to the bulk of the info :

Test set 1 : Checks with nothing changed
----------------------------------------

o It was possible to freeze/crash Waterfall Bandmap with a CW carrier
on 20m. 40W was enough for consistent freezes.
o With the antenna feed to the SDR removed, it was possible to
key up as many times as I wanted, it would not freeze/crash,
even with 100W.
o With the SDR connected to the switch, but tuned to 40m, it was
possible to key up as many times as I wanted on 20m, it would not
freeze / crash, even on 100W

o It was possible to freeze/crash N1MM+ (N1MM+ controlling SDR) on
20m. 40W was enough for consistent freezes. Reset Radios did
not bring the spectrum window back to life.
o With the antenna feed to the SDR removed, it was possible to
key up as many times as I wanted, and N1MM+ would not freeze/crash,
even with 100W
o With the SDR connected to the switch, but tuned to 40m, it
was possible to key up as many times as I wanted on 20m, it would
not freeze/ crash N1MM+, even with 100W


Test Set 2 : Try Steve N2IC's ExtIO DLL version
-----------------------------------------------

o Tests were abandoned - Steve's DLL was the same version already in use


Test Set 3 : New version of N1MM+
---------------------------------

o It initially looked good, but eventually managed to get N1MM+ spectrum
window to freeze/crash using a 100W CW carrier.
o It was noted that the spectrum window appeared to be suppressing the
carrier (it used to be there - guess this is new)
o Reset Radios did not recover the spectrum window - again a full restart
of N1MM+ was needed - and Task Manager may have been necessary (sorry,
notes don't say)
o It seems to be considerably more robust than it was when operating a CW
carrier.
o When operating SSB, the sideband is visible, but an area round the
(suppressed) carrier is attentuated. Whereas CW was more likely to
cause issues before, now SSB has the higher risk of freeze/crash.
This shift is most likely down to the increased resilience to CW,
NOT some new unintended side effect.
o Detaching the SDR antenna feed, transmitting into a dummy load, or
having the SDR on 40m with the rig transmitting on 20m all allow
the SDR to endure as many TX events as I could give it - ie I could
not break it.

The above leads me to conclude that something is not liking the higher
ADC drive levels associated with the SDR being connected. What is
interesting is that the carrier suppression on CW seems to help. I
am guessing this is done in N1MM+ not in the DLL ?

I did not get a chance to try HDSDR with the RSP1A ExtIO DLL, I'll need
to try that in the next coulple of days.

It does seem clear that there is one "sure fire" way of fixing the
issue - reduce the signal level into the SDR. I'll look to make
a second RX/TX switch to block to -20dBm level signal that is
still making its way through - but hopefully it will be possible
to implement a software fix eventually. Indeed Steve has shared
his RSP1A settings - with any luck that may be enough, just
setting the RSP1A up differently...

I'll report back further findings :)

Best regards,

Pat. (M0MGO)

--
Patrick Herborn <pat@...>

Patrick Herborn
 

A quick update.

I got a chance to try the HDSDR test tonight (with SDRPlay ExtIO DLL).

As anticipated, HDSDR also froze/crashed, further pointing toward the DLL as the
cause. That being the case, I tried Steve's config for the DLL and hey presto,
it works! OK, great - a working config, now find out the critical bit....

Steve had LNA gain 2, Low IF, 200kHz IF filter, and 31 IF gain, with a Total
Gain Reduction of 43dB....

First test : try the ADC AGC rather than a static gain. That still worked so
that was good.

Next test : try different LNA gains. That also worked fine - with more gain
it would show ADC OVERLOAD on the SDRPlay config window, and there was
clipping hash in the spectrum, BUT it didn't crash!

Next test : try it with the wider 1.536kHz IF bandwidth. This got rid of
the decimation, again it would show ADC OVERLOAD but not crash, which is
still good.

The final change was back to Zero IF - immediate freeze/crash. Right, it
doesn't like Zero IF!

It looks like the only thing I *NEED* to change in order to avoid
freezes/crashes is to use Low IF.

I tested this in N1MM+ and it was stable running the RSP1A itself,
I haven't tried WB at this time but I would be somewhat surprised
if this didn't fix it.

There is one caveat here.... it was a different rig and I had to run
FM with zero mic gain to get a carrier. Thought this one could be
keyed by MIC UP and MIC DOWN on CW but alas not, and didn't have a
spare key to hand. So it COULD still break, *BUT* given that it
pretty much IMMEDIATELY broke with Zero IF even at 5W, I suspect
that it will behave OK. Fingers crossed! Should get a chance to
test it on the actual rig we should be using for IOTA tomorrow.

If it pans out well (no pun intended ;) ) the use of Low IF could then
make its way into the manual....

Best regards,

Pat. (M0MGO).


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

There is a bug on transmit. Try right-click reset radios to start it
going again.

The DLL for SDRPlay can crash when restarted. Don't keep closing and
opening the spectrum window.

If you insist on trying to crash the window by opening and closing, you
can make spots persist in the telnet window.

The db scale is not accurate.  Hiding it to provide more spectrum
display area is intentional.

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.

SDR Console is a much better SDR receiver & display.  It does not
integrate finding *signals* (the red dots), keyboard (shift up/down to
jump signals), radio control and spot display.

Tom - N1MM

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@...>

Patrick Herborn
 

This "should" be the final update in this thread (assuming no other gremlins
materialise)....

The use of the "Low IF" option in the SDRPlay configurator appears to have
resolved the SDR stability issues. It was running for over 24hrs solid
during IOTA, I'de call that stable!

I would recommend that a note be put into the N1MM+ manual in the
Spectrum Window -> SDRPlay section to advise the use of "Low IF"
if users are experiencing stability problems.

Many thanks once again to all those who helped!

Best regards,

Pat. (M0MGO)

--
Patrick Herborn <pat@...>