►
Description
Paul KB5MU walks through the process of setting up a Remote Lab test using the AYECKA SR-1 DVB-S2 + GSE receiver to receive a DVB-S2 + GSE signal generated by GNU Radio with the gr-dvbgse module. A quick look at most of the setup menus of the SR-1. Complete installation of GNU Radio 3.9 on a fresh Ubuntu 20.04.4 LTS virtual machine.
ORI Remote Lab documents:
https://github.com/phase4ground/documents/tree/master/Remote_Labs
GNU Radio:
https://www.gnuradio.org
gr-dvbgse module from drmpeg, Ron Economos, W6RZ:
https://github.com/drmpeg/gr-dvbgse
Open Research Institute:
https://openresearch.institute
A
A
A
A
A
A
A
A
A
There's
a
couple
of
different
channels
of
configuration
again
we're
going
to
use
just
channel
one
which
has
this
configuration
set
for
1280
megahertz,
which
is
just
an
arbitrary
number,
but
it's
in
the
handban
and
dvbs2
and
notice
down
here
near
the
middle
there's.
Generic
stream
encapsulations
turned
on
now.
Zero
always
gets
you
back
out
of
these
menus,
so
hit
zero
a
couple
of
times
to
get
back
to
the
main
menu.
A
Let's
take
a
look
at
the
current
status
and
we're
only
interested
in
channel
one,
so
I'm
going
to
hit
one
to
get
into
that
and
here's
the
current
status.
It's
not
locked,
so
there's
no
signal
currently
we're
going
to
generate
a
signal
to
allow
it
to
receive
anything
and
hitting
zero
to
get
back
out
again.
A
Let's
look
at
the
network
setup.
The
management
port
is
connected
to
this
ip
address.
You
see
here
at
the
top
1073
111,
that's
just
the
network
address
in
the
remote
labs
private
lan,
looking
down
a
little
further.
The
lan
ip
address
is
for
the
traffic
port
and
it
is
set
up
with
an
ip
address
in
the
ham,
radio
net
44
block
44.0.1.100.
A
A
A
Okay,
that's
all
we
need
from
this
screen.
Let's
just
look
on
the
system
screen
briefly,
you
can
see
there's
resets
and
and
various
kinds
of
information
here.
None
of
it,
I
think,
is
relevant
to
this
experiment
and
five
gets
me
statistics
again,
I'm
only
interested
in
number
one
notice.
It's
all
zeros,
there's
nothing
coming
in
right
now.
In
order
to
get
these
numbers
to
change
from
zero,
we
have
to
send
some
data
through
and
before
we
can
do
that.
We
have
to
establish
a
dbb
s2
signal
so
going
back
to
the
main
display.
A
Now
we
need
to
generate
a
signal
and,
as
I
mentioned,
we're
going
to
try
to
use
gnu
radio
to
do
that.
This
is
a
brand
new
vm,
that's
completely
from
scratch.
I've
got
an
ubuntu
install
provided
by
the
lab
manager.
That's
me
but
never
mind
that
and
we're
going
to
install
a
new
radio
from
scratch
and
bring
it
all
the
way
up
to
transmitting
signals
that
can
be
received
by
the
sr1.
A
So,
let's
start
with
a
new
window,
make
it
a
little
bit
bigger.
We
also
need
some
instructions,
so
let's
go
to
the
web
and
take
a
look
at
the
installing
guinea
radio
web
page.
I
just
typed
in
install
gnu
radio
into
google,
and
this
is
the
first
thing
that
came
up.
This
is
from
the
guinea
radio
website
and
the
box
across
the
top.
That
says,
linux
is
exactly
the
instructions
we
need.
A
A
A
A
So
let's
go
back
to
the
web
browser
and
bring
up
this
page.
It's
on
github
github.com,
slash
dr
mpeg
slash,
gr,
dvb
gse,
so
it's
a
new
radio
package
for
dvb
generic
stream
encapsulation
and
all
the
source
code
is
here
for
you
to
study
and
modify
and
do
whatever
you
want
with
I'm
going
to
scroll
down
through
this
extensive
readme,
it
describes
setting
up
the
test
scenario
we're
going
to
use.
A
A
A
A
A
A
A
Install
prefix
all
caps
and
it's
slash
user
by
default.
It
would
be
slash
users,
that's
local
and
that
doesn't
match
how
gnu
radio
gets
installed.
The
way
we
installed
it.
So,
with
this
define
on
the
command
line,
it'll
match
and
then
dot
dot,
slash
tells
it
where
to
find
its
cmake
config
file
so
hit
that
oh,
we
don't
have
cmake
either
so
apt,
install
cmake.
A
A
A
A
A
The
vnc
server
should
have
been
installed
with
the
fresh
vm,
let's
find
out
the
nc
server
dash
list.
Okay,
it's
there.
In
fact,
there's
one
already
open
I'm
going
to
go
ahead
and
kill
that
one,
because
that's
from
some
previous
testing
so
kill
colon,
two
all
right
and
then
list
again
now,
there's
none
and
I'm
gonna
start
one
of
my
own
pnc
server
local
host.
A
A
59.06
because
I
use
6
on
this
computer,
I'm
not
worried
that
it's
not
encrypted
because
we're
already
working
over
an
encrypted
lan
and
I
enter
the
password
that
I
set
up
and
here's
my
graphic
user
interface
to
nuts.
Don't
worry
about
the
colors
being
wrong!
They'll
fix
themselves
here
in
a
second
there
we
go
and
I'm
just
going
to
open
a
terminal.
A
A
A
If
you
look
in
the
upper
left
hand,
corner
you'll
see
a
box
called
ipacketsource
that
grabs
packets
off
of
the
local
network,
configuration
I'll
talk
about
that
in
a
second
and
creates
baseband
frames
in
the
dbb
s2
format,
and
then
it
passes
through
all
these
boxes.
The
bb
scrambler,
the
bch
encoder,
the
ldpc
encoder,
the
interleaver,
the
modulator
physical
air,
framer
and
a
final
filter
and
then
goes
out
to
two
destinations.
A
A
I
wonder
if
we're
ready
to
run
it,
let's
push,
go
and
see
what
happens.
The
first
thing
you
get
is
this
warning.
This
is
always
happens
when
you
run
a
radio
for
the
first
time
unless
you
configure
the
x
term,
we
don't
care
about
that.
So
I'm
just
going
to
click,
ok
and
look
down
here
in
the
bottom
left.
That's
where
the
messages
are
I'll,
make
a
little
more
room
for
them
got
some
errors.
A
A
A
A
A
A
A
A
A
A
This
is
a
work
around
for
a
permissions
problem
in
linux,
and
normally
ordinary
user
programs
would
not
be
able
to
capture
packets.
Out
of
the
networking
stack
at
all,
you
can
run
your
program
under
sudo,
so
it
has
root
access
and
then
it
would
be
able
to,
but
it
would
also
be
able
to
do
all
sorts
of
things
that
you'd
rather
not
allow
it
to
do
so.
A
Instead,
you
can
find
a
program,
the
program
you're,
going
to
run
and
give
it
special
permissions
to
do
the
networking
thing,
because
the
program
we're
running
is
actually
a
python
program.
We
have
to
assign
the
privileges
to
python.
That's
a
security
problem.
You
wouldn't
want
to
do
this
on
a
public
machine,
but
we're
in
a
vm
behind
log
in
on
private
lan,
and
I
think
it's
probably
safe
enough,
so
we're
going
to
copy
this
instruction,
go
back
to
our
terminal
and
paste
it
in
and
get
errors.
A
A
This
block
of
five
instructions
creates
a
fake
network
interface,
almost
like
an
ethernet
card
in
your
computer,
but
entirely
imaginary.
In
software
this
will
be
the
destination
to
which
we
write
packets
that
need
to
go
out
through
our
guinea
radio
based
transmitter
now
we'll
simply
write
them
to
this
fake
interface
and
the
packet
snooping
that
we
talked
about
before
will
intercept
them
as
they
go
to
that
interface
and
send
them
out
over
the
air
instead
cool.
A
A
That's
where
we're
going
to
want
to
listen
for
packets,
coming
out
of
the
sr1
that
have
gone
over
the
air
been
received
and
come
back
out.
Remember
the
sr1
puts
those
out
to
the
lan
router
address,
so
we
need
to
ensure
that
this
monitor
port.
The
enx
port
has
the
right
ip
address
to
accept
those
packets.
A
A
A
A
This
is
expected.
The
problem
is
that
that
when
I
answered
yes,
that
I
want
everybody
to
be
able
to
capture
packets,
everybody
doesn't
really
mean
everybody
to.
In
order
to
be
able
to
have
permission
to
capture
packets.
I
need
to
be
a
member
of
the
group
called
wireshark,
so
I
have
to
add
myself
to
that
group.
A
Sudo
user,
mod,
a
capital
g,
the
group
name
wireshark
and
my
username
kb5mu
okay,
and
to
confirm
that,
let
me
type
groups
which
just
lists
the
groups
that
I'm
currently
in
and
you'll
see
that
wireshark
is
not
in
there.
Unfortunately,
the
group's
setting
doesn't
take
effect
until
you
log
out
and
log
back
in
so
I'm
going
to
do
that
now.
A
Now
it's
capturing
on
that
interface
and
if
we
wait
a
few
seconds
we'll
see
if
there's
any
traffic,
there
might
not
be
any
here's
some.
This
is
a
message
from
the
ieca
device
from
the
sr1
to
a
broadcast
address.
It's
an
arp
query:
it's
looking
to
find
out
who
has
that
address
440199,
which
is
the
router
address,
and
it
wants
the
answer
sent
back
to
itself
at
44,
0,
1
100.
A
A
A
A
A
Okay,
let's
look
again
now
it
has
the
internet
address
that
we
specified
and
one
of
the
other
commands
we
gave
must
have
cleared
that
out.
Somehow,
so,
let's
try
tshark
again
and
see
what
we
see
now.
Okay,
this
is
better.
Now
we
see
the
arp
request
same
as
before,
but
now
we're
seeing
an
answer
and
other
stuff
starts
to
happen.
There's
some
background
traffic
going
on
in
this
network,
the
usual
overhead
stuff
of
computers
trying
to
talk
to
each
other,
but
no
actual
traffic.
A
A
A
A
A
A
A
A
There's
some
trickery
involved
to
make
that
happen.
If
we
send
a
ping
packet
to
a
particular
address,
44001
or
44002,
I
guess
normally
it
would
go
out
over
the
air
and
something
on
the
far
side
of
the
world
might
respond
to
it,
but
we
don't
have
any
far
side
of
the
world.
Instead,
we
have
some
fakery
faker
in
the
new
radio
flow
graph.
A
A
A
A
Look
at
the
air.
We
got
a
response.
This
is
a
known
bug.
It
eats
the
first
packet
or
two,
but
now
that
we've
got
a
packet,
that's
come
out
and
it's
been
echoed
back
a
successful
ping
and
if
we
set
that
up
to
run
infinitely
just
turn
off
the
count
restriction.
So
it's
pinging
once
a
second
and
then
look
over
here
at
the
statistics.
We'll
see
a
data
rate
of
about
704
bits
per
second
from
these
small
packets
going
by
once
per
second,
not
bad.
A
You
can
see
it
counting
up
and
not
missing
any
frames
and
doing
doing
quite
well.
So
now
we
have
reached
the
second
level
of
success.
We've
actually
transmitted
some
data
over
dbvs,
2,
gsc,
properly
encapsulated
received
it
with
the
sr1
gotten
the
data
out
of
the
sr1
into
the
computer
and
processed
it
and
generated
a
fake
response.
A
A
To
the
same
address
as
before,
and
when
I
do
that
it's
going
to
flood
the
channel
with
with
a
bunch
of
data
and
we'll
be
able
to
see
it
in
our
statistics,
so
bang,
oh
there's,
a
restriction
here
too
ping
has
because
it
can
generate
lots
of
data
is
restricted
in
order
to
use
it
with
such
a
short
interval.
I
have
to
be
root,
so
I
just
have
to
add
sudo
to
the
front
of
that.
So
bang
now
we're
generating
lots
of
data
and
what
did
that
do?
Look
all
of
a
sudden.
A
A
A
10
000
bytes
per
ping,
so
one
thing
we
see
right
away
is
that
we
don't
get
responses,
there's
some
kind
of
a
problem
in
the
fragmentation
once
the
packets
get
bigger
than
about
a
thousand
bytes,
they
have
to
be
broken
up
into
lots
of
little
packets
and
that's
not
apparently
not
quite
being
done
right.
So
ping
is
not
believing
the
responses,
but
it's
still
generating
all
that
data.
It's
still
going
over
the
air
and
look
look
at
this
right
here
now
we
have
eight
million
bits
per
second
going
over
this
link.
A
No
bad
fragmentation,
crcs,
it's
just
solid
at
eight
megabits
per
second
and
we
could
go
back
into
the
flow
graph
and
change
some
of
the
parameters
to
get
even
more
so
we're
using
about
six
megahertz
of
bandwidth.
Transmitting
eight
megabits
per
second
successfully,
with
just
a
solid
data
link
over
ddb
s2
from
gnu
radio,
confirmed
by
the
commercial
hardware,
the
ayeka
sr1,
and
that
is
what
we
intended
to
achieve
today.
A
I
think
we
learned
a
little
bit
about
all
the
ins
and
outs
and
hopefully
we're
more
familiar
with
the
sr1.
As
a
piece
of
test
equipment,
so
when
it's
time
to
test
against
our
own
implementation
of
fpga
or
whatever
we
got,
will
have
a
solid
test
bench
to
test
against
and
a
reference
to
compare
against.