Re: [Discuss-gnuradio] New OFDM blocks

[Martin Braun (CEL)]

On Sun, Apr 28, 2013 at 07:52:45PM -0400, Sean Nowlan wrote:
> If I'm reading ofdm_carrier_allocator_cvc_impl.cc right, it appears
> that the user must make sure that the occupied carrier indexes and
> pilot tones don't refer to the same positions with OFDM symbols,
> otherwise the occupied data carriers will get blown array. Is this
> correct?

Hi Sean,

yes, that's correct.

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


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

Re: [Discuss-gnuradio] Is there any PN cross correlator implementation for packet detection in Gnuradio?

[Martin Braun (CEL)]

On Mon, Apr 29, 2013 at 02:48:36PM +0800, Yingjie Chen wrote:
> I wonder if any PN cross correlator is implemented, which means the received
> signal is cross correlated with known preamble stored locally. Thank you so
> much.

You can either use an FIR (see the filter section) or one of the
correlators from the 'Synchronization' section.

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


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

Re: [Discuss-gnuradio] TDMA Engine Error

[Sam mite]

On Fri, Apr 26, 2013 at 10:15 AM, Josh Blum  wrote:

>
> >   File "/home/s/tdm/tdma_radio.py", line 70, in __init__
> > freq=freq,
> >   File "/home/s/.grc_gnuradio/tdma_hier.py", line 76, in __init__
> > self.tdma_engine =
> >
> precog.tdma_engine(initial_slot,slot_interval,guard_interval,number_of_slots,lead_limit,link_speed)
> >   File "/usr/local/lib/python2.7/dist-packages/precog/tdma_engine.py",
> line
> > 100, in __init__
> > self.set_tag_propagation_policy(extras_swig.TPP_DONT)
> > NameError: global name 'extras_swig' is not defined
> >
>
> Looks like an import got removed from that file, but I dont think its
> needed.
>
> try changing this trouble line to
>
> self.set_tag_propagation_policy(gnuradio.extras.TPP_DONT)
>
> Or if that doesnt work
>
> from gnuradio import extras
> self.set_tag_propagation_policy(extras.TPP_DONT)
>
> -josh
>

Thanks that solved the problem. tdma_radio.grc ran without any error with
output as follows:

UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 100 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
>>> gr_fir_fff: using SSE

How can I use tdma_engine in my following FSK flow graph;

TX Flow graph:
File source ---> Packet Encoder ---> pack to unpack/chunks to symbol -->
upsample  by 8---> Freq Mod---> USRP

Lets say USRP sampling rate is 500k.

 I want USRP to transmit for 1 second and then wait for 2 second (in these
two seconds two other same type of transmitters would transmit)and this
process should continue.  Can I do that? Where should I place this
"tdma_engine" block. And what would be the values for its parameters?

Thanks for the time.

-- 

Best Regards,

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

Re: [Discuss-gnuradio] Polyphase clock sync ccf symbols needed ?

[Sam mite]

On Sun, Apr 28, 2013 at 8:39 PM, Tom Rondeau  wrote:

> On Mon, Apr 15, 2013 at 12:25 AM, Sam mite  wrote:
> >
> >
> >
> >> > Hi list,
> >> >
> >> > I want to calculate the number of symbols taken by my Polyphase clock
> >> > sync
> >> > ccf block after which it locks. Although I am getting 0 BER (except at
> >> > start) but I want to know after how many symbols loop get lock. And
> then
> >> > by
> >> > varying different parameters I want to observe the lock time/symbols
> >> > needed.
> >> > From which plot I can get this information and how? . Current
> parameters
> >> > set
> >> > are:
> >> >
> >> > Sample/symbpol= 4
> >> > Loop BW= pi/100
> >> > damp factor= 0.707
> >> > filter size = 32
> >> > output sps = 1
> >> > max rate dev = 1.5
> >> > initial_phase=16
> >> >
> >> > Phase plot is showing some sinusoidal output. Attached are the two
> phase
> >> > plots. phase2.jpg is zoomed in version of phase1.jpg.
> >> >
> >> > Thanks ahead of time.
> >> >
> >> >
> >> > --
> >> > Best Regards,
> >> >
> >> > Sam
> >>
> >> Sam,
> >>
> >> Yes, the phase output port of the sync block is the one you want to
> >> look at. The phase rounded to the nearest integer (unless it's the
> >> floor) is the number of the filterbank being used at that time, which
> >> represents the phase offset of the signal.
> >>
> >> Are you tracking a real signal being received or a simulated signal?
> >> You're going to see some movement, plus or minus, around the closest
> >> phase, though. If its a real signal being received, there's going to
> >> be some small jitter in the timing between the two radios that the
> >> algorithm is trying to track. Also noise will affect if somewhat as it
> >> tries to keep a lock. The fact that it looks like it's actually
> >> oscillating is interesting. Have you tried to reduce the loop
> >> bandwidth to see how that affects things?
> >>
> >> Tom
> >>
> >
> > Thanks Tom,
> >
> > Currently, I am tracking a simulated signal (although I am getting zero
> BER
> > through USRPs as well). There is currently no additive noise. Reducing
> loop
> > bandwidth by a factor of 4 gives nice plots, as tracking become good by
> > reducing noise bandwidth. But, steady state value of 24 reaches after
> > approximately 9000samlples. That means my loop is taking 9000/4 symbols
> to
> > get lock? And after that it 'll produce desired output.  Am i doing
> > something wrong? Something I am missing?
> >
> > Attached are the snapshots of new phase plots.
> >
> > --
> >
> > Best Regards,
> >
> > Sam
>
>
> Sam,
>
> No, I don't think that you are doing something wrong here. But those
> figures you've posted look like the circuit is under-damped. It should
> be critically damped,


Why the circuit should be critically damped? In my first mail, I said that
I am  using damp_factor= 0.707. It should be under-damped. No? The problem,
i think, is that its taking too long 9000/4 symbols to get lock. No ?

so it'd be interesting to see what's going wrong
> inside of the algorithm. I've looked at it with this in mind, but I
> can't see that anything is being done differently than the normal
> control loops that we use, and the parameters should be set to be
> critically damped.
> This sounds like something we can develop and discuss on the signal
> processing wiki page. Would you be able to start something here?
> There's already a section for Synchronization. Maybe just create a new
> page off that for discussing this particular algorithm/block.
>

I'll be glad to :)

>
> (for signing up to post on the wiki:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-can-I-post-on-this-wiki-use-the-bug-tracker
> )
>
> Thanks!
> Tom
>


-- 

Best Regards,

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

[Discuss-gnuradio] how to convert python file in dat file

[Omer Omer]

hi, i wantto convert python file into dat file  in order to load in matlab.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] peak near center freq for noise signal, how to fix it

[vegihat vegihat]

Well as you advice me, i set the --lo-offset=1M , for the following command

uhd_rx_cfile -a serial=4759a751 -N 10 -f 2.53G --samp-rate=2M
--lo-offset=1M noise.dat -v

However the peak is still there. I give below the output of
uhd_rx_cfile.py.
As you can see the Rx DDC frequency is -2M (if I have understood
correctly, it should be 1M,right?  )

Any idea what is the wrong..


linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.005.002-47-g4a860d74

-- Opening a USRP1 device...
-- Using FPGA clock rate of 64.00MHz...
Using mid-point gain of 45.0 ( 0.0 - 90.0 )
Motherboard: USRP1 (4759a751)
Daughterboard: RFX2400 (no serial, RX2, A:0)
Rx gain: 45.0
Rx baseband frequency: 2.528G
Rx DDC frequency: -2M
Rx Sample Rate: 2M
Receving 100k samples
Writing 32-bit complex floats
Output filename: noise.dat



2013/4/28 Alex Zhang 

> I remember that some DC is manually added into the frequency point which
> can be divided by 5Mhz or 10Mhz? Besides the DC at the your central freq,
> be aware of that if the lo offset setting makes your bandwidth cover these
> frequency point, you still can see the peaks.
> Hope I am not wrong, at least It seems that I observed that thing before.
>
>
> On Fri, Apr 26, 2013 at 1:44 PM, Marcus D. Leech wrote:
>
>> On 04/26/2013 02:27 PM, vegihat vegihat wrote:
>>
>>> if i have understand i need to use the --lo-offset of uhd_rx_cfile
>>>
>>> i have gave various values to  --lo-offset and only one value has moved
>>> the DC offset (--lo-offset=1G) and the plotfft gives many small spikes
>>> (maybe this is caused to aliasing, but i am not sure)
>>>
>>> which is the rule (value of --lo-offset) to set the DC offset out of my
>>> band?
>>>
>> What I do is set my LO offset to about half my bandwidth, so in your case:
>>
>> --lo-offset 1.0e6
>>
>>
>> --
>> 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
>>
>
>
>
> --
>
> Alex,
> *Dreams can come true – just believe.*
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to convert python file in dat file

[Tom Rondeau]

On Mon, Apr 29, 2013 at 7:08 AM, Omer Omer  wrote:

> hi, i wantto convert python file into dat file  in order to load in matlab.
>

Omer,

This isn't a GNU Radio question. We don't really do Matlab support on this
mailing list. I'm sure there's some information about how to do this
elsewhere.

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

Re: [Discuss-gnuradio] Polyphase clock sync ccf symbols needed ?

[Tom Rondeau]

On Mon, Apr 29, 2013 at 4:10 AM, Sam mite  wrote:
>> Sam,
>>
>> No, I don't think that you are doing something wrong here. But those
>> figures you've posted look like the circuit is under-damped. It should
>> be critically damped,
>
>
> Why the circuit should be critically damped? In my first mail, I said that I
> am  using damp_factor= 0.707. It should be under-damped. No? The problem, i
> think, is that its taking too long 9000/4 symbols to get lock. No ?

Hm, it appears you're right that it's under damped. I thought I had
translated it so that 0.707 was crtically damped, but apparently I
didn't. I was looking at the Costas loop implementation to make sure.
But they converges at the same time.

However, in the case of the timing loop, we're not talking about a
slight under damping. With .707, I would expect it to dip slightly
before converging. But the way this looks, it is significantly under
damped with the number of cycles of oscillation. So I still think
something isn't quite right. Not sure if it will necessarily converge
any faster, but it should behave more like expected.

>> so it'd be interesting to see what's going wrong
>> inside of the algorithm. I've looked at it with this in mind, but I
>> can't see that anything is being done differently than the normal
>> control loops that we use, and the parameters should be set to be
>> critically damped.
>> This sounds like something we can develop and discuss on the signal
>> processing wiki page. Would you be able to start something here?
>> There's already a section for Synchronization. Maybe just create a new
>> page off that for discussing this particular algorithm/block.
>
>
> I'll be glad to :)

Thanks!
Tom


>>
>> (for signing up to post on the wiki:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-can-I-post-on-this-wiki-use-the-bug-tracker)
>>
>> Thanks!
>> Tom
>
>
>
> --
>
> Best Regards,
>
> Sam

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

Re: [Discuss-gnuradio] GSOC ideas [802.11]

[2_...@libero.it]

Probably I'll choose openCL. It means that I must learn a new language,but it's 
not bad..
>le to do either for this project. Have you
>checked the mailing list archives? Getting GPU-based processing into a
>GNU Radio flowgraph is quite hard, given the structure of the
>scheduler. Also, which elements are you hoping to accelerate?
Do you speak about the fact that in cuda memory can be used only in the thread 
which instantiated it?

>There is the gr-gpu project (it's a CGRAN project) that is based on
>using CUDA for the development of the signal processing blocks.
>Mostly, this was done because OpenCL was too new at the time and was
>not really usable for this purpose.
I've already seen it,but thank you!!

>And, an aside on co-processor projects like gr-gpu. My opinion on this
>is that we wouldn't carry gr_block's that are written for
>co-processors in GNU Radio, anyways. So the license doesn't matter so
>much for that
I've not considered this aspect...is it for GSOC rules,in your opinion?

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

[Discuss-gnuradio] Announcing new OpenCL block

[Josh Blum]

Hey list,

I have created an OpenCL block that allows a user to interface with an
OpenCL compatible device, like a GPU. This block handles most of the
complications of using the OpenCL API. All the user has to do is feed
the block a .cl file with the kernel source and click run!

This block makes use of GRAS's new buffer model and buffer API so memory
allocated by OpenCL can be directly written by upstream blocks and
directly read by downstream blocks. This translates to DMAs over the
PICe bus for most graphics cards, with no unnecessary memcpys between
blocks.

Now I should note that signal processing on GPUs is not something that
is inherently faster vs a GPP implementation. Algorithms that are highly
parallel and "expensive" tend to be better candidates. I am excited to
see what interesting kernels users can come up with!

For more details, install instructions, examples, see:
https://github.com/guruofquality/gras/wiki/Opencl

-josh

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

[Discuss-gnuradio] GSoC Students: IRC Session

[Martin Braun (CEL)]

Hi all,

tomorrow, 16:00 CEST (1400 UTC), I will do an IRC session where I'll
answer questions for those of you applying to GSoC.

We'll meet in #gnuradio on Freenode.
There might be other mentors around, but it's me for sure.

If you upload your proposals until tomorrow morning my time, I might be
able to check them out.

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-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


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

Re: [Discuss-gnuradio] How to diagnose make test failures

[Barry Jackson]

On 28/04/13 18:55, Tom Rondeau wrote:


That's very concerning about not finding libvolk.so. Make sure you
have, in the build directory, volk/lib/libvolk.so.0.0.0. If that's not
there, volk didn't build properly, which is necessary for the rest of
the QA tests that are failing.

Tom


Hi Tom,
The file is there - here is what I attached to the last post in the 
thread about build failures with boost-1.52.


The build is done in chroot with base system and all buildrequires installed

This is with boost-1.53 just to be clear :-

 [iurt cauldron] 
rootjackodesktop/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build$ ctest -V 
-R qa_volk_test_all
UpdateCTestConfiguration  from 
:/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/DartConfiguration.tcl

Test project /home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: qa_volk_test_all

1: Test command: 
/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/volk/lib/test_all

1: Test timeout computed to be: 9.99988e+06
1: /home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/volk/lib/test_all: 
error while loading shared libraries: libvolk.so.0.0.0: cannot open 
shared object file: No such file or directory

1/1 Test #1: qa_volk_test_all .***Failed0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.01 sec

The following tests FAILED:
  1 - qa_volk_test_all (Failed)
Errors while running CTest
#-

So to be sure I cd'd into the build dir and ls -l :-

[iurt cauldron] 
rootjackodesktop/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build$ cd volk
[iurt cauldron] 
rootjackodesktop/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/volk$ cd lib
[iurt cauldron] 
rootjackodesktop/home/baz/rpmbuild/BUILD/gnuradio-3.6.3/build/volk/lib$ ll

total 7092
drwxr-xr-x 4 baz baz4096 Apr 15 10:56 CMakeFiles/
-rw-r--r-- 1 baz baz 353 Apr 15 10:56 CTestTestfile.cmake
-rw-r--r-- 1 baz baz   61580 Apr 15 10:56 Makefile
-rw-r--r-- 1 baz baz1964 Apr 15 10:56 cmake_install.cmake
lrwxrwxrwx 1 baz baz  16 Apr 15 10:57 libvolk.so -> libvolk.so.0.0.0*
-rwxr-xr-x 1 baz baz 4603262 Apr 15 10:57 libvolk.so.0.0.0*<=###
-rwxr-xr-x 1 baz baz 1862413 Apr 15 10:57 test_all*
-rw-r--r-- 1 baz baz  163386 Apr 15 10:56 volk.c
-rw-r--r-- 1 baz baz9246 Apr 15 10:56 
volk_16i_s32f_deinterleave_32f_x2_a_orc_impl.c
-rw-r--r-- 1 baz baz6934 Apr 15 10:56 
volk_16ic_deinterleave_16i_x2_a_orc_impl.c
-rw-r--r-- 1 baz baz6739 Apr 15 10:56 
volk_16ic_deinterleave_real_8i_a_orc_impl.c
-rw-r--r-- 1 baz baz   12958 Apr 15 10:56 
volk_16ic_magnitude_16i_a_orc_impl.c
-rw-r--r-- 1 baz baz   12020 Apr 15 10:56 
volk_16sc_magnitude_32f_aligned16_orc_impl.c

-rw-r--r-- 1 baz baz5893 Apr 15 10:56 volk_16u_byteswap_a_orc_impl.c
-rw-r--r-- 1 baz baz7022 Apr 15 10:56 
volk_32f_s32f_multiply_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz6998 Apr 15 10:56 
volk_32f_s32f_normalize_a_orc_impl.c

-rw-r--r-- 1 baz baz6520 Apr 15 10:56 volk_32f_sqrt_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7134 Apr 15 10:56 volk_32f_x2_add_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7158 Apr 15 10:56 
volk_32f_x2_divide_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7477 Apr 15 10:56 
volk_32f_x2_dot_prod_32f_a_orc_impl.c

-rw-r--r-- 1 baz baz7246 Apr 15 10:56 volk_32f_x2_max_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7246 Apr 15 10:56 volk_32f_x2_min_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7174 Apr 15 10:56 
volk_32f_x2_multiply_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz7174 Apr 15 10:56 
volk_32f_x2_subtract_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz8338 Apr 15 10:56 
volk_32fc_32f_multiply_32fc_a_orc_impl.c
-rw-r--r-- 1 baz baz9260 Apr 15 10:56 
volk_32fc_magnitude_32f_a_orc_impl.c
-rw-r--r-- 1 baz baz   11087 Apr 15 10:56 
volk_32fc_s32f_magnitude_16i_a_orc_impl.c
-rw-r--r-- 1 baz baz   12556 Apr 15 10:56 
volk_32fc_s32fc_multiply_32fc_a_orc_impl.c
-rw-r--r-- 1 baz baz   12560 Apr 15 10:56 
volk_32fc_x2_multiply_32fc_a_orc_impl.c

-rw-r--r-- 1 baz baz6702 Apr 15 10:56 volk_32i_x2_and_32i_a_orc_impl.c
-rw-r--r-- 1 baz baz6691 Apr 15 10:56 volk_32i_x2_or_32i_a_orc_impl.c
-rw-r--r-- 1 baz baz6533 Apr 15 10:56 volk_8i_convert_16i_a_orc_impl.c
-rw-r--r-- 1 baz baz7790 Apr 15 10:56 
volk_8i_s32f_convert_32f_a_orc_impl.c

-rw-r--r-- 1 baz baz8171 Apr 15 10:56 volk_cpu.c
-rw-r--r-- 1 baz baz   31600 Apr 15 10:56 volk_machine_avx_64_mmx_orc.c
-rw-r--r-- 1 baz baz   22073 Apr 15 10:56 volk_machine_generic_orc.c
-rw-r--r-- 1 baz baz   27122 Apr 15 10:56 volk_machine_sse2_64_mmx_orc.c
-rw-r--r-- 1 baz baz   28765 Apr 15 10:56 volk_machine_sse3_64_orc.c
-rw-r--r-- 1 baz baz   30837 Apr 15 10:56 volk_machine_sse4_1_64_orc.c
-rw-r--r-- 1 baz baz   31052 Apr 15 10:56 volk_machine_sse4_2

[Discuss-gnuradio] Calculating the delay of TCP link.

[Sajjad Safdar]

Hi,
I am sending audio at 50 kHz sample rate via TCP sink from host A to other host 
B. The host B is connected via router in same network. How can i calculate the 
time delay from host A to host B via this TCP link.

Best Regards,
SAJJAD SAFDAR ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calculating the delay of TCP link.

[Mike Jameson]

Hi Sajjad,

Try tcping if ping doesn't do what you want:

http://www.linuxco.de/tcping/tcping.html

Mike

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


On 29 April 2013 20:01, Sajjad Safdar  wrote:

> Hi,
> I am sending audio at 50 kHz sample rate via TCP sink from host A to other
> host B. The host B is connected via router in same network. How can i
> calculate the time delay from host A to host B via this TCP link.
>
> Best Regards,
> SAJJAD SAFDAR
>
> ___
> 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] Calculating the delay of TCP link.

[Mike Jameson]

Hi Sajjad,

Ignore the last message! TCP Traceroute is actually what you are after:

http://michael.toren.net/code/tcptraceroute/

You will need to do a time to live of 1

Mike

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


On 29 April 2013 20:21, Mike Jameson  wrote:

> Hi Sajjad,
>
> Try tcping if ping doesn't do what you want:
>
> http://www.linuxco.de/tcping/tcping.html
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: m...@scanoo.com
> Web: http://scanoo.com
>
>
> On 29 April 2013 20:01, Sajjad Safdar  wrote:
>
>> Hi,
>> I am sending audio at 50 kHz sample rate via TCP sink from host A to
>> other host B. The host B is connected via router in same network. How can i
>> calculate the time delay from host A to host B via this TCP link.
>>
>> Best Regards,
>> SAJJAD SAFDAR
>>
>> ___
>> 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] Calculating the delay of TCP link.

[Mark McCarron]

Calculating delay is complex.

If you just want to know the average time between hosts on an IP network, then 
use the Ping command.  It has a RTT value in ms.  Just remember that on a 
packet switched network, this can vary but is typically under 1ms in a local 
environment.

Similar delays exist throughout the receive chain and processor, which are 
virtually impossible to measure accurately.

Accurate measurements like for radar, or bearings are impossible without some 
form of time-stamp at the receiver and that would require an atomic clock chip.

Regards,

Mark McCarron

Date: Mon, 29 Apr 2013 12:01:57 -0700
From: engrsajjadsaf...@yahoo.com
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Calculating the delay of TCP link.

Hi,I am sending audio at 50 kHz sample rate via TCP sink from host A to other 
host B. The host B is connected via router in same network. How can i calculate 
the time delay from host A to host B via this TCP link.
Best Regards,SAJJAD SAFDAR 
___
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] HackRF beta registration is now open

[Michael Ossmann]

Registration is now open for the HackRF beta test.  If you have an
invitation code from ToorCon 14 or the 2012 GNU Radio Conference, now is
the time to use it:

https://greatscottgadgets.com/forms/hackrf-beta-reg.html

HackRF beta units (Jawbreaker) will be shipped free of charge to
registered beta participants while availability lasts.  I expect to
receive more beta units than the number of codes distributed, so
register even if you don't have a code and you will be placed on a
waiting list for the additional units.

I expect to ship the beta units by the end of May.

For those of you new to HackRF, it is an open source hardware platform
for SDR.  HackRF is supported by gr-osmosdr (latest git).  For more
information:

https://greatscottgadgets.com/hackrf/

Thanks,

Mike

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

Re: [Discuss-gnuradio] how to convert python file in dat file

[Hanz]

If you want to load files into Matlab which you saved for example through a
file sink, you can do that via the command fread. Check the documentation of
it. For the correspondences between Matlab and GNU Radio Type, compare the
fread documentation and this site of J.Blum:
http://www.joshknows.com/gnuradio#datatypes

Regards



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-convert-python-file-in-dat-file-tp41048p41061.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] Link error in compilation of sample programs in /uhd/host/examples

[中城 智之]

Hi all,

I installed GnuRadio+UHD onto Ubuntu 12.10(64bit) and 13.04(64bit) by using 
build-gnuradio script in http://www.sbrac.org/files/build-gnuradio. No error 
message had been displayed in the installation. But a following link error 
message is shown when I compile sample c++ programs in /uhd/host/examples. 

 error message ***
>Scanning dependencies of target benchmark_rate
>[  5%] Building CXX object CMakeFiles/benchmark_rate.dir/benchmark_rate.cpp.o
>Linking CXX executable benchmark_rate
>/usr/bin/ld: CMakeFiles/benchmark_rate.dir/benchmark_rate.cpp.o: undefined 
reference to symbol >'_ZTVN5boost6detail16thread_data_baseE'
>/usr/bin/ld: note: '_ZTVN5boost6detail16thread_data_baseE' is defined in 
DSO /usr/lib/libboost_thread.so.1.49.0 >so try adding it to the linker command 
line
>/usr/lib/libboost_thread.so.1.49.0: could not read symbols: Invalid operation
>collect2: error: ld returned 1 exit status
>make[2]: *** [benchmark_rate] Error 1
>make[1]: *** [CMakeFiles/benchmark_rate.dir/all] Error 2
>make: *** [all] Error 2
***

The compile procedure I use is following:
$ mkdir /uhd/host/examples/build
$ cd /uhd/host/examples/build
$ cmake ../
$ make

"ldconfig -p | grep boost_thread" returns

libboost_thread.so.1.49.0 (libc6,x86-64) => /usr/lib/libboost_thread.so.1.49.0
libboost_thread.so (libc6,x86-64) => /usr/lib/libboost_thread.so

therefore, I think that the path to boost library is recognized by operating 
system.

I would like you to inform me my mistake.

Regards,
Nakajo


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

Re: [Discuss-gnuradio] Link error in compilation of sample programs in /uhd/host/examples

[Josh Blum]

> The compile procedure I use is following:
> $ mkdir /uhd/host/examples/build
> $ cd /uhd/host/examples/build
> $ cmake ../
> $ make
> 
> "ldconfig -p | grep boost_thread" returns
> 
> libboost_thread.so.1.49.0 (libc6,x86-64) => /usr/lib/libboost_thread.so.1.49.0
> libboost_thread.so (libc6,x86-64) => /usr/lib/libboost_thread.so
> 
> therefore, I think that the path to boost library is recognized by operating 
> system.
> 
> I would like you to inform me my mistake.
> 


So in this case, it looks like you configured the cmake project with the
root directory of /uhd/host/examples. However it cant be used this way.
A lot of important variables get set in the top level CMakelists.txt

For what its worth, the examples always get built with the install. You
can find them in install_prefix/lib/uhd/examples

-josh

> Regards,
> Nakajo
> 
> 
> ___
> 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] TDMA Engine Error

[Sam mite]

On Mon, Apr 29, 2013 at 12:53 PM, Sam mite  wrote:

>
> On Fri, Apr 26, 2013 at 10:15 AM, Josh Blum  wrote:
>
>>
>> >   File "/home/s/tdm/tdma_radio.py", line 70, in __init__
>> > freq=freq,
>> >   File "/home/s/.grc_gnuradio/tdma_hier.py", line 76, in __init__
>> > self.tdma_engine =
>> >
>> precog.tdma_engine(initial_slot,slot_interval,guard_interval,number_of_slots,lead_limit,link_speed)
>> >   File "/usr/local/lib/python2.7/dist-packages/precog/tdma_engine.py",
>> line
>> > 100, in __init__
>> > self.set_tag_propagation_policy(extras_swig.TPP_DONT)
>> > NameError: global name 'extras_swig' is not defined
>> >
>>
>> Looks like an import got removed from that file, but I dont think its
>> needed.
>>
>> try changing this trouble line to
>>
>> self.set_tag_propagation_policy(gnuradio.extras.TPP_DONT)
>>
>> Or if that doesnt work
>>
>> from gnuradio import extras
>> self.set_tag_propagation_policy(extras.TPP_DONT)
>>
>> -josh
>>
>
> Thanks that solved the problem. tdma_radio.grc ran without any error with
> output as follows:
>
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 100 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
> >>> gr_fir_fff: using SSE
>
> How can I use tdma_engine in my following FSK flow graph;
>
> TX Flow graph:
> File source ---> Packet Encoder ---> pack to unpack/chunks to symbol -->
> upsample  by 8---> Freq Mod---> USRP
>
> Lets say USRP sampling rate is 500k.
>
>  I want USRP to transmit for 1 second and then wait for 2 second (in these
> two seconds two other same type of transmitters would transmit)and this
> process should continue.  Can I do that? Where should I place this
> "tdma_engine" block. And what would be the values for its parameters?
>
> Thanks for the time.
>
> --
>
> Best Regards,
>
> Sam
>

Any thoughts or comments on this, please. Anyone done this before?

-- 

Best Regards,

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