TX FIFO under/overflow indication
167 views
Skip to first unread message
"Christoph v. Wüllen"
Feb 24, 2021, 12:45:15 PM2/24/21
to herme...@googlegroups.com
Dear all,
I am implementing to display the TX FIFO underflow/overflow condition
in the piHPSDR TX panadapter. Every time such a condition occurs,
it is displayed for two second in red.
The problem is that „Underrun“ is now displayed after EACH rx/tx
transition for 2 seconds, and the reason is that the HL2
firmware reports „underflow“ as long as the fifo is empty.
Upon RX, the TX fifo is reported to be empty (correct) and
the underflow condition is reported (wrong), and after the
RX/TX transition the underflow condition is reported until
the first burst of data is filled into the TX fifo queue.
Of course I can ignore the underflow/overflow bits in the
first half dozen packets received from the HL2 after a
RX-TX transition, but wouln’t it be more logical when
the firmware reports the underflow only when the FIFO
queue is actually drained, so goes from 1 to 0 samples,
or is this either wrong or too complicated to implement
in the firmware?
The reason for my doing so is to get a diagnostic into
the much-discussed „TX latency“ topic.
Yours, Christoph DL1YCF.
I am implementing to display the TX FIFO underflow/overflow condition
in the piHPSDR TX panadapter. Every time such a condition occurs,
it is displayed for two second in red.
The problem is that „Underrun“ is now displayed after EACH rx/tx
transition for 2 seconds, and the reason is that the HL2
firmware reports „underflow“ as long as the fifo is empty.
Upon RX, the TX fifo is reported to be empty (correct) and
the underflow condition is reported (wrong), and after the
RX/TX transition the underflow condition is reported until
the first burst of data is filled into the TX fifo queue.
Of course I can ignore the underflow/overflow bits in the
first half dozen packets received from the HL2 after a
RX-TX transition, but wouln’t it be more logical when
the firmware reports the underflow only when the FIFO
queue is actually drained, so goes from 1 to 0 samples,
or is this either wrong or too complicated to implement
in the firmware?
The reason for my doing so is to get a diagnostic into
the much-discussed „TX latency“ topic.
Yours, Christoph DL1YCF.
Matthew
Feb 24, 2021, 2:44:49 PM2/24/21
to Hermes-Lite
My guess is it would be too complicated to implement in gateware.
If you know the set buffer size you can calculate/set how many reports to ignore during rx to tx transition. I used this method when I was trying to dynamically size the buffer. But I lost interest in this approach.
73 Matthew M5EVT.
Steve Haynal
Feb 26, 2021, 1:38:48 AM2/26/21
to Hermes-Lite
Hi Christoph,
I'd rather change the documentation of these flags to mean FIFO is full or FIFO is empty as that is easier in the gateware. Also, other software expects it to work as it currently does.
Last November I created a gateware variant plus external software to debug problems with the TX buffer. If people see issue, this is the tool I'd like them to use and share results from. You can find the thread here:
73,
Steve
kf7o
Reply all
Reply to author
Forward
0 new messages