Closed rpatel3001 closed 7 months ago
From SBS the squawk should be accepted.
Are you sure it's in the data stream?
Squawk has some logic to require the squawk to be received twice before the change is accepted. I'm not sure if that applies to SBS input as well though. ... .don't think it does.
number of messages might be it... looking at the current tar1090 list I only have squawks for targets with >2 messages. Possibly a separate issue, I've never seen a target listed as only having 1 message.
Squawk is definitely in the input SBS messages, I can actually monitor the SBS output port and see the squawk forwarded on all messages there as well.
also, I didn't look too hard at the code, what causes blank lines to be output on the SBS output port? Invalid/old messages?
https://github.com/wiedehopf/readsb/blob/dev/track.c#L2013
Yeah i believe that's what is happening. The squawk will only change after receiving the same squawk twice. For actual ModeS / ADS-B data that's a sane approach.
I don't know if i want to change it even for SBS to be honest it's a good thing most of the time. An exception for SBS jaero input might be possible as it's an input that only gets messages very rarely.
thanks. if you don't want to add an exception i can just send messages twice lol
That would be the thing to do for now at least. I'll think about making an exception for jaero when i get the chance.
ah sending twice doesn't work, looks like there's a wait period. Not sure if the 15 second or 750 ms wait period is the relevant one.
you can always recompile with local changes
Background: I'm extracting positions from ACARS/HFDL messages and forwarding them to readsb (as embedded in the ultrafeeder and tar1090 containers). I'm trying to differentiate the source of the position (ACARS vs HFDL) by setting the squawk to either 1111 or 3333.
Not every line of the tar1090 aircraft list shows a squawk. There are some 1111, some 3333, and some blank. Not entirely sure if the issue is in readsb or tar1090.