EMEA Region L Band Frequencies

Yeah, but it’s our own fault that they are idle tones right now. We’ll get this licked quickly.

We should look into an ARM-friendly STC-C client. I’ll put that on our list. There are just so many things on our list right now…

I am the same no files being downloaded.

Yes, the content server is broken. We’ll have this resolved tomorrow. Please check back in 24-hours.

Hello all! This is my first post to the forum!

Yesterday, I set up a PC with Lubuntu (I am newbee to Linux) and installed the outernet software following the instructions from Outernet L-band on Linux desktop — Outernet L-band for Linux 1.0a7 documentation.

The demodulator shows the message “Schedule set failure” in the bottom right rectangular frame but it seems to lock on the Alphasat Outernet signal with a reported SNR of 9-10 dB. After running for about 12 hours it reported the following:

Batch: 771604 AFEDrops: 0 Freq: NORMAL Offset: 2019.08 Hz
PhzIntg: 1 ClkIntg: -1 Rs: NORMAL Offset: 0.00 Hz
RSSI: -126.51 dBm AFE Gain: 49.60 dB AGC mult: 31219 SNR: 8.95 dB

DPDrops: -1 SER: 0
CRC Ok: 0 CRC Errs: 0 PER: -nan Invert: 0

aFreq: 2206.544 aPkmn: 26.778 SigDet: 1 State: CODE LK

I can confirm that the hardware is working fine, as it has no problem to receive AERO and marine traffic, although the signals are decoded on a windows PC.

I guess that I have the same results as g0hww.

Can anyone confirm the reception of data via Alphasat the last 24h? It would be also helpful if someone explained the meaning and significance of the abbreviated units and their values reported by the demodulator.

Hardware: RTL-SDR v.2 / Minikits EME179-1540 LNA / Home-made helical antenna.
I have yet to test the RTL-SDR v.3 as well as the Outernet patch antenna and LNA.

Greetings OM :slight_smile:
Initially I wondered why your offset ~2kHz was so much higher than my offset of ~500Hz but then I realised you were using an OEM RTL-SDR dongle an not the one from the Outernet kit.

Oops. Posted instead of pasted. The demod shows this for me …

Outernet SDR Satellite Demodulator                          Version: 1.0.4
Batch: 10884        AFEDrops: 0         Freq: NORMAL        Offset: 498.22 Hz
PhzIntg: -1         ClkIntg: 0          Rs: NORMAL          Offset: -0.14 Hz
RSSI: -100.53 dBm   AFE Gain: 42.00 dB  AGC mult: 3759      SNR:  9.97 dB

DPDrops: -1                             SER: 0
CRC Ok: 0           CRC Errs: 0         PER: -nan           Invert: 0

aFreq: 480.530      aPkmn: 23.333       SigDet: 1           State: CODE LK

Very rarely during fades I do see a non-zero Symbol Error Rate, but these transients are extremely short and the SER never goes very high, perhaps 0.0005 when the SNR dips down to 8dB or so.

I mention this only because it might be useful in terms of figuring out what is wrong, as It does mean that the SER is not ‘stuck’ at 0 for me. I assume the SER would be a NaN like the Packet Error Rate if symbols weren’t being recovered from the waveform.

Hi Darren,

Thanks for your reply!

Regarding the SER, also here the decoder shows occasionally the value of 0.0005.
Here follows the initialisation output of the decoder with some errors which I do not know how important are.

$ demod-presets euraf
sFound Rafael Micro R820T tuner
sdr100: /lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by sdr100)
sdr100: /lib/x86_64-linux-gnu/libncurses.so.5: no version information available (required by sdr100)
SDR satellite demodulator, V1.0.4 Outernet Inc.
Using: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
s[R82XX] PLL not locked!
sh: 1: cpufreq-set: not found
WARNING: Failed to set CPU clock, status = 32512
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 Hz.
Tuned to 1545940000 Hz.

and here is the demodulator’s screen

Outernet SDR Satellite Demodulator                          Version: 1.0.4
Batch: 42564        AFEDrops: 0         Freq: NORMAL        Offset: 1932.20 Hz
PhzIntg: 0          ClkIntg: 1          Rs: NORMAL          Offset:  0.04 Hz
RSSI: -125.42 dBm   AFE Gain: 49.60 dB  AGC mult: 27522     SNR: 10.30 dB

DPDrops: -1                             SER: 0
CRC Ok: 0           CRC Errs: 0         PER: -nan           Invert: 0

aFreq: 1923.433     aPkmn: 21.538       SigDet: 1           State: CODE LK

Still no packets.

I have multiple receivers setup, receiving from AlphaSat. Kit is

  1. rtlsdr v.3 and Outernet LNA + Antenna
  2. Outernet radio(E4000)/LNA/Antenna.

Heres a screen shot taken a minute back:

As I am almost on the edge of the AlphaSat footprint, my SNR tends to be between 2-5db, but packets still come down fine.

I am very surprised to see no frame lk at 9db+ SNR, though at code lk, the SNR display in the demodulator console is not very meaningful.

Could you try with a different radio?

Also - this happens to me if I bring certain electronics very close to the antenna - solar panels, power banks, RPI3(!). Try using a usb extender cable if not already.

-Ab

Thanks for the info Abhishek.

Actually, I wondered what other States existed, beyond “CODE LK”. It would be useful if there was a little more info on such matters in the documentation.

The L-Band kit receive chain seems to be working very well in fact. I have the patch directly attached to the LNA and now have a 15m length of CLF-400 coax with the RTL dongle more conveniently located near my main Linux box.

The RSSI on the Outernet signal dropped by the expected amount , given the -0.168dB/m spec for the coax at 1.5GHz, but the SNR actually increased by about 0.5dB.

I expect that modest improvement in SNR could be accounted for either by:

  • Less power in conducted emissions from the formerly co-located RTL dongle and Linux laptop computer, with about 2m of USB cable, or
  • Less radiated emissions power from the formerly co-located dongle or laptop into the patch antenna

This is what a wide band-width view of that part of the spectrum looks like in gqrx:

and a narrower view of the Outernet signal via Alphasat:

Regarding others receivers, I suppose I could try my USRP B100 with WBX daughter-board, but I would need to get a Bias-T to power the LNA and then there’s the little matter of the closed source software not supporting it.

It could feasibly be a multipath issue. The line-of-sight to Alphasat seems likely to be peering just over a neighbours roof, so it could be inter-symbol interference, I suppose. I’m not sure if the waveform in question is robust in that regard.

We have heavy rain forecast for the rest of the day today, so I’m not planning on trying anything today, but I might see if I have any more luck wandering off somewhere with the laptop and L-Band kit tomorrow to see if a clearer view of the sky helps.

Cheers,

Darren, G0HWW

Your reception looks excellent.

Yes, try another location - that could help narrow down the issue.

As far as status symbol codes go, they are (in order of functionality):

Search, Sig Det (signal detect), Code Lk, Const Lk, Frame Lk.

Frame Lk is where you should get packets. Const Lk is when the demod is able to see good BPSK constellations, but is still not able to decode them. Code Lk is when BPSK-like signal is detected in the data, but is not enough to get Const Lk.

When on anything below Const Lk, most of the values in the demod console lose a lot of their significance - obviously, as the demod cannot know if it is even looking at the right signal.

Yours definitely looks like a interference issue, cause your signal quality looks great. Please try at another location, with a clearer line of sight.

I’m also wondering if I might be getting image spurs on the Outernet signal spot.
I can contrive tuning solutions that put a strong spur right on top of the signal.

Any time that I can see signals scrolling across each other as I am tuning the receiver, I know it is a sure sign that I need to optimise my tuning solution to avoid them.

In this screen shot that’s just what I did.

Looking at the command line options for sdr100, I don’t see a way to vary the tuning solution, by which I mean varying the hardware frequency of the RTL dongle and the modem passband offset. In the absence of any means to specify a tuning solution, it might be nice if the demod software itself could run through a few alternate tuning solutions to see which give the best results.

I wonder what the actual centre frequency of the modem passband is, compared with base-band 0Hz?

Running demod-presets shows that the sample rate is 1000000Hz, which is not one of the supported sample rates in gqrx, so even if I knew the modem offset, I most probably wouldn’t be able to reproduce the tuning solution to see if any image spurs aligned with the Outernet spot anyway.

@g0hww, @SV2HWM:

Could you try OuternetInABox:

https://archive.outernet.is/images/OuternetInABox/

Make sure you read the Readme in that directory, and also the readme in the correct directory for your OS - Linux or Windows. Those have instructions for configuring the beam.

The default beam is EURAF.

Just wanted to report that I tried repositioning my antenna-and-LNA-on a stick, still with the 15m CLF400 feeder to a different position that would be unlikely to have a similar multi-path environment, still with >8dB SNR, but my experience was the same as before with v1.04 desktop linux s/w.

Next I ditched the 15m feeder and wandered around the property with a laptop and the antenna-and-LNA-and-RTL-on-a-stick with a 2m USB cable. I ensured that the laptop, dongle and USB cable was always outside the field of view of the antenna. I managed to get >8dB SNR in all spots with a decent view to 25E, but the experience with the demod was unchanged.

I’ve played around with BGAN terminals in the past, and my experience with them leads me to conclude that had I been using a BGAN terminal, the view to the satellite would have produced satisfactory results from these locations.

I’ll try the OuternetInABox ASAP.

Its a fairly quick try and doesn’t interfere with the rest of your system. Let me know how it goes.

Don’t change anything else on your setup until you try OuternetInABox. Theres a good chance your setup is fine.

Aaaaah! The OuternetInABox works for me :slight_smile:

I guess that there are issues with the desktop linux solution!

Yes!! Yay!!

Watch for the files!

It might take a short while before one shows up - if you start receiving in the middle of a file, nothing happens until transmission of next file starts.

I am hoping @SV2HWM gives it a shot too.

Please keep us posted!

The qemu package I needed on Ubuntu 14.04.4 LTS was qemu-system-x86 and its dependencies, BTW.

Ok, thanks for letting me know. On Mint, the package qemu-system-i386 provides the minimum that is needed, but seems ubuntu only provides the complete x86 + x64 package in one.

Interestingly, with the qemu stuff, I’m seeing frequent downward SNR excursions from the nominal 9dB down to as low as 0dB occasionally but more often to about 3 or 4dB, with state transitions as appropriate.

I never saw that much variation in SNR with the suspect desktop s/w. The constellations still look quite similar in their spread to the desktop s/w.

I suspect that the SNR fluctuations are related to the fact that the LOS to Alphasat is only about 10 degrees in azimuth to the view up the road that I live on, so I think there’s a fair chance I’m getting multipath fades due to road traffic. The PER is about 1%. I’ll see if the fast fading calms down later on.