Skip to content
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

Implement L0 protocol version 2 #31

Draft
wants to merge 6 commits into
base: dstn-beamid
Choose a base branch
from

Conversation

cubranic
Copy link

This version adds another field to the header to encode the time (in
nanoseconds since the Unix epoch) of the very first FPGA sample (the one
with fpga_count=0) at offset 8, just before "fpga_count". This increases
the length of the header by 8 bytes and pushes back the offsets of all
the subsequent fields.

This version adds another field to the header to encode the time (in
nanoseconds since the Unix epoch) of the very first FPGA sample (the one
with fpga_count=0) at offset 8, just before "fpga_count". This increases
the length of the header by 8 bytes and pushes back the offsets of all
the subsequent fields.
@cubranic cubranic marked this pull request as draft September 16, 2020 13:47
@cubranic
Copy link
Author

Hi @dstndstn. I implemented the reader for the new L0 packet format (as implemented in kotekan/kotekan#823). Can you have a look over and let me know if this change makes sense to you?

To make changing the code simpler, I added a constant for the length of the packet header (24 before, 32 now). I think I hunted down all the places in the source that hardcoded that value to index into the packets directly. There are still a few places in avx_kernels where it is used, in particular the three lines starting at line 346. Do you know what that snippet is doing?

@dstndstn
Copy link
Member

Hi Davor,
Sorry for my very slow reply!
That snippet in the AVX kernels is a coincidental innocent 24 unrelated to the header size -- if you look nearby, that function is decoding 32 bytes at a time, which is does in chunks of 8, so that "24" is just the offset of the 4th set of 8.

@dstndstn
Copy link
Member

I think the above commits are enough to set the frame0_nano field in the assembled_chunks from the intensity_packets, and I think I removed all the (much larger!) previous mechanism.

There are corresponding branches in rf_pipelines and ch_frb_l1 that we should commit at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants