►
From YouTube: M17 protocol development for P4DX
Description
Specification of M17:
https://spec.m17project.org/
P4DX architecture document:
https://github.com/phase4ground/documents/blob/master/Engineering/Requirements/Architecture/20200902-AREx-System-Architecture.pdf
M17 is P4DX native digital uplink protocol.
There are at least three use cases of M17.
One, 9600 bps voice for VHF/UHF.
Two, the idea of 9600 bps data or packet mode, also VHF/UHF.
Three, higher bitrate mode for microwave.
There is a data type specifier in the current specification. Reserved protocol types are RAW, AX.25, APRS, 6LoWPAN, IPv4, SMS, and Winlink.
What we're talking about today is what, if anything, needs to be added to the specification in order to enable high bitrate operation for microwave, and also to figure out if anything needs to be done for IP over M17 or M17 over IP.
From Slack:
Ron
What needs to be defined is how to do IP over M17. In the M17 specification, there's a protocol identifier for IPv4, but that's it.
And here is a review of the conversation from 2021. This was the starting point for the conversation in this video recording.
Ron
M17 supports IPv4, but I'm not exactly sure how. The M17 specification seems pretty vague on that particular point
Howie
Assume we consider M17 stream mode operating in an FDM manner with a receiver for each uplink channel. Each channel can be given a GSE label that could map to an uplink center freq. The 4FSK modulated data is demodulated but not decoded. Instead, the data streams are clocked into individual buffers and used to generate the GRE frames. The idea is to keep the M17 frames intact so that on the ground earth station the demodulated data is identical to the uplinked frame which can be processed by the existing M17 decoder software. You listen to a channel by selecting the label for the stream you want to listen to. The limiting factor becomes how fast you can assemble the uplink channels into GRE frames.
I don't think there is any need or desire to use anything other than native M17 on the uplink. While GSE is normally used for IP transport I think we could put the M17 frames into the GSE data field. At that point the only overhead is on the downlink with the addition of the GSE headers and LSF management. I have not looked closely at the sizes of the required fields are or how much processing it would take to multiplex multiple uplink streams into a composite downlink. At this point I am just brainstorming.
Anshul
looks like we don't need IP as an intermediate step. I agree with @ab2s that there is no need to use anything other than native M17 on the uplink. GSE should encapsulate M17 frames and produce BBFRAME as it normally does for IP packet.
It implies we will be not using any IP stream/packets on uplink. Everything uplink will be M17 based.
Do you see any concerns here . Else, I will proceed with implementation of GSE block in firmware keeping this decision in mind.
A
I
won't
say
the
first
of
many
because
who
knows
with
all
these
brilliant
people
here
we
might
solve
all
the
problems
and
come
up
with
all
the
designs,
but
what
I'm
trying
to
do
is
gather
as
broad
input
as
possible,
because
this
has
to
do
with
the
spec
for
m17
and
our
uplink
and
the
stuff
that
we
need,
I
think,
for
a
higher
bitrate
microwave
link.
If
we
I'm
assuming
that
that
we
would
like
to
see
that
happen,
that
we
don't
want
to
just
use
the
9
600
bit
per
second
mode.
A
A
I
believe
this
is
the
latest
and
greatest
there's
been
some
formatting
changes
and
some
some
location
changes,
but
this
this,
I
believe,
is
the
correct
one
and
let's
see
if
I
can
also
put
in
a
picture.
Yes,
I'll
put
in
a
photo
that
I
just
took
and
it's
the
it's
the
only
thing
that
really
mentions
ipv4
in
the
spec
and
it
yeah.
Here
we
go
it's
in
the
there
we
go
yeah,
it's
called
a
data
type
specifier
and
the
specification.
I
think
it's
in
the
application
section.
A
A
But
I
think
most
of
that
is
is
normal
stuff,
that's
in
other
similar
protocols.
So
that's
one
use
case
is
the
is
voice
digital
voice,
vhfuhf
and
there's
awful
lot
of
time
and
attention
being
plowed
into
it,
and
a
lot
of
interesting
circuits
and
implementations
and
things
are
going
pretty.
Well
then
the
other
use
case.
It's
the
idea
of
a
9
600
bits
per
second
data
or
packet
mode,
and
every
so
often
in
the
in
the
past.
Six
months
to
a
year,
packet
or
data
mode
has
has
popped
up
in
m17
project.
A
There
used
to
be
a
pdf
that
was
supposed
to
be
the
packet
spec
and
it
was
a
parallel
document
to
the
to
the
spec
I
just
linked
that
seems
to
have
disappeared,
and
so
there
isn't
really
current
data
or
packet
mode.
There
are
two
different
modes
in
in
m17,
there's
a
streaming
so
that
you
don't
know
how
many
packets
frames
you're
going
to
get
and
and
then
and
then
the
case
where
it
is
packetized
or
it's
kind
of
called
packet
mode.
A
In
both
cases,
though,
that
seems
to
be
a
voice
or
assuming
voice,
and
the
third
use
case
is
a
higher
bit
rate
mode
for
microwave,
which
is
kind
of
where
we're
at
so
since
microwave
allows
us
to
have
such
much
wider
bandwidths
and
since
our
baseline
for
fdma
uplink
assumes
up
to
100
kilohertz.
That's
what
we
have
right
now
as
a
as
an
assumption
you
get
about
100
kilohertz
of
96
kilohertz,
and
we
expect
your
signal
to
be
somewhere
around
25
kilohertz
wide.
Now
that's
been
our
baseline
assumption
for
a
long
time.
A
Those
are
numbers
that
space
people
say
are:
okay,
you
know
they
they
could
change.
That's
why
we're
trying
to
get
things
to
work
over
the
air
as
quickly
as
possible,
because
these
are
the
sorts
of
things
that
you
will
find
out
very
quickly.
Do
not
do
or
do
not
work,
but
in
in
any
case
it
doesn't
matter
what
the
end
number
of
uplink
channels
are.
A
A
So
those
are
the
three
different
use
cases
and
and
then
there's
a
question
of
okay.
So
so,
since
we're
data
centric
and
we
want
to
be
able
to
ship
data-
and
since
we
have,
we
do
not
have
the
same
protocol
all
the
way
through
that
we
have
the
opportunity
to
use
dpbs2
s2x
on
the
downlink
and
we
have
m17,
maybe
one
of
many
different
things.
That's
transmitted
on
the
uplink
that
we
simply
digitize
and
then
package
that
stuff
up
for
people
in
channels.
A
A
So
since
these
protocol
types
are
in
there,
it
kind
of
begs
the
question
of
well
how
what
do
we
need
to
add
to
the
spec?
If
anything,
in
order
to
take
advantage
of
this,
and
what
do
we
might?
What
might
we
want
to
do
at
microwave
to
handle
ip
over
m17,
and
that
was
a
question
that
was
raised
this
past
week
by
ron
economos
on
slack,
and
it's
also
a
question
that
he
raised
a
while
back
in
2021.
A
He
says
what
needs
to
be
defined
as
how
to
do
ip
over
m17
in
the
spec
there's
a
protocol
identifier
for
ipv4
and
that's
it
and
before
a
year
ago
he
said,
I
guess
m17
supports
ib
ipv4,
but
I'm
not
exactly
sure
how
and
the
spec
seems
pretty
vague
on
that.
Okay,
so
that
that's
that's
what
was
said
by
ron,
I'm
going
to
go
ahead
and
put
all
of
this
into
the
chat.
A
A
He
agreed
that
it
was
vague
by
the
way.
That's
he's
starting
off
by
agreeing
with
with
ron
and
howie's
take
was
that
we
don't
do
anything
with
ib
ipv4.
We
don't
mess
with
m17
that
we
use
native
m17
on
the
uplink
and
that's
it
and
then
we'd
end
up
putting
the
m17
frames
into
gse
data
fields.
The
generic
stream
encapsulation
on
dvb
s2,
downlink.
A
A
Okay,
yeah,
the
probably
the
important
most
important
thing
to
know,
is
that
we
have
a
frequency
division,
multiple
access
up,
link
on
five
gigahertz,
and
so
those
frequency
division
channels
would
be
some
of
them.
Maybe
all
of
them
would
be
full
of
m17
signals
and
then
in
our
transponder,
what
we
do
is
we
we
take
in
all
those
channels,
they're,
digitized
and
then
they're,
packed
into
dvb,
s2
or
sgx
frames,
and
then
there's
some
quality
of
service
stuff,
there's
some
adaptive
coding
and
modulation
stuff.
A
But
it
is
a
digitally
multiplexing
transponder,
so
it
goes
from
five
gigahertz
and
it
transmits
at
10
gigahertz
the
protocols
on
the
uplink
and
the
protocols
of
the
downlink
are
different.
So
we
have
an
opportunity
to
really
screw
things
up.
You
know
and
make
it
overly
complicated
and-
and
you
know,
lots
and
lots
of
overhead
pads
packets
all
the
way
down.
It's
all
headers.
You
know
we
could
easily
do
something
like
that.
You
know
so
so.
B
A
A
A
A
You
know
which,
which
we
we
don't
need
to
do.
We
we
don't
have
to
do
that.
We
can
actually,
since
it's
packetized,
it's
essentially
already
frames
of
data
that
can
go
right
into
gse
on
the
downlink
at
least.
That's
that's
my
opinion.
My
understanding
of
of
what
we're
capable
of
doing
with
gse,
so
m17
would
use
would
have
as
its
payload
whatever
it
had
right
now.
A
If
you
were
going
to
ship
data
through
m17
protocol,
is
there
something
else
that
needs
to
be
done
it?
It
certainly
does
not
seem
to
be
very
efficient
at
9
600
bits
per
second
to
then
say
that
your
payload
is
going
to
be
ipv4,
so
I'm
I'm
curiou.
I
guess
I
have
lots
of
questions.
I
probably
have
more
questions
than
answers.
You
know
I
see
these
these
protocol
types
and
like
what?
What
exactly
are
we
expected
to
do
with
them?
A
C
A
B
On
the
system
like,
let's
say,
we're
we're
trying
to
kind
of
design
to
have
we
looked
and
compared
it
to
like
ccs,
ccsds
and-
and
I
mean
that's
kind
of
a
very
popular
open
source
system-
that
a
lot
of
people
are
using
and
being
adopted.
So
what
is
the
advantage
of
using
this?
You
know
what
we're
trying
to
do
over
something
else.
A
B
A
I'm
familiar
with
with
like
ccsds
privileges
and
emphasizes
ld
ldbc,
which
is
what
we
use
for
dbbs2,
and
I
I
know
that
there's
there's
a
really
good
document
from
ccsds
on
how
to
on
how
to
implement
dvbs2
within
ccsds
links
in
a
compatible
way
that
you
have
to
do
a
little
bit
of
work,
but
it's
it's
almost
there.
So
my
I
have
never
thought
about
this.
This
question
with
respect
to
the
uplink.
I've
always
looked
at
our
compatibility
with
ccsds
on
the
downlink,
so
I
think
maybe
we
can.
A
We
can
go
look
but
but,
like
I
said,
we're
not
it's
it's.
We
want
to
make
sure
that
we
are
compatible
with
and
fully
utilize,
m17
and
now's
the
time
to
change
the
specification
you
know
or
if
we,
if,
if
necessary,
so
I
I
don't
want
to
give
off
the
vibe
that
that
I
believe
that
it's
that
we
have
to
change
it.
A
We
may
we
may
look
at
this
and
and
walk
through
these
questions
and
and
say
that
we
don't
need
to
change
anything
but
I'd
like
to
fully
utilize
and
make
m17
as
perfect
as
possible
for
for
what
we
want
to
use.
But
it's
not
the
only
uplink
protocol
that
we'll
be
seeing
or
the
only
or
that
we
can
accept.
D
I
think
if
we,
if
we
do
want
to
run
data
through
m17
using
m17
as
much
as
possible
of
the
standard
existing
m17
protocol
on
the
uplink,
then
it's
I
think
it's
pretty
clear
how
you
put
data
in
there
there's
a
type
id,
and
maybe
that's
all
you
need
it's
pretty
clear
that
you
they
intend
for
you
to
put
packets
of
whatever
you're
transmitting
into
packets
of
m17
and
that
that's
all
you
need
to
know
about
that.
As
far
as
I
can
see
now,
there
are
some
consequences.
D
A
D
Voice
frames
that
you
can
stack
up
to
make
a
data
frame,
okay
and
the
reason
it's
limited
is
because
they
want
to
encode
the
length
in
a
certain
way
that
I'm
not
sure,
that's
a
great
reason
to
have
it
limited,
but
there
it
is
so
you
can
get
up
to
much
longer
than
a
voice
frame.
Okay,
I
forget,
I
don't
know
exactly
what
it
translates
into
in
the
in
time
units,
but
it's
like
a
second
or
more
just
off
hand
of
data,
not
not
constrained
by
voice
latency.
A
D
Yes,
I
believe
it
is,
and
it's
that's
actually
pretty
well
defined
in
the
spec
already
it's
just
in
one
of
the
appendices:
okay,
there's
an
appendix
on
ip
networking.
That
includes
exactly
how
you
put
an
m17
packet
into
and
its
auxiliary
control
stuff
as
well
into
ip,
but
it's
oriented
strictly
toward
what
jay
said
that
linking
repeaters
it
may
be
good
enough.
We'd
have
to
look
at
it
carefully.
Make
sure
that
everything
we
need
is
in
there,
but
it
depends
on
what
the
use
case
is.
Why
are
we
putting
m17
into
ip.
A
A
Which
raises
immediately
raises
the
the
reason
why
qo
100
is
not
accessible
over
a
terrestrial
network
because
they
were,
they
were
very
concerned
about
it.
Getting
completely
flooded
by
you
know,
essentially
voip
or
ip
voice
users
I,
which
which-
and
that
was
that
was
a
call
made
very,
very
early
on
to
force
people
to
access
this
particular
spacecraft
over
the
air,
and
you
had
to
be
in
the
footprint,
no
remote
stations
or
very
limited
remote
stations.
A
A
You
know
I
I
can
see
where
mountaintop
terrestrial,
you
know
you
know.
Essentially
a
groundsat
in
los
angeles
would
end
up
just
being
another
node
in
m17,
and
you
know
we
would.
I
would.
I
would
expect
this
a
similar
sort
of
situation,
that
we
have
it's
sbms
meetings,
where
there's
50
people
on
zoom
and
there's
15
people
in
the
room
at
the
in-person
meeting
and
there's
one
or
two
people
on
atv
checking
into
the
meeting,
and
it's
the
same.
Two
people.
A
A
Then
you
can't
connect
up
to
the
equivalent
of
zoom.
So
I
don't
think
we
have
to
decide
that
right
now,
but
you
know
to
me
it's
something
that
we'd
want
to
do.
I'd
lean
more
towards
going
ahead
and
putting
that
in
there
because
of
the
potential
usefulness
and
and
the
the
number
of
people
that
would
then
be
available
to
to
use
it.
So
I
don't
know
what
do
y'all
think.
E
So
you're
saying
that
you'd
have
m17
coming
in
and
then
you
would
then
take
the
m17
and
packetize
it
or
do
it
over
ip.
So
then
you
could
potentially
have
one
ip
pipe
going
from
the
hardware
to
somewhere,
whether
it's
to
other
reflectors
or
you're,
using
ip
as
your
sold,
downlink
or
piece
of
pc
or
downlink,
instead
of
instead
of
bringing
all
the
different
m17
channels
up
and
all
the
m17
channels
just
sort
of
existing
back
down.
D
I
don't
think
we're
proposing
to
use
the
satellite
as
a
as
the
backbone
for
the
repeater
linking
we're
proposing
to
participate
in
the
repeater
linking
as
a
repeater.
Basically,
so
if
anybody
using
the
satellite
wanted
to
get
involved
in
that
they
could
do
the
appropriate,
whatever
the
appropriate
command
sequences
are,
I
don't
know
how
that
even
works
on
m17,
I'm
not
sure
they
do
yet
and
and
link
to
another
site
which
may
or
may
not
be
part
of
the
terrestrial
network.
A
Yeah,
it's
a
fork,
you
know
like
so
you'd
have
the,
but
I
guess
the
the
the
most
sensible
answer
to
your
question
is:
yes,
it's
you
know.
If
we,
if
we
added
a
compatibility
with
a
linked
repeater
system,
it
would
be
any
it'd
be
m17
coming
in
and
then
it
would
be
put
over
ip
using
what
what's
in
this
appendix
with
and
there's
all
sorts
of
repercussions
for
these
sorts
of
decisions,
but
it
it's
not
either
or
it's
both
you're,
adding.
D
I
think
that's
an
excellent
point
and
that
leads
us
to
conclusion
that
the
that
we're
wrapping
m17
in
their
ip
networking
framework,
that's
defined
in
this
appendix,
is
outside
the
air
interface
and
probably
not
done
inside
of
the
phase
four
transponder.
It
would
be
a
separate
adaptation
layer
that
you'd
add
to
a
mountain
top
thing.
If
you
wanted
to
do
that
with
your
mountain
top.
A
E
D
E
So
you're
not
going
to
try
to
do
that
in
the
satellite
you
would
you
would
do
that.
You
would
do
that
aggregation
on
a
ground
station
and
maybe
maybe
send
ip
up
and
down
have
an
eyepiece
have
an
ip
stream
that
that
was
on
the
ground
already
channel
a
bunch
of
m17
aggregated
into
an
ip
stream
up
and
back
down,
or
you
could
have
a
bunch
of
m17
going
up,
but
it's.
But
at
that
point
it's
still
going
to
be
m17.
Coming
back
down.
A
It's
a
concept
that
where
you
have
hts
and
analog
you
know
or
p25
or
whatever,
and
that
whatever
footprint
you
can
pick
up
within
an
area
of
you
know
mobile
communications
like
that
vhf
uhf
that
it's
aggregated
and
sent
up
in
a
channel
and
that
that
is
an
uplink
and
then
it
and
then
all
of
a
sudden,
your
area
which
may
be
a
communications
emergency
or
an
event
of
some
sort,
all
of
a
sudden
that
has
a
footprint
as
wide
as
whatever
satellite
you're
we're
working
through.
So
it's
a
similar
concept.
A
I
think
to
that
and
it's
that
that
is
definitely
outside
of
the
transponder.
It's
just
another
channel.
It
might
have
to
be
a
bigger
channel
than
than
what
we
are
assuming
and
we've
talked
about
channel
bonding,
and
I
know
a
little
bit
about
that.
You
know
so
so
it
would
be.
It's
like
okay!
Well,
we
asked
ourselves
well
how
big
is
the
entire
two
meter
band?
You
know
why
not
just
you
know
say
that
we'll
we'll
put
the
entire
two
meter
band
in
a
particular
area
on
the
you
know
up
and
down.
A
If
you
needed
to
you
know-
and
this
was
back
when
we
were
speaking
actively
with
fema-
this
was
something
that
they
they
were
like.
You
can
do
that.
I'm
like
well
yeah,
you
know,
that's,
that's
it's
an
implementation
challenge.
It's
not
a
blank
paper
design
problem.
These
are
things
that
we
we
know
how
to
do.
It
would
take
some
some
fairly
high
horsepower
stuff
for
for
budgets
like
us,
but
you
know
the
motorola
has
a
radio
that
does
this.
You
know
I
mean
they.
A
A
D
A
Yeah,
but
I'd
like
to
talk
about
that,
because
there's
a
there's
always
going
to
be
a
big
pressure
to
to
just
use
whatever
to
use.
M17
use
the
9600
per
second,
because
it's
going
to
be
a
tough
uphill
battle
to
get
people
to
develop,
build,
buy
manufacturer.
You
know
adopt
radios
that
do
yet
another
digital
voice
protocol.
This
is
a
huge
effort.
It
I
think
it's
going
to
be
successful.
I
wouldn't
spend
a
lot
of
time
on
it.
A
If
I
didn't,
but
I
know
it's
a
really
very
hard
thing
so
and
then
what
are
we
going
to
do
turn
right
around
and
say
you
have
to
have
a
broader
band
radio
to
do
m17
over
the
satellite,
so
in
in
terms
of
like
market
awareness,
market
acceptance,
products
success,
protocol
success,
I
think
we
have
to
you-
know,
look
really
really
hard
at.
We
have
to
support
the
9600
version,
but
wow
is
it
so
harshly
limited
in
terms
of
bits
per
second,
so.
A
D
You're,
assuming
that
user
would
have
a
off-the-shelf
m17,
maybe
even
an
ht
but
m17
radio
of
some
sort
and
he'd
want
to
be
able
to
use
that
on
the
satellite
and
it
can't
right
because
it's
the
wrong
band
and
the
wrong
power
and
the
wrong
gain
and
everything.
So
at
minimum.
He's
gonna
have
to
have
like
an
up
converter.
A
D
A
D
I
think
that
maybe
people
are
going
to
say
that,
of
course,
why
can't
I
use
my
ht
they've
said
that
on
you
know,
on
about
their
fm
hts
for
every
single
sideband
satellite
there's
been
and
so
on,
and
so
on.
At
some
point
you
have
to
just
have
to
say:
yeah,
okay,
it's
going
to
take
some
new
equipment.
A
A
A
I
mean
I
have
to
actually
like
write
python
scripts
and
have
spreadsheets
to
figure
this
stuff
out
right,
okay,
so,
unless
you're
I'm
not
expecting
answers
to
that
question,
but
I
think
we
need
to
start
working
on
an
m17
uplink
spec
for
five
gigahertz,
for
what
we're
doing
and
we're
going
to
have
to
start
transmitting
it
over
the
air
or
at
least
conduct
it
into
our
circuits
and
start
working
with
it.
Like
you
know.
E
A
A
And
that,
when
my
when
I
talk
up
m17
to
groups
and
people,
I
always
emphasize
that
it's
a
layered
protocol
and
to
me
like
from
the
start,
it
was
the
intention
and
the
execution
are
yeah.
It's
layered,
but
it
isn't
quite
this
isn't
as
modular
in
this
spec,
as
it
probably
should
be,
so
we're
not
there
yet,
and
I
deeply
appreciate
the
work
that
you're
doing
to
make.
That
actual
like,
like
meant
to
make
what
I'm
promising
people
actually
true.
A
A
You
know
it's
like
that
column
from
from
family
circus
magazine.
Can
this
protocol
be
saved?
Some
of
them
cannot.
Some
of
them
are
just
terrible,
and
I
so
one
of
them
starts
with
the
letter
a
and
is
very
frustrating
to
to
work
with,
but
this
one,
no,
I
think
we
can
achieve
it.
You
can
get
there
so
so
I
guess
it
sounds
like
the
two
jobs,
you're,
you're,
excellent
and
and
very
appreciated
work
which
will
change
the
future
of
ham,
radio
for
everyone.
A
It
will
you're
you're
like
messing
with
the
actual
dna
like
so
it
sounds
like
those
are
intertwined
problems
like
what
what
and
it
I
guess
what
what
I'm
most
frightened
of.
If
I
was
I'm
really
frightened
of
anything
but
like
most
kind
of
like
looking
at
is
you
know,
is
there
anything
broken?
I
think,
which
is
what
you
said
like?
A
A
A
E
A
I
asked
the
question
it
was
months
ago
now,
but
I
I
kind
of
had
a
tantrum
about
the
quality
of
the
codec
because
it
was
on
the
friday
net.
It
just
sounds
like
and
at
all,
but
that's
all
codecs
that
are
like
ambi
codex.
You
know
all
the
ambi
codecs
sound
like
crap
and
I'm
expecting
kodak
2
to
be
better
and
I'm
hearing
person
after
person
sound
worse
than
jc
system
fusion
and
I
was
like
we
have
to
find.
We
cannot
have
this
be
the
product
that
we're
trying
to
sell.
A
We
can't
and
that
sparked
some
work
on
the
3200
bit
per
second
kodak
from
voice
check,
and
I
think
that
there's
some
improvements
that
can
be
found
from
his
work
and
then
we
seriously
looked
at
how
hard
is
it
to
just
drop
in
a
new
codec
to
drop
in
opus
or
luna?
Or
you
know,
there's
there's
a
number
of
them,
and
even
you
know,
even
if
you
just
limit
yourself
to
open
source,
you
still
have
two
big
ones:
opus
and
kodak
too,
but
at
3
200
bits
per
second.
A
It
still
doesn't
sound
good
to
me
and
with
everything
it
turns
out
that,
with
everything
being
kind
of
assuming
this
particular
assuming
codec
too
there's
an
awful
lot
of
stuff.
That
seems
like
it's.
It's
hanging
on
that
decision,
so
the
in
the
end,
they
were
like.
Oh
we're,
just
going
to
stay
with
kodak
too,
which
is
fine
as
long
as
it
does
not
sound
like
it
sounded
months
ago.
A
You
know
from
these
very
all
these
companies
and
then
you
take
it
out
of
the
box
and
you
you
go
to
talk
to
your
friends
and
you
can't
recognize
who
they
are
and
it
just
it
works
it.
It
hurts
me
so
I
I
don't
want
us
to
have
that
problem
and
I
don't
want
m17
vhf
ui
shipped
out
of
that
problem
to
at
least
mitigate
it
as
much
as
possible,
but
at
9
600
bits
per
second.
A
D
D
A
D
A
A
B
B
B
E
A
D
E
B
A
Yeah,
that's
that's
yeah.
I
think
I
think
so
that's
I
mean
the
sort
of
the
goal
would
be
okay,
so
we
have
this
spec
and
then
can
we
get
a
hook
in
to
where
a
receiver
that
then
knew
what
what
was
coming.
Could
you
know,
which
is
our
radios
would
know
what
to
do,
and
then
I'm
thinking
that
that
would
that
would
help.
Am
I
I
guess
the
other
way
to
do.
This
is
to
just
leave
this
completely
alone
and
and
do
a
totally
separate
parallel
effort.
D
E
E
There's
not
really
issues
it's
more,
it's
more
just
making
sure
things
are
well
defined
and
clear.
Some
of
the
wording
is
in
this.
In
this
version,
some
of
the
wording
is
a
little
bit
tough,
there's,
there's
references
to
items
that
really
should
only
be
in
the
data.
The
data
link
layer
like
when
I
start
talking
about
what
type
of
sync
burst
words.
So
it's
like
you
shouldn't
be
talking
about
what
type
of
sync
burst
words.
A
E
The
only
the
only
point
contention
that
I've
run
into
so
far
and
it's
not
that
big
of
a
deal,
but
at
this
level
the
the
data
is
xored
with
random
data.
So
you
get
a
you,
get
a
randomized,
a
somewhat
randomized
bit
stream
so
that
you
can
at
least
guarantee
that
you're
getting
zero
and
one
transitions
and
the
data
is
just
a
table
of
random
numbers
and
it
wasn't
generated
by
any
specific
algorithm.
So
anybody
that
implements
it
actually
has
to
put
the
table
in
there.
B
E
So
I
understand
why
you
know,
and
and
to
a
certain
extent
you
know
the
argument
was
well:
are
48
six
spikes
going
to
kill
you,
probably
not,
unless
you're
really
constrained
in
fpga
or
something
and
just
rather
do
it
that
way
but
anyway,
but
that's
that's
the
type
of
problems
that
are
popping
up
where
it's
it's
not
like.
Even
the
algorithm
here
isn't
very
clear.
I
mean
you
can
do
lots
of
different
ways
of
doing
an
xor
to
to
generate
a
scrambler.
B
B
You
know,
like
you,
said
you
kind
of
said
this,
that
right
at
the
beginning,
where
nine
kilohertz
channel-
that's
that
can
be.
You
know
time
and
I'm
not
necessarily
a
big
fan
of
4fsk
from
a
frequency,
modulation
standpoint,
and
this
is
a
digital
system.
Can
we
select
a
more
modern
alternative
to
you
know,
modulation,
even.
A
A
B
C
A
A
A
A
A
I
I'm
I'm
hoping
that
that
will
make
our
job
easier,
that
that
we
can
then
work
on
implementing
a
much
higher
bit
rate
version
based.
That
would
then
be
triggered
by
that
particular
type
field.
Is
that?
Does
it
sound
like
something
that
we
should
ask
for
knowing
all
the
things
we
don't
know
right
now,.
B
B
B
A
E
So
would
you
do
something
like
you'd
have
this
field
in
the
link,
setup
frame
and
you'd
start
off
at
9
600
with
the
first
link
setup
and
then
switch,
but
that
doesn't
help
you
with
the
other
the
break,
because
that
you
only
get
the
link
setup
frame
when
you
first
start
transmitting
after
that,
it's
all
broken
up
in
part
of
the
part
up
in
the
super
frame.
So
you've
got
the
1
6
of
each
link
setup
frame
per
frame
yeah
there
you
go.
E
E
E
A
D
A
I
mean
if
it
was,
I
would
not
put
the
voice
codec
rates
in
the
data
link
layer
at
all,
but
that's
I
I'm
I'm
pretty
extreme
on
this
issue
that
the
negotiation
of
the
codec
needs
to
be
at
the
application
layer
and
if
you
wish,
if
you
want
to
sound
like
ambi
or
you
want
people
to
sound
like
ambi,
you
can
choose
that.
But
you
know
the
rest
of
us
would
like
to
recognize
our
friends.
A
D
D
A
D
D
A
A
Well,
we,
oh,
I
I
commit
I
didn't
want
to
over
commit
people
since
I
proposed
an
hour
and
we've
we've
filled
it.
We
filled
it
up
with
lots
of
good
questions
and
answers.
So
I
wanted
to
be
respectful
of
folks
time
and
and
go
ahead
and
and
close
it
and
then
we
will
meet
meet
again
to
talk
about
this
stuff.
It
sounds
like
there's
a
lot
of
work.
That's
going
on.
We've
raised
a
lot
of
questions.
A
D
B
A
A
That's
kind
of
a
good
question:
gosh,
you
know,
there's
there
are
ways
to
have
cross
project
channels,
but
I'm
not
sure
how
that
works
with
discord,
there's
an
awful
lot
of
channels
on
discord
and
there's
at
least
one
where
the
protocol
stuff
happens.
So
I
don't
know,
let
me
think
about
it
and
see
what
I
can
do
I.
If
it
ends
up
being
a
much
lengthier
project,
then
you
know,
then
I
guess
the
answer
would
would
be
yes.
A
A
A
I
think
we've
concluded
that
we're
in
good
shape
and
that
both
exist
and
that
you
know
what
we
have
is
m17
native
we're
just
handling
m17
on
the
uplink.
That
m17
already
has
a
protocol
field
for
ipv4
that
if
you
really
wanted
to
put
ipv4
in
in
m17,
you
could
and
that
the
appendix
and
the
specification
already
defines
a
way
to
do
m17
art
over
ip
and
that
we
we
don't
need
to
do
anything
drastic
at
all
that
it's
it's
pretty
much
worked
out.
D
A
Correct
we
don't
need
to
do
that
and
both
howie
and
onshaw
both
came
down
on
that
side
back
in
2021,
and
I
think
that
I
think
what
ron
is
saying
ron
economist
is
saying
is
that
when
he
says
what
needs
to
be
defined
is
how
to
do
ip
over
m17,
but
I
I
think
that
just
that
having
the
protocol
identifier
and
then
shipping
ipv4
within
m17,
with
of
course,
the
limitations
that
paul
brought
up.
That's
and
that's
not
our
job.
That's
that's
a
m17
job
and
I
think
that's
that's
set.
E
A
Actually
yeah,
I
agree.
I
actually
wrote
that
down
that
you
know,
wouldn't
it
be
cool
to
have
you
know
a
hello
world
for
all
of
this
and
I
I,
when
I
saw
wind
link,
I
I
know
some
people
that
would
be
excited
about
that
and
you
know
so,
I'm
looking
at
6
lopan
and
familiar
with
that
as
well.
There's
some
really
neat
things
that
could
be
done.
So
I
agree
with
you.
D
Yeah
question
occurred
to
me,
which
I
have
not
yet
researched,
which
is,
is
the
packet
mode
supported
at
all
in
the
m17
mod
and
m17
d,
mod
programs
that
already
exist,
and
if
it
is,
then
it
would
be
easy
enough
to
to
do
some
demos
with
that.
If
it's
not,
then
that's
where
it
needs
to
go.
First,
probably,
is
to
add
implementation
of
all
the
all
the
modes
into
those
examples.
D
A
B
B
B
Yeah
and
and
from
an
open
source
perspective,
because
I
mean
I
think
the
europeans
have
adopted
a
lot
of
it.
I
mean
it's
that's
where
they
originate,
you
know
and
from
an
open
source
perspective.
I
think
you
get
a
lot
of
bang
for
your
buck
if
you're
doing
that
and
there's
also
a
fairly
rich
resource
pool
of
people
that
know
how
to
deal
with
it.
So
anyways,
okay,
I'll
I'll
point,
give
some
links
and
some
of
the
my
favorite
docs
and
stuff
like
that.