On Mon, 15 Jul 2019 14:34:14 -0500
"Chuck Dietz" <w5prChuck@...> wrote:
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 :)
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
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,
Patrick Herborn <pat@...>
Patrick Herborn <pat@...>