LoRA is super cool! We've been following FossaSat with great interest and were very fortunate to have an opportunity to hear Julian Fernandez present about the project in person.
We have several options for supporting modes other than our "native" 4-ary minimum shift keying uplink. We anticipate channels about 100kHz wide. More bandwidth needed, you bond them together. If you want, for example, a number of narrowband modes supported within that channel, then each channel can be treated like a band that can be subdivided into subchannels.
If we approach this like it's a subdivided band, traffic needs to be recognized and properly transmitted through the system.
The set of technologies for that on Phase 4 Ground is called "ARAP" or amateur radio access point. The number of modes recognized depends on how ambitious we get with the number and type of signals recognized, and that depends on how much horsepower we have in the payload receiver. The basic requirement is to support FM HTs and P25 radios. We want to digitize and then tag these signals as legacy FM traffic and pass them through the system.
We have demonstrated this type of approach at Symposium in the past, where traditional HT traffic is digitized, turned into tagged CODEC2 frames, and then the multiple HT traffic is combined and repeated as a single digital signal. The receiver selects one of the channels present in the composite signal. You're not necessarily limited to selecting only one channel. If you want a conference, then multiple channels would be selected. This leads right to a need for a good user interface.
Being able to recognize, digitize, and include a variety of signal types? Sounds awesome to me! To mean it means we need to take on autonomous signal identification, see what machine learning can do for us, and all sorts of other really neat stuff that is in the domain of cognitive radio. We have a solid beginning here and some working code. There's an excellent implementation of modulation type recovery using machine learning that we expect to rely upon. Books like Signal Analysis for Radio Monitoring by Roland Proesch and the Autonomous Receiver book from JPL provide a lot of leverage here too!
The most important question to me is "What would you like to see the end result do?" When you think about a successful LoRA integration, what does that look like?
-Michelle W5NYV
On Sat, May 11, 2019 at 9:30 AM Pedro Converso pconver@gmail.com wrote:
Hello Michelle,
Impresive information, thanks! for sharing.
Do you know if some decoder is or will be implemented for LoRa ?.
This due the growing activity, future satellites on LoRa & Balloon usage of LoRa.
Thanks in advance,
73, LU7ABF, Pedro
On 5/11/19, Michelle Thompson via AMSAT-BB amsat-bb@amsat.org wrote:
My daughter Geneva and I had a wonderful time at JAMSAT Symposium in
March
2019! There was a wide variety of talks about so many different
payloads, a
very special banquet dinner, adventures in Kyoto and Osaka, visits to ham radio stores, getting to see a new ICOM radio up close, lots of Pokemon,
a
Fire Festival, and making so many new friends. We were welcomed and will never forget the hospitality.
A big part of Symposium was the GNU Radio Workshop by Imamura-san. It was an honor to share how we on Phase 4 Ground use GNU Radio in our presentation on Sunday morning.
GNU Radio is a digital signal processing framework for software-defined radio. It’s the software that tells the hardware in your radio what to
do.
We need to be able to quickly and easily set up a software-defined radio
to
do whatever modulation and coding we want during development of new payloads and new ground stations. In many cases, GNU Radio is the exact right tool for this job.
GNU Radio Companion is a Graphical User Interface that allows us to drag and drop functions onto a canvas. We click block outputs to connect to block inputs. When we do this, it creates a directed graph that
implements
radio functions. The signals flow from beginning to end. Each block modifies the signal, as if it was part of a circuit. The flow graph looks something like a block diagram combined with a software flowchart. GNU Radio has software variables. It can adapt to signal conditions and user input.
The workshop at JAMSAT was held after the last talk on Sunday. It was several hours of hands-on training. Participants brought their own computers, installed GNU Radio, and created useful radio flow graphs that worked with real hardware. Several experiments were done in order. Imamura-san kept everything organized through a set of projected slides that had clear instructions. Optimizations and customizations were made
so
that participants could see how they can use GNU Radio to achieve their goals. The hardware included RTL-SDRs and Plutos. Imamura-san also demonstrated a live video transmission from the podium.
Something that I noticed in the workshop was how much easier it would be
if
this community could use the software if it was in Japanese. I decided to see what was required. After some homework and reading, I got a very
simple
example working and understood the basic workflow. I asked JAMSAT if they were interested in a localized version of GNU Radio Companion. JAMSAT responded positively and work began in earnest! It started to become
clear
that after this initial groundwork, that additional languages would be
much
easier. I reached out to AMSAT-DL next, and got an enthusiastic response there too. As of today, both German and Japanese are in progress! I received an inquiry about Portuguese following the initial announcement that the main menus had successful translations in testing. It's now on
the
list after we fully test localization for German and Japanese.
While at JAMSAT, I was able to give a status update for Phase 4 Ground.
Phase 4 Ground is a broadband digital microwave system for both
terrestrial
and space use. It complies with both ITAR and EAR open source and public domain carve-outs, so it’s open to participation worldwide. All
engineering
is published as it’s created. All are welcome to participate.
Phase 4 Ground is best suited for GEO and HEO satellite missions. The uplink is frequency division multiple access. We use a 5GHz uplink. The regenerative repeater payload receives the uplink signals, digitizes
them,
multiplexes them, and processes them into DVB-S2 and DVB-S2X frames. The downlink is 10GHz. DVB-S2 is Digital Video Broadcasting Satellite 2nd edition. The X stands for extensions down in to Very Low SNR modulation
and
codings. Very Low SNR is of interest to hams, so we include the extension to the main standard DVB-S2.
We use both pilots and short frame lengths in order to make the receiver implementation as easy as possible. Pilot tones are optional, and there
are
medium and long frames available in the standard.
There is a recommended order to receive DVB-S2/X frames. The first stage
of
the demodulator is symbol timing recovery. We have to figure out the best possible time to measure, or take a snapshot, of the received signal. The receiver does not know the phase of the transmitter clock. We will not be automatically coordinated with it. It's not just a problem with phase, either. The receiver and transmitter may disagree in terms of the period
of
the clocks, or we might have jitter, or we might have drift. We have to analyze the received waveform and synchronize our receiver clock to the transmitter clock that is “hidden” in the received signal. Then, once we are synchronized, we sample that symbol and report the results.
Doing this gives us a reliable value for the received symbol. Now that we have a series of received symbols, we have to figure out the start of the frame. This is done in DVB-S2 (and many other protocols) by sending a
fixed
pattern at the start of every frame. For DVB-S2, this is called a
Physical
Layer Start of Frame sequence. It’s 26 symbols long. This is what we look for. Once we see it, we know where the start of the frame is!
Frame synchronization can be done in several ways. There are two
different
methods described in the implementation guidelines for DVB-S2/X. One is relatively simple, using shift registers. The other is bit more complex, using state machines. There are advantages to using the state machine method, but it’s more complicated and expensive. The shift registers is simple and cheap, but gives up a bit of performance. This is the constant balance in digital communications. Performance comes at a cost!
Right after frame synchronization, we correct for carrier frequency
error.
First we do a coarse correction. This can be done with a
delay-and-multiply
frequency error detector. Then we do a fine correction. This can be done with something like a feed-forward estimation algorithm. Coarse
correction
is in the MHz, and fine correction is the hundreds of kHz.
Next, we do phase recovery. This is to fix any residual frequency offset from the coarse and fine frequency offsets. Phase 4 Ground will support
all
the modulation and codings of DVB-S2/X, but we expect lower order modulations to be more heavily used. This means that a pilot-assisted maximum-likelihood (ML) feed-forward estimator will be the most useful.
If
you compute the average phase of each pilot field, then you can subtract this out and improve the signal. Higher-order modulations will need
another
feedback loop.
Automatic gain control is next. AGC can be done in many ways. One way to
do
it depends on the pilot symbols in DVB-S2/X standard. These symbols are sent at regular intervals to provide a known easy-to-receive signal. We
use
these known pilot symbols in order to determine the amplitude multiplication factor for the rest of the signal. Pilot symbols are optional in the DVB standard, but Phase 4 Ground requires them. When the pilot symbols are on, the AGC is listening. When the pilot symbols are
off,
the AGC turns off, and the information from the AGC is used.
After AGC, the constellation is decoded. DVB-S2 has a lot of them! There are many techniques to get the bits from the constellations. GNU Radio
has
a very versatile and powerful constellation block. Instead of the usual MPEG transport stream (DVB-S2 is for satellite TV,
so
the content is usually broadcast television signals), we use the more flexible Generic Stream Encapsulation standard from DVB.org. This means
we
have less overhead and complexity, and can handle any digital traffic
that
the amateur operator wants to transmit. It’s just a digital pipe.
Phase 4 Ground uses GNU Radio extensively in research and development as well as for archiving and publishing our work. GNU Radio is not just a
tool
to figure things out, but is also a way to define a reference design for the radio.
Because Phase 4 Ground is not a bent pipe, the payload is more complex. This complexity needs to be fully tested on the ground before risking
large
digital circuits in space.
All the uplink channels are received with a polyphase filter bank. The current polyphase filter bank implementation in GNU Radio needs some updates in order to achieve the speeds and performance that we want. This is an active area of research and development. There have been three efforts over the past three years by various groups that have attempted
to
update and improve the existing working polyphase filter bank in GNU
Radio.
There is some recent good news here! EJ Kreinar reported that his open project (Theseus Cores) has an open source FPGA polyphase channelizer!
This
works with RFNoC. We will experiment with this in our payload design.
This
could fill in a big piece of the system that we need. Check it out here: http://gitlab.com/theseus-cores/theseus-cores
Ron Economos and Paul Williamson successfully implemented GSE in GNU
Radio
and in Wireshark. This made it possible to do transport layer testing.
Ron
Economos is the lead author of the DVB blocks in GNU Radio. Improvements
to
GSE continue today. The current focus is improving internetworking functions so that large amounts of data can be more easily handled. We intend to use multicast IP as much as possible, and making sure GSE integrates well with multicast IP is important. The path forward with
that
is in our test plan. You can find our test plan here:
https://github.com/phase4ground/documents/blob/master/Papers_Articles_Presen...
The error correction in DVB-S2/X is state of the art. There are not many other error correcting codes that are better than Low Density Parity
Check
- BCH. This is a concatenated digital code specified by the DVB standard
for S2 and T2 transmissions. We have two open source implementations of LDPC decode for DVB-S2/X. The first one is for graphical processing units and was written by Charles Brain. It was demonstrated at 2017 AMSAT-NA Symposium and at several events following.
The second open source implementation is in C by Ahmet Inan and can be found here: https://github.com/xdsopl/LDPC This version has been incorporated into GNU Radio by Ron Economos. This
can
be found here: https://github.com/drmpeg/gr-dvbs2rx
The next step for LDPC is to implement and publish an open source version for FPGA.
GNU Radio is very important for our voice codec work, uplink modulation experiments, and trying out authentication and authorization schemes. GNU Radio allows us to use a wide variety of off the shelf hardware to
achieve
things that were not possible only a few short years ago. The GNU Radio community has been welcoming, helpful, supportive, friendly, and a source of continually amazing software-defined radio advancements.
GNU Radio has an annual conference. In 2018, we held a week-long “Block Party” for DVB-S2/X. We had fun, set up multiple demos, explained
DVB-S2/X,
made the case for open source LDPC, and made progress on DVB-S2
correlates
and GSE. Phase 4 Ground made significant progress due to the generous support of the conference organizers and the community.
Learn more about the conference here: https://www.gnuradio.org/grcon/grcon19/
Registration for 2019 is open. The conference will be held September
16-20,
2019 in Huntsville, AL, USA. There is a poster session, proceedings,
talks,
workshops, contests, and social activities. The theme for 2019 is Space Communications! There are special gifts for space themed content. If you have a GNU Radio project that you want to share, consider making a presentation at or sending a poster to GNU Radio Conference 2019.
The collaboration between Phase 4 Ground and JAMSAT has been absolutely stellar and we all look forward to continued enjoyment and success. Next generation payloads will be more complicated with multiplexing and
advanced
digital techniques. We all need to be able to work together, internationally. Open source and public domain is the best way forward. Phase 4 Ground and Open Research Institute are entirely dedicated to
making
this happen. We will be keeping the momentum and progress going. ORI is proud to be an affiliate member of Open Source Initiative https://opensource.org/
Join the Phase 4 Ground team! Our work benefits all AMSAT organizations. Our mailing list can be found at our website
https://openresearch.institute/
Write me at w5nyv@arrl.net if you want to join our Slack account. This
is
where daily engineering discussions take place.
More soon! -W5NYV _______________________________________________ Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership.
Opinions
expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite
program!
Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb