Improperly Reading Header

[BlueNalgene]

I had some high hopes for your code as a way to simplify OPUS processing while retaining Linux compatibility for large batch jobs, however I ran into a snag while testing the program. Spectragryph loads the files just fine, so there may be something silly the Python script is stumbling on. When I try to read a file from my instrument, Python kicks back a Key Error.

First, some housekeeping:

• Python v3.8.10
• brukeropusreader version: 1.3 (from pip3)
• OS/Kernel: Ubuntu 20.04 focal/x86_64 Linux 5.11.0-40-generic
• Bruker Hardware: EM-27/Sun

Example 1

This is the most basic example of the error encountered.

Minimal Working Failing Example:

from brukeropusreader import read_file
opus_data = read_file('211118_EM27-SUN_#155_BA.0000')

Error raised:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/opus_parser.py", line 23, in read_file
    opus_data = parse_data(data, meta_data)
  File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/opus_parser.py", line 60, in parse_data
    name, parser = block_meta.get_name_and_parser()
  File "/usr/local/lib/python3.8/dist-packages/brukeropusreader/block_data.py", line 67, in get_name_and_parser
    return BLOCK_7[self.channel_type], parse_series
KeyError: 136

Example 2

Here, I dug through the code a bit to see what about the blocks is not behaving

Minimal Working Example:

import brukeropusreader
with open("211118_EM27-SUN_#155_BA.0000", 'rb') as infile:
     mydata = infile.read()
metas = brukeropusreader.opus_parser.parse_meta(mydata)
for i in metas:
     print(i.data_type)

Result:

0
96
64
48
7
23
7
7
23
7
0
23
23
160
32

As you can see, there are multiple block types that do not match your existing prototypes. Not accustomed to much Bruker data, I'm not sure if this is normal. However, the frequency of 0, 7, and 23 suggest that we have a reasonable cursor offset. This may be irrelevant to the BLOCK_7 key error I see, but it was an interesting observation. If most of OPUS code the author is used to seeing comes from more traditional benchtop instruments, the EM-27 may be introducing some strange new formats.

Reference Code

Binary data I used

https://www.dropbox.com/s/5jawojpjmboop0c/211118_EM27-SUN_%23155_BA.0000?dl=0

Hex dumped to plain text for your convenience

https://www.dropbox.com/s/vjwf0ibxlniptfz/tmp.xxd?dl=0