OpenwaterHealth / OpenwaterHealth/openlifu-python

Resolve Trigger-to-Pulse-Start Delay

Open
#351 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.