The 20:30 message from IZ7SLZ:

found rank 0: GE PAUL TNX RPRT  ps [  1  180  180  180  180]
re-encode 296/1040 ber 2.85e-01  Es/N0=-7.9 Eb/N0=2.4 effrate=1/10.83

In this case, the initial reference phase was good.

Bit clock is lagging 45 mS on this one.

In answer to an earlier question from Andy, there's no
facility in the decoder to search for the correct bit clock
offset, or frequency offset for that matter.

(I think Markus has some tools he's put together to help
with that).

I just do trial and error.   I assume that it's fairly
easy to set a PC clock to within 50mS with ntpd, even
on Windows.   If you have a DSL line which isn't too
asymmetric, you can use an Internet time server and
get within 50mS.  This mode really requires sender and
receiver to make sure their bit clock and RF frequency
are exact enough.  EbNaut signals don't include any sort
of pattern that the receiver can use to synchronise with
it - that costs far too many dBs.  It's cheaper to
install ntpd than to double your tx power.

The reason for the time offset parameter really is to allow
you to start recording early so that blankers can settle,
etc.  And the frequency offset is to accommodate say a DDS
that doesn't do the exact frequency, or a rubidium offset.

It's a last resort if you have to be guessing offsets
to find a decode.  It means you're covering up for a fault.

Markus just wrote:
> same here when using the show_rawsyms3a utility. The peak
> in the skyblue spectrum-of-squares  will conveniently
> guide you to the correct frequency and time offset if
> Eb/N0 is above 4 dB or so.

And also the constellation plot is just a blob below 3 or 4dB,
with no discernible axis to hint of a reference phase.  When
you look at it, it's remarkable that anything can be decoded
from it.

21:00 message not decoded, Domenico are you QRT now?
I will be soon but the rx carries on recording.
--
Paul Nicholson
--