Broadcastify Calls

[KD0FEO]

New calls uploader here. I’ve noticed that my software is picking up traffic from several counties, many of which already have multiple nodes uploading the same calls. Am I safe to disable those and focus primarily on my own sites area? Or should I just keep pumping everything, even if it feels like I’m adding unnecessary load to the system? I am noticing a lot of duplicate calls on my node, is this a concern? How do I remedy it? Any help for a new calls uploader is welcome.



On most of those overlapping calls, my node is marked as "Current [A]" which I don't understand, is that good or bad? I'm located a bit farther out and have less site traffic, so it appears my skew may be lower than the busier metro-area systems in the Twin Cities. Node in question: 4916 - Site in question: Sherburne - Wright Co. Simulcast (Wright County)

 

[Enforcer52]

I would not upload calls that are already being duplicated by others, just causes more overhead on the servers, and on your own system. 3,446 duplicate calls is a bit much. Personally I only upload calls that are not being uploaded by others. Just causing a lot of redundancy on the system, and benefits no one.

 

[GTR8000]

I would not upload calls that are already being duplicated by others, just causes more overhead on the servers, and on your own system. 3,446 duplicate calls is a bit much. Personally I only upload calls that are not being uploaded by others. Just causing a lot of redundancy on the system, and benefits no one.

Actually in this case redundancy is a good thing. If one nodes fails or goes offline, another node can pick up the slack. Lindsay designed BCFY Calls to specifically handle duplication of uploaded talkgroups for this very reason, so there is no need to concern yourself with the capacity of the servers.

Send it all and let BCFY sort it out. If one of the other nodes goes down and you stopped decoding some of those talkgroups, you may regret losing those archives.

 

[Enforcer52]

If there are several others already sending the same channels to Calls as the OP stated, then there really isn't a reason to send them again and get thousands of duplicate rejects.

 

[KD0FEO]

Actually in this case redundancy is a good thing. If one nodes fails or goes offline, another node can pick up the slack. Lindsay designed BCFY Calls to specifically handle duplication of uploaded talkgroups for this very reason, so there is no need to concern yourself with the capacity of the servers.

Send it all and let BCFY sort it out. If one of the other nodes goes down and you stopped decoding some of those talkgroups, you may regret losing those archives.

This is what I was looking for, I wasn't sure if I was doing something wrong by having duplicates. I'll keep pumping them in as long as I don't get in trouble! Also can you elaborate what the "Current [A]" means next to my node on the calls I upload?

 

[GTR8000]

Current [A] means Current, Assigned. In other words, that is the primary active node for any talkgroups it's sending to Calls.

Broadcastify Calls Duplicate Calls Handing Updates

TLDR: We're testing a new algorithm for duplicate calls handling on the following systems: https://www.broadcastify.com/calls/trs/3508 https://www.broadcastify.com/calls/trs/100 https://www.broadcastify.com/calls/trs/7494 https://www.broadcastify.com/calls/trs/7349 Details I've written a new...

forums.radioreference.com

Spend some time reading through that thread. A lot of discussion early on in the process, but will likely answer your questions. Pay attention mostly to Lindsay's posts, naturally.

 

[AB5ID]

If there are several others already sending the same channels to Calls as the OP stated, then there really isn't a reason to send them again and get thousands of duplicate rejects.

The servers don't care, it's good to have a backup.

 

[blantonl]

If there are several others already sending the same channels to Calls as the OP stated, then there really isn't a reason to send them again and get thousands of duplicate rejects.

Disregard this advice.

Please send everything you have, all the time. Broadcastify calls nodes go down all the time and having a backup source is really important now for calls. The server load is negligable, and duplicate rejects is how the system is setup to handle this stuff and it is totally normal.

We want as many nodes as possible covering as many sites as possible.

 

[blantonl]

I would not upload calls that are already being duplicated by others, just causes more overhead on the servers, and on your own system. 3,446 duplicate calls is a bit much. Personally I only upload calls that are not being uploaded by others. Just causing a lot of redundancy on the system, and benefits no one.

Would you please not do this? Send everything all the time. If you can capture it, send it. Duplicate calls are not a bad thing.

 

[Enforcer52]

Sorry for the bad advice. As someone who has worked with computers for over 35 years, ran networks for school districts, lawyers, doctors, and other professionals. There is just so much redundancy needed, before it starts eating into your band width and network resources. Not to mention the overhead on a pc serving up the info.

Just my opinion!

 

[rjdj2000]

Would you please not do this? Send everything all the time. If you can capture it, send it. Duplicate calls are not a bad thing.

Awhile back I ran into the issue of having a lot of errors. Come to find out another node came alive in my area and apparently were getting to the server before me. I still sent everything and just as quick as the new node came, it was gone. So serve it all.

 

[blantonl]

Sorry for the bad advice. As someone who has worked with computers for over 35 years, ran networks for school districts, lawyers, doctors, and other professionals. There is just so much redundancy needed, before it starts eating into your band width and network resources. Not to mention the overhead on a pc serving up the info.

Just my opinion!

We need way more redundancy, and I can definitely tell you as the creator and maintainer of this system that there is an extremely small overhead of bandwidth and network resources involved for duplicate call management.

Your calls node literally says "I have this call" and the system says "send it" or "we already have it."

It might be the smallest overhead process in the history of computers.

 

[Enforcer52]

our calls node literally says "I have this call" and the system says "send it" or "we already have it."

Then it is much more efficient than what most systems are, and what I am used too.

So guess instead of just throwing the 25 or so local TxWarn channels I have now, I can start throwing all 900+ I am able to receive (minus whats not allowed).

Thanks for clearing that up

 

[mtindor]

Then it is much more efficient than what most systems are, and what I am used too.

So guess instead of just throwing the 25 or so local TxWarn channels I have now, I can start throwing all 900+ I am able to receive (minus whats not allowed).

Thanks for clearing that up

On the Calls platform, everything is allowed. What I mean is that if you're picking up 900 talkgroups on one node, regardless of the service tag you should send every one of them. Broadcastify Calls happily accepts it and the BCFY infrastructure decides what is available to the public at that point. Quite a bit different than how the regular feeds work.

 

[blantonl]

Then it is much more efficient than what most systems are, and what I am used too.

So guess instead of just throwing the 25 or so local TxWarn channels I have now, I can start throwing all 900+ I am able to receive (minus whats not allowed).

Thanks for clearing that up

Yes, absolutely. Send everything you can. Don't hold back. Don't cheat us. Give us what we want!

 

[blantonl]

We're also going to be making available everything in Broadcastify Calls, all talkgroups and frequencies, available to premium subscribers. We're working on rolling this change out shortly.

 

[KD0FEO]

Does the site do load balancing? I've noticed when other sites get super busy like during the bad weather we've been experiencing, I'll become assigned versus other sites that typically have call control. Does it take into effect how many calls each node is processing and how to more effectively get the quickest source for calls?

Also, new to simulcast.. why is it that sometimes talkgroups will show up for a short period of time and then disappear? I know the talkgroups are still active because I see their calls, but they drop from the site I'm using and come back randomly. Do they normally just bounce around in simulcast to different towers?

 

[n0esc]

Also, new to simulcast.. why is it that sometimes talkgroups will show up for a short period of time and then disappear? I know the talkgroups are still active because I see their calls, but they drop from the site I'm using and come back randomly. Do they normally just bounce around in simulcast to different towers?

Answering this with some knowledge of how the MN ARMER system works and also partly regarding your first post about how the towers work since you are close to the border of a county. Typically ARMER towers will give priority to the county level users, (MNDOT and MNSP get statewide privilege), this extends outward from county borders by one tower site usually to give a buffer.

As to why some talkgroups pop up and then disappear, that's a radio affiliating with a tower that has that TG in a scanlist or set to it. Users that travel across the state are usually assigned a ROAM talkgroup. They are supposed to switch radios to that TG specifally and not scan so they aren't dragging traffic from bigger cities onto rural towers that might not have the capacity for it. I'm going to guess knowing that the ambulance in Litchfield is run by Mayo that they are probably your culprit and medics covering shifts up there coming from other cities are either being nosy or they are forgetting to switch to the ROAM group when they do transfers. As far as I am aware all of the Mayo radios are programmed with the same access to all of their sites, with just bank 1 changing depending on the radios home.

All that is a long winded way of saying it happens with any other ARMER users the same, but they are a known offender.

 

[KD0FEO]

@n0esc Anoka County is one that comes and goes, N. Dispatch & S. Dispatch come and go without any real rhythm. I watch the nodes broadcasting those and sometimes there are 5 nodes and sometimes only 2. I've noticed state patrol as well, I typically always receive 2600 (St. Cloud) but periodically 2500 will start showing up and be gone by the end of the night. My antennas are indoors pointed at the Howard Lake tower so perhaps I'm periodically grabbing signals from another tower and that's why everything shifts? It's got a pretty good signal that averages about -14dB, is it just neighboring towers confusing me?

 

[n0esc]

That one's out of my wheelhouse. State patrol could be either a case of evening commute and you are seeing metro 2500 officers following the flow of traffic out are getting close enough to affiliate with the Wright Co towers. Or you've got a trooper that lives out that way and is heading home at the end of a shift and it's pulling traffic that way.