Print

[ZL1BBW]

Is there any where that it automatically logs all contacts?  I forgot to press log for a Dx ped and could really do with finding it  if possible.
Thanks

[AA4PB]

all.txt should have a record of your QSO.

[AK4YA]

Does anyone know the format of the CSV?  Most fields are easy to figure out except the SNR figures, cant tell which side in the CSV belongs to which side of the QSO.

[VA3VF]

Is there any where that it automatically logs all contacts?  I forgot to press log for a Dx ped and could really do with finding it  if possible.
Thanks

As AA4PB said, the data traffic, no a ham log per se, is all in the all.txt file. Open the file with your favorite text editor and do a search on the call sign. Make sure to check the time and confirm the 73. This is to ensure you see the good contact, not previous attempts that were not answered/completed.

[VA3VF]

Does anyone know the format of the CSV?  Most fields are easy to figure out except the SNR figures, cant tell which side in the CSV belongs to which side of the QSO.

Sorry, no idea of the CSV format.

As for the SNR, it's linked to the second call sign. Like this:

callsign1 callsign2  -10

The -10 was sent by callsign2.

Apologies if I misunderstood your question.

[K5PS]

Open the file with your favorite text editor and do a search on the call sign.

The ALL.txt file is typically enormous, and if you're using Windows the default .txt editor notepad or wordpad usually can't handle it. I'd recommend downloading and using notepad++ (if you don't already have it).

[ZL1BBW]

Thanks, if it wasnt 5V7 i probably wouldnt worry.

[ZL1BBW]

Thanks, found 3 exchange's of rpt, but nowhere a 73, they are all timed pretty closely so should be ok.

Thanks

[VA3VF]

Thanks, found 3 exchange's of rpt, but nowhere a 73, they are all timed pretty closely so should be ok.

If "pretty closely" is less than 30 minutes you should be ok. Still, write those down and check the online log tomorrow. If you want to go even 'deeper', assuming the contact is in the log, continue on to OQRS and enter the times to see which one was logged.

[ZL1BBW]

Thanks, found 3 exchange's of rpt, but nowhere a 73, they are all timed pretty closely so should be ok.

If "pretty closely" is less than 30 minutes you should be ok. Still, write those down and check the online log tomorrow. If you want to go even 'deeper', assuming the contact is in the log, continue on to OQRS and enter the times to see which one was logged.

All tidied up now, paid for and hopefully on their way.

Thanks to all.

[WO7R]

Does anyone know the format of the CSV?

I forget the details, but I reverse engineered it, especially the essentials of it, in about five minutes by simply paying attention to some QSOs I logged and then looking at the CSV.  It includes things like whatever you manually set for wattage.

There is also a kind of "shadow" ADIF file which actually has a little more information (STATION_CALLSIGN if you , for instance, share the machine with a contest call).  That, you might simply import somewhere.  But the CSV is fine for routine use.

[N1UK]

As an aside I like the fact that JTDX labels it's all.txt  files by the month which makes it so much quicker to load ie 202210_ALL.TXT


73 Mark N1UK

[WO7R]

To be more explicit about the CSV format:

Now, as for the basic "CSV" style log, there are two formats over time, but I think only the most recent has survived unless you're a die hard VHFer using the WSJT as opposed to WSJT-X.

The format I see in WSJT-X goes like this:

Date, UTC, DXCall, DXGrid, freq, Mode,report_sent,report_rec,power,comment

If it is the older format, then some of the first parameters are in a little different order and it is obvious from inspection which is which once you know the above is what the contents are.

If that's not enough and you want to reverse engineer the log for yourself, make up a phony QSO with unique values for the above and save it (you can manually delete it).  The log will then reveal itself to you whatever version of the code you have.

[WO7R]

The ALL.txt file is typically enormous, and if you're using Windows the default .txt editor notepad or wordpad usually can't handle it. I'd recommend downloading and using notepad++ (if you don't already have it).

I admit I divide my ALL.TXT over time to keep the processing time of that file sane.  It's a dumb bit of bookkeeping, but I recommend it -- anyone with rudimentary programming skills should be able to do this.  Then, when you search for something, you don't plow through "infinity and beyond" to get it.

Or else, once in a while, just take down WSJT-X, rename ALL.TXT to  (say)   ALL.2022-12-03.TX or some such.  The next time you start up WSJT-X, it will recreate a new ALL.TXT from the point.  If you want to find an old QSO, it's now a little more work, but it makes it a lot easier to do things like archive ALL.TXT to 'someplace else' which I like to do and it's why I break it up.  This has been a widely implemented logging strategy for years.  I wish WSJT-X had it built-in.  Another plus to JTDX for doing this.

However, setting that all aside, in 64 bit Windows, ordinary Notepad now handles some astonishingly large files -- 10s of megabytes at least.  It could probably handle a very large ALL.TXT these days; much more than it once did.

[W1VT]

Yes, I recently used Notepad with a large ALL.TXT and was surprised how well it worked.
I did have to be patient for it to load before I could do anything.