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 no-freq-table-entry-for-upload]. I don't see any place to add freq information specific to calls.
No Freq Table for calls upload
- Thread starter scottb908
- Start date
- Status
The API is providing an error response code: 1 no-freq-table-entry-for-upload
What does that mean?
What does that mean?
It means that there isn't a slot to frequency lookup table defined for the node on our end. The frequency lookup table maps the slot assignments on the node provider's end to specific frequency entries in the RRDB.
Looking at this person's nodes, it appears they are probably trying to send to the wrong node ID. He should be sending to node ID 3260 but he's probably trying to send to his old node 3254 which no longer has a freq table because we moved it to 3260 for him when he decided to switch from Trunk Recorder to SDR Trunk.
Looking at this person's nodes, it appears they are probably trying to send to the wrong node ID. He should be sending to node ID 3260 but he's probably trying to send to his old node 3254 which no longer has a freq table because we moved it to 3260 for him when he decided to switch from Trunk Recorder to SDR Trunk.
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
Last edited:
Everything looks fine on our end. For some reason it looks like you're sending to the wrong node.
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: */*
Content-Type: multipart/form-data; boundary=--sdrtrunk-sdrtrunk-sdrtrunk
User-Agent: sdrtrunk
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="apiKey"
7888cce7*************
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="systemId"
3260
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="callDuration"
4.032
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="ts"
1711680328
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="tg"
100
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="src"
0
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="freq"
453.5625
----sdrtrunk-sdrtrunk-sdrtrunk
Content-Disposition: form-data; name="enc"
mp3
----sdrtrunk-sdrtrunk-sdrtrunk--
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 32
Connection: close
Server: awselb/2.0
Date: Fri, 29 Mar 2024 02:45:34 GMT
X-Cache: Miss from cloudfront
Via: 1.1 bfc4676044fcc4c0c8e705c71ca51fea.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: IAD55-P5
X-Amz-Cf-Id: gg5WfkNiXEUqoKfxdH3yqGCQinZUc21rLr7WewIuydFyJHN7rv8Olg==
1 No-Freq-Table-Entry-For-Upload
There's your problem. For some reason you're sending 100 instead of 1 for the slot or entry ID or whatever it's called in SDRTrunk.
I'm guessing this is where you've run into trouble because you've assigned "100" as the talkgroup ID when Broadcastify calls is expecting "1" as the entry ID.
Remember, for conventional channels we have to map your conventional channels to frequencies in the RadioReference database. When you submitted your application for the node, you gave us a list of frequencies you planned on capturing. And they are in order from N+1
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 had each one as a different talk group, just didn’t make the connection that it was tied to the order n+1 to the application listing.
- Status
