Re: [Discuss-gnuradio] Time sinks out of sync after adding and removing noise in simple FSK simulation

[James Wanga]

That's really helps me understand what's happening, thank you. I'm curious if 
this can be solved by sending packets instead of raw bytes. Is it correct to 
assume that sequence detection is one of the responsibilities of a packet 
decoder? I'm also curious if I there is any advantage to using a clock recovery 
block and binary slicer instead of the monolithic GFSK demod block? Stated 
another way. Is the GFSK demod block just a quadrature demod, clock recovery, 
and binary slicer rolled into one? 

Another thought is, once you loose symbol timing, do I need to then dynamically 
tweak the clock recovery settings (like mu) in order to realign?

James Wanga

> On Sep 14, 2017, at 7:20 AM, Kevin Reid  wrote:
> 
>> On Thu, Sep 14, 2017 at 12:08 AM, James Wanga  wrote:
>> I recently decided to simulate an FSK modulation scheme with a constant 
>> source, a noice source and 2 time sinks. The first time sink is 
>> pre-modulation and the second is post-modulation. When I first start the 
>> simulation, both time sinks display the same waveform as expected. When I 
>> add a strong noise signal in real time via a GUI entry the post-modulation 
>> time sink displays a randomly changing waveform again, as expected. However, 
>> when I reduce the noise source to 0, the post-modulated sink stabilizes to 
>> match the pre-modulated sink except that it is translated arbitrarily to the 
>> left or right. this causes an arbitrary byte to be spit out when the bits 
>> are repacked.
> 
> This is not an effect of your simulation but an actual problem in digital 
> communication.
> 
> When you introduce noise, the GFSK Demod loses track of the actual symbol 
> timing and so its estimate drifts freely. When you remove the noise, it locks 
> on again starting at who-knows-what symbol out of your 8-symbol groups. The 
> same problem would occur in a real receiver which does not share a clock with 
> the transmitter, because you start in the no-information state.
> 
> If you want to recover properly aligned bytes (or packets, even) you need a 
> way to detect where one begins. This is usually done with a known sequence of 
> symbols at the beginning of a transmission. Unfortunately, I don't have 
> experience with the digital blocks available in GNU Radio so I cannot tell 
> you how to construct a working example.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time sinks out of sync after adding and removing noise in simple FSK simulation

[Kevin Reid]

On Thu, Sep 14, 2017 at 12:08 AM, James Wanga  wrote:

> I recently decided to simulate an FSK modulation scheme with a constant
> source, a noice source and 2 time sinks. The first time sink is
> pre-modulation and the second is post-modulation. When I first start the
> simulation, both time sinks display the same waveform as expected. When I
> add a strong noise signal in real time via a GUI entry the post-modulation
> time sink displays a randomly changing waveform again, as expected.
> However, when I reduce the noise source to 0, the post-modulated sink
> stabilizes to match the pre-modulated sink except that it is translated
> arbitrarily to the left or right. this causes an arbitrary byte to be spit
> out when the bits are repacked.
>

This is not an effect of your simulation but an actual problem in digital
communication.

When you introduce noise, the GFSK Demod loses track of the actual symbol
timing and so its estimate drifts freely. When you remove the noise, it
locks on again starting at who-knows-what symbol out of your 8-symbol
groups. The same problem would occur in a real receiver which does not
share a clock with the transmitter, because you start in the no-information
state.

If you want to recover properly aligned bytes (or packets, even) you need a
way to detect where one begins. This is usually done with a known sequence
of symbols at the beginning of a transmission. Unfortunately, I don't have
experience with the digital blocks available in GNU Radio so I cannot tell
you how to construct a working example.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Markus Heller]

my experiments with an arbitrary GPS module offering a PPS discipline
showed that it is easily archievable to create a local clock (ntpd
based) with a clock precision of 1 microsecond even with cheap low-power
soc computers: I was using a Raspberry Pi. 

The most interesting finding was the clock drift in correlation with the
air pressure. Air pressure change obviously influences the quarz on the
raspberrypi. 

http://www.dl8rds.de/index.php/NTP-Server_with_Raspberry_Pi_and_Sure_Electronics_GPS_Eval_board

vy73
markus
dl8rds

Am Mittwoch, den 16.08.2017, 22:27 +0200 schrieb Marcus Müller:
> 10 ms timing certainty is actually pretty hard to achieve across USB2!
> But: as far as I can see, it'd be rather easy to say, tune both sticks
> to DVB-T, cross-correlate to find the relative offset, tune to the
> frequency of interest and work from there. That is, if the delay spread
> in the cellular channel < 10ms, but considering that would be equivalent
> to a path length difference of 3000 km...
> 
> I don't think the tuning process itself would interrupt the sampling,
> right (Sylvain)?
> 
> Cheers,
> Marcus
> 
> 
> On 08/16/2017 07:40 PM, b.shube...@sirinsoftware.com wrote:
> > Say we need +-10ms accuracy in timestamps. Precision Time Protocol in LAN 
> > should sync PC's clocks with enough accuracy. 
> > And then using USRP-like methods - set current/start time - get first 
> > sample in known time? Of course USB will add
> > undetermined delays but no external GPS required.
> >
> > On Wed, 2017-08-16 at 16:57 +0100, Derek Kozel wrote:
> >> It should be pointed out that the hardware based timestamping is only 
> >> needed if you need time alignment better than a
> >> half second or so. With USB transfers, various buffers, NTP based 
> >> alignment of the host computer's time, and some
> >> extra code on the host side you could do a coarse time alignment, probably 
> >> with less than a half second of error.
> >>
> >> You could also time align the streams if both radios receive the same 
> >> signal and you know the distance (and other
> >> details depending on the precision needed) between the transmitter and 
> >> your two receivers. This is done by many
> >> protocols like the cellular standards to create a distributed timebase, 
> >> but quickly becomes non-trivial.
> >>
> >> The B200 does timestamping in the FPGA and can use a 1PPS signal to align 
> >> to GPS time. It is more expensive than the
> >> HackRF, but much less than the $3000 mentioned above.
> >>
> >> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:
> >>> On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
>  What type of hardware? I thought from hardware point of view only 
>  precise clock is required and all the other
> >>> things in
>  firmware. I've naively thought i could modify hackrf firmware to get 
>  this feature.
> >>> Mostly a FPGA and a PPS input from a GPS receiver.
> >>>
> >>> Each individual sample has a timestamp of when it has been received.
> >>> And you can also reset the timestamp on the next  PPS edge.
> >>>
> >>> Technically it would be possible to modify the hackrf firmware and
> >>> repurpose some GPIOs and have all samples transmitted to the host be
> >>> in timestamped packets and implements timestamping in the on-board
> >>> ARM.
> >>> For additional hardware you'd only need an external GPS receiver (or
> >>> some other way to have both a single freq reference + single sync
> >>> pulse).
> >>>
> >>> Cheers,
> >>>
> >>> Sylvain
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Markus Heller]

In case of a multilateration attempt, please consider this presentation:

https://www.youtube.com/watch?v=Km4TU17b05s

vy73
markus
dl8rds

Am Donnerstag, den 17.08.2017, 01:52 +1000 schrieb
vk4...@tech-software.net:
> Are you trying to do MultiLateration using software defined radio ?
> 
> 
> -Original Message-
> From: Sylvain Munaut [mailto:246...@gmail.com] 
> Sent: Thursday, 17 August 2017 1:20 AM
> To: b.shube...@sirinsoftware.com
> Cc: vk4...@tech-software.net; GNURadio Discussion List 
> <discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] Time syncing between SDRs on different 
> computers
> 
> On Wed, Aug 16, 2017 at 5:11 PM,  <b.shube...@sirinsoftware.com> wrote:
> > What type of hardware? I thought from hardware point of view only 
> > precise clock is required and all the other things in firmware. I've 
> > naively thought i could modify hackrf firmware to get this feature.
> 
> Mostly a FPGA and a PPS input from a GPS receiver.
> 
> Each individual sample has a timestamp of when it has been received.
> And you can also reset the timestamp on the next  PPS edge.
> 
> Technically it would be possible to modify the hackrf firmware and repurpose 
> some GPIOs and have all samples transmitted to the host be in timestamped 
> packets and implements timestamping in the on-board ARM.
> For additional hardware you'd only need an external GPS receiver (or some 
> other way to have both a single freq reference + single sync pulse).
> 
> Cheers,
> 
> Sylvain
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Marcus Müller]

10 ms timing certainty is actually pretty hard to achieve across USB2!
But: as far as I can see, it'd be rather easy to say, tune both sticks
to DVB-T, cross-correlate to find the relative offset, tune to the
frequency of interest and work from there. That is, if the delay spread
in the cellular channel < 10ms, but considering that would be equivalent
to a path length difference of 3000 km...

I don't think the tuning process itself would interrupt the sampling,
right (Sylvain)?

Cheers,
Marcus


On 08/16/2017 07:40 PM, b.shube...@sirinsoftware.com wrote:
> Say we need +-10ms accuracy in timestamps. Precision Time Protocol in LAN 
> should sync PC's clocks with enough accuracy. 
> And then using USRP-like methods - set current/start time - get first sample 
> in known time? Of course USB will add
> undetermined delays but no external GPS required.
>
> On Wed, 2017-08-16 at 16:57 +0100, Derek Kozel wrote:
>> It should be pointed out that the hardware based timestamping is only needed 
>> if you need time alignment better than a
>> half second or so. With USB transfers, various buffers, NTP based alignment 
>> of the host computer's time, and some
>> extra code on the host side you could do a coarse time alignment, probably 
>> with less than a half second of error.
>>
>> You could also time align the streams if both radios receive the same signal 
>> and you know the distance (and other
>> details depending on the precision needed) between the transmitter and your 
>> two receivers. This is done by many
>> protocols like the cellular standards to create a distributed timebase, but 
>> quickly becomes non-trivial.
>>
>> The B200 does timestamping in the FPGA and can use a 1PPS signal to align to 
>> GPS time. It is more expensive than the
>> HackRF, but much less than the $3000 mentioned above.
>>
>> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:
>>> On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
 What type of hardware? I thought from hardware point of view only precise 
 clock is required and all the other
>>> things in
 firmware. I've naively thought i could modify hackrf firmware to get this 
 feature.
>>> Mostly a FPGA and a PPS input from a GPS receiver.
>>>
>>> Each individual sample has a timestamp of when it has been received.
>>> And you can also reset the timestamp on the next  PPS edge.
>>>
>>> Technically it would be possible to modify the hackrf firmware and
>>> repurpose some GPIOs and have all samples transmitted to the host be
>>> in timestamped packets and implements timestamping in the on-board
>>> ARM.
>>> For additional hardware you'd only need an external GPS receiver (or
>>> some other way to have both a single freq reference + single sync
>>> pulse).
>>>
>>> Cheers,
>>>
>>> Sylvain
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Vitt Benv]

In my experience "rf inserting" 1pps into early receiver (sampler) stages,
maybe "coding" timing with 1pps && 10Hz, all derived from gps reference.
This "affect" the signal under analysis but that can be do only
periodically... for multilateration ;-)

Victor

Il 16 ago 2017 19:45,  ha scritto:

> No.
>
> On Thu, 2017-08-17 at 01:52 +1000, vk4...@tech-software.net wrote:
> > Are you trying to do MultiLateration using software defined radio ?
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[b . shubenok]

No.

On Thu, 2017-08-17 at 01:52 +1000, vk4...@tech-software.net wrote:
> Are you trying to do MultiLateration using software defined radio ?
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[b . shubenok]

Say we need +-10ms accuracy in timestamps. Precision Time Protocol in LAN 
should sync PC's clocks with enough accuracy. 
And then using USRP-like methods - set current/start time - get first sample in 
known time? Of course USB will add
undetermined delays but no external GPS required.

On Wed, 2017-08-16 at 16:57 +0100, Derek Kozel wrote:
> It should be pointed out that the hardware based timestamping is only needed 
> if you need time alignment better than a
> half second or so. With USB transfers, various buffers, NTP based alignment 
> of the host computer's time, and some
> extra code on the host side you could do a coarse time alignment, probably 
> with less than a half second of error.
> 
> You could also time align the streams if both radios receive the same signal 
> and you know the distance (and other
> details depending on the precision needed) between the transmitter and your 
> two receivers. This is done by many
> protocols like the cellular standards to create a distributed timebase, but 
> quickly becomes non-trivial.
> 
> The B200 does timestamping in the FPGA and can use a 1PPS signal to align to 
> GPS time. It is more expensive than the
> HackRF, but much less than the $3000 mentioned above.
> 
> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:
> > On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
> > > What type of hardware? I thought from hardware point of view only precise 
> > > clock is required and all the other
> > things in
> > > firmware. I've naively thought i could modify hackrf firmware to get this 
> > > feature.
> > 
> > Mostly a FPGA and a PPS input from a GPS receiver.
> > 
> > Each individual sample has a timestamp of when it has been received.
> > And you can also reset the timestamp on the next  PPS edge.
> > 
> > Technically it would be possible to modify the hackrf firmware and
> > repurpose some GPIOs and have all samples transmitted to the host be
> > in timestamped packets and implements timestamping in the on-board
> > ARM.
> > For additional hardware you'd only need an external GPS receiver (or
> > some other way to have both a single freq reference + single sync
> > pulse).
> > 
> > Cheers,
> > 
> > Sylvain
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[mleech]

I have time-synchronized RTLSDRs using a known, pseudo-random, sequence
injected into the RX inputs using directional couplers.   These all had
a common clock so they wouldn't drift apart. 

On 2017-08-16 11:57, Derek Kozel wrote:

> It should be pointed out that the hardware based timestamping is only needed 
> if you need time alignment better than a half second or so. With USB 
> transfers, various buffers, NTP based alignment of the host computer's time, 
> and some extra code on the host side you could do a coarse time alignment, 
> probably with less than a half second of error.
> 
> You could also time align the streams if both radios receive the same signal 
> and you know the distance (and other details depending on the precision 
> needed) between the transmitter and your two receivers. This is done by many 
> protocols like the cellular standards to create a distributed timebase, but 
> quickly becomes non-trivial.
> 
> The B200 does timestamping in the FPGA and can use a 1PPS signal to align to 
> GPS time. It is more expensive than the HackRF, but much less than the $3000 
> mentioned above. 
> 
> On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:
> 
>> On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
>>> What type of hardware? I thought from hardware point of view only precise 
>>> clock is required and all the other things in
>>> firmware. I've naively thought i could modify hackrf firmware to get this 
>>> feature.
>> 
>> Mostly a FPGA and a PPS input from a GPS receiver.
>> 
>> Each individual sample has a timestamp of when it has been received.
>> And you can also reset the timestamp on the next  PPS edge.
>> 
>> Technically it would be possible to modify the hackrf firmware and
>> repurpose some GPIOs and have all samples transmitted to the host be
>> in timestamped packets and implements timestamping in the on-board
>> ARM.
>> For additional hardware you'd only need an external GPS receiver (or
>> some other way to have both a single freq reference + single sync
>> pulse).
>> 
>> Cheers,
>> 
>> Sylvain
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 

Links:
--
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Derek Kozel]

It should be pointed out that the hardware based timestamping is only
needed if you need time alignment better than a half second or so. With USB
transfers, various buffers, NTP based alignment of the host computer's
time, and some extra code on the host side you could do a coarse time
alignment, probably with less than a half second of error.

You could also time align the streams if both radios receive the same
signal and you know the distance (and other details depending on the
precision needed) between the transmitter and your two receivers. This is
done by many protocols like the cellular standards to create a distributed
timebase, but quickly becomes non-trivial.

The B200 does timestamping in the FPGA and can use a 1PPS signal to align
to GPS time. It is more expensive than the HackRF, but much less than the
$3000 mentioned above.

On Wed, Aug 16, 2017 at 4:20 PM, Sylvain Munaut <246...@gmail.com> wrote:

> On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
> > What type of hardware? I thought from hardware point of view only
> precise clock is required and all the other things in
> > firmware. I've naively thought i could modify hackrf firmware to get
> this feature.
>
> Mostly a FPGA and a PPS input from a GPS receiver.
>
> Each individual sample has a timestamp of when it has been received.
> And you can also reset the timestamp on the next  PPS edge.
>
> Technically it would be possible to modify the hackrf firmware and
> repurpose some GPIOs and have all samples transmitted to the host be
> in timestamped packets and implements timestamping in the on-board
> ARM.
> For additional hardware you'd only need an external GPS receiver (or
> some other way to have both a single freq reference + single sync
> pulse).
>
> Cheers,
>
> Sylvain
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[vk4tec]

Are you trying to do MultiLateration using software defined radio ?


-Original Message-
From: Sylvain Munaut [mailto:246...@gmail.com] 
Sent: Thursday, 17 August 2017 1:20 AM
To: b.shube...@sirinsoftware.com
Cc: vk4...@tech-software.net; GNURadio Discussion List 
<discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

On Wed, Aug 16, 2017 at 5:11 PM,  <b.shube...@sirinsoftware.com> wrote:
> What type of hardware? I thought from hardware point of view only 
> precise clock is required and all the other things in firmware. I've naively 
> thought i could modify hackrf firmware to get this feature.

Mostly a FPGA and a PPS input from a GPS receiver.

Each individual sample has a timestamp of when it has been received.
And you can also reset the timestamp on the next  PPS edge.

Technically it would be possible to modify the hackrf firmware and repurpose 
some GPIOs and have all samples transmitted to the host be in timestamped 
packets and implements timestamping in the on-board ARM.
For additional hardware you'd only need an external GPS receiver (or some other 
way to have both a single freq reference + single sync pulse).

Cheers,

Sylvain


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Sylvain Munaut]

On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
> What type of hardware? I thought from hardware point of view only precise 
> clock is required and all the other things in
> firmware. I've naively thought i could modify hackrf firmware to get this 
> feature.

Mostly a FPGA and a PPS input from a GPS receiver.

Each individual sample has a timestamp of when it has been received.
And you can also reset the timestamp on the next  PPS edge.

Technically it would be possible to modify the hackrf firmware and
repurpose some GPIOs and have all samples transmitted to the host be
in timestamped packets and implements timestamping in the on-board
ARM.
For additional hardware you'd only need an external GPS receiver (or
some other way to have both a single freq reference + single sync
pulse).

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[b . shubenok]

What type of hardware? I thought from hardware point of view only precise clock 
is required and all the other things in
firmware. I've naively thought i could modify hackrf firmware to get this 
feature.

On Wed, 2017-08-16 at 17:04 +0200, Sylvain Munaut wrote:
> The USRP have dedicated hardware to support that kind of stuff, the
> rtl-sdr and hackrf do not.
> That's the kind of advanced features that are cut to reduce the price ...
> 
> Cheers,
> 
> Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[vk4tec]

$30 vs $300 $3000

-Original Message-
From: Sylvain Munaut [mailto:246...@gmail.com] 
Sent: Thursday, 17 August 2017 1:04 AM
To: b.shube...@sirinsoftware.com
Cc: vk4...@tech-software.net; GNURadio Discussion List 
<discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

The USRP have dedicated hardware to support that kind of stuff, the rtl-sdr and 
hackrf do not.
That's the kind of advanced features that are cut to reduce the price ...

Cheers,

Sylvain


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Sylvain Munaut]

The USRP have dedicated hardware to support that kind of stuff, the
rtl-sdr and hackrf do not.
That's the kind of advanced features that are cut to reduce the price ...

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[b . shubenok]

In two words - receive signal in two points in space and process them 
accordingly to timestamps.

On Wed, 2017-08-16 at 23:40 +1000, vk4...@tech-software.net wrote:
> RTL-SDR has no time - it's a dumb A/D with a XTAL
> 
> Same with Hack RF
> 
> What ru trying to do
> 
> A
> 
> -Original Message-
> From: Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+vk4tec=tech-software@gnu.org] On Behalf
> Of b.shube...@sirinsoftware.com
> Sent: Wednesday, 16 August 2017 11:22 PM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Time syncing between SDRs on different computers
> 
> Hi,
> 
> Reading through archive I've found a thread describing how to sync time
> between two USRPs on different computers using set_time_now and
> set_start_time methods. Unfortunately I have only RTL-SDR now (and will have
> HackRF in a few weeks). As far as I can see there are no such methods in
> RTL-SDR osmocom source.
> 
> Is it possible to add them to the driver code or it is only available on
> certain hardware platforms? If so which platforms support them? Will they
> work on HackRF?
> 
> Thanks in advance,
> Bohdan Shubenok.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[vk4tec]

RTL-SDR has no time - it's a dumb A/D with a XTAL

Same with Hack RF

What ru trying to do

A

-Original Message-
From: Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+vk4tec=tech-software@gnu.org] On Behalf
Of b.shube...@sirinsoftware.com
Sent: Wednesday, 16 August 2017 11:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Time syncing between SDRs on different computers

Hi,

Reading through archive I've found a thread describing how to sync time
between two USRPs on different computers using set_time_now and
set_start_time methods. Unfortunately I have only RTL-SDR now (and will have
HackRF in a few weeks). As far as I can see there are no such methods in
RTL-SDR osmocom source.

Is it possible to add them to the driver code or it is only available on
certain hardware platforms? If so which platforms support them? Will they
work on HackRF?

Thanks in advance,
Bohdan Shubenok.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time syncing between SDRs on different computers

[b . shubenok]

Hi,

Reading through archive I've found a thread describing how to sync time between 
two USRPs on different computers using
set_time_now and set_start_time methods. Unfortunately I have only RTL-SDR now 
(and will have HackRF in a few weeks). As
far as I can see there are no such methods in RTL-SDR osmocom source.

Is it possible to add them to the driver code or it is only available on 
certain hardware platforms? If so which
platforms support them? Will they work on HackRF?

Thanks in advance,
Bohdan Shubenok.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Marcus,

Seems like that did the trick! I also ran the command

ln -s /dev/null /tmp/nirvana.hdr

(the directory and file names I used for the last argument were different
for my system but I modified them here for the sake of consistency)

As without that I was getting a very small header file containing the tags
that I was not recording in that directory, which kept overwriting itself
and was very small/inconsequential, but no point in leaving it there.

I'll have to run some tests before I field this system but I think I'm all
set and this is definitely progress.

Thanks everyone

-Mike G

On Tue, Aug 16, 2016 at 11:14 PM Marcus Müller 
wrote:

> You could try by creating a symbolic link to /dev/null somewhere you can
> create arbitrary files; eg.
>
> ln -s /dev/null /tmp/nirvana
>
> and use that instead of /dev/null
>
> On 16.08.2016 23:40, Derek Kozel wrote:
>
> Hello Michael,
>
> Unfortunately we've reached past my depth in the file sinks and tags.
> Hopefully someone with more experience can step in at this point. My guess
> with the detached headers is that Nate's trick with the filenames and
> /dev/null fails because there's a suffix being added for the detached
> header and /dev/null.metadata (or whatever the suffix is) doesn't exist.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo 
> wrote:
>
>> Derek,
>>
>> Funny you should mention the file meta sink block... originally that was
>> what we had implemented using a copy block to create the push button
>> recording functionality, but that introduced errors in the alignment
>> between headers and the IQ data since the copy block did not play nice with
>> absolute item numbers.
>>
>> I was hoping that writing to a null file would then produce() as much
>> data and keep the headers and IQ data in sync so I tried using the same
>> file name construction used in Nate's flowgraph with .dat replaced with
>> .cfile
>> (prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if
>> recording_checkbox else "/dev/null"), but I am noticing a few problems
>> again.
>>
>> If the meta data file sink is set to have a detached header, which would
>> be ideal, I get a runtime error when I try to run the flowgraph
>> (RuntimeError: file_meta_sink: can't open file).
>>
>> On the other hand, with the detached header field turned off, the
>> recording process doesn't throw any errors and everything appears to
>> function the way I'd like. However when playing back one of these recorded
>> files using a file meta source, I get the following error:
>>
>> RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31
>>
>> Not sure what to make of either of these.
>>
>> Thanks again,
>>
>> Mike G
>>
>>
>> On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel 
>> wrote:
>>
>>> I'd recommend leaving the filenames as is. The call to the mboard sensor
>>> will cause delays and doesn't reflect the time that the samples actually
>>> were acquired. Instead change to using a File Meta Sync which will store
>>> the timestamp tags produced by the USRP and gr-uhd. These contain the
>>> USRP's internal time which eliminates most sources of error in the time
>>> stamps. Setting the USRP's internal time is covered in the manual and a few
>>> times on the list. If you have any trouble with that please let us know.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
>>> wrote:
>>>
 Marcus,

 Thanks for getting back to me so quickly.

 I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
 output of uhd_usrp_probe is as follows:

 linux; GNU C++ version 4.8.4; Boost_105400;
 UHD_003.010.git-156-g2d68f228

 Thanks again,

 Mike G


 On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller <
 marcus.muel...@ettus.com> wrote:

> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples
> of data while viewing the spectrum (the user can watch a waterfall display
> of the readings being taken on an Ettus x310, and press and hold a button
> to record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink
> block in GRC seem to be the perfect solution to this, but I'm noticing an
> error whenever i change the frequency during execution. The timestamps
> recorded in the resulting filenames rapidly jump ahead in time (easily
> confirmed by comparing the filenames to the output of the tag debug block
> or writing the same data to a metadata file and reading its header). When
> I'm using my GPSDO as a time source, the time starts 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Marcus Müller]

You could try by creating a symbolic link to /dev/null somewhere you can
create arbitrary files; eg.

ln -s /dev/null /tmp/nirvana

and use that instead of /dev/null


On 16.08.2016 23:40, Derek Kozel wrote:
> Hello Michael,
>
> Unfortunately we've reached past my depth in the file sinks and tags.
> Hopefully someone with more experience can step in at this point. My
> guess with the detached headers is that Nate's trick with the
> filenames and /dev/null fails because there's a suffix being added for
> the detached header and /dev/null.metadata (or whatever the suffix is)
> doesn't exist.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo  > wrote:
>
> Derek,
>
> Funny you should mention the file meta sink block... originally
> that was what we had implemented using a copy block to create the
> push button recording functionality, but that introduced errors in
> the alignment between headers and the IQ data since the copy block
> did not play nice with absolute item numbers.
>
> I was hoping that writing to a null file would then produce() as
> much data and keep the headers and IQ data in sync so I tried
> using the same file name construction used in Nate's flowgraph
> with .dat replaced with .cfile
> (prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile"
> if recording_checkbox else "/dev/null"), but I am noticing a few
> problems again.
>
> If the meta data file sink is set to have a detached header, which
> would be ideal, I get a runtime error when I try to run the
> flowgraph (RuntimeError: file_meta_sink: can't open file). 
>
> On the other hand, with the detached header field turned off, the
> recording process doesn't throw any errors and everything appears
> to function the way I'd like. However when playing back one of
> these recorded files using a file meta source, I get the following
> error:
>
> RuntimeError: pmt::deserialize: malformed input stream, tag value
> = : 31
>
> Not sure what to make of either of these.
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  > wrote:
>
> I'd recommend leaving the filenames as is. The call to the
> mboard sensor will cause delays and doesn't reflect the time
> that the samples actually were acquired. Instead change to
> using a File Meta Sync which will store the timestamp tags
> produced by the USRP and gr-uhd. These contain the USRP's
> internal time which eliminates most sources of error in the
> time stamps. Setting the USRP's internal time is covered in
> the manual and a few times on the list. If you have any
> trouble with that please let us know.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo
> > wrote:
>
> Marcus,
>
> Thanks for getting back to me so quickly.
>
> I'm currently using an Ettus X310 with a UBX-160
> daughterboard, and the output of uhd_usrp_probe is as follows:
>
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.git-156-g2d68f228
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller
>  > wrote:
>
> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording
>> selected samples of data while viewing the spectrum
>> (the user can watch a waterfall display of the
>> readings being taken on an Ettus x310, and press and
>> hold a button to record data when the spectrum looks
>> interesting).
>>
>> The combination of the burst tagger block and the
>> tagged file sink block in GRC seem to be the perfect
>> solution to this, but I'm noticing an error whenever
>> i change the frequency during execution. The
>> timestamps recorded in the resulting filenames
>> rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag
>> debug block or writing the same data to a metadata
>> file and reading its header). When I'm using my GPSDO
>> as a time source, the time starts out in sync with
>> GPS but rapidly gets 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

Hello Michael,

Unfortunately we've reached past my depth in the file sinks and tags.
Hopefully someone with more experience can step in at this point. My guess
with the detached headers is that Nate's trick with the filenames and
/dev/null fails because there's a suffix being added for the detached
header and /dev/null.metadata (or whatever the suffix is) doesn't exist.

Regards,
Derek

On Tue, Aug 16, 2016 at 2:32 PM, Michael Giallorenzo 
wrote:

> Derek,
>
> Funny you should mention the file meta sink block... originally that was
> what we had implemented using a copy block to create the push button
> recording functionality, but that introduced errors in the alignment
> between headers and the IQ data since the copy block did not play nice with
> absolute item numbers.
>
> I was hoping that writing to a null file would then produce() as much data
> and keep the headers and IQ data in sync so I tried using the same file
> name construction used in Nate's flowgraph with .dat replaced with .cfile
> (prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if
> recording_checkbox else "/dev/null"), but I am noticing a few problems
> again.
>
> If the meta data file sink is set to have a detached header, which would
> be ideal, I get a runtime error when I try to run the flowgraph
> (RuntimeError: file_meta_sink: can't open file).
>
> On the other hand, with the detached header field turned off, the
> recording process doesn't throw any errors and everything appears to
> function the way I'd like. However when playing back one of these recorded
> files using a file meta source, I get the following error:
>
> RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31
>
> Not sure what to make of either of these.
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  wrote:
>
>> I'd recommend leaving the filenames as is. The call to the mboard sensor
>> will cause delays and doesn't reflect the time that the samples actually
>> were acquired. Instead change to using a File Meta Sync which will store
>> the timestamp tags produced by the USRP and gr-uhd. These contain the
>> USRP's internal time which eliminates most sources of error in the time
>> stamps. Setting the USRP's internal time is covered in the manual and a few
>> times on the list. If you have any trouble with that please let us know.
>>
>> Regards,
>> Derek
>>
>> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
>> wrote:
>>
>>> Marcus,
>>>
>>> Thanks for getting back to me so quickly.
>>>
>>> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
>>> output of uhd_usrp_probe is as follows:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>>>
>>> Thanks again,
>>>
>>> Mike G
>>>
>>>
>>> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
>>> wrote:
>>>
 Hi Michael,

 what USRP are you using, and which version of UHD?


 Best regards,

 Marcus

 On 16.08.2016 17:41, Michael Giallorenzo wrote:

 Hi everyone,

 I'm currently trying to develop a gui for recording selected samples of
 data while viewing the spectrum (the user can watch a waterfall display of
 the readings being taken on an Ettus x310, and press and hold a button to
 record data when the spectrum looks interesting).

 The combination of the burst tagger block and the tagged file sink
 block in GRC seem to be the perfect solution to this, but I'm noticing an
 error whenever i change the frequency during execution. The timestamps
 recorded in the resulting filenames rapidly jump ahead in time (easily
 confirmed by comparing the filenames to the output of the tag debug block
 or writing the same data to a metadata file and reading its header). When
 I'm using my GPSDO as a time source, the time starts out in sync with GPS
 but rapidly gets corrupted as i change the frequency. Likewise when I use
 relative time, timestamps start at 0 but increase too quickly.

 As far as I can tell, this is because the tagged file sink block is not
 seeing the rx_time tags on the data stream and is instead trying to
 calculate the time based on the sample rate, but is confused when the
 changing frequency results in extra tags that are effectively being
 generated faster than expected.

 I'm fairly new to gnuradio and my background isn't really software but
 I've been experimenting with OOT modules and have modified a few built in
 blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
 100, i believe time_tags_outer.size() is returning a value of 0 and that
 may be the source of my problems. Perhaps this stems from my lack of
 understanding of how the scheduler calls the work function (ie how is the
 value of noutput_items determined?), but I'm not 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Derek,

Funny you should mention the file meta sink block... originally that was
what we had implemented using a copy block to create the push button
recording functionality, but that introduced errors in the alignment
between headers and the IQ data since the copy block did not play nice with
absolute item numbers.

I was hoping that writing to a null file would then produce() as much data
and keep the headers and IQ data in sync so I tried using the same file
name construction used in Nate's flowgraph with .dat replaced with .cfile
(prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".cfile" if
recording_checkbox else "/dev/null"), but I am noticing a few problems
again.

If the meta data file sink is set to have a detached header, which would be
ideal, I get a runtime error when I try to run the flowgraph (RuntimeError:
file_meta_sink: can't open file).

On the other hand, with the detached header field turned off, the recording
process doesn't throw any errors and everything appears to function the way
I'd like. However when playing back one of these recorded files using a
file meta source, I get the following error:

RuntimeError: pmt::deserialize: malformed input stream, tag value = : 31

Not sure what to make of either of these.

Thanks again,

Mike G

On Tue, Aug 16, 2016 at 8:24 PM Derek Kozel  wrote:

> I'd recommend leaving the filenames as is. The call to the mboard sensor
> will cause delays and doesn't reflect the time that the samples actually
> were acquired. Instead change to using a File Meta Sync which will store
> the timestamp tags produced by the USRP and gr-uhd. These contain the
> USRP's internal time which eliminates most sources of error in the time
> stamps. Setting the USRP's internal time is covered in the manual and a few
> times on the list. If you have any trouble with that please let us know.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
> wrote:
>
>> Marcus,
>>
>> Thanks for getting back to me so quickly.
>>
>> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
>> output of uhd_usrp_probe is as follows:
>>
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>>
>> Thanks again,
>>
>> Mike G
>>
>>
>> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
>> wrote:
>>
>>> Hi Michael,
>>>
>>> what USRP are you using, and which version of UHD?
>>>
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>>
>>> Hi everyone,
>>>
>>> I'm currently trying to develop a gui for recording selected samples of
>>> data while viewing the spectrum (the user can watch a waterfall display of
>>> the readings being taken on an Ettus x310, and press and hold a button to
>>> record data when the spectrum looks interesting).
>>>
>>> The combination of the burst tagger block and the tagged file sink block
>>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>>> whenever i change the frequency during execution. The timestamps recorded
>>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>>> comparing the filenames to the output of the tag debug block or writing the
>>> same data to a metadata file and reading its header). When I'm using my
>>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>>> gets corrupted as i change the frequency. Likewise when I use relative
>>> time, timestamps start at 0 but increase too quickly.
>>>
>>> As far as I can tell, this is because the tagged file sink block is not
>>> seeing the rx_time tags on the data stream and is instead trying to
>>> calculate the time based on the sample rate, but is confused when the
>>> changing frequency results in extra tags that are effectively being
>>> generated faster than expected.
>>>
>>> I'm fairly new to gnuradio and my background isn't really software but
>>> I've been experimenting with OOT modules and have modified a few built in
>>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>>> may be the source of my problems. Perhaps this stems from my lack of
>>> understanding of how the scheduler calls the work function (ie how is the
>>> value of noutput_items determined?), but I'm not really sure how to modify
>>> this or really why this is happening.
>>>
>>> Sorry if my thoughts here are kind of all over the place. Any insight or
>>> reading material that anyone could offer would be greatly appreciated.
>>>
>>> Thanks,
>>>
>>> Mike G
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> 

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

I'd recommend leaving the filenames as is. The call to the mboard sensor
will cause delays and doesn't reflect the time that the samples actually
were acquired. Instead change to using a File Meta Sync which will store
the timestamp tags produced by the USRP and gr-uhd. These contain the
USRP's internal time which eliminates most sources of error in the time
stamps. Setting the USRP's internal time is covered in the manual and a few
times on the list. If you have any trouble with that please let us know.

Regards,
Derek

On Tue, Aug 16, 2016 at 1:02 PM, Michael Giallorenzo 
wrote:

> Marcus,
>
> Thanks for getting back to me so quickly.
>
> I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
> output of uhd_usrp_probe is as follows:
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228
>
> Thanks again,
>
> Mike G
>
>
> On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Derek,

Thanks for responding, that is indeed very close to the functionality I'm
after. However there is one small(?) deviation from what I'm after and that
is that I'm trying to use GPS time stamps with the intent of synchronized
acquisitions between separate X310 units at a later time.

To that end, I changed the filename in the file sink block to:

prefix +
str(self.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_real()) +
".dat" if recording_checkbox else "/dev/null"

And its throwing the error :
"IOError: [Errno 2] No such file or directory:
'/home/acquisitions/temp_1388780308.0.dat'"

Apparent loss of precision on the timestamp from the GPSDO aside, I am
confused as that directory (/home/acquisitions/) does exist and normally
the file would be created and written to (the append file field is still
set to "overwrite" and in this respect the block functions as intended when
the filename is set to datetime.now()...

I realize this changes the nature of my original question, but any further
help would be greatly appreciated!

-Mike G


On Tue, Aug 16, 2016 at 1:49 PM Derek Kozel  wrote:

> Hello Mike,
>
> Here is a simple, but clever, flowgraph put together by Nate Temple which
> does exactly what you describe. It isn't an answer to the time errors
> you've seen, but I hope it is useful anyways.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Marcus,

Thanks for getting back to me so quickly.

I'm currently using an Ettus X310 with a UBX-160 daughterboard, and the
output of uhd_usrp_probe is as follows:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-156-g2d68f228

Thanks again,

Mike G


On Tue, Aug 16, 2016 at 12:11 PM Marcus Müller 
wrote:

> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples of
> data while viewing the spectrum (the user can watch a waterfall display of
> the readings being taken on an Ettus x310, and press and hold a button to
> record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink block
> in GRC seem to be the perfect solution to this, but I'm noticing an error
> whenever i change the frequency during execution. The timestamps recorded
> in the resulting filenames rapidly jump ahead in time (easily confirmed by
> comparing the filenames to the output of the tag debug block or writing the
> same data to a metadata file and reading its header). When I'm using my
> GPSDO as a time source, the time starts out in sync with GPS but rapidly
> gets corrupted as i change the frequency. Likewise when I use relative
> time, timestamps start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is not
> seeing the rx_time tags on the data stream and is instead trying to
> calculate the time based on the sample rate, but is confused when the
> changing frequency results in extra tags that are effectively being
> generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built in
> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
> 100, i believe time_tags_outer.size() is returning a value of 0 and that
> may be the source of my problems. Perhaps this stems from my lack of
> understanding of how the scheduler calls the work function (ie how is the
> value of noutput_items determined?), but I'm not really sure how to modify
> this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight or
> reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael M]

I created an hier block that does exactly that: run it once, reload your
blocks, and then use the "QT GUI Record Button" block as a sink in other
flowgraphs.

Thank you Derek for sharing Nate's flowgraph - my block had been using a
selector block, and created a 0-byte file every time a flowgraph using it
was run. Using "if/then" in the file sink like Nate did eliminates that!

Best,
Michael Morrison

On Tue, Aug 16, 2016 at 12:47 PM, Derek Kozel  wrote:

> Hello Mike,
>
> Here is a simple, but clever, flowgraph put together by Nate Temple which
> does exactly what you describe. It isn't an answer to the time errors
> you've seen, but I hope it is useful anyways.
>
> Regards,
> Derek
>
> On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> what USRP are you using, and which version of UHD?
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>>
>> Hi everyone,
>>
>> I'm currently trying to develop a gui for recording selected samples of
>> data while viewing the spectrum (the user can watch a waterfall display of
>> the readings being taken on an Ettus x310, and press and hold a button to
>> record data when the spectrum looks interesting).
>>
>> The combination of the burst tagger block and the tagged file sink block
>> in GRC seem to be the perfect solution to this, but I'm noticing an error
>> whenever i change the frequency during execution. The timestamps recorded
>> in the resulting filenames rapidly jump ahead in time (easily confirmed by
>> comparing the filenames to the output of the tag debug block or writing the
>> same data to a metadata file and reading its header). When I'm using my
>> GPSDO as a time source, the time starts out in sync with GPS but rapidly
>> gets corrupted as i change the frequency. Likewise when I use relative
>> time, timestamps start at 0 but increase too quickly.
>>
>> As far as I can tell, this is because the tagged file sink block is not
>> seeing the rx_time tags on the data stream and is instead trying to
>> calculate the time based on the sample rate, but is confused when the
>> changing frequency results in extra tags that are effectively being
>> generated faster than expected.
>>
>> I'm fairly new to gnuradio and my background isn't really software but
>> I've been experimenting with OOT modules and have modified a few built in
>> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
>> 100, i believe time_tags_outer.size() is returning a value of 0 and that
>> may be the source of my problems. Perhaps this stems from my lack of
>> understanding of how the scheduler calls the work function (ie how is the
>> value of noutput_items determined?), but I'm not really sure how to modify
>> this or really why this is happening.
>>
>> Sorry if my thoughts here are kind of all over the place. Any insight or
>> reading material that anyone could offer would be greatly appreciated.
>>
>> Thanks,
>>
>> Mike G
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


push-to-record.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Derek Kozel]

Hello Mike,

Here is a simple, but clever, flowgraph put together by Nate Temple which
does exactly what you describe. It isn't an answer to the time errors
you've seen, but I hope it is useful anyways.

Regards,
Derek

On Tue, Aug 16, 2016 at 9:08 AM, Marcus Müller 
wrote:

> Hi Michael,
>
> what USRP are you using, and which version of UHD?
>
>
> Best regards,
>
> Marcus
>
> On 16.08.2016 17:41, Michael Giallorenzo wrote:
>
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples of
> data while viewing the spectrum (the user can watch a waterfall display of
> the readings being taken on an Ettus x310, and press and hold a button to
> record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink block
> in GRC seem to be the perfect solution to this, but I'm noticing an error
> whenever i change the frequency during execution. The timestamps recorded
> in the resulting filenames rapidly jump ahead in time (easily confirmed by
> comparing the filenames to the output of the tag debug block or writing the
> same data to a metadata file and reading its header). When I'm using my
> GPSDO as a time source, the time starts out in sync with GPS but rapidly
> gets corrupted as i change the frequency. Likewise when I use relative
> time, timestamps start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is not
> seeing the rx_time tags on the data stream and is instead trying to
> calculate the time based on the sample rate, but is confused when the
> changing frequency results in extra tags that are effectively being
> generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built in
> blocks to suit my needs before. In "tagged_file_sink_impl.cc" around line
> 100, i believe time_tags_outer.size() is returning a value of 0 and that
> may be the source of my problems. Perhaps this stems from my lack of
> understanding of how the scheduler calls the work function (ie how is the
> value of noutput_items determined?), but I'm not really sure how to modify
> this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight or
> reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


grc_recording.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Marcus Müller]

Hi Michael,

what USRP are you using, and which version of UHD?


Best regards,

Marcus


On 16.08.2016 17:41, Michael Giallorenzo wrote:
> Hi everyone,
>
> I'm currently trying to develop a gui for recording selected samples
> of data while viewing the spectrum (the user can watch a waterfall
> display of the readings being taken on an Ettus x310, and press and
> hold a button to record data when the spectrum looks interesting).
>
> The combination of the burst tagger block and the tagged file sink
> block in GRC seem to be the perfect solution to this, but I'm noticing
> an error whenever i change the frequency during execution. The
> timestamps recorded in the resulting filenames rapidly jump ahead in
> time (easily confirmed by comparing the filenames to the output of the
> tag debug block or writing the same data to a metadata file and
> reading its header). When I'm using my GPSDO as a time source, the
> time starts out in sync with GPS but rapidly gets corrupted as i
> change the frequency. Likewise when I use relative time, timestamps
> start at 0 but increase too quickly.
>
> As far as I can tell, this is because the tagged file sink block is
> not seeing the rx_time tags on the data stream and is instead trying
> to calculate the time based on the sample rate, but is confused when
> the changing frequency results in extra tags that are effectively
> being generated faster than expected.
>
> I'm fairly new to gnuradio and my background isn't really software but
> I've been experimenting with OOT modules and have modified a few built
> in blocks to suit my needs before. In "tagged_file_sink_impl.cc"
> around line 100, i believe time_tags_outer.size() is returning a value
> of 0 and that may be the source of my problems. Perhaps this stems
> from my lack of understanding of how the scheduler calls the work
> function (ie how is the value of noutput_items determined?), but I'm
> not really sure how to modify this or really why this is happening.
>
> Sorry if my thoughts here are kind of all over the place. Any insight
> or reading material that anyone could offer would be greatly appreciated.
>
> Thanks,
>
> Mike G
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time errors using burst tagger and tagged file sink

[Michael Giallorenzo]

Hi everyone,

I'm currently trying to develop a gui for recording selected samples of
data while viewing the spectrum (the user can watch a waterfall display of
the readings being taken on an Ettus x310, and press and hold a button to
record data when the spectrum looks interesting).

The combination of the burst tagger block and the tagged file sink block in
GRC seem to be the perfect solution to this, but I'm noticing an error
whenever i change the frequency during execution. The timestamps recorded
in the resulting filenames rapidly jump ahead in time (easily confirmed by
comparing the filenames to the output of the tag debug block or writing the
same data to a metadata file and reading its header). When I'm using my
GPSDO as a time source, the time starts out in sync with GPS but rapidly
gets corrupted as i change the frequency. Likewise when I use relative
time, timestamps start at 0 but increase too quickly.

As far as I can tell, this is because the tagged file sink block is not
seeing the rx_time tags on the data stream and is instead trying to
calculate the time based on the sample rate, but is confused when the
changing frequency results in extra tags that are effectively being
generated faster than expected.

I'm fairly new to gnuradio and my background isn't really software but I've
been experimenting with OOT modules and have modified a few built in blocks
to suit my needs before. In "tagged_file_sink_impl.cc" around line 100, i
believe time_tags_outer.size() is returning a value of 0 and that may be
the source of my problems. Perhaps this stems from my lack of understanding
of how the scheduler calls the work function (ie how is the value of
noutput_items determined?), but I'm not really sure how to modify this or
really why this is happening.

Sorry if my thoughts here are kind of all over the place. Any insight or
reading material that anyone could offer would be greatly appreciated.

Thanks,

Mike G
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Raster- Linux

[Marcus Müller]

Nope, same problem under Ubuntu 16.04LTS



On 10.07.2016 16:20, Marcus Müller wrote:
> Hi Ellie,
>
> you'd have to recompile GNU Radio to use a different version of QWT – I
> don't know how you've installed your current version, so this might be
> more or less complicated.
>
> I'll try to build a quick Ubuntu 16.04 container with GNU Radio from the
> Ubuntu package sources to see whether things work better there (because
> in that case, upgrading from 15.10 to 16.04 is what I'd recommend –
> especially since 16.04 is a LTS release)
>
>
> Best regards,
> Marcus
>
> On 10.07.2016 14:54, Ellie White wrote:
>> Hi Marcus,
>>
>> Thanks very much for the advice! I tried what you suggested ("stop",
>> "start", "autoscale", etc) but the time raster is stubbornly refusing to
>> work. I am beginning to think, like you said, that it may have something to
>> do with the QWT version installed.  So I am trying to upgrade to version 6
>> but I am getting confused because once I installed version 6.1.4 of QWT it
>> saved to my 'Home' folder so GNU Radio is still detecting version 5. Do you
>> have any tips on how I could get it to use QWT 6? (I tried searching the web
>> for instructions/hints but have yet to turn up anything useful!) Thank you
>> so much!
>>
>> -Ellie
>>
>> -Original Message-
>> From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
>> Sent: Saturday, July 9, 2016 9:21 AM
>> To: discuss-gnuradio@gnu.org; orionnebul...@outlook.com
>> Subject: Re: [Discuss-gnuradio] Time Raster- Linux
>>
>> Hi Ellie,
>>
>> not a silly question at all! And, first of all: Welcome to the GNU Radio
>> community!
>>
>> With 32kS/s, it's taking quite some time to build up something visible,
>> "pushing" out the solid yellow, but for me, this works (see screenshot
>> attached).
>>
>> So, this actually does sound like a bug, but I can't really put my finger on
>> where things might go wrong. A couple of ideas to try, sorted by
>> desperation:
>>
>> * middle mouse button on time raster canvas, "stop", middle mouse, "start"
>> * middle mouse button -> autoscale
>> * mmb -> save image (& inspect image)
>>
>> If none of that helps, my best guess is that this might have something to do
>> with the QWT version used – but as I've never saw that problem "in the
>> wild", that would surprise me a bit. Then again, the Time Raster Sink is not
>> the most popular (yet, one of the most helpful, I think) signal
>> visualization sink – so maybe this simply never came up.
>>
>> Actually, the warning that the visualization window nearly hides reads:
>>
>>  std::cerr << "Warning: QWT5 has been found which has serious performance
>> issues with raster plots."
>>
>> and so, maybe the performance issue is so severe that you simply see
>> nothing.
>>
>> Best regards,
>> Marcus
>>
>> On 07.07.2016 03:26, Ellie White wrote:
>>> Hello!
>>>
>>>  
>>>
>>> I am a new GNU Radio user and I have a question about the QT GUI Time 
>>> Raster sink in GNU Radio version 3.7.8.  I built a flowgraph (which is 
>>> attached as a .grc file) with a source connected to both a QT GUI Time 
>>> Sink and Time Raster. While the Time Sink displays the signal 
>>> properly, the Time Raster is blank and shows no signal, as shown in 
>>> the screen shot I included. I have tried to use the Time Raster tool 
>>> on Ubuntu - version 15.10 (it is a virtual machine running in 
>>> Windows), and cannot figure out why the time raster doesn’t appear to 
>>> display a signal. Am I doing something wrong, or is this a known 
>>> issue?  Thanks very much for your time and apologies if this is a 
>>> silly question.
>>>
>>>  
>>>
>>> -Ellie
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Raster- Linux

[Marcus Müller]

Hi Ellie,

you'd have to recompile GNU Radio to use a different version of QWT – I
don't know how you've installed your current version, so this might be
more or less complicated.

I'll try to build a quick Ubuntu 16.04 container with GNU Radio from the
Ubuntu package sources to see whether things work better there (because
in that case, upgrading from 15.10 to 16.04 is what I'd recommend –
especially since 16.04 is a LTS release)


Best regards,
Marcus

On 10.07.2016 14:54, Ellie White wrote:
> Hi Marcus,
>
> Thanks very much for the advice! I tried what you suggested ("stop",
> "start", "autoscale", etc) but the time raster is stubbornly refusing to
> work. I am beginning to think, like you said, that it may have something to
> do with the QWT version installed.  So I am trying to upgrade to version 6
> but I am getting confused because once I installed version 6.1.4 of QWT it
> saved to my 'Home' folder so GNU Radio is still detecting version 5. Do you
> have any tips on how I could get it to use QWT 6? (I tried searching the web
> for instructions/hints but have yet to turn up anything useful!) Thank you
> so much!
>
> -Ellie
>
> -Original Message-
> From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
> Sent: Saturday, July 9, 2016 9:21 AM
> To: discuss-gnuradio@gnu.org; orionnebul...@outlook.com
> Subject: Re: [Discuss-gnuradio] Time Raster- Linux
>
> Hi Ellie,
>
> not a silly question at all! And, first of all: Welcome to the GNU Radio
> community!
>
> With 32kS/s, it's taking quite some time to build up something visible,
> "pushing" out the solid yellow, but for me, this works (see screenshot
> attached).
>
> So, this actually does sound like a bug, but I can't really put my finger on
> where things might go wrong. A couple of ideas to try, sorted by
> desperation:
>
> * middle mouse button on time raster canvas, "stop", middle mouse, "start"
> * middle mouse button -> autoscale
> * mmb -> save image (& inspect image)
>
> If none of that helps, my best guess is that this might have something to do
> with the QWT version used – but as I've never saw that problem "in the
> wild", that would surprise me a bit. Then again, the Time Raster Sink is not
> the most popular (yet, one of the most helpful, I think) signal
> visualization sink – so maybe this simply never came up.
>
> Actually, the warning that the visualization window nearly hides reads:
>
>  std::cerr << "Warning: QWT5 has been found which has serious performance
> issues with raster plots."
>
> and so, maybe the performance issue is so severe that you simply see
> nothing.
>
> Best regards,
> Marcus
>
> On 07.07.2016 03:26, Ellie White wrote:
>> Hello!
>>
>>  
>>
>> I am a new GNU Radio user and I have a question about the QT GUI Time 
>> Raster sink in GNU Radio version 3.7.8.  I built a flowgraph (which is 
>> attached as a .grc file) with a source connected to both a QT GUI Time 
>> Sink and Time Raster. While the Time Sink displays the signal 
>> properly, the Time Raster is blank and shows no signal, as shown in 
>> the screen shot I included. I have tried to use the Time Raster tool 
>> on Ubuntu - version 15.10 (it is a virtual machine running in 
>> Windows), and cannot figure out why the time raster doesn’t appear to 
>> display a signal. Am I doing something wrong, or is this a known 
>> issue?  Thanks very much for your time and apologies if this is a 
>> silly question.
>>
>>  
>>
>> -Ellie
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Raster- Linux

[Ellie White]

Hi Marcus,

Thanks very much for the advice! I tried what you suggested ("stop",
"start", "autoscale", etc) but the time raster is stubbornly refusing to
work. I am beginning to think, like you said, that it may have something to
do with the QWT version installed.  So I am trying to upgrade to version 6
but I am getting confused because once I installed version 6.1.4 of QWT it
saved to my 'Home' folder so GNU Radio is still detecting version 5. Do you
have any tips on how I could get it to use QWT 6? (I tried searching the web
for instructions/hints but have yet to turn up anything useful!) Thank you
so much!

-Ellie

-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Saturday, July 9, 2016 9:21 AM
To: discuss-gnuradio@gnu.org; orionnebul...@outlook.com
Subject: Re: [Discuss-gnuradio] Time Raster- Linux

Hi Ellie,

not a silly question at all! And, first of all: Welcome to the GNU Radio
community!

With 32kS/s, it's taking quite some time to build up something visible,
"pushing" out the solid yellow, but for me, this works (see screenshot
attached).

So, this actually does sound like a bug, but I can't really put my finger on
where things might go wrong. A couple of ideas to try, sorted by
desperation:

* middle mouse button on time raster canvas, "stop", middle mouse, "start"
* middle mouse button -> autoscale
* mmb -> save image (& inspect image)

If none of that helps, my best guess is that this might have something to do
with the QWT version used – but as I've never saw that problem "in the
wild", that would surprise me a bit. Then again, the Time Raster Sink is not
the most popular (yet, one of the most helpful, I think) signal
visualization sink – so maybe this simply never came up.

Actually, the warning that the visualization window nearly hides reads:

 std::cerr << "Warning: QWT5 has been found which has serious performance
issues with raster plots."

and so, maybe the performance issue is so severe that you simply see
nothing.

Best regards,
Marcus

On 07.07.2016 03:26, Ellie White wrote:
>
> Hello!
>
>  
>
> I am a new GNU Radio user and I have a question about the QT GUI Time 
> Raster sink in GNU Radio version 3.7.8.  I built a flowgraph (which is 
> attached as a .grc file) with a source connected to both a QT GUI Time 
> Sink and Time Raster. While the Time Sink displays the signal 
> properly, the Time Raster is blank and shows no signal, as shown in 
> the screen shot I included. I have tried to use the Time Raster tool 
> on Ubuntu - version 15.10 (it is a virtual machine running in 
> Windows), and cannot figure out why the time raster doesn’t appear to 
> display a signal. Am I doing something wrong, or is this a known 
> issue?  Thanks very much for your time and apologies if this is a 
> silly question.
>
>  
>
> -Ellie
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Tom Rondeau]

On Fri, Apr 29, 2016 at 10:35 AM, Henning Bredenberg <
henning.bredenb...@tuhh.de> wrote:

> Hi Tom,
>
> That's what i thought the message strobe does. I tried different times but
> the time sink output doesn't change and shows a continuous signal flow. I
> changed the burst size in the random_pdu_generator but nothing changes. No
> matter what options are changed, the time sink shows a continuous stream
> with the "packet_lenght" tags from the pdu_to_tagged_stream-block as seen
> in the attached file (1k interval in the message strobe block, 256 Bytes
> generated).
>
> So i thought maybe the following blocks, after the generator and before
> the time sink, i.e. pdu_to_tagged_stream and the PSK_mod (GRC flow graph
> attached in the first post) just consume the items, produce output items
> and don't care about the time when a pdu was generated. That leads to the
> general question for me: At which rate is the pdu sent? how long is the
> transmission time for a fixed size pdu and how can I determine it?
>
>
> Thanks for taking time and have a nice weekend all.
> Best regards,
> Henning


Yes, that's exactly how this should behave. When you "stop" time in a
flowgraph, samples don't continuously flow. So even if you send a PDU at
time 0, wait a second, and send another, there is no data between the end
of the first PDU and the start of the second PDU even though 1 second has
elapsed in wall time.

One way that I've simulated the effect you're going for is to use a stream
mux with a null source as the second input. Have it pass the PDU from the
first stream, then calculate the number of samples of 0's you want between
PDUs and mux those in as the second stream.

Tom




>
> Quoting Tom Rondeau :
>
> On Fri, Apr 29, 2016 at 5:30 AM, Henning Bredenberg <
>> henning.bredenb...@tuhh.de> wrote:
>>
>> Hi Marcus,
>>>
>>> Thanks for your response. I realized that I have a more fundamental
>>> problem before optimizing this project:
>>> Can u give me hints on how I can generate one simple PDU? My flowgraph
>>> now
>>> keeps generating
>>> one PDU after the other and the time sink display is continuously filled
>>> with samples.
>>>
>>> In my understanding the different blocks create output items as long as
>>> input items are generated. In this case the flowgraph only stops when
>>> closed manuelly.  So I would need a generator block who generates one
>>> output item, i.e. one PDU, and then stops creating output items. Maybe it
>>> is possible to create one PDU following by output items that are just
>>> zeros? Is it possible to do that with the random_pdu_generator block or
>>> are
>>> there any other generation blocks that I should investigate?
>>>
>>> My goal in general is to generate one simple packet burst that fits into
>>> a
>>> 20 ms slot. I have issues with this first step, before changing things
>>> like
>>> adding delays etc.
>>>
>>>
>>> Best regards,
>>> Henning
>>>
>>
>>
>>
>> Henning,
>>
>> You can use the Random PDU Generator block to send just a single PDU into
>> your flowgraph. It has an input message port called "generate" that
>> triggers the block to send more PDUs. You can use the Message Strobe block
>> to make the Random PDU Generator post a message at given intervals. Or you
>> could use the new Edit Box Message (just merged into master yesterday) to
>> trigger a new PDU every time to press enter when in that box.
>>
>> Tom
>>
>>
>>
>>
>> Quoting Marcus Müller :
>>>
>>> Hi Henning,
>>>

 to only answer the first part of your questions:
 On 04/27/2016 03:22 PM, Henning Bredenberg wrote:

 Hi Martin,
>
> the time tag 'tx_time' tells the USRP when to transmit - so far so
> good. So I don't need any delay blocks because the USRP sink realizes
> the delay, right?
>
> Nearly! In fact, the USRP itself realizes that in hardware -- which is
 much, much better, because that hardware "knows" and runs at a rate
 directly linked to the sampling rate and LO frequencies; if your PC
 waited the 240ms of "PC clock time", that might be anything between 238
 and 300ms "USRP time", if we add non-deterministic delay of the USB
 transport for commands. So: there's a feature in the FPGA image that
 allows you to specify "hey, FPGA, I want you to execute that "start
 streaming" command *exactly* at the clock tick nr 12147, and it will do
 that.

 Assume i want to add a propagation delay of 240ms: Setting 'tx_time'
> at the begin of the burst to 240ms will realize that?
>
> No, you should first set the device time to something sensible (or just
 roll with it being set to zero on device initialization) and use
 relative times to that.
 Minor caveat: if you're using a device with adjustable master clock rate
 (mainly: B2xx and E31x), and you change the MCR after setting the time,
 the host won't know when that change of "tick rate" happened, and the
 

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Henning Bredenberg]

Hi Tom,

That's what i thought the message strobe does. I tried different times  
but the time sink output doesn't change and shows a continuous signal  
flow. I changed the burst size in the random_pdu_generator but nothing  
changes. No matter what options are changed, the time sink shows a  
continuous stream with the "packet_lenght" tags from the  
pdu_to_tagged_stream-block as seen in the attached file (1k interval  
in the message strobe block, 256 Bytes generated).


So i thought maybe the following blocks, after the generator and  
before the time sink, i.e. pdu_to_tagged_stream and the PSK_mod (GRC  
flow graph attached in the first post) just consume the items, produce  
output items and don't care about the time when a pdu was generated.  
That leads to the general question for me: At which rate is the pdu  
sent? how long is the transmission time for a fixed size pdu and how  
can I determine it?



Thanks for taking time and have a nice weekend all.
Best regards,
Henning


Quoting Tom Rondeau :


On Fri, Apr 29, 2016 at 5:30 AM, Henning Bredenberg <
henning.bredenb...@tuhh.de> wrote:


Hi Marcus,

Thanks for your response. I realized that I have a more fundamental
problem before optimizing this project:
Can u give me hints on how I can generate one simple PDU? My flowgraph now
keeps generating
one PDU after the other and the time sink display is continuously filled
with samples.

In my understanding the different blocks create output items as long as
input items are generated. In this case the flowgraph only stops when
closed manuelly.  So I would need a generator block who generates one
output item, i.e. one PDU, and then stops creating output items. Maybe it
is possible to create one PDU following by output items that are just
zeros? Is it possible to do that with the random_pdu_generator block or are
there any other generation blocks that I should investigate?

My goal in general is to generate one simple packet burst that fits into a
20 ms slot. I have issues with this first step, before changing things like
adding delays etc.


Best regards,
Henning




Henning,

You can use the Random PDU Generator block to send just a single PDU into
your flowgraph. It has an input message port called "generate" that
triggers the block to send more PDUs. You can use the Message Strobe block
to make the Random PDU Generator post a message at given intervals. Or you
could use the new Edit Box Message (just merged into master yesterday) to
trigger a new PDU every time to press enter when in that box.

Tom





Quoting Marcus Müller :

Hi Henning,


to only answer the first part of your questions:
On 04/27/2016 03:22 PM, Henning Bredenberg wrote:


Hi Martin,

the time tag 'tx_time' tells the USRP when to transmit - so far so
good. So I don't need any delay blocks because the USRP sink realizes
the delay, right?


Nearly! In fact, the USRP itself realizes that in hardware -- which is
much, much better, because that hardware "knows" and runs at a rate
directly linked to the sampling rate and LO frequencies; if your PC
waited the 240ms of "PC clock time", that might be anything between 238
and 300ms "USRP time", if we add non-deterministic delay of the USB
transport for commands. So: there's a feature in the FPGA image that
allows you to specify "hey, FPGA, I want you to execute that "start
streaming" command *exactly* at the clock tick nr 12147, and it will do
that.


Assume i want to add a propagation delay of 240ms: Setting 'tx_time'
at the begin of the burst to 240ms will realize that?


No, you should first set the device time to something sensible (or just
roll with it being set to zero on device initialization) and use
relative times to that.
Minor caveat: if you're using a device with adjustable master clock rate
(mainly: B2xx and E31x), and you change the MCR after setting the time,
the host won't know when that change of "tick rate" happened, and the
conversion between timestamps and tick numbers will be pretty random.

Best regards,
Marcus




Do I tag the burst in the code of the PDU-generator using
add_item_tag() or is there another block who does it after the
generator (I thought the pdu_to_tagged_stream - block tags the packet)?

The crucial code in the random_pdu_impl.cc is:
[...]
  // pick a random vector length
  int len = d_rvar();
  len = std::max(d_length_modulo, len - len%d_length_modulo);

  // fill it with random bytes
  std::vector vec(len);
  for (int i=0; i

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Tom Rondeau]

On Fri, Apr 29, 2016 at 5:30 AM, Henning Bredenberg <
henning.bredenb...@tuhh.de> wrote:

> Hi Marcus,
>
> Thanks for your response. I realized that I have a more fundamental
> problem before optimizing this project:
> Can u give me hints on how I can generate one simple PDU? My flowgraph now
> keeps generating
> one PDU after the other and the time sink display is continuously filled
> with samples.
>
> In my understanding the different blocks create output items as long as
> input items are generated. In this case the flowgraph only stops when
> closed manuelly.  So I would need a generator block who generates one
> output item, i.e. one PDU, and then stops creating output items. Maybe it
> is possible to create one PDU following by output items that are just
> zeros? Is it possible to do that with the random_pdu_generator block or are
> there any other generation blocks that I should investigate?
>
> My goal in general is to generate one simple packet burst that fits into a
> 20 ms slot. I have issues with this first step, before changing things like
> adding delays etc.
>
>
> Best regards,
> Henning



Henning,

You can use the Random PDU Generator block to send just a single PDU into
your flowgraph. It has an input message port called "generate" that
triggers the block to send more PDUs. You can use the Message Strobe block
to make the Random PDU Generator post a message at given intervals. Or you
could use the new Edit Box Message (just merged into master yesterday) to
trigger a new PDU every time to press enter when in that box.

Tom




> Quoting Marcus Müller :
>
> Hi Henning,
>>
>> to only answer the first part of your questions:
>> On 04/27/2016 03:22 PM, Henning Bredenberg wrote:
>>
>>> Hi Martin,
>>>
>>> the time tag 'tx_time' tells the USRP when to transmit - so far so
>>> good. So I don't need any delay blocks because the USRP sink realizes
>>> the delay, right?
>>>
>> Nearly! In fact, the USRP itself realizes that in hardware -- which is
>> much, much better, because that hardware "knows" and runs at a rate
>> directly linked to the sampling rate and LO frequencies; if your PC
>> waited the 240ms of "PC clock time", that might be anything between 238
>> and 300ms "USRP time", if we add non-deterministic delay of the USB
>> transport for commands. So: there's a feature in the FPGA image that
>> allows you to specify "hey, FPGA, I want you to execute that "start
>> streaming" command *exactly* at the clock tick nr 12147, and it will do
>> that.
>>
>>> Assume i want to add a propagation delay of 240ms: Setting 'tx_time'
>>> at the begin of the burst to 240ms will realize that?
>>>
>> No, you should first set the device time to something sensible (or just
>> roll with it being set to zero on device initialization) and use
>> relative times to that.
>> Minor caveat: if you're using a device with adjustable master clock rate
>> (mainly: B2xx and E31x), and you change the MCR after setting the time,
>> the host won't know when that change of "tick rate" happened, and the
>> conversion between timestamps and tick numbers will be pretty random.
>>
>> Best regards,
>> Marcus
>>
>>>
>>>
>>> Do I tag the burst in the code of the PDU-generator using
>>> add_item_tag() or is there another block who does it after the
>>> generator (I thought the pdu_to_tagged_stream - block tags the packet)?
>>>
>>> The crucial code in the random_pdu_impl.cc is:
>>> [...]
>>>   // pick a random vector length
>>>   int len = d_rvar();
>>>   len = std::max(d_length_modulo, len - len%d_length_modulo);
>>>
>>>   // fill it with random bytes
>>>   std::vector vec(len);
>>>   for (int i=0; i>> vec[i] = ((unsigned char) d_bvar()) & d_mask;
>>>
>>>   // send the vector
>>>   pmt::pmt_t vecpmt(pmt::make_blob([0], len));
>>>   pmt::pmt_t pdu(pmt::cons(pmt::PMT_NIL, vecpmt));
>>>
>>>   message_port_pub(PDU_PORT_ID, pdu);
>>> [...]
>>>
>>> My idea then is to use add_item_tag here with 'tx_time' as key for the
>>> output vector "PDU_PORT_ID", i.d. "pdus" in GRC.
>>>
>>> An additional question: How do I set a data rate that determines how
>>> long a packet needs to be transmitted? Is that done by USRP as well?
>>>
>>> By now the time sink just shows a blue, continuous signal as seen in
>>> the attached picture.
>>>
>>> Best regards,
>>> Henning
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Henning Bredenberg]

Hi Marcus,

Thanks for your response. I realized that I have a more fundamental  
problem before optimizing this project:
Can u give me hints on how I can generate one simple PDU? My flowgraph  
now keeps generating
one PDU after the other and the time sink display is continuously  
filled with samples.


In my understanding the different blocks create output items as long  
as input items are generated. In this case the flowgraph only stops  
when closed manuelly.  So I would need a generator block who generates  
one output item, i.e. one PDU, and then stops creating output items.  
Maybe it is possible to create one PDU following by output items that  
are just zeros? Is it possible to do that with the  
random_pdu_generator block or are there any other generation blocks  
that I should investigate?


My goal in general is to generate one simple packet burst that fits  
into a 20 ms slot. I have issues with this first step, before changing  
things like adding delays etc.



Best regards,
Henning


Quoting Marcus Müller :


Hi Henning,

to only answer the first part of your questions:
On 04/27/2016 03:22 PM, Henning Bredenberg wrote:

Hi Martin,

the time tag 'tx_time' tells the USRP when to transmit - so far so
good. So I don't need any delay blocks because the USRP sink realizes
the delay, right?

Nearly! In fact, the USRP itself realizes that in hardware -- which is
much, much better, because that hardware "knows" and runs at a rate
directly linked to the sampling rate and LO frequencies; if your PC
waited the 240ms of "PC clock time", that might be anything between 238
and 300ms "USRP time", if we add non-deterministic delay of the USB
transport for commands. So: there's a feature in the FPGA image that
allows you to specify "hey, FPGA, I want you to execute that "start
streaming" command *exactly* at the clock tick nr 12147, and it will do
that.

Assume i want to add a propagation delay of 240ms: Setting 'tx_time'
at the begin of the burst to 240ms will realize that?

No, you should first set the device time to something sensible (or just
roll with it being set to zero on device initialization) and use
relative times to that.
Minor caveat: if you're using a device with adjustable master clock rate
(mainly: B2xx and E31x), and you change the MCR after setting the time,
the host won't know when that change of "tick rate" happened, and the
conversion between timestamps and tick numbers will be pretty random.

Best regards,
Marcus



Do I tag the burst in the code of the PDU-generator using
add_item_tag() or is there another block who does it after the
generator (I thought the pdu_to_tagged_stream - block tags the packet)?

The crucial code in the random_pdu_impl.cc is:
[...]
  // pick a random vector length
  int len = d_rvar();
  len = std::max(d_length_modulo, len - len%d_length_modulo);

  // fill it with random bytes
  std::vector vec(len);
  for (int i=0; i

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Marcus Müller]

Hi Henning,

to only answer the first part of your questions:
On 04/27/2016 03:22 PM, Henning Bredenberg wrote:
> Hi Martin,
>
> the time tag 'tx_time' tells the USRP when to transmit - so far so
> good. So I don't need any delay blocks because the USRP sink realizes
> the delay, right? 
Nearly! In fact, the USRP itself realizes that in hardware -- which is
much, much better, because that hardware "knows" and runs at a rate
directly linked to the sampling rate and LO frequencies; if your PC
waited the 240ms of "PC clock time", that might be anything between 238
and 300ms "USRP time", if we add non-deterministic delay of the USB
transport for commands. So: there's a feature in the FPGA image that
allows you to specify "hey, FPGA, I want you to execute that "start
streaming" command *exactly* at the clock tick nr 12147, and it will do
that.
> Assume i want to add a propagation delay of 240ms: Setting 'tx_time'
> at the begin of the burst to 240ms will realize that?
No, you should first set the device time to something sensible (or just
roll with it being set to zero on device initialization) and use
relative times to that.
Minor caveat: if you're using a device with adjustable master clock rate
(mainly: B2xx and E31x), and you change the MCR after setting the time,
the host won't know when that change of "tick rate" happened, and the
conversion between timestamps and tick numbers will be pretty random.

Best regards,
Marcus
>
>
> Do I tag the burst in the code of the PDU-generator using
> add_item_tag() or is there another block who does it after the
> generator (I thought the pdu_to_tagged_stream - block tags the packet)?
>
> The crucial code in the random_pdu_impl.cc is:
> [...]
>   // pick a random vector length
>   int len = d_rvar();
>   len = std::max(d_length_modulo, len - len%d_length_modulo);
>
>   // fill it with random bytes
>   std::vector vec(len);
>   for (int i=0; i vec[i] = ((unsigned char) d_bvar()) & d_mask;
>
>   // send the vector
>   pmt::pmt_t vecpmt(pmt::make_blob([0], len));
>   pmt::pmt_t pdu(pmt::cons(pmt::PMT_NIL, vecpmt));
>
>   message_port_pub(PDU_PORT_ID, pdu);
> [...]
>
> My idea then is to use add_item_tag here with 'tx_time' as key for the
> output vector "PDU_PORT_ID", i.d. "pdus" in GRC.
>
> An additional question: How do I set a data rate that determines how
> long a packet needs to be transmitted? Is that done by USRP as well?
>
> By now the time sink just shows a blue, continuous signal as seen in
> the attached picture.
>
> Best regards,
> Henning
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Henning Bredenberg]

Hi Martin,

the time tag 'tx_time' tells the USRP when to transmit - so far so  
good. So I don't need any delay blocks because the USRP sink realizes  
the delay, right? Assume i want to add a propagation delay of 240ms:  
Setting 'tx_time' at the begin of the burst to 240ms will realize that?



Do I tag the burst in the code of the PDU-generator using  
add_item_tag() or is there another block who does it after the  
generator (I thought the pdu_to_tagged_stream - block tags the packet)?


The crucial code in the random_pdu_impl.cc is:
[...]
  // pick a random vector length
  int len = d_rvar();
  len = std::max(d_length_modulo, len - len%d_length_modulo);

  // fill it with random bytes
  std::vector vec(len);
  for (int i=0; i

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Martin Braun]

USRP sinks already support tagged streams, so you're halfway there
already. Adding a 'tx_time' tag onto the first sample of the burst will
let you transmit when you like. Note that you might want to pad your
burst with zeros (at the beginning and end) to flush the signal
processing lines.

Cheers,
M

On 04/22/2016 02:29 AM, Henning Bredenberg wrote:
> Hi all,
> 
> In the attached picture a flow graph is shown where i use the "random"
> pdu generator for a fixed sized pdu (1200 bytes here). The
> pdu_to_tagged_stream block makes it accessible for a simple BPSK
> modulation to send it over a coax cable to another USRP B200. A time
> sink shows what the transmitter transmits and what the receiver should
> receive ideally.
> By inserting some different delays, e.g. a uniformly distributed (0 to
> 80 ms in the disabled block here), i want to emulate a communication
> system. My questions are:
> 
> 1. How can a realize a burst transition that transmit the fixed sized
> burst, i.d. the pdu, in a 20 ms slot whereas the last 60ms no transition
> occurs before a new pdu is generated by the message_strobe block? By now
> it is a continuous transition no matter what i change.
> 
> 2. I want to store the time from generating the pdu till my second USRP
> receives it. Tagging the time should be an option to realize that. Since
> a have no clue: How can i realize that using time tags? The simplest
> case is - without any delays - that the pdu is generated and transmitted
> in a 20ms slot plus the processing time which should be small compared
> to the 20 ms.
> 
> I am thankful for any kind of help. Thanks and have a nice weekend,
> Henning
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time tags for transition time using USRPs

[Henning Bredenberg]

Hi all,

In the attached picture a flow graph is shown where i use the "random"  
pdu generator for a fixed sized pdu (1200 bytes here). The  
pdu_to_tagged_stream block makes it accessible for a simple BPSK  
modulation to send it over a coax cable to another USRP B200. A time  
sink shows what the transmitter transmits and what the receiver should  
receive ideally.
By inserting some different delays, e.g. a uniformly distributed (0 to  
80 ms in the disabled block here), i want to emulate a communication  
system. My questions are:


1. How can a realize a burst transition that transmit the fixed sized  
burst, i.d. the pdu, in a 20 ms slot whereas the last 60ms no  
transition occurs before a new pdu is generated by the message_strobe  
block? By now it is a continuous transition no matter what i change.


2. I want to store the time from generating the pdu till my second  
USRP receives it. Tagging the time should be an option to realize  
that. Since a have no clue: How can i realize that using time tags?  
The simplest case is - without any delays - that the pdu is generated  
and transmitted in a 20ms slot plus the processing time which should  
be small compared to the 20 ms.


I am thankful for any kind of help. Thanks and have a nice weekend,
Henning
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time triggered filter

[Philip Hahn]

Ah, sorry for not hitting reply-all. Yeah, I tried firdes and figured I was
missing something as is usually the case. Thanks again,

philip

On Wed, Apr 6, 2016 at 8:24 PM, Kevin Reid  wrote:

> On Apr 6, 2016, at 20:14, Philip Hahn  wrote:
>
> > Related question: I'm having trouble notch negative frequencies. I
> understand it needs to be a complex->complex with complex taps but most of
> the filter blocks don't seem to support this. In my case a band reject
> filter is what I'm looking for to remove spurious noise. I guess the answer
> is to frequency xlate, filter and then frequency xlate back?
>
> This is just a limitation in some of the canned blocks, not in GNU Radio
> itself. Instead of picking a 'band reject filter' block, pick the 'FIR
> Filter' block (either the decimating or interpolating type, doesn't
> matter), and in the Taps field insert a call to firdes --
>
> Huh. firdes doesn't have a complex band reject function. Well, you can use
> gnuradio.filter.firdes.complex_band_pass and apply standard techniques to
> turn the result into a band-reject filter: see
> http://www.dspguide.com/ch14/5.htm if you need info.
>
> > thank you Kevin,
>
> Please make sure to “reply all” (include the mailing list in your replies)
> so other people can follow the discussion and offer advice.
>
> --
> Kevin Reid  
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time triggered filter

[Kevin Reid]

On Apr 6, 2016, at 20:14, Philip Hahn  wrote:

> Related question: I'm having trouble notch negative frequencies. I understand 
> it needs to be a complex->complex with complex taps but most of the filter 
> blocks don't seem to support this. In my case a band reject filter is what 
> I'm looking for to remove spurious noise. I guess the answer is to frequency 
> xlate, filter and then frequency xlate back?

This is just a limitation in some of the canned blocks, not in GNU Radio 
itself. Instead of picking a 'band reject filter' block, pick the 'FIR Filter' 
block (either the decimating or interpolating type, doesn't matter), and in the 
Taps field insert a call to firdes --

Huh. firdes doesn't have a complex band reject function. Well, you can use 
gnuradio.filter.firdes.complex_band_pass and apply standard techniques to turn 
the result into a band-reject filter: see http://www.dspguide.com/ch14/5.htm if 
you need info.

> thank you Kevin,

Please make sure to “reply all” (include the mailing list in your replies) so 
other people can follow the discussion and offer advice.

-- 
Kevin Reid  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time triggered filter

[Kevin Reid]

On Apr 6, 2016, at 19:06, Philip Hahn  wrote:

>  Is it possible to start and stop a filter within a flowgraph?
> 
>  I have a complex data file which is 300 seconds in length and I only want to 
> filter a few seconds in the middle of the file. Is it possible to trigger a 
> filter on and off based on time or some other data trigger?

Do you want to output _only_ that filtered section (a), or to pass through the 
other  data unfiltered (b)?


If (a), then:

You can use the 'Head' and 'Skip Head' blocks together to discard specific 
sample counts. However, it would be more efficient to just slice up the data 
file yourself.

For other types of triggering, you will need blocks to do the job. If the 
criterion can be described as signal power or the presence of a specific 
frequency, then you can use one of the various 'Squelch' blocks with 'gate' 
mode enabled.

Otherwise, you'll have to write a custom block for whatever criterion you have 
-- it just needs to discard the unwanted data and pass through the wanted data.


If (b), then:

The expensive-but-accurate way is to create a detector for whatever your 
trigger criterion is, and have it output a stream of 1s or 0s (for present or 
absent) at the sample rate. Then use the basic math blocks to calculate the 
result
   (condition-met * filtered-signal + (1 - condition-met) * unfiltered-signal)


Finally, if you were doing this in real-time (not from a file) and could afford 
some unreliable time delay, you could instead write code to monitor a probe 
block or message output for your trigger condition and toggle the settings of a 
'Copy' (for case (a)) or 'Multiply Matrix' (for case (b)) block. This approach 
is maximally flexible, but is subject to the whims of thread scheduling so is 
less precise.

-- 
Kevin Reid  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time triggered filter

[Philip Hahn]

Good Evening,

 Is it possible to start and stop a filter within a flowgraph?

 I have a complex data file which is 300 seconds in length and I only want
to filter a few seconds in the middle of the file. Is it possible to
trigger a filter on and off based on time or some other data trigger?

 Thank you,

Philip Hahn
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time Limit

[Bekir Sait Çiftler]

Dear GNURadio fellows,

I am trying to save my samples in a file for limited time or limited number
of samples using file sink block in GRC. I have searched over archive and
web, but I did not find how to do it. There are some information about head
(skip), etc. but I did not understand how to use it. I am using GNURadio
Live 3.7.3.

Best regards,

Bekir
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Limit

[Martin Braun]

On 06/10/2014 03:37 PM, Bekir Sait Çiftler wrote:
 Dear GNURadio fellows,
 
 I am trying to save my samples in a file for limited time or limited
 number of samples using file sink block in GRC. I have searched over
 archive and web, but I did not find how to do it. There are some
 information about head (skip), etc. but I did not understand how to use
 it. I am using GNURadio Live 3.7.3.

head is the right way to go. Check out the examples, and read the manual
page, and you should find out how it works very easily.

M


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Martin Braun]

On 12.05.2014 20:19, Marcus Müller wrote:

Well, not that I'm aware of.
However, FFT, multiplication with a signal source, IFFT is not really
hard to do, and it's what a time shift mathematically is.


Careful... if you do that on a stream, you have to keep track of phases.
I know Marcus knows this -- consider this a don't do this at home 
unless you know what you're doing :)


Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Martin Braun]

On 13.05.2014 07:14, asad umer wrote:

I am also  using the delay block in the way u have mentioned but the
signal in scope doesn't act accordingly ,it remains in phase with the
original...


That's unlikely. Do this:

1) Connect sig source into port 1 of your scope (e.g. create a sine wave)
2) Connect same sig source to delay
3) Connect delay to port 2 of your scope
4) Choose a good delay that's not multiples of your wave length
5) Et voilá, phase shift.

M


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time delaying a signal

[asad umer]

I want to introduce a time delay in a signal received through USRP...I
have used the 'Delay' block but it is not showing any delay...what is
the appropriate block to use??
Can i delay the phase instead? Are time and phase delay equal?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Marcus D. Leech]

On 05/12/2014 02:02 PM, asad umer wrote:

I want to introduce a time delay in a signal received through USRP...I
have used the 'Delay' block but it is not showing any delay...what is
the appropriate block to use??
Can i delay the phase instead? Are time and phase delay equal?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


The delay block is in samples.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[asad umer]

On 5/12/14, Marcus D. Leech mle...@ripnet.com wrote:
 On 05/12/2014 02:02 PM, asad umer wrote:
 I want to introduce a time delay in a signal received through USRP...I
 have used the 'Delay' block but it is not showing any delay...what is
 the appropriate block to use??
 Can i delay the phase instead? Are time and phase delay equal?

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 The delay block is in samples.



 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
so there is no exclusive block for this purpose in GRC??

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Mike Jameson]

The delay block works in samples so to get seconds you have to multiply the
sample rate by the number of seconds you want to be delayed by.

Mike

On Mon, May 12, 2014 at 7:14 PM, asad umer user0...@gmail.com wrote:

 On 5/12/14, Marcus D. Leech mle...@ripnet.com wrote:
  On 05/12/2014 02:02 PM, asad umer wrote:
  I want to introduce a time delay in a signal received through USRP...I
  have used the 'Delay' block but it is not showing any delay...what is
  the appropriate block to use??
  Can i delay the phase instead? Are time and phase delay equal?
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
  The delay block is in samples.
 
 
 
  --
  Marcus Leech
  Principal Investigator
  Shirleys Bay Radio Astronomy Consortium
  http://www.sbrac.org
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 so there is no exclusive block for this purpose in GRC??

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Marcus D. Leech]

On 05/12/2014 02:14 PM, asad umer wrote:



so there is no exclusive block for this purpose in GRC??

A delay in samples is a delay in time:

1 sample == 1/sample-rate  seconds  of delay




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Marcus Müller]

Well, not that I'm aware of.
However, FFT, multiplication with a signal source, IFFT is not really hard
to do, and it's what a time shift mathematically is.

Greetings,
Marcus


On Mon, May 12, 2014 at 8:14 PM, asad umer user0...@gmail.com wrote:

 On 5/12/14, Marcus D. Leech mle...@ripnet.com wrote:
  On 05/12/2014 02:02 PM, asad umer wrote:
  I want to introduce a time delay in a signal received through USRP...I
  have used the 'Delay' block but it is not showing any delay...what is
  the appropriate block to use??
  Can i delay the phase instead? Are time and phase delay equal?
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
  The delay block is in samples.
 
 
 
  --
  Marcus Leech
  Principal Investigator
  Shirleys Bay Radio Astronomy Consortium
  http://www.sbrac.org
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 so there is no exclusive block for this purpose in GRC??

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Marcus D. Leech]

On 05/12/2014 02:19 PM, Marcus Müller wrote:

Well, not that I'm aware of.
However, FFT, multiplication with a signal source, IFFT is not really 
hard to do, and it's what a time shift mathematically is.


Greetings,
Marcus

Also, a phase-shift is just a complex multiply by:

complex(cos(ang),sin(ang))

With angle in radians

That's how I do manual phase correction in the interferometer support in 
simple_ra




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[Mike Jameson]

To shift just the phase you can use the 'Complex To Float' block in GRC
which separates the stream into real and imaginary components.  After
adding the delay block in line with the imaginary component you can then
recombine the stream by using the 'Float To Complex' block.

Mike

--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com


On Mon, May 12, 2014 at 7:23 PM, Marcus D. Leech mle...@ripnet.com wrote:

 On 05/12/2014 02:19 PM, Marcus Müller wrote:

 Well, not that I'm aware of.
 However, FFT, multiplication with a signal source, IFFT is not really
 hard to do, and it's what a time shift mathematically is.

 Greetings,
 Marcus

 Also, a phase-shift is just a complex multiply by:

 complex(cos(ang),sin(ang))

 With angle in radians

 That's how I do manual phase correction in the interferometer support in
 simple_ra




 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time delaying a signal

[asad umer]

I am also  using the delay block in the way u have mentioned but the signal
in scope doesn't act accordingly ,it remains in phase with the original...


On Mon, May 12, 2014 at 11:27 PM, Mike Jameson m...@scanoo.com wrote:

 To shift just the phase you can use the 'Complex To Float' block in GRC
 which separates the stream into real and imaginary components.  After
 adding the delay block in line with the imaginary component you can then
 recombine the stream by using the 'Float To Complex' block.

 Mike

 --
 Mike Jameson M0MIK BSc MIET
 Email: m...@scanoo.com
 Web: http://scanoo.com


 On Mon, May 12, 2014 at 7:23 PM, Marcus D. Leech mle...@ripnet.comwrote:

 On 05/12/2014 02:19 PM, Marcus Müller wrote:

 Well, not that I'm aware of.
 However, FFT, multiplication with a signal source, IFFT is not really
 hard to do, and it's what a time shift mathematically is.

 Greetings,
 Marcus

 Also, a phase-shift is just a complex multiply by:

 complex(cos(ang),sin(ang))

 With angle in radians

 That's how I do manual phase correction in the interferometer support in
 simple_ra




 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time interval

[Marco Bosco]

Hi all!

I have the following flowgraph with a sample rate = 32k :

Random source -- Throttle -- uchar to float -- scope sink

If a zoom in the plot I can see that the time interval between each sample is 
40 us. How can I compute this value?

Marco.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time interval

[Martin Braun]

On 09.02.2014 12:28, Marco Bosco wrote:

Hi all!

I have the following flowgraph with a sample rate = 32k :

Random source -- Throttle -- uchar to float -- scope sink

If a zoom in the plot I can see that the time interval between each
sample is 40 us. How can I compute this value?


Time between samples is 1./sampling rate. 1/32k=31.25us, the sink 
probably has ticks at even intervals.


MB

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time

[Paul B. Huter]

I am looking for a block that will give me a time while I am playing back
my data in GNURadio Companion. By this, I mean something that will pop up
when I start my flow and show me the time since the flow was started. I do
not care if it does not stop, I just want to be able to have a reference
point for how long my FFT Sink has been playing. Is there such a thing?
I have looked through all of the blocks in GRC, and I am probably just
missing it or not recognizing it.

Thank you.

Paul B. Huter
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time

[Marcus D. Leech]

On 01/10/2014 06:19 PM, Paul B. Huter wrote:
I am looking for a block that will give me a time while I am playing 
back my data in GNURadio Companion. By this, I mean something that 
will pop up when I start my flow and show me the time since the flow 
was started. I do not care if it does not stop, I just want to be able 
to have a reference point for how long my FFT Sink has been playing. 
Is there such a thing? I have looked through all of the blocks in GRC, 
and I am probably just missing it or not recognizing it.


Thank you.

Paul B. Huter


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

That doesn't really belong as a signal-processing block.

Consider probes/function-probes in GRC, and the ability to call imported 
Python code.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time controlling block

[Karan Talasila]

Marcus,

I think wayne is referring to the gnuradio scheduler presentation of Tom
Rondeau in his blog. The link is

http://gnuradio.squarespace.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html



On Tue, Dec 3, 2013 at 12:44 PM, Marcus Müller mar...@hostalia.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 This is redundant. The block base class has methods
 nitems_read() and nitems_written() that do exactly what you want.

 However: I'm totally interested in this presentation on the current
 scheduler; URL?

 Greetings,
 Marcus

 On 02.12.2013 19:45, Wayne Roberts wrote:
  you could keep a class variable which is added to every time work()
  is called, adding to it each time the value of noutput_items or
  input_items.size().
 
  Its also useful to know the scheduler, because it feeds work() an
  arbitrary number of samples each time. There is a presentation on
  gnuradio scheduler.
 
 
  On Mon, Dec 2, 2013 at 1:07 AM, Sandhya G sandhya4...@gmail.com
  wrote:
 
  Hi, Today i got a idea about implementing three different
  modulations on single message signal. But i want the modulations
  to happen after certain time has searched (can say exactly like
  counter). which is the block in GNU Radio that i can use has a
  counter.
 
 
  Thanks and regards, Sandhya
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 
 
  ___ Discuss-gnuradio
  mailing list Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSnYTwAAoJEAFxB7BbsDrLjH8H/1b7Ocr4McViRZUThAb0Q0b5
 yFlbSJe+5fKbbwJXptLq8/UZSOIVVHeekd3937RKHpHOmxkXY2FTZr8TQmadM/w0
 L5wYSflm4VxA3F6OkAOAUpZDNX7KTL7uRDGRS0X7EqiVyjai3BCakwiYEDZTNrQB
 n/cLUgum0qt0eDCSIF4OiPYc4nDHiQJd+iswR3Le476/qJA5Is/08I84muSDCCnM
 pDtHvwaDuV87fYuZGmxHuBDyknNAJAnhWcatUh8B1SIquWBieezhMkNQAGOLKWRV
 7y+cCVyXWPMchkN73vUWcuKPIis4U2kMkXF9f3q8cV3I83RqWizg1aA/lEpBBqI=
 =B3bM
 -END PGP SIGNATURE-

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




-- 
Regards
Karan Talasila
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time controlling block

[Sandhya G]

Hi,
Today i got a idea about implementing three different modulations on
single message signal. But i want the modulations to happen after certain
time has searched (can say exactly like counter). which is the block in GNU
Radio that i can use has a counter.


Thanks and regards,
Sandhya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time controlling block

[Wayne Roberts]

you could keep a class variable which is added to every time work() is
called, adding to it each time the value of noutput_items or
input_items.size().

Its also useful to know the scheduler, because it feeds work() an arbitrary
number of samples each time.
There is a presentation on gnuradio scheduler.


On Mon, Dec 2, 2013 at 1:07 AM, Sandhya G sandhya4...@gmail.com wrote:

 Hi,
 Today i got a idea about implementing three different modulations on
 single message signal. But i want the modulations to happen after certain
 time has searched (can say exactly like counter). which is the block in GNU
 Radio that i can use has a counter.


 Thanks and regards,
 Sandhya

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time controlling block

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is redundant. The block base class has methods
nitems_read() and nitems_written() that do exactly what you want.

However: I'm totally interested in this presentation on the current
scheduler; URL?

Greetings,
Marcus

On 02.12.2013 19:45, Wayne Roberts wrote:
 you could keep a class variable which is added to every time work()
 is called, adding to it each time the value of noutput_items or 
 input_items.size().
 
 Its also useful to know the scheduler, because it feeds work() an
 arbitrary number of samples each time. There is a presentation on
 gnuradio scheduler.
 
 
 On Mon, Dec 2, 2013 at 1:07 AM, Sandhya G sandhya4...@gmail.com
 wrote:
 
 Hi, Today i got a idea about implementing three different
 modulations on single message signal. But i want the modulations
 to happen after certain time has searched (can say exactly like
 counter). which is the block in GNU Radio that i can use has a
 counter.
 
 
 Thanks and regards, Sandhya
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 
 
 ___ Discuss-gnuradio
 mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnYTwAAoJEAFxB7BbsDrLjH8H/1b7Ocr4McViRZUThAb0Q0b5
yFlbSJe+5fKbbwJXptLq8/UZSOIVVHeekd3937RKHpHOmxkXY2FTZr8TQmadM/w0
L5wYSflm4VxA3F6OkAOAUpZDNX7KTL7uRDGRS0X7EqiVyjai3BCakwiYEDZTNrQB
n/cLUgum0qt0eDCSIF4OiPYc4nDHiQJd+iswR3Le476/qJA5Is/08I84muSDCCnM
pDtHvwaDuV87fYuZGmxHuBDyknNAJAnhWcatUh8B1SIquWBieezhMkNQAGOLKWRV
7y+cCVyXWPMchkN73vUWcuKPIis4U2kMkXF9f3q8cV3I83RqWizg1aA/lEpBBqI=
=B3bM
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time Granularity of USRP N2XX

[Harry Zhang]

Hi,
Since we can get receive time of rx_stream's first sample via rx tags, I
have two questions about the time granularity. Given the internal clock
is 10Mhz, is the time granularity 0.1us? The fractional second is stored
double type. Does it mean the last digits of the fractional sec are invalid?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Granularity of USRP N2XX

[Marcus Müller]

Hi Harry,

as far as I know, the granularity of a time stamp is the sample duration 
at the downsampled side.
As for the 10MHz: The 10MHz clock is used to derive different other 
clocks, especially the rx ADC and tx DAC clocks, which are an order of 
magnitude higher; bear in mind that when you request e.g. 5MHz samle 
rate you still get the 100MHz* samples of the ADC, but downsampled by a 
factor of 20.


Please also bear in mind that due to physics, processing etc the 
timestamp of the rx side is delayed to the actual reception of that 
sample, and that this delay is largely constant when receiving using 
the same settings, but my change based on sampling rate and other factors.


Greetings
Marcus

*for USRP2 arch, if I remember correctly.
On 26.11.2013 13:04, Harry Zhang wrote:

Hi,
Since we can get receive time of rx_stream's first sample via rx tags, I
have two questions about the time granularity. Given the internal clock
is 10Mhz, is the time granularity 0.1us? The fractional second is stored
double type. Does it mean the last digits of the fractional sec are invalid?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Granularity of USRP N2XX

[Harry Zhang]

Dear Marcus,
Thank you for your reply.
I'm confused about two concepts. Referring to the file 
time_spec.hpp in UHD, fractional sec is calculated according to the 
parameter ticks and tick_rate. So I think the time granularity is  
'1/tick_rate'  which is 0.1us using 10Mhz clock. But for the timestamp 
of sample stream, the granularity is the  sample duration. Is it correct?


Best,
Harry
 2013/11/26 20:12, Marcus Müller wrote:

Hi Harry,

as far as I know, the granularity of a time stamp is the sample 
duration at the downsampled side.
As for the 10MHz: The 10MHz clock is used to derive different other 
clocks, especially the rx ADC and tx DAC clocks, which are an order of 
magnitude higher; bear in mind that when you request e.g. 5MHz samle 
rate you still get the 100MHz* samples of the ADC, but downsampled by 
a factor of 20.


Please also bear in mind that due to physics, processing etc the 
timestamp of the rx side is delayed to the actual reception of that 
sample, and that this delay is largely constant when receiving using 
the same settings, but my change based on sampling rate and other 
factors.


Greetings
Marcus

*for USRP2 arch, if I remember correctly.
On 26.11.2013 13:04, Harry Zhang wrote:

Hi,
Since we can get receive time of rx_stream's first sample via rx tags, I
have two questions about the time granularity. Given the internal clock
is 10Mhz, is the time granularity 0.1us? The fractional second is stored
double type. Does it mean the last digits of the fractional sec are 
invalid?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Granularity of USRP N2XX

[Ben Hilburn]

Hi Harry -

Actually, the name `tick_rate


On Tue, Nov 26, 2013 at 5:49 AM, Harry Zhang zhang...@gmail.com wrote:

 Dear Marcus,
 Thank you for your reply.
 I'm confused about two concepts. Referring to the file time_spec.hpp
 in UHD, fractional sec is calculated according to the parameter ticks and
 tick_rate. So I think the time granularity is  '1/tick_rate'  which is
 0.1us using 10Mhz clock. But for the timestamp of sample stream, the
 granularity is the  sample duration. Is it correct?

 Best,
 Harry

  2013/11/26 20:12, Marcus Müller wrote:

 Hi Harry,

 as far as I know, the granularity of a time stamp is the sample duration
 at the downsampled side.
 As for the 10MHz: The 10MHz clock is used to derive different other
 clocks, especially the rx ADC and tx DAC clocks, which are an order of
 magnitude higher; bear in mind that when you request e.g. 5MHz samle rate
 you still get the 100MHz* samples of the ADC, but downsampled by a factor
 of 20.

 Please also bear in mind that due to physics, processing etc the
 timestamp of the rx side is delayed to the actual reception of that
 sample, and that this delay is largely constant when receiving using the
 same settings, but my change based on sampling rate and other factors.

 Greetings
 Marcus

 *for USRP2 arch, if I remember correctly.
 On 26.11.2013 13:04, Harry Zhang wrote:

 Hi,
 Since we can get receive time of rx_stream's first sample via rx tags, I
 have two questions about the time granularity. Given the internal clock
 is 10Mhz, is the time granularity 0.1us? The fractional second is stored
 double type. Does it mean the last digits of the fractional sec are
 invalid?

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time Granularity of USRP N2XX

[Ben Hilburn]

Hi Harry -

Actually, the name `tick_rate` is somewhat confusing. The tick_rate refers
to the clock rate that the DSP chain runs at. Here is a bit of code
regarding the tick_rate from the USRP2 / N-Series implementation that might
make things a little more clear:

_tree-createdouble(mb_path / tick_rate)
.publish(boost::bind(usrp2_clock_ctrl::get_master_clock_rate,
_mbc[mb].clock))
.subscribe(boost::bind(usrp2_impl::update_tick_rate, this,
_1));

Marcus explained things correctly in his e-mail. So, on an N-Series device,
the time step between samples is 1/100e6 = 10 ns.

Cheers,
Ben


On Tue, Nov 26, 2013 at 5:49 AM, Harry Zhang zhang...@gmail.com wrote:

 Dear Marcus,
 Thank you for your reply.
 I'm confused about two concepts. Referring to the file time_spec.hpp
 in UHD, fractional sec is calculated according to the parameter ticks and
 tick_rate. So I think the time granularity is  '1/tick_rate'  which is
 0.1us using 10Mhz clock. But for the timestamp of sample stream, the
 granularity is the  sample duration. Is it correct?

 Best,
 Harry

  2013/11/26 20:12, Marcus Müller wrote:

 Hi Harry,

 as far as I know, the granularity of a time stamp is the sample duration
 at the downsampled side.
 As for the 10MHz: The 10MHz clock is used to derive different other
 clocks, especially the rx ADC and tx DAC clocks, which are an order of
 magnitude higher; bear in mind that when you request e.g. 5MHz samle rate
 you still get the 100MHz* samples of the ADC, but downsampled by a factor
 of 20.

 Please also bear in mind that due to physics, processing etc the
 timestamp of the rx side is delayed to the actual reception of that
 sample, and that this delay is largely constant when receiving using the
 same settings, but my change based on sampling rate and other factors.

 Greetings
 Marcus

 *for USRP2 arch, if I remember correctly.
 On 26.11.2013 13:04, Harry Zhang wrote:

 Hi,
 Since we can get receive time of rx_stream's first sample via rx tags, I
 have two questions about the time granularity. Given the internal clock
 is 10Mhz, is the time granularity 0.1us? The fractional second is stored
 double type. Does it mean the last digits of the fractional sec are
 invalid?

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Harry Zhang]

Dear Miklos,
I got a weird problem while running the sync method(Node A transmit 
the sync messages,node A and B receive them).
I control A transmit continuously for 0.2sec and stop for 
2sec,repeat this.In the 0.2 sec period, node A could transmit 20 sync 
message and the difference of A and B's receive timestamp remain 
stable(such as 3.205122sec), the standard deviation of it is about 
5us,which is good. But when transmitting again after 3sec stop, the 
difference of A and B's receive timestamp is completely different with 
the previous one(changed to 3.245897sec but also stable). The difference 
is about .Considering the clock drift is small(about 2.5ppm),the the 
difference of receive timestamp between node A and B should remain 
unchanged in several minutes.So I think it's not caused by the clock 
drift in such a short time.

What maybe cause this problem?
Thanks in advance.

Best Regard,
Harry

2013/10/16 20:20, Miklos Maroti wrote:

Hi Harry,

On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang zhang...@gmail.com wrote:

Dear Miklos,
 Thank you for your inspiring reply.
 1.I do think this method sounds like a receiver-receiver sync while sync
message's transmitter A also doing beacon node C's function ( (1)sending
sync message and (2)recording receive time which would be sended to B for
sync).Is it correct?

Well, it is a transmitter-receiver synchronization, since only two
nodes are involved A and B, and only A sends, B only receives. The
real problem is to correlate samples with time, and I have used the RX
chain sample counter as time both on node A and B. You cannot use PC
time because of large errors over ethernet/USB so you have to use the
clock of the FPGA.


 2.For 1us accuracy, does it mean the sample rate must be more than 1e6?

Yes, of course. But you can even synchronize at 10 times the sampling
rate (hard, but not impossible), i.e. you would use 1e6 sampling rate
and get 1e7 precision.


 3.Does close to zero samples means the sample_rate*sample_offset
produces larger error when I use it for getting sync message's receive time?

close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I
do not use zero complex numbers is because I am afraid that the FPGA
switches off the TX chain if you continuously try to transmit zeros. I
am not sure that it does, you can experiment with that.


 4.The 1us is the jitter caused by sample duration.What about the jitter
produced by tx/rx tags? I do think 160us is mainly caused by the difference
between actual time when message leaving/arriving antenna and tx/rx tags's
time.What's your opinion?

I do not know about the tx/rx tags. Of course the FPGA needs time to
do the DSP, so it is possible that what you are seeing 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 Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.

Best,
Miklos

On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang zhang...@gmail.com wrote:

Dear Miklos,
  I'm glad to hear from you.
  The idea of this experiment is quite similar to 

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

[Miklos Maroti]

Hi Harry,

On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang zhang...@gmail.com wrote:
 Dear Miklos,
 Thank you for your inspiring reply.
 1.I do think this method sounds like a receiver-receiver sync while sync
 message's transmitter A also doing beacon node C's function ( (1)sending
 sync message and (2)recording receive time which would be sended to B for
 sync).Is it correct?

Well, it is a transmitter-receiver synchronization, since only two
nodes are involved A and B, and only A sends, B only receives. The
real problem is to correlate samples with time, and I have used the RX
chain sample counter as time both on node A and B. You cannot use PC
time because of large errors over ethernet/USB so you have to use the
clock of the FPGA.

 2.For 1us accuracy, does it mean the sample rate must be more than 1e6?

Yes, of course. But you can even synchronize at 10 times the sampling
rate (hard, but not impossible), i.e. you would use 1e6 sampling rate
and get 1e7 precision.

 3.Does close to zero samples means the sample_rate*sample_offset
 produces larger error when I use it for getting sync message's receive time?

close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I
do not use zero complex numbers is because I am afraid that the FPGA
switches off the TX chain if you continuously try to transmit zeros. I
am not sure that it does, you can experiment with that.

 4.The 1us is the jitter caused by sample duration.What about the jitter
 produced by tx/rx tags? I do think 160us is mainly caused by the difference
 between actual time when message leaving/arriving antenna and tx/rx tags's
 time.What's your opinion?

I do not know about the tx/rx tags. Of course the FPGA needs time to
do the DSP, so it is possible that what you are seeing 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 Harry,

 First, you should always transmit from node A, but when you want to be
 silent, then transmit something very close to zero complex numbers.
 This will ensure, that you have a nice continuous stream of data going
 out, and you can plan to do anything you want with sampling rate
 precision (better than 1us). Once you can do this, then transmit some
 pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
 and it is possible to synchronize to that with sampling rate precision
 again. Now comes the trick: node A not only transmits continuously,
 but it also receives continuously just like node B (with an antenna or
 just overhearing in the board). Both A and B synchronizes to the
 signal transmitted by A. In case of node A you do not have to worry of
 slightly different clocks, so once you are synchronized you will never
 get out of sync if you count the number of samples. In the case of
 node B it is harder, since node A might run a little faster or slower,
 so you will get out of sync, so you have to maintain synchronization.
 At this point, you have achieved synchronization of the two USRP
 nodes: you can stop sending periodically (continue spending close to
 zero samples) and then you can sample some data from node C, doing
 beam forming (depends on modulation), or whatever. You can correlate
 the received samples at node B with the received samples at node A
 with close to one sample precision (better than 1us).

 If you do not want to transmit all the time, then you can use TX tags,
 but it gets a little trickier, and I think there is some bug in the
 FPGA hardware to cause very rarely one sample shift between the TX and
 RX chain. I am not absolutely sure about this, but I could not explain
 something in any other way.

 Best,
 Miklos

 On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang zhang...@gmail.com wrote:

 Dear Miklos,
  I'm glad to hear from you.
  The idea of this experiment is quite similar to the core of your
 honored
 paper The flooding time synchronization protocol. It's a
 transmitter-receiver sync method using precious tx/rx timestamp to
 synchronize transmitter's and receiver's local timer.
  On the transmitter side, sync message is transmitted every 1 sec.
 Using
 rx tags, it's easy to get the average receive interval is 1.0003sec and
 the
 jitter is around 320us. Considering the interval jitter is 2*(rx
 jitter+rx
 jitter), the sync 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
 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 

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

[Harry Zhang]

Dear Miklos,
I'm glad to hear from you.
The idea of this experiment is quite similar to the core of your 
honored paper The flooding time synchronization protocol. It's a 
transmitter-receiver sync method using precious tx/rx timestamp to 
synchronize transmitter's and receiver's local timer.
On the transmitter side, sync message is transmitted every 1 sec. 
Using rx tags, it's easy to get the average receive interval is 
1.0003sec and the jitter is around 320us. Considering the interval 
jitter is 2*(rx jitter+rx jitter), the sync 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
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 side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang zhang...@gmail.com wrote:

Hi,
I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me some documents about this?
Thanks in advance.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Miklos Maroti]

Hi Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.

Best,
Miklos

On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang zhang...@gmail.com wrote:
 Dear Miklos,
 I'm glad to hear from you.
 The idea of this experiment is quite similar to the core of your honored
 paper The flooding time synchronization protocol. It's a
 transmitter-receiver sync method using precious tx/rx timestamp to
 synchronize transmitter's and receiver's local timer.
 On the transmitter side, sync message is transmitted every 1 sec. Using
 rx tags, it's easy to get the average receive interval is 1.0003sec and the
 jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx
 jitter), the sync 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
 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 side, then you can avoid all time stamping problems and
 effectively synchronize the tx and rx chains of a single usrp.

 Miklos

 On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang zhang...@gmail.com wrote:

 Hi,
 I have implemented time synchronization between two USRPs without GPSDO,
 MIMO cable or referring to computer's time.It's a sender-receiver method
 based on message exchange. It will be included in my next paper soon.
 I use the tx_time and tx_sob tag to transmit the message at the planned
 time. When this message researches the receiver, I can get the receive
 time via rx_time tags. The transmit and receive time of tx tags and rx
 tags are recorded in USRP motherboard without the jitter of Ethernet
 cable or operating system. So I think it could achieve the best accuracy
 without modifying FPGA.
 The experiment shows the accuracy is around 160us. I think it's mostly
 caused by the jitter of the tx tag's time. I wanna achieve better
 accuracy than this and the best way is adding a hardware timestamp
 module in FPGA. Is this way feasible?
 As for now, I wanna get a depth understanding of the implementing of tx
 tag,so I will know the accuracy limit of this method. But I'm not
 familiar with the FPGA, so could anyone describe how tx_time tag
 implemented or give me some documents about this?
 Thanks in advance.

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Harry Zhang]

Dear Miklos,
Thank you for your inspiring reply.
1.I do think this method sounds like a receiver-receiver sync while 
sync message's transmitter A also doing beacon node C's function ( 
(1)sending sync message and (2)recording receive time which would be 
sended to B for sync).Is it correct?

2.For 1us accuracy, does it mean the sample rate must be more than 1e6?
3.Does close to zero samples means the sample_rate*sample_offset 
produces larger error when I use it for getting sync message's receive time?
4.The 1us is the jitter caused by sample duration.What about the 
jitter produced by tx/rx tags? I do think 160us is mainly caused by the 
difference between actual time when message leaving/arriving antenna and 
tx/rx tags's time.What's your opinion?


Best,
Harry

2013/10/12 19:17, Miklos Maroti wrote:

Hi Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.

Best,
Miklos

On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang zhang...@gmail.com wrote:

Dear Miklos,
 I'm glad to hear from you.
 The idea of this experiment is quite similar to the core of your honored
paper The flooding time synchronization protocol. It's a
transmitter-receiver sync method using precious tx/rx timestamp to
synchronize transmitter's and receiver's local timer.
 On the transmitter side, sync message is transmitted every 1 sec. Using
rx tags, it's easy to get the average receive interval is 1.0003sec and the
jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx
jitter), the sync 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
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 side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang zhang...@gmail.com wrote:

Hi,
I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me 

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

[Miklos Maroti]

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 side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang zhang...@gmail.com wrote:
 Hi,
 I have implemented time synchronization between two USRPs without GPSDO,
 MIMO cable or referring to computer's time.It's a sender-receiver method
 based on message exchange. It will be included in my next paper soon.
 I use the tx_time and tx_sob tag to transmit the message at the planned
 time. When this message researches the receiver, I can get the receive
 time via rx_time tags. The transmit and receive time of tx tags and rx
 tags are recorded in USRP motherboard without the jitter of Ethernet
 cable or operating system. So I think it could achieve the best accuracy
 without modifying FPGA.
 The experiment shows the accuracy is around 160us. I think it's mostly
 caused by the jitter of the tx tag's time. I wanna achieve better
 accuracy than this and the best way is adding a hardware timestamp
 module in FPGA. Is this way feasible?
 As for now, I wanna get a depth understanding of the implementing of tx
 tag,so I will know the accuracy limit of this method. But I'm not
 familiar with the FPGA, so could anyone describe how tx_time tag
 implemented or give me some documents about this?
 Thanks in advance.

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Harry Zhang]

Hi,
I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me some documents about this?
Thanks in advance.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time-domain waterfall (as in webSDR)

[Salvatore Micheal]

does anybody know how to replicate Pieter's work in webSDR producing a
time-domain waterfall?

the waterfall i'm using now is WX GUI Waterfall Sink and it works
beautifully but is basically a frequency-domain/power waterfall right?

i'm new to GRC so perhaps my understanding of the Sink above is incorrect
(plz correct me if i'm wrong) .. perhaps someone can explain the
differences between Pieter's frequency-vs-time waterfall and the Sink above?

sam/kg4g-go
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time-domain waterfall (as in webSDR)

[Marcus D. Leech]

On 09/03/2013 10:38 PM, Salvatore Micheal wrote:
does anybody know how to replicate Pieter's work in webSDR producing a 
time-domain waterfall?


the waterfall i'm using now is WX GUI Waterfall Sink and it works 
beautifully but is basically a frequency-domain/power waterfall right?


i'm new to GRC so perhaps my understanding of the Sink above is 
incorrect (plz correct me if i'm wrong) .. perhaps someone can explain 
the differences between Pieter's frequency-vs-time waterfall and the 
Sink above?


sam/kg4g-go


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
In the Gnu Radio waterfall sink, the Y axis is time, the X axis is 
frequency, and the Z axis (colour) is power level.


That seems identical to what they do on WebSDR


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time to reconfigure a block in flowgraph

[Martin Braun]

On Thu, Dec 16, 2010 at 05:32:23PM -0800, Steve Mcmahon wrote:
 Hello:
 
 I need some help on a timing issue.
 
 I have a timer running on a separate thread which changes parameters in my 
 flow graph every 100ms or 200ms. When I change the frequency of my Signal 
 Source by using gr.sig_source_c.set_frequency(), the timer thread is still 
 able to fire every 100ms or 200ms and change the tone frequency every cycle. 
 However, when I try to also change the center frequency in the timer thread 
 with usrp2.sink_32fc.set_center_freq(), it cannot keep up and often takes 
 more than 100ms or 200ms.
 
 How long do functions such as usrp2.sink_32fc.set_center_freq() take to 
 execute? Do I need to to gr.lock() and gr.unlock() my flowgraph before 
 changing these kind of parameters? How can I change parameters every 100ms?

Not the most general answer you can get, but if you want to do *precise*
retuning (e.g. for frequency hopping) to my best knowledge the way to go
is to use a larger bandwidth and do the tuning digitally. You don't have
to use lock() for retuning the usrp (just as you don't have to do so for
calling set_center_freq() on the sig_source).

Cheers,
MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association



signature.asc
Description: Digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time to reconfigure a block in flowgraph

[Steve Mcmahon]

Hello Martin Braun:

I'm not sure what you mean. There is no set_center_freq() method in 
gr_sig_source_c.

When you say the best way to implement frequency hopping is to use a larger 
bandwidth and do the tuning digitally, you mean to do the tuning in software 
in the Python flowgraph using Gnuradio blocks?

Thanks.

Steve McMahon


--- On Fri, 12/17/10, Martin Braun martin.br...@kit.edu wrote:

 From: Martin Braun martin.br...@kit.edu
 Subject: Re: [Discuss-gnuradio] time to reconfigure a block in flowgraph
 To: discuss-gnuradio@gnu.org
 Date: Friday, December 17, 2010, 3:36 AM
 On Thu, Dec 16, 2010 at 05:32:23PM
 -0800, Steve Mcmahon wrote:
  Hello:
  
  I need some help on a timing issue.
  
  I have a timer running on a separate thread which
 changes parameters in my flow graph every 100ms or 200ms.
 When I change the frequency of my Signal Source by using
 gr.sig_source_c.set_frequency(), the timer thread is still
 able to fire every 100ms or 200ms and change the tone
 frequency every cycle. However, when I try to also change
 the center frequency in the timer thread with
 usrp2.sink_32fc.set_center_freq(), it cannot keep up and
 often takes more than 100ms or 200ms.
  
  How long do functions such as
 usrp2.sink_32fc.set_center_freq() take to execute? Do I need
 to to gr.lock() and gr.unlock() my flowgraph before changing
 these kind of parameters? How can I change parameters every
 100ms?
 
 Not the most general answer you can get, but if you want to
 do *precise*
 retuning (e.g. for frequency hopping) to my best knowledge
 the way to go
 is to use a larger bandwidth and do the tuning digitally.
 You don't have
 to use lock() for retuning the usrp (just as you don't have
 to do so for
 calling set_center_freq() on the sig_source).
 
 Cheers,
 MB
 
 -- 
 Karlsruhe Institute of Technology (KIT)
 Communications Engineering Lab (CEL)
 
 Dipl.-Ing. Martin Braun
 Research Associate
 
 Kaiserstraße 12
 Building 05.01
 76131 Karlsruhe
 
 Phone: +49 721 608-3790
 Fax: +49 721 608-6071
 www.cel.kit.edu
 
 KIT -- University of the State of Baden-Württemberg and
 National Laboratory of the Helmholtz Association
 
 
 -Inline Attachment Follows-
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time to reconfigure a block in flowgraph

[Josh Blum]

On 12/17/2010 10:28 AM, Steve Mcmahon wrote:
 Hello Martin Braun:
 
 I'm not sure what you mean. There is no set_center_freq() method in
 gr_sig_source_c.
 
 When you say the best way to implement frequency hopping is to use a
 larger bandwidth and do the tuning digitally, you mean to do the
 tuning in software in the Python flowgraph using Gnuradio blocks?
 

Typically with frequency hopping applications, the closer you tune to
the host the faster, but the more constrained is your bandwidth, and
therefore tuning capabilities:

1) Tune in software: fastest option but tuning is the most bandwidth
constrained (how much can you tune with (25Msps on USRP2)). This is as
easy as changing your filter taps or changing the freq on a sig source.

2) Tune in FPGA DSP: second fastest option. Latency is the RTT/2 +
cordic delay. However tuning is now constrained by the bandwidth of
100Msps w/ USRP2.

3) Tune in the RF daughterboard: the slowest option with the largest
tuning range.

Two notes:
*) In uhd you can tune the FPGA DSP without re-tuning the daughterboard
settings using the tune_request struct. I dont think the capability is
available in the older gnuradio+USRP2 driver.

*) You may be able to modify the tuner code of the WBX to respond
quicker by example: if you know you dont have to switch VCO selection,
the tuning code could be optimized for latency by only tuning part of
the RF chip.

-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time to reconfigure a block in flowgraph

[Steve Mcmahon]

Hello:

I need some help on a timing issue.

I have a timer running on a separate thread which changes parameters in my flow 
graph every 100ms or 200ms. When I change the frequency of my Signal Source by 
using gr.sig_source_c.set_frequency(), the timer thread is still able to fire 
every 100ms or 200ms and change the tone frequency every cycle. However, when I 
try to also change the center frequency in the timer thread with 
usrp2.sink_32fc.set_center_freq(), it cannot keep up and often takes more than 
100ms or 200ms.

How long do functions such as usrp2.sink_32fc.set_center_freq() take to 
execute? Do I need to to gr.lock() and gr.unlock() my flowgraph before changing 
these kind of parameters? How can I change parameters every 100ms?

I'm running GNU Radio 3.3.0 on Linux.

Thanks for your help.

Steve McMahon




  

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] time stamped transmission with usrp1 supported in UHD?

[Kyle Zhou]

I know time stamped tx/rx with usrp2 is supported in uhd. 
According to past posts, support for usrp1 was worked on.
Could anyone give an update on that progress? Is it already done?
Regards
Kyle

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] time stamped transmission with usrp1 supported in UHD?

[Josh Blum]

USRP1 support is in the UHD, but no timestamps.

-Josh

On 11/04/2010 05:56 AM, Kyle Zhou wrote:

I know time stamped tx/rx with usrp2 is supported in uhd.
According to past posts, support for usrp1 was worked on.
Could anyone give an update on that progress? Is it already done?
Regards
Kyle

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Tim Pearce]

Hi Guys,

After experimenting a bit more I think the issue was my test setup.

Previously I was using python to setup a USRP Source (with timestamps) and
save both the samples (64 bit) and timestamps (32bit) to a file sink to
process by importing with numpy and checking timestamps later.

At 25MHz thats ~ 300MB/sec of data, which is substantially more than
machines disk, which is probably about 20MB/sec max.

I've written a quick test block to run the same basic check in memory (i.e
check if latest timestamp is sooner than the last one -- expected to fail at
roll over!) and have had no problems using a 25MHz bandwidth.

I would have thought the large amount of memory in the machine would have
let me get over the hard drive bottleneck for a short period (say 30
seconds). The amount of data seems generated seems reasonable but the file
sink seems to be causing corruption in terms of misordered samples.

I've had a quick look at the code and gr.file_sink(..) seems to use fwrite,
is this thread safe? Thats the only idea I cant think of atm that might be
causing this, has anyone else got any ideas?

I'm going to have a quick google to see if theres a safer way to implement I
can test quickly, has anyone looked at this before? (Those expensive PCI
Expressive SSD Cards that can handle 1.4Gbit/sec would be nice if they
werent quite as expensive :) )

Cheers,

Tim


On Wed, Nov 11, 2009 at 10:22 PM, Doug Geiger
douglas.gei...@nrl.navy.milwrote:

 devin kelly wrote:

 Hello everyone,

 I'm doing a project with the USRP2 that where I need to know the Time of
 Arrival(TOA) of the waveforms.  This is for a geolocation application.

 My understanding as of now is that the hooks to get TOA are there in the
 USRP2, but the firmware does not provide access to them at this point.  Is
 this correct?

 If the firmware can provide TOA, how can I get that information??

 Thanks,
 Devin
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 The timestamp on the frame of *samples* is indeed available - and if you
 use the low-level interface to the USRP2 (libusrp2) you can see those
 timestamps. However, the gr-usrp2 interface (i.e. the default source block
 for working with the USRP2) does not. If you want to see the timestamps in a
 GNURadio flowgraph, you'll need to create a custom block based on the
 usrp2_source_[32fc or 16sc] block.
 However, that won't give you the TOA of a received signal *directly*.
 You'll need some scheme to decide that a signal has arrived, and then
 calculate the TOA based on the timestamp corresponding to that sample (the
 timestamps you get from libusrp2 are for the first signal in the frame of
 samples - so you'd need to either calculate the running timestamp for each
 sample, or keep track of the offset within the frame somehow).
 Good luck!
  Doug

 --
 Douglas Geiger
 Code 5545
 U.S. Naval Research Laboratory
 Washington, DC 20375
 (202) 767-9048
 douglas.gei...@nrl.navy.mil




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Tim Pearce]

Oops sorry guys this is in reply to the wrong timestamp question -- I had
meant to reply to this thread:
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-11/msg00069.html

Cheers,

Tim

On Thu, Nov 19, 2009 at 7:02 PM, Tim Pearce timothy.pea...@gmail.comwrote:

 Hi Guys,

 After experimenting a bit more I think the issue was my test setup.

 Previously I was using python to setup a USRP Source (with timestamps) and
 save both the samples (64 bit) and timestamps (32bit) to a file sink to
 process by importing with numpy and checking timestamps later.

 At 25MHz thats ~ 300MB/sec of data, which is substantially more than
 machines disk, which is probably about 20MB/sec max.

 I've written a quick test block to run the same basic check in memory (i.e
 check if latest timestamp is sooner than the last one -- expected to fail at
 roll over!) and have had no problems using a 25MHz bandwidth.

 I would have thought the large amount of memory in the machine would have
 let me get over the hard drive bottleneck for a short period (say 30
 seconds). The amount of data seems generated seems reasonable but the file
 sink seems to be causing corruption in terms of misordered samples.

 I've had a quick look at the code and gr.file_sink(..) seems to use fwrite,
 is this thread safe? Thats the only idea I cant think of atm that might be
 causing this, has anyone else got any ideas?

 I'm going to have a quick google to see if theres a safer way to implement
 I can test quickly, has anyone looked at this before? (Those expensive PCI
 Expressive SSD Cards that can handle 1.4Gbit/sec would be nice if they
 werent quite as expensive :) )

 Cheers,

 Tim



 On Wed, Nov 11, 2009 at 10:22 PM, Doug Geiger douglas.gei...@nrl.navy.mil
  wrote:

 devin kelly wrote:

 Hello everyone,

 I'm doing a project with the USRP2 that where I need to know the Time of
 Arrival(TOA) of the waveforms.  This is for a geolocation application.

 My understanding as of now is that the hooks to get TOA are there in the
 USRP2, but the firmware does not provide access to them at this point.  Is
 this correct?

 If the firmware can provide TOA, how can I get that information??

 Thanks,
 Devin
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 The timestamp on the frame of *samples* is indeed available - and if you
 use the low-level interface to the USRP2 (libusrp2) you can see those
 timestamps. However, the gr-usrp2 interface (i.e. the default source block
 for working with the USRP2) does not. If you want to see the timestamps in a
 GNURadio flowgraph, you'll need to create a custom block based on the
 usrp2_source_[32fc or 16sc] block.
 However, that won't give you the TOA of a received signal *directly*.
 You'll need some scheme to decide that a signal has arrived, and then
 calculate the TOA based on the timestamp corresponding to that sample (the
 timestamps you get from libusrp2 are for the first signal in the frame of
 samples - so you'd need to either calculate the running timestamp for each
 sample, or keep track of the offset within the frame somehow).
 Good luck!
  Doug

 --
 Douglas Geiger
 Code 5545
 U.S. Naval Research Laboratory
 Washington, DC 20375
 (202) 767-9048
 douglas.gei...@nrl.navy.mil




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Doug Geiger]

Tim Pearce wrote:

Hi Guys,

After experimenting a bit more I think the issue was my test setup.

Previously I was using python to setup a USRP Source (with timestamps) 
and save both the samples (64 bit) and timestamps (32bit) to a file 
sink to process by importing with numpy and checking timestamps later.


At 25MHz thats ~ 300MB/sec of data, which is substantially more than 
machines disk, which is probably about 20MB/sec max.
Don't have a good answer on the thread-safety question - but one method 
I've used when I want to collect a bunch of data for a limited period of 
time is mount a ram disk/tmpfs. E.g. I'd do something like:

$ mkdir /tmp/shm
$ sudo mount -t tmpfs tmpfs /tmp/shm
$ usrp2_rx_cfile -e interface -f frequency -N big number here 
/tmp/shm/data.dat



Cheers,

Tim

Doug

--
Douglas Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
douglas.gei...@nrl.navy.mil



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Tim Pearce]

Doug,

Thanks I'll try this. Googling a bit more I think fwrite has to be thread
safe, I'll double check my setup again and have another think if this
doesn't help.

Cheers,

Tim

On Thu, Nov 19, 2009 at 7:17 PM, Doug Geiger douglas.gei...@nrl.navy.milwrote:

 Tim Pearce wrote:

 Hi Guys,

 After experimenting a bit more I think the issue was my test setup.

 Previously I was using python to setup a USRP Source (with timestamps) and
 save both the samples (64 bit) and timestamps (32bit) to a file sink to
 process by importing with numpy and checking timestamps later.

 At 25MHz thats ~ 300MB/sec of data, which is substantially more than
 machines disk, which is probably about 20MB/sec max.

 Don't have a good answer on the thread-safety question - but one method
 I've used when I want to collect a bunch of data for a limited period of
 time is mount a ram disk/tmpfs. E.g. I'd do something like:
 $ mkdir /tmp/shm
 $ sudo mount -t tmpfs tmpfs /tmp/shm
 $ usrp2_rx_cfile -e interface -f frequency -N big number here
 /tmp/shm/data.dat

  Cheers,

 Tim

 Doug

 --
 Douglas Geiger
 Code 5545
 U.S. Naval Research Laboratory
 Washington, DC 20375
 (202) 767-9048
 douglas.gei...@nrl.navy.mil


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time of Arrival Hooks

[devin kelly]

Hello everyone,

I'm doing a project with the USRP2 that where I need to know the Time of
Arrival(TOA) of the waveforms.  This is for a geolocation application.

My understanding as of now is that the hooks to get TOA are there in the
USRP2, but the firmware does not provide access to them at this point.  Is
this correct?

If the firmware can provide TOA, how can I get that information??

Thanks,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Tim Pearce]

Devin,

The metadata is already passed to GNURadio by the USRP2 firmware. Its the
gnuradio usrp2 source block that doesn't do anything with this information
(metadata has the timestamp for the first sample of each frame)

You can modify the code to provide a second stream, or interleave the data
with them somehow by modifying the rx**_fc_handler.h files (primarily) to
get access to this timestamp data in C++ blocks or post processing in python
(all I've done so far).

Look for the Fixme: Do something with metadata line!

I've posted a couple of questions about getting timestamps to this mailing
list (I don't need absolute times in my case though so haven't thought about
how to sync these timestamps to real times) which some people (Doug, Juha I
think) have helped me out on and I'm just summarising their replies here!

I think I've read something about the 3.3 release implementing this but that
might have been about the ability to do TDMA

Cheers,

Tim

On Wed, Nov 11, 2009 at 7:21 PM, devin kelly dwwke...@gmail.com wrote:

 Hello everyone,

 I'm doing a project with the USRP2 that where I need to know the Time of
 Arrival(TOA) of the waveforms.  This is for a geolocation application.

 My understanding as of now is that the hooks to get TOA are there in the
 USRP2, but the firmware does not provide access to them at this point.  Is
 this correct?

 If the firmware can provide TOA, how can I get that information??

 Thanks,
 Devin

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time of Arrival Hooks

[Doug Geiger]

devin kelly wrote:

Hello everyone,

I'm doing a project with the USRP2 that where I need to know the Time 
of Arrival(TOA) of the waveforms.  This is for a geolocation application.


My understanding as of now is that the hooks to get TOA are there in 
the USRP2, but the firmware does not provide access to them at this 
point.  Is this correct?


If the firmware can provide TOA, how can I get that information??

Thanks,
Devin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
  
The timestamp on the frame of *samples* is indeed available - and if you 
use the low-level interface to the USRP2 (libusrp2) you can see those 
timestamps. However, the gr-usrp2 interface (i.e. the default source 
block for working with the USRP2) does not. If you want to see the 
timestamps in a GNURadio flowgraph, you'll need to create a custom block 
based on the usrp2_source_[32fc or 16sc] block.
However, that won't give you the TOA of a received signal *directly*. 
You'll need some scheme to decide that a signal has arrived, and then 
calculate the TOA based on the timestamp corresponding to that sample 
(the timestamps you get from libusrp2 are for the first signal in the 
frame of samples - so you'd need to either calculate the running 
timestamp for each sample, or keep track of the offset within the frame 
somehow).

Good luck!
 Doug

--
Douglas Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
douglas.gei...@nrl.navy.mil



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time difference of two receivers

[Yong J. Chang]

Hi all,

Now I'm having interesting observation. I have three USRP and RFX2400 and
I'm testing broadcast ( 1 transmitter and 2 receivers). I hooked the
oscilloscope probes up right after AD8347-out (pin 4,3) in RFX2400 board. 

Although the two receivers are located very closely, there is a relative
random delay between two received signal ( +-125ns ) . I think that they are
the same. I cannot understand why they are different.

is there any clue?

Thanks in advance!
-- 
View this message in context: 
http://www.nabble.com/Time-difference-of-two-receivers-tp22548499p22548499.html
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time tagging

[isaacgerg]

Is there any plans to have the data time tagged as it comes out of the USRP?

Isaac
-- 
View this message in context: 
http://www.nabble.com/Time-tagging-tp18895912p18895912.html
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio