MikeOrlando02
Member
- Joined
- Oct 8, 2015
- Messages
- 97
Contacted ATT Postmaster, did not get a reply; however the messages starting going through again a few days later.
TwoToneDetect New TwoToneDetect in the works - Python based
- Thread starter aaknitt
- Start date
-
- Tags
- twotonedetect
MikeOrlando02
Member
- Joined
- Oct 8, 2015
- Messages
- 97
Today, our dispatch center is using their backup radio system and the quality is pretty bad. We are missing every page that is put out. The actual pages are A-Tone 1 Second and B-Tone 3 Seconds.
Here is an example paging set.
Thanks!
Here is an example paging set.
I was going to try lowering my TTD tone length to A-tone 0.4 and B-tone 1.0 to capture the tones. We are not currently using Tone Gap at all. Since my A-tone is really 1.0 and I have it set to 0.4, do I need to set my gap minimally to 0.6 so it ignores the remainder of the A-tone before seeking the B-tone? Should I increase this gap to 0.8 so if there is any warble between A-B that 200ms disregarded as well?
Thanks!
Each line represents a 200 ms sound sample (0.2 sec). So in the first tone set shown above you are hearing 0.6 sec of tone A. In the second, you are hearing 0.4 sec of tone A. If you set your tone length to something longer than these values, you will not get a decode. It isn’t apparent from these if there is a gap. If you are listening, is there a noticeable gap between the end of the A tone and the start of the B tone? If so, use the gap parameter. No need to use the gap for the end of the A tone. The program really only counts the end samples of the A tone and the beginning samples of the B tone.
Has anyone seen instances of TTD cutting off recordings at 55 seconds? I have TTD running on a Raspberry Pi and configured to record dispatches and send them via Telegram to a group. It also plays the dispatch live through a speaker on the Pi. Details on my setup are here.
But on longer dispatches, TTD cuts off the recording and the live audio at 55 seconds and I can't figure out why. It typically cuts off in the middle of the dispatcher talking, so it's not a situation where TTD thinks it's silent. What happens is that 1) the live/local audio cuts off suddenly 2) the recording is sent to telegram normally, but cuts off in the same place - at 55 seconds.
Shorter recordings are working correctly with the dispatch followed by a 15 second silence. It just seems that there's something in my config or TTD itself that limits the recordings to 55 seconds.
Anyone seen similar or have any advice on how to troubleshoot?
But on longer dispatches, TTD cuts off the recording and the live audio at 55 seconds and I can't figure out why. It typically cuts off in the middle of the dispatcher talking, so it's not a situation where TTD thinks it's silent. What happens is that 1) the live/local audio cuts off suddenly 2) the recording is sent to telegram normally, but cuts off in the same place - at 55 seconds.
Shorter recordings are working correctly with the dispatch followed by a 15 second silence. It just seems that there's something in my config or TTD itself that limits the recordings to 55 seconds.
Anyone seen similar or have any advice on how to troubleshoot?
Last edited:
MikeOrlando02
Member
- Joined
- Oct 8, 2015
- Messages
- 97
Could you be hitting a ~60 second timeout?
If the Audio Squelch Level is set too low, the program will continue to detect audio even when there is no radio traffic present, and the recording will continue until a 60 second timeout occurs after the Record Time expires. If your audio recordings are about 60 seconds plus your Record Time, you probably need to adjust your Audio Squelch Level up a bit.
At 55 seconds those are some long pages.
MikeOrlando02
Member
- Joined
- Oct 8, 2015
- Messages
- 97
I have been working on shortening my A and B tone length for more lenient detection when our backup dispatch is in use. Shortening that detection time seems to have messed with the balance I had in detecting the end of the first page and start of the second, I would like these to be two different files. For some reason I had been using a strange Release Time of 0.05, which I presume should be in 200 ms increments so I am currently testing at 0.4. Today, I got a traceback...
I have been monitoring pages and got a notification this AM, but then link was broken and file hadn't been uploaded. How should this feature work - "found a new tone to add to an existing alert thread - killing this one". It seems to have killed... meaning deleted the file it recorded and only recorded the second page. This is not desirable for me, I am all good on stopping the first recording and then starting a second when it detects the second page. But my first recording had already stopped, why did the software delete the first page, not send alerts or FTP upload?
Shortly after I got a traceback, see log file.
I have been monitoring pages and got a notification this AM, but then link was broken and file hadn't been uploaded. How should this feature work - "found a new tone to add to an existing alert thread - killing this one". It seems to have killed... meaning deleted the file it recorded and only recorded the second page. This is not desirable for me, I am all good on stopping the first recording and then starting a second when it detects the second page. But my first recording had already stopped, why did the software delete the first page, not send alerts or FTP upload?
Shortly after I got a traceback, see log file.
Hmm, I guess that's possible. I have played with the squelch, but usually moving it down (thinking that maybe it's accidentally detecting silence). I will try to adjust it up. RTL-Airband does a good job of only sending audio when the frequency is actually active.
Yeah, they are. These are usually the working fires with 10 or so units assigned. Tones for each station and batallion then dispatch calls out each unit. Not uncommon for all of that to take 30-40 seconds before they actually call out the incident. Problem is that they do the talkgroup assignment at the end, so when it cuts off I miss that and have to go hunting.
could you share your configuration file (config.cfg) and the information on one of your tone sets from tones.cfg?
Sure thing. I actually did a writeup of the entire config in another post that includes the config files and all the details I could think of. It's in the link below. The only thing that has changed since then is adding a notch filter into the rtl-airband config to cut out the CTCSS tone.
[Guide] TwoToneDetect with RTL-SDR and local audio
Lots of information in that other post. However, if we are going to troubleshoot your current setup, we are going to need the current tones.cfg that you are using. Obviously, your current setup uses totally different tone sets and descriptions than what you previously posted.
i also use rtl_airband as analog source for TTD on a pi and it works very well. The same calls are dispatched over a P25 digital system. I have another pi running boatbod OP25 on that and feeding audio into TTD on the same pi. Works like a charm. All calls are sent out as push notifications through IaR and Pushover. I ditched emails/texts 2-1/2 years ago.
Fair enough, however the configs in that post actually are from my real configs (with some redactions). The full contents of the current config/tones files are below. There are a few variations from what's in the post above, however these were all made trying to troubleshoot this issue. Both versions have the same problem with cutting off some longer dispatches.
tones.cfg
Code:
[Tone1]
Atone = 669.9
Btone = 617.4
Atonelength = 1
Btonelength = 1
Description = St. 2 - Woodland
record_delay = 0
record_seconds = 0
release_time = 30
playback_during_record = 1
alert_command = curl "https://api.telegram.org/[redacted]/sendMessage?chat_id=[redacted]" --data-urlencode "text=Dispatch for [d]"
post_email_command = curl -F document=@"[mp3]" https://api.telegram.org/[redacted]/sendDocument?chat_id=[redacted]
[Tone2]
Atone = 669.9
Btone = 651.9
Atonelength = 1
Btonelength = 1
Description = St. 3 - Riva
record_delay = 0
record_seconds = 15
release_time = 30
playback_during_record = 1
alert_command = curl "https://api.telegram.org/[redacted]/sendMessage?chat_id=[redacted]" --data-urlencode "text=Dispatch for [d]"
post_email_command = curl -F document=@"[mp3]" https://api.telegram.org/[redacted]/sendDocument?chat_id=[redacted]
[Tone3]
Atone = 707.3
Btone = 651.9
Atonelength = 1
Btonelength = 1
Description = St. 7 - Davidsonville
mp3_Emails = email@address.com
record_delay = 0
record_seconds = 15
release_time = 30
playback_during_record = 1
alert_command = curl "https://api.telegram.org/[redacted]/sendMessage?chat_id=[redacted]" --data-urlencode "text=Dispatch for [d]"
post_email_command = curl -F document=@"[mp3]" https://api.telegram.org/[redacted]/sendDocument?chat_id=[redacted]
[Tone4]
Atone = 669.9
Btone = 553.9
Atonelength = 1
Btonelength = 1
Description = Batallion 3
mp3_Emails = email@address.com
record_delay = 0
record_seconds = 15
release_time = 30
playback_during_record = 1
alert_command = curl "https://api.telegram.org/[redacted]/sendMessage?chat_id=[redacted]" --data-urlencode "text=Dispatch for [d]"
post_email_command = curl -F document=@"[mp3]" https://api.telegram.org/[redacted]/sendDocument?chat_id=[redacted]
[Longtone1]
Longtone = 707.3
Longtonelength = 6
Description = Long Tone Page
amr_emails = email@address.com
record_delay = 2
record_seconds = 15
release_time = 3
ignore_after = 60config.cfg
Code:
[Section1]
email_user = emailuser@address.com
email_pwd = cGFzc3dvcmQ=
email_server = localhost.local
email_port = 587
input_device_index = 5
output_device_index = 5
audio_threshold = 222.86094420380775
tone_offset = 0.0
mp3_bitrate = 32000
bcc = 0
email_priority = 3
audio_channel = mono
email_from = emailuser@address.com
instance_id = none
email_security = STARTTLS
email_authentication = 1
email_send_sequential = none
upload_ftp_server = ftp.yourserver.net
upload_ftp_port = 21
upload_ftp_username =
upload_ftp_password =
upload_file_prefix = http://www.example.come/audio/
upload_ftp_remote_path = /audio/
copy_from_email = 0
start_headless = 1
allow_remote_access = 1
gui_remote_access_port = 8081
record_release_time = 10
iar_api_key =
update_interval = 60.0Some things to try as starters:
1. Set both Atone and Btone lengths to 0.6
2. remove the special characters (. -) from your descriptions. Use underscores as separators, i.e., Battalion_3
3. Set all your record_seconds parameters to 30
4. Set all your release_time to 3
5. Add this to your config.cfg: stacked_extend_record = 1
6. In config.cfg set record_release_time = 3
BTW, do you know what version of TTD you are running?
Thanks for the reply here. It's been a few days since we've had one of those really long dispatches (probably a good thing since they're usually structure fires), so I haven't been able to test changes. In the mean time:
Running version 74d right now. I've been keeping up with updates while trying to fix this and it's happened across the last 5-6 versions.
1. Set both Atone and Btone lengths to 0.6
I can try this, but my local department actually publishes that the tones are 1 second. Will a shorter tone length mess with detection? That part has been pretty rock solid.
2. remove the special characters (. -) from your descriptions. Use underscores as separators, i.e., Battalion_3
Done
3. Set all your record_seconds parameters to 30
Done
4. Set all your release_time to 3
I will try this, but I have it set long because it's not uncommon for our dispatchers to pause while they get additional information. The long release time helps with that.
5. Add this to your config.cfg: stacked_extend_record = 1
I'll add this, but I haven't seen this one before. Any idea what it does?
6. In config.cfg set record_release_time = 3
Same answer as #4
Better to have your lengths set to slightly less than the published. If your Atone length is set to 1.0 and for some reason the radio/computer only hears 0.9 sec of it, you don't decode. Set it to 0.6 and you will reliably get the decodes. Same for BTone.
It is likely that your 30 sec setting here is the root of your problems. Every time there is a bit of radio traffic it resets the timer to wait for 30 more seconds. There is a maximum timeout in the program that I don't remember offhand but the repeating resets of your timer likely are hitting it. Better to set a longer record_seconds and a lower release_time. (better yet, train the dispatchers to be concise)
It was added during some revision to the program and isn't well documented. My understanding is that when it detects stacked tones it doesn't start recording the audio until the last tone is completed, then sends the same audio recording to all the appropriate agencies in the stacked tone sets. Entering this setting will also likely help considerably if you are seeing stacked tones.
According to some program notes that I have found, there is a 60 second timeout on the recorded audio. This is hard-coded in the program and not user-configurable. If your long pages involve stacked tones, then the stacked_extend_record will help.
(Edit) Note also that the stacked_extend_record only works with tone sets that are included in your tones.cfg. If you haven't entered a tone set in your tones.cfg, the program thinks that it is just plain audio.
Finally had a long page this morning that cut off. This one was 1:10 with some pauses in between some of the tones. It doesn't look like this one stacked tones/pages (I only got a notification for 1 station).
Here's a link if you want to hear the recording.
I'm making the rest of the changes you suggested now to continue testing.
MikeOrlando02
Member
- Joined
- Oct 8, 2015
- Messages
- 97
I have been noticing sporadic issues with my /logfiles/known_hosts file contents being wiped out and the file being empty. This prevents my audio from being uploaded via SFTP. I created a script that periodically checks the /logfiles/heartbeat.txt file and then the contents of the known_host file. Here are my results for the last three months:
2023-04-28 08:31:52,919 (WARNING) - Line:135 - *** knownhosts Repaired ***
2023-05-28 10:16:01,672 (WARNING) - Line:135 - *** knownhosts Repaired ***
2023-06-28 11:23:18,464 (WARNING) - Line:145 - *** knownhosts Repaired ***
This only appears to be occurring on the 28th of each month. Is there some sort of monthly cleanup task or other component built into TTD that runs on the 28th of the month? If so, it seems to be erasing the contents of the /logfiles/known_hosts.
2023-04-28 08:31:52,919 (WARNING) - Line:135 - *** knownhosts Repaired ***
2023-05-28 10:16:01,672 (WARNING) - Line:135 - *** knownhosts Repaired ***
2023-06-28 11:23:18,464 (WARNING) - Line:145 - *** knownhosts Repaired ***
This only appears to be occurring on the 28th of each month. Is there some sort of monthly cleanup task or other component built into TTD that runs on the 28th of the month? If so, it seems to be erasing the contents of the /logfiles/known_hosts.
Just an update. These settings are definitely working better than what I had originally. I suspect the issue is still there (I see some recordings come really close to cutting off), but these timings seem to run long enough to make up for any weirdness with the release times. A lot more of my recordings run long (multiple dispatches), but I think that's just due to the longer record_seconds parameter. I have not lost the end of a dispatch since I change to these timings. Thanks again for the help, even if I need to tweak further this gives me a much better starting point.
Hi, i am running the 64 bit version Debian Bullseye, would this still work? Rasperry Pi OS 32 bit
Similar threads
