-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sub-microsecond ADC delays are dropped without notification when exporting to .seq file #191
Comments
Hi @jweine. As Siemens interpreter also uses microsecond for that delay, as you said this will be consistent with Siemens convention. In Siemens, as the time is an integer, that We may be able to add a check and print a warning if the difference after integer cast is larger than |
The functionality to check the timing of your sequence already exists: ok, error_report = seq.check_timing()
if ok:
print("Timing check passed successfully")
else:
print("Timing check failed. Error listing follows:")
[print(e) for e in error_report] This works for any timing related value, e.g. gradient timing as well. You should really always use this. It might make sense for I did notice there's a little bug in I've not been happy about the way to print the report, it would make sense to either just print a report with nicer formatting indicating where the errors are, or to return a data structure that lists the specific errors (not as a string, e.g. a list of |
I did not realize I realized that it also assumes pypulseq/pypulseq/check_timing.py Lines 58 to 59 in 25938e8
A dict is also awesome if one wants to easily search for certain events in a spam of errors. |
I believe the answers and #200 addresses the issue. Closing. |
When adding ADC events that are starting on a valid time according to the adc-raster time but is smaller than a micro second the delay is simply dropped when exported to a .seq file.
This consistent with the file
in section 2.8.3, as the table states delays are specified in integers of microseconds.
Below I have a minimally working example that creates a readout trapezoidal and a corresponding ADC from a number of samples and a flat-duration. To obtain a valid dwell time, the actual ADC duration is recomputed to be slighlty shorter, and subsequently the adc is shifted to be centered with respect to the flat-top duration.
Expected behaviour
I suspect severity of this depends on the choses raster_times, and in most cases with the default siemens raster times the differences might be neglegible. However, a Userwarning that states that this conversion is happening might be a good idea, so the user can choose e.g. a different number of samples or delibarately choose to ignore this difference.
To Reproduce
Which results in the following file, stating a 4us delay instead of a 3.9us delay.
The text was updated successfully, but these errors were encountered: