On Tue, 23 Jul 2019 07:07:44 -0400
"Tom Wagner (N1MM)" <n1mmtomwagner@...> wrote:
Many thanks for your reply.
There is a bug on transmit. Try right-click reset radios to start itI 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 andApologies 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, youMany 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 spectrumRight, 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
In some configurations, I prevent the spectrum from displaying duringYes, 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), keyboardIndeed - those I could live without for now.
radio controlThat is possible with OmniRig :) SDRCV3 can do bidirectional rig
interaction (ie SDR tracks VFO, VFO tracks clicks in spectrum)
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 - N1MMMany thanks for your time, help and patience,
On 7/22/2019 9:11 PM, Patrick Herborn wrote:Evening All!
Patrick Herborn <pat@...>