portapack-mayhem / mayhem-firmware

Custom firmware for the HackRF+PortaPack H1/H2/H4
https://hackrf.app
GNU General Public License v3.0
3.52k stars 565 forks source link

add noaa decoder #731

Open dekid69 opened 2 years ago

dekid69 commented 2 years ago

for the hackrf mayhem it would be nice if there is a support to decode noaa sattelites

Brumi-2021 commented 2 years ago

Are talking about decoding 137 MHz weather satellite band? , if so , I think that issue is duplicated to #121

BehleZebub commented 2 years ago

I guess @deboi238 talks about NOAA weather satellite APT images @137MHz, APT encoding is explained here (wikipedia). NOAA weather alert/SAME is something different, it's a terrestrial broadcast @162MHz and that's what #121 is about.

AFAIK mamesshao8 has "RX NOAA" already implemented but the code is closed source.

I'd like to give it a try to implement a APT receiver, but it will take a long time to finish.

ImDroided commented 8 months ago

Has any work been done on this? This would be a cool app. It sucks @jamesshao8 has decided to not contribute his work as he has done come cool stuff . I don't know who pissed him off but it wasn't worth it lol. He has noaa sat images decoder, weather fax decoder, color sstv rx and tx plus a bunch more.

dekid69 commented 8 months ago

Sadly there’s no work has been done on this, I really like this feature like to be implemented to the mayhem

On Tue, Mar 26, 2024 at 8:35 PM ImDroided @.***> wrote:

Has any work been done on this? This would be a cool app. It sucks @jamesshao8 https://github.com/jamesshao8 has decided to not contribute his work as he has done come cool stuff . I don't know who pissed him off but it wasn't worth it lol. He has noaa sat images decoder, weather fax decoder, color sstv rx and tx plus a bunch more.

— Reply to this email directly, view it on GitHub https://github.com/portapack-mayhem/mayhem-firmware/issues/731#issuecomment-2021861960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVPQCXOZKRPCBPNFBBXOCKTY2I47VAVCNFSM6AAAAAARMTQLCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRRHA3DCOJWGA . You are receiving this because you were mentioned.Message ID: @.***>

htotoo commented 8 months ago

Can anyone provide a good quality c16 (pp recorder) recording? Not just the beginning (I only found that), but a bigger chunk of the image?

sergeyvfx commented 1 week ago

@htotoo Hey! I have some I've been using for own decoder I've been working a while ago: https://github.com/sergeyvfx/radio_core/tree/main/data/test/apt

The NOAA_44100.wav is an audio recording from SDRSharp. I think it is 16bit int samples, 44100 samplerate. As a readme file suggests there seems some dropped packets in it. I never figured out what caused them, but seemed useful to have those to help debugging synchronization mechanism in algorithm.

There is grid_test_44100.wav which is generated.

Both WAV files have a decoded image next to them, so you can see what part they actually contain.

I do have a raw IQ capture of the transmission, but it is quite big. Not sure it is more useful than an audio file.

Not sure how far you're with your work on getting APT decoder. If it helps, the algorithm I came up with is implemented in decoder.h, with a command line tool implemented in decoder.cc. It is quite naive implementation, nothing too fancy about it, but it worked quite good for the radio and antenna setup I've got. The tool is aimed for an offline usage, but the processor itself supports streaming.

There are also test files and decoders for SSTV, which might help with #2045.

Unfortunately, I am not sure whether I'll have enough time to dig into trying to implement the same in Mayhem, don't even have the portapack (yet :). But I am available to reply questions or even do more recordings! Just ping me if you think I can be of help.

I wish you all the best of everything! I really hope extra decoders can be implemented in Mayhem :)

htotoo commented 1 week ago

I can't replay the wav from one pp to another, only the c16. And replaying is far more efficient testing, than waiting for the next pass.

BehleZebub commented 1 week ago

@sergeyvfx thank you for the test files and decoder. I don't know, when I'll be able to look into this, but it surely helps for creating the NOAA app.

@htotoo it is possible to connect the output of one hackRF to the input of another, but connecting them directly will mostly fry the input stage, iirc. an -20dB attenuator should work fine to drop the max 15dBm output to the max allowed -5dBm of the input circuit.

sergeyvfx commented 1 week ago

@htotoo There are a few things I can think of:

@BehleZebub Understandable, no worries!

htotoo commented 1 week ago

Noone wanted to wire 2 pp-s together, they have antennas ;) Also would be preferable to have a big c16, that has a lot of other things too, not just a selected. that could help with the filtering, ...

So when playing a decodeabla signal from one pp to another, that has "everything" in it, is a more likely real world usage, than the wav playback. And i would love to prepare to a real world usage, not a "lab one".

image

sergeyvfx commented 1 week ago

The NOAA_44100.wav is an actual recording, just of audio, not an IQ. If you know a good place where i can share 190 meg of file I can provide the IQ recording of the same pass.

There is no single real world scenario, everyone has different antennas, different weather conditions, etc. At the end of a day what matters is SNR. In the "lab" configuration you can simulate different SNR levels, and say "the decoder will lock onto a signal once you have N B of SNR".

It is also way easier to start with the cleanest input possible, and put the foundations of the decoder, and make sure those work. Dealing with the more noisy scenarios is more like tweaking tolerances, filters, etc. Starting with a mindset to write a decoder that handles the lowest possible SNR is quite hard.