no, but I proposed a different way in my first reply.
On 15.02.24 12:41, Arhum Ahmad wrote:
Yes, in that case, could we reduce the strength of DC so that it won't interfere while
detecting the signal's frequency (on the run)?
On Thu, Feb 15, 2024 at 4:40 PM Marcus Müller
Yes, in that case, could we reduce the strength of DC so that it won't
interfere while detecting the signal's frequency (on the run)?
On Thu, Feb 15, 2024 at 4:40 PM Marcus Müller
wrote:
> Hey,
>
> can we keep this on the mailing list, please?
>
> But logically, if you have signal of interest
Hi Arhum,
some limited amount of DC offset is sadly to be expected from any direct conversion
architecture (that's a result of LO leakage as well as systematic DC offset).
Since DC is the lowest of all possible frequencies, a high-pass filter can be used to
eliminate it. The design of that
Hi David!
I'd be very lazy: just pad your pre-recorded signal with zeros, and play it on loop with
the file source.
Padding of files is easy, and essentially free in terms of storage space if your file
system supports sparse files (and if you're on linux, yes, it almost certainly does).
>
> Another possibility is to write your own source block which reads and stores
> the samples in memory, then outputs them at a specified time until the
> whole buffer is transmitted, then sleeps for a while and repeats. If you
> need to control actual transmission time more precisely it can be
On Wednesday, 7 February 2024 21:03:11 EET Daniel Estévez wrote:
>
> Hi David,
>
> One possible solution would be to make a flowgraph that plays the file
> once. Then make a bash script that loops, calling the flowgraph and then
> sleeping for some time.
>
> Best,
> Daniel.
>
Another
On 07/02/2024 17:09, David Barnhart wrote:
Hi all: I teach a course at USC on satellite ground communications
that is a lab-based class.
I would like to setup an intermittent transmission using a recorded
beacon that we have used before (in cfile format) to have them practice
“catching
Hello there, I managed to record 10Mhz of sample rate which u can find
here:
https://transfer.sh/vxuyz7zPyH/SDRSharp_20230928_110124Z_67610Hz_IQ.wav
It seams that interfering signal is infact DVB-T on Channel 46 with Center
frequency of 674 MHz
I also managed to capture that interference
Do you know this site?
https://www.sigidwiki.com/wiki/Signal_Identification_Guide
I had a short peek and could not find anything, but you may have a bit
more patience.
Best
Fabian
Am 27.09.23 um 13:21 schrieb veso...@gmail.com:
Hello there all, I hope someone can help me
I am trying to
Hi,
I'm not a radio engineer and don't use gnuradio much but used to think
about these things for hobby hacking.
Thoughts:
- Recording from multiple antennas simultaneously could:
- provide for separating it from the signal using a blind source
separation approach
- give more information on
Hello,
Taking a quick look at your recording, I see some kind of pulsed signal
that follows a regular pattern. The signal is on for a period of ~548
usec, then off for two periods of this duration (~548 usec per period),
and then the same repeats forever (one period on, two periods off). This
On 25/06/2023 16:49, Arhum Ahmad wrote:
Respected sir,
I am using N-200 USRP for transmitting a signal. While transmitting, I
havechangedthe Gain value in the SDRutransmitting block, but my signal
strength at the receiver remains the same. I also stop and restart the
code but the change in
You've probably already found
https://wiki.gnuradio.org/index.php/Message_Pair_to_Var
For example, if samp_rate is the target variable, you end up with something
like
self.p2v = blocks.msg_pair_to_var(self.set_samp_rate)
which will then call
def set_samp_rate(self, samp_rate):
Dear all,
This issue has been resolved through a chat at https://chat.gnuradio.orgwith
funkylab and drmpeg in the time interval: Indian Standard Time 14:24 to
16:38 dated 1st November 2022.
Please have a look if you are interested.
Thank you.
With regards,
Shuvodip
On Tue, Nov 1, 2022 at
See
https://wiki.gnuradio.org/index.php?title=SuggestedReading
-- CInaed
On 11/1/22 00:35, Shuvodip Majumdar wrote:
Hello Cinaed,
My doubt is not about the data types. It's about what the fields
signify, e.g. symbol rate, sampling rate, excess bandwidth etc.
Regards,
Shuvodip
On Tue, Nov
Hello Cinaed,
My doubt is not about the data types. It's about what the fields signify,
e.g. symbol rate, sampling rate, excess bandwidth etc.
Regards,
Shuvodip
On Tue, Nov 1, 2022 at 12:49 PM Cinaed Simson
wrote:
> Hi Shuvodip - if the blocks have the same color, then they have the
> same
Hi Shuvodip - if the blocks have the same color, then they have the
same data type - but not necessarily the same value.
What version of gnuradio are you using?
-- Cinaed
On 10/31/22 21:41, Shuvodip Majumdar wrote:
Dear all,
I am currently going through the tutorials of GNU Radio. Here I
Dear Kyeong,
Thank you very much. It worked perfect.
Regards,
Shuvodip
On Wed, 26 Oct, 2022, 17:43 Kyeong Su Shin, wrote:
> Hello Shuvodip:
>
> It simply takes STFT of the raw input data after applying a windowing
> function to them. No further calibrations or amplitude corrections are
>
Hi Rohith - in the Protocol Formatter, the hdr_format, I'm fairly
certain the hdr denotes "High Dynamic Range" used in imaging - TV images
for instance.
In which case, it may easily generate 4 times the data then your
sentence contains in bits.
-- Cinaed
On 10/13/22 02:17, Rohith Rajan
"A curse is just a special kind of magic."
– M. Müller's corollary
(seriously, though, we're doing good on the enabling-the-good-kind-of-magic
side.)
On 28.03.22 17:00, Ed Criscuolo wrote:
“Any sufficiently advanced technology is indistinguishable from magic.”
— A. C. Clarke
@(^.^)@ Ed
Sent
“Any sufficiently advanced technology is indistinguishable from magic.”
— A. C. Clarke
@(^.^)@ Ed
Sent from my iPhone
> On Mar 28, 2022, at 9:25 AM, Robert McGwier wrote:
>
>
> GnuRadio is so good it can even do magic. 邏
>
>> On Mon, Mar 28, 2022, 2:01 AM Lorenzo Mainardi wrote:
>> As
GnuRadio is so good it can even do magic. 邏
On Mon, Mar 28, 2022, 2:01 AM Lorenzo Mainardi wrote:
> As last resource I tried to update the libraries and the problem is
> magically solved.
> Thank you everyone for the support.
>
> Il dom 27 mar 2022, 18:46 Lorenzo Mainardi ha
> scritto:
>
>>
As last resource I tried to update the libraries and the problem is
magically solved.
Thank you everyone for the support.
Il dom 27 mar 2022, 18:46 Lorenzo Mainardi ha scritto:
> Hello everyone, I am trying to make a cheap USB dongle working with
> gnuradio and gnuradio-companion.
> I just
On 2022-03-27 15:32, Marcus Müller wrote:
Is 32k a supported sampling rate? Sounds two orders of magnitude too low.
The lowest RTL supported sampling rate is 250K, and then there's a jump
with no supported
rates until something like 900K.
For a single WBFM channel, you need the 250K
Is 32k a supported sampling rate? Sounds two orders of magnitude too low.
On 27.03.22 21:22, Lorenzo Mainardi wrote:
The error about PLL should be just "cosmetic" and not have any impact.
Anyway, I think I setup correctly both the correct frequency (I would
like to test the broadband FM, so
The error about PLL should be just "cosmetic" and not have any impact.
Anyway, I think I setup correctly both the correct frequency (I would
like to test the broadband FM, so 100e6) both the sampling frequency
(32k).
The real issue is the "Return code -11" error, I cannot find anything
about that.
Hi,
did you set the correct frequency? If it is outside the allowed range,
it is expected that the PLL cannot lock.
Best,
Fabian
Am 27.03.22 um 18:46 schrieb Lorenzo Mainardi:
Hello everyone, I am trying to make a cheap USB dongle working with
gnuradio and gnuradio-companion.
I just tried to
On Fri, Feb 11, 2022 at 01:36:59PM +, e heuchamps wrote:
> I have read in a thread in this forum that the sampling rate (usually
> denoted by the variable "samp_rate") is just a number representing how
> much values are in a period of the signal. This means that, for signal
> with frequency
dio 3.8.1, when using 3.8.2?
>
> Regards,
>
> Thangaraj
>
>
>
> Von: Paul Atreides
> Gesendet: Dienstag, 19. Oktober 2021 20:07
> An: Thangaraj Mukara Dhakshinamoorthy
> Cc: Ron Economos ; discuss-gnuradio@gnu.org
> Betreff: Re: Help- gr-lora OOT Modul
; PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3/dist-packages
> komro@komro-HP-ProBook-6560b:~$ printenv
> .
> .
> PYTHONPATH=:/usr/local/lib/python3/dist-packages
> .
> .
>
> But nothing fixed the issue yet, could anyone please help?
>
> Regards,
> Thangaraj
>
> Von: Discuss
You need to install liborc.
sudo apt-get install liborc-0.4-dev
Ron
On 10/19/21 6:12 AM, Thangaraj Mukara Dhakshinamoorthy wrote:
Hello,
My system config:
OS: Ubuntu 20.04.3 LTS
OS Type: 64-bit
RAM: 3.8 GB
Processor: Intel Core i5-2450M CPU @2.50GHz x4
UHD version: 3.15.0.0
GNU Radio
Many thanks Marcus and Cristophe for your answers.
I keep on working, I appreciate your help very much.
All best
stefano
Il 30/03/2021 20:01, Marcus Müller ha scritto:
Hi Stefano,
no need to thank me for patience, you're doing cool stuff! (but
please, always keep the mailing list in CC:,
Hi Stefano,
no need to thank me for patience, you're doing cool stuff! (but please,
always keep the mailing list in CC:, as there are multiple people who
can help you!)
The aO means "audio device is overflowing", which means you're not
getting the data away from the audio source quickly
Here again, struggling with another attempt to transmit in AM instead of
FM, I've copied/modified the grc file found at
https://wiki.gnuradio.org/index.php/Simulation_example:_AM_transmitter_and_receiver
I get the following error line, which I don't understand as it seems to
me identical to
Why are you doing short to float, if the output of the audio source is already
float?
On 30.03.21 01:47, Stefano Zorzanello wrote:
> Dear list,
>
> as a newbie I ask you for your help with the attached file. For a
> sound-installation
> purpose I'd like to transmit a weak signal, which is
# Make sure we're not leaving behind remnants of previous versions
cd gr-satellites/build
sudo make uninstall
# Get the newest state
git pull origin maint-3.8
# Build fresh
make clean
make -j5
sudo make install
Best regards,
Marcus
On 29.03.21 19:06, Abraham Diaz de Leon Camou wrote:
>
Yes, just hackRF One plugged into the RPI...
===
Sent from my mind, some fingers and electronics helped.
Il giorno 13 feb 2021, 23:13, alle ore 23:13, Fabian Schwartau
ha scritto:
>You are welcome :)
>I can't actually explain why it is working with the hackrf argument. If
>you have only one
You are welcome :)
I can't actually explain why it is working with the hackrf argument. If you
have only one sdr connected, it should work without it.
Anyway, I'm glad it works now.
Am 13. Februar 2021 22:54:32 MEZ schrieb Stefano Zorzanello
:
>please apologize, I didn't realize to have replied
please apologize, I didn't realize to have replied just to you.
about hackrf recognition, this is the terminal report:
- - - -
$ hackrf_info
Found HackRF board 0:
USB descriptor string: 088869dc3326571b
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1
Part ID Number:
Hi Stefano,
we should stay on the mailing list, so everyone can follow and contribute.
Are you sure there are not other messages? Because those below are no
error messages, just a warning and a bit of information, nothing to
really worry about.
One common problem (which I did not have) is missing
Hi Stefano,
don't worry asking such questions here on the list. That's its purpose I
guess ;)
First of all: I was able to run both of your flowgraphs on my PC with a
HackRF One, so the problem lies somewhere else.
A small google search reavealed no perfect solution, but it indicated
that
On 1/13/21 3:09 PM, Fabian Schwartau wrote:
If you can reproduce a failing wired keyboard, check what
/var/log/syslog says when it turns off. Use
tail -f /var/log/syslog
to monitor the output continously. There should be some note on what is
going on. A look in the xorg/wayland logs may also
If you can reproduce a failing wired keyboard, check what
/var/log/syslog says when it turns off. Use
tail -f /var/log/syslog
to monitor the output continously. There should be some note on what is
going on. A look in the xorg/wayland logs may also help.
Am 13.01.21 um 20:03 schrieb Barry Duggan:
See if it's this: https://hamwaves.com/usb.autosuspend/en/
On Wed, Jan 13, 2021 at 2:12 PM Barry Duggan wrote:
> I know this is not a GNU Radio problem directly, but I hope maybe
> someone has some insight into this.
>
> I have a Lenovo ThinkCentre M75s with a AMD® Ryzen 7 PRO 3700 Processor.
>
Hi Edward - I know next to nothing about Windows - but if you're setting
the device options for the hackrf as rtl="some an integer" I would be
really surprised if that works .
At some point in the distance past, you could set it device number to
"0" if you there was only one device - I don't
Hi Ray,
Thank you for your response! I've been retired for 18 years, but I've
been busier since I've been working with GNU Radio than I was before.
I look forward to your participation (and learning what a GOLF-Tee is ;).
73,
Barry Duggan KV4FV
https://github.com/duggabe
On 11/28/20 5:10
Hi Michael,
Thank you for your response! Are you currently using GNU Radio in your
ham operations? Is there a topic you would like to present?
I look forward to hearing from you.
73,
Barry Duggan KV4FV
https://github.com/duggabe
P.S. Please CC: discuss-gnuradio@gnu.org in your response (or
Hi Akinyele,
GNU Radio companion has an "screen capture" function that allows you to
directly save **good** images of your flow graph. Also, your operating
system has the same. So, I'll respectfully point out that taking photos
with a camera is a complicated and not overly useful method to
Hello EJ Kreinar,
Thank you for your reply. I am planning to use theseus.On a side
note I was seeing your talk on GRCon 18 when I was writing this email :)
Great talk by the way !!
As a first step I am trying to make a working POC, so if no. of channels
are restricted to powers of 2, I
Hi Mohamed,
I'll see if I can field a few of your questions...
3. I am currently pseudo-maintaining theseus-cores repo:
gitlab.com/theseus-cores/theseus-cores By that I mean Im not currently
actively developing anything for it (my spare time available to work on
open source fpga has decreased),
gt;
>
> [1] https://forums.gentoo.org/viewtopic-t-1098804-start-0.html
>
>
>
>
>
> Pierre
>
>
>
>
> >
> > De : Sebastian Müller
> >
> > À : discuss-gnuradio@gnu.org
> >
> > Sujet : R
Hello Pierre,
you already got everything right:
- gr-inspector for GNU Radio 3.7 requires Qt4
- gr-inspector for GNU Radio 3.8 requires Qt5
So there should be no problem in using Qt4 for your case. In particular,
gr-qtgui for GNU Radio 3.7 is using Qt4, not Qt5 [1].
Hello Vincenzo,
Thank you for the really detailed description of what you've done. The
original author of gr-gpredict-doppler stopped working on it five years
ago and so it is incompatible with recent versions of GNU Radio.
Happily another community member has updated it themselves. Delete
st a Unix security policy thing.
>
> Regards,
> Kyeong Su Shin
> --
> *보낸 사람:* Ahmet DEMIR 대신 Discuss-gnuradio
>
> *보낸 날짜:* 2020년 3월 6일 금요일 오후 4:45
> *받는 사람:* Müller, Marcus (CEL)
> *참조:* discuss-gnuradio@gnu.org
> *제목:* Re: Help
오후 4:45
받는 사람: Müller, Marcus (CEL)
참조: discuss-gnuradio@gnu.org
제목: Re: Help with uhd_packet_tx
Thank you for the answer but gnuradio does not let me save the generated file
in the same folder when I click Run/Generate. Error is:
Error: Cannot save: /usr/share/gnuradio/examples/blocks
Thank you for the answer but gnuradio does not let me save the generated
file in the same folder when I click Run/Generate. Error is:
Error: Cannot save: /usr/share/gnuradio/examples/blocks/packet_tx.grc
Müller, Marcus (CEL) , 5 Mar 2020 Per, 15:02 tarihinde
şunu yazdı:
> You'll need to open the
You'll need to open the packet_tx example from the same folder, and hit
"generate" on that, and then reload the block library.
On Thu, 2020-03-05 at 13:56 +0300, Ahmet DEMIR wrote:
> Thanks a lot for the help. I am using linux ubuntu 18.04 operating system.
> When I want to use the
Hi Andrew,
Shameless plug, but you can take a look at this repo
https://gitlab.com/phorvath/smogcli2 to record samples with RTL-SDR
and Raspberry PI. It is developed for the ATL-1 and SMOG-P satellites.
It is a standalone application, samples at 1.6 or 2.0 maps, tracks the
location of the
Hi Andrew,
I would encourage you to try using GNU Radio first on your host machine in
order to become familiar with it's operation. Then once you have an
understanding of it, you can easily deploy your application/flowgraph to a
headless device like a raspberry pi.
I'd suggest starting by going
Hi Andy,
You'll probably want to use gr-satellites instead of direwolf.
https://github.com/daniestevez/gr-satellites
You can record a pass using GNU Radio using a File Sink.
Regards,
Nate Temple
On Sat, Feb 15, 2020 at 6:01 PM Andrew Stamp wrote:
> Hi,
>
> I’m looking for assistance with
Hi Jean Marie - 2 thoughts:
1) Did you run "sudo ldconfig" after installation? Always a good idea to do
that after installing anything, to update to LD cache.
2) If you run
{{{
/usr/bin/python2 -c "import sys; print(sys.path)"
}}}
is one of the paths "/usr/local/lib/python2.7/dist-packages"? If
On Tue, Feb 11, 2020 at 11:15 AM "Till Hülder" wrote:
>
> Hello,
>
> i want to implement a FMCW-Radar in a frequency-chirp. First i tested the
> frequency-chirp . I send the chirp from TX to RX of my USRP.
> I get this warning :
>
> UHD Warning:
> For this connection, UHD recommends a
Juan,
Thanks a lot for your response. I tried stopping at the ifconfig stage and
wait for both PCs to be ready before hitting enter. But all I saw was TX and
no RX. Do you have any idea where the problem might be?
Tuan
On Wed, Jul 7, 2010 at 7:10 PM, Juan Quiroz asd...@yahoo.com wrote:
I have
Hi,
I have successfully run digital folders tunnel.py.
However, I am not receiving anything when i run the ofdm folder tunnel.py.
Whereas the benchmark_ofdm_tx+rx.py is running perfectly.
I have varied almost all the available parameters but to no avail.
Please help me out.
Thanks in advance.
a lot,
Tuan
On Thu, Jul 8, 2010 at 10:55 AM, chuck lorres chucklor...@hotmail.comwrote:
I am using RFX 2400, gnuradio 3.2.2, ubuntu 9.10 and 9.04 on another
--
Date: Thu, 8 Jul 2010 10:48:24 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
was observed. 0 packets were dropped.
--
Date: Thu, 8 Jul 2010 11:09:30 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com
To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
That's pretty much the same settings
is being sensed.In digital
folders tunnel.py is running perfectly.Thanks.
Date: Thu, 8 Jul 2010 13:07:04 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com
To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
I finally found a setting that actually works. So
.
Thanks.
--
Date: Thu, 8 Jul 2010 13:07:04 -0400
Subject: Re: [Discuss-gnuradio] Re: Help required tunnel.py
From: ta.tu...@gmail.com
To: chucklor...@hotmail.com; discuss-gnuradio@gnu.org
I finally found a setting that actually works. So the real problem I think
lies
I have installed deb package of GNU radio 3.2.2 for Ubuntu 9.04 and works fine,
with openSUSE 11.1 I try tarball and everything is OK, for openSUSE there's a
rpm package of GNU radio 3.1.3 avalaible in http://software.opensuse.org/search
it's ok too.
Try doing this step by step
Run tunnel.py,
I did the same question a few weeks ago! You should change carrier threshold to
a higher value, default is 30 db, I changed to 50 db to get a clear connection,
I'm working with openSUSE 11.1 and I'm root user transmitting in first wifi
channel, so I write in console:
user# python tunnel.py -f
On a fresh openSUSE 11.2, if have installed gnuradio a few days ago.
After the installation, rpm -qa --last gave me
python-Cheetah-2.4.0-1.3 So 21 Mär 2010 23:41:46 CET
python-lxml-2.2.2-2.1 So 21 Mär 2010 23:38:17 CET
python-wxGTK-2.8.10.1-2.pm.3.1
On Fri, Mar 19, 2010 at 8:15 AM, Andrew Rich vk4...@tech-software.net wrote:
Thanks Alex
I forgot about that page, talk about doing things the long way around !
I installed and got:-
*
The following GNU Radio components
Sorted
gnuradio install - openSUSE 11.1 Linux version 2.6.27.7-9-pae
1) gcc - YAST
2) python and python devel - YAST
3) SWIG - YAST
4) FFTW3F -devel YAST
5) libccpunit - YAST
+ installed gcc43-c++ (missing g++ error) (YAST)
+ Downloaded and installed boost_1_42_0 .tar.gz
Andrew,
It seems you are still missing a lot of dependencies, you can see a
list here: http://gnuradio.org/redmine/wiki/gnuradio/SuseInstall
On desktop linux distributions you should be able to have everything
enabled except
gcell
gr-gcell
gr-audio-osx
gr-audio-windows
gr-comedi
and possibly
.
- Original Message -
From: Alexandru Csete oz9...@googlemail.com
To: gnuradio discuss-gnuradio@gnu.org
Sent: Friday, March 19, 2010 9:14 PM
Subject: Re: [Discuss-gnuradio] Re: Help please - install openSUSE 11.1
gnuradio
Andrew,
It seems you are still missing a lot
Information for openSUSE 11.1 on GNUradio web page works fine, take care with
versions of packages that you can find in YAST because versions are not allways
most recent, you can find rpm packages to solve dependencies in
http://software.opensuse.org/search just select opensuse 11.1 and one
thanks it worked
_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/___
Discuss-gnuradio mailing
hi,
thanks for your reply Mr Timothy.
I proceeded with preceding steps and i installed gnuradio successfully however,
now im facing two more problems :
1) when i typre grc in terminal a error window pops up saying Cannot import
gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set correctly?
sometimes it helps to run the magic incantation:
sudo ldconfig
-Josh
On 03/07/2010 10:07 AM, sanam singh wrote:
hi,
thanks for your reply Mr Timothy.
I proceeded with preceding steps and i installed gnuradio successfully however,
now im facing two more problems :
1) when i typre grc in
On Sun, Mar 07, 2010 at 10:38:32AM -0800, Josh Blum wrote:
sometimes it helps to run the magic incantation:
sudo ldconfig
-Josh
And have you set your PYTHONPATH?
$ export PYTHONPATH=/usr/local/lib/python2.6/dist-packages
Eric
On 03/07/2010 10:07 AM, sanam singh wrote:
hi,
...@hotmail.com
CC: discuss-gnuradio@gnu.org
Subject: Re: Help req: Simulataneous transmission
On Mon, Jan 04, 2010 at 06:06:51AM +, nadia raj wrote:
Hi,
Thank you Mr.Eric for your valuable advice.
You're welcome.
Yes i studied and completely understood the example that you referred
On Mon, Jan 04, 2010 at 06:06:51AM +, nadia raj wrote:
Hi,
Thank you Mr.Eric for your valuable advice.
You're welcome.
Yes i studied and completely understood the example that you referred.
I have ,with your advice solved the problem of spatial demux.
Now i want to ask you that
Markus Feldmann feldmann_markus at gmx.de writes:
Therefore i have some questions:
To 2.) What allowed values for Look Ahead ?
And what does this mean ? Which unit ?
What is Alpha, and which are allowed values ?
If the peak detector gets a peak, what does it spit
-
From: Markus Feldmann [mailto:feldmann_mar...@gmx.de]
Sent: Monday, March 23, 2009 11:43 AM
To: gnu radio mailing list
Subject: [Discuss-gnuradio] Re: help on xlating frequency
Paul Mathews schrieb:
See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to
these lines in particular
Paul Mathews schrieb:
See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to these
lines in particular:
if self.use_IF:
# Turn If to baseband and filter.
self.chan_filt = gr.freq_xlating_fir_filter_ccf (chanfilt_decim,
chan_filt_coeffs, self.IF_freq,
Paul Mathews schrieb:
See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to these
lines in particular:
if self.use_IF:
# Turn If to baseband and filter.
self.chan_filt = gr.freq_xlating_fir_filter_ccf (chanfilt_decim,
chan_filt_coeffs, self.IF_freq,
Hi all,
Is it possible to do a reset at USRP?
Thanks,
Jose
2009/2/3 José Carlos Reyes jcreyesguerr...@gmail.com
Hi all,
As I posted before, after installing Gnu Radio (3.1.3 tarball) I tested my
USRP and Dbsrx daughterboard when usrp_fft.py and I could see gsm spectrum
without problems.
Joreen Tan wrote am 2008-10-28 18:36:
Joreen Tan wrote am 2008-10-28 08:04:
The error reported is as shown:
Traceback (most recent call last):
File usrp_fft.oy, line 24, in module
from gnuradio import usrp
ImportError: cannot import name usrp
Need more Info:
Did you compile by yourself or
Dear jorren
check your python path
your python can not found the module.
In my memory, you can find some discussion here (same error message)
Joreen Tan wrote:
...
The error reported is as shown:
Traceback (most recent call last):
File usrp_fft.oy, line 24, in module
from gnuradio import
Hi,
my python path is correct but i can't find any past discussions regarding the
same error message on google. May i check where can i find the past discussions?
Date: Tue, 28 Oct 2008 12:13:32 +0100 From: [EMAIL PROTECTED] To:
discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Re
-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Re: Help!
ImportError: cannot import name usrp Hi, This may be one of the more
stupid things I've said here (or any were else), but shouldn't it be
usrp_fft.py, and not usrp_fft.oy? It seems like an easy typo to make,
and when i do
Joreen Tan wrote am 2008-10-28 08:04:
Hi,
Just started on this project again and faced with this problem with the
gnuradio-3.1.3 version using fedora 9. The error message occured when i
was running gr-utils/src/python/usrp_fft.py
I am logging in as root.
The error reported is as
Anthony, you need to download and install Pyephem. You can get it here:
http://rhodesmill.org/pyephem/
Sorry, I am not familiar with Ubuntu, so I can't help with installing
it. But others on this list can help with that.
Dave
Message: 1
Date: Fri, 30 Nov 2007 17:40:55 + (UTC)
From:
Harold D. Skank wrote:
People,
I mis-stated my problem in my earlier posting. It's not the receive
message closing that I need to modify, but the transmit message closing.
Otherwise the posting was correct.
What do you mean by message closing?
Matt
People,
I mis-stated my problem in my earlier posting. It's not the receive
message closing that I need to modify, but the transmit message closing.
Otherwise the posting was correct.
Harold
On Sat, 2007-01-13 at 16:37 -0600, Harold D. Skank wrote:
People
A newbie here. I need to
--
Message: 3
Date: Thu, 16 Nov 2006 12:44:48 -0800
From: Eric Blossom [EMAIL PROTECTED]
Subject: Re: [Discuss-gnuradio] Help with Verilog: write_count[8]
To: seph 004 [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type:
On Fri, Nov 17, 2006 at 01:02:31AM -0800, seph 004 wrote:
Hi
Thanks for responding. So WR ~write_count[8] should be able to
serve as a write enable for a ram block?
Also, while testing with one of the unmodified FPGA builds, I found
that the have_space control line would sometimes go to
From: "Oussama Sekkat" [EMAIL PROTECTED]Subject: Re: [Discuss-gnuradio] Help with VerilogTo: "seph 004" [EMAIL PROTECTED]Cc: discuss-gnuradio@gnu.orgMessage-ID:[EMAIL PROTECTED]Content-Type: text/plain; charset="iso-8859-1"Hi Lance,On 11/7/06, seph 004 [EMAIL PROTECTED] wrote: Hi I've been bashing
Jim Borynec wrote:
Try using a meter long wire.
That seems to have fixed the problem; I took the two antennas and linked
them end-to-end and all of a sudden the scope reflects a change with and
without the antennas connected. Thanks so much!
What kind of wire is best? Are we talking just a
Anyway, installation, make check, and the ./test_standard_?x scripts
work fine (the LED behaves as expected and the benchmarks seem
reasonable), however I get nothing when running the usrp_oscope or
usrp_wfm_rcv scripts as directed in the instructions. Both dial tone
scripts work fine, by
1 - 100 of 101 matches
Mail list logo
