Why I won't be moving my feed to Broadcastify Calls

[ChrisABQ]

As a long time feed provider using Windows 10, broadcasting using Uniden BCD996P2 feeding with Scannercast with alpha tags, being part of this new Broadcastify Calls is not going to happen for me. My feed that I host is something that I do to share information with my community and hopefully encourage others to get into the hobby.

I simply will not take more time to have to adapt to a whole new system for this new service. If in the future all feeds will have to comply to this new streaming standard, I'm sorry to say, that my feed will see it's end of life. As of now, my feed system basically runs on auto pilot. I do not have time to play around with new programs and computer headaches to accomplish the goal of working with this new service.

Unless this new service can utilize current equipment that is being used by people like me, I don't really see a site-wide changeover.

 

[Reconrider]

Unless this new service can utilize current equipment that is being used by people like me, I don't really see a site-wide changeover.

I don’t understand the bcalls system. It seems like a step down from the normal feed.

With a feed you can use a scanner and have multiple agencies being listened to

With bcalls you have one

 

[nick0909]

On the flip side, I am fully excited for the Calls system. It allows me to ingest my two local trunk systems, which are both very busy, in whole. I currently provide 2 standard/old streams and 2 Calls streams. On my old stream everyone is forced to listen to the scan list that I picked and hope works best, but a big incident could be happening on one PD dispatch channel but another is tying up the stream with boring routine traffic and the listener just has to hope the scanner hits the channel they want to hear.

On the new system I run 22 recorders (in software) to save and send every call on the trunk systems and the user can pick their own scan list that THEY actually want to hear. And using the custom playlists THEY can pick whatever it is they want to listen to, including from multiple systems/agencies.

The system is still early in development, there are things that could be better about it, but the framework is there and the interface is improving all the time. It is also harder to set up on the feed provider side than simply plugging a scanner in to an audio port and hitting go, so I understand it won't have as many people interested in doing it, but I think versatility it provides is well worth it for me. I don't see the standard stream going away any time soon either, so I don't really think it is worth getting too worked up about, just provide the stream you enjoy and continue to enjoy it.

 

[tk000]

I don't believe anyone's forcing or requiring you to do anything.

And I'll again point out that the concept and functionality of Calls already exists at OpenMHz.

 

[RFI-EMI-GUY]

On the flip side, I am fully excited for the Calls system. It allows me to ingest my two local trunk systems, which are both very busy, in whole. I currently provide 2 standard/old streams and 2 Calls streams. On my old stream everyone is forced to listen to the scan list that I picked and hope works best, but a big incident could be happening on one PD dispatch channel but another is tying up the stream with boring routine traffic and the listener just has to hope the scanner hits the channel they want to hear.

On the new system I run 22 recorders (in software) to save and send every call on the trunk systems and the user can pick their own scan list that THEY actually want to hear. And using the custom playlists THEY can pick whatever it is they want to listen to, including from multiple systems/agencies.

The system is still early in development, there are things that could be better about it, but the framework is there and the interface is improving all the time. It is also harder to set up on the feed provider side than simply plugging a scanner in to an audio port and hitting go, so I understand it won't have as many people interested in doing it, but I think versatility it provides is well worth it for me. I don't see the standard stream going away any time soon either, so I don't really think it is worth getting too worked up about, just provide the stream you enjoy and continue to enjoy it.

Nick;
Can you explain how you are able to record every call in the trunk system? Are you using SDR? How does Calls parse out the talk group IDs?

 

[nick0909]

Nick;
Can you explain how you are able to record every call in the trunk system? Are you using SDR? How does Calls parse out the talk group IDs?

Yes, I'm using an SDR, one per system. They are both on the same PC running Linux. I have a $40 Nooelec that covers about 2.2mhz of bandwidth, which covers my city's P25 system, and a $100 Airspy Mini that covers about 5mhz of bandwidth which lets me cover my whole county P25 P2 system. They are both using Trunk Recorder software that records every call and uploads them, along with metadata about the call, to the Calls system. Calls then uses the metadata to parse out which TG that call was for. Now that Calls has every bit of activity on the system I can build custom scan lists for whatever I want, or use the recordings like a DVR to go back and listen to a specific incident that maybe wasn't on a TG that I would normally have enabled.

 

[blantonl]

Ok, Thanks for your feedback Chris

 

[RFI-EMI-GUY]

Will this service have better fidelity than the old? The old seems too compressed and it rings. I think many feed operators had little experience in matching audio levels or the importance of balanced to unbalanced audio termination to a sound card.

 

[blantonl]

Actually, time for me to rant:

I don't know if it's the COVID, or something in the water, or the economy etc... but lately this month I've run into a spate of spicy feed providers. You would think I showed up on everyone's doorsteps, forced their arm behind their back, and demanded they provide a feed to Broadcastify. It's been rather nutter-butters, and some seem to think that THEIR feed puts a million dollars a month in my pocket. I mean, of course, this business is wildly successful, but instead of seeing the shared value between both providers and this platform, some seem to make it a one-sided argument. Some of the crazy stuff this month:

First, we've implemented a trial of pre-roll advertising on feeds, and we had a few feed providers that absolutely went nuts over it - demanding that I take them off, proclaiming that "you can't do that to the feed that I've provided to you for 32 years!" etc and just generally got all bent out of shape about it, like I kicked their dog or something.

Second, we had a feed provider in Minneapolis last week just unilaterally decide to add law enforcement tactical channels to his FIRE feed, in complete and total violation of our terms of service, and when I questioned him about it he told me to pound sand, and then launched into a huge tirade of homophobic slurs, called us a " rinky-dink piece of **** company" and other deplorable and unprofessional communications. (Yeah: you Andy Ludowese in Minneapolis).

And then...

As a long time feed provider using Windows 10, broadcasting using Uniden BCD996P2 feeding with Scannercast with alpha tags, being part of this new Broadcastify Calls is not going to happen for me. My feed that I host is something that I do to share information with my community and hopefully encourage others to get into the hobby.

I simply will not take more time to have to adapt to a whole new system for this new service. If in the future all feeds will have to comply to this new streaming standard, I'm sorry to say, that my feed will see it's end of life. As of now, my feed system basically runs on auto pilot. I do not have time to play around with new programs and computer headaches to accomplish the goal of working with this new service.

I mean, let me set the table here... no pun intended.

This is analogous to Thanksgiving Day ChrisABQ showing up to grandma's house for turkey dinner, and grandma letting everyone know that Squash Casserole is on the menu today. And Chris here decides to loudly and aggressively proclaim that:

"I'm not eating squash casserole. Turkey Dinner has always been turkey, stuffing and green beans, and that is it. I WILL NOT EVEN TRY IT and if it is passed my way, everyone, MAKE NOTE, I WILL NOT BE TAKING A SERVING" Sheesh. Could have just said to yourself, I'm not eating that today. But nope, everyone is going to be told in no uncertain terms what's up. Meanwhile, Grandma is like - WTF?

Look, I'm excited about Broadcastify Calls, but no one has issued any edicts that you gotta move things to that in one month. We're slowly building it out, testing the viability of the platform, and we've got a LOT of work to do. We haven't mandated anything, and it's mostly a hobby for this business right now. I hope that it becomes our new direction though over the next few years. That's it.

/Rant Off

 

[KD0TAZ]

As a long time feed provider using Windows 10, broadcasting using Uniden BCD996P2 feeding with Scannercast with alpha tags, being part of this new Broadcastify Calls is not going to happen for me. My feed that I host is something that I do to share information with my community and hopefully encourage others to get into the hobby.

I simply will not take more time to have to adapt to a whole new system for this new service. If in the future all feeds will have to comply to this new streaming standard, I'm sorry to say, that my feed will see it's end of life. As of now, my feed system basically runs on auto pilot. I do not have time to play around with new programs and computer headaches to accomplish the goal of working with this new service.

Unless this new service can utilize current equipment that is being used by people like me, I don't really see a site-wide changeover.

On the contrary, it has the potential to substantially increase the number of monitored systems. Why? Ask yourself this - what is the biggest barrier to entry when it comes to providing a feed for a digital system? Obviously it's the scanner. Not everyone has a spare $400+ laying around to just dedicate to providing a feed. Calls requires nothing more than a $30 dongle (maybe two) and a computer. Now that SDRTrunk has Calls integration, the "Windows user who doesn't know Linux" barrier is gone.

I've been providing feeds a whole lot longer than you have, and when I heard about the Calls platform I could not wait to get it set up - because even small town traffic pushes and sometimes exceeds the limits of a regular streaming feed on a hardware scanner.

I don’t understand the bcalls system. It seems like a step down from the normal feed.

With a feed you can use a scanner and have multiple agencies being listened to

With bcalls you have one

The HUGE problem with a scanner based feed is that even though you can program a lot of TGs into it, it can only receive one channel at a time. Even when you've only got one smallish town's police/fire/EMS programmed, during an emergency there will be a lot more traffic, and could be Event/Fireground groups in use. Simultaneous transmissions get missed - that's the issue I've run into with my own feed monitoring 6 TG's. There was a feed that was up for a few years a couple counties over from me (it has recently gone dark) which had every talkgroup on a P25 site covering literally 15,000 square miles. It was an unlistenable disaster, because it was monitoring so many different agencies over such a large area on a single hardware scanner that you never heard a complete conversation. With SDR and Calls, the "ingester" can receive and record multiple calls simultaneously, which then get uploaded to the system and are available for playback sequentially. It also allows access to other agencies that a standard streaming feed on a hardware scanner would not be set to monitor. For example, due to the clutter issue, I did not have anything in my feed besides my local police/fire/EMS. Adding other agencies would have required setting up separate feeds, each needing me to buy another $400 scanner. Now that I have switched to SDRTrunk, I can still provide that streaming feed (vastly improved now that it can record and queue simultaneous calls into the stream), but since the P25 site it comes from simulcasts traffic from several surrounding counties, far more is now available on Calls using a $30 dongle than I'd ever be willing to invest in a bunch of digital scanners for.

 

[Mr_Boh]

@blantonl - I think some of the spiciness is just people who don't understand how to make it work, and are worried they are going to loose some clout or something of being a provider.

I am completely astonished how quickly the API was adopted by several pieces of software. TrunkRecorder can be daunting, particularly if you don't know Linux. But there are so many options now - SDRTrunk, Trunking Reorder, VOXCall, just to start. I am sure someone will have a solution for using a Uniden\Whistler\Whatever and log the calls, and probably be as easy as some of the software is today.

 

[One13Truck]

I like the POTENTIAL of this but as of right now running my feed off of a Mac I basically have it tied together with old duct tape and torn shoe strings the way it is plus my county is in the early/mid stages of switching from VHF conventional to P25. Maybe in the future when we finally flip the switch to P25 I'll play around with it. For ow I'll just be listening & checking the progress of Calls.

 

[dan-dekalb]

I'm a little late to this party, but I've spent the last couple of months getting Trunk Recorder, OP25, GQRX, etc. running on a Raspberry PI 4 with the goal of managing 4 RTL-SDR receivers to record two trunked systems in our County. I started as a feed provider because of 60Hz hum on the only other feed in the area. I was able to add the state trunked system, which made my feed unique enough that it was approved. I've always tried to make sure my feed was clear and the best possible.

When my local county went to P25 Phase II, I decided it was time to upgrade the Uniden. One of my biggest personal complaints on my feed was the requirement that the scanner change frequency and lose any other calls. With the SDR platform, audio from each call gets sequentially streamed to Broadcastify and, in my opinion, the quality is 1000% better than my old feed.

Looking into the (somewhat cloudy) future, I see a change coming down the road. As feed providers, we have spent years providing a curated audio product of what we believe the public wants to listen to. As we start providing feeds to the "calls" platform, we give the public an opportunity to curate their own feed of what they are interested in. I receive the State Police feed as part of the Illinois "StarCom" system, but I have no interest in broadcasting that in my feed, but someone out there may want to listen to it. I receive a number of talk groups that I don't include in my feed because they are not within the Broadcastify terms of service. With the calls platform, I can include it in the upstream, and it is up to Broadcastify if they want to allow operations or other audio to be available.

We are on the cusp of a new "golden age" of scanner capability. I built from source and had a steep learning curve getting everything working. I'm a firm believer that if we were to create a base RPi image that included docker, Trunk Recorder, Rdio, LiquidSoap, and a WebConfig to manage the configurations, it would be a game-changer in the scanner and streaming market. The only major thing I think we're missing in Trunk Recorder is the "--freq-error-tracking" option from OP25 to make it easier to adjust error correction on the RTL-SDR dongles.

The world is changing. As feed providers, we have to consider that we are not providing the scanner feed we want to listen to, but the audio that Broadcastify's customers want (or don't want) to listen to.

Just my $0.02 worth...

 

[frankbreden]

OK I really missed something. I provide 3 feed in the Tampa Area in Florida. I use 3-436's to each own computer to broadcast.

I have one computer crash. I am working on another computer. Did I miss a change somewhere?

 

[Kingscup]

OK I really missed something. I provide 3 feed in the Tampa Area in Florida. I use 3-436's to each own computer to broadcast.

I have one computer crash. I am working on another computer. Did I miss a change somewhere?

No changes to your current Broadcastify feed. What has happened is that RR/Broadcastify has added a “Calls” platform. It is similar to your current feed but uses software defined radio hardware/software and a computer. SDR can capture all frequencies at the same time (with limitations) and record them. It is then uploaded to Broadcastify for listening. No radio traffic is missed. Check it out here. Broadcastify Calls

 

[bdp278]

OK so let me see if I understand this new system: I have a SDS200 on my feed covering 18 different Fire Departments. Of course when my scanner stops on an active TG for a particular FD, any other conservations on any other TG’s are missed, until scanning is resumed. Does this new system capture those other TG’s while the scanner is stopped on an active TG?

 

[dan-dekalb]

Yes. Using SDR dongles, it can capture multiple transmissions at the same time. Think of it this way. The “SDR” is recording the entire 2MHz of spectrum all the time. Whenever a transmission is detected within the 2MHz, it is recorded and then streamed out via the existing Broadcastify interface and/or the new Calls platform. If there are two transmissions within that same 2MHz of spectrum, both can be recorded at the same time.

I’ve been working on upgrading my feed for about 4 months. I have 5 RTL-SDR receivers on one USB 3.0 hub feeding into a Raspberry PI 4. Two cover the local P25 Phase 2 county system. Two cover Illinois P25 Starcom system, and one is for the local fire department analog system. The difference between sequential streaming and a scanner changing channels is night and day. You get all the transmissions. On a busy night, at least 1/2 of the transmissions had the 1st half cut off on my feed.

I stream the same departments on my primary feed, but I send all transmissions to the Calls interface. Calls collects all the transmissions for Illinois StarCom from receive sites across the state and can present a feed that is more than a single site could provide.

 

[bdp278]

So will I need a different receiver, or will my Uniden SDS200 work?

 

[bdp278]

I think I found my answer. RDL-SDR V3 dongle connected to usb 3 in my laptop will receive one site, will need additional dongles for each site I wish to receive?

 

[dan-dekalb]

You need to look at the total frequencies covered. If you go to http://garvas.org/trunk-recorder/ and enter the frequencies from RadioReference, it will tell you how many dongles and recorders you will need. Each RTL-SDR dongle covers 2MHz of spectrum, so everything within that spectrum will be recorded, including control and voice channels.