Wow thanks. That's awesome. I think the 10 Bd Russian XPA signal stole some
riffs from Dream Theater.
http://www.sigidwiki.com/wiki/CIS_20-MFSK_XPA
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Sigidwiki-tp56045p56065.html
Sent from the GnuRadio mailing list archive
Could this be modified to, optionally, do the (complex) average after the
FFT. That would give a coherent average assuming no samples are dropped
prior to FFT. Nice for digging signals out of the noise compared to a
normal spectrum analyzer type average.
Lou
Marcus Müller-3 wrote
> Because I
Hmm.. maybe it is. I have done it in (shudder) LabView and it's nice since
noise reduces at 1/N instead of 1/sqrt(N); N is number of averages. Maybe
I'll try it tonight with just discrete blocks to compare them side by side.
Just something that can't be done with a normal spectrum analyzer.
Tha
The baudline sink is in gr-baz last time I used it:
https://github.com/balint256/gr-baz
Alternately, you can create a FIFO, point the GR file sink to it, then have
baudline read from it. I have some notes here:
https://rfpoweramp.wordpress.com/2014/04/20/baudline-tips/
Lou
Rebecca wrote
>
I'm running an N210 + LF TX/RX to 25W on HF, but also using separate RX and
TX antennas with adequate isolation ( https://www.qrz.com/db/KD4HSO ). The
LF-TX is direct sampling so you don't have the issue of LO leakage when you
are not transmitting (i.e. zeros into sink). With the I/Q conversion
d
I did something similar here:
https://github.com/madengr/ham2mon/blob/master/apps/estimate.py
It estimates the channel centers above a threshold and returns the indices
into the FFT.
Lou
Edward wrote
> Hello all,
> Is there any suggestion how to capture or save only several peaks
> &
You are not in the same boat, by far. I'm an EE RF/MW hardware guy with zero
formal software training (other than a FORTRAN undergrad course requirement;
if that hints to my age). SDR is a rather new field that requires a LOT of
cross discipline; it's software + radio. I have been messing with
Yes, pretty much. With the DFT (and the continuous one) you are correlating
the input waveform with harmonically related, complex sinusoids; essentially
for each harmonic you mix it down to DC then sum (integrate). The FFT is
different (I actually don't know how it works, other than it operates o
If you can synthesize the LO for the upconverter using the RTL XO as a
reference, the drift may tend to cancel. I say "may" as this is a trick
used in dual or triple down conversion chains. If you can alternate between
low and high sided IFs, then the drifts will move in the opposite directions
(
I see a link here:
http://gnuradio.org/grcon-2016/
Is registration open? It says it starts today 3/30/16, but no link.
Thanks,
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/GRCon16-links-tp59207.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
What would it take to get phase coherency, say at 1 GHz, on a global scale;
short of running cables? I assume with a moderate priced GPSDO one can get
10E-12 stability, so that would be 0.01 Hz frequency stability at 1 GHz.
Does that mean you can integrate for 10 seconds and stay within 0.1 radia
Dan,
This is HF, but similar concept of a low cost receiver, with integrated GPS,
tacked onto a single board computer.
https://www.kickstarter.com/projects/1575992013/kiwisdr-beaglebone-software-defined-radio-sdr-with
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/radi
Active loop >> LFRX>> N210 >> LFTX >> 20W PA >> SG-230 tuner >> inverted L.
Pics here:
https://www.qrz.com/lookup
I don't have any GR code for a full transceiver, more experimental, either
always RX or TX. I believe John Petrich has been working on a full
transceiver in GRC.
Lou
KD4HSO
Dani
I have a drive test app here which polls the B200 GPS every second while
running the GR flow:
https://github.com/madengr/drive_test/blob/master/apps/drive.py
Lou
Jason Matusiak wrote
> I have a python script I built up for GR that runs on my E310. As part
> of the startup, it checks
Try this:
https://www.dropbox.com/s/7xsg4arx5h3gvah/spectrum.grc?dl=0
The integrate with decimation is what you want. Starting at 32 ksps with a
1024 length FFT length yields 31.25 vector/sec. Then an integrate with
decimation by 32 averages down to 0.98 vector/sec.
However when I try reading
Yes, but I have a throttle after that file source, so it should be updating
about 1 vector/second (each vector is 1024 samples). It's happening about
1/8 that speed, so something does not seem quite right.
Lou
Marcus D. Leech wrote
> Files don't have any inherent sample-rate. Regardless of what
But the throttle should roughly slow it down to a real-time rate. The top
half of my grc file updates about 1 spectrum/second via a throttle, and
writes those vectors to disk. If I read back the the file also through a
throttle, it should have about the same rate, but it's much slower. Note to
d
If you are working off a file source, then you should be able to use the
"head" block to limit the number of samples read from the file. For
example, if you want to average 32 spectrums of length 1024, then you need
32*1024 samples in the "head".
Sorry, no idea how to change the default time plot
So if I swap positions of the "throttle" and "vector to stream", and setting
throttle for rate of 30 and 1024 items, then it works fine. It seems the
throttle has to be immediately after the file source, otherwise it gets
fouled up.
Lou
madengr wrote
> Try this:
>
&
Never mind, ignore that. Still seems to be working strangely.
madengr wrote
> So if I swap positions of the "throttle" and "vector to stream", and
> setting throttle for rate of 30 and 1024 items, then it works fine. It
> seems the throttle has to be imme
Yes, specifically copy uhd/host/examples/init_usrp/CMakeLists.txt over to
your build directory, then replace "init_ursp" with "gpio". Then just:
cmake .
make
Marcus D. Leech wrote
> The best thing to do is to use the existing UHD build infrastructure to
> compile UHD examples.
>
> Modify, th
Posting this to GR (as opposed to USRP) since it seems more theory.
Say I have an X300 and want to get DC - 200 MHz BW from a single daughter
card by combining two real sampled streams. The X300 ADCs (or within the
dual channel ADCs themselves) clocks can't be interleaved.
An argument is that on
In the spirit of voiding the warranty, physically invert the LVDS clock input
and output traces at the ADS62P48 with haywire and x-acto knife; the FPGA
may then not know the difference. Use it as sub-device A:AB at the full 200
Msps, then interleave the complex parts into a real stream once in GR.
You can dynamically change the name of the file sink while the flowgraph is
running. For example, you would change it from "/dev/null" to
"~/my_data.bin". You would start the flow, then in python loop, wait so
many ms, poll the time, then change the file sink name.
Lou
Ernest wrote
> Hi All,
How are you generating the bursts at baseband? I fill a vector source with
(1+1j)*(numpy.ones() + numpy.zeros()) at the appropriate length for the
sample rate, then let that repeat. I'm getting nice, clean rising edges on
my pulses (run into an oscilloscope). Maybe the first pulse is distorted,
If you built it from source, then "sudo make uninstall" from the "build"
directory.
Lou
John B. Wood wrote
> Hello, everyone. Short of starting with a fresh Fedora or Ubuntu OS
> build what's the quickest way to remove an older Gnuradio build prior to
> installing a later version?
--
Vi
k1gto wrote
> Is there any way to access the fft bins from python without writing a
> custom block?
See this:
http://ha5kfu.sch.bme.hu/fft_test
Lou
KD4HSO
--
View this message in context:
http://gnuradio.4.n7.nabble.com/help-accessing-fft-bins-in-python-script-tp50854p50891.html
Sent from th
If you want to do it the hard way, i.e. installing the dependencies from
scratch and building from source, I keep an updated list here; ignore the
date:
http://rfpoweramp.wordpress.com/category/sdr/gnu-radio/
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Installing-GNU-Radi
Raydel Abreu (CM2ESP) wrote
> However I would like to know how can I demodulate a PSK transmission which
> is carried over a typical FM signal.
IIRC you would just do the WBFM demod, then the PSK demod. See the gr-rds:
https://github.com/bastibl/gr-rds
Lou
--
View this message in context:
h
I'm using the freq message output of the QT GUI Frequency Sink to drive the
freq message input of the Frequency Translating FIR Filter. Since I have
set the the Center Frequency of the QT Frequency Sink to 7E6 Hz, that means
I need to subtract that value before I send it to the channelizer so it o
Try a CTRL-F and search for "note" block. I think it's under the misc folder
also. It only lets you do one line.
Lou
Richard Bell wrote
> Hi all,
>
> I would like to know if there is any way to add textboxes to a GRCs
> flowgraph for notes and documentation?
>
> Thanks,
> Rich
--
View t
See my note about dynamic recording of file names:
http://rfpoweramp.wordpress.com/category/sdr/gnu-radio/
The file sink is either being directed to "filename" or "/dev/null". You
can dynamically change that during the flow with a boolean check box. In
your case, instead of the check box, you wo
Here is the file:
https://dl.dropboxusercontent.com/u/49570443/fmt.grc
Lou
madengr wrote
> I'll post an example GRC file tonight that shows the dynamic recording
> with time stamped file. I'm going to try the ARRL Frequency Measurement
> test tonight, and wrote a
y and sampling
offsets next time.
http://youtu.be/_brT8AElZi0
https://github.com/madengr/fmt
Thanks,
Lou
KD4HSO
--
View this message in context:
http://gnuradio.4.n7.nabble.com/ARRL-FMT-with-GNU-Radio-tp51330.html
Sent from the GnuRadio mailing list archive at Nabbl
If you are using an "if" statement to switch between filename and /dev/null,
try putting the filename construction in the "if" statement, instead of a
separate variable. That may make it evaluate every time the "if" statement
is called.
My example used the LO frequency as part of the filename, an
Might want to post this over on the Ettus list, as I am having issue with the
X310 and LFRX and have a few threads on there with examples of diagnosing
it. The DC compensation seems to be always on (bad since the LRFX is DC
coupled), and the digital gain setting seems broke. These may be related
I assume m.data is a list of FFT magnitude-squared data; it can't be complex
otherwise math.log10() won't work. It must be magnitude-squared since it is
using 10*math.log10(), otherwise it needs to be 20*math.log10().
It finds the minimum out of all the bins and calls that the noise floor.
For e
Marcus,
OK; dumb question. How do I apply that, other an editing the source
manually? I tried the following, but it didn't like it:
cd /usr/local/src/gnuradio/
patch < 0001-qtgui-fixed-non-changing-from-sec-to-ms.patch
Thanks,
Lou
Marcus Müller wrote
> -BEGIN PGP SIGNED MESSAGE-
> Ha
Run volk_profile then rerun the tests.
Lou
Cocacola93 wrote
> On Ubuntu 14.04LTS 32bit, I tried installing using gnuradio-3.7.5
> The build completed, but several of the build tests fail
> 98 % tests passed,4 test failed out of 193
>
> The following tests FAILED:
> 1 - qa_volk_test_all
I assume this is your first install and VOLK has not been profiled already,
in which case you need to do a:
sudo make install
sudo ldconfig
volk_profile
make test
Cocacola93 wrote
> openbts@nujmee:~/gnuradio/build$ Run volk_profile
> Run: command not found
--
View this message in context:
No, do not type:
Run volk_profile
Type this:
volk_profile
Try my other suggestion if the above does not work. My guess is the VOLK
tests won't work since this is your first time installing gnuradio, and you
have not run the volk_profile. In which case you need to bootstrap by
installing it first
Sorry, the boostrapping was a guess on my part, as I recall having a similar
issue a while back and seeing this:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-07/msg00486.html
Lou
West, Nathan wrote
> On Tue, Nov 25, 2014 at 10:50 AM, West, Nathan
> <
> natw@.okstate
> > wrote:
>
>
Just a thought; when you stop your flow graph, are you using the big red X
button in the GRC menu bar (the improper method), or closing the WXGUI sink
window (the proper method)? I was doing it the wrong way for quite some
time and that caused issues with hardware access.
Lou
Thomas Early wro
Huh, good question, I just use CTRL-C for GR programs launched from the
terminal, and had no issues with hardware. If you set the GRC option block
to NO GUI, I don't recall if it even runs the flow; it may just generate the
top_block.py and you must manually launch from the terminal.
In general,
Can you do that for Ettus RFnoc? I noticed that has no category either.
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-display-category-none-tp51628p51635.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
I'm experimenting with very fine frequency measurements (i.e. uHz resolution)
at high sample rates. For instance, down-converting all the WWV signals
from a 100 Msps chunk of HF spectrum to near 0 Hz then comparing their
drift.
I have a handle on the DDC within the USRP and the sig_source_c withi
Do you mean adding a text label on the vertical axis, or scaling the
spectrum? For the latter, you would have to feed the USRP a known
(calibrated) noise source that is well above the USRP noise floor such as an
HP 346 noise source. Then read the value from the spectrum and just
re-scale the samp
Equivalent function here, which could be encapsulated into a GR block if you
don't need speed:
http://docs.scipy.org/doc/scipy-dev/reference/generated/scipy.signal.periodogram.html
I suppose it boils down to the difference between an FFT just normalized to
bandwidth, and the FFT of the autocorrel
level
every second and logs it with GPS data:
https://github.com/madengr/drive_test
Lou
Ali Riaz wrote
> Hello everyone,
>
> So I was trying to capture continuous IQ data from my USRP N200, and this
> needs to be done for about a week, but because the amount of data is
> gi
I saw from your other thread that you were channelizing and decimating, and I
assume you are logging this to disk for extended periods. I'm doing a
similar thing here:
https://github.com/madengr/nbfm_rec
Although I'm not using a channelizer, only because there is no band plan for
Can you you add the --recursive in the README?
I assume a standard "git pull" will be sufficient in the future or do we
also need to do a "git submodule update"?
Thanks,
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Empty-volk-directory-when-I-git-gnuradio-tp53073p531
Actually now I see it would probably be:
git pull --recurse-submodules=on
git submodule update
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Empty-volk-directory-when-I-git-gnuradio-tp53073p53155.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_
If I'm using a block that has a message port output, is there a way to put
those messages into a message queue? For instance:
self.message_queue = gr.msg_queue()
self.msg_connect((self.gsm_control_channels_decoder, 'msgs'),
(message_queue, 0))
I have used gr.msg_queue() with blocks.messa
Thanks Martin. Looking at the gr-blocks/examples/msg_passing, the tutorial
link, and qa_msg, I only find examples of posting messages. Those make
sense, but is there an equivalent to _post method that pulls messages?
http://gnuradio.org/doc/doxygen/classgr_1_1basic__block.html#a8501714cb14c1a08b4
Martin,
Yes, pop them outside the block, but also outside of the flow graph.
Exactly reverse of the last example "Posting from External Sources" here:
http://gnuradio.org/doc/doxygen/page_msg_passing.html
"The last feature of the message passing architecture to discuss here is how
it can be use
Tomaz,
Looks like you are measuring power on the spectrum analyzer with bandwidth
integration, and it's giving you -95 dBm in both cases, which is good if
it;s doing teh math, but what happens when you put the analyzer in linear
mode? Or leave it in log mode, open up the RBW >> 100 kHz and put it
Now that's disturbing that the analyzer is giving a false readings over
integrated BW measurements, even when it claims it's in RMS mode, although
that's maybe opposed to peak detector mode. It's still probably defaulting
to a LOG detector, and you can measure multi-tone signals, but each tone
mus
Similar issues here. On Fedora, you can use reposync to mirror a repository
to disc, transfer to DVD, then you can point yum to that when
installing/updating packages on your gapped machine. I believe you can do
something similar for a git repository, burn to DVD, then point it your DVD
when clon
Martin,
Thanks for this. While your at itcould you add a field in GRC UHD
source block to enable/disable the DC RX offset correction, as well as a
message to control it?
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a7beb49c1a04a81b3e7569db482453746
It actually works in
You probably shouldn't put code into /usr/local/bin as that is reserved for
binaries, and you shouldn't build as root. I clone stuff into
/usr/local/src, so do this:
sudo mkdir /usr/local/src
sudo chmod 777 /usr/local/src
cd /usr/local/src
git clone –recursive https://github.com/gnuradio/gnuradi
FWIW I keep on-line notes here if you want to do everything the hard way
(i.e. manually install dependencies and build from source):
https://rfpoweramp.wordpress.com/category/sdr/gnu-radio/
Lou
Richard Bell wrote
> Hi all,
>
> ...
>
> What is causing this problem?
>
> v/r,
> Rich
>
>
This scans the B200 through GSM channels, compares to a calibrated threshold,
and logs if it exceeds the threshold. You would just populate the Python
list with your frequencies and iterate through them. Note this uses the old
message queues, which as been deprecated, and I have not figured out a
Well googling that error points to something with the B200. I ran it last
night with latest UHD/GR and it runs fine. Python has no issues with 1000
length list of floats.
Lou
Ashraf Younis wrote
> Amazing, this seems to do what I needed. Thank you. It seems my list is
> too
> big because I get
Is there an optimum hardware decimation to maximize receiver dynamic range?
For example, if I have an X310 at 200 Msps with 14 bit ADC receiving a low
frequency tone (LFRX board), those samples are truncated to 16 bits prior to
Ethernet. If I'm decimating by 800 (from 200 Msps to 250 ksps) in the
Throught I'd share my GR based scanner with curses GUI. Locks on and
demodulates N number of NBFM channels and logs audio to disk. Uses
gr-osmosdr source so should work with a variety of devices.
https://github.com/madengr/ham2mon
https://www.youtube.com/watch?v=BXptQFSV8E4
--
View
Anybody know what happended to http://op25.osmocom.org/ ? It's down and so
is the repository at git://op25.osmocom.org/op25.git Looks to have been
down for at least 3 weeks. Is there a backup of the repository somewhere?
Thanks,
Lou
--
View this message in context:
http://gnuradio.4.n7.nab
1) Send in a CW tone from a signal generator of known power (dBm)
2) Read the level from GR FFT (dB)
3) Figure out the amount you need to offset (dB)
4) Multiply your samples by a constant value of 10**(offset_dB/20.0)
5) The GR FFT will now be calibrated to an absolute power (dBm).
Note if you c
I misread you question and thought you were receiving with the USRP. Same
procedure, just don't let the transmitted signal go past +/- 1.0 or you will
clip the DAC. In practice keep it backed off 6 dB or more to allow for
crest factor.
Lou
madengr wrote
> 1) Send in a CW tone from
in
noise marker mode. Just use a CW tone.
Lou
Jan wrote
> Actually, you were right at first madengr. My transmitter is USRP1 with
> WBX
> 50-2200 while my receiver is USRP N200 with TVRX2 and spectrum analyzer.
> Can you give me suggestions on how I can match the amplitude
Is the UHD GPIO API available in Python yet?
Lou
Martin Braun-2 wrote
> On 05.08.2015 10:32,
> mleech@
> wrote:
>> The B2xx GPIO J504 GPIO has the same API as X3xx.
>
> ...and the example is also the same (gpio.cpp).
>
> Cheers,
> Martin
--
View this message in context:
http://gnura
Added AM demodulation for VHF air-band reception, via “-d 0” option switch
for NBFM (default) and “-d 1“ for AM. OP25 via gr-dsd next on agenda; maybe
at hackfest.
https://github.com/madengr/ham2mon
Lou
--
View this message in context:
http://gnuradio.4.n7.nabble.com/HAM2MON-update-tp55492
1531 MHz signals from what? If you are using a patch antenna then it
probably won't have the bandwidth to cover 100 MHz.
Lou
KD4HSO
Cheng Chi wrote
> - Iridium antenna (I am not able to get specific antennas for
> Inmarsat...Iridium is at 1616 -1626.5 MHz and Inmarsat is at 1525-1559
> MHz.
> I
Try taking out the throttle. That's only needed to limit the CPU when there
is no hardware dictating the sample rate.
Lou
KD4HSO
embob wrote
> Ive got an USRP B100 which Im trying to get transmitting as a first step.
> Ive built the latest GNU Radio from source (using the buildgnuradio script
>
Martin Braun-2 wrote
> Generally: Don't use a message queue. Also, I recommend not adding any
> WX widgets, unless you hate QT, because we're trying to move away from
> them.
>
> The message passing interface might be a better choice, but the idea in
> general is very good.
>
> Martin
Is there a
Jonathan Fox wrote
> Hey List,
>
> I have two scripts I am running, the ofdm_v1_tx_freq_test.py and the RX
> version of it (see flow graph images and attached transmitter Python
> script). I am transmitting a sinusoid using OFDM modulation over the USRP,
> it works perfectly.
>
> I have made an a
The Syba SD-PEX20122 works well too. No issues streaming 46 Msps into GR QT
spectrum or uhd_benchmark. I get over-runs past that, but I'm not sure if
that's the B200, USB card, or CPU trying to keep up. Stay away from the
Renesas controller though, that's what on my motherboard and it's a hunk o
mkfifo my_fifo.bin
hexdump my_fifo.bin
Point your file sink to the my_fifo.bin and turn off the buffering. It will
then dump the data to the terminal in real time.
Lou
KD4HSO
Jay Radcliffe wrote
> I have a question about handling data after binary slicing in the
> demodulation portion of hand
I guess I'm confused then. I'm using the hex FIFO dump as I described to
examine AX.25 packets one bit at a time. Since the output of the slicer is
a byte whose LSB is the only thing you are interested in, I believe you can
use the unpacked-to-packed block to strip off the LSB from 8 bytes and pa
jimsiaf91 wrote
> Hi list, Has anyone been able to implement a frequency counter yet?
> Any ideas on how I should try it?
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@
> https://lists.gnu.org/mailman/li
How about the PFB synthesizer detailed by TR? I'd think all the dongles
would have to be phase locked and references tones (or comb) used to
calibrate the channels. If your signals are not crossing channels then
maybe you could get away without that.
http://www.trondeau.com/examples/2014/1/23/p
Regarding the low sample rate, I have had this issue too when decimating to
narrow bandwidths. I assume sample rate is an integer for most blocks
therefore one can't go below 1 samp/sec?
Lou
KD4HSO
--
View this message in context:
http://gnuradio.4.n7.nabble.com/low-frequency-in-GRC-tp48237p
Iain Young, G7III wrote
> I lashed up a quick Goertzel filter at 250Hz, and re-tuned so I was
> 250Hz off from MSF. Hacked up some code to actually decode the
> output of GRC to the timecode bits for MSF. It decodes perfectly,
> even without parity checking!
Thank you for the post. I was experime
If I want to run GR (and keep it updated via git) on a non-networked machine,
can I "git clone", copy the resulting gnuradio directory to a DVD, then "git
pull" from that DVD (specifically the *.git that is created in the gnuradio
directory?
Thanks,
Lou
KD4HSO
--
View this message in context:
Mike,
Can you give a general overview of how the program works, and maybe what you
are doing with the FFT and IFFT, and how you accomplish the tuning via mouse
click in GRC? I assume this is entirely done in GRC and there was no
modification of the generated Python?
Thanks,
Lou
KD4HSO
Mike J
Mike, thanks for the detailed explanation. Is there a reason for doing the
channel selection via FFT/IFFT method as opposed to a frequency xlating
filter? Maybe it's more efficient since you needed to do the FFT anyway for
the spectrum sense.
I see the frequency selection with the mouse is a fea
Hi all,
I updated my multi-channel, narrow-band FM recorder, tested with B200 and
N210, and put it on GitHub.
https://github.com/madengr/nbfm_rec
Features:
Parallel demodulation and recording of NBFM radio channels
Up to N channels limited by CPU and bandwidth of SDR (tested to 25 MHz
I actually started with that, but the US 2 meter "suggested" channels are
either 15 kHz or 20 kHz spacing depending on location. It's interesting to
dump all the 2 meter repeater traffic in my city to disk for several days.
Even the busy ones are only active about 2 hours/day. Unfortunately the
Orin,
Just curious what USB 3.0 chipset and OS you are using, and if you can go
over 50 Msps? I am able to get 45 Msps UHD Benchmark with the VLI VL80x,
but not over that.
Thanks,
Lou
KD4HSO
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Getting-overflows-at-50-Msps-not-su
GR 3.7.4 now has a message output on the QT GUI Frequency Sink. Is there way
in GRC to pass this message to a value field within a block? For instance,
pass it to the Center Frequency value in the UHD Source block to retune the
hardware?
Is there a way to disable the frequency re-centering when
I'm using 3.7 so I can't run your flowgraph, but you are using a NBFM to
demodulate WBFM at 93.5 MHz. Use the FM Demod block. You also don't need
the translating filter after the UHD source, unless you plan on increasing
the source sample rate to offset-tune from the LO feedthrough. Your FFT
sin
Martin,
After git pull, do I have to remove the build directory and rebuild the
entire code, or can I do a:
sudo make uninstall
cmake ../
make
make test
sudo make install
to just recompile the changed files. As a general rule, say going from
3.7.3 to 3.7.4, it's unclear to me when I should rebu
You may need the rtprio also. See notes at below link I have been keeping:
http://rfpoweramp.wordpress.com/2014/06/10/setting-up-the-usrp-b200/
Note there is something screwed up with Worpress and quotes pasted from the
Linux shell, so be careful if pasting in that text.
Lou
KD4HSO
John Meloc
Funny that I was doing the exact same thing last night, and I'm also getting
warnings on the receive end at only 500 ksps on a home LAN.
Should the stream be vectorized before the UDP sink, and if so how long? I
tried both stream and vectors but still get the warnings.
Lou
KD4HSO
Ward, Marcus
Peter,
Have you tried Baudline? It's not open source, but it is free, and will do
allot of what you want. Looks like there will be a new version soon with
64-bit support and I/Q demod. It's also quite easy to pipe GR file sink to
it via a FIFO (gr-baz has a sink for just that), but it will also
Marcus,
What OS are you using? I had the same issue (UDP not getting through on
receive side) with Fedora 20, even with Firewall "supposedly" turned off
(i.e. Trusted Zone selected). Manually adding the port exemption (I believe
I used port 65000) let the UDP through and it worked.
Lou
KD4HSO
As Martin said, it really helps to have a spectrum analyzer. What I'll do is
generate a CW tone (sinusoid) of 0.707 Vp; that is 3 dB backed off from DAC
full scale power. Then I'll increase the TX gain setting until the TX image
rejection starts to become poor. This will typically be 15 dBm for
I should note that want I really want to do is automate this measurement and
generate a series of curves that show TX_gain setting vs. intermod, for
several frequencies, at -3 dB from full scale. The state of GPIB support
under Linux doesn't seem to be that great though.
I suppose though that you
t
via Linux GPIB while controlling the GR flow, and plotting the results,
which makes a handy piece of test gear on the bench. I plan on doing the RX
side next, where results must be pulled from the GR flow via messages or
probes.
https://github.com/madengr/usrp_rf_tests
Thanks,
Lou
KD4HSO
--
I believe you need to use a probe. I'm doing something similar in the
attached *.grc. I use complex_to_mag_squared then integrate with decimation
down to 100 Hz. Take the Log10 and offset to get it in dBm, resulting in an
RSSI (Received Strength Signal Indicator) The Probe Signal pulls the RSSI
1) I have not calculated P1dB or IP3, yet. I will have to do that. I find
it's easier to look at a graph of IMD3 levels since it is more intuitive
that working from the IP3, which is more useful for calculations.
2) 0 dBFS would be the DAC swinging full scale; i.e. -1 to +1 float value
(DAC vo
1 - 100 of 124 matches
Mail list logo
