OpenwaterHealth / OpenwaterHealth/openlifu-python
Resolve Trigger-to-Pulse-Start Delay
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 27
- Forks
- 21
- Avg merge
- 1d 20m
- Merged PRs (30d)
- 6
Description
There is a ~125us delay between the application of the TR_BF_SYNC pulse provided by TRIGGER to the TX7332s and the initiation of output. When using Elastic Mode in the TX7332, the duration of the pulse is not timed from the initiation of the output, but from the trigger itself, resulting in pulses that are 125us shorter than expected. An adjustment when using Elastic Mode to account for this delay is included in a4875d36b028132f8d916d5adcf3d1bfed0069de, but this sort of "Magic Number" is not a good long term solution, and we should identify the source of the delay. There is an expected delay of 8 × TX_START_DEL +121 (= TX_DEL) BF_CLK periods, but at a BF_CLK = 10MHz and TX_START_DEL=0, this is only expected to be 12.1 us, not 125us.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with commit a4875d36b028132f8d916d5adcf3d1bfed0069de and trace the Elastic Mode trigger-to-output path for the TX7332. Compare the measured ~125us delay with the expected 8 × TX_START_DEL + 121 BF_CLK periods at 10MHz. Done means identifying the source of the discrepancy and replacing the magic-number adjustment with a justified solution.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100