It will show that the so called Deep Search mode is not a deep search, it is solely a reconstruction module, designed to recreate a fully known message.

How can we say this after reading the articles?

Well, this is because mathematics can be used to determine the possible data transfer at a given S/N ratio. Klaus makes it clear that at –27db only one call is possible to transfer in 60 seconds.

JT65 Deep Search "copies" two calls, locator and report in 48 seconds…!! This is only possible by "doping" the decoding process with the missing bits, which is exactly what K1JT is doing. Actually, doping is done to the extent that the message received via the airwaves is a fraction of the printed message on the computer screen. Take away the known info from the computer (calls + locator) and a decode is totally impossible.

We all know what we call doping in sport arenas... yes... cheating!

JT65 "Deep Search" is probably the biggest con (bluff) in the history of ham radio.

Please read the article, it reveals the true state of JT65, and clears up the smoke screens that K1JT has provided us with.

Added information about the recent Dubus article by DJ5HG showing how JT65 is using very little information (14 bits) to produce full calls, locator and report when the Deep Search (DS) mode is used. I also added some new statements from K1JT explaining how the Deep Search mode uses known information to print EME messages on the screen. Furthermore there is more information on Short Hand messages presented in the text below. For those of you who have visited my webpage before, the added new information is presented with a "New!" marker.

This again tells us that this is not a protocol designed to dig in the noise for weak radio signals, instead it looks for fragments that can be matched to known information present on the computer only.

In my eyes this invalidates JT65 contacts at S/N levels around –25 db or lower when comparing them to long established standards in the radio amateur world.

First, why am I,

SM2CEW Peter Sundberg doing this?

Well, to make a long story short, when a new communications protocol is to be launched there are certainly some requirements that need to be fulfilled to make it compatible with long established amateur radio standards.

In my opinion WSJT/JT65 is not in all ways complying with these standards, despite what the operator can see printed on the screen. The decoding is heavily relying on known data that is injected via a database or input boxes in the program user interface. In effect, the program creates (K1JT uses the terminology "reconstructs") data that it has not received over the airwaves by making use if the available known data on the computer. In my opinion this is not a good protocol, and it lacks some of the basic functions to enable an amateur radio QSO where all information is transferred via the airwaves at all times.

K1JT has in this way decided to set his own standards, and thereby in my eyes unfortunately invented a program that heavily relies on known information. As the program is not "random friendly" i e , people have a hard time finding each other on the bands, the use of real time liaison or continous spotting of ones presence is heavily relied on. This has lead to the fact that random operation, with many unknown parameters, is not a common way of operating any more. Therefore digital EME QSO's are no longer treated as the big achievements moonbounce contacts once were, and some people judge these contacts as being of less value, instead they treat them as Internet or Cluster QSO's. And so do many CW operators. This is very unfortunate.

To understand what I am talking about on this page one has to be familiar with the WSJT software package developed by K1JT. For more info on this check

It took me a while after JT65 was released until I realised what was possibly going on. As I stated above, in my opinion this piece of software

lack some properties that a secure communication protocol should have. Why is this you ask yourself.

I would say that the reason is that without injecting known information to the decoding process the computer program appears not to be much better at copying weak signals than a good CW operator. And by injecting known information to the decoding process the need for a full message to be transferred via the airwaves is perhaps no longer needed.

If you read on you will see that this is verified by tests performed by Joe Taylor, showing that unknown text messages can only be copied down to -20db S/N. We who have used the program know that we clearly hear the JT65 FSK tones in the receiver when the program reports -20db S/N. However, to copy weaker signals, the computer apparently needs to know what it has to decode, and it reconstructs the missing pieces withouth having received them.

NEW! A recent article in Dubus Magazine by DJ5HG http://dubus.ns.km1708.keymachine.de/DJ5HG.pdf shows that JT65 in Deep search mode only needs to copy equivalent to 2 characters (10 bits) to print full calls, locator and report. The rest of the information is reproduced from the database (CALL3.TXT file) in the harddrive of the computer. Or in case of a scheduled contact, the information is available in the MyCall and To Radio input boxes. Scroll down for latest update and information on how contacts made with JT65 in my opinion should be treated as invalid.

One of my concerns is that so called shorthand messages have entered the scene. They are used to complete the contact, but instead of the program detecting them and decoding them, the operator can watch a waterfall display and look for a tone frequency separation to do it.

There are many unsuccessfull CW contacts over the years that I could have completed if I only would have had to detect the presence of the other station.. and not having to figure out what he was sending back to me. But for me, and so many others, the challenge was just trying to figure out what the other guy was sending. In JT65, detecting the presence of two tones is apparently enough to call it a complete contact.

NEW ! Please read the paragraph below about Short Hand messages for the latest statements from K1JT on the matter.

K1JT has chosen to present a S/N-reading based on SSB bandwidth instead of using the very narrow bandwidth that the software uses to decode the tones. This has given JT65 a reputation of being far superior to other communication protocols, but as you will see in the text below, JT65 appears to only be able to copy totally unknown text messages down to –20db S/N. A level where a good CW operator is also able to copy random text messages.

But how correct are these numbers, and why reference them to a bandwidth that is clearly not used? More on that further down the page.

Here are some topics about JT65 that I would like to address.

Decoding

This is a statement from K1JT about the integrity of WSJT decodes:

1. Do not check "Aggressive decoding".2. Set the "Sync" threshold higher.3. Delete or rename the CALL3.TXT file.4. Pay attention to your interference environment and to the manyforms of numerical and graphical information provided to theoperator, and get involved in the decision process yourself.5. Never believe a questionable decoded callsign until you have seen it twice.Item #5 is absolutely foolproof. Mnemonic: "If in doubt, throw itout. See it twice? Then it's nice."

I did some testing of JT65 with WSJT 4.9.7 after Joe made these statements..First line is decoding the OH7PI file that is distributed with WSJT using K1RQG as the home call. The second and third line is the very same file decoded again, this time the home call in WSJT is changed to G4RGK...

Same file, distributed with the program, different decodes. K1JT tell us that this paragraph above has no relevance because it is referring to an old outdated version. The version 4.9.7 is however presently used by a number of people around the world, including a recent DX-expedition, and most people are unaware of the existing functionality. After some of us pointed it out, Joe Taylor submitted this interesting information to G4RGK to put on his website:

"WSJT 4.9.7 had a coding error. In a very limited set of circumstances, the error could cause an internally correct decoding of a transmission around -23 dB to be suppressed and "overruled" by a low-confidence result from the deep search decoder. The user would see only the incorrect result. Everyone who used WSJT 4.9.7 had this same problem, but different entries as "My Call" would generate false decodes with different received data files. Your call and some others would make it occur with the OH7PI file. My call would generate errors with different wave files. Using WSJT 4.9.7, any call sign will generate these low-confidence false decodes occasionally."

Have a look at a few different calls decoded from the supplied test file.

Do not use 4.9.7 !

The file "call3.txt" injecting known data to the decoding process

K1JT states the following:

"CALL3.TXT is nothing more than a list of active VHF/UHF stations. Ido not maintain the list. It is not a part of WSJT. A copy isdistributed with the WSJT installation package simply as aconvenience for new users. Nearly every active WSJT user maintainshis or her own version of the list."

Earlier version of WSJT crashes if you don't have a CALL3.TXT file. The program depends on it being there. Default install will place a CALL3.TXT file on in the WSJT folder, and the program will use it.

Checking the version 5.9.3

I did some testing with the late version WSJT 5.9.3 and one of the sample .wav files supplied on the download page. The install was exactly as the Install Wizard suggested, and to be sure I had no settings wrong I deleted the WSJT.INI file (as suggested by K1JT) and restarted the program with default settings. I found some interesting results. I have been accused of "mis-using" the software to get these decodes, but you can rest assured I have made an ordinary install, and as mentioned above used default settings as any user would do running the program for the first time. What is shown here, regardless of settings, is that the program is using known data in the process of decoding, why else would changes in a text file show up as decoded text.

To do my testing I chose the IK1UWL WAV-file, because this one is said to decode a weak JT65 EME signal. First of all, to even get a decode I had to put in K1JT as home call. If K1JT's call is not there as My call the file won't produce anything on the screen. When I put in Joes call the decode now looks like this:

163600 2 -26 2.5 221 4 # K1JT IK1UWL JN33 OOO

I then started looking at the CALL3.TXT file, and changed IK1UWL's call to IK1UW. No decode.

So I changed the call back to IK1UWL in the CALL3.TXT file, but now I also changed the locator JN33 to JP33. No decode!

I then changed back to the correct locator in the CALL3.TXT file, but instead of using capital letters JN33 I wrote Jn33, making the N a lower case "n". This is the decode I now get from the supplied sample file:

163600 2 -26 2.5 221 4 # K1JT IK1UWL Jn33 OOO

The program is reading the CALL3.TXT at all times to come up with information. It even uses the formatting from the file. It is obvious that the program is NOT decoding received information properly. It is looking for something that to some degree resembles what is known via the database and/or My Call and prints the information as it is available elsewhere!! In this example it is my assumption that the locator is not being decoded via the received weak signal, it is injected, or "reconstructed" as it is linked to the call via the database.

If I change IK1UWL to IK1UWl in the CALL3.TXT file the decode looks like this, it directly picks up the lower case "l" instead.

163600 2 -26 2.5 221 4 # K1JT IK1UWl Jn33 OOO

I changed IK1UWL's call to IK1UWLE in the CALL3.TXT file... have a good look at the decode.

163600 2 -26 2.5 221 4 # K1JT IK1UWLE Jn33 OOO

The decode is now producing a call, that only exists in the CALL3.TXT. The program does not flag it as a low confidence decode, so the to the operator there is no indication that this call was not received via the air waves. Remember, we are still using the supplied sample file from K1JT that he recorded off the air. I am not calling it a fake decode, but it is clearly not a genuine decode.

More examples of JT65 using known information to produce "genuine" decodes. This is from the WSJT tutorial, last paragraph. It's about using the sample file labeled DL7UAE that has two stations calling K1JT. I have underlined the interesting bits of information

"Hit F2 to open the Setup -> Options screen and enter your own call (or someother call) in place of K1JT in the "My Call" box. Then dismiss the Options screen and try to decode the SP6GWB signal again. Youwill surely fail, because for this message successful copy was obtained as aresult from the Deep Search decoder.

(Callsigns in the CALL3.TXT database are paired up with CQ and with the"MyCall" entry, encoded, and compared with the received information. If thesignals match to within a specified minimum confidence level, the matchingmessage is displayed.) If no good match is found, there is a small chance thatyou will see a low-confidence false decode. It will usually be flagged with a"?" mark to remind you to exercise your own judgment, based on signalstrength, sync level, displayed graphical information and your accumulated JT65experience, as to whether the message can be accepted as valid."

Well, following exactly this tutorial, using version 5.9.3, SP6GWB can beSP6GWBE, SP6GWBERT or anything I put in the CALL3.TXT file. Full confidencedecode, no flags attached.

(first line is the decode without changing the CALL3.TXT information, 2nd and3rd are decoded after I altered the SP6GWB entry in the file)

And, changing any of the known information as locator or home call produces a "no decode".. It's all about the "specified minimum confidence level" that the decoder is using, and it is unfortunately not set high enough to produce 100% reliable decodes. There is however no way for the operator to know this.

Conclusion:

It is obvious

that the program is using the information in the CALL3.TXT file or the information in the "My Call" or "To Radio" boxes to help reproduce data that was not received. This data was not received over the air, and the level of injected data to enable "recovery" is only known to K1JT.

As you will see below, a statement from K1JT tells us that JT65 is only capable of decoding unknown text to a level of -20db S/N. Again, this is basically the same S/N limit as a good EME operator needs to copy weak CW.

Now then, we have to ask ourselves a few relevant questions:

Why would a program have to inject known data to come up with the information needed to complete a QSO?

Why would a program need to have all the information present on the hard drive and in the computer RAM to be able to "decode" it?

Why are decodes that are apparently false not flagged as low confidence decodes in the program?

And if I, as some accuse me of, "mis-use" the program by using default, or as the program tells me "Normal" decoding methods in the IK1UWL example, why is the program setup this way then? Why not just provide one level of decoding, and make that one foolproof. One would think that the "Normal" setting means highest confidence level achievable, or?

And in the SP6GWB example (that was carried out by me "by the book") Joe Taylor specifically says that the information will not be decoded unless his call is in the My Call box. And he clearly explains that the program pair up his call with calls in the CALL3.TXT database to be able to decode. Again, why not let the decoder do the work by decoding only what it has received? Now text added to the call show up as full confidence decodes.

The info above raises the questions if JT65 is designed to perform better by giving up the need for receiving all needed information via the airwaves.

My tests have showed that there is no way to decode the sample file unless all the information is available on the computer. This would also be the reason for why the people who are using the program hang out on loggers, it is a good way to present the program with all needed information and put it in the computer RAM.

People then argue with me that random QSO's are made all the time with JT65. Well read on and I will show you why that is. It has to do with signal levels, and when they are good enough random works. Just like with CW. But as soon as the JT65 "deep search decoder" is being used known information is injected to the decoding process, else the program fails. During these contacts, unfortunately, the decoder has been given all information to "reproduce" the missing bits not received and the "truly remarkable EME QSO's" are not so remarkable.

At the bottom of this page you will find another example of how people have to inject known data when monitoring JT65B beacons to make use of the "deep search decoder". This time it is Bernd, DF2ZC who is handing out instructions. To me it looks rather obvious that by following the advice, presenting known information in the right places (i e MyCall and call3.txt), very little information is required to be picked up via the radio path. I do not understand why monitoring beacons this way is interesting, because it indicates very little about factual radio conditions. Fragments received are presented as full, genuine, decodes.

" At the JT65 Deep Search only the equivalent of two characters from the call sign or locator is necessary for decoding"

In effect, what he is saying in his Dubus article is that only two characters need to be decoded to print full EME messages containing more characters, for example

"DJ5HG SM2CEW KP15 OOO"

It should be noted that DJ5HG says two characters from the call OR the locator (which is also a part of the database). So linking a callsign to your own call might even have been done by using the locator information in the database. If so, no information necessary for a true EME contact has been passed via the airwaves.

In JT65 it appears that receiving "EW" is enough to say both calls, locator and report have been received.

"Minimum QSO: The definition of a minimum valid QSO is that both stations have copied all of the following:

1. Both callsigns from the other station"

As an example of how JT65 is presenting information only when it is know, take a look at the following information from K7XQ. It is an interesting report he published on Moon-Net, that in my eyes show us that JT65 is not capable of copying full calls at low signal levels, an therefore contacts made using the DS decoder should be treated as invalid.

"Last week I completed my small 2 x 7 element 6 meter EME station.

Before I worried about the transmit side, I wanted to test the receive sidesince this half of the station is complete. Acouple of nights ago, I saw that K7AD was on and willing to transmit via EME some test signals to see if I can receive anything off the moon on my end.

He began by calling me, "K7XQ K7AD ". I was in monitor only mode and DID NOT enter his callsign and/or grid in the call boxes. I assumed that any signal I receive would be "random" and I would be able to copy him no matter what text he sent.

His transmission continued for 30 minutes and I received over 9 transmissions of syncs between -30 and -22 db but absolutely no text was decoded.

Just about the time that I told him that I didn't copy anything from him, I proceeded to enter his callsign and grid in the box and from that point on, I began getting full text decoded on the screen.

I then went back to retrieve the wavefiles that contained only syncs and LO and BEHOLD, I got full text decodes from those wavefile sequences.

The question is how do I know if the program copies only partial calls and then the program proceeds to " fills in the missing blanks " based on a lookup table?

The other question I have is since the program knows who I am, how can I prove that the program needs to copy my calls from the station calling me to display full calls on the screen ???"

Good questions from Jeff K7XQ that surely more people in the EME community would like to see answered.

In the February 2005 edition of the 432 and above EME Newsletter from K2UYH K1JT states the following regarding JT65 and it's users:

"To maintain consistency with other EME practice, these hardy souls use exactly the same long-established criteria for what constitutes a valid QSO."

Of course, this is not true by any means, and K1JT is making his own interpretation of how QSO's are to be made, effectively trying to justify his invalid protocol.

Conclusion: It is obvious to me that decoding two characters and then adding known information via the local computer database is not in any way compatible with present EME QSO requirements.

I would not hesitate to say that QSO’s made with the Deep Seach (DS) module in JT65 are invalid with respect to any existing QSO requirement.

It is therefore sad to note that recent reports of completing DXCC on VHF/UHF depend on a communication protocol that doesn't live up to the minimum requirement for EME QSO's, or any amateur QSO's for that matter.

Shorthand messages

K1JT states the following:

"

The decoder knows what the shorthand message structure is supposed tobe -- tone separation and alternation period -- and it looks forsomething that matches one of these."

This is where corners are cut in this communication protocol. The program detects the tone separation, or establishes that one tone switches on/off at a rate of about 1.5 seconds, then it prints the shorthand message.

Joe carries on, stating:

"I have spent much more time on the full-length decoder than the shorthand decoder, which can almostcertainly be improved. I can usually do it myself by eye, if necessary, from the WSJT waterfall display or from Spectran."

Furthermore, in his Powerpoint presentation at the EME conference in 2004 about the source code of the JT65 protocol:

Using "Shorthand tricks for OOO, RO, RRR, 73", and "Shorthand messages are not very robust"

Let me give you an example to make it easier to get my point:

Shorthand messages are decoded only based on the tone spacing, it doesn't matter how these tones switch on/off. This is verified by Joe to be true.

So, when JT65 prints "RO", "RRR" or "73" and the average EME'er thinks that the program has decoded these characters. This is not true, it prints them on the screen when a certain tone spacing is confirmed and no coding is involved.

Actually, instead or "RO" K1JT could have decided to print this message on the screen:

"The computer has now verified that it has detected two tones at XX Hz spacing, and you can proceed by activating TX message #3"

Remember, no message was transferred so there is nothing to decode. Therefore it would be more convenient to help the operator by giving him robust instructions how to proceed.

But, had he done that, people would have said;

All that info can't have been transferred, the computer was just detecting the spacing of two tones.. right?

The answer is yes. The shorthand message is no "message". Code for RO, RRR or 73 is not transferred over the air. There is no FEC (Forward Errror Control) at all involved, and we are actually seeing the absolute minimum amount of FSK coding, i e tone spacing without need to find out their on/off pattern.

K1JT states the following, diminishing the necessity for a report during a QSO to a trivial message (!):

"The shorthand messages in JT65, which can be easily decoded by eye or ear, convey just a few "bits" of information. (Is RO being sent? Is RRR being sent? Is 73 being sent? Yes/No on each possibility.) Two bits actually suffice; that's all the information needed to convey the sense of these almost-trivial messages."

As we see, K1JT is defending his protocol saying it complies with the present rules for a valid EME contact. I say it does not. So, instead of the CPU actually decoding RO, RRR or 73 the operator can look at the tone separation on a waterfall display and say "Complete QSO!!". As K1JT says, this is not a robust communication protocol, two bits transferred, and no way to check that it is correct is not enough.

However, we understand why he chose to use them. Check this out, info from K1JT:

"Careful measurements on single transmissions with JT65 show thatits messages are decoded reliably yielding 100% copy at thefollowing approximate signal levels in a 2500 Hz bandwidth:

The table clearly shows that a "genuine" decode of known information needs -22dB S/N, unknown text needs -20dB (about 1 dB better than the old JT44) and the tone separation shorthand message yields a good -28dB...

Conclusion: For shorthand messages the software is not decoding information, it is looking for a tone separation or a tone on/off rate of about 1.5 seconds. This is why messages can be "decoded" at very low S/N levels. The program has a function so it also knowns when to expect a shorthand message, therefore making it even more easy to detect it, and not to confuse the decoder.

In my opinion, this in no way fulfills the requirement of "exchange of unknown information" that the current EME protocol requires. I am hopeful, given what K1JT has told us about the shorthand messages, that future versions will correct this.

Signal reports

Those remarkable S/N values that the program is presenting, how accurate are they?

First of all, they are averaged over the full receive period. EME signals suffer from QSB, and the CW operator normally uses peaks to copy the information needed. So does JT65.

In the CW/SSB world we normally say "You were peaking RST 519"!

K1JT has chosen to talk about an average signal level, which by definition is always going to be lower that the peak value that the program uses to copy the message.

Somehow this looks suspiciously like marketing.

Remember the shorthand message detection where the program would need ONE short peak to establish that there are two tones at an expected spacing. If you then average the signal level to S/N reports of -30dB you surely amaze the operator.

And t

he program would not need much more to confirm that two known callsigns are being received as it can make use of known data to reproduce what is missing. Remember, unknown info needs -20dB S/N to be properly decoded.

Levels lower than that rely on signal peaks, and known data.

K1JT admits:

"The FEC code used by JT65 is a low-rate code (r = 12/63) and consequentlyit, too, benefits greatly from an ability to "copy on the QSB peaks"."

VK7MO Rex writes:

While the majority of stations are stable to within a few Hz quite a few drift 20 Hz or more. Whilethe AFC on WSJT can follow this on a strong signal - those who drift should be aware that they aregiving up the last few dB of performance(signal reports are misleading in measuring performance asa drifting signal may decode at -30 dB when its real level is -20 dB).

Conclusion: S/N reports in JT65 are chosen to be displayed in a totally different way than what we are used to see. In my opinion this makes it difficult to establish whether one would have been able to copy a CW signal at the same reported level, because for CW we never talk about average strength. Instead we make use of peaks, and clearly, so does JT65. The bandwidth used to deliver S/N reports in no way reflects the bandwidth at which the tones in JT65 are decoded (4.7Hz). Why this method was chosen I have no idea. My suggestion is to also add "Peak" value to the signal reports. This would be very interesting information for both operators as it will give a better indication of what signal levels can be achieved.

"Transmit sensitivity"

K1JT states regarding the call3.txt and the deep search feature:

"As you know, this will provide about 4 dB more sensitivity, both

transmitting and receiving, for DXpeditions that need to use an extraDXCC prefix or portable suffix."

Conclusion: T

o put it in context, it can only mean that the unknown is given up and information is injected to the decoding process to reproduce the parts that were never received. This part of the decoding process is the one I am not comfortable with.

Coding/decoding of characters

The decoding process makes use of known information and K1JT has provided hard coded prefixes in the software. This might be a problem if a new, unknown special prefix is to be decoded. Special formatting is needed for the information to be transferred, else the decoding proces can only manage 13 unknown characters at -20db S/N. So the extra sensitivity can not be used unless the prefix is known.

Operating hints!

G4RGK has a helpful site where some of the problems of JT65 are explained. .

Some Moon-Net historyThis is how it all started, with me putting a question on the Moon-net reflector:

8 April 2004 I listened to the 3B9C expedition on 432 MHz calling on JT65B and when theprogram showed -27db I was hearing them fine on my loudspeaker. Then aftera while when they switched to CW they were good copy and we had a completecontact. I had no trouble hearing the JT65b tones reported at -27db whilelistening in SSB BW.

73/Peter SM2CEW

And the reply from K1JT>However, I cannot let stand without comment your claims that seem>to be saying that with good enough operators, CW can work>effectively at the same signal levels as JT65.

This was the first time someone had questioned JT65, and in this case I questioned the signal levels reported. Everything was based on a genuine experience where 3B9C first where on JT65 and then a few minutes later switched to CW. If you look at K1JT's reply, there is no question whether his software is presenting the wrong numbers, it is my ability tocopy CW at low levels that is questioned! This debate went on for a long time, and turned more into a CW vs Digital rather than the initial S/N issue that I addressed.

Next issue, the short hand messages:

20 June 2004 Today I listened to SV/DL2NUD running JT65 with DJ9YW on 23cm.SV/DL2NUD was fine copy here, even though he was only using 2 yagis and350w, good signal in the loudspeaker at -20 db reported in JT65.

Anyhow, for the first time (I haven't worked any QSO's using JT65 mode) Irealized what shorthand messages are, I have never really thought about it.At the risk of starting another lengthy debate I must say that I have ahard time finding that just two tones at fixed frequencies wiggling backand forth at a rate of about 1.5 seconds constituting an EME message. Nowonder those "messages" can be detected at low levels, it was very easy tohear just by ear what was going on.

I know should not start this debate again, but this was a new discovery tome (exactly, I have NOT read the manual before) and now it is even moreclear to me that we should not compare cw achievements with JT65.

73/Peter SM2CEW

This is what someone, I won't say who, sent first of all: 21 June 2004 >If you want to behave like an ostrich, or tyranosaurus rex, for that matter,>that's entirely up to you, but please stop sniping at those of us who like>to explore contemporary technology. FWIW. I'm not very impressed by big>antennas or illegal power. I prefer sophistication to brute force... Any fool can>build a big amplifier using obsolete tube technology, or a big antenna from>published data, or both... (many do!)

K1JT wrote this in one of his emails on the subject: 21 June 2004 >I (and many other hams who have adopted more modern coding and>modulation methods for doing EME) have little hope of outscoring>you in an EME contest, whatever modes we may use. It will be a>very long time before we catch up to you in initials, if ever -->and if we bother to keep count.>>For these and other philosophical reasons, I have little direct>interest in your all-important comparisons and the establishment>of "classes".>>With that said, I would be extremely disappointed if the ARRL or>any other forward-looking organization interested in the good of>Amateur Radio were to introduce arbitrary distinctions in their>programs (contests, awards, ...) that would have the effect of>belittling accomplishments of those who use technical innovations>to "do more with less."

JT65 Beacon monitoring

This is a message from DF2ZC on the Meteorscatter reflector, posted on 6 March 2006.

Again, when the program is not performing better than CW, Bernd advises us of the necessity

to inject known data so the fragments received can be presented as genuine decodes.

Hello All,

Though it is a little off topic it might still be interesting to many...

As some of us have already learned the well-known 144 MHz beacon GB3VHF(JO01DH) is now the first - at least to my knowledge - beacon which alsotransmits in JT65B mode. Every even minute (corresponding to having ticked"tx First" in the WSJT JT65B subroutine window) the beacon transmits"GB3VHF JO01DH". In the odd minutes it transmits the same message in plainold A1A.

This gives a wonderful opportunity to monitor the beacon signal even if oneis not in shack: By tuning in on 144.42860 MHz in SSB mode (CW carrier is on144.430 MHz in CW mode), untick the "tx First" in the WSJT program, press"F3" for Mute and then let the software run and decode the beacon signal.

Since the message text "GB3VHF JO01DH" does not match the messageconventions for the deep search mode in JT65B the additional dBs sensitivityare wasted. This is particularly unfortunate for hams wanting to do somelong distance beacon monitoring, not just 500 km like from here.

However, there is a way out to force the software to use the deep searchdecoder, because one could also regard JO01DH also as a callsign:

(1) Set your own callsign to GB3VHF in WSJT options(2) Set "JO01DH" as TO-Callsign (you can even use JO01DH als as JO01DH'slocator)(3) Store this unusual callsign JO01DH from JO01DH in calls3.txt

The turn your antenna to the beacon location and start running muted tx 2nd.It will work.

Good luck in beacon monitoring. And have fun with the statistic work andgraphic display later.