Add support for extended block lengths #914
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cedure internally.
for more information, see https://pre-commit.ci
…port for hexadecimal digit for extended block lengths
… into extended-block-length
for more information, see https://pre-commit.ci
|
Initial PR also broke IEEE block writes, which I'd forgotten I modified in the beginning. I added a new commit that fixes and added support for the header length going into hexadecimal when block is ≥1 GB for block writes. Tested normal functionality works by uploading an arb to my waveform generator, but I don't have anything with enough memory to test the hexadecimal digit. |
… into extended-block-length
for more information, see https://pre-commit.ci
|
I've added support for writes in the R&S format using |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the following:
parse_ieee_block_headernow supports decoding blocks ≥ 1 GB using hexadecimal length digit (Tektronix/LeCroy)parse_rs_block_headersupports decoding blocks ≥ 1 GB using parentheses-delimited length (Rohde & Schwarz)header_fmt = "rs"option added toread/query_binary_values(). Internally this first calls the functionparse_ieee_or_rs_block_header, which detects whether the block length begins with a parentheses and then calls theieeeorrsparser as appropriate. This implementation is used because R&S only uses this format when the block length exceeds 1 GB, so it's best to use automatic detection rather than need to have the user explicitly know whether it is using the parentheses format or notlength_before_blockandraise_on_late_blockoptions to the user interface ofread/query_binary_values(), to allow user to set these values. Previously these were not accessible by the user, and always set to 25 and False. Some Tektronix scopes can return trace metadata in ASCII in front of the block data (before the block header) so a late block header >25 bytes can be expected, but previously it will always raise a warning :In future it will be useful to add some way of retrieving this message in front of the block header (currently it is thrown away) but that is not included in this PR.
As a note, since the
header_fmt = rsoption in this implementation will interpret both IEEE (including the hex digit extension) and RS formatted blocks, it is somewhat "universal" for definite-length blocks, but doesn't detect indefinite length blocks if they happen to start with"(". The R&S format is only used for definite length blocks so I didn't think this would be a concern. But the user should be careful not to specifyheader_fmt = rsif an indefinite block is expected.For the hex extension, I added a check to make sure the block length makes sense if the digit is 0xA to detect if an HP block is being decoded with the IEEE parser (the block length should be much more than 64K if there are 0xA = 10 digits, if it's not then it must have been an HP block, and an exception is raised with a descriptive message). But I don't have a way of testing this since I don't have any instruments that return blocks in HP format.
I tested that the R&S block decoding works, and the regular IEEE block decoding also still works.
ruff check . && ruff format -c . --checkwith no errors