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

Normalize Labels for Compatibility #10

Open
xloem opened this issue Nov 2, 2015 · 1 comment
Open

Normalize Labels for Compatibility #10

xloem opened this issue Nov 2, 2015 · 1 comment

Comments

@xloem
Copy link

xloem commented Nov 2, 2015

I propose that the label names be changed so as to match tag names found in gnuradio, so that someday some compatible behavior or even standard may evolve.

The following tag names are used in gr-uhd and gr-osmosdr/bladerf:

txTime -> tx_time
txEnd -> tx_eob
rxTime -> rx_time
rxEnd -> rx_eob
rxFreq -> rx_freq
rxRate -> rx_rate

@guruofquality
Copy link
Contributor

What's even worse is that I'm the moron that came up with the gr-uhd names as well... So, I don't want to pull the rug out under anyone's feed here. But you are right that it might be better. Also the other toolkit blocks are using these rate and freq labels as well to automatically set their axis (see plotters).

I have found that a lot of generic blocks that use labels, often need a name passed as a parameter, because the upstream block providing the label may be one of many things (including but not limited to sdr source). So the actual label ID is not so important in this case, just as long as any two blocks agree.

Then there are blocks that specifically are meant to be connected to the SDR source/sink blocks. I think my concern is that some of the gnuradio blocks may have these tag names hard-coded, and pothos sdr label names would prevent them from being used.

So I am also considering:

  • Adding functions to set the used label id's (just like many of the other blocks have)
  • Or a function to configure "gnuradio" compatible labels. If there are blocks out there that need this. Obviously the first option is a little more flexible.

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

2 participants