Date   

locked Re: Feature Request - Log4OM V2

Dana Smith
 

Thanks. Been waiting to here from them. But I now have the Log4OM seeing the radio, but WSJT-X says it can’t see the com port leading me to more confusion Hi Hi
WSJTX is decoding, but the program won’t see the radio so it’s receiving signals but won’t set the frequency for transmit, etc. I am very confused now!!!!

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Jim N6VH
 

On 8/11/2021 11:22 AM, Dana Smith wrote:
Jim,
I understand that. Log4OM V2 is what doesn’t recognize the radio. Lof4OM Verson 1 worked just fine.
So I don’t know what setup for the interface is different, etc.
Thanks,
Dana
Dana,

Understood.  Then the question might be better asked on the Log4OM forum, on their web page. There are several people there who could help.

73,

Jim N6VH


locked Re: Feature Request - Log4OM V2

Dana Smith
 

Jim,
I understand that. Log4OM V2 is what doesn’t recognize the radio. Lof4OM Verson 1 worked just fine.
So I don’t know what setup for the interface is different, etc.
Thanks,
Dana

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Jim N6VH
 

On 8/11/2021 7:21 AM, Dana Smith wrote:
Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH
JTAlert doesn't interact with any transceiver. Is it possible the problem is with WSJT-X?

73,

Jim N6VH


locked Re: CQ Marathon anomalies

Phil Cooper
 

Many thanks for that Laurie,

I will keep an eye out, but I think this may have solved the problem.
As yet, i haven't seen anything that might give an alert.

Very best 73

Phil GU0SUP

-----Original Message-----
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@gmail.com>
Sent: Wednesday, 11 August, 2021 10:03
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon anomalies

On 11/08/2021 6:42 pm, Phil Cooper via groups.io wrote:

I do indeed have a QSL requirement set in the rebuild.... It is set to
LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP
That will be the reason previously worked and auto-marked as no longer
needed Marathon entities are re-alerting at a later time as the rebuild
is resetting the need status because it is looking for LoTW
confirmations in your log.

You can keep the Lotw requirement set for the other Alerts and turn off
all QSL requirements for the Marathon Alert only. The individual Alerts
have independent QSL requirements set under their respective sections of
the Rebuild settings.

de Laurie VK3AMA


locked Re: Feature Request - Log4OM V2

Joel
 

Dana

For my 7300 I had to get a USB to CV-I cable and follow this setup to get it to work with WSJTX and FLDigi. Try selecting your radio in omnirig for the setup:

Icom IC7300 CAT control for multiple DATA programs.
The IC7300 and similar radios that have two CAT connections that can be separated provide an easy and unique method of connecting multiple software data packages.
1. Having installed the Icom USB port drivers to the PC
2. Connect a USB cable to the rear connection on the IC7300 and to a USB port on the PC
3. Connect a USB CI-V cable to the ‘REMOTE’ socket on the back of the IC-7300 and another USB port on the PC.
4. Make a note of the port numbers for these two connections as shown in the PC device manager
Setting up the IC7300
In Menu/Set/Connectors/CI-V set the following
CI-V Baud rate = 19200
CI-V Tranceive = OFF
CI-V USB Port = Unlink from (Remote) CI-V USB Baud Rate = 19200
All other settings as default
Setting up Log4OM
Download and install Omnirig.
In Settings/Program Configuration/CAT Interface
CAT Engine = Omnirig
Check the box = Auto start CAT
Check the box = Invert SSB side (CW)
Check the box = Switch to digital mode when required Default = Select FT8 from list
Click ‘SAVE AND APPLY’
   24

In the Omnirig menu
1. Select the radio from the drop-down list (IC7300 DATA)
2. Select the com port number for the USB – USB connection to the radio and set the Baud rate to 19200
3. Click OK (Frequency and mode changes on the radio will be reflected in Log4OM
Setting up WSJT CAT control
In WSJT File/Settings/Radio
Select OMNIRIG Rig?? In the Rig menu
Set PTT method to CAT
Set Mode to DATA/PKT
Set Split Operation to FAKE IT Click OK
Setting up FLDIGI CAT control
In FLDigi Configure/Configure Dialog/Rig Control/Hamlib
Select Icom IC7300 (Stable) from the Rig menu Check the box ‘USE HAMLIB’
Select the USB CI-V – Remote com port number in the ‘DEVICE’ menu Set ‘BAUD RATE’ to 19200
Click on ‘INITIALISE’
Click ‘SAVE’
Click ‘Close’
In the Configure menu click on Save Config

Good luck & 73
Joel
AC8WS

On Aug 11, 2021, at 10:21 AM, Dana Smith <ah6rim9@...> wrote:


Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Dana Smith
 

Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - DXCC Most Wanted rank

Pete Ritter K5CPR
 

I hadn't envisioned it as a real-time lookup. I'd think that an infrequent update of the MWL of, say, every six months, would be fine since the ranks don't change much.  And I agree with you that it is eye candy and therefore not urgent or very important. Thanks for considering the change. 


locked Re: CQ Marathon anomalies

HamApps Support (VK3AMA)
 

On 11/08/2021 6:42 pm, Phil Cooper via groups.io wrote:

I do indeed have a QSL requirement set in the rebuild.... It is set to LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP

That will be the reason previously worked and auto-marked as no longer needed Marathon entities are re-alerting at a later time as the rebuild is resetting the need status because it is looking for LoTW confirmations in your log.

You can keep the Lotw requirement set for the other Alerts and turn off all QSL requirements for the Marathon Alert only. The individual Alerts have independent QSL requirements set under their respective sections of the Rebuild settings.

de Laurie VK3AMA


locked Re: CQ Marathon anomalies

Phil Cooper
 

Hi Laurie,

I do indeed have a QSL requirement set in the rebuild.... It is set to LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 11/08/2021 7:02 am, HamApps Support (VK3AMA) via groups.io wrote:
On 10/08/2021 3:32 am, Pete Ritter K5CPR via groups.io wrote:
I doubt that I'm the first to suggest this, but a quick search revealed no other such suggestions, so here goes ...

How about adding the rank on ClubLog's "DXCC Most Wanted List" to the info on the hover-over pop-up?

This is the first request for this.

Performing an online lookup to determine where a decoded station appears in the "Most Wanted" rankings is not suitable for the real-time alerting of JTAlert. It would be more suitable as part of the current online lookups when the DXCall changes. That is limited to the the data gathering & display for the current QSO partner.

JTAlert could mitigate the overhead of an online lookup by caching the lookup results as it currently does for other CPU expensive tasks like log B4 checks & XML lookups.

Having JTAlert from multiple users hitting the ClubLog server, even with local lookup caching, would likely not be appreciated by ClubLog.

JTAlert could eliminate the online-lookups by have the Rankings stored locally in the Callsigns database, my preferred method BTW, but that will require extending the Callsign database schema producing a database that is incompatible with all current JTAlert versions. Extending the Callsign database is currently a work-in-progress project as I have other data I want to include as part of some Alerting enhancements that are planned.

Knowing a station's position in the "Most Wanted" rankings, is in my mind, an "eye-candy" feature, like showing the location of decoded Callsigns on a world map. Both achieve little in working/logging stations, nice to look at, but not adding any real utility to the real-time alerting, IMO.

This is something I will add to the "nice-to-have-but-not-urgent" todo list. It may get elevated from that list when the current Callsign Database redesign project progresses.

de Laurie VK3AMA


Adding to my previous message...

At the time of my initial response I hadn't done any investigation into the lookup mechanism on Clublog. I assumed the lookup would be done in real-time (like xml lookups), thus my comments on overhead. Turns out the "Most Wanted" rankings are updated on a Monthly basis. That sort of frequency is a better fit for inclusion of the data into the existing database. It will be trivial to add to the database, but will be a breaking change so will not be rolled out anytime soon. It will have to wait until I finish the database extension project.

The inclusion & display of a ranking number (that is all it is) is not a high priority at this time.

de Laurie VK3AMA


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 10/08/2021 3:32 am, Pete Ritter K5CPR via groups.io wrote:
I doubt that I'm the first to suggest this, but a quick search revealed no other such suggestions, so here goes ...

How about adding the rank on ClubLog's "DXCC Most Wanted List" to the info on the hover-over pop-up?

This is the first request for this.

Performing an online lookup to determine where a decoded station appears in the "Most Wanted" rankings is not suitable for the real-time alerting of JTAlert. It would be more suitable as part of the current online lookups when the DXCall changes. That is limited to the the data gathering & display for the current QSO partner.

JTAlert could mitigate the overhead of an online lookup by caching the lookup results as it currently does for other CPU expensive tasks like log B4 checks & XML lookups.

Having JTAlert from multiple users hitting the ClubLog server, even with local lookup caching, would likely not be appreciated by ClubLog.

JTAlert could eliminate the online-lookups by have the Rankings stored locally in the Callsigns database, my preferred method BTW, but that will require extending the Callsign database schema producing a database that is incompatible with all current JTAlert versions. Extending the Callsign database is currently a work-in-progress project as I have other data I want to include as part of some Alerting enhancements that are planned.

Knowing a station's position in the "Most Wanted" rankings, is in my mind, an "eye-candy" feature, like showing the location of decoded Callsigns on a world map. Both achieve little in working/logging stations, nice to look at, but not adding any real utility to the real-time alerting, IMO.

This is something I will add to the "nice-to-have-but-not-urgent" todo list. It may get elevated from that list when the current Callsign Database redesign project progresses.

de Laurie VK3AMA


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 10/08/2021 11:16 pm, Pete Ritter K5CPR via groups.io wrote:
It’s to me more valuable than the DXCC entity number that is displayed already.

The DXCC number is displayed because there is no overhead in doing so, it is already available internally due to checking the DXCC Alert status.

de Laurie VK3AMA


locked Re: Wildcard for wanted callsigns

HamApps Support (VK3AMA)
 

On 10/08/2021 10:41 pm, WarrenG KC0GU wrote:
Try %DMC


That wont work.

From the help file...
  • Only a single wildcard character "%" is allowed
  • The wildcard is only supported as the last character
  • "VK3%" is valid
  • "VK%AMA", "VK%A%A", "%AMA" are all invalid.

de Laurie VK3AMA


locked Re: Wildcard for wanted callsigns

HamApps Support (VK3AMA)
 

On 10/08/2021 9:59 pm, Tony Dixon G4CJC wrote:
I was just wondering with the most excellent new code there was any way to alert for parts of a callsign past the initial characters? Eg *DMC. I know what the help file says and it's useful but limited.
Cheers
Tony G4CJC

Its on the todo list. Support for a more flexible regex style matching system will eventually be available courtesy of the new coding language. The existing matching mechanism is severely hamstrung by the woefully slow regex engine in the AutoIT code, which is the reason for the current restrictive limitation of a single trailing "%" character. Proper regex style matching would bring JTAlert to its knees on a very busy band with multiple matching strings to process.

The new implementation is being delayed because of the old AutoIT code that is still in place for all the Alerting logic and lookups. Once I can move the old alerting code away from AutoIT, a not-insignificant task due to its many internal dependencies on other internal AutoIT code, I will be able to introduce a proper regex style matching system for the Wanted Callsigns Alert.

de Laurie VK3AMA


locked Re: 2 Instances of JTAlert Simultaneously #FT8 #JTDX

HamApps Support (VK3AMA)
 

On 10/08/2021 11:50 am, Micky Corrow wrote:
I sometimes run 2 different stations simultaneously. Both are on totally separate computers and radios (and antennas).
Both computers run the same software combinations of JTDX, Log4OMv2 and JTAlert. 

While both stations run well, I will sometimes get a text alert from the other station on the one where I am currently sitting. Although this is not a showstopper by any means, is there a way to tie each instance of JTAlert to each specific band (on each separate computer)?

It is not the end of the world here, as I just usually ask the person texting me which band (if it is not obvious) and just keep going on from there.

Micky K1XH

Text Messages are directed to a Callsign only, there is no provision for separating Callsign messages on a per JTAlert instance basis. How would a station sending you a message know that it needs to go to a specific JTAlert instance your end? It is not possible.

Text Messaging in JTAlert is a single instance operation only, handled from instance #1 only, but outgoing messages can be initiated from any instance, they are all funneled back through instance #1 for sending to the Messaging server. Incoming messages are handled by instance #1 for display.

de Laurie VK3AMA


locked Re: CQ Marathon anomalies

HamApps Support (VK3AMA)
 

On 10/08/2021 11:23 pm, Phil Cooper via groups.io wrote:
I am still getting Marathon alerts for countries I have previously worked this year.
In setting, I have got "Auto clear triggered Alert entity after logging" checked, and under Bands, I have Tracking set to Any Band and Any Digital Mode.

I have just done a rebuild, and I am still getting several calls alerting me to a new Marathon entity, but they have ALL been worked this year, and 3 of them show B4 in the alter panel.
I am currently on 17m, and getting alters for 3W1T, T77C and 3D2USU, all of which were worked in the last month or so. The 3D2 was worked last week.

What am I missing here?

73 de Phil GU0SUP

Phil,

It is hard to know exactly what is happening your end without having access to your JTAlert settings and Log file.

You mention performing the Rebuild, that is a potential cause of previously worked Marathon entities getting their need status changed from not-needed to needed. Do you perhaps have a QSL requirement set in the Rebuild scan for the Marathon Alert? If you don't want to loose previously worked-only entries (set by the Auto Clear) for a specific Alert like the Marathon, than make sure that the Rebuild Scan for that Alert does not have any QSL requirements set or better still turn off that Alert in the Rebuild settings.

Do you have the Logging Success dialog turned on? If not, turn it on and keep an eye on what Alert types it is reporting have been cleared as a result of the Auto Clear settings. If it is correctly reporting that Marathon Countries and Zones are being cleared then you should not be getting alerted to those in future decodes. If you still get alerted than we will need to embark on a debugging exercise to identify the cause.

de Laurie VK3AMA


locked Re: Feature Request - DXCC Most Wanted rank

Dave Garber
 

I have my wanted dxcc in yellow to show new on that band.   Hsving most wanted to me would alert to some i had worked b4 but met the new criteria.....


On Tue., Aug. 10, 2021, 9:16 a.m. Pete Ritter K5CPR via groups.io, <cpritter=verizon.net@groups.io> wrote:
It’s an additional bit of information. I’m an info junkie. It’s to me more valuable than the DXCC entity number that is displayed already. In the rare event that I decode more than one new DXCC, knowing the wanted rank of each would help me decide which to chase first. 


locked CQ Marathon anomalies

Phil Cooper
 

Laurie and the group,

I am still getting Marathon alerts for countries I have previously worked this year.
In setting, I have got "Auto clear triggered Alert entity after logging" checked, and under Bands, I have Tracking set to Any Band and Any Digital Mode.

I have just done a rebuild, and I am still getting several calls alerting me to a new Marathon entity, but they have ALL been worked this year, and 3 of them show B4 in the alter panel.
I am currently on 17m, and getting alters for 3W1T, T77C and 3D2USU, all of which were worked in the last month or so. The 3D2 was worked last week.

What am I missing here?

73 de Phil GU0SUP


locked Re: Feature Request - DXCC Most Wanted rank

Pete Ritter K5CPR
 

It’s an additional bit of information. I’m an info junkie. It’s to me more valuable than the DXCC entity number that is displayed already. In the rare event that I decode more than one new DXCC, knowing the wanted rank of each would help me decide which to chase first. 

1921 - 1940 of 38435