Adding a second Raspberry Pi to a Calls feed

[Kingscup]

With the new Broadcastify feed image that just came out, I now have an extra Raspberry Pi. I was curious about adding it to my Calls feed and tried it out. Took one dongle over to the extra Pi. I only had it for a short time when I realized the radio traffic and channel description did not match which is not surprising. I am providing a conventional analog feed. Could the config.json files be changed to make it work or is this more on the Calls side (new configuration and/or new node?)?

 

[blantonl]

Can you post your config.json please so I can see how it matches up with how we provisioned your calls node?

 

[Kingscup]

{
"ver": 2,
"sources": [{
"center": 151276875,
"rate": 1000000,
"gain": 32.8,
"analogRecorders": 7,
"driver": "osmosdr",
"device": "rtl=0"
},{
"center": 154104375,
"rate": 1000000,
"gain": 32.8,
"analogRecorders": 4,
"driver": "osmosdr",
"device": "rtl=1"
}],
"systems": [{
"channels":
[151385000,
153770000,
154145000,
154445000,
154100000,
151175000,
151355000,
151220000,
151310000,
151265000,
151340000
],
"type": "conventional",
"shortName": "RVC",
"analogLevels": 12,
"audioArchive": false,
"callLog": false,
"squelch": -50,
"minDuration": 2.5,
"broadcastifyApiKey": " ",
"broadcastifySystemId": "438"
}],
"frequencyFormat": "hz",
"broadcastifyCallsServer": "https://api.broadcastify.com/call-upload"
}

 

[blantonl]

Ok, so what exactly is the problem? Everything looks good to me.

 

[Kingscup]

I currently have 2 RTL-SDR on one RPi running one Calls feed. I want to add a second RPi and take one of the RTL-SDR from the original RPi to place it onto the second RPi. I tested this out yesterday and it seemed to work except for one problem in the short time I had it hooked up. Transmissions were being misidentified. Meaning when someone talked on one frequency, the Calls program showed a different frequency/display/description.

151385000, <--probably related to this freq. being on the original RPi and not on the second RPi.
153770000,
154145000, <--Misidentified freq/display/description
154445000, <--Original transmission

Did I do something wrong? If it is possible, can I fix it on my end or is it on your end? I hope to take a split the load of each RPi so I can eventually a another frequency or two. Thanks.

 

[lynchy135]

Do you have the same config running on both Pis or did you split them such that half are on one, half are on the other?
What does the JSON look like from a call that is miss identified? You can find the JSON in trunk-build/{system name}/{year}/{month}/{day}/[talkgroup-time-frequency].json. For example, my path is trunk-build/scnjtrs/2021/4/28/103-1619621587_500612500.json. That JSON looks like

{
"freq": 5.00612e+08,
"start_time": 1619621587,
"stop_time": 1619621593,
"emergency": 0,
"talkgroup": 103,
"srcList": [ {"src": 38809, "time": 1619621587, "pos": 0.000000, "emergency": 0, "signal_system": "p25", "tag": ""} ],
"freqList": [ { "freq": 500612500.000000, "time": 1619621587, "pos": 0.000000, "len": 18560.000000, "error_count": 6.000000, "spike_count": 4.000000}]
}

I am not running conventional now, but I have in the past. It should a similar layout.

 

[Kingscup]

I was able to figure it out. On the second RPi, I added the #1 frequency (151385000) back to the top of the json file on the second RPI. This allowed all the info to line up with the with the correct frequencies. I assumed that I would receive an error with an out of range frequency and it would not work. I did receive an error on startup but it was essentially ignored and it worked. Of course it was something simple. Sigh. I appreciate the help. Thank you.