Hi, I am using GNU Radio 3.6.3rc0 with Ubuntu 12.10
since I am new in GNURadio and python, I am currently using the
gnuradio-companion to build simple examples.
I have installed the Extras package and trying to use the Packet Framer.
Extras: Socket to Blob --> Extras: Packet Framer --> GMSK mod
al
one)
should I compile it after changing it?
Thanks for your quick response :)
Guy
On Sun, Jan 13, 2013 at 8:35 PM, Josh Blum wrote:
>
>
> On 01/13/2013 07:18 AM, Guy Holtzman wrote:
> > Hi, I am using GNU Radio 3.6.3rc0 with Ubuntu 12.10
> > since I am new in GNURadio and p
yes, it seems to have solved the problem
thanks! Guy
On Mon, Jan 14, 2013 at 8:03 PM, Josh Blum wrote:
>
>
> On 01/14/2013 03:46 AM, Guy Holtzman wrote:
> > I have 2 files named extras_pmt.py:
> > [1] /home/guy/grextras/python/extras_pmt.py
> > [2] usr/local/
I am thinking of developing a TDMA MAC + PHY using GNURadio for low speed
communication (upto 200KBits per second) for prototyping. since OpenBTS
has successively implemented a GSM BS using GNURadio, this seems to be
a reasonable choice. but unlike OpenBTS, I want to avoid HW (clock changes)
or FP
mplementation. Porting to C++ is one obvious suggestion to improve
> performance.
>
> -John
>
>
>
> On Mon, Jan 21, 2013 at 6:16 AM, Guy Holtzman wrote:
>
>> I am thinking of developing a TDMA MAC + PHY using GNURadio for low speed
>> communication (upto 200KBi
Yes, Thanks
On Wed, Jan 23, 2013 at 8:33 PM, Josh Blum wrote:
>
>
> On 01/23/2013 12:18 PM, Guy Holtzman wrote:
> > Hi Again, and thanks for you answer :) . (I was out yesterday, so I did
> not
> > see your answer)
> >
> > As I understood the lead time is a
I am having the same issue, I tried Josh suggestion without success.
I have installed Extras and pre-cog using:
https://github.com/jmalsbury/pre-cog/wiki/Installation
what should I do to make it work?
here is a error log containing the versions I am using:
linux; GNU C++ version 4.6.3; Boost_
dio entirely and then the
> error disappeared.
>
>
> On Mon, May 27, 2013 at 12:36 PM, Guy Holtzman wrote:
>
>> I am having the same issue, I tried Josh suggestion without success.
>> I have installed Extras and pre-cog using:
>> https://github.com/jmalsbury/pre-cog/w
gnuradio and then reinstall bu
> ./build_gnuradio.
>
>
> On Mon, May 27, 2013 at 4:36 PM, Guy Holtzman wrote:
>
>> I am already working with the latest version of GNU Radio.
>> in which dir the libgnuradio-extras.so should appear and, which package
>> bulids it?
the problem was the lack of ldconfig in the end of the installation
I used:
sudo ldconfig
after the installation of extras, and it solved the problem
On Tue, May 28, 2013 at 9:08 PM, Guy Holtzman wrote:
> can it be a permission problem?
> I tried added a print before the error and disc
I have two USRP B100 and I am trying to sync them
for that I have connected them both to reference and 1pps from the same
source
the source is a rubidium standard source reference
it has a 10MHZ 1Vrms 50 ohm sine and 1pps outputs. I have tested it with a
scope to see if its stable.
for my test I tr
a command that could check if the USRP is locked to the external
clock?
what is the best way to debug this and to find the root cause?
Thanks for your help,
Guy
On Sun, Jun 2, 2013 at 9:55 PM, Marcus D. Leech wrote:
> **
> On 06/02/2013 02:49 PM, Guy Holtzman wrote:
>
> I h
LED E is always on, even when I disconnect the external source
I used this command on the Tx:
uhd.tune_request(91500)
and this command on the Rx:
uhd.tune_request(91500,10e6)
the freq is now very stable
but there is a constant shift of 570 Hz between Rx and Tx
another strange thing happ
is not related to the
rate itself since 25 does not work while 256000 does work (and they
both divide by 64MHz with an even result, the clock I am using)
Thanks, Guy
On Wed, Jan 23, 2013 at 10:46 PM, Guy Holtzman wrote:
> Yes, Thanks
>
>
> On Wed, Jan 23, 2013 at 8:33 PM, Josh
ing with more-complete control
> over the RF and DSP tuning aspects:
>
> http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
>
> I'd suggest you familiarize yourself with the entire documentation tree
> that's online:
>
> http://ettus-apps.sourcerepo
on the Rx side, I use uhd.tune_request(91500,10e6)
then I down-sample and display a FFT
the amount of down-sampling is enough that I can see how much frequency
offset I get.
I am testing it with a carrier generated from a second B100, using
uhd.tune_request(91500)
even if the reference had
OK, I discovered what was the problem.
it turns out I did not generate a carrier, but a just constant 0 (instead
of constant 0.7)
when generating a carrier, the Rx and Tx are perfectly synced
sorry for all the trouble, and thanks for the help
Guy
On Tue, Jun 4, 2013 at 8:57 PM, Guy Holtzman
17 matches
Mail list logo
