Classic feed from Calls
- Thread starter apu
- Start date
- Status
BenFranske
Member
- Joined
- May 6, 2005
- Messages
- 37
Depending on what software you are using to feed you can send a classic stream in addition to a Calls stream yourself. It's quite easy to do with SDRTrunk and possible, though more complex with trunk-recorder.
It puts no overhead on your streaming server on top of what it's already using for SDRTrunk. The only thing you'd want to do is create a small RAMdrive for the temporary recordings to avoid the constant wear on your storage drive.
I'd imagine that the dynamic feeds will not be available for quite some time, until the Calls system is way more established and refined.
Vermonster
Member
No, I mean one of the "coming" features of the Calls platform is to be able to create a "standard" feed from what is sent to the Calls servers. As it stands now, we as providers still have to maintain both, sending the Calls data as well as the standard audio stream. Once the new feature goes live, we will only have to send the Calls data, and the standard audio stream will be generated directly from that at Broadcastify's end.
But we could end a classic feed, replacing it with the Calls feed, and then repurpose the hardware? Even the equivalent of a "public playlist" to mix together different talkgroups similar to what a scanner would do?
Vermonster
Member
Ahah. Understood. Thanks.
I think this idea is great but I am presented with a "dilemma" that is surely not unique to me. While the majority of public safety in my area is trunked, there are several departments that are still conventional. As it stands I provide only the trunked data. I admit up front I have not researched the method to provide several conventional channels simultaneously and I'm not even sure it is possible in a Windows environment. Even if I were able to do so, will you be able to create one "standard" feed by using the sources of two completely different call systems?
Hopefully that question makes sense...
Hopefully that question makes sense...
I think this idea is great but I am presented with a "dilemma" that is surely not unique to me. While the majority of public safety in my area is trunked, there are several departments that are still conventional. As it stands I provide only the trunked data. I admit up front I have not researched the method to provide several conventional channels simultaneously and I'm not even sure it is possible in a Windows environment. Even if I were able to do so, will you be able to create one "standard" feed by using the sources of two completely different call systems?
Hopefully that question makes sense...
We can create a standard feed from anything in Broadcastify Calls.
I could create a standard feed of the San Diego Fire Department and the Boston Fire Tactical Channels if I wanted to. Just in the same way you can create a playlist in Broadcastify calls of any talkgroup or frequency that is covered by Broadcastify Calls. Do you want to create a playlist with the Seattle Fire Department Dispatch, and the Chicago Trash Trucks, and the San Antonio Police North Patrol, and the NYPD Bronx Precincts 46, 48 ? - you could literally do that right now. And we'll be able to create legacy feeds in the same way.
BenFranske
Member
- Joined
- May 6, 2005
- Messages
- 37
I had a bit different take on your question. There are at least two or three different things at play here. 1) How you capture the systems, 2) how you transmit the captured data to Broadcastify, 3) how Broadcastify presents the data.I think this idea is great but I am presented with a "dilemma" that is surely not unique to me. While the majority of public safety in my area is trunked, there are several departments that are still conventional. As it stands I provide only the trunked data. I admit up front I have not researched the method to provide several conventional channels simultaneously and I'm not even sure it is possible in a Windows environment. Even if I were able to do so, will you be able to create one "standard" feed by using the sources of two completely different call systems?
Hopefully that question makes sense...
For #1 options include traditional scanner(s) or SDRs. You can capture both digital systems, analog systems, trunked, and conventional using either method. SDRs can capture multiple nearby frequencies at the same time while traditional scanners are one frequency at a time, that goes for both analog or digital.
For #2 you can currently supply data to Broadcastify either using a traditional streaming audio feed or through the calls system where each transmission is uploaded separately. Theoretically you could transmit analog FM captures to the calls system as well, though I don't know that is supported at the moment. I also believe only SDRs can be used to send to the calls system.
#3 is really what this thread is talking about. There are huge advantages to accessing through the calls system (easy to go back and find old transmissions, knowing radio IDs, individual TGs, etc. for digital transmissions) but a lot of legacy software apps exist to use the traditional Broadcastify feeds. So, the coming feature is that Broadcastify can create playlists of groups of TGs being received on the Calls platform and publish those as various traditional Broadcastify feeds.
It sounds like maybe you are asking if it's possible to combine multiple traditional Broadcastify feeds together (possibly also incorporating a feed from the Calls system) into a single traditional feed. I don't think that is a planned feature, it would be pretty messy and computationally intensive on the backend to mix all those sources together.. Also, IMHO the Calls platform is just such a better way to "scan" you wouldn't really want to listen over a traditional feed unless you had no other choice. Note though that you CAN open multiple feeds at the same time on your own computer and mix together whatever you want.
My question had nothing to do with traditional feeds, it was strictly about combining the resources of multiple Broadcastify Calls feeds. Asked and answered in post #13.
- Status
