Date   

locked Re: JT Alert: Norton says it is unsafe [i.e. hamapps.com]

Gilbert Baron <w0mn00@...>
 

Another reason to toss any and all security software other than what is part of the OS itself as it is most often more trouble that it is worth. Instead, have frequent image backups etc.  Norton and McAffee are the worst and they charge for the privilege!

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, February 11, 2018 21:40
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JT Alert: Norton says it is unsafe [i.e. hamapps.com]

 

On 12/02/2018 2:04 PM, Nelson DiGennaro wrote:

Laurie,

NORTON Safe Web is showing "Dangerous Web Page Blocked" when I attempt to access https://hamapps.com/.  The blocking is coming from "Safe Web" (see https://safeweb.norton.com/report/show?url=hamapps.com and also https://safeweb.norton.com/about).  There is a link on the first URL for the Site Owner to resolve the issue (I believe).  The specific threat identified is "Trojan.Gen.2"  for the file "HamApps_JTAlert_2.10.13_Setup.exe" (and I presume other files as well).  It is not for some non-specific "repudiation" issue.

I hope this info proves to be of some value in getting this resolved.
--
de Nelson WB8VUU


Nelson,

There are no Trojans within the JTAlert software. The only malicious software here is Norton, incorrectly flagging HamApps.com as unsafe based on a false positive from their software. Norton is blocking the download because it has identified a Trojan, not a named true threat, but a "Generic" threat. They don't identify a true threat.

I abandoned using Norton in a very large National Corporate environment years ago, as it created more troubles than it solved. Trying to uninstall Norton tends to be more problematic than trying to remove a true virus infection and the only reliable way we found to uninstall was a format followed by an OS and Application install. Putting it bluntly, IMHO, Norton is a POS!

To make Norton happy, HamApps_JTAlert_2.10.13_Setup
.exe has been removed.

See this FAQ item on Virus false positives of JTAlert.

de Laurie VK3AMA
   


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente


locked Re: JT Alert: Norton says it is unsafe [i.e. hamapps.com]

roamer
 

re:Norton

I dumped norton 20+ yrs ago. I agree it a POS! 😬

Get Outlook for Android


locked Re: JT Alert: Norton says it is unsafe [i.e. hamapps.com]

HamApps Support (VK3AMA)
 

On 12/02/2018 2:04 PM, Nelson DiGennaro wrote:
Laurie,

NORTON Safe Web is showing "Dangerous Web Page Blocked" when I attempt to access https://hamapps.com/.  The blocking is coming from "Safe Web" (see https://safeweb.norton.com/report/show?url=hamapps.com and also https://safeweb.norton.com/about).  There is a link on the first URL for the Site Owner to resolve the issue (I believe).  The specific threat identified is "Trojan.Gen.2"  for the file "HamApps_JTAlert_2.10.13_Setup.exe" (and I presume other files as well).  It is not for some non-specific "repudiation" issue.

I hope this info proves to be of some value in getting this resolved.
--
de Nelson WB8VUU

Nelson,

There are no Trojans within the JTAlert software. The only malicious software here is Norton, incorrectly flagging HamApps.com as unsafe based on a false positive from their software. Norton is blocking the download because it has identified a Trojan, not a named true threat, but a "Generic" threat. They don't identify a true threat.

I abandoned using Norton in a very large National Corporate environment years ago, as it created more troubles than it solved. Trying to uninstall Norton tends to be more problematic than trying to remove a true virus infection and the only reliable way we found to uninstall was a format followed by an OS and Application install. Putting it bluntly, IMHO, Norton is a POS!

To make Norton happy,
HamApps_JTAlert_2.10.13_Setup.exe has been removed.

See this FAQ item on Virus false positives of JTAlert.

de Laurie VK3AMA
   



locked Re: Double clicking running slow with HRD

HamApps Support (VK3AMA)
 

On 12/02/2018 8:32 AM, Warren Greenberg via Groups.Io wrote:
When I have JTalert running with HRD, there is a 2-4 second delay after I double click on a call. When I have JTalert logging to a standard adif, the tx is almost instant when I double click (HRD & HRD Rig control is turned off when I log to adif).
 I was talking to Mike at Hamcation and he said to look at CPU utilization & memory usage and nothing looks out of the ordinary.
 My configuration is a HP 8200 elite SFF with 16 gig running Windows 10 pro 64 bit.
 My Flex3000 id's a PowerSDR, the flex talks to DDUTIL which connects to WSJT (WSJT is set for TS480). My logging program (Logic9) also talks thru DDUTIL. And when I have HRD running it runs thru DDUTIL. When I run. HRD & shut down Logic9 and when I run Logic9 I have HRD shut down.
 I gave WSJT'S radio configured as HRD & JTalert pointing to HRD V6.
 Any idea's.
 Warren-AE4WG
Warren,

When you say a 2 -4 second delay, I assume you mean a delay before your Rig activates PTT. If that is the case, then the likely cause is a delay somewhere in the WSJT-X -> DDUTIL -> HRD -> Rig chain.

Sorry, I can't offer any authoritative advice regarding this setup, except to suggest you look at DDUTIL as I seem to recall some message on anther forum about DDUTIL latency (but I could be wrong). Why not take DDUTIL out of the picture while testing and have WSJT-X control HRD directly.

de Laurie VK3AMA
   


locked Re: JT Alert: Norton says it is unsafe [i.e. hamapps.com]

Dave AA6YQ
 

Norton is notorious for false positives.

"Trojan.Gen.2" means "This signature detects unclassified Trojan activity on the compromised computer." Translation: the observed behavior might be that of a Trojan.

This article cites two different online anti-malware checkers you can use to confirm that the report from Norton is erroneous:

<http://www.dxlabsuite.com/dxlabwiki/FalsePositive>

73,

Dave, AA6YQ

-----Original Message-----
From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Nelson DiGennaro
Sent: Sunday, February 11, 2018 10:05 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JT Alert: Norton says it is unsafe [i.e. hamapps.com]

Laurie,

NORTON Safe Web is showing "Dangerous Web Page Blocked" when I attempt to access https://hamapps.com/. The blocking is coming from "Safe Web" (see https://safeweb.norton.com/report/show?url=hamapps.com and also https://safeweb.norton.com/about). There is a link on the first URL for the Site Owner to resolve the issue (I believe). The specific threat identified is "Trojan.Gen.2" <http://www.symantec.com/avcenter/cgi-bin/virauto.cgi?vid=41129> for the file "HamApps_JTAlert_2.10.13_Setup.exe" (and I presume other files as well). It is not for some non-specific "repudiation" issue.

I hope this info proves to be of some value in getting this resolved.
--
de Nelson WB8VUU
(https://www.qrz.com/db/WB8VUU)


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


locked Re: JT Alert: Norton says it is unsafe [i.e. hamapps.com]

Nelson - WB8VUU
 

Laurie,

NORTON Safe Web is showing "Dangerous Web Page Blocked" when I attempt to access https://hamapps.com/.  The blocking is coming from "Safe Web" (see https://safeweb.norton.com/report/show?url=hamapps.com and also https://safeweb.norton.com/about).  There is a link on the first URL for the Site Owner to resolve the issue (I believe).  The specific threat identified is "Trojan.Gen.2"  for the file "HamApps_JTAlert_2.10.13_Setup.exe" (and I presume other files as well).  It is not for some non-specific "repudiation" issue.

I hope this info proves to be of some value in getting this resolved.
--
de Nelson WB8VUU
(https://www.qrz.com/db/WB8VUU)


locked Re: Log4om issue...Zone 5 default bug...

Tom WA9WSJ
 

Hi Jim,

I fully agree, that's why I started there but until I mentioned it here, there was no responses, even though it got 50 views, over a few weeks.
I think maybe that it wasn't viewed by those that would have answers, in that forum, or weren't checking it often.

I'll pursue the subject there.

thanks again,

73 Tom



From: Jim Preston <jpreston1@...>
To: Support@HamApps.groups.io
Sent: Sunday, February 11, 2018 3:24 PM
Subject: Re: [HamApps] Log4om issue...Zone 5 default bug...

Tom,

This seems to be more of an issue for the Log4OM forum. I have posted my
answer there.

73,

Jim N6VH


On 2/10/2018 6:11 PM, Tom WA9WSJ via Groups.Io wrote:
> Hi Jim,
>
> Ahh better understanding now, thanks!
>
> Interesting, I asked one gent about his zone and even though the map
> showed him in one zone, he actually was in an adjacent zone that the map
> didn't show. Sort of a bump in the line which captured him.
>
> So I have a couple more questions, if you know, :)
>
> 1. If I sign up for the xml service, will that update the zones in my
> logging program if I do an update? I would think so.
> 2. If so, will it update those guys who didn't add the zone info on
> their qrz lookup page?
>
> thanks again,
>
> Tom
>
>
> ------------------------------------------------------------------------
> *From:* Jim Preston <jpreston1@...>
> *Sent:* Saturday, February 10, 2018 6:57 PM
> *Subject:* Re: [HamApps] Log4om issue...Zone 5 default bug...
>
> Tom,
>
> Many other countries will show correct zones, simply because the country
> is only in one zone. Japan, zone 25, is just one example. The problem
> shows up when a country can have more than one zone. The US is one
> example, but there are others. Since ham calls in the US are not tied to
> any one region, it isn't easy to know what the zone is, just from the
> call. Even knowing the state doesn't always help, since some states are
> in more than one zone, depending on where in the state you are.
>
> 73,
>
> Jim N6VH
>
>
> On 2/10/2018 5:22 PM, Tom WA9WSJ via Groups.Io wrote:
>  > Hi Jim,
>  >
>  > Thanks for the info, makes sense now. Funny how the zones outside of the
>  > US seem to be okay. That's what kind of threw me on this.
>  >
>  > 73 Tom
>  >
>  >
>  >
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Jim Preston <jpreston1@... <mailto:jpreston1@...>>
>  > *Sent:* Saturday, February 10, 2018 3:36 PM
>  > *Subject:* Re: [HamApps] Log4om issue...Zone 5 default bug...
>  >
>  > Tom,
>  >
>  > As per my answer on the Log4OM forum, if you aren't a paid subscriber to
>  > QRZ, the zones might not get updated in Log4OM.
>  >
>  > 73,
>  >
>  > Jim N6VH
>  >
>  >
>  > On 2/9/2018 6:50 PM, Tom WA9WSJ via Groups.Io wrote:
>  >  > Hi Jim,
>  >  >
>  >  > I was finally able to get back at this. i checked your questions
> in the
>  >  > forum and answered you as well as Laurie.
>  >  >
>  >  > Thank you both for helping with this!
>  >  >
>  >  > 73 Tom
>  >  >
>  >  >
>  >  >
> ------------------------------------------------------------------------
>  >  > *From:* Michael Black via Groups.Io <mdblack98=yahoo.com@groups.io
>  > <mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>>
>  >  > *Sent:* Sunday, February 4, 2018 10:18 PM
>  >  > *Subject:* Re: [HamApps] Log4om issue
>  >  >
>  >  > I just submitted a bug report with an example of this problem.
>  >  > I just had one entry logged as Zone 5 and there was a prior entry
> in my
>  >  > log with him in Zone 4 where he should be.  So hopefully Laurie can
>  >  > figure out what's going on.
>  >  >
>  >  > It got the ITU wrong too.
>  >  >
>  >  > de Mike W9MDB
>  >  >
>  >  > On Sunday, February 4, 2018, 11:06:57 PM CST, Jim Preston
>  >  > <jpreston1@... <mailto:jpreston1@...>
> <mailto:jpreston1@... <mailto:jpreston1@...>>> wrote:
>  >  >
>  >  >
>  >  > Tom,
>  >  >
>  >  > I'm surprised that you didn't get an answer on the Log4OM Forum. The
>  >  > support people there are usually pretty quick to help.
>  >  >
>  >  > I sent a reply on the Log4OM forum. Please check it out there. I don't
>  >  > know if I can help, but maybe the discussion over there will get some
>  > help.
>  >  >
>  >  > 73,
>  >  >
>  >  > Jim N6VH
>  >  >
>  >  >
>  >  > On 2/4/2018 8:11 PM, Tom WA9WSJ via Groups.Io wrote:
>  >  >  > Hello Gents,
>  >  >  >
>  >  >  > I'm posting here because I have not gotten any answers from the
> log4om
>  >  >  > reflector or their forum since I posted on Jan 15th.
>  >  >  >
>  >  >  > Maybe someone has an idea to this?
>  >  >  >
>  >  >  >
>  >  >  > I checked some log entries recently for the cq zone numbers and
> found
>  >  >  > many that are actually in zone 3 and 4, are listed as in zone 5. I
>  >  >  > believe that all continental US contacts are defaulting to zone 5.
>  >  >  >
>  >  >  > So I did some searching for anything related to this in the
> forum and
>  >  >  > found some discussion about it concerning that the original qrz
> entry
>  >  >  > could be wrong but I need to add the following because it may be
>  > another
>  >  >  > problem.
>  >  >  >
>  >  >  > I verified that QRZ has the right zone info for a couple of qso's
>  > and so
>  >  >  > I did an "update" for these qso's in log40m but the zone entry
> in the
>  >  >  > log didn't change to the correct number which was shown on qrz.
>  >  >  >
>  >  >  > I can understand that if QRZ didn't show any zone info for a
>  > particular
>  >  >  > call, that maybe it would default, but I verified that the correct
>  > info
>  >  >  > was listed.
>  >  >  >
>  >  >  > I'm using the current versions of all three: WSJT-X ft-8 program,
>  >  >  > JTAlert program and log4om.
>  >  >  >
>  >  >  > Any thought about this?
>  >  >  >
>  >  >  > Thanks, Tom
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >  >
>  >
>  >
>  >
>  >
>  >
>  >
>
>
>
>
>
>






locked Re: WES logging

Dave Godfrey
 

Ohhhh, thanks. Looking in the wrong app.

On Feb 11, 2018 9:49 AM, "Brian (N2MLP)" <n2mlp@...> wrote:

It’s in HRD

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Dave Godfrey
Sent: Sunday, February 11, 2018 10:02 AM
To: Support@HamApps.groups.io
Subject: [HamApps] WES logging

 

I am currently logging to HRD and want to also send log info to QRZ log. Can't find any settings for QRZ logging.

 

Dave NY5A


locked Re: Log4om issue...Zone 5 default bug...

Jim N6VH
 

Tom,

This seems to be more of an issue for the Log4OM forum. I have posted my answer there.

73,

Jim N6VH

On 2/10/2018 6:11 PM, Tom WA9WSJ via Groups.Io wrote:
Hi Jim,
Ahh better understanding now, thanks!
Interesting, I asked one gent about his zone and even though the map showed him in one zone, he actually was in an adjacent zone that the map didn't show. Sort of a bump in the line which captured him.
So I have a couple more questions, if you know, :)
1. If I sign up for the xml service, will that update the zones in my logging program if I do an update? I would think so.
2. If so, will it update those guys who didn't add the zone info on their qrz lookup page?
thanks again,
Tom
------------------------------------------------------------------------
*From:* Jim Preston <jpreston1@cox.net>
*To:* Support@HamApps.groups.io
*Sent:* Saturday, February 10, 2018 6:57 PM
*Subject:* Re: [HamApps] Log4om issue...Zone 5 default bug...
Tom,
Many other countries will show correct zones, simply because the country
is only in one zone. Japan, zone 25, is just one example. The problem
shows up when a country can have more than one zone. The US is one
example, but there are others. Since ham calls in the US are not tied to
any one region, it isn't easy to know what the zone is, just from the
call. Even knowing the state doesn't always help, since some states are
in more than one zone, depending on where in the state you are.
73,
Jim N6VH
On 2/10/2018 5:22 PM, Tom WA9WSJ via Groups.Io wrote:
> Hi Jim,
>
> Thanks for the info, makes sense now. Funny how the zones outside of the
> US seem to be okay. That's what kind of threw me on this.
>
> 73 Tom
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Jim Preston <jpreston1@cox.net <mailto:jpreston1@cox.net>>
> *To:* Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
> *Sent:* Saturday, February 10, 2018 3:36 PM
> *Subject:* Re: [HamApps] Log4om issue...Zone 5 default bug...
>
> Tom,
>
> As per my answer on the Log4OM forum, if you aren't a paid subscriber to
> QRZ, the zones might not get updated in Log4OM.
>
> 73,
>
> Jim N6VH
>
>
> On 2/9/2018 6:50 PM, Tom WA9WSJ via Groups.Io wrote:
>  > Hi Jim,
>  >
>  > I was finally able to get back at this. i checked your questions
in the
>  > forum and answered you as well as Laurie.
>  >
>  > Thank you both for helping with this!
>  >
>  > 73 Tom
>  >
>  >
>  >
------------------------------------------------------------------------
>  > *From:* Michael Black via Groups.Io <mdblack98=yahoo.com@groups.io
<mailto:yahoo.com@groups.io>
> <mailto:yahoo.com@groups.io <mailto:yahoo.com@groups.io>>>
>  > *To:* Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
<mailto:Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>>
>  > *Sent:* Sunday, February 4, 2018 10:18 PM
>  > *Subject:* Re: [HamApps] Log4om issue
>  >
>  > I just submitted a bug report with an example of this problem.
>  > I just had one entry logged as Zone 5 and there was a prior entry
in my
>  > log with him in Zone 4 where he should be.  So hopefully Laurie can
>  > figure out what's going on.
>  >
>  > It got the ITU wrong too.
>  >
>  > de Mike W9MDB
>  >
>  > On Sunday, February 4, 2018, 11:06:57 PM CST, Jim Preston
>  > <jpreston1@cox.net <mailto:jpreston1@cox.net>
<mailto:jpreston1@cox.net <mailto:jpreston1@cox.net>>> wrote:
>  >
>  >
>  > Tom,
>  >
>  > I'm surprised that you didn't get an answer on the Log4OM Forum. The
>  > support people there are usually pretty quick to help.
>  >
>  > I sent a reply on the Log4OM forum. Please check it out there. I don't
>  > know if I can help, but maybe the discussion over there will get some
> help.
>  >
>  > 73,
>  >
>  > Jim N6VH
>  >
>  >
>  > On 2/4/2018 8:11 PM, Tom WA9WSJ via Groups.Io wrote:
>  >  > Hello Gents,
>  >  >
>  >  > I'm posting here because I have not gotten any answers from the
log4om
>  >  > reflector or their forum since I posted on Jan 15th.
>  >  >
>  >  > Maybe someone has an idea to this?
>  >  >
>  >  >
>  >  > I checked some log entries recently for the cq zone numbers and
found
>  >  > many that are actually in zone 3 and 4, are listed as in zone 5. I
>  >  > believe that all continental US contacts are defaulting to zone 5.
>  >  >
>  >  > So I did some searching for anything related to this in the
forum and
>  >  > found some discussion about it concerning that the original qrz
entry
>  >  > could be wrong but I need to add the following because it may be
> another
>  >  > problem.
>  >  >
>  >  > I verified that QRZ has the right zone info for a couple of qso's
> and so
>  >  > I did an "update" for these qso's in log40m but the zone entry
in the
>  >  > log didn't change to the correct number which was shown on qrz.
>  >  >
>  >  > I can understand that if QRZ didn't show any zone info for a
> particular
>  >  > call, that maybe it would default, but I verified that the correct
> info
>  >  > was listed.
>  >  >
>  >  > I'm using the current versions of all three: WSJT-X ft-8 program,
>  >  > JTAlert program and log4om.
>  >  >
>  >  > Any thought about this?
>  >  >
>  >  > Thanks, Tom
>  >  >
>  >
>  >
>  >
>  >
>  >
>  >
>
>
>
>
>
>


locked Re: Where does the data come from for the lookup?

Jim N6VH
 

Larry & Brian,

AFAIK, the grid that is sent to the log program by JTAlert is the one received from the transmitting station by WSJT-X (Laurie, correct me if I am wrong). What the log program does with the grid is another matter, and outside the control of JTAlert.

73,

Jim N6VH

On 2/11/2018 8:01 AM, Lawrence Godek wrote:
Brian, I'd think that as long as you updated your GRID locator in QRZ.com when you change locations, if the grid does indeed change, would be all you need to do.  My thoughts for correct grid logging since QRZ.com is where the data comes from.
Larry
W0OGH
On Sun, Feb 11, 2018 at 7:25 AM, Brian Kassel <briank7re@gmail.com <mailto:briank7re@gmail.com>> wrote:
Laurie Said:
"If you want JTAlert to provide accurate State alerts I can put
in-place a Callsign override in the FCC Data import code so that each
time the Callsigns database is updated (as well as HamSpots,net)
your State is recorded per your last request. I already do this for
6 other Callsigns, adding another is not a problem.
If you request an override, please be aware that the override is
permanent until you request its removal. It is a manual process (not
onerous, 5 seconds to comment out the code). It is not automated
based on date or some online service lookup change detection. You
simply request via email that the current override be removed or
changed."
Apparently I had been dealing with all of the wrong sources in my
quest to get the state changed.
I was not aware of the process in which state names are determined.
Your suggestion as to how to get an over ride for the state names
was unknown to me, so
I ended up pursuing the wrong  sources.
I now understand the process, and I thank you for your direction.
Since my state changes and locations will change from week to week,
I am not sure
that I should bother you with the constant updates that would be
required.
Thanks again for the excellent reply, and for your time in
supporting the applcation.
I will think on it a bit.
--
Sent by my Raspberry PI3
Brian K7RE


locked Double clicking running slow with HRD

Warren Greenberg
 

When I have JTalert running with HRD, there is a 2-4 second delay after I double click on a call. When I have JTalert logging to a standard adif, the tx is almost instant when I double click (HRD & HRD Rig control is turned off when I log to adif).
 I was talking to Mike at Hamcation and he said to look at CPU utilization & memory usage and nothing looks out of the ordinary.
 My configuration is a HP 8200 elite SFF with 16 gig running Windows 10 pro 64 bit.
 My Flex3000 id's a PowerSDR, the flex talks to DDUTIL which connects to WSJT (WSJT is set for TS480). My logging program (Logic9) also talks thru DDUTIL. And when I have HRD running it runs thru DDUTIL. When I run. HRD & shut down Logic9 and when I run Logic9 I have HRD shut down.
 I gave WSJT'S radio configured as HRD & JTalert pointing to HRD V6.
 Any idea's.
 Warren-AE4WG


locked Re: Feature reqest

Randy
 

Thank you Laurie,

I already knew about the ordering by freq but aside from keeping the calls in relatively the same order from decode to next decode, that (nor a history list) didn't help much in locating the signal under crowded band conditions with 30+ decodes per cycle.  And the band crowding is only getting worse, so bad at times I just move on.

I appreciate the addition of the decode frequency in the bubble, that will help sorting out stations I want to focus on.  

Maybe down the road a right-click copy (or even better, arbitrary RX freq control via UDP) would be icing on the cake.   I'm not sure how RX-freq control during non-CQ calls could lead to QRM or abuse.


---
~Randy

Until next time,

~Randy
K6RP

On 02/11/2018 10:24 am, HamApps Support (VK3AMA) wrote:

On 12/02/2018 5:18 AM, HamApps Support (VK3AMA) wrote:
On 12/02/2018 5:11 AM, Randy wrote:

How about we can display the RX frequency in the info bubble when hovering over a call?

Literally any help I can get finding the station in the waterfall will be very helpful.

---
~Randy
K6RP

Displaying the Rx frequency in the Callsign tooltip should not be a problem. Consider it done.
Until the next release and if your have the screen-space, the Rx frequency (DF) of the decodes is already visible within the Decodes History display.

de Laurie VK3AMA
   

In addition, the Callsign display is in DF order lowest to highest, left to right across the JTAlert window.

de Laurie VK3AMA
   


locked Re: #FT8 #FT8

Mike Shelby
 

Thanks Michael for the help. The information you provided got me headed in the right direction. I renamed the config.sqlite file. The WSJT-X - JTAlertx program still hung. Would not even create a fresh new config.splite file. Tried running JT65-HF – JTAlert program. That started up correctly and created a fresh new config.sqlite file. Swapped back to the old original config.sqlite file. Started WSJT-X – JTAlertx, its now running correctly. Looking at the configuration/settings, I cannot find any damage or errors. Thanks for the help.


locked Re: Feature reqest

HamApps Support (VK3AMA)
 

On 12/02/2018 5:11 AM, Randy wrote:

How about we can display the RX frequency in the info bubble when hovering over a call?

Literally any help I can get finding the station in the waterfall will be very helpful.

---
~Randy
K6RP
Randy,

Already implemented (see title of tooltip) and a new build sent to you for testing.

   

de Laurie VK3AMA
   


locked Re: Where does the data come from for the lookup?

Brian Kassel K7RE
 

Thanks Larry.  I think that will do as you say.

Thanks to all for the help.

--
Sent by my Raspberry PI3
Brian K7RE


locked Re: Feature reqest

HamApps Support (VK3AMA)
 

On 12/02/2018 5:18 AM, HamApps Support (VK3AMA) wrote:
On 12/02/2018 5:11 AM, Randy wrote:

How about we can display the RX frequency in the info bubble when hovering over a call?

Literally any help I can get finding the station in the waterfall will be very helpful.

---
~Randy
K6RP

Displaying the Rx frequency in the Callsign tooltip should not be a problem. Consider it done.
Until the next release and if your have the screen-space, the Rx frequency (DF) of the decodes is already visible within the Decodes History display.

de Laurie VK3AMA
   

In addition, the Callsign display is in DF order lowest to highest, left to right across the JTAlert window.

de Laurie VK3AMA
   


locked Re: Feature reqest

HamApps Support (VK3AMA)
 

On 12/02/2018 5:11 AM, Randy wrote:

How about we can display the RX frequency in the info bubble when hovering over a call?

Literally any help I can get finding the station in the waterfall will be very helpful.

---
~Randy
K6RP

Displaying the Rx frequency in the Callsign tooltip should not be a problem. Consider it done.
Until the next release and if your have the screen-space, the Rx frequency (DF) of the decodes is already visible within the Decodes History display.

de Laurie VK3AMA
   


locked Re: #FT8 #FT8

HamApps Support (VK3AMA)
 

On 11/02/2018 3:59 PM, Mike Shelby wrote:

JTAlertX 2.10.14, hangs on startup

Looks like this is an issue with latest Java runtime version 8 update 161. Problems started today, right after updated to latest Java runtime.


JTAlert doesn't use Java.

Give your PC a "Restart" as that is becoming the fix for many Wind10 unexplained application behaviours in recent times.

de Laurie VK3AMA
   


locked Re: Feature reqest

Randy
 

Another idea,

maybe right-click "Copy RX frequency" then I can paste it into WSJT.

---
~Randy
K6RP


On 02/11/2018 10:06 am, HamApps Support (VK3AMA) wrote:

On 12/02/2018 4:27 AM, Randy wrote:

Thanks, mike.   I have not checked that thread out yet...

Rather than 'set up a call' - can we just change RX frequency?   That's really all I'm looking for - an easy way to tune my RX without scrolling up through a mile long list of decodes to locate the frequency.   I have no problem manually setting up the call... a little help tuning RX would go a mile.

~Randy
K6RP


Randy,

JTAlert is already sending the correct UDP request to WSJT-X regardless of the decode type double-clicked. The filtering to only accept the UDP request for CQ only decodes is happening within WSJT-X. If WSJT-X is extended to allow non-CQ decode double-clicks than it will only require you to upgrade WSJT-X.

de Laurie VK3AMA
   


locked Re: Feature reqest

HamApps Support (VK3AMA)
 

On 12/02/2018 4:27 AM, Randy wrote:

Thanks, mike.   I have not checked that thread out yet...

Rather than 'set up a call' - can we just change RX frequency?   That's really all I'm looking for - an easy way to tune my RX without scrolling up through a mile long list of decodes to locate the frequency.   I have no problem manually setting up the call... a little help tuning RX would go a mile.

~Randy
K6RP


Randy,

JTAlert is already sending the correct UDP request to WSJT-X regardless of the decode type double-clicked. The filtering to only accept the UDP request for CQ only decodes is happening within WSJT-X. If WSJT-X is extended to allow non-CQ decode double-clicks than it will only require you to upgrade WSJT-X.

de Laurie VK3AMA
   

17921 - 17940 of 36910