|
From: | Carlos Alberto Ruiz Naranjo |
Subject: | Re: [Discuss-gnuradio] Delay block controlled by input |
Date: | Wed, 8 Oct 2014 15:24:54 +0200 |
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 <address@hidden>:GreetingsOK !! 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.2014-10-08 14:53 GMT+02:00 Marcus Müller <address@hidden>: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 public function, as you can see in the documentation I linked.
>
> Maybe a solution is to introduce Orbit Satellite in Delay block, but this
> is really inefficient to do tests.
Good point, but you should be able to test your "calculate transmission
delay from an integer" functionality externally; also, there's no reason
to have something like a class "delay_calculator", with methods you call
from your modified delay block. You can test that very easily isolated.
> And a problem if I want to change the
> Delay block for your solution (FFT).
Well, yes, if you change approaches, the old approach will no longer
apply. That's a design decision you'll have to make.
>
> Really the delay is in the non-modulated signal.
I don't understand this sentence, sorry.
Greetings,
Marcus
>
>
>
> 2014-10-08 13:43 GMT+02:00 Jeff Long <address@hidden>:
>
>> 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 your receiver and the
>> real world, that's normal and you have to find ways to deal with it.
>>
>> - Jeff
>>
>> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>>
>>> 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 10230000 samples the delay block is entering the
>>> delay in signal time = 1 second.
>>> 1 second in the real world (later I replay the signal with a USRP).
>>>
>>> 2014-10-08 13:18 GMT+02:00 Martin Braun <address@hidden
>>> <mailto:address@hidden>>:
>>>
>>> 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 10230000 samples are one
>>> second
>>> > (in the real world).
>>> >
>>> > In the first graph I have two clocks (counters samples). When
>>> passing
>>> > 102300 samples it increase0.01 seconds.
>>> > In the first watchthis time controls the position of the
>>> satellite and
>>> > hisdelay in this time. It allows to know what signal time is
>>> passing in
>>> > the delay block.
>>> >
>>> >
>>> > But I have a problem: clock 2 (a test clock) and clock 1 haven't the
>>> > same time; it has a drift.
>>> >
>>> >
>>> > Then, I must use clock 2 (
>>> > count the samples in the delay block output, not input). But it
>>> creates
>>> > a loop.
>>> >
>>> >
>>> >
>>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller <address@hidden
>>> <mailto:address@hidden>
>>> > <mailto:address@hidden <mailto:address@hidden
>>>>>> :
>>> >
>>> > Hello Carlos,
>>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>>> > > I generate the signal from a file (10230000 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 samples pass
>>> through
>>> > your processing chain (ie. GNU Radio). It is the time base at
>>> which they
>>> > are measured, or simulated to, mathematically.
>>> > The device/software that actually captures the samples and
>>> saves them
>>> > has a fixed clock. If that clock changes too much a) compensate
>>> that in
>>> > software, if possible or b) get a better device.
>>> > This is digital signal processing. Real world time has *no*
>>> meaning
>>> > here, everything is measured relative to the interval between
>>> two
>>> > sampling times. You can process the signal as fast or slow as
>>> you want
>>> > to (as long as that doesn't lead to things like overflows), and
>>> nothing
>>> > in the processing chain should care.
>>> > >
>>> > > - 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 don't understand your graph, sorry :(
>>> >
>>> > Greetings,
>>> > Marcus
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden <mailto:address@hidden>
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
[Prev in Thread] | Current Thread | [Next in Thread] |