►
From YouTube: 20210521 "Office Hours" M17 Integration
Description
Initial discussion about M17 Integration into P4DX uplink with members of both teams.
A
Thank
you,
everybody
for
coming,
and
I
will
seed
the
floor
to
to
to
you
all
to
do
introductions
and
to
talk
about
the
protocol
and
how
to
properly
integrate
it
for
space.
What
we
need
to
do
what
we
can
get
away
with
you
know
and
and
all
that,
so
why
don't
you
introduce
yourself
steve
to
the
people
that
don't
don't
know
you.
B
B
B
I've
got
a
couple
of
hams
up
here
that
I'm
that
I'm
working
with
as
well.
I'm
learning
a
whole
lot,
a
lot
of
stuff
from
everybody
and
I'm
really
looking
forward
to
taking
this
project
a
whole
lot
further.
So,
that's
that's
who
I
am,
and
you
know
hopefully
I'll,
stick
around
or
hopefully
they'll
keep
me
around
for
longer.
So
I'm
trying
to
earn
my
keep
as
as
much
as
possible.
Fantastic.
C
I
kind
of
first
got
involved
with
the
intersection
of
ham,
radio
and
software
with
the
md
380
tools
project,
where
I
wrote
the
linux
version,
the
python
version
of
the
firmware
upload
functionality
and
I
flushed
out
the
trip
driver
and
got
it
working,
but
I
never
actually
closed
that
anywhere
because
it
was
very
hacky.
Chirp
was
only
serial
capable.
C
D
All
right,
hi
guys,
I'm
rob
wx
9-0,
I'm
a
software
engineer
by
trade
and
started
cam
radio
started
in
jam.
Radio
about
2012
and
I've
started
mobile,
linked
after
playing
around
with
some
electronic
stuff
and
and
designing
parts
for
my
for
my
own
use
and
showing
them
off
and
people
asking
for
them.
So
it
was
kind
of
an
accident
that
I
started
the
firm,
but
it's
been
very
successful.
I.
C
D
D
C
E
So
I'm
again
a
software
and
a
hardware
engineer
by
profession,
mostly
into
linux,
kernel
and
embedded
development
with
ori
I
contributed
to
ldbc
encoder.
I
am.
There
is
a
contributing
for
fcc
regulations
regarding
debris
mitigation
and
now
I'm
working
on
this
transponder
transmitter
part
to
be
specific.
That's
that's
what
we
are
here.
I
want
to
understand
how
we
are
going
to
get
the
uplink
packet,
so
I
am
17
and
and
then
I
have
a
gsc
block
in
the
fpga
that
will
do
the
encapsulation,
so
we
will
discuss
that
in
detail.
E
D
A
Same
here-
and
I
am
michelle
thompson,
w5
nyb
and
I'm
a
co-founder
and
ceo
current
ceo
of
open
research
institute
and
my
primary
job-
is
to
provide
resources
and
remove
roadblocks,
and
my
background
is
in
information
theory
or
icky
math,
which
is
forward
error,
correction,
cryptography
compression
things
like
that.
I
firmly
believe
in
getting
stuff
working
over
the
air
if
it
doesn't
work
over
the
air,
it
doesn't
work,
and
that
is
the
source
of
great
joy
and
great
frustration
and
all
sorts
of
crazy
experiences
in
getting
hardware
to
work
in
the
lab.
A
A
E
A
I'm
sure
yeah,
we
should
probably
explain
what
we
mean
by
gse.
It's
the
generic
stream
encapsulation
protocol
from
digital
video
broadcasting.
So
what
it
does
is
replaces
it's
a
drop-in
replacement
for
mpeg-2
in
dvb-s2
and
s2x
t2
t2,
all
of
those.
So
when
we
say
gse,
that's
the
gse
we're
referring
to
generic
stream
encapsulation.
A
Yes,
this
is
an
overloaded
acronym,
as
a
lot
of
the
three
water
ones
are
so
yeah
onshul
is
is
taking
that
open
protocol,
and
these
we
with
what
we
use
is
our
transport
stream
and
so
we're
looking
at
okay,
we
want
to
ship
m17
in
an
efficient
manner
and
what
what
sort
of
what
changes
do
we
anticipate
there's
the
changes
that
onchil
is
talking
about,
which
are
protocol,
specific
sorts
of
things?
What
do
we
need
to
do
there?
A
E
Yeah
so
at
broad
level,
that's
what
how
how
we
can
carry
out
demodulation
deco
decoding
of
m17
frames
and
what
will
be
the
changes
required
at
the
protocol
layer?
How
we
can,
how
I
can
use
m17
protocols,
not
protocols
the
frame
fields
and
translate
into
ip
fields,
because
I
need
to
decode
and
get
the
data
ip
data
out
of
it
like
ethernet,
mac
address
and
payload
and
everything.
And
then
in
put
my
gsc
layer.
On
top
of
that.
C
Okay,
so
that
would
be
pretty
low
bandwidth.
I
mean
we're
we're
4
800
baud,
the
we
have
what
3200
bits
of
payload
on
voice
streams.
We
can
probably
equal
a
little
bit
more
out
of
that
for
packet
formats.
So
are
you?
Are
you
imagining
something
really
wide
bandwidth
or
are
we
just
doing
really
slow
speed
ip.
A
Yeah,
I
can
help
a
little
bit
here.
The
the
the
baseline
uplink
channel
width
for
for
us
is
around
about
100
kilohertz,
and
that's
so
about
about
100
users
about
100
kilohertz
it.
This
is
channelized
in
frequency.
So
what
you're
speaking
to
is
a
big
channelizer
in
the
sky
or
or
on
on
a
mountain
top?
A
So
so
that's
our
baseline.
What
we
would
really
like
to
do
is
allow
m17
protocol
to
simply
work
to
be
the
native
digital
protocol.
This
channel
can
be
digitized
and
the
entire
thing
transported
downstream.
We
like
to
privilege
things
like
m17
that
we
recognize
what
it
is
and
use
it.
So
there's
plenty
of
room
to
grow
in
the
uplink.
You
know
in
in
terms
of
like
a
limit
on
the
baud
rate.
A
A
It
doesn't
just
mean
that,
like
you,
just
change
everything
you
know
just
because
you
have
the
the
space,
so
so
one
of
the
one
of
the
things
that's
very
important
to
figure
out
from
both
the
protocol
and
implementation
point
of
view
is
like
here
you
go,
there's
a
bunch
of
freedom.
Is
it?
Is
it
good
to
to
go
ahead
and
use
that
or
do
you
want
to
really
preserve
this?
This?
C
A
A
C
A
C
B
Okay,
that
that
does
bring
me
back
a
couple
of
years.
I
white
check
and
I
used
to
kind
of
joke
about
this,
but
there
is
the
idea
and
the
desire
to
have
a
satellite
mode.
I
think
that's
part
of
the
reason
that
he
was
so
driven
to
get
onto
the
kio100
satellite.
It
was
to
test
it
out,
see
if
we
can
shoot
it
up
to
the
sky
and
hear
something
back,
but
I
do
believe
that
we
should,
you
know,
take
a
look
at
it
as
a
wider
band.
B
You
know
protocol
so
that
we
can.
We
can
shove
more
data
into
it.
We
can
shove
a
higher
bit
rate
codec,
which
a
number
of
people
in
the
chat
are
are
pushing
for
you
know,
so
I
think
yeah
this.
The
this
discussion
with
adding
a
wideband
mode
for
for
m17
kind
of
you
know
brings
me
back
to
that
original.
You
know
discussion
that
we
had
a
few
years
a
couple
years
ago.
You
know.
C
And
to
just
expand
on
that
a
tiny
bit
in
a
completely
different
direction.
I
don't
know
why
I
said
expand
to
answer
anshul's
topic,
which
was
where
can
we
put
ip
fields?
Mac
addresses
all
the
the
various
things
you
would
need
for
an
ip
uplink.
I
think
we're
going
to
have
to
have
a
specific
mode
to
m17,
specifically
to
design
for
that,
because
we
have
16
bytes
of
payload
on
voice
streams
and
with
the
existing
baseband
protocol
that
we
have
on
rf
right
now.
D
Well,
there
is
a
there
is
a
packet
mode
to
for
m17
that
would
that
might
be
able
to
handle
some
of
that
it
might
be
less
efficient.
We
could
just
if
we're.
If
we
are
going
to
do
ip,
we
we
can
just
use
the
six
pipe
that
we
have
for
the
the
sender
and
receiver,
as
you
know,
just
to
plop
in
a
mac
address
in
there
right.
Those
are
six
bytes
and
that
would
work.
D
F
C
D
D
The
other
option
that
we
have,
if
we're
talking
about
going
and
essentially
expanding
m17,
to
be
able
to
work
across
a
100k
bandwidth,
then
we
need
to
decide.
Do
we
make
you
know?
How
do
we
do
it?
We
go
about
doing
that
right.
Are
we
we
going
to
expand
the
the
size
of
the
the
packets?
Are
we
going
to
pack
more
packets
in
each
packet?
Has
some
overhead
right?
So
all
these
things
need
to
be
discussed
and
to
figure
out
what
makes
sense.
A
Yeah,
I
can
talk
a
little
bit
about
that.
Our
baseline
modulation
for
the
uplink
has
been
four
area:
minimum
shift,
keying
or
minimum
frequency
shift
keying
for
a
while.
I
mean
because
of
the
benefits
that
you
have
for
for
amplifiers
and
and
such
and
that
made
all
the
rf
people
happy.
So
that's
not
really
far
away
from.
D
A
A
D
E
So
michelle-
and
here
we
are
talking
about
some-
is
it
some
major
changes
because
from
where
I'm
coming
is
michelle?
We
have
a
demo
in
august
and
I
want
to
demo
complete
transmitter
with
m17
uplink
and
then
I'm
doing
gs
encoding
and
then
forwarding
it.
So
what
the
changes
that
you
are
mentioning?
Are
they
going
to
take
a
lot
of
time
or
can
I
expect
a
simple
stream
test
stream,
which
I
can
use
and
then
experiment
on
that
with
the
changes
rob
that
you
have
suggested.
D
A
It
doesn't
there's
always
unintended
consequences
of
you
know,
making
there's
always
unintended
consequences,
but
it
doesn't
seem
to
me
like
there's
like
it's
a
impossible
or
intractable
thing
to
say:
okay,
now
we're
going
to
make
it
wide
wideband
simply
because
of
the
quality
and
thoughtfulness
of
the
existing
protocol.
It
seems
like
it
should
be
something
that
we
could
go
ahead
and
try.
A
You
know
and
and
see
see
what
happens.
We
have
a
number
of
people
that
are
much
more.
You
know
much
more
experienced
and
and
have
a
lot
of
skill
in
in
figuring
out.
Oh,
you
know,
wow
your
frame
if
you
change
the
frame
here
for
this
broadband
or
broader
band
application,
you're
going
to
have
to
do
x,
y
or
z.
One
of
the
big
concerns,
I
think,
is
overhead.
Of
course
you
know
so
so
what
you
need
to
do
is
size,
the
the
frames
and
the
packets
and
the
payloads
and
the
overhead.
A
So
my
confidence
is
very
high,
that
if
we
go
ahead
and
commit
and
and
put
out
some
sort
of
proposal,
go
ahead
and
write
it
up
and
let
anshul
you
know,
grip
into
it
and
and
give
it
a
shot
that
we'll
see
where
the
the
edges
are.
You
know
where
the
rough
edges
are
and
where
the
bottlenecks
are.
So
I
don't
see
any
deal
breakers
in
the
protocol.
A
F
A
But
honestly,
it's
it's
a
it's
a
real
quality
protocol
and
everybody
that's
looked
at
it
has
said
this
is
really.
This
is
better
than
our
native
protocol
that
we've
been
doodling
for
a
couple
of
years.
Now
it's
it's
the
right
direction,
it's
where
we
were
headed
and
it's
just
better
and
we
should
enthusiastically
embrace
it
and
use
it
and
support
it,
because
it's
open
throat,
you
know
open
source
and
and
all
that,
all
right
back
to
you.
C
C
C
C
Yeah,
I'm
not
sure.
I
know
that
the
like
the
one
of
the
lower
speeds
that
he
already
has
programmed
is
like
56k
and
I
was
hoping
to
to
see
what
it
can
do.
I
honestly
I
got
excited
because
I
figured
I'd
buy
it
and
even
if
I
can't
change
it,
if
I
can't
you
know,
maybe
I
got
myself
in
over
over
my
head,
which
has
happened
before
worst
case.
I
have
four
cool
packet
modems,
you
know
so.
C
E
I
mean
initially,
I
I
need
to
understand.
Like
rob
mentioned,
how
will
the
headers
will
be
formed
so
that
I
can
how
I
can
map
those
headers
to
ip
related
things,
so
a
small
documentation
for
that?
That
should
be
done
and
if
I
can
join
your
group
so
that
I
can
post
any
questions
and
discuss
with
you
on
slack
channel
or
whatever
tool
you
are
using.
C
E
That's
right,
yeah
and
then
I
can
go
through
the
documentation,
improve
it
discuss
and
then
I
will
start
with
my
implementation
of
gsc.
Considering
I
can
map
those
packets,
I
can
map
ip
packets
and
in
can
encapsulate
gsc,
and
so
I
will
start
with
the
implementation
of
that.
Along
with
that,
I
will
carry
on
my
discussion
with
you
parallelly
and
then
let's
see
how
it
progresses.
E
A
Yeah,
we
use
guinea
radio
quite
a
quite
a
lot,
I
think
onshool
and
the
others
that
are
that
are
working
on
all
the
the
guts
of
it.
We
all
rely
on
gnu
radio,
the
the
sorts
of
bandwidths,
though,
that
we're
using
we've
run
out
of
gnu
radio
gnu
radio's
ability
to
to
support
like
when
I
do
demos
of
the
polyface
filter
bank
for
the
uplink.
I
have
to
use
a
very
small
cut
down
thing,
so
that's
really
the
only
drawback
to
to
using
canoe
radio,
but
there
is
implementation
of
gse.
F
E
Yeah
yep,
as
as
michelle
mentioned,
that
we
are
using
two
radio
heavily
for
for
every
stage
output.
We
use
gnu,
radio
for
validation
and
even
for
coding
for
fpga.
We
first
can
sell
crew
radio.
What's
the
logic
there
and
then
we
implemented
fpga
for
gsc.
We
have
a
module
in
gnu
radio,
but
that's
for
yeah
ib,
but
nothing
for
m17.
A
A
We
use
any
sdr,
we
can
get
our
hands
on
the
ones
that
have
been
the
most
reliable
have
been
the
usrps
in
the
lab.
We've
used,
blades
hack,
rf's
tons
of
rtl
sdrs
for
lower
bandwidth
work.
We've
used,
let's
see
the
for
first
moving
more
towards
towards
rf
the
analog
devices
dev
board
that
that
bolts
right
up
to
the
7000
series
thing
and.
A
Is
accessible
for
in
the
remote
lab,
so
you
know
that's.
The
goal
is
to
try
to
get
this
stuff
into
people's
hands
and
accessible
with
all
the
test
equipment
but
yeah,
the
those
are
the
generally
the
go-to
sdrs
have
been
the
either
the
x
310
a
little
bit
finicky
with
its
particular
fpga
accessibility.
But
the
b210
has
been
a
real
workhorse
for
us
and
has
helped
us
validate
a
whole
ton
of
things.
A
No,
it
really
isn't
and
we
have
one
and
it's
just
a
question
of
like
who
grabs
what
and
works
on
it.
The
exciting
thing
about
the
pluto
is
that
amsat
dl
is
working
really
hard
on
spinning
a
version
of
the
pluto
without
which
has
a
greatly
upgraded
clock
and
some
other
some
other
upgrades
that
make
it
really
much
more
useful
for
space
and
the
reason
one
of
the
big
reasons
there
is
not
just
for
their
engineering
team
and
for
those
of
us
that
want
to
do
sdr
work.
F
D
A
F
A
D
A
D
D
F
F
F
A
A
Yeah
gsc
is
fun
and
there's
a
gse
protocol
document
from
dvb.org
dvb.org
has
all
of
their
stuff
there
and
it.
It
really
is
good.
It's
not
a
solution
for
insomnia,
unlike
a
lot
of
other
protocol
documentations,
which
are
just
terrible
and
they
have
an
implementation
guideline
and
most
all
of
their
standards
do,
and
it's
really
good
too.
So
you
know
it's
it's
it's
pretty
good.
I
think
onshore
is
up
to
date
with
all
the
with
all
the
gse
stuff.
I
I
know
enough
to
be
dangerous
about
gse.
A
You
know
so
there's
plenty
plenty
of
help
and-
and
I
guess
the
overall
goal
is
not
to
harm
or
disrupt
or
you
know,
annoy
irritate
fold.
Spindle
mutilate
m17
at
all.
You
know
we
just
we're
hugely
enthusiastic
about
it
and
we
see
great
potential
for
using
it
in
a
broader
bandwidth,
microwave
application.