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

[Marcus Müller]

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 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 <
> address@hidden>:
>
>> And a question. In:
>>
>> uint64_t
>> <http://gnuradio.org/doc/doxygen/stdint_8h.html#aec6fcb673ff035718c238c8c9d544c47>
>> 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>:
>>
>>> 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 <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
>>>>>>
>>>>