Inmarsat 143 C-Band help?

[thebaldgeek]

Loving the software!! Thanks again for all your help and input.
I have thus far only been using it on L-Band on 3 different sats and its been going well. Tonight I have tried my first C-Band setup.
While I live in USA, I have a good contact in Australia that I have helped get his dish set up with tracking and GPSDO LNB.
I spent a solid 5 hours tonight trying to get his C-Band setup moved off VAC and SDR-Console/SDR# and onto SDRReceiver since he gets a lot of CRC errors etc.
After 5 hours, I have nothing.

I am using your 143.ini file, but even after extensive tweaking I can not get more than one Jaero to decode.
To show some contrast, here is a badly adjusted waterfall.

I have opened the other SDR software and tried to find the center of first 2-3 VFOs and adjust the ini file to match, but just cant get Jaero to give anything solid. As I said, I know SDRReceiver is working as I can cut the .ini file down to 1 VFO and get some good decodes, but as soon as I add a second, I cant get both to lock - its only one or the other.
Unlike L Band, with C Band it seems when you select a single VFO you just cant see anything on the waveform? Win 10. new Dell PC with SSD and 32g RAM, 3.4GHz CPU etc, its a powerful machine.
Thanks for your thoughts.

BTW, writing up my how-to here: https://thebaldgeek.github.io/SDRReceiver.html

[jeroenbeijer]

The bottom jaero spectrum looks a little odd. I can't see any obvious reason why adding more VFO's would cause such a problem but there is always the unexpected. If you run with only the VFC02 VFO details does it work? I assume the topic names match up between jaero and the SDR? I am away travelling and won't have much time until early next week. From the SDR point of view it does not know if its doing L or C band btw.

[thebaldgeek]

C-Band update.
I put in about 9 hours over the weekend, so I am now in the pocket for around 14 hours and still cant get any Jaeros to reliably decode.
Two interesting aspects. If we move the 'Main' frequency up via the radio buttons (to around 1546198600) in the GUI we can get 1-2 Jaeros to decode some messages, but if we then copy paste or type that new frequency into the ini file in the 'Center_frequency' parameter when we restart SDRReceiver, it ignores that value and uses the original center frequency. (Thus we have to make this offset every time we start the receiver). This makes me think its hard coded or odd values are rounded/up/down. If we change other parameters in the ini file, the changes are reflected as expected, so we know we are using the correct .ini file.
Along the same lines, if we try and use the 'mix_offset' parameter, to achieve this center point shift, it is also ignored. Setting it to a higher or lower value makes no difference.
Thus we have to try and hand adjust / guess each of the VFO's. To try and save sanity, we have only been working with 2-3 VFOs in the 10500 range to start.
I fully understand that the receiver does not know C from L, but its been very difficult to get C up and running.
If we fall back to the old VAC ways, we can get 10+ Jaeros decoding 10500 and some 1200 burst with the usual random BAD CRC errors in about 5 minutes.

TL:DR I'd love to know more about the filter_bandwidth, gain and out_rate. The center_frequency and mix_offset seem buggy.

Also over the weekend I helped 4 people get up and running on L-Band. Most take around 15-20 minutes.
One was interesting, SDRReceiver would just crash/close with no errors when the SDR was started, but SDR# ran fine. Looking at the Windows device manager, the RTL dongle was not shown. Reloading the driver got him up and running quickly (I found out after reloading that he had the dongle on the end of a long USB extension cord!)
Most get stuck with making the .ini file (Windows adds .txt after it) and making the start bat file for SDRReceiver and Jaero.
Once you create those files and put them on the desktop - it just works every time.

[jeroenbeijer]

Not seeing what you are seeing ref sample rate and mix offset, the values should be read from the ini file each time, there is no hardcoded center frequency:

So no idea what is going on there. Is this with an RTL SDR V3?

I don't have my C band dish setup here at the moment so I am unable to try this myself. It is running fine at a friend in Australia. I ran the C band ini file on an L band antenna and things look ok, the correct rate is sent to Jaero at least so I don't see any issues there.

[jeroenbeijer]

I realize I have not fully documented all keys, timing was a bit unfortunate. filter bandwidth is simply an audio low pass filter with the key value being the passband width. 0 indicates no filter. It uses the hamming window.

out_rate can be used to specify the output audio rate iso of using the data rate. For burst mode jaero expects 48Khz always.

The gain is simply an integer multiplier to increase or decrease the audio gain into jaero until you get a green ball.

Also note that checksum errors on C band will happen regardless of whether you have a perfect audio stream. Particularly on the 1200 burst channels the signals are so weak I doubt anyone without a really professional setup can decode all messages without checksum errors.

[jeroenbeijer]

Happy to help troubleshoot this further but I am gonna need some information in that case, i.e. what type of device was used and the full ini file. I have no indications to believe the changing the center frequency and or the offset key would not be read properly when starting up.

[thebaldgeek]

I am using an RTLSDR v3 SDR dongle. Its the same one we have been using in SDR# and SDR-Console with VAC, so I am confident the hardware is Ok.
I will attach an example .ini file, but its the same as the one you provide as an example.
The issue is that with the .ini stripped down to one VFO, we can not get a single Jaero to decode.
There is something about C-band data that is different from L-Band data that stops it from working. (As best as the 3 of us that have spent hours and hours trying to get C-band up and running).

[jeroenbeijer]

Don't see the ini file attached. I did spend quite some time myself to recreate the issue you have without any luck. I think good to make sure the ini file does not contain any text or duplicate keys after the last VFO. So if you can share the exact ini file I can just debug through it to see if anything there may be causing the problem.

[thebaldgeek]

What sized C-Band dish are you using? What satellite are you looking at? I can provide the file to match.

[jeroenbeijer]

120cm. I took it down some time ago since I am somewhat limited with garden space and 25E would require the dish to be in an awkward spot. 54W works ok but there is so little traffic there now I did not think it was worth the trouble. I will rig it up again though. I am mostly interested in the ini file that produced the weird looking spectrum that you attached initially. Or if you have one that does not seem to work for you for 97W I can run it here just to see if the settings work out as they should.

[jeroenbeijer]

So I setup my C band dish for 54W again. Seems it drops below the horizon here when it is at the bottom of the loop so I don't always get signal these days. Also seems my external tcxo broke so I used a standard single output titanium LNB. Anyways I had no difficulties getting all 4 10500 burst channels, both R and both T channels. The frequencies I entered in the ini file were right out of SDR# and they worked directly. So the freqs shown in SDR# are very close if not an exact match with the frequencies to be used in the ini file. I did get a few hits on 1200 burst yesterday but the signal is pretty weak and with the standard LNB it is easy to drift off freq.

Clearly the FFT in the application is not really suitable for C Band but when you select the VFO you can see the bursts.

The ini file I used looks like this. I only added 2 x 1200 channels so obviously that part needs working on.

center_frequency=1535600000 zmq_address=tcp://*:6003

auto_start=0 auto_start_tuner_idx=0 tuner_gain=496 correct_dc_bias=1 mix_offset=0

[main_vfos] size=2 1\frequency=1536200000 1\out_rate=192000 2\frequency=1534943490 2\out_rate=192000

[vfos] size=6 1\frequency=1536199985 1\gain=0.5 1\out_rate=48000 1\filter_bandwidth=24000 1\topic=VFC01

2\frequency=1536217553 2\gain=0.5 2\out_rate=48000 2\filter_bandwidth=24000 2\topic=VFC02

3\frequency=1536231100 3\gain=0.5 3\out_rate=48000 3\filter_bandwidth=24000 3\topic=VFC03

4\frequency=1536245703 4\gain=0.5 4\out_rate=48000 4\filter_bandwidth=24000 4\topic=VFC04

5\frequency=1534943490 5\gain=0.5 5\out_rate=48000 5\filter_bandwidth=3000 5\topic=VFC05

6\frequency=1534905300 6\gain=0.5 6\out_rate=48000 6\filter_bandwidth=3000 6\topic=VFC06

I made a slight change to the gain setting for each VFO, I will commit this shortly and rebuild on github. I had to enter a value lower than 1 so I just changed this to a float when the ini file is read so one can enter decimal values.

So in summary, I have no clue why you could not get more than 1 burst channel to work. I suspect something in the ini file or the zmq parameters with jaero. So if you want to share an ini file that causes you problems I can have a look. I also realize the frequencies for the 143E C band ini file may not match for every setup depending on LNB used and its LO frequency. But it is easy enough to adjust the frequencies appropriately if needed.

[thebaldgeek]

Thanks so much for the sanity check. I know its a lot of work you just put in to prove that it can decode C-band data. Setting up the dish etc is a solid chuck of time and effort and I really appreciate it.

I spent around 5 hours today trying to get a single VFO and single Jaero to decode to no avail. Here are some screenshots to help show you what we are looking at.

That's the native SDRReceiver setup. We don't know how to set the VFO frequency, your readme.md says we need to change it for C-band, but no other details. We tried moving it up and down, but never got any signal or decodes in Jaero.

Next, here is how we set the main frequency and the VFO using SDR# as you suggested. And the VFO:

I think that should give you an idea of how we are trying to get the ini file configured.

The SDR# screenshots are just to show you the signal and frequencies since its impossible to see any signal on SDRReceiver on C-Band (Which is Ok, if we knew how to set the main VFO(s) frequency I think).

We also tried many different gain settings in both the SDR gain setting and the VFO gain settings, as I said, there were around 5 hours of testing many (hundreds?) combinations of settings in the .ini file.

Just to correct the last comment in your last reply, we can get not a single burst channel to work reliably. I am trying to understand the .ini file as I have 3 satellites to set up, 98W, 143E and 25E. All three of us are so tired of BAD CRC errors from VAC. All three of us are running SDRReceiver on L-Band and it took 10-15 minutes to get going. Beyond happy with it and why we are all working hard to move our C-band setups over to it... But C-Band is just not working at all for all three of us.

Here is the ini file we were testing with.

sample_rate=1536000
center_frequency=1547000000
zmq_address=tcp://*:6007

#remote_rtl=127.0.0.1:1234

#valid tuner gains r82xx_gains[] = { 0, 9, 14, 27, 37, 77, 87, 125, 144, 157, 166, 197, 207, 229, 254, 280, 297, 328, 338, 364, 372, 386, 402, 421, 434, 439, 445, 480, 496 };
tuner_gain=402
correct_dc_bias=1
mix_offset=0

auto_start=1
#auto_start_tuner_idx=0


[main_vfos]
size=1
1\frequency=1547000000
1\out_rate=192000


#VFO's in frequency order from lowest to highest, first 7 are 10500. 

[vfos]
size=1

1\frequency=1547018000
1\gain=5
1\out_rate=48000
1\filter_bandwidth=24000
1\topic=VFC01

[jeroenbeijer]

Your VFO gain is too high, a red volume light is not good (depending on how bad it is which is not visible I guess). Did you pull the latest SDRReceiver build? (It did also work with the previous version with gain = 1 btw) I would put the tuner_gain to the highest value 492 and then adjust the VFO gain down until you get 3 greens on messages (0.2 here). When I tried it with the settings in your ini file I got nothing myself. Reducing the VFO gain fixed that. Otherwise the ini file should be good, I tried it with the exact same setup but obviously with a different center and VFO freq for 54W. You may want to cut the filter bandwidth to something like 16Khz to avoid any interference from adjacent channels.

One other thing I just noticed. I pulled the latest jaero and when starting it directly in 10500 burst mode I noticed it missed a lot of messages Bad R/T Packet even on strong bursts. However when I cycled to 1200 burst (or any other mode) and then back to 10500 burst it seemed to work much better. Could just be my eyes playing tricks on me but maybe you can try it if you are faced with the same situation. Will have a quick look at the jaero code.

BTW, double checked the SDR# freq vs. ini file freq, what you have shown above should work.

[jeroenbeijer]

Right, so there was bug in jaero for the burst modes, I missed that earlier. QT connections are not unique by default and hence the burst demodulators got duplicate data. Fixed that so the connections are created uniquely.

I have sent a pull request to Jonti but not sure when he has time. So in the meantime you can use my jaero fork release package which I just completed building. It is identical except for this small fix.

[thebaldgeek]

The trouble with screenshots is they only show 1 second of 5 hours. I tested dozens of SDR and sub-vfo gain settings. Red LED, green LED and gray LED, zero decodes in all states. I used your latest build as of 16 hours ago, so am confident with that side of it. I understood that SDRReceiver using data vs audio, the volume LED was not important. You are suggesting otherwise? ie, on L-Band we get solid decodes no matter what color the volume LED.

The question of how to set the main VFO frequency is unanswered. The SDR mid band is very clear, look at the waterfall, find the top, bottom and thus the middle point and set the SDR to that. The main VFOs is a mystery. Can we run say 17 sub-vfos from one main vfo? If not, how do we decide how many main vfos to configure and how do we calculate their frequencies?

Thanks for tracking down that decoder bug. I have been reading the change notes for each Jaero and did not see any code changes to the decoder so thought the issue was else where. Any idea how long that bug has been around? Will begin testing your fork today.

[jeroenbeijer]

Regardless of the source of the data, if the incoming audio volume is too high you will get clipping and all sorts of things will happen rendering the data useless for decoding. It seems with the C Band LNB as source the VFO gain will need to be lower than typically is the case for L band. So generally speaking one should aim for a green volume light in jaero even if there is some margin.

I think I wrote a few lines on the concept of the main VFO's on the readme page but it probably lacks detail. In order to save CPU, the receiver "breaks" the bandwidth down into clusters of VFO's that are nearby each other in the spectrum. So on L Band, it could cluster the low speed data in one main VFO and the high speed channels in another. The VFO's you want to monitor need to fit inside one of these main VFO's bandwidth. So in one of your screenshots above I think I see 7 x 10500 burst channels centered around +/- 1547.025. You could put the main VFO on that frequency and with a bandwidth of 192000 (out_rate being the bandwidth basically) you can then set VFO's in the range 1546.929 - 1547.121. Keep in mind the signal tapers off a little at the edges. You can also choose 384000 as main VFO bandwidth. You may need that for the 1200 burst channels as I think those are further apart. Or you can setup 3 (or more) main VFO's and divide them that way.

You can put as many VFO's in each main VFO as you like BUT they need to be inside the bandwidth. The code tries to figure out which main VFO to use. I had a quick look at the code but do not have time to look at it further just now, but I think it will just decimate down from the full bandwidth if a VFO is outside of the bandwidth of any main VFO or even if no main VFO's exist. You can try with main VFO size = 0 if you want to find out. I can have a look later.

That bug was already there in my code that jonti merged into jaero this last summer, I had just missed it. I have a friend in Australia running C band but with a custom built jaero. So I guess nobody tried C Band with ZMQ audio on the proper jaero release until now :-)

[thebaldgeek]

Thanks so much for leaving this issue open and not closing it due to 'inactivity'... we have been working every few weeks on trying to get this going..... (So so so so so so many hours spent on .ini files ).

Working with our guy in Australia again on 143E. C-Band. Just looking at 1 VFO to try and get it to decode. We tried to change it to match your example a few posts ago.

We changed the filter to better match yours and the blue FFT Jaero wave took a dive and now looks flat like your screenshot. The Bad R/T errors are still there. Just as much as ever. Just a bit confused what the filter bandwidth and out_rate do exactly and what we should be looking for in Jaero other than less Bad R/T errors.

[jeroenbeijer]

I had been thinking to improve things a little by making the FFT tracking the signal more quickly if you will and had some changes in mind for this. But basically I have not really had time recently and since I only get 54W effectively here due to the orientation of my house versus the garden I lost motivation a little :-) 54W drops below the horizon here a few hours a day and it generally moves a lot I guess and I do not have a tracking motor or anything like that.

Anyways, you will always get Bad R/T Packets, especially on 1200 burst. Jaero detects these burst transmissions using a peak detector, it is quite neat, jonti describes it on his site. So when this peak detector detects a burst transmission jaero waits for the preamble to come through. Once it has found a preamble it knows there is an actual message coming. It collects the data and tries to decode the packet as more and more packet data comes in. In order to successfully decode the packet, the data needs to pass a checksum test. If it fails this test and it cannot decode the packet you will get this "Bad R/T" packet error. C band is much more challenging than L band, there is a significant amount of phase shift making it much harder to track the entire transmission in phase and frequency correctly. So I think unless you have a dish setup similar in size to what inmarsat uses with full tracking etc you will probably get bad packets.

I did some benchmarking with a friend in Australia before and it seemed that the SDR with jaero decoded at least as many messages as a setup with SDR Console. I have had it running on 54W and the message decoding was certainly on par with what I would expect having used SDR Console before. But having said that, the way the FFT display currently works does not make it easy for C band as it is difficult to get the frequencies set right. But if you have the exact frequencies for SDR Console you should be able to work it out.

[slongani]

Old issue, but just wanted to provide my feedback.

@thebaldgeek Not sure why you are facing problems, but SDRReceiver has been working fine for me on 10500bps burst signals. I am able to run 7 JAERO instances for the 143E, with (hopefully) decent decodes. Got ~55k messages for yesterday (22nd Jan, UTC) without tracking or GPS mod.

[thebaldgeek]

Thanks for the sanity check. I swapped out the Titanium LNB for an external 10Mhz ref norsat LNB on my 98w setup and am getting about +9db boost in signal. Truly massive over what we have been working with for years. (The Titanium we all have been using is not longer made and the new version is heavily filtered on ADSC frequencies). Still no joy after hours of SDRReceiver .ini file tweaks. Our Australian station spent many hours on his own after some training on running SDRReceiver and got some decodes from 143 as well, but nothing like what the usual SDR-Console -> VFO -> VAC -> Jaero method provides, so we can confirm what you are reporting... It works, but is very very very hard to setup.

[slongani]

I will post my ini file tomorrow, till then:

I have center frequency set as 154680000, main vfo: 1546960000 (these both are center of the sdr/band).

Now for the individual VFOs, I put the left frequency (as indicated in sdrsharp, if you are using USB). For me, the first one starts at 1546907500, and rest follow with 15KHz spacing.

I also have set the filter_bandwidth for all channels at 16000.

My JAEROs & SDRReceiver run headless, but I do monitor on a secondary PC occasionally (basically to set the offset). Works fine with very few bad R/T packets.

I tune the offset using a beacon I see at 1542177500, this is what I use to maximize the signal. The first channel is at a spacing of 4730KHz from the beacon.

Hope this helps.

[slongani]

Sorry for the (massive) delay. Forgot about this. Here is the INI:

`mix_offset=8400 disable_fft=1 sample_rate=1536000 center_frequency=1546800000 zmq_address=tcp://*:6003

tuner_gain=157

auto_start=1

[main_vfos] size=1 1\frequency=1546950000 1\out_rate=192000

[vfos] size=7

1\frequency=1546907500 1\gain=10 1\filter_bandwidth=16000 1\out_rate=48000 1\topic=VFC01

2\frequency=1546922500 2\gain=10 2\filter_bandwidth=16000 2\out_rate=48000 2\topic=VFC02

3\frequency=1546937500 3\gain=10 3\filter_bandwidth=16000 3\out_rate=48000 3\topic=VFC03

4\frequency=1546952500 4\gain=10 4\filter_bandwidth=16000 4\out_rate=48000 4\topic=VFC04

5\frequency=1546967500 5\gain=10 5\filter_bandwidth=16000 5\out_rate=48000 5\topic=VFC05

6\frequency=1546982500 6\gain=10 6\filter_bandwidth=16000 6\out_rate=48000 6\topic=VFC06

7\frequency=1546997500 7\gain=10 7\filter_bandwidth=16000 7\out_rate=48000 7\topic=VFC07 `

The mix_offset parameter now gets dynamically updated based on the center_freq provided by JAERO, so as to keep all the VFOs centered. Must be working. Up to 100k messages/day from 143E now.

[DaveNF2G]

None of the above is C-band. 1.5 GHz is L-band. The RTL SDRs are not capable of C-band reception. In fact, I don't know of any SDRs that are.

[slongani]

Downconverted, obviously. If I had been using SDR capable of 3.6GHz reception (Pluto, HackRF etc.), I would have mentioned that.

[DaveNF2G]

Not obvious, but OK. What is the main receiver? I'm still looking for C-band capability.

[slongani]

It is a LNB. 3.4-4.2GHz becomes 950-1750MHz.