Broadcastify Calls and Railroad Audio

[iceman977th]

I’ve thought about trying out Broadcastify Calls to record railroad voice traffic across multiple channels.

I guess the big questions would be
1. Can Broadcastify Calls support that functionality?
2. Has anyone done this before with rail channels?
3. Can the entire rail band (160.215-161.565) be covered with a single SDR?
4. Is there anything I’m missing?

 

[alabamarailfan]

This is an interesting concept. I was kind of under the impression that the calls system was geared more towards digital/trunked communications but it would certainly be interesting to try for railroad communications. Let us know your results if you try it!

 

[GTR8000]

The latest builds of SDRTrunk are capable of NBFM, so that's not a problem. An RTL dongle can see ~2.4 MHz worth of contiguous spectrum, so that easily covers 160-162. SDRTrunk can be used to provide audio to both Calls as well as traditional BCFY feeds.

The biggest stumbling block is how would the node(s) look on Calls? Since these are all analog frequencies, there are no talkgroups to capture, only individual frequencies. You would certainly not want to "scan" the frequencies and upload all of that audio to a single entity on Calls, that would be quite a mess and would basically duplicate the functionality of a traditional BCFY feed.

So perhaps you would have to apply for a conventional Calls node for each frequency you'd be decoding, which would mirror the individual channel definitions in SDRTrunk. So essentially you'd be using a single install of SDRTrunk to capture multiple frequencies in the 160-162 band, and feeding each of those to an individual Calls node.

@blantonl what say you about this concept?

 

[iceman977th]

The latest builds of SDRTrunk are capable of NBFM, so that's not a problem. An RTL dongle can see ~2.4 MHz worth of contiguous spectrum, so that easily covers 160-162. SDRTrunk can be used to provide audio to both Calls as well as traditional BCFY feeds.

The biggest stumbling block is how would the node(s) look on Calls? Since these are all analog frequencies, there are no talkgroups to capture, only individual frequencies. You would certainly not want to "scan" the frequencies and upload all of that audio to a single entity on Calls, that would be quite a mess and would basically duplicate the functionality of a traditional BCFY feed.

So perhaps you would have to apply for a conventional Calls node for each frequency you'd be decoding, which would mirror the individual channel definitions in SDRTrunk. So essentially you'd be using a single install of SDRTrunk to capture multiple frequencies in the 160-162 band, and feeding each of those to an individual Calls node.

@blantonl what say you about this concept?

I guess that's how I'd have to do it.. lol. The Calls feature would be nice overall for capturing multiple frequencies, even non-trunked frequencies. I wouldn't mind having a way to record the individual frequencies that my public safety feeds provide, that way no traffic is missed in recording. But that's why I'm here asking if my idea, starting off with a railroad channel, is even viable.

Mike

 

[blantonl]

Trunk Recorder would work GREAT for this. It supports Conventional Analog FM - and an RTL stick would probably work fine for the entire railroad band.

GitHub - robotastic/trunk-recorder: Records calls from a Trunked Radio System (P25 & SmartNet)

Records calls from a Trunked Radio System (P25 & SmartNet) - robotastic/trunk-recorder

github.com

You can see an example of a Trunk Recorder Analog Node that I run with multiple analog channels here:

Broadcastify

The worlds largest source of public safety, aircraft, rail, and marine live audio streams

www.broadcastify.com

This is using an AirSpy, but a RTL has enough bandwidth for the entire Railroad band

Config looks like this for this node:

{
  "ver": 2,
  "sources": [
    {
      "center": 154000000.0,
      "rate": 10000000,
      "error": 350,
      "ifGain": 10,
      "mixGain": 10,
      "lnaGain": 7,
      "digitalRecorders": 8,
      "analogRecorders": 6,
      "driver": "osmosdr",
      "device": "airspy=0x260868C83278989B"
    }
 ],
  "systems": [
{
      "type": "conventional",
      "shortName": "vhfanalog",
      "broadcastifyApiKey": "4c3e6b1c-xxxxxx-xxxxxxxxxxxx",
      "broadcastifySystemId": "20",
      "audioArchive": "false",
      "maxDev": 3500,
      "squelch": -55.0,
      "minDuration": 0.75,
      "channels": [155610000,154295000,155550000,155400000,153950000,155730000]
    }
],
  "broadcastifyCallsServer": "https://api.broadcastify.com/call-upload",
  "frequencyFormat": "mhz",
  "captureDir": "/Users/lindsay/radio/audio",
  "controlWarnRate": "10",
  "callTimeout": "1",
  "logFile": "false",
  "logLevel" : "info"
}

 

[GTR8000]

Okay so one node with each frequency mimicking a "talkgroup". I didn't even consider that, I bet SDRTrunk is also capable of sending individual frequencies to a single node like that.

 

[blantonl]

Okay so one node with each frequency mimicking a "talkgroup". I didn't even consider that, I bet SDRTrunk is also capable of sending individual frequencies to a single node like that.

That's how it works. Bascially, each conventional analog channel is assigned a talkgroup in auto-incrementing order (n+1). So, we set those up as "slots" in Broadcastify Calls.

So if you want to do this, simply get your node up and running and squelches set properly etc... then submit an application for a Broadcastify Calls Node that is a Trunk Recorder Node / Conventional System and paste your trunk recorder config in the box... and we'll provision it as appropriate with each of the frequencies as slots starting at 1 and then n+1. Note that the analog frequencies must have RRDB entries already in the database.

 

[Kingscup]

I guess that's how I'd have to do it.. lol. The Calls feature would be nice overall for capturing multiple frequencies, even non-trunked frequencies. I wouldn't mind having a way to record the individual frequencies that my public safety feeds provide, that way no traffic is missed in recording. But that's why I'm here asking if my idea, starting off with a railroad channel, is even viable.

I provide a conventional analog Calls feed. Luckily, I only need 1MHz of spectrum to do it. I am able to monitor 7 frequencies but any more that that, my RPi 4 will overload and Trunk Recorder will stop. I suspect if you try and do 1.5MHz or more of spectrum, you may be able to 4-5 frequencies before the RPi overloads.

My RPi does overload about every 1-2 months. I suspect it is related to some sort of interference that causes every frequency to receive static and the RPi tries to process and upload all frequencies at the same time causing an overload.

 

[a417]

I provide a conventional analog Calls feed. Luckily, I only need 1MHz of spectrum to do it. I am able to monitor 7 frequencies but any more that that, my RPi 4 will overload and Trunk Recorder will stop. I suspect if you try and do 1.5MHz or more of spectrum, you may be able to 4-5 frequencies before the RPi overloads.

My RPi does overload about every 1-2 months. I suspect it is related to some sort of interference that causes every frequency to receive static and the RPi tries to process and upload all frequencies at the same time causing an overload.

Next time this happens you should look at the logs to see exactly what is going on, see where it's choking to death...

 

[Kingscup]

Next time this happens you should look at the logs to see exactly what is going on, see where it's choking to death...

Can you remind me how to do that? I think I may have done that once or twice but I don't remember how as that may have been a few years ago. I couldn't find anything on Google.