[Moon-Net] IQ+ PREAMP GAIN NEEDED
Edward R Cole
kl7uw at acsalaska.net
Fri Nov 4 22:29:31 CET 2016
OK, hadn't considered the difference in input sampling rates used, so bad idea.
For guys like Serge who do not want to get into all the tech issues
of figuring out Linrad or installing and running all those instances,
I thought maybe I had an approach which would work.
As far as the averaging window, I ignore it. My contacts are based
on what shows in the main window.
MAP65 provides more info than I can take advantage of in a
contest. Often enough stations to work without use of deep search or
averaging. Often I am under a huge pileup keeping busy writing down
decoded calls and their DF. This exists outside contests, too.
On 6m & 23cm I'm often working skeds so MAP65 display is unnecessary.
Better decoding will be nice just like a bigger antenna would.
I would like to help Serge get his IQ+ working up to potential. It
should be at least equal to using an IC275.
It would only be better using a dual-pol array for input. But Serge
is satisfied with what he is using.
I feel I made a wise decision to buy x-yagis in the beginning. I was
lucky to have the funds available in 1998. Experience so much
faraday on 6m, waiting to see a signal. More gain will help but not
cure that. On 1296+ using CP eliminates polarity issues. One of the
factors in deciding to skip 432.
Some day when the dust settles that I have time to go back looking at
Linrad, your help would be welcomed.
reading the mail
At 12:33 PM 11/4/2016, Roger Rehr W3SZ wrote:
>Thanks for the note and the great comments. I have a couple of
>comments-on-your-comments that I think would be of general interest,
>which I interspersed below.
> > Its my understanding that one can record the soundcard audio stream
> > as a .wav file which you could then run on WSJT or MAP65, and compare
> > how well they decode. I am less concerned that the signal level
> > reported is the same, than that the decoding thresholds are
> > equal. (actually I am not that concerned as I have excellent
> > performance from MAP65 and WSJT10, both using the KV decoder.
>But there is no need to make such a recording. With the system which
>Alex and I use to compare MAP65 and WSJT, the real-time signals as they
>are received and sent to both programs are identical. There is no
>reason to make a recording to use for input.
>You might say that other stations that couldn't do the proper evaluation
>of MAP65 and WSJT in real-time as Alex and I did might want to make such
>a recording in order to evaluate their systems. But note that you can't
>use one recording to directly feed MAP65 and WSJT, as they have
>different input requirements. MAP65 requires as input a 96000 Hz
>sampling rate wideband signal, while WSJT requires a narrowband (2.4-5
>kHz wide) signal at 11025 Hz sampling rate. So if you made a single
>recording to feed to both, it would need to be a 96000 Hz sampling rate
>wideband signal that you fed into a Linrad master which you then used to
>send timf2 data to MAP65, and that same instance of Linrad would also
>have to produce processed audio reduced to a narrow band signal at 11025
>Hz sampling rate to feed WSJT. That would be essentially an identical
>system to what Alex and I use for our tests, but with a recorded
>wideband file instead of off the air signals used for input to Linrad.
>(Actually it would be slightly simplified, using the master Linrad to
>produce the audio signal for WSJT instead of using a slave Linrad to
>feed multiple WSJT instances). So if the station had the capability of
>doing the experiment with a recorded file, that station could have also
>done it in real-time.
> > I am a little surprised that WSJT-X is usable for eme; my take was
> > that it was designed for HF?
>I was experimentally using a WSJT-X development version (v 1.7.0-rc1
>r7219). As an example of how this looked during the EME contest, I have
>put a screen grab taken by me during the first leg of the ARRL 2016 EME
>You will see 5 instances of WSJT-X running as well as MAP65 (and a few
>other, irrelevant-to-this-discussion programs).
>WSJT-X worked well for me during the contest with two caveats.
>The first caveat is simply that I did not use WSJT-X for transmitting at
>all, because MAP65 took care of that. So I can't report on the transmit
>function of WSJT-X.
>The second caveat is that there was some interesting behavior (with me
>using both averaging and Deep Search simultaneously) where, once WSJT-X
>had "decoded"/produced a message, the "Average Decodes" window would
>sometimes continue to show that decode recurring as a new message with
>new time stamps, sequence after sequence, even though I had in fact
>changed frequency and there was no possibility of my continuing to
>receive that message. This is just another example of the fact that
>operator attention and intervention are necessary when using the WSJT
>modes, as with any other mode of operation. I mention it here only
>because the frequency of such messages requiring "operator attention"
>was much greater than I was used to seeing with WSJT or earlier versions
>of WSJT-X without this averaging. An example of this issue is seen on
>this screen grab:
>I had completed working EI4DQ at 1340 and I changed frequency
>immediately after that (he was at 144.117). I worked K3RWR, completing
>at 1400 on 144.135 and K1JT, completing at 1409 on 144.108. So I was
>NOT receiving ON 144.117 after 1340, and there was no way any instances
>of WSJT-X could receive signals from EI4DQ after 1340. But if you look
>at WSJT-X-135 you will see in the "Average Decodes" window apparent new
>decodes of EI4DQ at 1342, 1345, 1348, 1353, and 1403. And if you look
>at WSJT-X-Elecraft, you will see in the "Average Decodes" window new
>decodes of EI4DQ at 1342, 1344, 1348, 1353, 1357, 1400, 1402, and 1403.
>During some of these periods I was transmitting, and in none of these
>periods was either my WSE Linrad receiver or my Elecraft receiver on
>EI4DQ's frequency. Some of these "decodes" of EI4DQ were during odd
>periods, and I believe that during this time he was only transmitting
>during even periods. So there is no possibility that these were real
>decodes. You can see other examples of messages from other stations
>appearing in the "Average Decodes" window that also occurred across a
>time span during which I hopped through multiple receive frequencies,
>often without transmitting, so that there is no way that these stations
>would have been similarly frequency hopping following my receiver from
>frequency to frequency, and no way that these messages were "real". I
>tried using "Erase" and "Clear Avg" to stop these repeating messages,
>but that did not seem to stop it in every case. I believe that the "d#"
>designation for the "Average Decodes" messages in question indicates
>that they are a product of deep search, and the numeral indicates the
>depth of the search required to produce the message. And I also believe
>that the "f#" designation means that the FT decoder produced the
>message. But I do not know any of that for certain. My memory is that
>this phenomenon was not limited to "deep search" messages, but my
>recollection on that point may be faulty, and in this screen grab the
>false messages are limited to messages with the "d#" designation.
>It is quite possible that this interesting behavior is due to lack of
>knowledge or user error on my part. It could also be that it was an
>issue in the version of WSJT-X devel that I used and which has since
>been corrected. WSJT-X development is now well beyond the version of
>WSJT-X that I used. It may well be that this is just another example of
>why some user attention/intervention is still important with the WSJT
>modes as it is with any other mode, as has been pointed out so many
>times to us simple users by the experts. But I mention this interesting
>behavior here so that anyone who is experimenting with a pre-release
>version of WSJT-X during the next leg of the contest knows that they
>might see this behavior. There are two bottom lines here: User
>attention and intervention are necessary with any mode of operation, and
>the WSJT modes are no exception. And don't necessarily believe it if
>WSJT-X tells you that another station is following you up and down the
>band trying to work you as you "search and pounce" on other stations who
>are calling CQ. :)
> > Yes, keep comparisons for same decoding sw.
>No, I disagree on this one. The appropriate objective now is to see how
>the currently available version of MAP65 compares with the best
>available alternative, and that means comparing (MAP65 with the KV
>decoder) with (WSJT-X with the FT decoder). Again, the comparison of
>(MAP65 with the KV decoder) and (WSJT with the KV decoder) has already
>been done with data including huge numbers of decodes by both Alex and
>me. There is no reason to repeat those experiments with what is a
>soon-to-be-obsolete piece of software (WSJT) in order to show the same
>result yet again when that result is clear and already 4 years old. But
>a comparison between (WSJT-X using the Franke-Taylor) decoder and (MAP65
>with the KV decoder) is a useful comparison to make, because those
>programs are what people will be using until MAP65 gets the new
>decoder. When there is a version of MAP65 with the FT decoder available
>to us, then comparing MAP65-FT to WSJT-X-FT will be appropriate, and I
>am sure that several of us will be doing that comparison at that time.
> > That will be another topic. Be interested to read about and try using.
>Thanks! I hope that that there will be an opportunity to do that soon!
>But the WSJT-X / MAP65 developers have quite a lot on their collective
>plate at this time, so I am not holding my breath. It will come when it
>does and we can all enjoy the great gifts that the developers have
>already given us until then.
>Thanks again for the great comments, Ed, and
>Moon-Net posting and subscription instructions are at
>No virus found in this message.
>Checked by AVG - www.avg.com
>Version: 2015.0.6201 / Virus Database: 4664/13347 - Release Date: 11/04/16
73, Ed - KL7UW
"Kits made by KL7UW"
Dubus Mag Business e-mail:
dubususa at gmail.com
More information about the Moon-net