Aviation feed 2-3 minute call skew???

n0esc

Feed Provider
Joined
Dec 19, 2002
Messages
211
Location
SE MN EN33
No, skew should be minimal irrespective of what type of audio you are feeding into the platform. What are you feeding from, Windows or a dedicated system? If a standard Win PC, using an app like Dimension 4 to make sure your clock is "always" correct is a good idea. Thinking Man Software - Dimension 4 v5.3

Depending on how many SDRs you are running on each machine you may just be saturating the processing limits and thr airband traffic is getting left behind in favor of the SDRTrunk data.
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
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.
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,650
Location
Carroll Co OH / EN90LN
I feed a call system with SDRTrunk and see very little if any lag......

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.
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
Yes.... :cautious: 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.
 

mtindor

OH/WV DB Admin
Database Admin
Joined
Dec 5, 2006
Messages
10,650
Location
Carroll Co OH / EN90LN
Yes.... :cautious: 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.

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.
 

n0esc

Feed Provider
Joined
Dec 19, 2002
Messages
211
Location
SE MN EN33
If you are into plane spotting, and that delay is indeed 2-3 minutes, that's basically an eternity if you are trying to listen to ATC to know what is going on. Obviously much smaller and more specialized sites, but liveatc and radarbox both provide audio feeds that are near real time. While closer to real time is nice for public safety, there is little to no impact as a hobbyist or member of the public to have a short delay, but the main interest of listening to ATC isn't to know what happened a few minutes ago, but to know what's going on in the moment.
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
I'm curious about your use case. What makes that delay a major issue?
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.
 

HarryWilly

Member
Feed Provider
Joined
Jul 4, 2007
Messages
271
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.
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.
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
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.
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...

For the calls system, I agree with you on the others. I've tried Trunk-Recorder with the same outcome as you mention. Very few transmissions make it through that aren't dupes. I MUCH prefer SDR-Trunk as it does a great job! My Problem is that I have 2 systems that I am feeding that I can cover both with 2 SDRs. But I am 1 mile from one transmitter, and many miles from the other. Therefore I am using trunk-recorder on one feed and SDR-Trunk on the other becuase if I set the appropriate gain for the farther site, it blows the close site up and get bad calls.
 

n0esc

Feed Provider
Joined
Dec 19, 2002
Messages
211
Location
SE MN EN33
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
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
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

But if TR puts 2 transmissions together and SDRTrunk does not, then how could TR ever have the same timestamp?
 

krokus

Member
Premium Subscriber
Joined
Jun 9, 2006
Messages
6,084
Location
Southeastern Michigan
I guess I don’t know what you mean by “direct feed”……
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.
 

timsheff

Member
Premium Subscriber
Joined
Dec 14, 2023
Messages
41
Location
SW Cedar Rapids
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.
Yes, obviously I could listen directly, but when I'm not at my location I'm out of luck.
 
Top