discuss-gnuradio
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 127, Issue 9

From: duanyiemo3
Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 127, Issue 9
Date: Fri, 21 Jun 2013 17:45:40 +0800
hans:
        your supire i want you startx your unbint .the last list i can't understand your idea.but the one of the list will be ok.
 
http://www.exploit-db.com/wp-content/themes/exploit/docs/26314.pdf cheeck this one .
 the php webshell about the way we can atccteked the install.
 
 
duanyiemo3
 
Date: 2013-06-07 00:01
Subject: Discuss-gnuradio Digest, Vol 127, Issue 9
Send Discuss-gnuradio mailing list submissions to
address@hidden
 
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
 
You can reach the person managing the list at
address@hidden
 
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
 
 
Today's Topics:
 
   1. Re: Sampling glitch in the RX path (John Malsbury)
   2. Error in grid_plotter.py (Marcus D. Leech)
   3. Re: Sampling glitch in the RX path (Miklos Maroti)
   4. GNU Radio (etc) via MacPorts Update (Michael Dickens)
   5. GnuRadio +  EveryCircuit? (Joel Mayer)
   6. PC/SC reader emulation (Ghazamfar)
   7. Ucla Zigbee compiling issues on MacOs X and Ubuntu 12.04.2
      LTS (Arturo Rinaldi)
   8. Slow app launch (Dan Aldrich)
   9. Re: Ucla Zigbee compiling issues on MacOs X and Ubuntu
      12.04.2 LTS (Bastian Bloessl)
  10. CRC boost library (Nemanja Savic)
  11. How to save/read sc8 format to/from file and convert it to
      complex float 32? (Rickard)
  12. Re: CRC boost library (Martin Braun (CEL))
  13. Re: CRC boost library (Nemanja Savic)
  14. Fwd: time_recov and freq_recov in generic_mod_demod (Adeel Anwar)
  15. Re: How to save/read sc8 format to/from file and convert it
      to complex float 32? (Josh Blum)
  16. Re: How to save/read sc8 format to/from file and convert it
      to complex float 32? (Michael Ossmann)
 
 
----------------------------------------------------------------------
 
Message: 1
Date: Wed, 5 Jun 2013 09:16:33 -0700
From: John Malsbury <address@hidden>
To: Miklos Maroti <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Sampling glitch in the RX path
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
 
If there are no overruns, you are most likely not dropping samples.  The
switch from rx to tx and back will not impact the received sample stream.
Increase your packet lead time from 10 ms.  Keep in mind that the PC will
have some process jitter so that actual transfer of the burst may vary from
the nominal 10 ms lead you're asking for.  If the PC is a little slow, or
the OS is busy doing something else, you might deliver a late packet.
 
Anyway, once you've got the system working consistently, you can working on
optimizing things for lower latency (lead time).
 
-John
 
 
On Wed, Jun 5, 2013 at 8:58 AM, Miklos Maroti <address@hidden>wrote:
 
> Hi Guys,
>
> I am using N210 with SBX at 5M sampling rate. I have one USRP Source
> running continuously (connected to the TX/RX antenna), and a USRP Sink
> (connected also to TX/RX) that sends timed packets with the tx_time,
> tx_sob, tx_eob tags at a rate of 1 ms per packet. I am sending packets
> 10 ms prior to the USRP Sink and I use the sample counter of the USRP
> Source to monitor the time on the FPGA.
>
> After some time I am observing timing errors (L) that I cannot
> explain. The only possible explanation would be a sampling glitch in
> the RX path when switching between TX and RX. That is, it seems that a
> few samples are lost in the RX path when the switch is made, and
> therefore the FPGA time and the number of samples received are
> diverging over time (by a small amount for each switch). I do not
> observe this behavior at 500K sampling rate, there no RX samples seem
> to be lost. There are no underruns/overruns prior to the lots of L's.
>
> Any ideas why this is happening and whether it can be prevented somehow?
>
> Miklos
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130605/e3b40feb/attachment.html>
 
------------------------------
 
Message: 2
Date: Wed, 05 Jun 2013 12:30:52 -0400
From: "Marcus D. Leech" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Error in grid_plotter.py
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
I have a user who is occasionally getting this:
 
raceback (most recent call last):
   File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/common.py", 
line 106, in <lambda>
     self._plotter.Bind(wx.EVT_LEFT_DOWN, lambda evt: 
plotter.call_freq_callback(evt.GetPosition()))
   File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/grid_plotter_base.py", 
line 90, in call_freq_callback
     x, y = self._point_label_coordinate
TypeError: 'NoneType' object is not iterable
 
In the "simple_ra" app, which does establish a call-back for left-clicky 
in the spectral window.
 
Is this perhaps because the callback is getting called at a time when 
the plotter isn't fully set up, and how can we detect that case properly?
 
 
-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
 
 
 
 
------------------------------
 
Message: 3
Date: Wed, 5 Jun 2013 12:35:33 -0500
From: Miklos Maroti <address@hidden>
To: John Malsbury <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Sampling glitch in the RX path
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
 
Hi John,
 
Thanks for the quick reply. Increasing the lead time will just delay
the occurrence of the storm of L's (when the host gets permanently
behind the USRP). Here is some data which supports this claim and I
think the TX/RX switch rate influences these:
 
1) I periodically send for 0.9 ms timed with tx_time, tx_sob, tx_eob,
followed by 0.1 ms gap. I use 20 ms lead time, and I measure the
number of seconds the flowgraph can run before it falls behind (lots
of L's). I have run this 3 times, and got 43 sec, 44 sec, 37 sec.
 
2) 0.9 ms TX, 0.1 ms RX, 30 ms lead, runs for 60 sec, 53 sec, 67 sec
 
3) 0.9 ms TX, 0.1 ms RX, 40 ms lead, runs for 107 sec, 87 sec, 104 sec
 
Thus run time increased linearly with the increase of the lead time.
 
4) 0.4 ms TX, 0.1 ms RX, 40 ms lead, runs for 55 sec, 62 sec, 54 sec
 
Thus if you increase the rate of TX/RX switches then the run time
decreases linearly
 
5) 1 ms TX, 1 ms RX, 20 ms lead, runs for 149 sec, 124 sec, 68 sec
 
6) 1 ms TX, 1 ms RX, 40 ms lead, runs for 391 sec, 219 sec, 283 sec
 
Thus decreasing the packet rate will increase the run time. In
scenario 5) and 6) it will gradually get more and more L's (between
packets) until it hits the wall. And I also observe U's but no O's
overruns. Thus as we are eating up our lead time and getting closer to
the edge the USRP is not getting enough data and the times are getting
worse and worse until all of the packets are in the past.
 
>From this I deduce that there must be an RX sampling glitch when
switching between TX/RX, no?
 
Best,
Miklos
 
On Wed, Jun 5, 2013 at 11:16 AM, John Malsbury <address@hidden> wrote:
> If there are no overruns, you are most likely not dropping samples.  The
> switch from rx to tx and back will not impact the received sample stream.
> Increase your packet lead time from 10 ms.  Keep in mind that the PC will
> have some process jitter so that actual transfer of the burst may vary from
> the nominal 10 ms lead you're asking for.  If the PC is a little slow, or
> the OS is busy doing something else, you might deliver a late packet.
>
> Anyway, once you've got the system working consistently, you can working on
> optimizing things for lower latency (lead time).
>
> -John
>
>
> On Wed, Jun 5, 2013 at 8:58 AM, Miklos Maroti <address@hidden>
> wrote:
>>
>> Hi Guys,
>>
>> I am using N210 with SBX at 5M sampling rate. I have one USRP Source
>> running continuously (connected to the TX/RX antenna), and a USRP Sink
>> (connected also to TX/RX) that sends timed packets with the tx_time,
>> tx_sob, tx_eob tags at a rate of 1 ms per packet. I am sending packets
>> 10 ms prior to the USRP Sink and I use the sample counter of the USRP
>> Source to monitor the time on the FPGA.
>>
>> After some time I am observing timing errors (L) that I cannot
>> explain. The only possible explanation would be a sampling glitch in
>> the RX path when switching between TX and RX. That is, it seems that a
>> few samples are lost in the RX path when the switch is made, and
>> therefore the FPGA time and the number of samples received are
>> diverging over time (by a small amount for each switch). I do not
>> observe this behavior at 500K sampling rate, there no RX samples seem
>> to be lost. There are no underruns/overruns prior to the lots of L's.
>>
>> Any ideas why this is happening and whether it can be prevented somehow?
>>
>> Miklos
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
 
 
 
------------------------------
 
Message: 4
Date: Wed, 5 Jun 2013 13:49:30 -0400
From: Michael Dickens <address@hidden>
To: "address@hidden List" <address@hidden>
Subject: [Discuss-gnuradio] GNU Radio (etc) via MacPorts Update
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
 
I finally finished the gnuradio (and related) ports today, for install via MacPorts on Mac OS X (mainly 10.6+, but should work on 10.4+).  I split gr-osmosdr off such that there is a 3.6 API version and a 3.7 API version -- respective: gr-osmosdr and gr-osmosdr-next.  The GNU Radio ports are split similarly: gnuradio and gnuradio-devel are for 3.6 API, and gnuradio-next is for 3.7 API.  gnuradio-devel will track to 'maint' branch, while gnuradio-next will track the 'master' branch until, and maybe beyond, the 3.7 release -- I'll deal with that issue when the release gets there.
 
Not surprisingly, gr-osmosdr-next requires gnuradio-next; MacPorts will verify that the correct ports are installed.  gr-osmosdr required either gnuradio or gnuradio-devel, so I had to add a specific check to make sure gnuradio-next is not installed.  After quite a bit of testing to make sure the various tests worked, I pushed the commits yesterday and today, and I think all is OK again in MacPorts GNU Radio land after last week's merging of master and next, and moving towards using the 3.7 API and away from the 3.6 API.
 
If you have any issue that you believe is MacPorts related, let me know here, to my email directly, via MacPorts user's list, or via a MacPorts ticket.  If you use Mac OS X and have an issue with GNU Radio, no matter how it is installed, I can generally help you out, too.  Happy hacking! - MLD
 
 
 
 
------------------------------
 
Message: 5
Date: Wed, 5 Jun 2013 13:00:41 -0500
From: "Joel Mayer" <address@hidden>
To: <address@hidden>
Subject: [Discuss-gnuradio] GnuRadio +  EveryCircuit?
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
 
Here is a link to an Android ap called: EveryCircuit
 
http://www.everycircuit.com/<http://www.everycircuit.com/>
 
My question is, if I learn how to design circuits
on this application, will I gain insights into the
subtleties of gnuradio?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130605/3e3937f0/attachment.html>
 
------------------------------
 
Message: 6
Date: Wed, 5 Jun 2013 12:22:51 -0700 (PDT)
From: Ghazamfar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] PC/SC reader emulation
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
 
Greetings-
Can I emulate a PC/SC reader with GNU radio? Does anyone have any code or
configuration, which I can leverage please?
Regards-
Ghazamfar
 
 
 
--
View this message in context: http://gnuradio.4.n7.nabble.com/PC-SC-reader-emulation-tp41825.html
Sent from the GnuRadio mailing list archive at Nabble.com.
 
 
 
------------------------------
 
Message: 7
Date: Thu, 06 Jun 2013 01:55:55 +0200
From: Arturo Rinaldi <address@hidden>
To: GNU Radio mailing list <address@hidden>
Subject: [Discuss-gnuradio] Ucla Zigbee compiling issues on MacOs X
and Ubuntu 12.04.2 LTS
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
 
Hi folks,
 
I have recently bumped into some issues when building the ucla_zigbee 
platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two 
setups :
 
*Setup 1*
 
MacOs X 10.7.4
Macports 2.1.3 (It was used for getting the gnuradio dependencies)
GNU Radio 3.6.4.2 installed from tarball (and not from macports)
 
I attach the "make" log error file. So I tried to tweak the 
Makefile.common file this way :
 
/# includes//
//grincludedir  = /usr/local/include/gnuradio/swig//
//
//# swig includes //
//swigincludedir = /usr/local/include/gruel/swig/
 
but then then i the errors reported in the ucla_error_2.txt log file 
which is really strange since /usr/local/include/gnuradio should already 
be in the system path.
 
P.S. : By using the tweak i didn't get any error if the installation of 
gnuradio is performed by macports. Is there to add the
 
//usr/local/include/gruel/swig
 
/includes to the Makefile.common file ?
 
*Setup 2*
 
Ubuntu 12.02.2 LTS
GNU Radio 3.6.4.1 (Binary deb version from Ettus Research)
 
Th built-in gcc compiler (the 4.6.3) returns build errors so I decided 
to install and set the alternatives to gcc, g++ and cpp 4.5 which are 
mantained in the 12.04 official repos.
 
The building from source went smoothly but this time i have installation 
issues. In fact i experienced an installation error when the compiler 
enters the /*source/python* directory. I can't post the log file since i 
don't currently have this machine by my side but i'll post it in a few 
hours.
 
Has anyone of you experienced similar issues at least on one of the setups ?
 
Thanks in advance
 
Kind Regards,
 
                    Arturo
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/6d0db8e7/attachment.html>
-------------- next part --------------
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in src
Making all in lib
/opt/local/bin/swig -c++ -fvirtual -python -modern -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/local/include/gnuradio/swig -I/usr/local/include/gnuradio -module ucla -o ucla.cc ucla.i
/usr/local/include/gnuradio/swig/gnuradio.i:31: Error: Unable to find 'gruel_common.i'
/usr/local/include/gnuradio/swig/gr_basic_block.i:26: Error: Unable to find 'pmt_swig.i'
make[3]: *** [ucla.cc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 1489 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/6d0db8e7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.common
Type: application/octet-stream
Size: 1240 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/6d0db8e7/attachment.obj>
-------------- next part --------------
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in src
Making all in lib
/opt/local/bin/swig -c++ -fvirtual -python -modern -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/local/include/gruel/swig -I/usr/local/include/gnuradio/swig -module ucla -o ucla.cc ucla.i
/usr/local/include/gnuradio/swig/gnuradio.i:47: Error: Unable to find 'gr_types.h'
make[3]: *** [ucla.cc] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
 
------------------------------
 
Message: 8
Date: Wed, 5 Jun 2013 21:13:55 -0400
From: Dan Aldrich <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Slow app launch
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
 
Not sure if this is gnuradio related or xQuartz, but gnuradio_companion is slow to launch (MacOS i7 processor). Gpredict also behaves the same way. Once launched, everything is fine. I'm thinking it's more related to XQuartz. Anyone else seen this?
 
Thanks,
-d
 
 
------------------------------
 
Message: 9
Date: Thu, 06 Jun 2013 07:23:52 +0200
From: Bastian Bloessl <address@hidden>
To: Arturo Rinaldi <address@hidden>
Cc: GNU Radio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] Ucla Zigbee compiling issues on MacOs
X and Ubuntu 12.04.2 LTS
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
Hello Arturo,
 
On 06/06/2013 01:55 AM, Arturo Rinaldi wrote:
> I have recently bumped into some issues when building the ucla_zigbee
> platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two
> setups :
 
I think the UCLA blocks were not updated to work with GNU Radio 3.6.4. I 
made some 802.15.4 blocks based on the UCLA Phy. Maybe you want to give 
them a try.
 
https://github.com/bastibl/gr-ieee802-15-4
 
The last commits port the blocks to v3.7 API. If you want to use 3.6.4 
you should go back some commits
 
git checkout v3.6
 
Best,
Bastian
 
 
 
 
------------------------------
 
Message: 10
Date: Thu, 6 Jun 2013 10:17:24 +0200
From: Nemanja Savic <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] CRC boost library
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
 
Hi all guys,
 
I've just been wondering has anybody of you tried this:
 
http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html
 
and how it fits if yes.
 
Best regards,
 
-- 
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/14b8f5c5/attachment.html>
 
------------------------------
 
Message: 11
Date: Thu, 6 Jun 2013 12:38:36 +0200
From: Rickard <address@hidden>
To: List List <address@hidden>, "address@hidden"
<address@hidden>
Subject: [Discuss-gnuradio] How to save/read sc8 format to/from file
and convert it to complex float 32?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
 
Hi gurus,
 
- Which is the simplest way, preferably directly in grc, to compactly save 8bit I/Q data (sc8) from an UHD source to a file instead the of the standard format complex float 32 (which is 4 times larger) ?
 
- Then also, how to convert received and saved sc8 data to the normal complex float 32 in grc?
 
The reason is that I want to take advantage of the sc8 reduced precision by reducing the file size when storing received data to file.   That is, not only halve the bandwidth "over the wire" (compared to sc16) but also reduce the file size when storing. 
 
Or is there alternative and better ways to accomplish this when receiving and saving raw 8 bit I/Q data?
 
In GRC I see its possible to select the output format "complex int 16", instead of the standard "complex float 32", but I don't find how to process or interpret this format further (e.g. saving, reading, converting to complex float 32, etc). 
 
Thanks,
Rickard
 
 
------------------------------
 
Message: 12
Date: Thu, 6 Jun 2013 15:12:52 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] CRC boost library
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
 
On Thu, Jun 06, 2013 at 10:17:24AM +0200, Nemanja Savic wrote:
> Hi all guys,
> 
> 
> I've just been wondering has anybody of you tried this:
> 
> http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html
 
Tim just pushed a change to master where the crc32_bb stream block uses
just that. Plus we might use it in the packet header generators/parsers.
 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/38af2dcd/attachment.pgp>
 
------------------------------
 
Message: 13
Date: Thu, 6 Jun 2013 15:36:04 +0200
From: Nemanja Savic <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] CRC boost library
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
 
Thank you Martin.
Meanwhile I tried, and works just fine.
 
Best
 
 
On Thu, Jun 6, 2013 at 3:12 PM, Martin Braun (CEL) <address@hidden>wrote:
 
> On Thu, Jun 06, 2013 at 10:17:24AM +0200, Nemanja Savic wrote:
> > Hi all guys,
> >
> >
> > I've just been wondering has anybody of you tried this:
> >
> > http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html
>
> Tim just pushed a change to master where the crc32_bb stream block uses
> just that. Plus we might use it in the packet header generators/parsers.
>
> 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
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
 
 
-- 
Nemanja Savi?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/34316841/attachment.html>
 
------------------------------
 
Message: 14
Date: Thu, 6 Jun 2013 06:44:14 -0700
From: Adeel Anwar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Fwd: time_recov and freq_recov in
generic_mod_demod
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
 
Ada,
 
 
>As I looked up from the documents, it was said that the signal after the
usrp source at the receiver, is baseband signal, whose central >frequency
is around 0 Hz, and already take off the carrier frequency. But in the
demodulation, there are still freq_recov and time_recov block. >Are they at
the symbol level?
 
Yes and  there is always a freq-difference between Tx and Rx LO due to this
there will always be some freq-offset
 
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Why-is-there-always-a-frequency-offset-when-transmitting-from-one-USRP-to-another
 
>I'm quite confused with how the benchmark, actually the demodulation in
generic_mod_demod.py works. When does the carrier frequency is >taken off?
In USRP. Timing recovery for compensating timing-offset, Freq-Recovery for
freq-offset.
 
http://gnuradio.org/doc/doxygen/classdigital__pfb__clock__sync__ccf.html
http://gnuradio.org/doc/doxygen/classdigital__fll__band__edge__cc.html
 
-Adeel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130606/7020298c/attachment.html>
 
------------------------------
 
Message: 15
Date: Thu, 06 Jun 2013 11:27:02 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] How to save/read sc8 format to/from
file and convert it to complex float 32?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
 
 
 
On 06/06/2013 06:38 AM, Rickard wrote:
> Hi gurus,
> 
> - Which is the simplest way, preferably directly in grc, to compactly
> save 8bit I/Q data (sc8) from an UHD source to a file instead the of
> the standard format complex float 32 (which is 4 times larger) ?
> 
> - Then also, how to convert received and saved sc8 data to the normal
> complex float 32 in grc?
> 
 
A block that implements this conversion w/ a configurable scalar would
be ideal. But there may not be such a direct block: there are float to
char, char to float converters. And you can use this with complex
to/from float and vector to/from streams block to get the two lanes of
data into one.
 
-josh
 
> The reason is that I want to take advantage of the sc8 reduced
> precision by reducing the file size when storing received data to
> file.   That is, not only halve the bandwidth "over the wire"
> (compared to sc16) but also reduce the file size when storing.
> 
> Or is there alternative and better ways to accomplish this when
> receiving and saving raw 8 bit I/Q data?
> 
> In GRC I see its possible to select the output format "complex int
> 16", instead of the standard "complex float 32", but I don't find how
> to process or interpret this format further (e.g. saving, reading,
> converting to complex float 32, etc).
> 
> Thanks, Rickard _______________________________________________ 
> Discuss-gnuradio mailing list address@hidden 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
 
 
 
------------------------------
 
Message: 16
Date: Thu, 6 Jun 2013 09:46:07 -0600
From: Michael Ossmann <address@hidden>
To: Josh Blum <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] How to save/read sc8 format to/from
file and convert it to complex float 32?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
 
On Thu, Jun 06, 2013 at 11:27:02AM -0400, Josh Blum wrote:
>
> A block that implements this conversion w/ a configurable scalar would
> be ideal.
 
That would be very nice.  I've been using (for input from sc8 file to a
complex flowgraph):
 
UChar to Float -> Deinterleave => Float to Complex
 
Since my samples are unsigned chars, this gives me an offset of
approximately 128 that I can correct with Add Const either before
Deinterleave or after Float to Complex (where it is 128+128j).
 
Unsigned sc8 is the primary data format used by HackRF, so this may be
interesting to other HackRF users.  The conversion is handled by
gr-osmosdr when communicating with a HackRF directly from GNU Radio, but
files transmitted or received via the hackrf_transfer utility are in the
unsigned sc8 format.
 
Mike
 
 
 
------------------------------
 
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
End of Discuss-gnuradio Digest, Vol 127, Issue 9
************************************************
reply via email to
[Prev in Thread] Current Thread [Next in Thread]