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

Digital RF Source block and handling missing values #4

Open
ryanvolz opened this issue Jul 16, 2019 · 1 comment
Open

Digital RF Source block and handling missing values #4

ryanvolz opened this issue Jul 16, 2019 · 1 comment
Assignees

Comments

@ryanvolz
Copy link
Member

This issue was originally raised in #3 here. Executive summary: The Digital RF Sink writes data in continuous mode by default, and when given 'now' as the starting write time this will almost always result in missing samples at the beginning of the first file, stored as NaN for floating point types. The Digital RF Source defaults to beginning to read the data at the start of the file, so it starts by outputting those NaNs. Other GNU Radio blocks subsequently choke on the NaNs and playback fails.

A detailed summary can be found in #3 here. The options for fixing this behaviour include:

  • Calling this out and making it more clear in the documentation
  • Defaulting to chunked mode for writing (maybe if we test the performance again now, the difference is not so large?)
  • Having Digital RF Source skip over default samples at the start of the stream, or somehow otherwise know at what point the Sink started writing
  • Converting 'NaN' values to 0 or something valid when streaming in GNU Radio
@ryanvolz
Copy link
Member Author

Commit 0f2fa4a, included in the 2.6.2 release, should partially solve this problem by outputting the missing values (NaN or minimum integer) as 0 when read from the Digital RF Source blocks in GNU Radio. At least now the playback should not fail, even if the user might see unexpected zeros.

I still think we need to do more to address this so the behavior is not as surprising. I recently tested write performance in chunked mode again, and there is still a significant speed penalty to defaulting to that. I don't think it makes sense to change chunked to the default.

Improving the documentation would go a long way I think, so we should do that before I would consider this issue resolved. There's still room for considering whether or not we want to further modify the Digital RF Source to skip over missing samples that are actually contained in the files with continuous mode (as opposed to just missing chunks in the files as in chunked mode).

@ryanvolz ryanvolz self-assigned this Jul 20, 2021
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

No branches or pull requests

1 participant