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

[Martin Braun]

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 calling it from other blocks, though.

Cheers,
M
> 
> 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo
> <address@hidden <mailto: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 <mailto: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 <mailto: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
>             <mailto: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>
>             >>> <mailto: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>>
>             >>>      > <mailto: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>
>             <mailto:address@hidden
>             <mailto:address@hidden>>
>             >>>      >
>             https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>             >>>      >
>             >>>
>             >>>
>             >>>     _______________________________________________
>             >>>     Discuss-gnuradio mailing list
>             >>>     address@hidden
>             <mailto:address@hidden>
>             <mailto: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 <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
>