TwoToneDetect New TwoToneDetect in the works - Python based

[DC31]

Andy, i experienced two false actvations last night. It appears that the program detected the tone sets during normal radio transmissions. The recordings in each start in the middle of a routine transmission, not a dispatch. Post # 55 above indicates 0.4 sec tone A and 0.4 sec tone B within 4 sec. We use a tone A duration of about 1 sec.and tone B of about 2.5 to 3 sec. Tone B always immediately follows Tone A. Could one of these be adjusted to reduce the chances of falses?

Thanks

 

[ScanYak]

Andy, I congratulate your work that has been done on this program.
I was wondering on future work/builds if it would be possible to control the length of the tones, specifically the longtone? Our dispatcher manually push a button for a single tone and it will last 2 to 3 seconds. I'm not sure the length required now for the longtone.

 

[rualfire]

Andy, I congratulate your work that has been done on this program.
I was wondering on future work/builds if it would be possible to control the length of the tones, specifically the longtone? Our dispatcher manually push a button for a single tone and it will last 2 to 3 seconds. I'm not sure the length required now for the longtone.

Great work to be sure! I've been running v.24 for the past 2 years with a nightly reboot schedule to account for the hanging


It would be nice to be able to specify the long tone length (QC2 specifies 8 seconds for group call.)

We've switched to a digital radio system and the tones are now simply recorded and replayed across the digital system. The tones are formulated with a traditional two tone with a long station specific tone added afterwords. The station tone is only 5 seconds in duration which is what I'd like to key on so that I can send station specific emails.

Is it possible to add a variable to specify long tone duration?

 

[rualfire]

additional information

I tested it with a 5 second tone and the long tone detection works at this length. I'm not sure what the cutoff is, but I suspect it to be 4 seconds?

 

[aaknitt]

Yes, right now it's four seconds. The way the algorithm works is something like this:

1) Check for A tone or Long Tone frequencies
2) If an A tone or Long Tone is found, check for matching B tones for 4 seconds
3) If no matching B tones are found within four seconds, check for Long Tone frequencies again.

The tricky part is accounting for the situation where an A tone is also used as a long tone. For instance, if 707.3/746.8 is used for one station, while 707.3 long is used for another station. The algorithm above handles this, but makes it impossible to detect a "long" tone that is less than four seconds long.

I've been working on an update that will have some improvements in how the timing can be configured, and these changes may enable detection of oddball tones. It should also enable changes to reduce falsing. I'm sorry for the pause in the releases, I haven't had any time to work on this in the last couple of weeks. I may be able to squeeze some work out this weekend, but I've been pretty tied up recently.

Andy

 

[Manichee]

Just wanted to post and say I have been running this for a couple days now. I am really liking the way the program is working now. The only issue I have right now is with the multiple detection, which may be fixed in your next update I think. Here is an example:

FD1 = 368.5 349.0
FD2 = 389.0 539.0
M1 = 349.0 389.0

This morning FD1 was dispatched with FD2 as autoaid. The program picked the first 2 tones and started recording and sent email to FD1 list, then it grabbed the B tone of FD1 and the A tone of FD2 and started recording and sent email to M1 list. Then it took FD2 tone a and b and recorded and sent email to FD2 list. Now the problem is that M1 was never toned for it. I'm not sure how best to do detection to eliminate this. Just wanted to get that out there and hopefully it made sense.

 

[DC31]

Tough to fix

Assuming the fd1 and fd2tones are stacked, the tone set really becomes 368.5/349.0/389.0/539.0. This string has the M1 tone pair in it. When you are looking for that pair for M1, by design, it is going to activate. Don't the M1 pagers open up during this sequence also? I would expect them to if they are on the same radio frequency. If you are monitoring M1 on a different channel in your scanner you are experiencing the same problem that would exist if two agencies used the same tone set on different channels. The program is monitoring several channels on the scanner feed and not making a distinction between channels. So any valid tone set on any scanned channel is going to cause an actvation.

All that being said, i am no expert on the matter, you will really have to see what andy says

Just wanted to post and say I have been running this for a couple days now. I am really liking the way the program is working now. The only issue I have right now is with the multiple detection, which may be fixed in your next update I think. Here is an example:

FD1 = 368.5 349.0
FD2 = 389.0 539.0
M1 = 349.0 389.0

This morning FD1 was dispatched with FD2 as autoaid. The program picked the first 2 tones and started recording and sent email to FD1 list, then it grabbed the B tone of FD1 and the A tone of FD2 and started recording and sent email to M1 list. Then it took FD2 tone a and b and recorded and sent email to FD2 list. Now the problem is that M1 was never toned for it. I'm not sure how best to do detection to eliminate this. Just wanted to get that out there and hopefully it made sense.

 

[krokus]

This might be a bit tough to fix, but mainly due to having to detect the "gap" between tone sets. (That is my guess, since you are saying the FD1 tone B was paired with FD2 tone A, to trigger the M1 reaction.)

The gap will be harder to detect if the dispatch console is not configured correctly, and the dispatcher's mic is enabled during/between tone sets. (One of my local agencies is like that, I can hear what the dispatcher is doing, between the tone sets for the various stations.) That makes for a lack of silence, which the silence would be relatively easy to detect.

I will also apply the disclaimer that I am not a Subject Matter Expert, I do not play one on TV, and I did not even stay in a Holiday Inn Express.

 

[aaknitt]

Just wanted to post and say I have been running this for a couple days now. I am really liking the way the program is working now. The only issue I have right now is with the multiple detection, which may be fixed in your next update I think. Here is an example:

FD1 = 368.5 349.0
FD2 = 389.0 539.0
M1 = 349.0 389.0

This morning FD1 was dispatched with FD2 as autoaid. The program picked the first 2 tones and started recording and sent email to FD1 list, then it grabbed the B tone of FD1 and the A tone of FD2 and started recording and sent email to M1 list. Then it took FD2 tone a and b and recorded and sent email to FD2 list. Now the problem is that M1 was never toned for it. I'm not sure how best to do detection to eliminate this. Just wanted to get that out there and hopefully it made sense.

Wow that's a good one

I think the next version may help with that problem, since I'm trying to set it up so that you can specify the duration of the B tone. Assuming this is Quick Call 2 timing, you should be able to set the duration of the M1 B tone to greater than 1 second, which should eliminate the falsing in the situation you specify.

Andy

 

[Manichee]

Assuming the fd1 and fd2tones are stacked, the tone set really becomes 368.5/349.0/389.0/539.0. This string has the M1 tone pair in it. When you are looking for that pair for M1, by design, it is going to activate. Don't the M1 pagers open up during this sequence also? I would expect them to if they are on the same radio frequency. If you are monitoring M1 on a different channel in your scanner you are experiencing the same problem that would exist if two agencies used the same tone set on different channels. The program is monitoring several channels on the scanner feed and not making a distinction between channels. So any valid tone set on any scanned channel is going to cause an actvation.

All that being said, i am no expert on the matter, you will really have to see what andy says

There is a slight pause between the tone sets when sent out, so the pagers don't activate for m1 tones. 368.5/349.0/pause/389.0/539.0. I'll try to look back and see if i can find the sequence in an audio file.

 

[fireman1374]

Thank you very much for the new versions!! I have tried v45 and v46, but still keep getting this when the program tries to email.

done converting to MP3
Unhandled exception in thread started by <function alert at 0x041762F0>
Traceback (most recent call last):
File "<string>", line 242, in alert
File "<string>", line 147, in mail
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 242
, in __init__
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 302
, in connect
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 277
, in _get_socket
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/socket", line 553,
in create_connection
socket.gaierror: [Errno 11004] getaddrinfo failed

 

[Manichee]

Thank you very much for the new versions!! I have tried v45 and v46, but still keep getting this when the program tries to email.

done converting to MP3
Unhandled exception in thread started by <function alert at 0x041762F0>
Traceback (most recent call last):
File "<string>", line 242, in alert
File "<string>", line 147, in mail
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 242
, in __init__
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 302
, in connect
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/smtplib", line 277
, in _get_socket
File "E:\Python\build\pyi.win32\TwoToneDetect45\outPYZ1.pyz/socket", line 553,
in create_connection
socket.gaierror: [Errno 11004] getaddrinfo failed

Double check the smtp address in your config file. Also check to see if a firewall is blocking it.

 

[aaknitt]

v48 Released

Well I didn't get much time this weekend to work on this, but I'm going to go ahead and release version 48 anyway, and hopefully it's not too full of bugs.

Version 48 Release Notes:
- Adds support for AMR format file compression in addition to MP3 file compression. In order for AMR support to work, Nokia Multimedia Converter 2.0 must be installed in the C:\Nokia\Tools\Nokia_Multimedia_Converter_2_0 directory. There are separate email lists for mp3 and AMR attachments. See the sample tone.cfg file for details.
*IMPORTANT* - if AMR support is not needed, delete the amr_Emails line for each tone set
- Adds a parameter to the tone config file for B tone length. This allows the user to specify the length of time that the B tone must be succesfully decoded before the program will alert. USE THIS PARAMETER WITH CAUTION. It is recommended that this parameter be set as short as possible but long enough to prevent falsing on "regular" radio transmissions. To keep the behavior the same as in previous versions of the program, set this parameter to .4. If it is set longer than .4, the B tone must be continuously detected for as long as the parameter is set to. If any noise or interference causes another frequency to be measured for any part of this duration, the tone will not decode successfully.

I think the configurable B tone length may also help with the situation with the short long tone (2-3 seconds long). Set it up as an A-B tone with the A and B tone the same frequency, and make the B tone length as long as needed. Not sure if that's a perfect solution, but it may work.

Let me know how this version works. I didn't get to test it much and it doesn't add as many features as I was hoping for, but at least it's something.

Andy

 

[DC31]

Andy, I am now running V46 and V48 in parallel. I have set the V48 to .6 seconds. I just received a false on one tone set in V46 but not V48. In my early trials had had the settings in V48 from .6 to 1.0 and missed some tone sets. I now notice in the activity screen that it checks multiple times for Tone B and lists a frequency below it. Not really sure what this means. I have had some check for Tone B four times before it sent the email. Is this an indication that the Tone B setting is too long? I never saw this in V46.

It seems that there may be some trial and error involved in getting the Tone B duration set optimally.


thanks for your efforts.

Well I didn't get much time this weekend to work on this, but I'm going to go ahead and release version 48 anyway, and hopefully it's not too full of bugs.

Version 48 Release Notes:
- Adds support for AMR format file compression in addition to MP3 file compression. In order for AMR support to work, Nokia Multimedia Converter 2.0 must be installed in the C:\Nokia\Tools\Nokia_Multimedia_Converter_2_0 directory. There are separate email lists for mp3 and AMR attachments. See the sample tone.cfg file for details.
*IMPORTANT* - if AMR support is not needed, delete the amr_Emails line for each tone set
- Adds a parameter to the tone config file for B tone length. This allows the user to specify the length of time that the B tone must be succesfully decoded before the program will alert. USE THIS PARAMETER WITH CAUTION. It is recommended that this parameter be set as short as possible but long enough to prevent falsing on "regular" radio transmissions. To keep the behavior the same as in previous versions of the program, set this parameter to .4. If it is set longer than .4, the B tone must be continuously detected for as long as the parameter is set to. If any noise or interference causes another frequency to be measured for any part of this duration, the tone will not decode successfully.

I think the configurable B tone length may also help with the situation with the short long tone (2-3 seconds long). Set it up as an A-B tone with the A and B tone the same frequency, and make the B tone length as long as needed. Not sure if that's a perfect solution, but it may work.

Let me know how this version works. I didn't get to test it much and it doesn't add as many features as I was hoping for, but at least it's something.

Andy

 

[Jay911]

I just encountered something which at least I didn't expect, but it might be normal behavior.

I can't tell you for sure what version I'm running, because I'm a thousand or two miles away from my monitoring machine. I think it's 46. Our dispatcher just hit our tones, then accidentally hit them a second time before giving the voice alert. I got two emails. One has the end of the first tones (as intended by my setup), the full second set of tones, and then her voice message. The second recording has just the end of the second set of tones, and then her voice message (identical in tone, inflection, etc - clearly the same message).

Did the program record the stream twice simultaneously?

 

[johnmac]

Ok, I have a little issue. I installed v48 and chose my usb sound card, but the input is my soundmax sound card which is intrgrated in the motherboard and is being used for a RR feed. I checked the nixer settings and they seem to be correct. Even though I have selected the correct sound card in the software, the audio from the other soundcard is coming through V48. I did not have this issue w/other versions.

Just loaded v44 and it works fine with the usb sound card!!

 

[aaknitt]

Andy, I am now running V46 and V48 in parallel. I have set the V48 to .6 seconds. I just received a false on one tone set in V46 but not V48. In my early trials had had the settings in V48 from .6 to 1.0 and missed some tone sets. I now notice in the activity screen that it checks multiple times for Tone B and lists a frequency below it. Not really sure what this means. I have had some check for Tone B four times before it sent the email. Is this an indication that the Tone B setting is too long? I never saw this in V46. It seems that there may be some trial and error involved in getting the Tone B duration set optimally.

Yeah I've been leaving a lot of debugging stuff in there. Eventually once the program is "stable" I'll clean it up and remove a lot of that stuff. Basically it's checking for the B Tone every 200 ms. So if you set the B tone length to one second, it's going to take five time samples, each 200 ms long. If any one of them isn't the correct tone, it will fail to decode the tone set. Each time it takes a 200 ms sample it prints the dominant tone frequency to the terminal screen.

I'm not completely happy with this algorithm, as it doesn't really leave much margin for error. I'm thinking of changing it to make it a little less strict, we'll see.

Andy

 

[aaknitt]

I just encountered something which at least I didn't expect, but it might be normal behavior.

I can't tell you for sure what version I'm running, because I'm a thousand or two miles away from my monitoring machine. I think it's 46. Our dispatcher just hit our tones, then accidentally hit them a second time before giving the voice alert. I got two emails. One has the end of the first tones (as intended by my setup), the full second set of tones, and then her voice message. The second recording has just the end of the second set of tones, and then her voice message (identical in tone, inflection, etc - clearly the same message).

Did the program record the stream twice simultaneously?

Yes, it did. That's the intended behavior, and that's what allows the program to handle stacked tone sets (unlike the old LabView version, which would only catch the first tone set in a sequence).

Andy

 

[aaknitt]

Ok, I have a little issue. I installed v48 and chose my usb sound card, but the input is my soundmax sound card which is intrgrated in the motherboard and is being used for a RR feed. I checked the nixer settings and they seem to be correct. Even though I have selected the correct sound card in the software, the audio from the other soundcard is coming through V48. I did not have this issue w/other versions.

Just loaded v44 and it works fine with the usb sound card!!

That's odd, I don't think anything related to sound card selection has changed, but I'd have to go back and look to be sure. Have you been re-using the same configuration file or using the new one that comes with each release? Maybe try manually setting your sound card to "0" in the config file and then reselect it once the program starts and see what that does for you.

Andy

 

[johnmac]

That's odd, I don't think anything related to sound card selection has changed, but I'd have to go back and look to be sure. Have you been re-using the same configuration file or using the new one that comes with each release? Maybe try manually setting your sound card to "0" in the config file and then reselect it once the program starts and see what that does for you.

Andy

I reset the input and output devices to zero, restarted the program and changed the sound cards in the program. Discovered that I had to exit and re-start for it to take effect. Working fine now. Interesting that the input and output values are different numbers in the config file. Now just waiting for some tones to check it out.

Again, thanks for a fantastic program.