Re: [Discuss-gnuradio] GOES LRIT???

[Patrik Tast]

Hi,


See https://github.com/mbsat/gr-poes-weather/tree/master/apps/GOES/gui
You need to upgrade the code to work with latest GR (to use cmake and
stuff)

To decode frames into images you need to use the RICE algorithm.

Patrik

On Thu, 2013-10-24 at 10:55 -0400, Raydel Abreu (CM2ESP) wrote:
> Hello,
> 
> 
> Is there any GOES LRIT decoder available under Linux and GNU Radio
> with support for USRP or RTL-SDR. In case there is only USRP
> compatibility, perhaps with the GRC file freely available it can be
> attempted to be converted for RTL-SDR?
> 
> 
> I have found some tools but only for POES HRPT...
> 
> 
> 
> Thanks,
> 
> 
> Raydel
> 
> ___
> 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] GOES LRIT???

[Raydel Abreu (CM2ESP)]

Hello Ian and all,

Thanks for the attached files, i tested it but when opening it says that
some blocks are not defined, a costas loop in one case and I don't remember
the other one...

After browsing a little bit on the GNU Radio website I found a folder that
includes that files, perhaps, downloading the entire folder and building it
would fix the missing files error.

Thanks!!!

Raydel


2013/10/25 Ian Buckley 

> Raydel,
> There was included in Gnuradio3.3 an example called usrp_rx_lrit which has
> since I assume been depreciated. I have never actually used it. so I can't
> comment on how well it might have worked.  It is attached here for your
> reference, though I suspect it will be a major effort to get it to work
> with a modern version of gnu radio.
>
> -Ian
>
>
>
>
>
>
>
>
> On Oct 24, 2013, at 7:55 AM, Raydel Abreu (CM2ESP) 
> wrote:
>
> > Hello,
> >
> > Is there any GOES LRIT decoder available under Linux and GNU Radio with
> support for USRP or RTL-SDR. In case there is only USRP compatibility,
> perhaps with the GRC file freely available it can be attempted to be
> converted for RTL-SDR?
> >
> > I have found some tools but only for POES HRPT...
> >
> > Thanks,
> >
> > Raydel
> > ___
> > 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] GOES LRIT???

[Raydel Abreu (CM2ESP)]

Patrick,

Thanks for the link!!! I have visited your repository before, but I failed
to dig deeper, that's why I didn't found the GOES I believed it was only
for HRPT, that's a great opportunity, I will try to build it.

Quick question, you mention I need to do RICE for obtaining images, so if I
understand correct your application produces the frame files, a (dot)lrit
file if I am correct? If that's the case I can use your program for the
receiving chain, dump the lrit files into a shared folder and then
processing the images with compatibles windows programs I am familiar too.
Am I correct?

Thanks!

Raydel


2013/10/25 Patrik Tast 

> Hi,
>
>
> See https://github.com/mbsat/gr-poes-weather/tree/master/apps/GOES/gui
> You need to upgrade the code to work with latest GR (to use cmake and
> stuff)
>
> To decode frames into images you need to use the RICE algorithm.
>
> Patrik
>
> On Thu, 2013-10-24 at 10:55 -0400, Raydel Abreu (CM2ESP) wrote:
> > Hello,
> >
> >
> > Is there any GOES LRIT decoder available under Linux and GNU Radio
> > with support for USRP or RTL-SDR. In case there is only USRP
> > compatibility, perhaps with the GRC file freely available it can be
> > attempted to be converted for RTL-SDR?
> >
> >
> > I have found some tools but only for POES HRPT...
> >
> >
> >
> > Thanks,
> >
> >
> > Raydel
> >
> > ___
> > 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] GOES LRIT???

[Patrik Tast]

Hi Rydel,

Right, you will first get CCSDS frames (bpsk-demodulated) let us call
that file lrit-frames.dat. To create images from the frames
(lrit-frames.dat) we need to unpack the data (lrit-frames.dat) using the
RICE algorithm to a new file say goes-13-lrit-frames.lrit. Since the
data rate is low we could rice-decode the frames (10 frames/earth disk)
on the fly, of course. 

The (NASA) RICE algorithm seems to be fairly easy BUT I haven't bothered
to try since the result (full-disk) ain't that valuable for weather.
You'll get nice images of Tellus, that's 4 sure.

The RICE lib from NOAA is found here
http://www.noaasis.noaa.gov/LRIT/software.html It doesn't link (on
linus), we've asked if they could release source-code so we could make
it cross-platform (last year)

We will support you if you want to have a go. We have antennas standing
by at LA (Los Alamitos)

Patrik


On Fri, 2013-10-25 at 08:26 -0400, Raydel Abreu (CM2ESP) wrote:
> Patrick,
> 
> 
> Thanks for the link!!! I have visited your repository before, but I
> failed to dig deeper, that's why I didn't found the GOES I believed it
> was only for HRPT, that's a great opportunity, I will try to build it.
> 
> 
> Quick question, you mention I need to do RICE for obtaining images, so
> if I understand correct your application produces the frame files, a
> (dot)lrit file if I am correct? If that's the case I can use your
> program for the receiving chain, dump the lrit files into a shared
> folder and then processing the images with compatibles windows
> programs I am familiar too. Am I correct?
> 
> 
> Thanks!
> 
> 
> Raydel
> 
> 
> 
> 2013/10/25 Patrik Tast 
> Hi,
> 
> 
> See
> https://github.com/mbsat/gr-poes-weather/tree/master/apps/GOES/gui
> You need to upgrade the code to work with latest GR (to use
> cmake and
> stuff)
> 
> To decode frames into images you need to use the RICE
> algorithm.
> 
> Patrik
> 
> On Thu, 2013-10-24 at 10:55 -0400, Raydel Abreu (CM2ESP)
> wrote:
> > Hello,
> >
> >
> > Is there any GOES LRIT decoder available under Linux and GNU
> Radio
> > with support for USRP or RTL-SDR. In case there is only USRP
> > compatibility, perhaps with the GRC file freely available it
> can be
> > attempted to be converted for RTL-SDR?
> >
> >
> > I have found some tools but only for POES HRPT...
> >
> >
> >
> > Thanks,
> >
> >
> > Raydel
> >
> > ___
> > 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] forecast and set history function for haar decomposition

[Bharat Mukkala]

thanks , and i have created the block ,which is working fine (but it is slow
for signals of larger size) 




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327p44381.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] GRC example using a single USRP2 with WBX for simultaneous OFDM transmit and receive

[Elvis Dowson]

Hi,
I have a USRP2 + WBX board, and would like to use GRC to simultaneously 
transmit and reveive OFDM using a single unit.

Is it possible to have a single GRC file launch two windows and run the 
transmission and reception using a single WBX board at the same time?

Best regards,

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

[Discuss-gnuradio] gnuradio-3.7.1 : rx_ofdm.grc file does launches a barely visible window with no output

[Elvis Dowson]

Hi,
  If I launch gr-digital/examples/ofdm/rx_ofdm.grc using 
gnuradio-companion, it runs a barely visible window that is probably a few 
10x20 pixels in size, and if you maximize it, the window is empty with no 
controls.

This is with the gnuradio-3.7.1 release.

Best regards,

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

[Discuss-gnuradio] Wx GUI Swig

[Paul B. Huter]

Is there a solution to the "wx_gui_swig" error on Windows when using a WX
FFT? I am using GNURadio 3.7.

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

Re: [Discuss-gnuradio] GOES LRIT???

[Patrik Tast]

On Fri, 2013-10-25 at 18:13 +0300, Patrik Tast wrote:
> Yeah, use a RTL-dongle and you could also use a $5 TV-inline amplifier 
> (or 2x if you have a long line). TV-inline amplifier:s are noisy but who
> cares in your case, the GOES signal is strong at you location. You can
> find one at ebay or here
> http://www.sadoun.com/Sat/Order/Switches/inline_amplifier.htm
> 
> 
> Patrik
> 
> 
> 
> 
> On Fri, 2013-10-25 at 10:31 -0400, Raydel Abreu (CM2ESP) wrote:
> > Hi Patrick,
> > 
> > 
> > Thanks for the help. A full-disk is a nice start from scratch, and
> > perhaps later going better. I have an RTL-SDR dongle with a R820T
> > tuner, my idea is to eventually receive data with it, but it is a work
> > in progress. The dish and the LNA should be ready by January.
> > 
> > 
> > I live in Cuba, but I have a friend in Argentina who has a dish, a LNA
> > and a RTLSDR dongle working right now. I will ask him for record a WAV
> > file containing I/Q data from the dongle and then try here at my home
> > for demodulate his signal. If we had success, that will be excellent.
> > 
> > 
> > I have to wait until my ground station is complete, here in Cuba there
> > are no specialized stores for that so all the equipment has to be
> > homebrew. I am working on the dish and its feed and a friend in
> > Croatia sent me a 1500 MHz LNA which I have to try to re-tune to 1700,
> > when the postal package arrives next month... I have my fingers cross
> > hoping to have all ready by January.
> > 
> > 
> > So far I have only obtain APT imagery, but I guess APT will not be
> > active too long, so GOES seems to be the best choice...
> > 
> > 
> > Best regards,
> > 
> > 
> > Raydel
> > 
> > 
> > 2013/10/25 Patrik Tast 
> > Hi Rydel,
> > 
> > Right, you will first get CCSDS frames (bpsk-demodulated) let
> > us call
> > that file lrit-frames.dat. To create images from the frames
> > (lrit-frames.dat) we need to unpack the data (lrit-frames.dat)
> > using the
> > RICE algorithm to a new file say goes-13-lrit-frames.lrit.
> > Since the
> > data rate is low we could rice-decode the frames (10
> > frames/earth disk)
> > on the fly, of course.
> > 
> > The (NASA) RICE algorithm seems to be fairly easy BUT I
> > haven't bothered
> > to try since the result (full-disk) ain't that valuable for
> > weather.
> > You'll get nice images of Tellus, that's 4 sure.
> > 
> > The RICE lib from NOAA is found here
> > http://www.noaasis.noaa.gov/LRIT/software.html It doesn't link
> > (on
> > linus), we've asked if they could release source-code so we
> > could make
> > it cross-platform (last year)
> > 
> > We will support you if you want to have a go. We have antennas
> > standing
> > by at LA (Los Alamitos)
> > 
> > Patrik
> > 
> 



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

[Discuss-gnuradio] PSK31 dynamic TX flow

[Louis Brown]

I'm experimenting with PSK31 transmission.  I can transmit bits streamed from a 
file, but to take it to the next level, I need to dynamically switch between 
keyboard keystroke generated data and a repetitive 1010 without stopping the 
flow.

Is there a way in GRC (or the main GR python script) to dynamically select 
between a signal source and a file source, using the signal source when the 
file source is empty?  The file source would be a FIFO that I would fill with 
an external python script that translates keyboard strokes into a varicoded bit 
stream.  When that FIFO is empty I need to switch back to the alternating 1010. 
 I'd rather not source the 1010 from the FIFO since that may lead to timing 
issues.

I'm trying to avoid, in the short term, writing a custom GR source block, but 
that may be inevitable.  I read there is a way to probe data in the flow; is 
there a way to stuff bits into a stream?

Thanks,
Lou


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

[Discuss-gnuradio] stream tag samples

[Jenny Galasso]

  



Hi,
I'm using stream tags to time tag my data.  In particular, I'm reading in 
one-second files and tagging the first sample read in with the time.  I'm 
concerned with how the tag will be handled during decimation, filtering etc.  I 
have read the documentation and understand that the tag is reassigned based on 
the relative_rate.  For this particular data set though, it is important that 
the tags stay with the specific samples to which they were assigned, even if 
some of the tags are lost during decimation, filtering, etc.


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

Re: [Discuss-gnuradio] PSK31 dynamic TX flow

[John Malsbury]

Louis,

You can use a socket-to-pdu block, and write an external python application
to send repeating data or pass along key strokes through the socket.  Use a
Pdu-to-tagged-stream to convert to a stream of bytes that in turn
stimulated the modulator blocks.  That'll make integration and
customization a little easier than starting with a new, custom block.

http://docs.python.org/2/howto/sockets.html

-John


On Fri, Oct 25, 2013 at 11:52 AM, Louis Brown  wrote:

> I'm experimenting with PSK31 transmission.  I can transmit bits streamed
> from a file, but to take it to the next level, I need to dynamically switch
> between keyboard keystroke generated data and a repetitive 1010 without
> stopping the flow.
>
> Is there a way in GRC (or the main GR python script) to dynamically select
> between a signal source and a file source, using the signal source when the
> file source is empty?  The file source would be a FIFO that I would fill
> with an external python script that translates keyboard strokes into a
> varicoded bit stream.  When that FIFO is empty I need to switch back to the
> alternating 1010.  I'd rather not source the 1010 from the FIFO since that
> may lead to timing issues.
>
> I'm trying to avoid, in the short term, writing a custom GR source block,
> but that may be inevitable.  I read there is a way to probe data in the
> flow; is there a way to stuff bits into a stream?
>
> Thanks,
> Lou
>
>
> ___
> 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] stream tag samples

[Nowlan, Sean]

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Jenny Galasso
Sent: Friday, October 25, 2013 3:06 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] stream tag samples

Today at 1:02 PM
Hi,
I'm using stream tags to time tag my data. In particular, I'm reading in 
one-second files and tagging the first sample read in with the time. I'm 
concerned with how the tag will be handled during decimation, filtering etc. I 
have read the documentation and understand that the tag is reassigned based on 
the relative_rate. For this particular data set though, it is important that 
the tags stay with the specific samples to which they were assigned, even if 
some of the tags are lost during decimation, filtering, etc.
Is this even possible? Are there any recommendations or tricks to get it to 
behave this way?
Thanks!
Jenny


Hi Jenny,

If you decimate by N, you're getting rid of N-1 out of every N samples. So 
naturally you would want the tag to stick with the sample that doesn't get 
thrown out. Similarly, if you interpolate by M, you introduce M-1 samples into 
the stream for every input sample; you'd naturally want the tag associated with 
input sample /i/ to be placed on the first sample of the corresponding batch of 
M output samples. The propagate_tags method in 
gnuradio/gnuradio-runtime/lib/block_executor.cc handles this by default. You 
can override this behavior in your own blocks by calling 
"set_tag_propagation_policy(TPP_DONT)" in your block's constructor and then 
handling tags yourself in your work method.

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

[Discuss-gnuradio] [GRC] Working Group

[Sebastian Koslowski]

Hi,

most of you have probably heard, during the last GRCon a Working Group
(GRWG) on GRC was formed as spin-off from the User Experience GRWG. The
goal was and is to add new cool features to our favorite flow graph
generator tool and, in a boarder sense, to discuss how we want a future
Development Environment [0] for GNU Radio to look and interact with
users and developers.

A lot of good suggestions and features were collected during the
conference, in IRC and on the list. I have organized/commented them a
bit and put them on the wiki [1]. However, the list is by far not
complete and I'd like to continue the discussion here on the list
(tagged [GRC]) as well as in a hangout I'll setup soon. I want to invite
especially those who are willing join this GRWG and help to implement stuff.

I have been playing around with a QT-port of GRC. Replacing GTK has some
nice benefits, one which is the reduction of the number of GUI
frameworks GR depends on. The project is still in an early stage and I
welcome any help I can get to move it forward. In my opinion, new
features that require substantial work/re-write to implement, should be
developed for the QT version. Others ("low hanging fruits"), where the
duplication effort is not too much, should be put in the GTK version first.

OK, that's it for now, I'll be posting a time and date for a hangout
soon. Feel free to comment and discuss.

Sebastian

[0] http://hokietux.net/blog/blog/2013/10/06/forward-steps-for-gnuradio/
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap

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

Dipl.-Ing. Sebastian Koslowski
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe, Germany

Phone: +49 721 608-46275
Fax:   +49 721 608-46071
Email: sebastian.koslow...@kit.edu
Web:   http://www.cel.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] stream tag samples

[Nowlan, Sean]

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Friday, October 25, 2013 3:23 PM
To: Jenny Galasso; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] stream tag samples


From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On 
Behalf Of Jenny Galasso
Sent: Friday, October 25, 2013 3:06 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] stream tag samples

Today at 1:02 PM
Hi,
I'm using stream tags to time tag my data. In particular, I'm reading in 
one-second files and tagging the first sample read in with the time. I'm 
concerned with how the tag will be handled during decimation, filtering etc. I 
have read the documentation and understand that the tag is reassigned based on 
the relative_rate. For this particular data set though, it is important that 
the tags stay with the specific samples to which they were assigned, even if 
some of the tags are lost during decimation, filtering, etc.
Is this even possible? Are there any recommendations or tricks to get it to 
behave this way?
Thanks!
Jenny


Hi Jenny,

If you decimate by N, you're getting rid of N-1 out of every N samples. So 
naturally you would want the tag to stick with the sample that doesn't get 
thrown out. Similarly, if you interpolate by M, you introduce M-1 samples into 
the stream for every input sample; you'd naturally want the tag associated with 
input sample /i/ to be placed on the first sample of the corresponding batch of 
M output samples. The propagate_tags method in 
gnuradio/gnuradio-runtime/lib/block_executor.cc handles this by default. You 
can override this behavior in your own blocks by calling 
"set_tag_propagation_policy(TPP_DONT)" in your block's constructor and then 
handling tags yourself in your work method.

Sean

I don't think there's a way to tell GNU Radio blocks derived from 
sync_decimator and sync_interpolator to quit propagating tags as described 
above (unless you write blocks that inherit from these classes yourself). It's 
the only way that really makes sense when changing rate domains by a rational 
factor.

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

Re: [Discuss-gnuradio] GOES LRIT???

[Patrik Tast]

Inorder to port it to GR the C++ code is needed (where all the fiddling
is done).
Can you give us a link?

Patrik

On Thu, 2013-10-24 at 23:29 -0700, Ian Buckley wrote:
> Raydel,
> There was included in Gnuradio3.3 an example called usrp_rx_lrit which has 
> since I assume been depreciated. I have never actually used it. so I can't 
> comment on how well it might have worked.  It is attached here for your 
> reference, though I suspect it will be a major effort to get it to work with 
> a modern version of gnu radio.
> 
> -Ian
> 
> 
> On Oct 24, 2013, at 7:55 AM, Raydel Abreu (CM2ESP)  wrote:
> 
> > Hello,
> > 
> > Is there any GOES LRIT decoder available under Linux and GNU Radio with 
> > support for USRP or RTL-SDR. In case there is only USRP compatibility, 
> > perhaps with the GRC file freely available it can be attempted to be 
> > converted for RTL-SDR?
> > 
> > I have found some tools but only for POES HRPT...
> > 
> > Thanks,
> > 
> > Raydel
> > ___
> > 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  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  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