dernasherbrezon / r2cloud

Decode satellite signals on Raspberry PI or any other 64-bit CPU.
Apache License 2.0
255 stars 30 forks source link

NOAA Spectogram from no-resample #101

Closed Lukas0025 closed 3 years ago

Lukas0025 commented 3 years ago

Is possible to make spectogram from no-resample sample? Because you are doing a spectogram from a resampled, the spectogram looks different than with SATNTOGS or GQRX. It would be better if the spectogram was bleached from the original sample.

I noticed that you are already doing a resample when receiving using pipelaining. Therefore, I understand that this would be an intervention in the structure of the program because you would have to do a resample after you do the spectogram, or do a resmaple for decode and delete it after decoding.

dernasherbrezon commented 3 years ago

are already doing a resample when receiving using pipelaining

Can you please elaborate? Spectrogram is being created from raw I/Q https://github.com/dernasherbrezon/r2cloud/blob/master/src/main/java/ru/r2cloud/SpectogramService.java#L69

Lukas0025 commented 3 years ago

Yes you creating spectogram from raw I/Q, but you have other sample rate for APT, LRPT, FSK_AX25_G3RUH and TELEMETRY

https://github.com/dernasherbrezon/r2cloud/blob/21d19469777837c6aadfc1f09590b06d949836ba/src/main/java/ru/r2cloud/satellite/ObservationFactory.java#L83

Because you use different sample rates for other protocols, that's why you have different range of frequency (width) on spectrogram.

Meteor-m n2 (sample rate 144000) NOAA on top meteor

NOAA 18 (sample rate 11025) noaa

It's not a problem that would be important, but if someone wants to compare spectograms through satellites, it will be a problem.

You can fix it witch add frequency to spectogram, or make spectograms from same sample rate

dernasherbrezon commented 3 years ago

Ah, I got it.

Yes, they are different, but should be taken from input sample rate:

Meteor: 288k Telemetry: 240k APT: 11k

So overall flow is this:

  1. run rtl_sdr or rtl_fm on inputSampleRate
  2. Save the raw data
  3. Create spectogram from the raw data (288k)
  4. Demodulate raw data. First step of demodulation is a resample. So for meteor the data will be resampled from 288k to 144k. Doppler correction & the rest of demodulation/decoding will work on that 144k stream.

The APT algorithm is a bit different, because APT is processed by rtl_fm + sox. The raw data file in this case will contain only 11k.

I can change APT to store the raw data from rtl_fm (60k) and generate spectogram from it. But that would increase the disk space required for APT observations. And before doing that, I need to understand the use case.

Can you describe the use case when some one wants to compare spectrograms between different satellites? Currently input sample rates selected very specifically to make "samples per symbols" integer. For example meteor has the following:

Input sample rate 288k / 2 = output sample rate (144k) / 2 = LRPT baud rate 72k.

Lukas0025 commented 3 years ago

I personally would use it for nonsense with signals, but otherwise I did not find any reasonable use, so I close the issue.