Search results

The Donkey Duster club has a repeater on 10

I host the Bristol/State PD feed; unfortunately, it's too far for me to pick up the towers there. The only time I see Troop D is if it comes across a patch.

I work with radio encryption. Yes, I know that keys can be cracked with enough computing power and time. Without a key, it's pretty much useless.

Loaded the image onto an older Pi3. I'm not sure what is dragging on the machines; however, even the basic functions are painfully slow, like opening a browser. I get its an older hardware so I accept that. I attempted to use SDRTrunk with a single RTL, and both times, after about 45 minutes...

im calling BS, without the keys you cant decrypt

I provide one of the state pd feeds and can get you some of the recordings. I’m also in litchfield so mostly the troop l simulcast

I am all set and running. Maybe a small suggestion in the application page for Sdrtrunk conventional mention that the order submitted need to match the talk group numbers. I knew they were in an order, thought that was just for the channel configuration. Also the screenshot from sdr says 1-6500...

I just did a packet capture off the wire and it does appear that I am sending to the right node. POST /call-upload HTTP/1.1 Connection: Upgrade, HTTP2-Settings Content-Length: 760 Host: api.broadcastify.com HTTP2-Settings: AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA Upgrade: h2c Accept: */*...

@blantonl Good Evening, Is there anything else that we can check on the back end. I have complete deleted and rebuild the SDR Trunk config and I am still getting the api error. As far as I can tell I have everything configured as expected. Api key starting with - 7888cce and system ID 3260

@DSheirer is there anything within the logs or config to check. From what I can see from the ui the right node is configured

I did delete the old config and added the new one. From what i can tell should be hitting the new node? Even after the fresh entries still get that message. Restarted the app several times in case something was cached

So i have "talkgroups" but getting an API error saying no freq [Broadcastify Calls API upload URL Request failed [1 no-freq-table-entry-for-upload]

I am trying to get the SDR Trunk set up to feed calls from a conventional system. Whenever there's activity I am seeing the stream being uploaded to the standard streams but calls doesn't report any activity. in the logs I am seeing an error [Broadcastify Calls API upload URL Request failed [1...

SDR trunk will do conventional freq now with their latest release. It can now tune to analog conventional frew. Turns out when I set up the Calls application I was going to use a different encoding app and switched to SDRTRunk. Looks like there's dependencies needed that they have to match.

@blantonl Will do. Since Fire/EMS etc are different frequencies, should I submit 1 for each frequency or pump them in with "internal" talkgroups into 1 feed? Since Ill be putting in new applications feel free to kill node 3254

I just recently set up a conventional source to feed calls using SDR trunk. I also use SDR Trunk to feed the same sources to a broadcastify feed. Looking at the logs I see that I an transmitting the Broadcastify feeds but not sending data for calls. I have assigned and confirmed the aliases are...

I also couldnt get trunk recorder to connect so went with SDR Trunk, Not sure if that will need to be updated too

I just submitted a request (which got approved) for Terryville / Plymouth town services. I am not sure if I mistype something or not, but could this system be renamed to reflect that its Terryville Fire/Plymouth EMS/Plymouth Public Works Node 3254

Now that SDR Trunk allows for analog conventional systems, I was thinking about sending a copy of my stream to the calls system as well. Since its a non trunked system, would I need to create a feed for fire, second for EMS or would I put them into one feed with a fake alias?

here are all the towers and CC groups. CT ARES - Digital Mobile Radio (DMR) all the talk group https://ctares.org/CT-ARES_DMR_Talkgroup_Info_5May16.pdf