Hello Steve,

Thanks for your reply and remarks,

There is no doubt that a fair amount of the decoding problems is caused by too strong signals and other forms of distortion on the transmitting side. There is however mote to that I think.

On the decoding the following. The decoder can be seen as a processing block or function. This might not be true, but assuming
it is true, I think it is not not an efficient idea to send a certain
amount of work, some of interest, other not of interest or just
not belonging to be processed ( such as JT65, PSK, teletype or what else comes along.

The idea as implemented in the earlier versions of WSJT and WSPR-x
made all the sense in the world. 

The processing bloc has also limited capabilities in terms of available time and processing power so why overload or making it
hard on the processing?

By looking to the signals on the waterfall for example I can estimate being in a limited cases that certain signals are not going to be decoded. By using a by the user directed window to decode a signal
of interest problems can be avoided.

It could well be that a narrow window is being swept over a wide frequency range I believe that this is the case in effect, but the decoder is asked to process signals that may cause problems and an user can prevent that.

When running a CQ we have in most all cases an idea where the answer is going to come in frequency.

When answering a CQ, we know the frequency where we will transmit or 
close to at least. 

I am not saying here that a wide window is not useful but being able
to select between a mode matched narrow window and a wide window makes all the sense in the world.

So having the ability so direct signals or rather only one signal to the decoder makes all the sense in the world ( narrow mode matched
tol under control of user and wide band for search and monitoring )

Getting an idea whether the decoder is detecting syncs and how many
is also interesting to me even as no decode takes place, again
it could be made as a option for some ( I hope )

73 Rein W6SZ








--- In WSJTX@..., blitz716  wrote:
  

Rein,
I was watching some real strong signals not decode yesterday and found
reducing the gain setting in the wide window helped decode them. (I
usually have it at 3) Apparently a signal CAN be too strong for the
decoder to process. I also saw some seriously overloaded signals as
well, and they wouldn't decode either.

Important folks, watch your xmit signal does NOT trigger your ALC in any
way, the signal needs to be uncompressed, just below the point where the
ALC kicks in for best quality and thus best decode. Its been mentioned
before, and bears repeating.

I have also noted the long time-to-decode, as it bit me when a guy
replied to my CQ yesterday. The decode button was illuminated just fine,
but my auto-reply started without me seeing the results of his decode.
Perhaps this is a function of the decoder trying to decypher more than
one signal in the bandwidth its viewing? Im only venturing a guess on this.
I do however like the function that lets me see the entire bandwidth,
and if this IS the reason, I'm willing to wait the extra 2 minutes
before replying. However, lets remember this might be the case, and give
the guy the benefit of waiting that extra cycle before abandoning the
possibility of him returning. I had one guy do exactly that yesterday as
well, and tho I tried called him back multiple times, in response to him
answering my cq, he moved on before I could get back to him. Just a
couple points to ponder.
Steve KC2UK


Rein A wrote:
    

Hi All,

Let me first tell everyone how much I like the new JT9 mode.

I hope it will remain foremost a part of the premier WSJT weaksignal protocols.

My first interest in amateur radio is listening and monitoring weak signals.

As far as JT9-1, goes you can watch my receive results on PSK reporter virtually
7 x 24 mostly 20 m.

A very important point with the WSJT modes is the decoding process, in my case
the weak ones
in particular.

At times I see DX signals from here and there, all with < -20 dB. From that I
conclude
that there are no real big problems here in receiving ( RX settings, software,
antenna, noise etc etc )

In spite of that, my decode average is perhaps not higher than an estimated 75
percent at best.

First of all there are the signals, visible on the waterfall, but clearly too
weak.no problem.

Then there are the signals strong, but they just do not decode for unknown
reasons to me, at least.

A few versions ago signals with just syncs detected are not being shown any
longer. A big loss
in my opinion and perhaps, it could be made part of the options selectable.

Then there is the issue of time spent in decoding.

I see here cases where 3-4 signals , weak ones are decoded and displayed within
less than 10 seconds, marvellous


On the other hand there might be cases where just one, perhaps even strong
signal does not get
decoded while the decode cycles lasts and lasts even beyond 60 seconds.

As a general rule ( perhaps totally wrong ) I think if a signals does not get
decoded within
perhaps 3 seconds, there is a problem. Most likely it will not get decoded,
period.

Again from just observing not really knowing what is going on, it looks as if
the decoder
does not know how to process this situation and just decides "let it go, lost
cause"

I do not seem to be able to make this decision for the program, but would like
to be able
to finish the process in order to get ready for the next receive period. ( 60
secs )

I am not really sure how the process is, what the interaction is between the
data acquisition.
and the decoding, are they in series or in parallel or some combination?

As I am old fashioned, I do not mind at all, actually it is aprt of my joy in
amateur radio.
"to do things" while receiving. This has nothing to do with the use of computers
or
other means, tools, my interaction in receiving is a great part of the fun.

The wide band decoding ( formerly 500 Hz and above ) is very nice for unattended
monitoring
but I feel rightly or wrongly that it limits, under circumstances, the decoding.

So here again, I would like to see that as an option, wide band plus selected
narrow band and
narrow band only.

All these points, in my opinion on at least , play in the real world. Let me
give some examples:

- there are non JT9 signals in the passband ( deadly as far as decoding goes )
- there are real strong or over driven JT9 signals present often the same
results.
- there is a JT65 signal is the pass band ( quite often here ) ditto.
- there are JT9 transmission producing a screen full of dot shaped signals on
the waterfall,
do not know what is going on but I see it often

To illustrate some of these cases I include 5 files from last night where a JT65
signal
appeared and made the receiving disabled for 3 or 4 minutes.

http://www.nitehawk.com/w6sz/wspr_x/130412_1052.wav

http://www.nitehawk.com/w6sz/wspr_x/130412_1053.wav

http://www.nitehawk.com/w6sz/wspr_x/130412_1054.wav

http://www.nitehawk.com/w6sz/wspr_x/130412_1055.wav

http://www.nitehawk.com/w6sz/wspr_x/130412_1056.wav

When running these files the decoding does not seem to "hang" as long as getting
this off the air?

Tee idea is to hear some other opinions and perhaps getting the discussion going
on some more options.

73 Rein W6SZ











------------------------------------

Yahoo! Groups Links




      

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/WSJTX/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/WSJTX/join
    (Yahoo! ID required)

<*> To change settings via email:
    WSJTX-digest@... 
    WSJTX-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    WSJTX-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/