You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was originally raised in #3here. 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 #3here. 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
The text was updated successfully, but these errors were encountered:
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).
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:
The text was updated successfully, but these errors were encountered: