Callsign Alert by Band

8 posts / 0 new
Last post
VE2EVN
Callsign Alert by Band

Hello,

I've noticed that the callsign alert by band does not seem to work.

I set J5T, 15M , All Modes. -- Nothing.
If I set J5T, All Bands, All Modes. -- I get alerts.

It would be nice to be able to set more than one band as well, but if it's not possible and means setting multiple alerts, as long as the per Band works, I can live with that.

The partial call alert doesn't work either, but I believe that bug is already known.
I Tried to use both J6 and J6*. Neither one worked (and yes, I had the 'Allow partial callsign alert' selected.

Marc-Andre, VE2EVN/VA2EI

oh1kh
Callsign Alert by Band

HI Marc-Andre

Tested also the alert a little bit.

We had some different opinions with Petr at the time this partial callsign clause was added.
Now source has:
'select * from call_alert where callsign regexp %s'
where the %s is the callsign coming from DXCluster and 'callsign' is one of alerted calls list.

should be:
'select * from call_alert where %s regexp callsign'

You can easily test it by making your list of partial callsigns to your alert callsigns list.
Then open OSQ list/Filter/SQL console and copy that source line to it with replacing the %s with uppercase callsign that you imagine is coming from DXCluster.
When you press upper green arrow and have some results then alert may hit (if band and mode are ok, see below)

You may test with both 'select * from call_alert where callsign regexp %s' and 'select * from call_alert where %s regexp callsign'
and see what the difference is.

Next regexp syntax must be right. Otherwise it will not hit, or hits unwanted calls.
Regexp syntax can be found from many places. One is : https://en.wikipedia.org/wiki/Regular_expression#Delimiters
Asterisk may lead to unwanted result.

In current source if mode and band are empty and callsign result from alert calls list is the call then alert hits.

If they are not empty they are ANDed, so both mode and band must be true before hit. This is also true if other is empty
and other has content. They still are ANDed that leads to impossible situation and does not hit in any case.
The check should first done in case other band or mode is empty for both cases and finally if they do not hit then
to situation where both have contents and they both hit.

And also states saving of "call alert" and "partial call alert" checkboxes, specially the "partial" one, is done quite complicated way but finally seems to result ok. I would prefer saving them right away from "on change" event.

This saving is important as alerting for incoming DXCluster call is done only if saved state of checkbox is true.

While writing this and checking the source code I had a test alert running in cqrlog and I did not get any results (with partial calls checked).
Next I will try to make these changes to my devel version and see if I'm right with these.

--
Saku
OH1KH

oh1kh
Callsign Alert by Band

HI Marc-Andre

I have now rewritten parts of call alerting routines and it looks promising. How ever it needs still more testing before pull request.
Unfortunately I'm traveling during weekend and can not do further tests.

If you and/or someone other reading this is willing to test DXCluster alert calls, specially the partial call alerts, it would be nice.
I have pushed source to github https://github.com/OH1KH/cqrlog-devel and ready compiled binary for x86_64 can be found from http://www.saunalahti.fi/sakny/bin/cqrlog2/

Testing binary is just: backup your logs, then replace current binary file (usually /usr/bin/cqrlog) with the cqrlog file found from zip file.
I did made a test script to see alerts:

!/bin/sh
#
echo 'Alert: '$1' '$2' '$3' '$4 >> /home/saku/lazarus/cqrlog_work/testalert.txt
#
#Set cqrlog/preferences/DXCluster/Run this command when callsing is spotted:
# /home/saku/lazarus/cqrlog_work/testalert.sh $CALLSIGN $BAND $MODE $FREQ
#
# Then use:
# tail -f /home/saku/lazarus/cqrlog_work/testalert.txt
# to see coming alerts

Change path names and remember to chmod u+x the scipt file before usage.

I would be happy to hear comments about test results.

--
Saku
OH1KH

File: 

oh1kh
Callsign Alert by Band

Alert callsigns had also open transaction with same query/transaction pair that is used in wsjtx/worked grids.
That caused alert callsigns list disappear if wsjtx remote was open and new decoding was done.

For latest test binary I have created own query/transaction pairs only for wsjtx/worked grids usage.
That may have effects also to something else that might have suffered for wsjtx remote / grid map usage.

--
Saku
OH1KH

oh1kh
Callsign Alert by Band

Test results of partial callsign alert:

Partial callsign alert targets:

#calls having number 4  @ 40m/SSB
#calls starting VK  all band/all mode
#calls starting	ZL  all band/all mode
#calls having number 4  @ 40M/CW
#calls staring with EA @ 20M/RTTY
#calls having numbers 1, 2 or 3 @30M/all mode
#calls having numbers 7 and 9  @ 15M/SSB

Targets in form they appear in database 
(and in Callsign alert form. Excluding id there):
MariaDB [cqrlog004]> select * from call_alert;
+----+----------+------+------+
| id | callsign | band | mode |
+----+----------+------+------+
|  1 | [4]      | 40M  | SSB  | 
|  2 | ^VK      |      |      | 
|  3 | ^ZL      |      |      |
|  4 | [4]      | 40M  | CW   |  
|  5 | ^EA      | 20M  | RTTY | 
|  6 | [1-3]    | 30M  |      |  
|  7 | [7,9]    | 15M  | SSB  | 
+----+----------+------+------+
7 rows in set (0.00 sec)

Result of running alert script:
Alert: R1853S 30M CW 10.1237
Alert: EO25PWC 30M CW 10.1131
Alert: UR4KWU 40M SSB 7.0729
Alert: JA4IAQ 40M SSB 7.0763
Alert: HA3HZ 30M CW 10.136
Alert: IQ4FD 40M CW 7.0275
Alert: JA1FUI 30M CW 10.136
Alert: UR4KWU 40M SSB 7.073
Alert: IQ4FD 40M SSB 7.116
Alert: UR4KWU 40M SSB 7.073
Alert: OK1XHC 30M CW 10.136
Alert: 4U1A 40M CW 7.016
Alert: R1853S 30M CW 10.1265
Alert: IQ4FF 40M SSB 7.093
Alert: EA4EQ 40M SSB 7.067
Alert: 4U1A 40M CW 7.016
Alert: EA4EQ 40M SSB 7.064
Alert: EA4EQ 40M SSB 7.067
Alert: ZL2OK 80M SSB 3.795
Alert: OT4I 40M SSB 7.159
Alert: ZL2OK 80M SSB 3.795
Alert: OT4I 40M SSB 7.159
Alert: G4OJY 40M SSB 7.159
Alert: EO25PWC 30M CW 10.1165
Alert: R7LZ/1 30M CW 10.113
Alert: G4OJY 40M SSB 7.158
Alert: IQ4FA 40M SSB 7.115
Alert: R7LZ/1 30M CW 10.113
Alert: R7LZ/1 30M CW 10.113
Alert: IK4GRO 40M SSB 7.156
Alert: ZL2OK 80M SSB 3.796
Alert: R7LZ/1 30M CW 10.1131
Alert: SV1JDZ 30M SSB 10.144
Alert: OT4I 40M SSB 7.158
Alert: 3B8CF 30M CW 10.114
Alert: 4U1A 40M CW 7.023
Alert: 3B8CF 30M CW 10.114
Alert: EA4EQ 40M SSB 7.068

So this looks good and after a bit more testing is ready for pull request.

--
Saku
OH1KH

DL7OAP
Hi

i installed the developer version 2.01 (138) and did now configure the partial alert for the dxcluster. i will have a look in the next days and give feedback.

at the moment its working fine. filtering for / and VK and ZL.
the shell scripts prints correctly only the wanted callsigns and starts a mp3-file to wake me up.

still gets cleared callsign alert list with dev 138, when using wsjtx-cq-monitor and wsjtx is start/end a transmission.

73 de DL7OAP, Andy

DL7OAP
in version 2.01 dev 138 i can

in version 2.01 dev 138 i can now reproduce the clearing of the callsign alert list.
its in the moment when wsjtx-cq-monitor is filling the "new qso" form via remote.
so it seems there is also a relation between the new qso GUI and the callsign alert list.
73 de DL7OAP, Andy

oh1kh
Thanks again Andy!

Thanks again Andy!

I will look that for next job.
Open transaction at alert calls list seems to make several problems.

--
Saku
OH1KH