Outernet in L-Band no longer available?


The one big issue we’ve got to resolve is the SNR versus how well the bare LNB works. So far, most of us have done OK with just a bare LNB, but some of us live on the EIRP fringe (or travel to the EIRP fringe like me). Ken


I can conclude that the ku band bare lnb would NOT work on a boat even when moored. The motion would be too much to maintain the alignment (even in my not so fringe satellite beam footprint).


Yes - - that’s a good assessment. The L-band worked great on small and large boats as I did run test a year ago. With the active patch’s 20 deg capture angle, I could lay the terminal on its back pointed straight up in Southern latitudes and close reliable links continuously. In Northern latitudes, centering on the satellite gave me allot of flexibility (even in rough seas) until the ship made wide turns. I don’t honestly know how to do that with the Ku-band system without some sort of pointing device like a several thousand dollar KVH TV3.

I wonder how a $104 Shakespeare Galaxy SRA-50 Sirius antenna would do? Ken


Remember SiriusXM is in the 2.32GHz… that part of the band “re-characterized” to be only available to their use a couple of years ago.


OK. L-band had it’s advantages, but it is gone for economic reasons which have been explained. Now, whether we like it or not, it’s time to move on. There is a budget here. If we are willing to hope there is a future for Outernet or any other similar service, we need to keep moving ahead with the available options.

I stand behind these guys and will help keep experimenting with whatever the next format may be!

Let’s face it. They are not trying to, and will never be the next Elon Musk! (Although I wish them the best!)


Wow! After reading my last post, I came across as an Outernet cheerleader. Honestly, I didn’t mean too. I’m just an old guy who has seen too much bullsh!t in my life and has nothing in the game! The best to everyone! Must be the rum.


SES-2 TP 9C downlinks at 3.8865 GHz which, yes is higher than Sirus. But according to Shakespeare, the SRA-50 “meets or exceeds” Sirus standards. I can’t find a frequency spec for the SRA-50, but Sirius is close to SES-2. Perhaps it worth a try by someone who might have one on hand. Ken


Oops - - Konrad pointed out the downlink frequency is much higher, so I’m wrong here. Oh well, sorry - - Ken


Another purchase required?

I am on my third outernet package purchase. Now, according to Konrad - it is no longer the beloved plug and play Outernet. I am not a tinker, hacker or programmer (neither I am guessing, is most of the developing countries where the Outernet was originally conceived for) - so what is the benefit to the world?

I just dug out my v2.03 from its faraday box to check on the outernet - no lock - due to no L band…

Sadly, I don’t want to purchase another soon-to-be obsolete platform until something is finalized and the tinkers, hackers and programmers are finished tinkering, hacking and programming.


L-Band Outernet is gone. So if you don’t have a DreamCatcher 3.02Q or 3.03 board with a Marverick MK1-PLL LNB, you need new receive hardware.

Second, Outernet is only currently broadcasting in the United States. It’s quite possible that new services will be available. We’ll have to wait for those announcements.

Correct. No L-band Outernet data broadcast.

The DreamCatcher 3.XX platform is working just fine. It does download news articles, Wikipedia articles, weather, etc. As far as I can tell, the hardware platform is not “soon-to-be obsolete” The change between the 3.02Q and 3.03 boards was extremely minor. Both of them work fine. The hardware appears to be stable.

So is Outernet still plug and play? Of course it is.

Is your TV “broken” if Netflix does not work? Of course not.

So what’s my rant about? (for the benefit of people reading this thread).

Using an Application Programming Interface (API), I’m trying to read APRS messages that come down as part of the Outernet data broadcast. APRS is a ham radio protocol that relays messages, location infomation, weather information, telemetry, etc. I’m using an external computer (Windows, Mac, Linux, Raspberry Pi, etc.) to make sense or interpret that data using a very new language called Node-RED. Node-RED on the top layer is a language that allows people to build software graphically like clicking together Legos. I have already used Node-RED to report my DreamCatcher’s status via twitter. It works like a charm.

So what’s my point?

My rant about APRS not working correctly is about a relatively small oversight – There is no timestamp data associated with a received APRS message when using the /DIRECT/getAPRS API. So if you parse through the data that’s in the DreamCatcher’s database you could run into old data and accidentally present it as current information. I have no idea if a weather station reporting heavy storm conditions is current or weeks old. I don’t know if the location sent from my Son’s vehicle in the depths of a deep Washington forest is current or from weeks ago when he was out there camping. I have no idea if the message sent to me saying “No worries - all good” is current. A time stamp is essential.

I’m trying to get the API fixed so that much more functionality can be added to Outernet by the tinkers, hackers and programmers.

Bugs and imperfections are unfortunately the nature of software and firmware. Tinkers, hackers and programmers are rarely ever finished. This is how bugs are fixed and new features are added. It’s actually a large part of my enjoyment of Outernet is being able to improve what’s there and create more functionality.

No worries, your DreamCatcher will work just fine without APRS being honed to perfection.

–Konrad, WA4OSH


Hi Konrad,
Thanks for your “rant” I found it very informative.
I too have just removed my v2 from it’s cardboard “Faraday cage”. I put the box on the shelf before even getting it up and working. I was just about to buy a v3 but as I live in Australia it obviously it’s too soon.
I’d like to put the v2 to some use so will give APRS a shot and would be grateful of any tips/links you could provide. This API you speak of. Is it publically available ? (I know nothing of APIs apart from people getting their crypto accounts hacked).
Many thanks
Mike Greenhill


I think the best bet would be to find the Armbian code for the DreamCatcher V2.0. Armbian is Debian written for an ARM processor chip. I shorted my DC 2.0 by having left it out in the rain. I believe the SDR hardware is a standard RTL-SDR. I would try to get gqrx or grc running on it. Keep in mind Raspberry Pi binaries won’t run on it. You will have to compile your own programs from source for it.

It has a 1.5 GHz SAW filter in the front end, so see what you find on the L-Band.

I’m putting together a comb generator for VHF through L-Band. I will be looking at the bandwidth of the same SAW filter on the SDRx.



I would use a Dreamcatcher 2 as a WSPR receiver.


In order to receive WSPR on a Dreamcatcher 2, you would have to

  1. Bypass the SAW Filter (or replace it with a 100 MHz one?) or both the LNA & SAW
  2. Use an up-converter like Ham It up
  3. Re-compile the WSPR software to run on ARMbian.

Can you tell us how to bypass the LNA & SAW filter on the DreamCatcher 2?



I’m still waiting on a working comb generator to arrive in my mailbox.



The LNA and SAW are on the antenna, not on Dreamcatcher.


I thought there were two types of antennas:

  1. Active
  2. Passive

The active antenna connected to the bypass connection and the passive antenna connected to an LNA/SAW input. Am I mistaken?

I thought the arrangement was the same on the SDRx.



I’m referring to specifically the bypass, which allows for non-L-band operations.


Is there bias on the bypass connector? If so how many volts? Amps? Can it be turned on and off from Armbian?

If everything is right, the bias tee may be used to power the HF up-converter.



Yes, there is. The current is only 68 mA, but it’s something. The inductor limits maximum current to 100 mA.

sudo su
cd /sys/class/gpio
echo 119 > export
cd gpio119
echo out > direction
echo 1 > value

#Bias tee control
High: enabled
Low: disabled
added since Rev1 119 (PD23 GPIO)