In ref. to my potential Stars-X decodes being SNIPE-D, it looks like the frames are different, so it doesn’t appear so. Certainly could still be some other sat, though!
2 Likes
I’m sure everyone does the same thing… I had ChatGPT analyze my presumed BRO-22 decodes and in addition to some less interesting observations, it identified:
… and when I specifically asked if the last 4 bytes of each frame were a checksum (and if so, which variety), we got a nice clean answer there:
4 Likes
Since we don’t have AX.25 addresses to check against w/ AX100 frames, if anyone would like a method to ensure that only valid decodes are sent to SatNogs from BRO-22, here are the settings that work in the ‘Check CRC’ block when using GNU Radio + gr-satellites:
3 Likes
can it manually set on satyaml file ?
To ensure that the frames come from BRO-22 you may additionally use the gr satellites block Check Hex String.
In case the frames start with
0x836780.
3 Likes
Sorry I sure don’t know. It’s a single block w/ it’s own settings… pass or fail.
No, there is no CRC option for the Yaml configuration
1 Like
BRO-22 still going strong, so I’ll devote future passes to trying to determine if anything is really being downlinked from STARS-X.
5 Likes
It appears that Object #69504 (132-C) is closest to the orbit of BRO-22 that you all kindly provided just after launch. (Corrected my original post; new pic reflects consistent Object #'s)
1 Like
Thanks! BRO-22 set in DB to follow 69504.
3 Likes
A decent -83- decodes tonight from BRO-22 w/ the 2.5-turn helical omni. Note that it’s now showing as Object # 69504 in the TLEs as well.
5 Likes
