Probably someone hasnβt set right the timestamp. Iβll open an issue to add an additional check if timestamp is in the future then to not accept it. Thanks for noting this!
2 Likes
I moved this in a new topic in order to discuss it without spamming the βENSO re-entryβ one.
Looking in https://network.satnogs.org/observations/12492386/ the frames comes from the gr-satellites running in parallel with the satnogs-client. All of them are noise frames as there isnβt any signal visible and the pass is very low.
With the current architecture, unfortunately the noise frames are reaching DB. Maybe we should reconsider it. Any suggestion is more than welcome on how we should handle this situation.
2 Likes
The issue is indeed with gr-satellites, we at TU Berlin have also noticed it. The cause is the new MobiTUB decoder by @kerel designed for TUBIN/TUBiX20. BEESAT-1 causes here a problem due to different framing. The good thing is it was already fixed in gr-satellites, see:
Mobitex: Drop frame if none of the datablocks is correct by kerel-fs Β· Pull Request #775 Β· daniestevez/gr-satellites
I guess now there needs to be a new gr-satellites release or the station owners have to install from source to remove this error.
Btw. since its recovery last year BEESAT-1 is operated from time to time, mainly depending on how much time the team has.
1 Like