Examples of how to assess and change transmit pulse and receive signal timing in the DLITE0100A1 firmware. This is a “flash” post: very quick, draft. You can also probe signals, both digital and analog, at various points on the hardware to get a real-world assessment. Nominally, the Rx Delay implementation has an offset and scale for mapping its accuracy, depending on your use-case. You can adjust as needed.
Summary
For the stock legacy firmware, the following use-cases were set up for different scenarios:
- Set Rx Delay to zero, by design:
- Invokes functions that start the receive capture timer one instruction cycle prior to initiating the transmit pulse.
- Set Rx Delay to a positive value, within range, greater than zero, by design:
- Invokes functions that start the receive capture timer AFTER the pulse and pulse-damping (RTZ = return to zero) durations are complete, plus nominally a one or a few machine instruction cycles for maintenance, introducing an offset to the receive delay setting that depends on your particular settings.
- Default pulse and RTZ duration settings are shown below. Nominally, 8 + 7 clock cycles, respectively, plus instruction cycle overhead and intentionally inserted “nop”s.
- DSP/MCU runs at a nominal 35MHz.
- Rx Delay function is implemented in the Delay_us function. It may be close, but not exact depending on overhead. The assembly code would provide an exact answer, as would probing board signals.
All of this behavior can be changed to suit particular needs by simply updating the firmware functions. You will see there was, and is room for, lots of experimentation to look at particular things. You could set the firmware up to support negative Rx Delay such that you could capture more time before the pulse begins, or change when the capture is initiated in all cases such that you always have the same baseline. It just depends on your needs and use-cases.
If you’d like more details and exact instruction cycle delays for your use-cases, just let me know.
Code Screenshots
