discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functio


From: Ben Hilburn
Subject: Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio
Date: Wed, 29 Mar 2017 10:25:17 -0400

Hi Kostis -

So the SigMF spec is designed specifically to enable writing the metadata and dataset files in a streaming manner. The spec is careful not to dictate how applications create SigMF recordings, so it's not a problem if you write a bunch of stuff and then after you finish streaming to the files you open them up and add some more stuff to finish them off.

Bastian's point, though, is a good one. In the use-case where you are streaming metadata and samples into files and then you close your application, do you plan on needing to go back to add more information to the metadata file? If so, how do you do that in an automatic way if the flowgraph has stopped?
Maybe I could let the destructor of the block in combination with fseekm handle the finalization of the metafile. The case of segfault is actually a question that needs more attention.

Not a bad idea. It might be worth getting Johnathan to weigh-in on what he thinks is best, here, too.
 
- We are working hard to get the SigMF spec into a stable state as soon as possible, but as you can see from the issue tracker (which is where we are hosting our discussions) there are aspects of the spec that are still being debated. Many of these would impact your implementation. I think it would be good to explain your plan to (a) participate in the SigMF spec discussions, especially with the insight you gain from implementing support for it and (b) deal with pieces of the spec that may be a moving target.

I have already started looking at the open issues. Do you think it would be meaningful to move the discussion there, in a dedicated issue?

For discussion of the SigMF design, the SigMF tracker is the right place. For discussion of your GSoC proposal, I think staying on-list is the right thing =)
 
- Since this will create a dependency on RapidJSON (or whatever you use), we'll want to be sure that *not* having that installed doesn't prevent building anything not related to SigMF within GNU Radio. I really dislike adding dependencies, but since we don't already have a JSON library there isn't much of an option, here, so we just need to be sure to minimize the burden to users, developers, and packagers.

According to the description in the main page, RapidJSON "is self-contained and header-only". I dont know if MIT is a problem though.

MIT license is fine .

Cheers,
Ben

reply via email to

[Prev in Thread] Current Thread [Next in Thread]