INMARSAT Aero 10500 with CLI tool about satdump HOT 25 CLOSED

So, for inmarsat you "need" (for most narrow band signals, if you have a dc spike) to use offset tunning, passing the arg --offset.
The reason you're getting such a high SNR and no sync is because of the dc spike of the rtl-sdr. You can remove the dc spike using --dcblock, but, as I said before, inmarsat channels (especially STD-C) are pretty narrow in bandwidth, so even with the dc spike being blocked, you'll lose a considerable amount of the signal.

from satdump.

For the offset, what you want is: select a center frequency just below or above the actual signal you want (for this case in particular/inmarsat) with --frequency, and then pass the offset of the signal you want from the center frequency with --offset.

For example: 1539.5 MHz as the center frequency, and if the signal were to be at 1539.6 MHz. the args passed would be --frequency 1539.5e6 --offset -100e3

If you still have trouble decoding or if you want to, you can join the matrix help room and there will be people to help you.

from satdump.

Thanks so much for the help. So I've tried to now account for that DC spike by choosing a base frequency and off-setting to get to the actual center freq.

Something isn't right with the INMARSAT_AERO_105 decoding, I just get invalid CRCs over and over:

[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (E) Invalid CRC!
[12:21:10 - 03/12/2023] (I) Progress nan%, Lock : NOSYNC, Viterbi BER : 0.000000%, Lock : NOSYNC 

Though this could be simply because we aren't locked onto the signal properly.

I'm going to park AERO for now and just try to get STD-C working then come back to it. I'm now using this command for STD-C: satdump live inmarsat_std_c /root/inmarsat-stdc/ --source rtlsdr --bias --gain 40.2 --samplerate 2400000 --frequency 1539500000 --offset 4700

SNR is substantially better, but for some reason I still get no sync:

[12:14:00 - 03/12/2023] (I) Progress inf%, SNR : 10.816330dB, Peak SNR: 10.816330dB
[12:14:10 - 03/12/2023] (I) Progress inf%, SNR : 15.115590dB, Peak SNR: 15.497877dB
[12:14:20 - 03/12/2023] (I) Progress inf%, SNR : 15.245454dB, Peak SNR: 15.523817dB
[12:14:30 - 03/12/2023] (I) Progress inf%, SNR : 15.169564dB, Peak SNR: 15.578302dB
[12:14:40 - 03/12/2023] (I) Progress inf%, SNR : 15.350992dB, Peak SNR: 15.578302dB
[12:14:50 - 03/12/2023] (I) Progress inf%, SNR : 15.234881dB, Peak SNR: 15.578302dB
[12:14:50 - 03/12/2023] (I) Progress nan%, Viterbi BER : 0.000000%, Lock : NOSYNC

Is there something else I can try or anything I can do to troubleshoot a bit deeper?

I will also look at setting up Matrix, though I'm hoping to post whatever the solution is into this GitHub issue so that if some other poor soul on the Internet ever comes across it, they have the answer :)

from satdump.

So, my guess is that the offset is wrong, could you send a small baseband for me to check? like 1 minute or so.

Also keep in mind that if the signal is above the center frequency, you use a negative offset, because its center frequency - signal frequency

from satdump.

Sometimes the SNR can get high from other signals or even because its only getting the "border of the signal", like, just a tiny part of it, the constellation can look right, but the correlator won't sync.

from satdump.

Okay so further testing.. I've installed satdump on a Windows machine so I can use the GUI and I've recorded the baseband file (attached in ZIP - GitHub wouldn't let me go bigger than 25MB so it's quite short but you'll see what I mean).

Below is a live stream in SDR#, tuned into 1.539.594.300 (base frequency that SDR# sent to RTL-TCP is 1538900700):

I then connected satdump to RTL-TCP at that same center frequency and recorded. Here is the waterfall when I fed it into SDR#:

Not sure if this is an SDR# quirk, but the waterfall looks like a mirror image, and even sounds like one when I looked at the similar spikes on either side.

Anyway, I flicked through the spikes in the waterfall and nothing in there is wide enough to be STD-C, nor do any of the signals in there sound like it.

I checked the RTL-TCP logs, satdump is indeed asking for the correct center frequency:

Let me know if you're able to make anything of the baseband recording. For what it's worth, when I piped the audio from SDR# into Scytale-C at the aforementioned frequency, I was able to decode just fine (so I'm not barking up the wrong tree with the frequency, at least).

from satdump.

Looks like it didn't upload, at least I can't see any attachments, and yes, its showing a mirrored image on the second SDR# screenshot.

Could you record a baseband file with satdump and upload it on https://www.swisstransfer.com/?

from satdump.

And yes, scytale-c will work, because you're tunning the signal with a VFO, so it's "easier"/more intuitive than using frequency offsets, because oftentimes the tuner is not actually tunned at the exact frequency it says so that the channels will be slightly off, and that's what I think is happening.

from satdump.

Sure, here's the recording: https://www.swisstransfer.com/d/74e48d94-2243-4589-99e4-11181fc98200
I recorded using this command: satdump record /root/basebandrecord --source rtlsdr --bias --samplerate 2048000 --frequency 1339.5e6 --baseband_format ziq --timeout 60

That makes sense about Scytale-C, I can see visually that it is doing the fine-tuning itself. Not sure if there's an easy way to use that to my advantage to find the frequency easier that I can then feed into satdump, but we'll see what you find in the recording. Thanks heaps for this!

from satdump.

The recording is using a wrong frequency of 1339.5e6, should be 1539.5e6.

from satdump.

Far out sorry - my mistake! Here is the correct base freq recording: https://www.swisstransfer.com/d/ff383d81-bcb2-43e1-9440-73a2513ede1f

Command used: satdump record /root/basebandrecord --source rtlsdr --bias --samplerate 2048000 --frequency 1539.5e6 --baseband_format ziq --timeout 60

from satdump.

Are you sure everything is right with the setup? There is nothing on both recordings you sent.

Could you try using the GUI to record or going over the setup to check that it is working? Maybe some cable or something is not connected or the antenna is not pointing at the sat?

from satdump.

Well it helps if I add the gain to the command, apologies I'm a bit of a toddler with satdump lol. I've run this one through the GUI myself and can definitely see signals showing up now: https://www.swisstransfer.com/d/e35ed7a3-2e00-486f-9595-a595369bf5f8

Is there an intuitive way to use the GUI to "find" the offset? I could do this then bring it over to the CLI.

edit: adding the record command used: satdump record /home/lcladmin/basebandrecord2 --source rtltcp --bias --samplerate 2048000 --frequency 1539.5e6 --baseband_format ziq --timeout 60 --gain 38

from satdump.

Lol it happens! all good, so it shows up now.

So, what I do is, I stick with a center frequency like I've said, in this case you did 1539.5e6, then I open the GUI and I find the offset using my mouse hovering over the FFT, then I set the offset and I check if its decoding. For inmarsat STD-C you have the correlator and viterbi, if its like the image below, its working, it can take ~8.64s to sync (as this is the time the sat takes to send each frame), but it will show up as the image you see.

Another thing to look at, if, for example, the correlator is not syncing but you have a constellation, you might've not set the proper offset, and also the constellation will look kinda oval, and not circle-shaped as the image below.

Something else that can help tunning is using Decimation, because it allows you to have a ""zoomed in"" version of the IQ, and its easier to find the right offset.

Another very good thing is that the STD-C channels have a 1 KHz spacing, so, even if they are not using a spacing of 1 KHz for every channel, they will all be sums of 1 KHz. For example:

The first signal, right after the DC spike is at an offset of -5.3 KHz;
The second signal after it, is at -15.3 KHz;
And so on...

from satdump.

First signal:

Second signal:

from satdump.

Ah awesome! I've done some testing which consisted of:

• Confirming I can get the decoder working on the same offset as you had (and others)
• Re-recording and being able to repeat this on new recordings
• Connecting the GUI version of satdump to rtl_tcp and decoding live

My error I think was not using a negative number for the offset (I was confused because in my mind we're counting up from the base frequency, not down, so my logic was it should be a positive number but this isn't the case).

Interestingly, I'm still unable to get the CLI version working properly. Again seeing lots of NOSYNC messages and no data coming in:

[11:40:50 - 09/12/2023] (I) Progress inf%, SNR : 25.659397dB, Peak SNR: 25.778980dB
[11:41:00 - 09/12/2023] (I) Progress inf%, SNR : 26.030111dB, Peak SNR: 26.059351dB
[11:41:10 - 09/12/2023] (I) Progress inf%, SNR : 25.613144dB, Peak SNR: 26.133219dB
[11:41:20 - 09/12/2023] (I) Progress inf%, SNR : 25.830538dB, Peak SNR: 26.133219dB
[11:41:30 - 09/12/2023] (I) Progress inf%, SNR : 26.029072dB, Peak SNR: 26.133219dB
[11:41:40 - 09/12/2023] (I) Progress inf%, SNR : 25.823425dB, Peak SNR: 26.133219dB
[11:41:40 - 09/12/2023] (I) Progress nan%, Viterbi BER : 0.000000%, Lock : NOSYNC
[11:41:50 - 09/12/2023] (I) Progress inf%, SNR : 25.601208dB, Peak SNR: 26.133219dB
[11:42:00 - 09/12/2023] (I) Progress inf%, SNR : 25.942829dB, Peak SNR: 26.179716dB
[11:42:10 - 09/12/2023] (I) Progress inf%, SNR : 25.324083dB, Peak SNR: 26.179716dB

I'm using the GUI to find the signal first on the waterfall, here is what I did in the GUI:

• Connect via rtl_tcp to the remote SDR
• Tune in to 1539.500000 base frequency
• Set decimation to 2 (to "zoom in" like you suggested)
• Set the sampling rate to 1.536Msps
• Set the gain to 20 (presumably this is dBm)
• Enabled Bias-Tee

I found an STD-C signal at an offset of ~6.3kHz and eventually fine-tuned that to 6.43kHz. I then took this info and used it to form the CLI command, which ended up being: satdump live inmarsat_std_c /root/inmarsat-stdc/ --source rtlsdr --bias --gain 20 --samplerate 1.536e6 --frequency 1539.5e6 --offset -6430

As far as I can tell everything is correct here:

• Base frequency is the same as what I used in the GUI
• Offset is the same as what I've used in the GUI (6.3kHz) and got a successful decode with
• Sample rate same as GUI
• Gain I've tried at 20 dBm (worked in GUI) and 38 (what I recorded the baseband file with last time)

Is there anything obvious to you that I might have missed in my command?

from satdump.

What you did differently thing you did on the CLI was using -6430 and not -6300, and you can use --decimation 2 as well if you want. Its not necessary, but it can help you get more SNR.

from satdump.

Yeah I've tried both offsets, in the GUI I got a slight improvement fine-tuning it to an offset of -6430.

Is it possible the --offset parameter isn't passing through to something properly in the CLI version of satdump? I've tried with --decimation 2 added as well but still can't get a lock. The signal is definitely there at that offset because it works perfectly in the GUI, it just seems to be the CLI that isn't happy.

from satdump.

Oh god I'm so sorry, I forgot my brain somewhere lmao, its not --offset its --freq_shift

from satdump.

Not gonna lie I actually lol'd out loud, it happens hahaha

Well.. that did it :)

13:30:38 - 11/12/2023] (I) Start processing...
[13:30:38 - 11/12/2023] (I) Using input frames 
[13:30:38 - 11/12/2023] (I) Start webserver on 0.0.0.0:8080
[13:30:40 - 11/12/2023] (I) Progress inf%, SNR : 0.000000dB, Peak SNR: 0.000000dB
[13:30:50 - 11/12/2023] (I) Progress inf%, SNR : 11.790677dB, Peak SNR: 12.187071dB
[13:30:56 - 11/12/2023] (T) Got STD-C Frame Corr 121 Inv 0 Ber 0.128906 No 5630
[13:30:56 - 11/12/2023] (I) Packet : Bulletin Board
[13:30:56 - 11/12/2023] (I) Packet : Signalling Channel
[13:30:56 - 11/12/2023] (I) Packet : Signalling Channel
[13:30:56 - 11/12/2023] (I) Packet : Signalling Channel
[13:30:56 - 11/12/2023] (I) Packet : Enhanced Data Report Acknowledgement
[13:31:00 - 11/12/2023] (I) Progress inf%, SNR : 12.022723dB, Peak SNR: 12.425486dB
[13:31:05 - 11/12/2023] (T) Got STD-C Frame Corr 126 Inv 1 Ber 0.230469 No 5631
[13:31:05 - 11/12/2023] (I) Packet : Bulletin Board
[13:31:05 - 11/12/2023] (I) Packet : Signalling Channel
[13:31:05 - 11/12/2023] (I) Packet : Signalling Channel
[13:31:05 - 11/12/2023] (I) Packet : Signalling Channel
[13:31:10 - 11/12/2023] (I) Progress inf%, SNR : 11.879372dB, Peak SNR: 12.425486dB

We are in business! Thank you so much for your help, it's really made a huge difference, I'm going to figure out what I can do with this data now :) Feel free to close this issue

from satdump.

hahaha thats awesome!

You're welcome!

If you want more data in the future you can decode all at the same time with --multi_vfo and a json file :)

from satdump.

Oh that's awesome! So with that can I set multiple offsets that are adjacent and decode them all at once? e.g. I could pick up pretty much all the STD-C signals at the same time?

I've tried to dig up a central list of the CLI options for satdump but all I've managed to come up with is this one that doesn't mention some of the arguments we've used: https://www.satdump.org/posts/basic-usage/#cli-this-part-was-made-by-aang23

Is there somewhere else I could find them so I can mess with the CLI a bit more?

from satdump.

Yes, you can get every one of them!

So the way of doing it is using --multi_vfo file.json, in the json file you need to specify the name of the vfo, the frequency (the actual frequency, not the offset), and the pipeline name.

As an example:

{
	"vfo1": {
		"frequency": 1539505035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo2": {
		"frequency": 1539525035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo3": {
		"frequency": 1539545035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo4": {
		"frequency": 1539555035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo5": {
		"frequency": 1539565035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo6": {
		"frequency": 1539585035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo7": {
		"frequency": 1539595035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo8": {
		"frequency": 1539615035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo9": {
		"frequency": 1539635035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo10": {
		"frequency": 1539665035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo11": {
		"frequency": 1539675035,
		"pipeline": "inmarsat_std_c"
	},
	"vfo12": {
		"frequency": 1539685035,
		"pipeline": "inmarsat_std_c"
	}
}

Then you save it as a json file, and you do it as I said above. Also with the multi vfo option you don't use the --freq_shift option.

from satdump.

You can do this for every other pipeline, not just for inmarsat!

from satdump.

Thank you so much! That is awesome. I'm going to close this issue, really, thank you so much for going above and beyond to help me figure this out :)

from satdump.