Why don’t the packets decode as “data”? Should there be an “AX.25” demod option instead of the “AFSK 1K2” for the 145.825 APRS downlink frequency? Note that the strong signals in this waterfall are my own terrestrial based uplink packets - which I assumed should have no difficulty being decoded.
I guess I just am not sure how the built-in decoders work - only the NOAA APT decoders have worked for observations that I have scheduled on my station (although others have scheduled observations that do show decoded telemetry frames).
Encoding in like the base encoding. For example for something like APRS its AFSK1K2 with a AX.25 Framing. Which I think (I haven’t looking on gitlab to see what they do for it) the AFSK 1K2 decoder is built with AX.25 framing as its generally the normal framing.
I’m not a coding guy, so unfortunately I’m not really sure what these documents do. My question essentially is “Is the satnogs client supposed to automatically decode the APRS frames and upload them to the server?”
For the start and end of the pass, yes. But for the middle portion of the pass there is no doppler correction in either direction - and those packets should decode, no?
So - right off the bat, I don’t think our AFSK1k2 script is successful with NO-84 (yet - but we are improving on them weekly). That said, you have a successful observation of the packets, successfully doppler-corrected for. Don’t be confused by the really strong signal bursts, I’m not sure what they are but given the curve they are probably terrestrial. Here are the NO-84 packets themselves:
Ok, so my understanding is that, Yes - the built in decoder is supposed to automatically decode the packets. But in this case it just isn’t successful at doing so yet.
Those “strong signal bursts” are my own 145.825 uplink packets (with 3 tuning steps) as I attempted to work NO-84 from my front yard, about 100 feet from the Satnogs antenna.
