During testing I have seen that sometimes Longmynd will output a
very small (a few bytes) UDP packet that only contains the beginning of
the BBHEADER of a BBFRAME. This matches what happens with the FT2232H
USB interface: the corresponding bulk transfer only carries a few
bytes.
Most likely this is caused by the bulk transfer being timed such it is
executed very shortly after the STV0910 begins to output a BBFRAME. In
this case the FT2232H FIFO would only contain the first few bytes of the
BBFRAME.
This fixes the problem by reading multiple UDP packets if necessary,
until enough data for a full BBHEADER has been collected. The BBHEADER
is then validated as usual.
I have tested that a ping -s 1450 -i 0.01 with IPv6 on a 1 Msym/s QPSK 1/2
normal FECFRAME no pilots link (which achieves occupancy of ~70%)
doesn't lose any packets after this change. There are no drops or decode
errors while streaming audio either.
During testing I have seen that sometimes Longmynd will output a very small (a few bytes) UDP packet that only contains the beginning of the BBHEADER of a BBFRAME. This matches what happens with the FT2232H USB interface: the corresponding bulk transfer only carries a few bytes.
Most likely this is caused by the bulk transfer being timed such it is executed very shortly after the STV0910 begins to output a BBFRAME. In this case the FT2232H FIFO would only contain the first few bytes of the BBFRAME.
This fixes the problem by reading multiple UDP packets if necessary, until enough data for a full BBHEADER has been collected. The BBHEADER is then validated as usual.
I have tested that a ping -s 1450 -i 0.01 with IPv6 on a 1 Msym/s QPSK 1/2 normal FECFRAME no pilots link (which achieves occupancy of ~70%) doesn't lose any packets after this change. There are no drops or decode errors while streaming audio either.