I may have found the solution.
Looking up the error with libuhd.so.003, I found that I should add the
following line to /etc/ld.so.conf:
/usr/local/lib
and then run:
sudo ldconfig
Manually cleaning out everything from find / -name '*gnuradio*' and
pattern-matching with "gr-" and "uhd", (oy),
Hi All
I am Srinivasan living in Singapore and have M.Sc. Comp.Sci.
My self and few engineers have detected unknown RF at 2.4 GHz which has
different FFT pattern, waterfall image, Radio Sound.
The identification and classification of the signal is really difficult
process.
Below is th
Hi All
I am Srinivasan living in Singapore and have M.Sc. Comp.Sci.
My self and few engineers have detected unknown RF at 2.4 GHz which has
different FFT pattern, waterfall image, Radio Sound.
The identification and classification of the signal is really difficult
process.
Below is th
Hello,
I recently tried installing gnuradio on two newer core-i7 machines (both
with Ubuntu 14.04LTS) with the new version of pybombs.
Trying to stay away from pip (since I guess it's not updated as soon or
often?), I used the following commands to attempt both installs:
git clone git://github.c
On 2/5/16 6:46 PM, Richard Bell wrote:
No it wouldn't work. You have to synchronize before you start de-spreading.
I disagree. Mathematically, its the same result if you synchronize,
then despread, or despread then synchronize. In the real world,
however, its a different ballgame!
DSSS sprea
No it wouldn't work. You have to synchronize before you start de-spreading.
Rich
On Fri, Feb 5, 2016 at 3:07 PM, Henry Barton wrote:
> The last thing I wonder is, can a receiver just pick up a DSSS signal and
> start applying the despreading code? I watched a YouTube video about this
> and the
The last thing I wonder is, can a receiver just pick up a DSSS signal and start
applying the despreading code? I watched a YouTube video about this and the
example involved multiplying the spreading code by the voltages of the
composite waveform and averaging them. My system takes 16 chips to ex
"Assuming the transmitter and receiver were perfectly clocked in unison, what
stops the receiver from tuning in in the middle of a byte, thus getting a
nibble from the current byte and a nibble from the next?"
Nothing. That is a synchronization task your receiver must perform. Assuming
the TX
It will depend on how the rest of the radio is built up. I'm not familiar
with VP9, but can I assume it's a spec on bits in a higher layer then Layer
1? Another words, you are assuming you have bits to correlate with, as
opposed to wave shapes?
You're getting into the difficulties of radio design
So long as you know what you're looking for in any given scenario, you can
use that to correlate to. It can be data or a preamble. If your
receiver knows the data will always be a certain way ahead of time though,
it's hard to call that data. Semantics at that point.
Rich
On Fri, Feb 5, 2016 at 2
Typically a correlator is used to look for a known sequence of bits, so the
radio can align the rest of the processing from the end of this known
sequence. This is referred to as frame synchronization. You could use the
correlation estimation block to implement something like this. It would
place a
Hi,
By adding ${UHD_LIBRARIES}, the problem is solved :)
Thanks,
Zhihong
On Fri, Feb 5, 2016 at 11:40 AM, Zhihong Luo wrote:
> Hi Marcus,
>
> Sorry about the pictures, I will use text later on :)
>
> After adding the gnuradio-runtime, the top-block line works with no
> errors. But the gr::uh
Hi all. I've successfully written a DSSS modulator and demodulator in Windows
with a chip rate of 16x. It writes samples to a file that the demodulator can
read and despread. Before I try any practical implementations, I need to know
how a DSSS stream would be synchronized. Assuming the transmit
On 02/05/2016 03:06 PM, Chris Kuethe wrote:
I'm going to guess the root cause is power:
- I recently heard some folks wishing for an external power connector
for their minis due to power issues.
- My B200 will brown out on a 6ft cable, and usually works fine on the 3ft
- My laptop will switch fro
On 02/05/2016 03:06 PM, Chris Kuethe wrote:
I'm going to guess the root cause is power:
- I recently heard some folks wishing for an external power connector
for their minis due to power issues.
- My B200 will brown out on a 6ft cable, and usually works fine on the 3ft
- My laptop will switch fro
I'm going to guess the root cause is power:
- I recently heard some folks wishing for an external power connector
for their minis due to power issues.
- My B200 will brown out on a 6ft cable, and usually works fine on the 3ft
- My laptop will switch from charging to discharging when I push the B200
Hello,
I recently started working with the Ettus B200mini board in GNU Radio and I
appear to be having issues with the detection of USB 3.0. The system I am
working on is a Dell Latitude E6530 with Ubuntu 14.04. I just yesterday
updated to the latest version of GNU Radio and UHD by running the
bui
On 02/05/2016 01:40 PM, Michael Skaggs wrote:
Hello,
I recently started working with the Ettus B200mini board in GNU Radio
and I appear to be having issues with the detection of USB 3.0. The
system I am working on is a Dell Latitude E6530 with Ubuntu 14.04. I
just yesterday updated to the lat
It's not in a released version yet (the fix). We'll have a new release soon.
Cheers,
Martin
On 02/04/2016 06:50 PM, Seth Hitefield wrote:
> Can you try installing pybombs by cloning the git repo and running 'sudo
> python setup.py install'? I believe we pushed a fix for that a few days
> ago, but
On 02/05/2016 12:29 PM, Hans Van Ingelgom wrote:
Hello,
I've updated pybombs to the latest revision. update now works without
crashing.
I still can't access the hardware.
If I run osmocom_fft i get the following message:
built-in source types: file osmosdr fcd rtl rtl_tcp uhd rfspace redpit
While I am still not certain if this is the intended behavior or not, I
made a fix that resolves my issue (Pull Request 737 here:
https://github.com/gnuradio/gnuradio/pull/737). It's quite possible I am
overlooking broader applications here, so let me know if this is not the
desired way of dealing
Hello,
I've updated pybombs to the latest revision. update now works without
crashing.
I still can't access the hardware.
If I run osmocom_fft i get the following message:
built-in source types: file osmosdr fcd rtl rtl_tcp uhd rfspace redpitaya
With gqrx it is a bit different:
built-in sourc
Hi Marcus,
Sorry about the pictures, I will use text later on :)
After adding the gnuradio-runtime, the top-block line works with no errors.
But the gr::uhd::usrp_source::sptr usrp_source =
gr::uhd::usrp_source::make(device_addr, uhd::stream_args_t("fc32")); stills
has error:
/usr/bin/ld: CMak
Sorry, I had brain rottage.
So, 4 dBW is a little more than 2W (unlike 40dBW, which is 10kW,
indeed). Also, small errors in the SNR formula (suddenly dropped a -1,
but that doesn't really hurt much, there).
On 05.02.2016 11:51, Marcus Müller wrote:
> Hi Daniel,
>
> On 04.02.2016 22:49, Daniel Poco
Hi Daniel,
On 04.02.2016 22:49, Daniel Pocock wrote:
> To give a more specific example:
>
> a) SDR device sampling the 2 meter band (144 - 148 MHz), this input
> range is locked and can't be changed by users
>
> b) using something like the USRP B200
> - it can do 61 Million samples/sec, 12 bit sam
Hi Zhihong,
please stop posting screenshots of text. It's text, you can mark it,
copy it, and paste it to an email as text. It's way easier for everyone
to deal with that.
Now, you've used
target_link_libraries(tags gnuradio-uhd boost_system)
which links the target "tags" against the libraries
26 matches
Mail list logo
