locked Re: JT-9 decoding
Rein,toggle quoted messageShow quoted text
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.
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 <*> 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/