Date   

locked Error message Adif

sidney7539
 

Hi,
      I have been using jt alert for some time associated with qso relay to input into hrd logbook. Recently I found that jt alert was not working. I downloaded the latest version and installed. Now whenever I launch jt alert I get an error message, as shown below. Uninstalling and re-installing all programs has no effect. Running virus checks and other PC tools does not improve matters. I can still use jt alert to select calls ect. But after a qso it will not transfer the qso to hrd logbook. I am using win10.
Can anyone advise me on this please. Many thanks for taking the time to read this.
Regards,
Sid.


locked Re: File header <EOH> in lastqso.adi

Tom Ramberg, OH6VDA
 

That´s very possible. But then N1MM+ isn't conformant either, I couldn't care less about that, I'm just trying to solve a minor problem, and inserting <EOH> at the start of the file solved it both in N1MM+ and in Swisslog. Thanks for your kind assistance.
--
73 de Tom OH6VDA


locked Re: File header <EOH> in lastqso.adi

Larry Knain
 

The ADIF spec does not require a header be present which would mean Swisslog is not conformant with the ADIF spec. The ADIF spec has been that way for several years.


From the ADIF 3.0.6 spec:

IV.A.2. ADI File Structure

An ADI file begins with an optional Header followed by one or more Records:

Header
Record
Record
...
Record

73, Larry W6NWS


On 11/3/2018 9:17 AM, Tom Ramberg via Groups.Io wrote:
It happens from time to time that my logger doesn't log a qso properly, and the easiest way to handle it is just importing the lastqso.adi file.

My logger (Swisslog for Windows) won't import unless there is a file header, so I have to add a first line:
<EOH>. 
I have also noticed the same when using N1MM+.

Is it possible to get that inserted  by JTAlert?

73 de Tom OH6VDA
Sendt fra min iPad Air 2

--
73 de Tom OH6VDA


locked File header <EOH> in lastqso.adi

Tom Ramberg, OH6VDA
 

It happens from time to time that my logger doesn't log a qso properly, and the easiest way to handle it is just importing the lastqso.adi file.

My logger (Swisslog for Windows) won't import unless there is a file header, so I have to add a first line:
<EOH>. 
I have also noticed the same when using N1MM+.

Is it possible to get that inserted  by JTAlert?

73 de Tom OH6VDA
Sendt fra min iPad Air 2

--
73 de Tom OH6VDA


locked Re: Worked B4 not shown as such

HamApps Support (VK3AMA)
 

On 3/11/2018 10:43 PM, HamApps Support (VK3AMA) wrote:
On 3/11/2018 10:19 PM, k2rrv@... wrote:
I just helped a friend (K2BY) upgrade WSJT-X 1.9.1 AOK! Then we updated JTAlert to 2.12.6 and he now gets  adiFLmport: Error on startup. I rebuilt Scan Log still NG. No B4 info etc. I can't imagine operating FT8 without all the vital info we take for granted when everything is working right. Thanks Laurie and team!

Shouldn't we be making a BACKUP of this essential adi file upon program closing, automatically? Where would we get the data from to rebuild this file if it were lost after many years of operating??? Lost, stolen destroyed PC, or by simply replacing an old unresponsive hard drive. Is there a utility to copy this important file to an offsite repository or an external drive?  Just another question. I use several PCs including a laptop/desktop and portable for QRP, is there a way to maintain a SINGLE adi reference file so that all operating positions have the same data such as B4s, states?

Chuck
K2RRV
What does the ADIFImport error say? Do you have a screen-capture of the error message?

If the ADIF import fails, than the the Scan Log will not find any confirmations and no B4's will be found.

de Laurie VK3AMA

I just now noticed the error message image attached to the original message.

The clue is in the command line parameters shown, specifically --in="".

You have specified ADIF logging, but have not set the path to your ADIF file.

de Laurie VK3AMA


locked Re: Worked B4 not shown as such

HamApps Support (VK3AMA)
 

On 3/11/2018 10:19 PM, k2rrv@... wrote:
I just helped a friend (K2BY) upgrade WSJT-X 1.9.1 AOK! Then we updated JTAlert to 2.12.6 and he now gets  adiFLmport: Error on startup. I rebuilt Scan Log still NG. No B4 info etc. I can't imagine operating FT8 without all the vital info we take for granted when everything is working right. Thanks Laurie and team!

Shouldn't we be making a BACKUP of this essential adi file upon program closing, automatically? Where would we get the data from to rebuild this file if it were lost after many years of operating??? Lost, stolen destroyed PC, or by simply replacing an old unresponsive hard drive. Is there a utility to copy this important file to an offsite repository or an external drive?  Just another question. I use several PCs including a laptop/desktop and portable for QRP, is there a way to maintain a SINGLE adi reference file so that all operating positions have the same data such as B4s, states?

Chuck
K2RRV
What does the ADIFImport error say? Do you have a screen-capture of the error message?

If the ADIF import fails, than the the Scan Log will not find any confirmations and no B4's will be found.

de Laurie VK3AMA


locked Re: Worked B4 not shown as such

k2rrv@...
 

I just helped a friend (K2BY) upgrade WSJT-X 1.9.1 AOK! Then we updated JTAlert to 2.12.6 and he now gets  adiFLmport: Error on startup. I rebuilt Scan Log still NG. No B4 info etc. I can't imagine operating FT8 without all the vital info we take for granted when everything is working right. Thanks Laurie and team!

Shouldn't we be making a BACKUP of this essential adi file upon program closing, automatically? Where would we get the data from to rebuild this file if it were lost after many years of operating??? Lost, stolen destroyed PC, or by simply replacing an old unresponsive hard drive. Is there a utility to copy this important file to an offsite repository or an external drive?  Just another question. I use several PCs including a laptop/desktop and portable for QRP, is there a way to maintain a SINGLE adi reference file so that all operating positions have the same data such as B4s, states?

Chuck
K2RRV


locked Re: Says i need to update even though I have

n5rn@...
 

I found the issue. 

Bitdefender identified a couple of files as being affected by "ransomware".   I turned off the ransomware detection and installed with no issues.  It see everything as current. 

FWIW - I could not "tag" 2.12.17 installer as not being ransomware because it looks like it creates some files in a temp folder and that changes each time you try to install and Bitdefender says the files are a target of ransomware.

Problem resolved.


locked Re: Says i need to update even though I have

HamApps Support (VK3AMA)
 

On 3/11/2018 9:40 PM, n5rn@... wrote:
I have downloaded and installed all the latest updates from Hamapps but I'm still getting the updates notification.  I'm running 2.12.17 Traditional,  Database 2018.11.02, and Sounds 2.5.1.   Is there a way to determine what updates the program thinks I need?

n5rn

JTAlert Settings (F11), navigate to the "Program Updates" section.

de Laurie VK3AMA


locked Says i need to update even though I have

n5rn@...
 

I have downloaded and installed all the latest updates from Hamapps but I'm still getting the updates notification.  I'm running 2.12.17 Traditional,  Database 2018.11.02, and Sounds 2.5.1.   Is there a way to determine what updates the program thinks I need?

n5rn


locked Re: Missing setting version 2.12.6

roamer
 


Question!  WTH does the freq., within a Very few Hz, mean in the real world?


locked Re: Explanation of # and *

HamApps Support (VK3AMA)
 

On 3/11/2018 1:04 PM, Robert wrote:
This is an easy one, but I can't find the answer in the Help file anywhere.
I have the colors working fine, but I get ones with a * (Star) , and once in awhile a # (hashtag).
What do those designate and how do I set them?

They are CQ indicators.

Open the JTAlert Settings (F11) and navigate to the "Alerts -> CQ and QRZ" section and your questions will be answered.

de Laurie VK3AMA


locked Explanation of # and *

Robert <Robert@...>
 

This is an easy one, but I can't find the answer in the Help file anywhere.
I have the colors working fine, but I get ones with a * (Star) , and once in awhile a # (hashtag).
What do those designate and how do I set them?
--

Thanks,

Robert AC2MM


locked Re: Missing setting version 2.12.6

Jim - N4ST
 

Release notes for 2.12.6 includes the statement:

 

- Option to log QRG only (dial frequency only) has been removed. Frequency

       now logged will always be the true Tx frequency (Dial + df). Note: Since

       WSJT-X doesn't provide the Rx frequency in the logged QSO packet, the Rx

       frequency logged will be the Tx frequency.

 

______________

73,

Jim – N4ST

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of vk7cej@... via Groups.Io
Sent: Friday, November 2, 2018 18:11
To: Support@HamApps.groups.io
Subject: [HamApps] Missing setting version 2.12.6

 

I searched, and could not find, so apologies if I or someone else has posted this before.   my memory just does not recall if I did post before..  sorry

Anyway, the missing settings...  Prior to version 2.12.6, when you opened settings and clicked on 'Logging'  directly beneath the tick boxes under 'Confirmed / Worked Bands Display' there were Two additional settings under the label 'Logged Frequency',   these settings were 'QRG only'  or  'QRG + DF (true RF)

These selections are no longer there and now my log shows all sorts of weird and wonderful frequencies, which I personally do not like.    Were these selections left off on purpose, or is this an error ???

regards
John

 


locked Re: Missing setting version 2.12.6

HamApps Support (VK3AMA)
 

On 3/11/2018 9:10 AM, vk7cej@... via Groups.Io wrote:

I searched, and could not find, so apologies if I or someone else has posted this before.   my memory just does not recall if I did post before..  sorry

Anyway, the missing settings...  Prior to version 2.12.6, when you opened settings and clicked on 'Logging'  directly beneath the tick boxes under 'Confirmed / Worked Bands Display' there were Two additional settings under the label 'Logged Frequency',   these settings were 'QRG only'  or  'QRG + DF (true RF)

These selections are no longer there and now my log shows all sorts of weird and wonderful frequencies, which I personally do not like.    Were these selections left off on purpose, or is this an error ???

regards
John

The 2.12.6 release notes have the answer.

The relevant sections...
  Changes:
    - Option to log QRG only (dial frequency only) has been removed. Frequency
       now logged will always be the true Tx frequency (Dial + df). Note: Since
       WSJT-X doesn't provide the Rx frequency in the logged QSO packet, the Rx
       frequency logged will be the Tx frequency.

  Fixes:
    - Incorrect logging of dial & df (reported via the WSJT-X status packet) when
       Band is changed before finalising logging of the last QSO. That is the WSJT-X
       Log QSO window is open, the Band is changed before logging the QSO via the
       OK button on the Log QSO window.

Unless WSJT-X changes in the future (which I doubt) to include the dial freq and DF in the Logged QSO data packet, than this change in JTAlert behaviour is permanent and unlikely to be reversed.

de Laurie VK3AMA


locked #Announcement #NewRelease : Latest Callsign Database is available for download. Ver 2018.11.02 #Announcement #NewRelease

HamApps Support (VK3AMA)
 

Visit https://HamApps.com for the download link to the latest Callsign Database installer.

de Laurie VK3AMA



locked #Announcement #NewRelease : JTAlert 2.12.7 is available for download #Announcement #NewRelease

HamApps Support (VK3AMA)
 

Visit https://HamApps.com for the download link and upgrade/install instructions

This release is available in two builds, the traditional build (menus and band activity displayed on the titlebar) plus a new "Alternate Layout" build created for those Win10 users who are experiencing missing menus and band activity display with the traditional JTAlert build.

Release Notes...
  Changes:
    - Late logging of a WSJT-X QSO (after changing DX Call before completing the
       logging of the previous DX Call), initially no longer shows a Callsign
       Mismatch error. The log fields data from a snapshot taken (for the
       previous DX Call) when the DX Call was changed is used if the Callsign
       of the snapshot matches the logged Callsign, otherwise the Callsign
       Mismatch error is still shown.

  Fixes:
    - Incorrect country for WSJT-X decode callsigns using special event words as
       the callsign prefix eg. POTA/Callsign, SOTA/Callsign, QRPP/Callsign, etc.
       (Why the recent change in operator behaviour? The convention has been to
       include these activation words as a suffix, eg Callsign/POTA).


de Laurie VK3AMA


locked Missing setting version 2.12.6

vk7cej@y7mail.com
 

I searched, and could not find, so apologies if I or someone else has posted this before.   my memory just does not recall if I did post before..  sorry

Anyway, the missing settings...  Prior to version 2.12.6, when you opened settings and clicked on 'Logging'  directly beneath the tick boxes under 'Confirmed / Worked Bands Display' there were Two additional settings under the label 'Logged Frequency',   these settings were 'QRG only'  or  'QRG + DF (true RF)

These selections are no longer there and now my log shows all sorts of weird and wonderful frequencies, which I personally do not like.    Were these selections left off on purpose, or is this an error ???

regards
John

 


locked Re: Ransomware detection?

Tony Dixon G4CJC
 

They seem to have fixed it. At least I can now add the plugins to the exceptions. This done after you get a remediation flagged up, by going to Notifications, clicking on the particular ransomware notification and looking at what file caused it. There is the option to place that file in the exceptions. Then it works fine.
Make sure you have the latest version of Bitdefender as I think this only appeared yesterday. The guys at Bitdefender have persisted with me and tho' they were a bit slow (they always apologised) I'm happy with the outcome.
Tony


locked Re: Reporting wrong band for a single cycle after a band change

Uwe, DG2YCB
 

Laurie,

Yes, it was JTAlert spots, and yes, WSJT-X build (1.9.1) is the published one. Meanwhile I've done some more tests. False spotting always occures when band change is being done within a certain time frame (close to the end of a FT8 cycle or immediately at the beginning of a new cycle). It is reproducible. The following video gives some more evidence and information: http://dg2ycb.duckdns.org/JTAlert_band_change_bug.mp4

Bug fix should be easy. As a band change is recognized by JTAlert immediately, it only needs to be programmed in a way, that then sending spots to hamspots.net (and/or receiving of decodes from WSJT-X) is IMMEDIATELY being paused for 10 to 15 seconds.

Seems that you tried already to fix this in the past because when changing the band some seconds earlier, receiving of decodes from WSJT-X by JTAlert is already being paused for one cycle in all newer versions of JTAlert (not sure exactly since when). But this fix is obviously not working when band change is being done within a certain time frame. As most of the people may change the bands close to the end on a FT8 cycle, from my point of view it is likely that some of the false spottings at hamspots.net are resulting from this unwanted behaviour.

Whould be great if that bug can be fixed.

73 de Uwe, DG2YCB

14841 - 14860 of 36910