Just started an aviation feed from RTL-Airband. Is 2-3 minute call skew normal?
I have timed the lag on Broadcastify, on my end it will run 1 1/2 to 3 minutes. Usually around 2 minutes.Feeding from Pi4 with one dongle (for now) using RTL-Airband. Files are written immediately, but at least a 2 minute lag before playing thru BCFY.
I feed a call system with SDRTrunk and see very little if any lag......
Yes....Skew, lag, same thing. Skew is used for the calls platform, so I assumed I would use that lingo here.
Point is, 1-3 minute DELAY in my opinion leaves me not much desire to bother feeding that aviation band.
Thank you for the info. That is what I was looking for. I will investigate other venues.I get it. The delay has always been there on the feeds platform though. I realize that doesn't make it any less painful for you. Just the way it is.
I feed several ADSB sites. Just general aviation spotting I guess, but I like to pull my ADSB feed up and listen to ATC. It sucks when someone is cleared for takeoff, yet on the ADSB screen, they’re 30 miles down the road.I'm curious about your use case. What makes that delay a major issue?
What software are you using? I am beginning to believe skew is an unfair measure. Trunk Recorder doesn't break each transmission into a separate "call" whereas SDRTrunk does, thus it seems TrunkRecorder providers are being unnecessarily penalized when Calls thinks their submission is a "duplicate call" yet is significantly better audio quality and still reasonably fast compared to an SDRTrunk user providing around about the same speed.The Calls platform is a different beast. On that platform it's heard almost instantly after the machine captures it and uploads it. My Calls skew is usually between 0.5 and 1 second. On the regular feed system things are entirely different, and the term skew has never been used to discuss that platform. I suspect the OP read some previous things about the BCFY Calls platform and skew and is associating it with his standard feed.
For this particular situation that I originally asked about (Aviation feed) I am using RTL-Airband. It seems to do a nice job at splitting the transmissions, but there is a 2-3 minute lag when listening on BCFY. I'm guessing that all broadcast feeds are in the same boat and it is not because it's the aviation band...What software are you using? I am beginning to believe skew is an unfair measure. Trunk Recorder doesn't break each transmission into a separate "call" whereas SDRTrunk does, thus it seems TrunkRecorder providers are being unnecessarily penalized when Calls thinks their submission is a "duplicate call" yet is significantly better audio quality and still reasonably fast compared to an SDRTrunk user providing around about the same speed.
It's definitely not an issue with my computer clock. I physically live close to an actual NIST atomic clock and use them as a time source with advanced software that can accurately adjust for jitter, latency, and other factors. Not saying I don't want the other user to be broadcasting calls, just frustrated when I can not miss transmissions and provide high quality and somehow my "skew" is too high.
To clarify, the difference in how TR and SDRTrunk capture calls is moot in the skew calculation. The timestamp used for the skew calculation is generated on call completion, and compared to NIST time on the BCFY server +/- your local system time. The skew number is just the difference between those. Since they aren't running AI against the audio contents (Yet?), it's agnostic to your single call vs another nodes 3-4 for a routine exchange, and wouldn't penalize either node for duplicates or missed calls. It's the call uploads of identical length and timestamps that are targeted as likely duplicates and a lot of other witchcraft and wizardry to make it all work the way BCFY wants it to.What software are you using? I am beginning to believe skew is an unfair measure. Trunk Recorder doesn't break each transmission into a separate "call" whereas SDRTrunk does, thus it seems TrunkRecorder providers are being unnecessarily penalized when Calls thinks their submission is a "duplicate call" yet is significantly better audio quality and still reasonably fast compared to an SDRTrunk user providing around about the same speed.
It's definitely not an issue with my computer clock. I physically live close to an actual NIST atomic clock and use them as a time source with advanced software that can accurately adjust for jitter, latency, and other factors. Not saying I don't want the other user to be broadcasting calls, just frustrated when I can not miss transmissions and provide high quality and somehow my "skew" is too high.
To clarify, the difference in how TR and SDRTrunk capture calls is moot in the skew calculation. The timestamp used for the skew calculation is generated on call completion, and compared to NIST time on the BCFY server +/- your local system time. The skew number is just the difference between those. Since they aren't running AI against the audio contents (Yet?), it's agnostic to your single call vs another nodes 3-4 for a routine exchange, and wouldn't penalize either node for duplicates or missed calls. It's the call uploads of identical length and timestamps that are targeted as likely duplicates and a lot of other witchcraft and wizardry to make it all work the way BCFY wants it to.
See: Broadcastify Calls Node Skew Problems
Sorry about the delay, I missed he alert of the comment, apparently.I guess I don’t know what you mean by “direct feed”……
Yes, obviously I could listen directly, but when I'm not at my location I'm out of luck.Sorry about the delay, I missed he alert of the comment, apparently.
I meant setting up streaming directly from your own equipment, not using an external server. That delay should be no more than a few seconds.