Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

gt; *보낸 사람:* Müller, Marcus (CEL) 대신 Discuss-gnuradio > > *보낸 날짜:* 2019년 7월 16일 화요일 오전 1:58:24 > *받는 사람:* discuss-gnuradio@gnu.org; atiq@gmail.com > *제목:* Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal > for limesdr mini with help of gnu radio. > >

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

ards, Kyeong Su Shin 보낸 사람: Müller, Marcus (CEL) 대신 Discuss-gnuradio 보낸 날짜: 2019년 7월 16일 화요일 오전 1:58:24 받는 사람: discuss-gnuradio@gnu.org; atiq@gmail.com 제목: Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

Dear Atiqur, the sampling rate is the product of symbol rate and samples per symbol (quite intuitive, isn't it?). Nyquist should be no problem here: you're the one producing that signal, so it will inherently "fit". 4sps? Are you sure? That's way too little. Many (most) channels wouldn't even b

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

Dear Atiqur, my concerns are less of the GRC variant, but of the DSP variant: * If your GRC doesn't complain about you using Throttle together with the hardware blocks, that's a bug in the hardware blocks. Anyway, NEVER use Throttle with hardware blocks. You incur the two-clock problem, and will

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

Also, should I use timing recovery and equalizer in the receiving side(as it would make more sense). My idea is transmitting the data and receiving it simultaneously without losing data. Thank you. On Mon, Jul 15, 2019 at 5:40 PM Md. Atiqur Rahman wrote: > Dear Marcus, > Thank you for your qu

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

Oh, and why are you doing an equalizer and a timing recovery on the *transmit* side!? On Mon, 2019-07-15 at 15:04 +, Müller, Marcus (CEL) wrote: > Also, without knowing, I'm almost certain that 64kS/s is not a possible > sampling rate for the device. You really might want to read the console >

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

Also, without knowing, I'm almost certain that 64kS/s is not a possible sampling rate for the device. You really might want to read the console output very closely! On Mon, 2019-07-15 at 14:56 +, Müller, Marcus (CEL) wrote: > So, first of all: > > never use "Throttle" in a flow graph with har

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

So, first of all: never use "Throttle" in a flow graph with hardware. In fact, GRC will *scream* at you that you shouldn't be doing that! Then: I can't claim to have any knowledge of the limeSDR driver, but unless that driver specifically allows you to start the TX and RX streaming at the exac

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

Hi, How to calculate how much is the ppm from the error value, which is actually the drift. If suppose my sample rate is 48KHz and the accumulated error after 1M samples (20.833 sec) is 'n' samples, then ppm = n, Is that correct calculation ? On Thu, Oct 27, 2016 at 3:24 AM, Marcus Müller wr

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

On Thu, Oct 27, 2016 at 10:35:32PM +, Fons Adriaensen wrote: > time constant of around 10 / B, i.e. one second. So the relativei Correction : of around 1 / (10 * B), i.e. one second. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

On Wed, Oct 26, 2016 at 11:54:17PM +0200, Marcus Müller wrote: > > The actual frequency of the clock used to measure time doesn't > > matter as long as it has reasonable short term stability (and both sides > > use the same clock of course). > Exactly; that what was I was worried about. I don't ha

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem

Hi Fons, On 10/26/2016 10:26 PM, Fons Adriaensen wrote: > On Wed, Oct 26, 2016 at 01:30:19PM +0200, Marcus Müller wrote: > >> Now, these microsecond timestamps >> will introduce a /third/ clock into our problems. I can see how the >> control loop converges in case of that clock being both faster t

Re: [Discuss-gnuradio] Delay locked loop for the two-clock problem (was: simple mod-demod combinations doesn't work)

On Wed, Oct 26, 2016 at 01:30:19PM +0200, Marcus Müller wrote: > Now, these microsecond timestamps > will introduce a /third/ clock into our problems. I can see how the > control loop converges in case of that clock being both faster than your > sampling clock and relatively well-behaved, but: is

[Discuss-gnuradio] Delay locked loop for the two-clock problem (was: simple mod-demod combinations doesn't work)

Hi Fons, Hi Kevin, this sounds very nice! I've only read your email+presentation and skimmed your paper, and I have the following rather technical question: Your DLL depends on you having a delay estimator $\hat D(t)=W(t)-R(t)-c+e(t)$, in which $R$ are the read-from-buffer, $W$ the written-to-bu

Re: [Discuss-gnuradio] Delay Block for Tags?

The best way to do that would probably be to create a block that disables tag propagation and then reinserted the tags at the right sample offset based on your desired delay. - Seth > On Apr 23, 2015, at 20:40, Richard Bell wrote: > > Hi all, > > I need to delay a tag in my stream only, not

[Discuss-gnuradio] Delay Block for Tags?

Hi all, I need to delay a tag in my stream only, not the sample it is attached to. I'm looking for the equivalent of a delay block, but for tags. Does anyone know of a way of doing this in grc? v/r, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradi

Re: [Discuss-gnuradio] Delay block controlled by input

Now the clock runs fine (with gr::block::nitems_read). But I have another problem: I have a rate of 10.23 million samples per second and I need to delay the signal +-1ns. With the modified block delay (controlled by an input) I can delay the signal 97.75ns (1 / 10,230,000 -> + - one sample). Cou

Re: [Discuss-gnuradio] Delay block controlled by input

On 10/08/2014 03:24 PM, Carlos Alberto Ruiz Naranjo wrote: > Really the question is: > > How can I call > gr::block::nitems_read( unsigned int/which_input/ ) > > from a block to know the nitems_read of another block? You call 'nitems_read()'? Not sure you should be ca

Re: [Discuss-gnuradio] Delay block controlled by input

You call another_block->nitems_read(number) with number being the number of the input stream (ie. 0 for the first, 1 for the second and so on). Remember, GNU Radio is C++, and blocks are built as classes. Greetings, Marcus On 08.10.2014 15:24, Carlos Alberto Ruiz Naranjo wrote: > Really the quest

Re: [Discuss-gnuradio] Delay block controlled by input

Really the question is: How can I call gr::block::nitems_read (unsigned int *which_input*) from a block to know the nitems_read of another block? 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com>: > And a question. In: > > uint64_t >

Re: [Discuss-gnuradio] Delay block controlled by input

And a question. In: uint64_t gr::block::nitems_read ( unsigned int *which_input*) How I know wich_input? 2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com>: > OK !! Thank you v

Re: [Discuss-gnuradio] Delay block controlled by input

OK !! Thank you very much for the tips. Next week I will use it in my PC of the lab. ;) The delay is in the data, not in the modulated signal. And I insert the average between the previous and the next sample. Greetings 2014-10-08 14:53 GMT+02:00 Marcus Müller : > Hi, > > On 08.10.2014 14:38, C

Re: [Discuss-gnuradio] Delay block controlled by input

Hi, On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote: > Delay Block is controlled by Satellite Orbit and Satellite Orbit by > "simulated clock". The output of Satellite Orbit is the delay (samples). > Can I know the nitems_read of Delay Block from other block (Satellite > Orbit)? Yes. It's a

Re: [Discuss-gnuradio] Delay block controlled by input

Delay Block is controlled by Satellite Orbit and Satellite Orbit by "simulated clock". The output of Satellite Orbit is the delay (samples). Can I know the nitems_read of Delay Block from other block (Satellite Orbit)? Maybe a solution is to introduce Orbit Satellite in Delay block, but this is re

Re: [Discuss-gnuradio] Delay block controlled by input

If you're comparing real time (system clock) to your sample stream, you'll get jitter, not drift, using a throttle. Throttle maintains a sample rate over time, but operates on blocks, and also is running under a non-realtime operating system. If you're talking about drift between the clock on

Re: [Discuss-gnuradio] Delay block controlled by input

In that case, just use nitems_read() [1] in your delay block to inherently calculate "simulated time". However, I'm a bit curious about the effects of using delay to do this: Because, as long as the satellite is approaching you, you're occasionally dropping samples, whereas you're inserting zeros

Re: [Discuss-gnuradio] Delay block controlled by input

Yes, it is not a real time clock. This "clock" tracks the current time of the signal in GNURadio. clock2 and clock1 have a drift because the number of counted samples are different. For example, if it pass 1023 samples the delay block is entering the delay in signal time = 1 second. 1 second i

Re: [Discuss-gnuradio] Delay block controlled by input

See also http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-does-sample-rate-mean-in-GNU-Radio. M On 10/08/2014 01:18 PM, Martin Braun wrote: > If you don't have hardware involved, you have no 'clock'. And as such, > it can't drift. > > M > > On 10/08/2014 12:29 PM, Carlos Alberto Ruiz

Re: [Discuss-gnuradio] Delay block controlled by input

If you don't have hardware involved, you have no 'clock'. And as such, it can't drift. M On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote: > Sorry, I have explained bad: S > I have the signal saved in a file and 1023 samples are one second > (in the real world). > > In the first gra

Re: [Discuss-gnuradio] Delay block controlled by input

Sorry, I have explained bad: S I have the signal saved in a file and 1023 samples are one second (in the real world). In the first graph I have two clocks (counters samples). When passing 102300 samples it increase 0.01 seconds. In the first watch this time controls the position of the satelli

Re: [Discuss-gnuradio] Delay block controlled by input

Hello Carlos, On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote: > I generate the signal from a file (1023 samples/s) to a file. My > sampling clock drifts significantly :S No. Unless I misunderstood you, you have a big misconception: "sampling clock" is *not* the rate at which your sample

Re: [Discuss-gnuradio] Delay block controlled by input

I generate the signal from a file (1023 samples/s) to a file. My sampling clock drifts significantly :S - Picture one: Counter Clock 2 is correct but Counter Clock 1 no. Then I should use the second configuration, but it is not allowed because I have a loop, right? ​ I'll try the method you

Re: [Discuss-gnuradio] Delay block controlled by input

Ok, you'll have to explain why you'd need throttle, as this is almost never the case, especially not when a) working in a simulation or b) working with "real" hardware, as that usually enforces a sampling rate. If you know the physical sampling rate, counting samples *must* work, unless your sampli

Re: [Discuss-gnuradio] Delay block controlled by input

I am having problems with the clock. I need to track the real time of the signal. I have tried to get it with a sample counter and a throttle (to maintain the rate), but it doesn't work. The clock is faster or slower than the current signal time. Any idea? ;) 2014-09-23 20:13 GMT+02:00 Tom Rondea

Re: [Discuss-gnuradio] Delay block controlled by input

On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com> wrote: > - SIGNAL: 1023 samples/s > > - CLOCK: Counter that increments +0.001 when passing 10230 samples. > > - SATELLITE ORBIT: Calculate the satellite orbit and delay. > > > ​ > Ok. My problem with t

Re: [Discuss-gnuradio] Delay block controlled by input

- SIGNAL: 1023 samples/s - CLOCK: Counter that increments +0.001 when passing 10230 samples. - SATELLITE ORBIT: Calculate the satellite orbit and delay. ​ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/lis

Re: [Discuss-gnuradio] Delay block controlled by input

It simulates the signal delay of a satellite. It is updated every millisecond. The control mechanism is a block which calculates the satellite orbit every millisecond and measures the distance. 2014-09-23 14:54 GMT+02:00 Tom Rondeau : > On Tue, Sep 23, 2014 at 2:38 AM, Carlos Alberto Ruiz Naranj

Re: [Discuss-gnuradio] Delay block controlled by input

On Tue, Sep 23, 2014 at 2:38 AM, Carlos Alberto Ruiz Naranjo < carlosruiznara...@gmail.com> wrote: > Hello, > > I have modified GNURadio delay block. It is a controlled delay from an > input at runtime. > > I would like to know your opinion; if the block is well designed. > > > http://pastebin.com

[Discuss-gnuradio] Delay block controlled by input

Hello, I have modified GNURadio delay block. It is a controlled delay from an input at runtime. I would like to know your opinion; if the block is well designed. http://pastebin.com/f7Y24fin http://pastebin.com/0gKDHgwL ___ Discuss-gnuradio mailing l

Re: [Discuss-gnuradio] delay of Synchronization by using PPS

Hi ? ?, I don't really understand your timing diagram (~-_- style), could you explain them in more detail? Greetings, Marcus On 17.07.2014 18:32, ? ? wrote: > hi guys, > Im using a USRP-N and a USRP2 to send a Square Signal to another USRP2 for > proving Synchronization by using PPS. > > after

[Discuss-gnuradio] delay of Synchronization by using PPS

hi guys, Im using a USRP-N and a USRP2 to send a Square Signal to another USRP2 for proving Synchronization by using PPS. after execute a get following message: linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.007.000-1-stable Using Volk machine: sse4_1_32 -- Opening a USRP2/N-Series device

Re: [Discuss-gnuradio] delay line

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forgot to mention: You must call the set_history() function accordingly! On 03.02.2014 00:13, Marcus Müller wrote: > Yes, it will. The GNU Radio scheduler calls your block's work() > function whenever it needs new data. > > Anyway, this is a very bas

Re: [Discuss-gnuradio] delay line

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, it will. The GNU Radio scheduler calls your block's work() function whenever it needs new data. Anyway, this is a very basic principle of GR; I recommend working through the "creating an OOT module" tutorial, it's really great! Greetings, Marcus

Re: [Discuss-gnuradio] delay line

On 02.02.2014 14:14, MHMND Herath wrote: Dear Sir I created a C++ sync block and inserted out[i]=in[i-100] I wanted to get 100th earliest sample continuously. It worked. But I wanted to know will this correct when it connected to a source continuously. Thanks Neil You probably want to

[Discuss-gnuradio] delay line

Dear Sir I created a C++ sync block and inserted out[i]=in[i-100] I wanted to get 100th earliest sample continuously. It worked. But I wanted to know will this correct when it connected to a source continuously. Thanks Neil ___ Discuss-gnurad

[Discuss-gnuradio] Delay between feedback and scheduling decision in LTE implemented in GNURadio

Hi, I would like to ask if anyone knows how long is the delay between a feedback and a scheduling decision in implementation of LTE on USRP boards using GNURadio? I am trying to use OpenLTE source codes but since it is only downlink I need to add a feedback (power gain or SINR) and then transmitt

Re: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

It turns out that the time registers were being written in the wrong order. I have pushed a fix to the master (seconds need to be written last). -Josh On Mon, May 24, 2010 at 3:49 AM, Manuel Fuhr wrote: > 2010/5/21 周亮 : >> Hi, >> >> These days I am trying to synchronize two USRP2 with PPS signal

Re: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

2010/5/21 周亮 : > Hi, > > These days I am trying to synchronize two USRP2 with PPS signal  and UHD. > The two USRP2 is connect with same reference clock and PPS signal. I use > function "set_time_next_pps(uhd::time_spec_t(0))" to set time to be zero, > and make two USRP2 start sampling after 3 secon

Re: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

Could you check that the revisions of the USRP2s are the same. I remember that the lower impedance in the rev 1 caused a pretty long delay, but I think we fixed this. You could still look at the PPS inputs with an oscilloscope probe and see what it looks like. juha On Sat, May 22, 2010 at 08:49,

Re: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

When performing set_time_next_pps(...) you will want a sleep(1) prior to starting streaming. Because it could take as much as 1 second for the registers to latch the new time value. Yes, I have used sleep(1) commmand after I call set_time_next_pps() function. The problem is that if I replace t

RE: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

Hi， > You need to configure the usrp2 to use the external reference. Did you > run set_clock_config(...) prior to setting the time? Yes, I have set the clock config to make USRP2 lock to reference clock SMA and PPS SMA. > When performing set_time_next_pps(...) you will want a sleep(1) prior

Re: [Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

These days I am trying to synchronize two USRP2 with PPS signal and UHD. The two USRP2 is connect with same reference clock and PPS signal. I use function "set_time_next_pps(uhd::time_spec_t(0))" to set time to be zero, and make two USRP2 start sampling after 3 seconds. The result shows tha

[Discuss-gnuradio] Delay of synchronization with PPS and UHD on USRP2

Hi, These days I am trying to synchronize two USRP2 with PPS signal and UHD. The two USRP2 is connect with same reference clock and PPS signal. I use function "set_time_next_pps(uhd::time_spec_t(0))" to set time to be zero, and make two USRP2 start sampling after 3 seconds. The result shows t

[Discuss-gnuradio] delay through dsp pipeline

Hello, In several discussions, I recall it was mentioned that the timestamp reference is at the end of the dsp pipeline. Is the dsp pipeline consisting just of the DDC or anything else? It was also mentioned that the delay through the dsp pipeline depending on some factors such as decimation rat

Re: [Discuss-gnuradio] Delay

Per- > > After implementing Eric's advice, please post the minimum > > delay value you obtain. > > I'm interested to hear. Thanks. > > Changin the fusb_* parameters didn't change my results. By reducing the > buffer size (of the reads and writes) the delay is reduced down to around > 1ms (I have

RE: [Discuss-gnuradio] Delay

> After implementing Eric's advice, please post the minimum > delay value you obtain. > I'm interested to hear. Thanks. > > -Jeff > Changin the fusb_* parameters didn't change my results. By reducing the buffer size (of the reads and writes) the delay is reduced down to around 1ms (I have s

Re: [Discuss-gnuradio] Delay

Per- > > I have made my own little program (based on libusrp) that reads data from a > > file and sends it on the DAC of the USRP (basic db) and simultaneously > > receives data and saves it on file. All at 2MHz sample-frequency. > > > > It seems to work well. But when I connect the DAC directly t

Re: [Discuss-gnuradio] Delay

On Tue, Mar 04, 2008 at 11:32:46AM +0100, Per Zetterberg wrote: > Dear All, > > I have made my own little program (based on libusrp) that reads data from a > file and sends it on the DAC of the USRP (basic db) and simultaneously > receives data and saves it on file. All at 2MHz sample-frequency. >

[Discuss-gnuradio] Delay

Dear All, I have made my own little program (based on libusrp) that reads data from a file and sends it on the DAC of the USRP (basic db) and simultaneously receives data and saves it on file. All at 2MHz sample-frequency. It seems to work well. But when I connect the DAC directly to the ADC I se

[Discuss-gnuradio] delay in tx chain

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've asked a similar question before, so please try and bear with me :). Is there a way to calculate the delay of all blocks after yours in a chain? It might be as easy as summing up the histories of all of the blocks... As an illustration of why we