Re: GrRangeWidget is buggy

ep 5, 2022 at 8:31 PM Miklos Maroti wrote: > Hi All, > > If you use the value of the range widget in an expression for a callback, > then you get the error: > > TypeError: unsupported operand type(s) for +: 'float' and 'GrRangeWidget' > > I have tested this for the maint 3

GrRangeWidget is buggy

Hi All, If you use the value of the range widget in an expression for a callback, then you get the error: TypeError: unsupported operand type(s) for +: 'float' and 'GrRangeWidget' I have tested this for the maint 3.10 branch, but the relevant files are unchanged in the master branch. I have

Re: QA python code uses installed python and c++ library

GNU_Radio_3.9_OOT_Module_Porting_Guide#CMakeLists.txt_changes_to_fix_OOT_module_testing > > Regards, > Vasil > > On 02/03/2022 05.19, Miklos Maroti wrote: > > Dear All, > > > > I have a GNURadio 3.10 OOT module which has C++ blocks and python QA > code. > > D

QA python code uses installed python and c++ library

Dear All, I have a GNURadio 3.10 OOT module which has C++ blocks and python QA code. During my development I do the following steps: 1. make 2. make test 3. make install 4. change c++ files 5. make 6. make test At the last step the python QA code will link the already installed python library

Re: Mac Layer

Hi Nick, You can take a look at the https://gitlab.com/marmote/gr-marmote3 repo as well. That has a custom waveform and custom MAC but it is a full fledged solution. The bare essentials (real time part) are kept in gnuradio, the rest is controlled from python using protocol buffers. Low latency

delete_head_blocking replacement for 3.8

Dear All, What is the proper replacement code for the delete_head_blocking function that was removed in gnuradio 3.8? I see that in pdu_to_tagged_stream simply using delete_head_nowait is used with checking for NULL and returning 0 in the work function. Will the block scheduler run this code in a

Re: Help with cubesats

Hi Andrew, Shameless plug, but you can take a look at this repo https://gitlab.com/phorvath/smogcli2 to record samples with RTL-SDR and Raspberry PI. It is developed for the ATL-1 and SMOG-P satellites. It is a standalone application, samples at 1.6 or 2.0 maps, tracks the location of the

Re: FBMC

Hi! Indeed. Take a look at the polyphase_chan_filter and polyphase_synt_filter files. The MarmotE FBMC implementation is special in a way that the sample rate of the subcarriers can be different than the overall sampling rate divided by the number of channels. Cheers, Miklos On Sun, Feb 2, 2020

[Discuss-gnuradio] DARPA SC2 Team MarmotE modem is open sourced

Dear Fellow GNURadio Users, We are happy to announce that we are open sourcing the MarmotE modem that we have developed for the DARPA Spectrum Collaboration Challenge under the GPLv3 license at https://gitlab.com/marmote/gr-marmote3. This is an FBMC based modem capable of using up to 40MHz of

Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files

Dear Martin, I have been looking at the GNURadio scheduler quite a bit recently and would like to summarize my experiences that could affect the direction of this GREP. As you have properly observed, the scheduler is very hard to change as it is, but there are new opportunities if we allow

Re: [Discuss-gnuradio] stop/start is not called in gr.basic_block

Hi Bastian, Thanks that solved the issue. I was not aware of that. Best, Miklos On Thu, Oct 5, 2017 at 2:29 AM, Bastian Bloessl <m...@bastibl.net> wrote: > Hi, > > On 10/05/2017 03:13 AM, Miklos Maroti wrote: >> >> I am trying to implement a simple block in pytho

[Discuss-gnuradio] stop/start is not called in gr.basic_block

Hi Guys, I am trying to implement a simple block in python but it seems that stop and start is never called when I implement them. The bare bones python code would be this: class test(gr.basic_class): def __init__(self): gr.basic_block.__init__(self, name="test", in_sig=None,

[Discuss-gnuradio] cppunit not displaying any messages

Hi All, I am not that familiar with cppunit, but my understanding is that it should print out a message when CPPUNIT_ASSERT or CPPUNIT_ASSERT_MESSAGE failes. I have deliberately added failures, and indeed the test fails with ctest but no output is produced. I am using "ctest -VV". I am getting

Re: [Discuss-gnuradio] tagged stream interleaver, scheduler and forecast

, Miklos Maroti <mmar...@gmail.com> wrote: > Hi Marcus, > > I do not know if you or someone else has the expertise on tricking the > scheduler to do the right thing. I would like to implement a tagged > stream interleaver that takes two tagged stream inputs and merges them &

[Discuss-gnuradio] tagged stream interleaver, scheduler and forecast

Hi Marcus, I do not know if you or someone else has the expertise on tricking the scheduler to do the right thing. I would like to implement a tagged stream interleaver that takes two tagged stream inputs and merges them into a single stream. Sometimes only one stream will contain packets, so it

Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig

Hi Marcus, On Mon, Jul 31, 2017 at 1:38 AM, Marcus Müller wrote: > Hi Miklos, > > what surprises me a bit is that you're introducing a new block > scheduling semantic in an OOT – wouldn't you have to modify the > scheduler to make it do things differently when encountering a >

Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig

%includes %include "mymodule/tagged_stream_block2.h" Best, Miklos On Sun, Jul 30, 2017 at 2:13 PM, Miklos Maroti <mmar...@gmail.com> wrote: > Hi All, > > It seems that no one really has the SWIG expertise. Just to reiterate, > if I copy tagged_stream_block from GnuR

Re: [Discuss-gnuradio] custom tagged_stream_block basetype and swig

to derive tagged_stream_block2, then it wants to generate a constructor and of course that fails. But why? Best, Miklos On Fri, Jul 28, 2017 at 6:34 PM, Miklos Maroti <mmar...@gmail.com> wrote: > Dear All, > > For various reasons I am not happy with the tagged_stream_block > implemen

[Discuss-gnuradio] custom tagged_stream_block basetype and swig

Dear All, For various reasons I am not happy with the tagged_stream_block implementation, and I have implemented my own version, called tagged_stream_block2 and put it into my OOT module. I can use the gr_modtool to create tagged_stream_blocks and manually change the basetype to my version.

Re: [Discuss-gnuradio] Custom block arguments

You have an extra > after samps_per_sweep here: samps_per_sweep> Best, Miklos On Sun, Jul 9, 2017 at 6:22 PM, Vipin Sharma wrote: > Here is the XML I am using. Note that CustBlock in my original post is > really 'TargetDetector_cf'. > > > > TargetDetector_cf >

Re: [Discuss-gnuradio] QA code for python hierarchical block

pp wrappers. So in an xxx OOT module I should always import xxx_swig (and never import xxx) and import python files by name if I want to use other hierarchical modules. Is this accurate? Best, Miklos On Mon, Jun 19, 2017 at 11:40 PM, Cinaed Simson <cinaed.sim...@gmail.com> wrote: > On 0

[Discuss-gnuradio] QA code for python hierarchical block

Hello, I have a simple question: I would like to write QA code for a hierarchical python block. That hierarchical block uses cpp blocks from the same out of tree module. The python code for the hierarchical block imports the xxx module, but that is not available in QA code yet, and in other

Re: [Discuss-gnuradio] scratch space in output buffer

/master/gr-dtv/lib/dvbt2/dvbt2_freqinterleaver_cc_impl.h#L35 > > Ron > > > On 05/30/2017 01:42 PM, Miklos Maroti wrote: >> >> Hi Ron, >> >> Thanks for the quick response! >> >> On Tue, May 30, 2017 at 3:32 PM, Ron Economos <w...@comcast.n

Re: [Discuss-gnuradio] scratch space in output buffer

place to be preserved across general_work calls, so return noutput_items will not be enough. Best, Miklos > > Ron > > > On 05/30/2017 12:57 PM, Miklos Maroti wrote: >> >> Hi, >> >> I would like to use scratch space within the output buffer of a block, >> bu

[Discuss-gnuradio] scratch space in output buffer

Hi, I would like to use scratch space within the output buffer of a block, but not sure if I can rely on the scheduler not altering the content of those items in the output buffer that I have written to but have not made it available to downstream blocks within general_work. I know how blocks,

Re: [Discuss-gnuradio] Latest Hackfest

Hi Tom, On Fri, Apr 4, 2014 at 12:21 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Apr 3, 2014 at 3:05 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Dear Tom, I have read about the FEC work done during the Hackfest, so this would be an appropriate time to bring this up. We have

Re: [Discuss-gnuradio] Need help to understand code of sync:decimator block

Hi Kunal, Use a decimating FIR filter with taps [0.2, 0.2, 0.2, 0.2, 0.2] and decimation 5. It will be faster than anything you are about to write. Miklos On Sat, Mar 8, 2014 at 12:03 PM, kunal sankhe kunal.2...@gmail.com wrote: Hello Marcus, Sorry for my vague explanation. I want to write a

Re: [Discuss-gnuradio] Unable to stop the flow graph after calling stop()

Dear Activecat, Throw an exception. It will kill the application. Miklos On Mon, Mar 3, 2014 at 11:57 AM, Activecat active...@gmail.com wrote: Dear Marcus, Says, the constructor performed some basic checking on the constructor arguments, then had found some fatal error (says, division by

[Discuss-gnuradio] blocks with message input and output only

Hi Guys, How to write blocks that have only message input and outputs only? I have derived from gr:block, and in most cases it seems to work, but if I put together a test that has no streams, then the whole graph stops I think prematurely. How to ensure that a flow graph works with messages only?

Re: [Discuss-gnuradio] blocks with message input and output only

Sorry, everything works as expected (needs a little wait at the beginning). Miklos On Tue, Mar 4, 2014 at 1:09 AM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, How to write blocks that have only message input and outputs only? I have derived from gr:block, and in most cases it seems

Re: [Discuss-gnuradio] pmt memory management

Hi Tom, Thanks for the clarification. I will be very careful, I promise :) Miklos On Mon, Feb 24, 2014 at 4:15 PM, Tom Rondeau t...@trondeau.com wrote: On Sat, Feb 22, 2014 at 1:49 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, Does copying a large pmt vector involve copying

Re: [Discuss-gnuradio] messages get lost randomly

Hi Martin, On Sat, Feb 22, 2014 at 1:44 PM, Martin Braun martin.br...@ettus.com wrote: On 02/22/2014 12:40 AM, Miklos Maroti wrote: Hi Guys, Ok, I have found out how to make it work reliably. You must register a listener with set_msg_handler, and then you will get the missing messages

[Discuss-gnuradio] pmt memory management

Hi Guys, Does copying a large pmt vector involve copying the underlying memory region or do they share a single copy (refcounted)? If the do share a single memory area, then can one thread modify the data of the vector and will it be visible to the other thread just like regular arrays? Miklos

[Discuss-gnuradio] messages get lost randomly

Hi Guys, I am using the messaging support of basic_block registering the message queue with message_port_register_in and removed the obtained messages with delete_head_blocking. This block is producing streams and everything seems to work fine as long as I consume the messages fast enough.

Re: [Discuss-gnuradio] messages get lost randomly

either), so if there is a gap in the message stream, then it will miss that message. Miklos On Fri, Feb 21, 2014 at 11:55 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, I am using the messaging support of basic_block registering the message queue with message_port_register_in

[Discuss-gnuradio] forecast

Hi Guys, If a block keeps some internal state, can the forecast method return different values for the same number of noutput_items depending on its internal state? Will the forecast method be called before the flow graph is started? Miklos ___

Re: [Discuss-gnuradio] set_relative_rate

Hi Tom, On Fri, Feb 7, 2014 at 11:10 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Feb 6, 2014 at 9:14 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Tom, Thanks for the answer! I have considered both approach already. What you are saying is that set_relative_rate cannot capture

Re: [Discuss-gnuradio] set_relative_rate

of processing very large blocks of data. Miklos On Thu, Feb 6, 2014 at 11:15 AM, Tom Rondeau t...@trondeau.com wrote: On Wed, Feb 5, 2014 at 7:02 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, Is it possible to write a c++ block that takes 2 input streams, produces 1 output streams

[Discuss-gnuradio] set_relative_rate

Hi Guys, Is it possible to write a c++ block that takes 2 input streams, produces 1 output streams, but to generate 1000 outputs it needs 1000 inputs of the first kind and 1 input of the second kind? How do I set the set_output_rate? Does it apply to both input streams? How can I ensure that the

Re: [Discuss-gnuradio] sched is requesting more input data than we can provide

. It is good to know. I wonder if I can set the relative rate differently for different input streams... but I could not find anything. Best, Miklos On Fri, Jan 24, 2014 at 2:00 PM, Martin Braun martin.br...@ettus.com wrote: On 01/24/2014 07:28 AM, Miklos Maroti wrote: I did not set anything

Re: [Discuss-gnuradio] sched is requesting more input data than we can provide

One more question: Can I change the relative rate (with set_relative_rate) while the flowgraph is running? What effect does that have? Miklos On Sat, Jan 25, 2014 at 12:07 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Martin, Ok, I think I have fixed the problem. I did not set

Re: [Discuss-gnuradio] sched is requesting more input data than we can provide

to use the relative rate info WHILE the flowgraph is running. I assume it uses only the forecast method only, no? Miklos On Sat, Jan 25, 2014 at 2:43 PM, Martin Braun martin.br...@ettus.com wrote: On 01/25/2014 02:23 PM, Miklos Maroti wrote: One more question: Can I change the relative rate

[Discuss-gnuradio] sched is requesting more input data than we can provide

Hi! I am getting this error: sched: xxx is requesting more input data than we can provide. ninput_items_required = 16000 max_possible_items_available = 8191 and I have no idea how to fix it. Is it possible to request more buffer space? Setting the minimum output buffer size seems to have

Re: [Discuss-gnuradio] sched is requesting more input data than we can provide

Hi Marcus, On Thu, Jan 23, 2014 at 10:12 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Miklos, the problem here is xxx: On 23.01.2014 22:00, Miklos Maroti wrote: sched: xxx is requesting more input data what's this xxx? It is requiring

[Discuss-gnuradio] filter taps and delays

Hi Guys, If I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5, 6]) on a vector source containing [1, 0, 0, ...] then I get [1, 2, 3, 4, 5, 6, 0, 0, ...] as expected. However, if I use interp_fir_filter_ccc(3, [1, 2, 3, 4, 5]) then I get [0, 1, 2, 3, 4, 5, 0, 0, ...] so the samples are shifted to the

Re: [Discuss-gnuradio] constellation soft decoder

Thanks. Miklos On Tue, Dec 17, 2013 at 3:45 PM, Martin Braun martin.br...@kit.edu wrote: On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Can you guys add me to the list of developers (user name: mmaroti)? Then I can file the bug report. In case this wasn't

Re: [Discuss-gnuradio] constellation soft decoder

the 0. (read: first) element. How this could happen with a QPSK object is currently subject to my confusion. Stay tuned for more confusing facts as the code unfolds :). Greetings, Marcus On 16.12.2013 08:30, Miklos Maroti wrote: Hi Marcus, I do not think it is a compiler bug, but something

Re: [Discuss-gnuradio] constellation soft decoder

, Miklos Maroti wrote: Hi Marcus, Ok, that makes sense. It does not crash with QPSK, but it does with BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This explains why there is crash in one case and not the other. Although neither sets the apply_pre_diff_code, so even QPSK should

Re: [Discuss-gnuradio] constellation soft decoder

the d_scalefactor manually later (this is used in calc_soft_dec)? Miklos On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Marcus, Anyway, I think Miklos is right: There is an error in calc_soft_dec in using the pre_diff_code even in the case that it is not set or its

Re: [Discuss-gnuradio] constellation soft decoder

Hi Tom, On Mon, Dec 16, 2013 at 7:27 PM, Tom Rondeau t...@trondeau.com wrote: On Mon, Dec 16, 2013 at 1:08 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, Ok, I have sent a pull request. On a related note: I do not understand the scaling performed in the constellation

[Discuss-gnuradio] constellation soft decoder

Hi Guys, Constellation soft decoder crashes for constellation_bpsk() and constellation_8psk(). I could not find the cause of this problem, the back trace on my machine points to gnuradio/gr-digital/lib/constellation.cc:286 for(int j = 0; j k; j++) { which does not make any sense. Any idea

Re: [Discuss-gnuradio] constellation soft decoder

S7390,...) and GNU Radio source version. Thanks and happy hacking, Marcus On 12/16/2013 01:05 AM, Miklos Maroti wrote: Hi Guys, Constellation soft decoder crashes for constellation_bpsk() and constellation_8psk(). I could not find the cause of this problem, the back trace on my machine points

[Discuss-gnuradio] UHD error on first connection

Hi Guys, When I boot up my computer and try to connect to an USRP2 node, then the first connection never works, but subsequent ones are working perfectly. 1) uhd_find_devices always works: linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.004-5-g6bb62ea3

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

the encoder and decoder becomes really slow. (Many optimizations are still in order.) I wish I could tell you I had a better BER plot, but what's there in the report is all I have currently. Thanks for checking out. On Tue, Nov 5, 2013 at 11:08 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Manu, Thanks for the report, it was more informative than the presentation. Yes, I have seen the BER figure, but that is not very will presented (e.g. you should use logarithmic scale for BER) and should have better resolution on the Eb/N0 axes

Re: [Discuss-gnuradio] The GSoC project on LDPC codes.

Dear Manu, Do you have any performance numbers on your LDPC decoder? I could not find any info, even in your presentation. Do you have also a BER figure, or even better would be some technical report. I would love to get some sense on the performance of your implementation. Best, Miklos On Tue,

Re: [Discuss-gnuradio] How to get multipe rx_time tags while receiving continuously

Hi Harry, You never stop the receiver on node B and C, right? You should not observe anything like that if you do not have dropped packets. Are you using USRP2's? Miklos On Sat, Nov 2, 2013 at 3:05 AM, Harry Zhang zhang...@gmail.com wrote: Tom, Thanks for your reply. I got a weird

Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

is the DSP time. However, the DSP time should be almost completely deterministic, so it cannot be a jitter just some time offset. If you see a jitter, then I think it must be caused by either ethernet or some DSP startup artifacts. Miklos Best, Harry 2013/10/12 19:17, Miklos Maroti wrote: Hi

Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

accuracy is 160us. I wanna break into USRP FPGA to achieve 1us or less accuracy. And I don't understand your continuously transmission. Could give me some details. 2013/10/12 9:03, Miklos Maroti wrote: Hi Harrz, What do you mean by 160us precision? How did you measure it or compute

Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

Hi Harrz, What do you mean by 160us precision? How did you measure it or compute it exactly? I do not understand your goal, but it is quite simple to synchronize two usrps with continuous transmission to within one sample and if you continuously receive the transmitted signal on the transmitter

[Discuss-gnuradio] swig madness

Hi Guys, I am trying to create a rational_sync_block class in an out of tree module, which is both an interpolator and decimator with a rational data rate. So I just wrote the class, almost exactly like how sync_interpolator is written. Then when I want to use this new base class in a derived

Re: [Discuss-gnuradio] swig madness

you may get a runtime error as it cannot find the object you are referencing within gnuradio. Michael Berman On Fri, Oct 4, 2013 at 2:36 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, I am trying to create a rational_sync_block class in an out of tree module, which is both

Re: [Discuss-gnuradio] sync_interpolator

like it if your time reference is sample time. On Tue, Aug 27, 2013 at 12:43:34PM -0500, Miklos Maroti wrote: Hi Martin, On Tue, Aug 27, 2013 at 3:07 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Aug 27, 2013 at 02:43:32AM -0500, Miklos Maroti wrote: Hi Martin

Re: [Discuss-gnuradio] sync_interpolator

:19 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Aug 27, 2013 at 12:11:48AM -0500, Miklos Maroti wrote: Hi Guys, I do not understand how set_history and fixed rate blocks are interacting. Supposedly, the scheduler can figure out a static schedule for sync blocks. However

Re: [Discuss-gnuradio] sync_interpolator

Hi Martin, On Tue, Aug 27, 2013 at 3:07 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: On Tue, Aug 27, 2013 at 02:43:32AM -0500, Miklos Maroti wrote: Hi Martin, I have checked the tutorials, but they do not give precise details. http://gnuradio.org/redmine/projects/gnuradio/wiki

[Discuss-gnuradio] sync_interpolator

Hi Guys, I do not understand how set_history and fixed rate blocks are interacting. Supposedly, the scheduler can figure out a static schedule for sync blocks. However, the sync_interpolator is forcasting this int sync_interpolator::fixed_rate_noutput_to_ninput(int noutput_items) { return

Re: [Discuss-gnuradio] inefficient large vectors

describe it in a few words or give a pointer where I can read upon the technical (!!) details. Best, Miklos Happy hacking, Marcus On 08/21/2013 07:59 PM, Miklos Maroti wrote: Hi! I have many sync blocks that work with large fixed size vectors, e.g. converts one vector of size 12659

[Discuss-gnuradio] inefficient large vectors

Hi! I have many sync blocks that work with large fixed size vectors, e.g. converts one vector of size 12659 to another with size 18353. I have just multiplied the sizeof(gr_complex) with 12659 and 18353 in the signature. However, when the flow graph is running, then I get a warning about paging:

Re: [Discuss-gnuradio] inefficient large vectors

Hi Marcus, Yes, I understand the page size limitation. However, if your vector is 1234 bytes, then you can happily allocate 4096 size buffer, but the the block you always give out the multiple of 1234 byes (i.e. 1, 2 or 3 vectors). The address space wrapping would work fine, so the start of the

Re: [Discuss-gnuradio] inefficient large vectors

Braun (CEL) martin.br...@kit.edu wrote: On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote: So is there a way to work with large odd length vectors which does not have this buffer allocation problem, and does not require padding? It seems to me that it could be supported: regular streams

[Discuss-gnuradio] GRCC generation

Hi! I would like to add a CMAKE rule to my out of tree module to generate hierarchical blocks from GRC files using the GRCC tool. However, GRCC refuses to pus the generated py and xml files to the right directory, and instead it always places them into the $HOME/.grc_modules directory even if

[Discuss-gnuradio] Sampling glitch in the RX path

Hi Guys, I am using N210 with SBX at 5M sampling rate. I have one USRP Source running continuously (connected to the TX/RX antenna), and a USRP Sink (connected also to TX/RX) that sends timed packets with the tx_time, tx_sob, tx_eob tags at a rate of 1 ms per packet. I am sending packets 10 ms

Re: [Discuss-gnuradio] Sampling glitch in the RX path

the system working consistently, you can working on optimizing things for lower latency (lead time). -John On Wed, Jun 5, 2013 at 8:58 AM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Guys, I am using N210 with SBX at 5M sampling rate. I have one USRP Source running continuously

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

you can't just use the fractional seconds. The FPGA won't switch to TX when it hits tx_time and starts clock out the samples. -John On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi John, Thanks for you quick reply, but you did not answer any of my

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

at 5:23 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi John, Thanks for the excellent suggestion! It seems to work reliably with 5ms buffering. I did not set the time of the FPGA, nor did I synchronized the FPGA with the host. I just used the received sample counter for all timings

[Discuss-gnuradio] half duplex set_auto_tx timing problems

Hi Guys! I am trying to develop a half duplex application with N210 and SBX daughterboard with the latest (git head) gnuradio that needs precise TX/RX switching times (like in TDMA) in the order of a few samples (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags and they do not

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

3, 2013 at 6:14 PM, John Malsbury john.malsb...@ettus.com wrote: If you choose TX/RX as both your transmit and receive antenna, the FPGA will switch between TX and RX automatically. It'll switch to TX when it receives samples to send. -John On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

Hi Marcus, Thanks for the quick comments. Yes, I totally agree that using full duplex with RX2 and TX/RX would be the ideal way to go, and as you say I can easily ignore and synchronize with my own transmissions. The problem is that I am required to use a single antenna, so I have to do a half

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

Hi Marcus, Thanks for the quick comments. Yes, I totally agree that using full duplex with RX2 and TX/RX would be the ideal way to go, and as you say I can easily ignore and synchronize with my own transmissions. The problem is that I am required to use a single antenna, so I have to do a half

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

? This contradicts the other sentences you wrote. Miklos -John On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi John, Thanks for you quick reply, but you did not answer any of my questions. Will the FPGA switch from TX to RX when it has already received from the host

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

Hi Marcus, On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech mle...@ripnet.com wrote: You say that it switch from TX to RX if the next timestamp is in the future and switch from RX to TX just when the timestamp is triggered. You see L because you are sending your bursts far enough advance. In

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

with the RX/TX switch scheduled with tx_time? Best, Miklos -Ian On Jun 3, 2013, at 5:50 PM, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Marcus, Thanks for the quick comments. Yes, I totally agree that using full duplex with RX2 and TX/RX would be the ideal way to go, and as you

Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

. on Jun 03, 2013, Miklos Maroti mmar...@math.u-szeged.hu wrote: Hi Marcus, On Mon, Jun 3, 2013 at 8:15 PM, Marcus D. Leech mle...@ripnet.com wrote: You say that it switch from TX to RX if the next timestamp is in the future and switch from RX to TX just when the timestamp is triggered