Re: [Discuss-gnuradio] DMR Teir 3 just wondering.

On 11/10/2017 01:09 PM, Adrian Hodgson wrote: > So to the point of the post, would it be of benefit to any developers with > the > intention of improving blocks, functionality etc if I offered the odd file > sink > of the radio systems for testing of software. Hi Adrian, we love sharing our

Re: [Discuss-gnuradio] GNU Radio OOT Modules with Same Name - What To Do?

The way OOTs are set up, having two OOTs with the same name will only work with hacky solutions. -- M On 11/03/2017 01:50 PM, Kyeong Su Shin wrote: > Hello Nicolas, > > It is a GNU Radio module that I saw from GRCon17: > https://github.com/samwhiting/gnuradio-doa/tree/master/gr-doa > >

Re: [Discuss-gnuradio] Fwd: E310 file transition problem

Can you please provide more details, and also, I recommend not posting pictures on Google drive (many people simply won't click it then). Cheers, Martin On 11/06/2017 10:45 AM, yuqing lin wrote: > > Hello all: >   We were trying to transmit data between USRP E310 and N200, I have > attached

Re: [Discuss-gnuradio] Setting output buffer to contain one packet

Would set_output_multiple() do what you want? https://gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3 However, you might want to consider passing your packets as messages, not as streams. -- M On 11/09/2017 07:06 AM, Muhammad Zulqarnain wrote: > Dear All! > > I

[Discuss-gnuradio] Problem to handle message port in thread

I'm getting an error while trying to use an output message port with a thread. The thread is responsible for executing function *check_buff()*. It seems to return the error bellow because the message port inside the function was not initialized yet. Firstly, the thread was started at the

Re: [Discuss-gnuradio] Problem to handle message port in thread

Hi André - I think you're looking for 2 steps: 1) In the block constructor, declare the message port, e.g.: {{{ message_port_register_out (pmt::mp ("frame request")); }}} You're probably already doing this. 2) Add the thread creation to the ::start method, so that the thread is not trying to

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Hi Eugene, yup, fully agree, the whole concept is slightly broken. So, first of all, I really think the key problem we're constantly working around is that tags have an integer offset – which leads to rounding errors, even in relatively benign scenarios. I'd propose we add a fractional part:

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

Why not make the sub-second offset a uint64. That way you can express time to the atto second (I think). The precision is overkill, but uint32, which barely breaks a picosecond is underkill. On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller wrote: > Hi Eugene, > > yup,

Re: [Discuss-gnuradio] Problem to handle message port in thread

Hi Michael, Thanks for you support but I'm still getting the same error. :/ 1) Yes, I'm already doing that. 2) I did that. See figure bellow. Unfortunately, the error persists as you can see bellow. *Figure 1: *start() method. *​* *Figure 2:* error I have not found such examples you mentioned