[Discuss-gnuradio] Reply: Subject: FM transmitter on MatLab and transmission on USRP

[senthil murugan]

Hi Rakesh,

In GNU Radio, FM demodulator is implemented digitally as

a = present_complex_sample * conj(previous_complex_samples)
out[current] = some gain * arctan ( imag(a), real(a) ); //demodulated FM
signal

So, you can also implement the same for demodulating FM signal in MATLAB.
Recorded FM files may already be available in internet. So, use that file
and test your MATLAB code.

For connecting USRP to Matlab, toolbox is already released by Mathworks
from 2011 versions. If using older version of Matlab, you can use
http://www.flexible-radio.com/tools4sdr/download   third-party plugins.
But, you can only use RFX 900 board which will not support FM reception
freq.range :-(

Hope this might help you,
Senthil
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble With UHD Tune Request

[Josh Blum]

On 07/27/2012 03:25 PM, Daniel Labarowski wrote:
> Thanks for the reply Josh! I should have been more specific. The link to
> the compile error was in the previous
> message which I had linked to. I can get passed this error if I remove
> all references to the problem header from
> //src/swig/_swig.i , but perhaps this causes the problems I
> mentioned in my first post

Looks like its missing an include for the
DL_Hitemp_Blocks_Frequency_Changer interface.

Careful, there are includes for compiling the wrapper and there are
includes for exporting interfaces to swig %include vs #include. Here is
a good example, see how the block includes appear 2x in the file with
different directives:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/swig/uhd_swig.i#n40


> 
> (second-to-last paragraph, although I have since been able to include
> include both files thanks to your last suggestion. The problems remain
> though.)? /Will read up on template directives. Was wondering if swig is
> even necessary to use my block in C++ flowgraphs?

swig is only for python bindings. All c++, then you dont need swig.

> 
> -Dan
> 
> On 07/27/2012 06:09 PM, Josh Blum wrote:
>> I'm not too bright, or I'm not sure what error message you are
>> referring to. I believe that you can pass the pointer. But to do so
>> you may need to set some sort of %template directive so swig know how
>> to deal with the object -josh 
> 
> 
> 
> 
> ___
> 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] Trouble With UHD Tune Request

[Daniel Labarowski]

Thanks for the reply Josh! I should have been more specific. The link to 
the compile error was in the previous 
message which I had linked to. I can get passed this error if I remove 
all references to the problem header from 
//src/swig/_swig.i , but perhaps this causes the problems I 
mentioned in my first post 
 
(second-to-last paragraph, although I have since been able to include 
include both files thanks to your last suggestion. The problems remain 
though.)? /Will read up on template directives. Was wondering if swig is 
even necessary to use my block in C++ flowgraphs?


-Dan

On 07/27/2012 06:09 PM, Josh Blum wrote:
I'm not too bright, or I'm not sure what error message you are 
referring to. I believe that you can pass the pointer. But to do so 
you may need to set some sort of %template directive so swig know how 
to deal with the object -josh 


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

Re: [Discuss-gnuradio] Transmission time control from python level

[Josh Blum]

> Unfortunately, this same output is displayed repeatedly. I am not sure why
> the time does not change. Is there any other command that will keep
> printing/pulling the recent time after 10 ms (1 ms)?
> 
> 

time_spec is a stuct that holds integer time and fractional time for
high precision. Nothing more. So uhd.time_spec_t(0) will always be zero.

-josh

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

Re: [Discuss-gnuradio] Custom Block Issue

[Josh Blum]

On 07/27/2012 02:01 PM, Jonathan Fox wrote:
> I am trying to create a custom block that does energy detection. I used the
> gr-modtool.py to generate the appropriate directory and files and added my
> algorithm and necessary code to the header and cc. I also added the XML
> file for the GRC It compiled without error but when I tried testing it out,
> I got this error:
> 
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781
> 
> Traceback (most recent call last):
>   File "/home/jonfox/spectrum_sensing_test.py", line 21, in 
> import specsense
>   File "/usr/local/lib/python2.7/dist-packages/specsense/__init__.py", line
> 45, in 
> from specsense_swig import *
>   File
> "/usr/local/lib/python2.7/dist-packages/specsense/specsense_swig.py", line
> 26, in 
> _specsense_swig = swig_import_helper()
>   File
> "/usr/local/lib/python2.7/dist-packages/specsense/specsense_swig.py", line
> 22, in swig_import_helper
> _mod = imp.load_module('_specsense_swig', fp, pathname, description)
> ImportError: libgnuradio-specsense.so: cannot open shared object file: No
> such file or directory
> 

First off, does the file really exist, if not is it installed, but under
the wrong name or wrong directory?

If its there, sometimes running sudo ldconfig fixes issues like this.

> specsense is the module I created with the modtool but I did not modify the
> swig file. Any ideas on what I did wrong here?
> 
> Also, it seems that my code for having a vector input does not hold up and
> I have to manually change the input type in the appropriate python script
> despite setting it in GRC already. Is there any documentation on adding
> vector inputs and outputs?
> 

any code snippets with the problem that you can post?
-josh

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

Re: [Discuss-gnuradio] Trouble With UHD Tune Request

[Josh Blum]

On 07/27/2012 11:33 AM, Daniel Labarowski wrote:
> I've been thinking about this issue and I have a feeling that the
> problem is that swig may not support my use of pointers as function
> parameters. My block accepts a boost::shared_ptr and a
> boost::shared_ptr as parameters. Disabling swig as I
> did before seems to have created other issues. Is there any way that I
> can either fix the swig error or disable swig altogether for this block
> and just install and link for c++, and not python, flowgraphs?
> 
> Previous message
> with
> link to swig error

I'm not too bright, or I'm not sure what error message you are referring to.

I believe that you can pass the pointer. But to do so you may need to
set some sort of %template directive so swig know how to deal with the
object

-josh

> 
> -Dan
> 
> 
> 
> ___
> 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] Custom Block Issue

[Jonathan Fox]

I am trying to create a custom block that does energy detection. I used the
gr-modtool.py to generate the appropriate directory and files and added my
algorithm and necessary code to the header and cc. I also added the XML
file for the GRC It compiled without error but when I tried testing it out,
I got this error:

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781

Traceback (most recent call last):
  File "/home/jonfox/spectrum_sensing_test.py", line 21, in 
import specsense
  File "/usr/local/lib/python2.7/dist-packages/specsense/__init__.py", line
45, in 
from specsense_swig import *
  File
"/usr/local/lib/python2.7/dist-packages/specsense/specsense_swig.py", line
26, in 
_specsense_swig = swig_import_helper()
  File
"/usr/local/lib/python2.7/dist-packages/specsense/specsense_swig.py", line
22, in swig_import_helper
_mod = imp.load_module('_specsense_swig', fp, pathname, description)
ImportError: libgnuradio-specsense.so: cannot open shared object file: No
such file or directory

specsense is the module I created with the modtool but I did not modify the
swig file. Any ideas on what I did wrong here?

Also, it seems that my code for having a vector input does not hold up and
I have to manually change the input type in the appropriate python script
despite setting it in GRC already. Is there any documentation on adding
vector inputs and outputs?

Thanks,

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

Re: [Discuss-gnuradio] Transmission time control from python level

[Nazmul Islam]

Thanks a lot, Josh. I tried to use the time_spec_t class in the GRC
generated python code through the following way:


class TimeFind(grc_wxgui.top_block_gui):
  .
self.time_spec_t = uhd.time_spec_t(0)
.

if __name__ == '__main__':

tb = TimeFind()
var = 1
tb.start()
while var == 1:
sleep(0.1)
print "current fractional time :" ,
tb.time_spec_t.get_frac_secs()
print "System time: " , tb.time_spec_t.get_system_time()
print "full sec: " , tb.time_spec_t.get_full_secs()
print "real second: " , tb.time_spec_t.get_real_secs()
tb.stop()



Basically, My code produces the following output:

current fractional time : 0.0
System time:   >
full sec:  swig/python
detected a memory leak of type 'time_t *', no destructor found.

real second:  0.0


Unfortunately, this same output is displayed repeatedly. I am not sure why
the time does not change. Is there any other command that will keep
printing/pulling the recent time after 10 ms (1 ms)?


Thanks,

Nazmul


On Fri, Jul 27, 2012 at 2:07 PM, Josh Blum  wrote:

>
>
> On 07/27/2012 10:24 AM, Nazmul Islam wrote:
> > Sorry for the previous email. I mistakenly hit the sent button before
> > completing the mail. Here is the complete mail:
> >
> > Is it possible to see the time through USRP GPSDO with
> > microsecond/millisecond granularity? I want to synchronize the timing of
> my
> > computers and run gnuradio codes based on the synchronized timing.
> >
>
> When synchronized to a common clock reference and time, a group of USRPs
> can perform actions simultaneously with accuracy down the the jitter of
> GPSDO ref clock + clock synthesizer chain.
>
> > For example, if I have ethernet based internet connection, I can use ntp
> > servers to synchronize the computers and read the time (using
> > "time.time()") with milisecond granularity. I am trying attain the same
> > thing using GPSDO. I am using the following python code.
> >
>
> the "magic" of the GPSDO and time synchronization is that there is a
> shared "pulse" aka PPS. This pulse is used to latch a time value into
> the FPGA at a very specific moment. From that point on, a group of usrps
> share the same concept of time.
>
>
> > 
> >
> > class TimeFind :
> >
> > .
> > self.uhd_usrp_source_0 = uhd.usrp_source(
> > device_addr="",
> > stream_args=uhd.stream_args(
> > cpu_format="fc32",
> > args="peak=0.5",
> > channels=range(1),
> > ),
> > )
> >
> > ...
> > ..
> >
> > if __name__ == '__main__':
> >
> > tb = TimeFind()
> >
> > print "current time :" , tb.uhd_usrp_source_0.get_time_now()
> > print "last pps time :" , tb.uhd_usrp_source_0.get_time_last_pps()
> > print "GPS Time: " ,
> > tb.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_int()
> > tb.Run(True)
> >
> > *
> >
> > I have the following issues:
> >
> > 1. The current time and last pps time show the following output:
> >
> > current time :  of
> > type 'uhd::time_spec_t *' at 0x331fcf0> >
> > last pps time :  > of type 'uhd::time_spec_t *' at 0x331fcf0> >
> >
> > How can I get the time value?
> see member functions:
> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
> >
> > 2. "GPS Time: " shows the time with 1 second granularity. Can I get
> higher
> > resolution that 1 second? Is there an option that allows to see the exact
> > time instead of the integer time?
> >
>
> GPS time in seconds is actually a blocking call that waits until the
> seconds increments to return you the time. That way you know very
> precisely that the next pulse will be time_read + 1 seconds.
>
> -josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble With UHD Tune Request

[Daniel Labarowski]

I've been thinking about this issue and I have a feeling that the 
problem is that swig may not support my use of pointers as function 
parameters. My block accepts a boost::shared_ptr and a 
boost::shared_ptr as parameters. Disabling swig as I 
did before seems to have created other issues. Is there any way that I 
can either fix the swig error or disable swig altogether for this block 
and just install and link for c++, and not python, flowgraphs?


Previous message 
with 
link to swig error


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

Re: [Discuss-gnuradio] Recording scarce AIS bursts

[Christian Gagneraud]

On 27/07/12 17:39, John Malsbury wrote:

You may not see optimal performance, but the standard or simple squelch
in GNU Radio may meet these basic needs.  I've used it for similar
functionality in other packet radio systems.  I'm not sure what the
"carrier on" time is before modulation starts, so I can't promise that
they will work w/ the higher datarate of AIS.


Hi Nick,

It seems to do the job, at least it work for the strong bursts. Now i 
think i just need to find the right gain settings to get the weaker ones 
pass through.


thanks,
Chris




Nick,

Any thoughts?

-John




On Fri, Jul 27, 2012 at 8:40 AM, Christian Gagneraud mailto:ch...@techworks.ie>> wrote:

Hi list,

The problem with AIS is that if you are not in a busy place you
might have to wait for few seconds up to few minutes before a new
message comes in. Which is a bit annoying when you are doing live
experimentations.

I was thinking about recording only the raw message bursts, but i
would need a way to trigger the recorder such as to cut-off the
blanks in between the messages, but i didn't find yet a solution to
achieve that.
Would anyone have some tips to share on how to do that?

Another solution would be to record hours of data, and then apply
the same principle but off-line using a python script.

My triggering decision would be based on the signal level difference
at the carrier frequency and "outside enough" the carrier frequency.

Or maybe would anyone on that list have some "chatty" AIS data files
to share?

Chris

--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990 
Web: http://www.techworks.ie/


_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio






--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



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

Re: [Discuss-gnuradio] FM transmitter on MatLab and transmission on USRP

[Adeel Anwar]

Rakesh,

Matlab/Simulink USRP support package already ships with demos of FM Tx/RX
and QPSK TX/RX
See
  http://www.mathworks.com/discovery/sdr/usrp.html

-Adeel


On Thu, Jul 26, 2012 at 10:57 PM, Rakesh K Gupta wrote:

>  Dear All,
>
> I am new to USRP. I want to develop FM transmission (Voice) using Matlab
> and radio transmission through USRP. Can you suggest some programme.
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> With Thanks and Regards
>
> ** **
>
> ** **
>
> Rakesh Kumar Gupta
>
> Senior Group Manager 
>
> Communication Division - Defence
>
> Rolta India Limited
>
> Rolta Tower C, Rolta Technology Park
>
> 22nd Street, MIDC, Marol,
>
> Andheri(East), Mumbai – 400 093
>
> Voice Board : +91 22 2926  Ext. 5176
>
> Mob : 917738777076
>
> Fax : +91 22 2926 6823
>
> @Work :<< rakeshk.gu...@rolta.com >>
>
> ** **
>
> --
> This e-mail, along with any files transmitted with it, is confidential and
> for the sole use of the intended recipient(s); it may also be legally
> privileged. If you happen to receive this e-mail and you are not the
> intended recipient, please notify us immediately by reply e-mail, and
> delete this e-mail message, including any file(s), from your system. Any
> unauthorised review, use, disclosure or distribution is prohibited and may
> be unlawful. Further, while we scan all emails, we cannot guarantee that
> any email is virus-free, nor can we accept responsibility for any virus
> that has been introduced by this email or its attachments.
>
> ___
> 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] Transmission time control from python level

[Josh Blum]

On 07/27/2012 10:24 AM, Nazmul Islam wrote:
> Sorry for the previous email. I mistakenly hit the sent button before
> completing the mail. Here is the complete mail:
> 
> Is it possible to see the time through USRP GPSDO with
> microsecond/millisecond granularity? I want to synchronize the timing of my
> computers and run gnuradio codes based on the synchronized timing.
> 

When synchronized to a common clock reference and time, a group of USRPs
can perform actions simultaneously with accuracy down the the jitter of
GPSDO ref clock + clock synthesizer chain.

> For example, if I have ethernet based internet connection, I can use ntp
> servers to synchronize the computers and read the time (using
> "time.time()") with milisecond granularity. I am trying attain the same
> thing using GPSDO. I am using the following python code.
> 

the "magic" of the GPSDO and time synchronization is that there is a
shared "pulse" aka PPS. This pulse is used to latch a time value into
the FPGA at a very specific moment. From that point on, a group of usrps
share the same concept of time.


> 
> 
> class TimeFind :
> 
> .
> self.uhd_usrp_source_0 = uhd.usrp_source(
> device_addr="",
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> args="peak=0.5",
> channels=range(1),
> ),
> )
> 
> ...
> ..
> 
> if __name__ == '__main__':
> 
> tb = TimeFind()
> 
> print "current time :" , tb.uhd_usrp_source_0.get_time_now()
> print "last pps time :" , tb.uhd_usrp_source_0.get_time_last_pps()
> print "GPS Time: " ,
> tb.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_int()
> tb.Run(True)
> 
> *
> 
> I have the following issues:
> 
> 1. The current time and last pps time show the following output:
> 
> current time :  type 'uhd::time_spec_t *' at 0x331fcf0> >
> last pps time :  of type 'uhd::time_spec_t *' at 0x331fcf0> >
> 
> How can I get the time value?
see member functions:
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
> 
> 2. "GPS Time: " shows the time with 1 second granularity. Can I get higher
> resolution that 1 second? Is there an option that allows to see the exact
> time instead of the integer time?
> 

GPS time in seconds is actually a blocking call that waits until the
seconds increments to return you the time. That way you know very
precisely that the next pulse will be time_read + 1 seconds.

-josh

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

Re: [Discuss-gnuradio] FSK Modulation

[Ben Hilburn]

Joana -

I am not familiar with the software you are using or the radio you are
using to transmit, so I can't help on that end.

Again, have you tried plotting the samples you are taking, either on an FFT
or a Scope, to see what you are getting?  What analysis have you done on
your samples to figure out what is happening, and what have you discovered?

It will be impossible for anyone to help you if all we know is "this is my
flowgraph and the samples aren't right".  To get good help, you really need
to start investigating stuff, and sharing information you find in hopes
that someone will recognize what might be happening.

Cheers,
Ben

On Fri, Jul 27, 2012 at 2:59 AM, Joana Gonçalves <
joana.goncal...@tekever.com> wrote:

>  Hello, 
>
> ** **
>
> I am using the HM-TRP-433D radio to transmit a word or a letter depending
> what I program. Attached is the radio configuration.
>
> I can’t decode what is in file and why is sending that data. 
>
> I think that I have something wrong on the quadrature demod block or I
> need to filter the noise or something cause the file is getting much more
> samples that I was expected.
>
> Thank you very much for your help
>
> ** **
>
> ** **
>
> ** **
>
> *De:* Ben Hilburn [mailto:b...@ettus.com]
> *Enviada:* quinta-feira, 26 de Julho de 2012 20:12
> *Para:* Joana Gonçalves
> *Cc:* Discuss-gnuradio@gnu.org
> *Assunto:* Re: [Discuss-gnuradio] FSK Modulation
>
> ** **
>
> Jo -
>
> ** **
>
> You'll need to provide more details.  You are clearly dumping the data to
> a file, but what is wrong with the samples?  Have you plotted the samples
> in your file and confirmed that it at least looks how you expect it to?
>  Are you getting the number of samples you expect?  Is it the right data
> type?
>
> ** **
>
> You'll need to do some more investigating and provide more details for us
> to be able to help you.
>
> ** **
>
> Cheers,
>
> Ben
>
> ** **
>
> On Thu, Jul 26, 2012 at 10:26 AM, Joana Gonçalves <
> joana.goncal...@tekever.com> wrote:
>
> Hello, I am trying to use GRC to demodulate FSK signal. I use the USRP1 to
> receive data from the radio and I can see when the radio is transmitting or
> not trough FFT Sink. The problem is that I need to copy to a file what the
> radio is sending and I can t receive the correct data . I attached my block
> diagram. 
>
> I'm looking forward to your helpful.
>
>  
>
> Regards
>
> Jo
>
>
> ___
> 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] Transmission time control from python level

[Nazmul Islam]

Sorry for the previous email. I mistakenly hit the sent button before
completing the mail. Here is the complete mail:

Is it possible to see the time through USRP GPSDO with
microsecond/millisecond granularity? I want to synchronize the timing of my
computers and run gnuradio codes based on the synchronized timing.

For example, if I have ethernet based internet connection, I can use ntp
servers to synchronize the computers and read the time (using
"time.time()") with milisecond granularity. I am trying attain the same
thing using GPSDO. I am using the following python code.



class TimeFind :

.
self.uhd_usrp_source_0 = uhd.usrp_source(
device_addr="",
stream_args=uhd.stream_args(
cpu_format="fc32",
args="peak=0.5",
channels=range(1),
),
)

...
..

if __name__ == '__main__':

tb = TimeFind()

print "current time :" , tb.uhd_usrp_source_0.get_time_now()
print "last pps time :" , tb.uhd_usrp_source_0.get_time_last_pps()
print "GPS Time: " ,
tb.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_int()
tb.Run(True)

*

I have the following issues:

1. The current time and last pps time show the following output:

current time :  >
last pps time :  >

How can I get the time value?

2. "GPS Time: " shows the time with 1 second granularity. Can I get higher
resolution that 1 second? Is there an option that allows to see the exact
time instead of the integer time?

I am sorry if these questions were asked before. I am trying to do these
from GRC based python codes.

Any help will be appreciated.

Thanks,

Nazmul







On Fri, Jul 27, 2012 at 1:15 PM, Nazmul Islam wrote:

> Hello Sean,
>
> Thanks a lot for your reply. Is it possible to see the time through USRP
> GPSDO with microsecond/millisecond granularity? I want to synchronize the
> timing of my computers and run gnuradio codes based on the synchronized
> timing.
>
> For example, if I have ethernet based internet connection, I can use ntp
> servers to synchronize the computers and read the time (using
> "time.time()") with milisecond granularity. I am trying attain the same
> thing using GPSDO. I am using the following python code.
>
> 
>
> class  :
>
> self.uhd_usrp_source_0 = uhd.usrp_source(
> device_addr="",
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> args="peak=0.5",
> channels=range(1),
> ),
> )
>
> ...
> ..
>
> if __name__ == '__main__':
>
> On Thu, Jul 12, 2012 at 9:44 AM, Nowlan, Sean  > wrote:
>
>>  Timestamps (tx_time), start-of-burst (tx_sob) and end-of-burst (tx_eob)
>> tags have to be affixed to samples in the work function of an upstream
>> block (before the UHD sink block). The UHD sink block interprets these
>> stream tags and controls the USRP accordingly, but it doesn’t implement the
>> scheduling itself. Your upstream block needs to know how many samples per
>> 1-second burst (which obviously depends on your USRP sample rate) and affix
>> tx_time, tx_sob, and tx_eob tags to the correct samples.
>>
>> ** **
>>
>> IIRC, one of the stream tags examples already implements the
>> aforementioned algorithm. You just need to lift it and perhaps put it in a
>> new block in line with your GR/GRC processing chain.
>>
>> ** **
>>
>> Sean
>>
>> ** **
>>
>> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
>> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
>> Of *Nazmul Islam
>> *Sent:* Thursday, July 12, 2012 7:00 AM
>> *To:* j...@ettus.com
>> *Cc:* discuss-gnuradio@gnu.org
>> *Subject:* Re: [Discuss-gnuradio] Transmission time control from python
>> level
>>
>> ** **
>>
>> Hi Josh,
>>
>> ** **
>>
>> Thanks a lot for your reply. Can I control the TX stream from the GRC
>> generated python code? In other words, can I change the UHD:USRP
>> source/sink parameters to set up the time stamps or controlling the
>> scheduling?
>>
>> ** **
>>
>> Thanks,
>>
>> ** **
>>
>> Nazmul
>>
>> On Sun, Jul 8, 2012 at 12:30 AM, Josh Blum  wrote:
>>
>>
>>
>> On 07/07/2012 09:30 AM, Nazmul Islam wrote:
>> > I have three USRP's and I want them to transmit a continuous stream of
>> > repeated GLFSR source in non-overlapping manner. In other words, each
>> > transmitter will transmit the source for 1 second and then pause for 5
>> > seconds. All transmitters will transmit during the 'odd' seconds so that
>> > there is a 1 second gap between the sources. This process should
>> continue
>> > for ever.
>> >
>> > Currently, I am controlling the starting and stopping time of the flow
>> > graphs to achieve my goals. Unfortunately, the code/flowgraph sometimes
>> > hangs after 15-20 starts. I am using the following code:
>> >
>> > 
>> > tb = GLFSR_tran

Re: [Discuss-gnuradio] Recording scarce AIS bursts

[John Malsbury]

You may not see optimal performance, but the standard or simple squelch in
GNU Radio may meet these basic needs.  I've used it for similar
functionality in other packet radio systems.  I'm not sure what the
"carrier on" time is before modulation starts, so I can't promise that they
will work w/ the higher datarate of AIS.

Nick,

Any thoughts?

-John




On Fri, Jul 27, 2012 at 8:40 AM, Christian Gagneraud wrote:

> Hi list,
>
> The problem with AIS is that if you are not in a busy place you might have
> to wait for few seconds up to few minutes before a new message comes in.
> Which is a bit annoying when you are doing live experimentations.
>
> I was thinking about recording only the raw message bursts, but i would
> need a way to trigger the recorder such as to cut-off the blanks in between
> the messages, but i didn't find yet a solution to achieve that.
> Would anyone have some tips to share on how to do that?
>
> Another solution would be to record hours of data, and then apply the same
> principle but off-line using a python script.
>
> My triggering decision would be based on the signal level difference at
> the carrier frequency and "outside enough" the carrier frequency.
>
> Or maybe would anyone on that list have some "chatty" AIS data files to
> share?
>
> Chris
>
> --
> Christian Gagneraud,
> Embedded systems engineer.
> Techworks Marine
> 1 Harbour road
> Dun Laoghaire
> Co. Dublin
> Ireland
> Tel: + 353 (0) 1 236 5990
> Web: http://www.techworks.ie/
>
>
> __**_
> 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] Recording scarce AIS bursts

[Christian Gagneraud]

Hi list,

The problem with AIS is that if you are not in a busy place you might 
have to wait for few seconds up to few minutes before a new message 
comes in. Which is a bit annoying when you are doing live experimentations.


I was thinking about recording only the raw message bursts, but i would 
need a way to trigger the recorder such as to cut-off the blanks in 
between the messages, but i didn't find yet a solution to achieve that.

Would anyone have some tips to share on how to do that?

Another solution would be to record hours of data, and then apply the 
same principle but off-line using a python script.


My triggering decision would be based on the signal level difference at 
the carrier frequency and "outside enough" the carrier frequency.


Or maybe would anyone on that list have some "chatty" AIS data files to 
share?


Chris

--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/


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

Re: [Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks

[Josh Blum]

try entering peak = 0.5 for stream args in grc usrp block and take a
look at the generated code

_josh

On 07/26/2012 05:58 PM, Nazmul Islam wrote:
> peak = 0.5

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

Re: [Discuss-gnuradio] Transmit and Received Signals are Different

[Martin Braun (CEL)]

On Thu, Jul 26, 2012 at 04:09:31PM -0700, Frederick Lee wrote:
> The channel model block contains a timing offset, and noise adder
> which I didn't use in my simulations. The only things I changed were
> the frequency offsets and the multipath variable (from what I found
> online, it's used to change amplitude and phase shift of the signal).
> The only difference that I can see between the channel model and using
> actual USRPs is that  USRPs up converts the signal into IF ( I believe
> ), converts it to analog, and the daughter board converts it to RF.
> Then the reverse happens in the other USRP. When the two USRPs are
> transmitting, any of the four things that the channel model does can
> happen, but the main ones I'm concerned about is the frequency shift.,
> and the DPSK block seemed to have taken care of that ( at least in the
> simulation ).
> I was using the */gr-uhd/examples/grc/uhd_dpsk_mod.grc and other
> similar examples as somewhat of a guide, and I don't see anything that
> looks very different from what I used. What kind of other adjustments
> must I make?


Frederick,

all kinds of stuff can go wrong.

When you say you see 'nothing' on the FFT sink, do you mean you see only
noise, or literally nothing?

Here's a typical ist of things I do when debugging such a link:

1) Use a spectral analyzer to see if the transmitter is actually
transmitting (where you want it to)
2) Connect an FFT sink directly to the UHD source to see if the signal
looks as expected

You've got a couple of things that surprise me in your FG:
- the packet decoder (I'm not 100% what that does) searches for a bit
string? If so, you have no way to guarantee you're actually receiving
that specific sequence. If you're literally rx'ing nothing, perhaps that
doesn't trigger.
- Why do you LPF bits?

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-43790
Fax: +49 721 608-46071
www.cel.kit.edu

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


pgpdK4neXdipm.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio