search

Abraxas3d / pluto-msk-application

C-code application for the PLUTO MSK implementation
1 stars 0 forks source link

Difference in bit count between success loop and 50% error loop #7

Open Abraxas3d opened 4 hours ago

Abraxas3d commented 4 hours ago 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
100 buckets of bits on the bus, 100 buckets of bits.
(2) Total PRBS_BIT_COUNT:   (0x0000de2c@0050)
(2) Total PRBS_ERROR_COUNT: (0x00000000@0054)
(2) 0.0 -586825 401317 0x01000000
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
100 (or more) buckets of bits on the bus.
(1) Total PRBS_BIT_COUNT:   (0x000d1abd@0050)
(1) Total PRBS_ERROR_COUNT: (0x00068f2e@0054)
(1) 50.0 -262210209 308963162 0x01000000
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Abraxas3d commented 4 hours ago

These seems impossible.

mwishek commented 3 hours ago

I assume that the both cases are allowed to run for a similar duration, such that we would expect bit counts to be more the same order of magnitude. If so. Then yes this would be unexpected, and should be impossible.

Considering the ILA triggering, it might be useful to either create a new register bit to trigger the ILA, or select several existing control bits so that we can see the state of the system around these reads.

mwishek commented 1 hour ago

As I suggested in the Slack chat, this actually isn't impossible, and makes sense if it is a result of the Costas loops not being locked.

The recovered bit clock/rate is derived from both Costas loops. If one or both loops aren't locked, the math that recovers the bit-clock could result in an unexpectedly high (and possibly low) recovered bit-rate. To be sure, the actual bit rate isn't being recovered, and the recovered bit rate is effectively noise.

This also shows the need for a lock detector. If the loops aren't locked the recovered bit clock and bits should be ignored.