-
Notifications
You must be signed in to change notification settings - Fork 16
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
Lo DE Segmented Packets #1016
Lo DE Segmented Packets #1016
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Nice clean, easy to read code. I'll approve with the assumption that you address the comment on the use of np.where()
.
imap_processing/lo/l0/lo_science.py
Outdated
# 1 = start of a group of segmented packet | ||
# 2 = end of a group of segmented packets | ||
# 3 = unsegmented packet | ||
seg_starts = np.where((seq_flgs == 1) | (seq_flgs == 3))[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I nit-pick the use of np.where()
a lot. This should really be np.nonzero()
. See the Note
at the top of the numpy documentation: https://numpy.org/doc/2.0/reference/generated/numpy.where.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting. I wasn't aware of that. Thanks, I'll make that change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor comment. Otherwise, LGTM
seq_flgs = dataset.seq_flgs.values | ||
seq_ctrs = dataset.src_seq_ctr.values | ||
|
||
# Find the start and end of each segment of direct events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These short comments were very helpful!
I just made an update to this PR. I found out that padding is added to the binary data to make the packet divisible by 8, so I made a small change to help me identify where to look for padding when this is used in processing. The change adds a comma between segments when they're combined into a single binary string. I'm not crazy about that approach, but I should be able to use that with a find for the next comma or end of the string and determine which bits I need to throw way. I also thought about keeping the binary string separated in a list of lists, but that would require another for loop or passing around another variable to keep track of which segment I'm in. Adding the comma seems easier, but the binary string with commas isn't ideal. Hoping to get others' thoughts on this. |
I wish I have ideas for this. This is where Greg is great at :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looks good to me. You can revisit this again in the future if you think of another solution to ,
.
Change Summary
Overview
This PR adds a function to handle Lo direct event segmented packets. This function will soon be added to Lo processing in combination with the event parsing to produce a L1A dataset for Lo direct events.
If there are too many bits of data needed to store Lo direct events for a single Aggregated Science Cycle into a single packet, the data will be segmented across multiple packets. The segments will be indicated by the seq_flag:
seq_flag 1 = start of segment
seq_flag 0 = one of the middle packet of a segment
seq_flag 2 = last packet of a segment
seq_flag 3 = unsegmented packet
The packets after the first will only contain the headers, shcoarse, binary data and checksum. They will not contain the count and passes fields.
Closes #1011