►
From YouTube: 20210822 M17 Summit
Description
Attending technical contributors: Jonathan Corgan, Steve Miller, Ed Wilson, Wojciech Kaczmarsk, Mike McGinty, and Rob Riggs from M17.
Support staff: Michelle W5NYV from ORI.
We have at least two technical questions that need to be answered.
One directly affects the protocol definition. There are differences of opinion on the end of stream, or EOS. There are multiple ways to do this and all of the different ways have assumptions, axioms, stipulations, and reasoning behind them. If all we do today is clearly identify several methods that can then be tested in simulation and over the air, then that is a huge step forward. Documenting all of the choices and showing the process of decision making is of great value to the community.
The other question affects usability, testing, verification and validation for the silicon path, and that is bit error rate testing. Team to discuss an approach to BER.
A
A
My
girlfriend
might
disagree
with
that,
but
I
don't
yeah.
So
I
got
an
email
from
jim
back
in
2016,
saying
we're
doing
a
hot
spot
and
I
did
feel
a
bit
bad
actually
because
I'm
a
really
good
friend,
with
gus
of
p1plm
of
dv
mega
fame,
still
am
actually
he's
a
lovely
guy.
And
so
I
thought
so.
I
sent
him
an
email
saying,
I'm
really
sorry,
but
there's
going
to
be
an
mmd
vm
hotspot
and
he
said.
B
C
A
Transmit's
always
the
easy
one
anyway,
but
the
receive
side
was
not
not
good
at
all,
but
be
nice
get
that
working
because
it
would
open
it
up,
because
it
also
means
you
can
actually
do
testing
with
hotspot
hotspot,
whereas
of
course,
as
you
know,
I've
got
basically
just
a
pile
of
radios
here,
yeah
all
on
dummy
loads.
Looking
forward
to
it,
it'll
be.
A
E
A
Might
all
change,
but
you
know
I'm
putting
it
in
just
to
see
if
it
works
and
passes
through
the
network
and
everything.
If
so,
we
can
then
tweak
the
format,
but
the
idea
is
just
to
get
something
that
works
and
see
if
we
can
just
pass
it
because
I've
already
me
and
oh
well,
anybody
wanting
an
m17
client
we're
already
passing
text
messages
to
each
other.
So,
on
the
touch
screen,
we
can
actually
see
each
other's
names,
which
is
quite
nice,
excellent.
D
A
D
D
D
That's
the
bit
error
rate
testing
ber
testing,
so
I
hope
you
all
will
help
me
see
why
there
would
be
any
resistance
to
better
visibility
with
respect
to
ber
testing,
because
I'm
I'm
looking
forward
to
hearing
more
about
this,
because
those
those
regimes
and
different
standards
are
going
to
be
required
to
go
to
silicon.
It's
going
to
be
required
for
more
data,
centric
media
and
it
very
well
will
be
expected
by
commercial
partners.
D
So
I'd
like
to
talk
about
the
bit
error
rate
questions,
and-
and
so
you
all
can
help
me
understand
where
we're
at
and
so
those
are
the
two
technical
questions.
The
the
technical
work
is
is
not
honestly,
not
the
most
important
part
of
meetings
like
this
working
together
successfully
is
there
have
been
some
people
have
spoken
up
about
feeling
unheard
unappreciated
and
uncomfortable
with
some
of
the
way.
Some
of
the
technical
discussions
have
gone.
D
This
meeting
alone
is
not
going
to
fix
that
not
gonna
not
intended
to
fix
it,
but
it
can
start
the
process
developing
more
of
a
of
a
history
of
working
together,
really
well
so
for
the
next
hour
or
so
put
everybody
else
in
the
best
possible
light,
even
if
it
feels
like
you're
the
one
that
has
to
carry
the
burden
and
be
generous
with
the
benefit
of
the
doubt.
If
anything
comes
up,
so
I'll
kick
off
introductions.
D
My
name
is
michelle
thompson
w5nyv,
I'm
the
co-founder
and
current
ceo
of
open
research
institute,
we're
the
fiscal
sponsors
of
m17.
I
have
a
master's
in
information
theory.
I
run
a
rural
telephone
company,
we
have
a
large
fiber
optic
plant
and
we
offer
both
broadband
and
traditional
voice
services.
I've
worked
for
global
star
atmc
apiary
kyocera
wireless.
A
couple
other
places
serve
on
technical
advisory
committees
for
virginia
tech,
space,
industry,
advisory
board,
arl
and
I've
applied
for
position
as
attack
for
the
fcc.
So
we'll
see
how
that
goes,
and
that's
that's
my
background.
D
D
B
I've
been
working
with
m17
for
the
last
year
or
so,
and
voyage
brought
me
along
and
again
I
have
no
technical
experiences,
but
I've
been
a
ham
radio
operator
for
many
many
years
and
I
have
worked
in
team
aspects
for
the
last
23
years
of
my
paid
career.
So
I'm
kind
of
used
to
teamwork
and
bringing
people
together
from
various
backgrounds
for
a
joint
course
to
make
sure
it
gets
done.
A
I
did
system
fusion
p25
nxdn
a
wall
sided
fm
ax25
based
on
rob's
code,
although
repurposed
to
a
different
scan,
some
frequency
and
m17,
which
I
think
I
did
nothing
about
september
last
year
september
september
october
and
as
as
you
know,
from
the
discussion
about
hot
spots,
which
is
currently
ongoing,
things
are
moving
quite
rapidly
in
that
way.
Now
I've
got
the
main
problems
fixed.
Excuse
me.
A
I
have
suggested
various
things
for
the
protocol,
a
number
of
which
have
been
taken
on
border
might
have
things
like
the
channel
access
number
and
also
the
change
of
synchronization
vectors
to
be
sort
of
more
unique,
so
they're
my
main
contribution,
I
think,
oh,
and
also
the
way
the
lsf
I
think
is
fragmented
as
well,
but
essentially
yeah
I've.
So
I've
got
a
lot
of
experience
implementing
other
dv
modes
and
I've
seen
a
lot
of
similarities
and
non-similarities
between
them.
F
F
Definitely,
you
know
teaches
me
a
lot
and
that's
what
I've
really
been
looking
forward
to
on
this
the
m17
project.
Really,
I
don't
do
a
whole
lot
as
far
as
the
protocol,
the
spec
or
you
know,
implementations
or
anything
like
that.
I
I
just
basically
kind
of
take
the
pieces
that
people
have
been
developing
and
put
them
into
action
to
see
how
well
they
work,
and
you
know
along
those
lines,
I've
been
learning
a
lot.
F
E
F
Know
the
chat
and
and
communications
platforms,
while
ed,
does
a
lot
of
the
moderation
for
that.
You
know,
I'm
the
one
that
runs
the
systems
behind
the
scenes
and
I'm
also
going
to
be
building
the
lab
for
m17
here
in
the
united
states
at
least
one
of
them
hopefully
there'll
be
many
but
yeah,
I'm
going
to
use
that
to
further
by
developing
an
amateur
radio
and
developing
and
17.
So
definitely
looking
forward
to
that
yeah,
I'm
just
a
simple
systems,
admin
making
my
way
through
amateur
radio.
F
C
Hi
guys
rob
riggs
wx90,
I
am
a
I've,
been
a
licensed
amateur
for
about
10
years.
Almost
I'm
a
software
engineer.
I
currently
work
in
the
fintech
industry
and
about
eight
years
ago
I
founded
mobilelink
to
sell
these
tncs
that
I
developed
for
aprs,
and
that
was
just
supposed
to
be
a
side
hobby
project
and
it's
basically
taken
on
a
life
of
its
own
to
the
point
where
I'm
having
to
make
a
decision,
whether
or
not
to
just
dedicate
full-time
to
to
that
project.
C
But
beyond
that
I've
been
doing
I've
been
a
software
engineer
for
30
plus
years
now,
I've
been
involved
in
a
lot
of
open
source
development
and
started
working
on
well.
I've
been
very
interested
in
electronics
and
digital
signal
processing
for
a
while
and
recently
picked
up
m17.
When
I
saw
a
post
by
voy
check
on
on
reddit
and
picked
my
interest
and
realized
that
with
an
open
protocol,
I
could
actually
do
the
implementation
in
the
tnc
and
take
it
on
from
there.
C
So
I
think
the
first
implementation
I
had
was
actually
done
in
python
on
a
notebook
around
november
time
frame
and
then
quickly,
converted
everything
over
to
c
plus,
where
we
have
a
standalone
linux
client
that
can
work
with
rtl
sdrs,
as
well
as
embedding
that
into
the
the
tnc3
and
some
additional
hardware
platforms
that
I've
been
playing
around
with
yeah.
So
that's
my
background.
E
E
E
It
wasn't
coded
by
me.
It
was
just
a
part
of
the
si
silicon
lapse
chip,
so
I
just
got
the
not
the
base
band
out,
but
rather
the
bit
stream
out,
so
I
just
had
to
unframe
it
and
pass
it
to
the
vocoder
and
do
the
other
stuff.
So
there
was
no
no
trellis,
no
with
therapy
no
convolutional
encoding
and
the
code
decoding
nothing
like
like
that,
but
it
worked.
So
it
was
my
first
implementation.
B
All
right,
so
my
name
is
mike.
My
call
is
w2fbi.
I
was
first
licensed
in
2009
and
just
as
a
small
point
of
interest.
That
call
is
actually
from
my
great
grandfather
out
on
long
island
in
the
30s,
so
that
it's
w2
fbi,
but
it
was
fbi
before
the
fbi
had
become
the
fbi.
They
were
still
the
bureau
of
investigation
and
when
the
fcc
went
to
the
new
call
system
and
took
over
from
the
previous
organization,
that's
the
call
he
ended
up
with.
B
B
So
that's
probably
where
I
feel
most
comfortable
is
playing
around
with
open
source
software
in
ham,
radio,
I'm
sure
that's
true
of
all
of
us
and
that
particular
platform.
I
have
a
lot
of
time
doing
not
code
on
the
radio
itself,
but
support
software
code,
plug
programming,
firmware
upgrading
everything
like
that.
That's
part
of
where,
where
dmr.tools
came
out
of,
is
it's
an
online
project
about
doing
support
software
for
those
radios
and
similar
ones
like
it
eventually
and
I've
written
code
for
a
lot
of
different
things?
B
D
D
A
A
The
top
bit,
which
you
know
with
will
obs,
is
actually
fine.
However,
if
you
do
have
a
problem
with
br
and
we
have
seen
it
occasionally,
certainly
on
my
system,
I
think
there's
actually
maybe
a
bug
actually
in
the
modem,
but
even
so
it's
an
interesting
and
useful
test
sometimes-
and
this
is
a
probably
to
do
with
the
way
a
convolution
codes
work
is
that
if
the
convolution
code
is
having
a
bad
time,
it'll
often
set
a
lot
of
bits
to
correct.
A
Thinking
about
this,
I
thought
this
is
not
the
strongest
way
of
doing
things,
but
while
we
had
the
checksum
on
the
payload,
then
it
was
less
of
an
issue.
However,
the
checksum
was
taken
off
which
I'm
fully
in
agreement
with,
I
might
have
absolutely
fully
in
agreement,
but
obviously
with
the
checksum
off.
It
means,
of
course,
that
we
can't
absolutely
guarantee
things,
there's
always
an
element
of
what's
the
word,
and
things
could
be
wrong,
it
might
be
a
bit.
You
know
one
or
two
bit
errors
saying
but
getting
into
the
check.
A
So
my
thing
was
a
fine
and
a
worthy
thing
to
do.
I've
got
no
issues
with
that
whatsoever
and,
and
so
looking
at
this,
and
because
he
was
dropping
out
from
time
to
time,
it's
not
every
over.
Not
not
it's
not
that
bad
by
any
means,
but
you
know
it
was.
There
was
a
certain
amount
of
ambiguity
there,
and
so
I
thought
one
of
the
best
ways
to
do
this.
A
A
The
idea
is
that
the
different
type
is
set
so
that,
if
anybody
happens
to
decode
that
message
on
its
own,
without
seeing
it
in
context
when
it's
decoded,
they
can
see
it's
an
end
of
message.
So
they
don't
start
saying.
Oh,
this
is
the
beginning
of
a
message,
because
it's
the
same
format,
so
the
actual
type
is
there
for
random
listeners
as
much
as
anything
else
as
the
receiving
station
receiving
the
stream
of
data.
A
It
is
possible
to
correlate
that
sync
and
if
the
sync
is
the
same
sync
as
a
header-
and
it
follows
in
the
stream
at
the
right
time
more
to
the
point
after
the
audio,
then
it's
actually
a
very
easy
decision,
then
to
make
to
say
that
is
the
end.
Now,
if
you
do
correlation,
my
experience
is
that
correlation
is
capable
of
correctly
decoding
symbols
at
a
level
below
which
audio
is
actually
broken.
In
almost
every
format,
I've
worked
with,
so
it
is
very
powerful
and
can
even
when
things
are
with
a
very
high
ber
that.
A
Will
still
indicate
the
end
of
a
transmission,
so
at
least
you
can
stop
and
move
on
to
the
next
person
or
whatever,
so
that
so.
That
is
why
I
am
very
much
in
favor
of
having
an
explicit
end
of
end
of
transmission
marker
based
on
a
repetition
of
the
header,
but
with
a
different
type
in
it
as
a
receiving
station.
You
don't
actually
need
to
decode
that
header
that's
actually
fairly
unimportant.
What
is
important
is
the
synchronization
a
vector,
I
don't
think
I've
expressed
myself
particularly
well,
but
that
is
my
thinking
behind
it.
A
D
Okay,
thank
you,
and
I
know
you
just
said
that
you
didn't
express
it
very
well.
I
think
I
understood
what
you
were
talking
about
there.
There
are
a
number
of
other
protocols
that
also
use
this
explicit.
You
know
start
end
of
stream
and
especially
for
voice
communications
or
asynchronous
communications.
This
is
this
is
widely
used.
D
There
are
other
framed
communications
protocols
that
don't
what
they
do
is
they
have
all
the
information
about
the
rest
of
the
the
payload
in
the
header
only
but
those
are
ones
that
are
deterministic
in
length,
and
so
the
thing
that
occurs
to
me
is
that
we're
assuming
that
m17
is.
You
know
this.
Their
streams
are
going
to
be
asynchronous
they're
going
to
be
at
various
lengths
and
that
this
sort
of
thing
really
has
to
to
kind
of
get
some
attention.
Would
that
would
that
be
fair
to
say,
okay,.
A
D
A
D
A
D
A
The
protocol
as
it
stands
is,
is
for
the
most
part
I
mean
I
I
could
argue
about
one
or
two
other
things
nip.
I
really
can't
be
bothered
to
be
perfectly
honest.
The
protocol
as
it
stands
is
pretty
good
and,
to
my
mind,
that
is
a
weak
point
and,
for
example,
if
you
want
to
actually
move
it
into
the
commercial
world,
which
is
not
not
my
interest,
because
it
raises
interesting
problems
with
some
of
the
stuff
I've
worked
with,
including
commercially
at
work.
D
C
So
my
thought
was
you
really
could
not
look
at
a
that?
Sync
word
and
just
say:
oh,
I
can
drop
this.
My
implementation
has
to
look
at
the
next
sync
word
to
figure
out.
You
know
once
it
sees
a
link
status
frame,
it
expects
to
see
a
another
stream
sync.
It
expects
to
be
able
to
decode
that,
first
of
all,
because
it's
got
to
know
what
to
expect
next,
and
I
think
that's
where
you
know
our
assumptions
about
what
we
can
do
with
this
protocol
differ.
C
So
I
think
this
is.
This
has
been
really
helpful
to
have
this
conversation,
because
now
we
can
kind
of
talk
about
that
and
whether
or
not
which
of
our
assumptions
really
are,
are
the
makes
sense
and
are
correct,
or
if
we
do,
I
mean
I
think
it's
it's
obvious
that
we
have
a
a
a
we
kind
of
disagree
on
what
would
happen
with
in
that
case.
So
we
have
to
decide
whether
or
not
it
is
feasible
or
reasonable
to
expect
data
to
immediately
follow
us,
a
stream
in
that
manner.
A
Sorry
go
ahead:
jonathan
yeah,
I
must
admit
packet
mode
in
itself,
doesn't
actually
interest
me.
I've
actually
just
taken
it
out
of
my
hotspot
implementation.
You
may
have
seen
me
mention
that,
because,
as
far
as
my
work
is
concerned,
I
don't
see
how
that
sort
of
fits
in
I'd
be
interested
in
that
conversation
about
switching
between
most,
but
I
really
do
think
it
is
actually
a
very
mature
minority
thing.
Don't
forget
just
because
you
see
the
end,
we
call
it
the
nsync.
Sorry,
the
header
sync
type
appearing
at
the
end.
A
Don't
forget
you
can
actually
look
at
the
type,
hopefully
it'll
decode
you
can.
You
know
when
the
fec
check
do
the
checksum,
and
in
that
case
you
could
actually
explicitly
check
the
type
to
go.
Oh,
is
this
an
end
marker,
or
does
this
mean?
Something
else
is
going
to
happen
now
as
a
pure
digital
voice
implementation?
I
would
probably
look
at
it
and
go
unless
it's
more
digital
voice.
Then
I'm
not
going
to
be
interested
anyway.
A
So
I'll
just
drop
it
and
do
an
end
of
stream
marker,
but
so
there
is
a
type
associated
with
it.
Obviously,
if
you
can't,
if
the
fec
is
too
badly
corrupted
and
we
can't
get
data,
then
we
then
have
to
make
a
decision,
and
my
decision
would
be
probably
since,
since
I've
seen
the
header
I'd,
probably
drop
it
and
in
theory
it
will
come
back
in
again
anyway
due
course
you
know
actually
a
few
hundred
milliseconds
later,
but
yeah,
I'm
not
sure
what
else
can
say
about
that.
To
be
honest,.
E
I
can
add
something
please,
okay,
so
if
jonathan
wants
to
use
an
lsf
frame
to
indicate
the
end
of
the
stream,
keep
in
mind
that
the
lsf
is
more
heavily
punctured
convolutional
code
than
the
voice,
packets
right
rob,
that's
correct.
I
think,
and
you
want
to
use
one
bit
of
the
type
which
is
more
prone
to
errors
than
using
a
voice
packet
and
using
even
one
bit
of
the.
A
A
No,
no,
not
necessarily,
I
would
actually
just
look
at
the
the
sync
factor,
because,
by
definition
the
scene
vector
is
is
has
complete
negative
correlation
with
the
stream.
When
I,
when
I
gave
you
those
new
sync
words,
I
was
very
careful
about
it.
The
sync
word
for
the
header
is
the
exact
opposite
of
a
stream
sync
word,
so
there
can
certainly
never
be
a
confusion
there
ever
ever.
So,
therefore,
it's
a
case
that
that
would
actually
the
way
I'm
proposing
is
a
very
sensitive
way
of
detecting
the
end
of
stream.
A
Yes,
you
can
actually
look
at
the
contents
of
that
header,
if
you
so
need,
but
you
don't
need
to
necessarily
that
the
reason
you
have
the
contents
of
the
header
saying
this
is
the
end
of
the
stream
is
in
case
the
repeater
accidentally
picks
up
just
the
end
frame.
You
know
because
of
interference
whatever,
and
you
can
look
at
it
and
go.
Oh
I've
got
a
header.
Is
this
the
beginning
of
something
and
you
can
look
at
it
and
go?
A
E
E
A
No,
it's
not
a
stupid
question
that
is
actually
similar
to
what
d-star
does.
I
was
going
to
mention
that,
but
I
couldn't
be
bothered
to
type
it
in
an
alternative
way
to
do
it,
and
this
is
exactly
what
d-star
does
and
for
all
its
faults.
D-Star
is
not
a
bad
protocol.
What
it
does
do
is
it
actually
has
a
unique
sync
thing,
which
is
actually
much
longer
than
a
normal
sync.
Normal
syncing
d
starts
quite
short,
it's
gmsk.
A
A
Does
it
does
seem
to
work
pretty
well
actually,
so
that
is
actually
an
option
which
I
did
consider
and
I
didn't
document,
because
simply
because
the
only
way
I
access
discord
is
to
find
my
mobile
phone,
and
I
really
can't
bother
to
type
that
much
in
it's
not
ideal.
I
don't
have
it
on
my
laptop,
for
example.
C
I
mean
I,
I
completely
agree
that
having
a
a
sync
word
as
a
end
of
stream
indicator
is
a
is
a
good
way
to
do
that
because,
as
jonathan
mentioned,
it
is
a
very
clear
indicator
and
lsu
the
the
the
the
header
sync
word
is:
is
the
perfect
one
to
use
there?
The
I
think
from
par
part
of
the
issue
is
like
I
haven't
experienced
the
the
the
problems
that
jonathan
has.
C
A
E
A
Idea
is
you
know,
it's
got
hysteresis,
so
you've
got
to
be
really
good
to
get
in.
However,
once
you're
into
the
system,
it
drops
those
requirements
slightly.
It
allows
a
certain
amount
of
errors
on
your
synchronization,
because
that's
what
life's
like
you
do,
you
know
miss
bits
for
whatever
reason
and
and
it
will
providing
your
sinks
are
above
a
certain
threshold
of
goodness,
which
is
not
perfect.
You
will
stay
in
the
system
if
you
drop
below
that.
A
I
think
it
gives
you
a
leeway
of,
I
think
three
more
sinks
before
it
declares
you
gone
and
then
sends
a
message
to
the
the
host
saying
this
transmission
is
gone
and
you
go
back
to
square
one
waiting
for
somebody
to
come
back
in,
however,
which
way
so
that's
how
I
do
it.
I
think
it's,
I
think
it's
three
sinks
I
allowed
to
lose,
which
is
120
milliseconds.
Maybe
I
should
make
it
a
bit
longer.
A
I
don't
know,
but
that's
how
I
do
it
and
of
course,
when
you
go
back
to
zero,
then
you
have
to
have
a
perfect
sink
again
to
get
back
into
the
system
so
that
it
doesn't
trigger
and
spend
time
trying
to
decode
stuff.
That's
mostly
rubbish,
but
allows
the
fact
that
once
you're
in
the
system,
you
may
be
less
than
perfect,
and
I
have
found
that
on
other
modes
to
be
a
pretty
good
way
of
doing
things,
because
you
can't
guarantee
things,
look
good,
all
the
time
mobile,
flutter
or
whatever.
C
Gotcha
yeah,
I
think
the
issue
you
know
one
one
of
the
reasons
that
it,
the
idea
of
using
a
link
setup
frame,
was
problematic.
For
me,
is
it
would
it
would
affect
the
state
machine
that
I
currently
have,
which
does
expect?
You
know
a
linked
setup
frame
to
be
priest
to
precede
some
other
information
right
and
the
other.
The
other
thing
is
that,
as
vojtech
mentioned,
because
of
that
I
would
need
to
decode
the
frame
to
know
what's
going
to
follow
right.
C
Yes,
the
assumption
is
the
there
is
following
data,
and
so,
if
we,
I
think
we
need
to
come
up
with
at
this
point,
we're
in
agreement
about
what
needs
to
happen.
We
just
need
to
work
out
the
details
right
on
on
how
do
we?
How
do
we
end
end
the
sequence
using
a
sync
word
and
some
other
information
now,
if
we
just
did
a,
I,
I
actually
like
the
suggestion
of
doing
a
full
frame
of
header
sinks.
A
A
C
A
Unused
one
yeah,
I
see
why
not
I
mean
those
essentially
there's
four
yeah,
which
I
created.
The
two
we're
using
are
opposites
of
each
other
yeah
on
purpose.
Dmr
does
the
same
trick
system.
Fusion
definitely
does
not
it's
rubbish.
That
is,
and
the
oh
stories
about
the
system,
fusion,
it's
so
weak
and
the
other
two
are
actually
just
bit.
Reversals
are
the
first
ones
yeah,
but
they
are
a
negative
correlation
to
each
other
same
thing.
I've
got
no
issues
with
that
whatsoever.
A
I'm
just
want
to
see
something
stronger
than
using
that
bit
having
a
having
something,
that's
say,
completely
left
field
that
has
no
other
meaning
within
the
protocol.
For
example,
like
you
know,
a
completely
different
sync
bit,
sync
sync
pattern:
sorry
that
that
to
me
fulfills
everything
I'd
like
to
see
because
that's
cannot
be
confused
with
anything
excuse
me
but
yeah
using
that
one,
but
you
want
to
use
that
for
better
rate
testing.
A
A
Maybe
I
don't
know
but
say
we
we
don't.
We
don't
have
to
be
limited
to
that,
at
least
in
my
implementation
on
the
modem,
I'm
you
know
I
can
sniff
all
sorts
of
synchronizations,
I'm
not
limited
to
that
length,
so
I
can
actually
have
that
running
in
parallel
and
it'll.
Look
at
it
and
go
okay,
I'm
checking
these
for
eight
symbols
and
I'm
checking
this
one
for
32
symbols.
That's
not
a
problem!
A
A
A
Yeah,
I
obviously
have
to
do
some
research
wikipedia
is
my
friend
yeah.
I
mean
it
depends
on
how
long
you
want
it
to
be.
It
doesn't
need
to
be
40
milliseconds
long
as
far
as
I'm
concerned,
but
I'm
thinking
purely
in
terms
of
dv,
because
the
idea
is
it's
going
to
be
fresh
air,
your
transmitter
is
going
to
go
off,
and
so
therefore
it
doesn't
matter
if
it's
not
a
full
40
milliseconds.
C
Yeah,
I
think
the
the
main
thing
is
that
it's
not
easily
confused
with
one
of
the
additional
sync
words
right.
I
think
that's
the
that's
the
real,
the
real
challenge,
with
only
eight
bits
that
we
have
and
those
codes
that
you
proposed,
I
think
are
are
perfect,
but
we
have
eight
of
them
and
it's
it's.
C
A
The
problem
is,
if
you
change
only
one
or
two
bits,
it
can
be
just
be
seen
as
corruption.
Yes,
absolutely
that's
one
of
the
reasons
I
suggest
it
after
the
original
ones,
which
only
had
like
one
bit
difference,
and
I
thought
you
know
in
the
real
world
that
that
can
happen
very
very
easily
and
you'll
just
get
confused.
So
we
have
to
and
say
I
got
the
idea
from
dmr
where
they
literally
have
negative
correlation
between
the
two
like
we
have.
They
can
never
ever
be
misinterpreted.
D
D
A
Yeah,
I
need
to
find
something
suitable
and
then
obviously
we
need
to
discuss
this.
I've
already
got
a
branch
of
my
code
that
does
this
the
new.
I
call
it
eof.
It's
easy
enough
to
change
that
to
support
it.
Obviously,
I
need
to
change
the
modem
firmware
as
well,
which
is
a
bit
of
pain,
but
so
well.
Yeah.
D
Yeah
I
do,
I
want
to
talk
about
bit
error
rates
having
a
little
bit
of
bias
in
this
particular
direction,
to
get
some
really
good
visibility
supported
as
early
as
possible
and
strictly
not
a
protocol
change,
at
least
not
by
my
way
of
thinking.
So
so
tell
me
tell
me
where
I
can
help
and
to
get
really
good
visibility
going
for
the
future.
D
We
have
a
future
path
coming
up
pretty
quickly
for
silicon,
and
the
expectations
are
are
going
to
be
pretty
high
for
their
for
validation
and
verification,
so
anything
that
we
can
do
now
support
from
from
development
pretty
pretty
necessary
for
that
to
happen
without
a
lot
of
cram
and
last
minute,
pain
and
and
and
work.
So
so
let
me
know
what
I
need
to
know.
C
It's
it's
probably
it's
I'm
sure
not
perfect.
It's
it's
working
well
for
me,
but
I
was
hoping
to
get.
You
know,
feedback
on
what
works,
what
doesn't
and
and
what's
the
right
way
forward,
because
I
don't
have
a
lot
of
experience
with
with
that.
I
do
know
that
you
know
none
of
the
test
equipment
that
I
have
is
gonna.
You
know
construct
a
a
m17
frame
for
me
and
inject.
You
know
pseudorandomized
data
into
it.
C
It'll
generate
pseudo
randomized
data,
but
I'm
not
going
to
be
able
to
make
sense
of
it,
because
it's
not
in
any
frame
format,
so
having
a
frame
format
and-
and
I
chose
a
a
puncture
matrix
that
matches
our
our
stream
payload,
because
that
to
me
made
the
most
sense
there
are
other.
We
could
certainly
try
other
function
matrices,
but
you
know
I'm
looking
for
feedback
on
on
those
sort
of
and
that
aspect
of
the
proposal.
C
Jonathan's
provided
good
feedback.
I
mean
the
initial
proposal
had
a
header
frame
in
there
and
that's
certainly
not
needed.
It's
certainly
not
wanted
for
for
bit
error
rate
testing
right,
but
but
something
you
know
some
standard
is
needed
because
we
are
going
to
have
soon
a
lot
of
pieces
of
equipment
around
and
it
would
be
good
to
test
against
each
other
or
at
least
have
some
standard
test
suite
that
we
can
just
point
at
a
device
and
say
how
well
is
this
working.
D
A
A
I
have
done
this
on
different
modes
record,
a
load
of
audio,
maybe
off
the
friday
night
net
and
just
replay
it
back
through
over
and
over
again
as
a
source
of
genuine
m17
audio
and
then
measure
the
ber
against
that,
because
you
know
that
that
is
authentic.
If
you
know
to
me
with
the
correct
puncturing,
you
know
it's
real
world
data.
A
A
So
I
personally
would
rather
spend
my
time
at
the
moment
adding
richness
to
the
client,
for
example
like
gps
data,
and
things
like
that,
which
we've
talked
about
and
see
if
we
can
get
that
through
yeah.
So
I'm
actually
more
interested
in
doing
that,
rather
than
be
asked
of
which
I
can
say,
I
can
read
down
my
logs
anyway,.
D
D
If
there
is
anything
that
we
find
and
the
goal
is
to
not
find
anything
by
doing
these
tests,
the
goal
is
to
confirm
that
the
all
these
choices
that
we've
made
and
talked
about
over
over
over
time
have
been
good
ones,
and
you
see
evidence
of
the
solid
engineering.
So
that's
the
goal,
and
and
as
a
raging
optimist,
my
expectation,
you
know,
but
the
the
testing,
the
sorts
of
sorts
of
testing
protocol,
testing
and
injection,
and
things
like
that.
D
If
it
does
reveal
something
well,
then
good
and
we'll
know
we'll
know
what
to
improve,
and
those
two
things
are
are
are
not
they
do
not
get
in
each
other's
way.
So
please
please
proceed
with
the
things
that
you're
motivated
and
inspired
to
do,
and
I'll
I'll
probably
be
talking
to
rob
a
little
bit
more
about
this.
D
C
D
C
A
I've
only
just
come
back.
I
was
at
my
girlfriends
until
a
few
hours
ago,
so
I
didn't
like.
Oh
very,
very
nice.
Thank
you,
but
I
did
say
I
wasn't
around
until
sunday
afternoon,
so
I
I
just
haven't
followed
it
up.
I'd
like
to
know
what
the
rationale
is.
I've
got
no
issue
with
it.
I'd
just
like
to
know
what
the
rationale
is
for
changing
it,
and
so.
C
I
think
the
rationale
was
at
the
time
that
if
you
looked
at
the
puncture
matrix,
there
were
a
lot
of
it
was
not
evenly
punctured.
So
there
were
places
where
there
was
a
lot
of
puncturing
in
the
in
the
bit
stream,
and
then
there
are
places
where
there
was
none
right.
So
there
were
six
runs
of
six
bits
that
were
not
punctured
and
and
two
bits
followed
by
a
puncture
two
bits
followed
by
puncture
and
that
seemed
like.
A
E
So
if
I'm,
if
I
may,
I
think
the
the
new
puncturing
pattern
is
the
p1,
because
we've
got
a
different
puncturing
pattern
for
the
lsf
and
for
the
voice
frames
so
for
voice
frames.
It's
an
easy
task,
because
we
only
eradicate
one
bit
per
12
bits
of
input.
So
that's
easy
and
that's
already
optimal
and
for
the
p1
pattern.
There
is
an
uneven
number
of
bits
coming
in
and
we
have
to
puncture
out
some
of
them
and
end
up
with
46,
I
believe
so.
Taking
an
input
input
of
61.
E
E
C
Yeah
I
mean
I
don't
know
how
much
more
needs
to
be
explained.
It
was
just
the
closest
we
could
get
with
the
odd
number
of
bits
that
we
had
to
to
an
even
two-thirds
puncture
matrix.
It
seems
to
work,
it
seems
to
work
fine.
My
my
only
concern
is.
We
now
have
some
interoperable
systems
right,
and
so
this
is
a
back
where
this
is
a
breaking
change.
D
C
A
At
this
moment
in
time
is
a
time
like
the
end
of
end
of
message.
This
is
the
time
to
do
it.
No,
no
later
I
mean
there
may
be
a
period
of
time
when,
for
example,
my
stuff
won't
talk
to
your
stuff,
but
it
probably
won't
be
for
very
long
to
be
perfectly
honest
when
you
get
your
firmware
out
so
yeah
I'm,
I
could
probably
if
I
can
see
the
function
matrix
and
the
term
way
that
I
understand
it.
I
could
do
it
tonight.
D
A
D
A
Yeah,
I
don't
think
you
know
by
the
time
this
stuff
sort
of
filters
through,
because
people
know
that
my
my
code
updates
on
a
daily
basis,
it's
famous
for
that,
so
anybody
who's
on
the
blue
and
bear
my
m17
is
in
my
beta
version.
It's
not
in
the
full
release
version
still,
and
so
people
following
that
will
be
building
their
own
software
and
will
be
updating
regularly.
So
you
know,
as
soon
as
I've
announced
on
opendv
saying,
look
if
you're
doing
this
grab
the
latest,
but
make
sure
you
update
everything
to
the
latest
people.
A
A
A
A
I've
got
okay,
I
can
play
it
that
hang
on
yeah.
This
is
this
is
what
I
don't
support,
because
you'll
see
that
this
is
the
latest
repeater
builder
beta.
There
is
an
i2c
display.
The
idea
is
instead
of
having
lots
of
leds
along
which
is
quite
common.
It's
the
idea
is
to
have
that
little
display,
saying
m17
or
dmr
or
whatever.
D
D
A
C
A
F
A
Yeah
I
found
a
I
found
a
hell
of
a
bug
in
there.
My
mistake
for
putting
packet
mode
in
which
I
took
out
and
found
out
that
packet
mode
was
matching
with
the
stream
sink,
not
the
packet
sink,
so
that
anything
stream
came
out
as
packet,
which
is
no
longer
handled
it
wasn't
handled
to
properly
anyway.
So
that
was
easy.
I.