Date   

locked Re: States-Wanted Boxes Auto-Untick?

Mike Rhodes
 

Thinking that doesn't happen until that state is confirmed. You are linked to your log aren't you?

Mike / W8DN

On 11/15/2020 7:29 PM, Patrick Hung wrote:
I just began working on my WAS award, and so have ticked the numerous boxes for states that I still need on the States Wanted page of JTAlert.

I had thought that once I complete a QSO with a station from a wanted state, JTAlert would automatically "untick" that box for me, or turn off that specific alert for that particular band, so that stations from the same state won't get highlighted again. To my disappointment, it doesn't do that; I've had to remember the states I just completed, and manually turn off the alert. Is this how it's supposed to work?

Thanks.
--
Patrick - W2TAR


locked Re: unsuccessful contacts with 7q7ru

Michael Aust
 

Worked them on CW on 40m and 20m
Mike
WB6DJI 


Sent from AOL Mobile Mail
Get the new AOL app: mail.mobile.aol.com

On Sunday, November 15, 2020, ray cathode via groups.io <ray_cathode1@...> wrote:

Roger,


it seems very strange that they would call at the 0-500 slot when I do.
That doesn't explain why other calls are verified.


9 Times total 6 last night and 3 so far today, that's not coincidence

My time is set every 30 minutes with D4, always well withing .2 seconds, besides I don't think they would call me if they couldn't decode me above 1000.


73,

W9RF - Joe







On Sunday, November 15, 2020, 4:00:52 PM CST, Roger M via groups.io <ac6bw@...> wrote:


Joe,
Like Bjorn said, the LIDS who don't know how to operate F/H mode see you working (or attempting to work) the DX in the 0 - 500 Hz slot, after the Fox has pushed you down in frequency. Then, they decide to call him in that same frequency slot, which creates QRM. After 3 tries, the Fox gives up.You say that you got dropped 6 times, so this may be a long shot answer, but it's certainly something to consider. I see these kinds of problems occur in every F/H operation. It can become a big mess.

I assume that your time is set accurately. I was working 7Q7RU today, and his time looked accurate on my end.
--
73,
Roger
AC6BW


locked States-Wanted Boxes Auto-Untick?

Patrick Hung
 

I just began working on my WAS award, and so have ticked the numerous boxes for states that I still need on the States Wanted page of JTAlert.

I had thought that once I complete a QSO with a station from a wanted state, JTAlert would automatically "untick" that box for me, or turn off that specific alert for that particular band, so that stations from the same state won't get highlighted again. To my disappointment, it doesn't do that; I've had to remember the states I just completed, and manually turn off the alert. Is this how it's supposed to work?

Thanks.
--
Patrick - W2TAR


locked Re: unsuccessful contacts with 7q7ru

Joe - W9RF
 

Roger,


it seems very strange that they would call at the 0-500 slot when I do.
That doesn't explain why other calls are verified.


9 Times total 6 last night and 3 so far today, that's not coincidence

My time is set every 30 minutes with D4, always well withing .2 seconds, besides I don't think they would call me if they couldn't decode me above 1000.


73,

W9RF - Joe







On Sunday, November 15, 2020, 4:00:52 PM CST, Roger M via groups.io <ac6bw@...> wrote:


Joe,
Like Bjorn said, the LIDS who don't know how to operate F/H mode see you working (or attempting to work) the DX in the 0 - 500 Hz slot, after the Fox has pushed you down in frequency. Then, they decide to call him in that same frequency slot, which creates QRM. After 3 tries, the Fox gives up.You say that you got dropped 6 times, so this may be a long shot answer, but it's certainly something to consider. I see these kinds of problems occur in every F/H operation. It can become a big mess.

I assume that your time is set accurately. I was working 7Q7RU today, and his time looked accurate on my end.
--
73,
Roger
AC6BW


locked Erroneous error message !

Paul F6EXV
 

Hi all
Strange behaviour...
Using Log4OM latest version, JTDX v2.2.0-rc152 and JTAlert 2.16.15 on Windows 10.
I am getting the attached error message when logging a QSO onto Log4OM.
But the QSO is indeed logged...

I have :
Enable transmission of last QSO ticked, on port 2333 in the "Last QSO API" setup
Enable Standard ADIF file logging unticked in the Standard ADIF file setup
Enable Log4OM V2 logging tocked, UDP connections on IP 127.0.0.1 on ADIF message port #2236
When I ask JTAlert to show Log Fields, the screen expands, but remains grey.
The headline says "JTAlert 2.16.15 F6EXV {80m,FT8,LogV2,#1}

If I untick "Enable Log4OM Logging", then I do not have access to "View log fields", and the expanded grey screen disappears, and the header will now show "NO LOG".
 And the QSO IS logged onto Log4OM, without any success message....

1/ How can I get access to the log fields below the display lines ?
2/ The "NO LOG" indication makes reference to which log ?
3/ How do I get a logging success message ?

Thanks + 73
Paul F6EXV



--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


locked Re: unsuccessful contacts with 7q7ru

Roger- AC6BW
 

Joe,
Like Bjorn said, the LIDS who don't know how to operate F/H mode see you working (or attempting to work) the DX in the 0 - 500 Hz slot, after the Fox has pushed you down in frequency. Then, they decide to call him in that same frequency slot, which creates QRM. After 3 tries, the Fox gives up.You say that you got dropped 6 times, so this may be a long shot answer, but it's certainly something to consider. I see these kinds of problems occur in every F/H operation. It can become a big mess.

I assume that your time is set accurately. I was working 7Q7RU today, and his time looked accurate on my end.
--
73,
Roger
AC6BW


locked Re: unsuccessful contacts with 7q7ru

Joe - W9RF
 

Bjorn,

I fail to see what that has to do with my situation, I always call above 1000 and don't hear anyone from 500-1000 except for the ones they throw up there, and that's only for a couple of passes.

So how does that explain my problem?







On Sunday, November 15, 2020, 3:39:50 PM CST, Björn SM7IUN <bjorn@...> wrote:


Likely since LIDS are repeatedly calling him below 1000Hz. 
The Fox will not respond to them, they just QRM. 

Björn SM7IUN

Den sön 15 nov. 2020 kl 22:05 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:
Good afternoon group.


Since yesterday evening 7q7ru has heard my call and called me down to his frequency (Fox/Hound) 9 times with out a successfully confirmation.

After a few back and forth with the signal report (which has been very good reports) they throw me up to a higher frequency and leave me there and go on calling other calls or calling CQ.

Are they running a different software that is not compatible with JTAlert/WSJT-X?
or is it possible a setting has been changed with my software?

I tested my software by making other contacts (not Fox/Hound) so unless the problem id something with Fox/Hound my software is working..


Thanks for any help..


73,

W9RF - Joe



locked Re: WSJT-X rc2

g4wjs
 

On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
On 16/11/2020 7:51 am, g4wjs wrote:

you appear to be one of the users using an inappropriate multicast address that has caused this change to be made. Until a version of JTAlert is available that will receive multicast traffic on the loop-back network interface, you can restore functionality by choosing your local subnet network interface in WSJT-X "Settings->Reporting->UDP Server->Outgoing interface".

Multicast addresses in the 239.0.0.0/16 block are potentially globally routed, that is not a good choice for getting traffic to a server on the same host or your local subnet.


--
73
Bill
G4WJS.

Bill,

JTAlert will work with a 224.0.0.0/16 multicast address. Try it.

From my JTAlert Help->About ...
   

Laurie,

as I explained off list, 224.0.0.1 is a special multicast address known as the "All Hosts" address. The 224.0.0.0/8 block of addresses is also special as they are never routed. 224.0.0.1 specifically (not just any 224.0.0.0/8 address) will work with the current JTAlert because every host joins that multicast group, on every network interface, automatically without the recipient application requesting membership. 224.0.0.1, the "All Hosts" multicast address, is just one member of the 224.0.0.0/24 block of 255 multicast addresses.

I think there may be some fundamental misunderstanding here about IPv4 address notation. IPv4 addresses are 32-bit numbers which are often written as a group of 4 decimal octets (representing 8-bits each), known as dotted decimal notation. IPv4 addresses are also written as groups, or subnets, where a specified number of high order bits, the prefix, are fixed and the remaining lower order bits form he membership of the subnet group. Some common subnets are:

127.0.0.0/8 - the loop-back addresses (they all start with 127., yes >16 million of them!), of which 127.0.0.1 is the most commonly used and supported.

192.168.0.0/16 - the class C private address block, they all start with 192.168. and are not normally routed.

172.16.0.0/12 - the class B private address block, they are 172.16.0.0 thru 172.31.255.255, also not normally routed.

10.0.0.0/8 - the class A private address block, they all start with 10., also not normally routed.

224.0.0.0/4 - the multicast group addresses, they are 224.0.0.0 thru 239.255.255.255.

Multicast group addresses are further subdivided, including 224.0.0.0/8 (not routed), and 239.0.0.0/24 (routing scope determined by further subdivisions and router settings, a.k.a. administratively scoped).


--
73
Bill
G4WJS.


locked Re: unsuccessful contacts with 7q7ru

Björn SM7IUN
 

Likely since LIDS are repeatedly calling him below 1000Hz. 
The Fox will not respond to them, they just QRM. 

Björn SM7IUN

Den sön 15 nov. 2020 kl 22:05 skrev ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io>:

Good afternoon group.


Since yesterday evening 7q7ru has heard my call and called me down to his frequency (Fox/Hound) 9 times with out a successfully confirmation.

After a few back and forth with the signal report (which has been very good reports) they throw me up to a higher frequency and leave me there and go on calling other calls or calling CQ.

Are they running a different software that is not compatible with JTAlert/WSJT-X?
or is it possible a setting has been changed with my software?

I tested my software by making other contacts (not Fox/Hound) so unless the problem id something with Fox/Hound my software is working..


Thanks for any help..


73,

W9RF - Joe



locked Re: unsuccessful contacts with 7q7ru

Joe - W9RF
 

Roger,


I understand that but with signal reports +4 to him and -01 to me, I know he doesn't have a problem hearing me.

Now, why can't he decode me (maybe that should be my question)


6 times in a row last evening he pushed me to a higher 500-1000 freq and after a minute or so I went back above 1000 and called him again, after he called a few more calls I was called back down to his freq again.

This went on for over an hour and finally he went qrt.



On Sunday, November 15, 2020, 3:12:09 PM CST, Roger M via groups.io <ac6bw@...> wrote:


It is normal for the Fox to push you up to a higher offset frequency, between 500 - 1000 Hz, if he has not successfully decoded you after 3 cycles in the 0 - 500 Hz frequency slot. At that point, your QSO is in limbo. Your best course of action is to start over by calling him with a TX1 above 1000 Hz.
The SW on your end is working as it should.

--
73,
Roger
AC6BW


locked Re: WSJT-X rc2

g4wjs
 

On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
FWIW, the original choice of the 239.255.0.0/16 subnet for the JTAlert multicast support was based on your recommendations in this posting
Quote...

Laurie,

the OP claimed to be using 239.0.0.1, that is most definitely *not* in the 239.255.0.0/16 block of multicast addresses!


--
73
Bill
G4WJS.


locked Re: WSJT-X rc2

HamApps Support (VK3AMA)
 

On 16/11/2020 7:51 am, g4wjs wrote:

you appear to be one of the users using an inappropriate multicast address that has caused this change to be made. Until a version of JTAlert is available that will receive multicast traffic on the loop-back network interface, you can restore functionality by choosing your local subnet network interface in WSJT-X "Settings->Reporting->UDP Server->Outgoing interface".

Multicast addresses in the 239.0.0.0/16 block are potentially globally routed, that is not a good choice for getting traffic to a server on the same host or your local subnet.


--
73
Bill
G4WJS.

Bill,

JTAlert will work with a 224.0.0.0/16 multicast address. Try it.

From my JTAlert Help->About ...
   

FWIW, the original choice of the 239.255.0.0/16 subnet for the JTAlert multicast support was based on your recommendations in this posting
Quote...
Hi Tag and Ed,

modern multicast routing does not rely on TTL values to restrict routing span, best to use an administratively scopes address. I use 239.255.0.0/16 addresses which is site local, it is a bit like 192.168.0.0/16 or 10.0.0.0/24 addresses. better still use IPv6 multicast group addresses like ffx5::/16 which are all site local multicast addresses, e.g. ff05::, ff05::1, ..., ff05::ff:ff, ff15::, ff15::ff:ff, ...


To which Tag responded in this posting
Quote...
I have started recommending 239.255.0.1 to my user base.


I followed your lead in recommending 239.255.0.0 as the Multicast address to use for WSJT-X inter-operating with JTAlert.

What do you recommend now as a suitable address within the 224.0.0.0/16 subnet?

Since the "goal posts" have changed with 224.0.0.0/16 now being recommended, I'll update the JTAlert documentation to use an address in the now recommended range.

de Laurie VK3AMA



locked Re: unsuccessful contacts with 7q7ru

Roger- AC6BW
 

It is normal for the Fox to push you up to a higher offset frequency, between 500 - 1000 Hz, if he has not successfully decoded you after 3 cycles in the 0 - 500 Hz frequency slot. At that point, your QSO is in limbo. Your best course of action is to start over by calling him with a TX1 above 1000 Hz.
The SW on your end is working as it should.

--
73,
Roger
AC6BW


locked unsuccessful contacts with 7q7ru

Joe - W9RF
 

Good afternoon group.


Since yesterday evening 7q7ru has heard my call and called me down to his frequency (Fox/Hound) 9 times with out a successfully confirmation.

After a few back and forth with the signal report (which has been very good reports) they throw me up to a higher frequency and leave me there and go on calling other calls or calling CQ.

Are they running a different software that is not compatible with JTAlert/WSJT-X?
or is it possible a setting has been changed with my software?

I tested my software by making other contacts (not Fox/Hound) so unless the problem id something with Fox/Hound my software is working..


Thanks for any help..


73,

W9RF - Joe



locked Re: JTA/2.3.0-rc2 failing

g4wjs
 

On 15/11/2020 20:30, Gene, K5PA wrote:

[Edited Message Follows]

I think I had to restart WSJT-X after selecting the ethernet_32769 for the change to take effect.
But it worked afterwards.
Hi Gene,

that's not necessary although it could tale up to 15 seconds after the change is saved before JTAlert sees the WSJT-X traffic.



--
73
Bill
G4WJS.


locked Re: WSJT-X rc2

g4wjs
 

On 15/11/2020 20:25, Thomas Mills wrote:
Just loaded wsjtx rc2 and got a message that the network port was not working.  found this on the wsjtx release notes, so I guess 239.0.0.1 want work anymore?


 Due to  some users using  inappropriate multicast IP  addresses for
   their interoperating  servers the default behaviour now is  to only
   send multicast  UDP datagrams  to the loop-back  network interface.
   Users who  require WSJT-X UDP  Message Protocol datagrams  to reach
   other  hosts will  now  have  to configure  WSJT-X  to  send on  an
   appropriate  network interface,  and  use  an appropriately  scoped
   multicast group address for their  server applications.  If you are
   not sure then  224.0.0.1 (or ff02::1 if IPv6 is  desired) is a safe
   choice.
Thanks Tom WB4JWM
_._,_._,_

Hi Tom,

you appear to be one of the users using an inappropriate multicast address that has caused this change to be made. Until a version of JTAlert is available that will receive multicast traffic on the loop-back network interface, you can restore functionality by choosing your local subnet network interface in WSJT-X "Settings->Reporting->UDP Server->Outgoing interface".

Multicast addresses in the 239.0.0.0/16 block are potentially globally routed, that is not a good choice for getting traffic to a server on the same host or your local subnet.


--
73
Bill
G4WJS.


locked Re: JTA/2.3.0-rc2 failing

Gene, K5PA
 
Edited

I think I had to restart WSJT-X after selecting the ethernet_32769 for the change to take effect.
But it worked afterwards.


locked WSJT-X rc2

Thomas Mills
 

Just loaded wsjtx rc2 and got a message that the network port was not working.  found this on the wsjtx release notes, so I guess 239.0.0.1 want work anymore?


 Due to  some users using  inappropriate multicast IP  addresses for
   their interoperating  servers the default behaviour now is  to only
   send multicast  UDP datagrams  to the loop-back  network interface.
   Users who  require WSJT-X UDP  Message Protocol datagrams  to reach
   other  hosts will  now  have  to configure  WSJT-X  to  send on  an
   appropriate  network interface,  and  use  an appropriately  scoped
   multicast group address for their  server applications.  If you are
   not sure then  224.0.0.1 (or ff02::1 if IPv6 is  desired) is a safe
   choice.
Thanks Tom WB4JWM


locked Re: JTAlert Not Responding When Moving from DX to Local

HamApps Support (VK3AMA)
 

On 15/11/2020 8:21 am, Robert A Wilson wrote:
I converted the HRD database from Access to MariaDB and it seems to be working better.
Wise move.

You likely would have corrected the problem by creating a new HRD Access Log file, importing your old contacts, and setting JTAlert to use that new Log.

In recent months there have been a significant number of HRD users experiencing severe JTAlert slowdown to complete lockup. This was tracked down to a problem with their Access Log, either the log file or the ODBC DSN defined for the Log. The fix in all cases was to create a new HRD Access Log file.

de Laurie VK3AMA


locked Re: Text message window

HamApps Support (VK3AMA)
 

On 15/11/2020 3:29 am, Guy G4DWV 4X1LT wrote:
I can confirm that I have already done as you suggested. Please see screenshot. I have just loaded JTAlert and the text window appeared.

--
73 de Guy G4DWV 4X1LT
Guy,

Are you talking about the popup that is shown when you receive a Text Message (which should not now be happening) or the Text Message window which allows you to compose/send a message?

If it is the latter, does it appear automatically when JTAlert is started or at random times?

de Laurie VK3AMA

5701 - 5720 of 37782