Thanks Jeff I was actually going down the tags road already. Since JAERO doesn’t use GNURadio, if I am going to modify JAERO to read tags, I’d like to do it in the cleanest way possible so I can have a simple feature/pull request and not require GNURadio as a dependency. That being said, can you tell me how to parse GNURadio tags out of a raw ZMQ stream? I was reading the docs and trying to do that yesterday and it’s really hard without the convenience of “get_tags_in_window”. I went through all the examples, but obviously they don’t focus on how to extract tags on the other side of a ZMQ socket. I may have missed something but it didn’t seem simple once you’re outside of GNURadio.
Thx
<end transmission> On Jan 18, 2022, at 06:06, Jeff Long <willcode4@gmail.com> wrote:
No, the current code will only add the key (topic) to each message.
Tags are passed through ZMQ, so you could inject tags (this might require a custom block) periodically and receive them in JAERO. You probably don't want them in every message anyway. This means that the receiver will need to wait until the next time the tags are sent, though. If you can work this out, it's cleaner. i'm passing downstream data to an external application (JAERO) which can decode audio data from a ZMQ socket.
JAERO's ZMQ SUB receives demod data as 3 separate messages: -TOPIC -SAMP RATE -DATA I'm using GNURadio 3.9 so I can pass the TOPIC no problem, but passing the sample rate as a separate message right after the topic has proven to be a challenge.
Currently, i've written a ZMQ PUB Sink in a Python embedded block that sends the zmq messages in the 3 message format above, it's a bit hacky but It's working. I'm looking for a better way to do this that uses the in-built GNURadio mechanisms to emit a custom key/value on the same interval as the topic and data.
Is there a way to send a second key/value pair with each TOPIC and DATA message that's sent?
For reference, this is the downstream ZMQ interface
|