Change to the feed for San Diego City and Poway Fire

[celbaseman]

I have upgraded the feed configuration for the San Diego City and Poway Fire feed https://www.broadcastify.com/listen/feed/10294

The feed is now running on a program called trunk recorder which uses SDR's instead of a scanner. The computer records the audio and then pushes it up to broadcasify. The advantage to this is that the SDR's are always monitoring the control channel. Plus the SDR's can record several talk groups at the same time and as they end they are pushed up to broadcastify. If all works correctly, this configuration should not miss a single transmission as, at times, several talk groups can be communicating at the same time.

I have also added medics to the feed -- so it is really busy now.

FYI, The SD city and Poway fire feed is the feed that provides audio to Pulsepoint as well as being able to be heard on many of the phone apps.

Any feedback positive or negative would be greatly appreciated either on this forum or in DM.

The feed might go up and down as I make adjustments.

 

[Anderegg]

How about priority, if not already, for 7B, and maybe add a "scanlist" for the fire tac channels that you would only enable during a major incident that you were aware of (or overnight when it's less busy), as not to lock the feed up with firefighters doing alarm testing and such

Make sure you don't add 7D...barf.

Paul

 

[disp10]

I wouldn't include 7C either. It's for the ambulance system status control and can be very busy.

As a side note I think the traffic from 7D has been moved to AMR dispatch on the RCS. I haven't heard much on it in awhile.

 

[celbaseman]

Thanks for the feed back.

I have "locked out" 7C, the medic SCC
7D is not active, but I left it out anyway.
7E EMS command channel is on.
EMS tacs 7F and 7G are "locked out" usually traffic about where the park the ambulance..

At this time, there is no way to prioritize a talk group over another. The feed computer records talk group I have told it to record -- then as each transmission ends, that MP3 is queued and sent to broadcastify.

I have noticed that during dispatches the dispatch is broken up into separated recordings. I think this is because some dispatchers unkey and rekey during the dispatch. Since this program is monitoring the control channel this is sensed and the audio file is created, then a new one is started when the dispatch continues. Unfortunately if another audio file is queued, then it interrupts the dispatch. That is a problem I am looking into.

When FD is busy with an incident -- the voice files are queued up and wait their turn to be sent to broadcastify. I noticed the other night, a call for a gas leak, a TC on I5 and a problem with trees near downtown had the radio very busy. At one point I figured the feed was about 10 minutes behind real time. But, looking at log files, every single transmission was recorded and uploaded.

I know Tac channels adds traffic - but sometimes this is where the action is really heard. The problem with enabling Tac channels during major incidents is, when the recording program starts, it reads a config file and I would have to halt the program and start it with a different config file. Not easy since I don't have easy access to the computer 24 hours.

More information about how this setup was built -- check out https://wiki.radioreference.com/index.php/Streaming_with_Trunk_Recorder_and_Liquidsoap

 

[Anderegg]

The ability to have access to all transmission recordings is a real benefit for the media. I can't tell you how many times my station has tried to snag an officer involved shooting incident or similar, only to have the remote scanner listening to the wrong talkgroup at that time. My other pet peeve is scanner feeds of analog channels that have extremely weak reception...static + extreme stream compression = please shoot me!

As for fire tacs, might want to add the 8O and 9O channels, they work as sort of an interop for Copter 1 and 2 on incidents. Also, you may find it safe to add 8C/F/I and 9/C/F/I to the stream, as those are the tac channels that would only go active during a large incident where they require additional tac channels, like a 2/3rd alarm fire. Better to have some extra transmissions in a large incident than no extra.

Paul

 

[celbaseman]

Paul, I do have the 8C/F/I and 9C/F/I in the list as well. I need to update info page of the feed.

As for the "O" channels, I need to look at the rules from broadcastify about interop channels. I do like your idea.

Earl

 

[Anderegg]

Maybe interop is the wrong word...typically they would have them on 8O and 9O working as an air to ground for brush fire ops in the city. Never hear any outside agencies using those channels.

Paul

 

[blantonl]

I have upgraded the feed configuration for the San Diego City and Poway Fire feed https://www.broadcastify.com/listen/feed/10294

The feed is now running on a program called trunk recorder which uses SDR's instead of a scanner. The computer records the audio and then pushes it up to broadcasify. The advantage to this is that the SDR's are always monitoring the control channel. Plus the SDR's can record several talk groups at the same time and as they end they are pushed up to broadcastify. If all works correctly, this configuration should not miss a single transmission as, at times, several talk groups can be communicating at the same time.

I have also added medics to the feed -- so it is really busy now.

FYI, The SD city and Poway fire feed is the feed that provides audio to Pulsepoint as well as being able to be heard on many of the phone apps.

Any feedback positive or negative would be greatly appreciated either on this forum or in DM.

The feed might go up and down as I make adjustments.

Some good news coming soon.

We're getting ready to roll out support later this spring and into early summer for Trunk Recorder and other SDR based clip archiving solutions to be able to host all the clips and metadata on Broadcastify.

This means we'll provide a centralized platform for free storage and management of all the audio and metadata for these instances. Broadcasters will have the ability to access ALL traffic that their SDR ingest systems generate, while the public will be able to access all traffic that meets Broadcastify's terms of service.

Stay tuned!

 

[celbaseman]

Paul, per your suggestion - have added TG's 7, 8, and 9 O to the feed.

 

[SDBud]

Maybe interop is the wrong word...typically they would have them on 8O and 9O working as an air to ground for brush fire ops in the city. Never hear any outside agencies using those channels.

Paul

Those channels were originally designed for interop between PD and FD, but they never got used much, and few even know about them now.