We have functions to convert PMTs to corresponding Python types. Have
you tried those? to_python()?
M
On 10/09/2014 02:57 AM, Jonathan Fox wrote:
> I have a series of collected metadata files. I have taken both the
> gr_read_file_metadata.py and parse_file_metadata.py scripts and hacked
> them to
Hi Jeroen,
here a link where there is an example about how to use UHD class.
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html
go in section "Detailed description".
Give me a feedback if you are able to use this class in our own block.
Bests,
Simone
On Wed, 8 Oct 2014 14:01:39 +0
Hello all,
I want to make a test communication system with USRP for narrow band HF
range voice transmission and reception. Also I am interested in using OFDM
scheme for that.
I need some guidance about what packages I should use for HF freq range and
OFDM multiplexing..?
If someone could provide
Greetings,
finnaly got it working :D Problem was with descrambler. Now it gives results
as follows:
Service: 'ok'
Duration: ''
Source_MAC_Adress: '232323232323'
Destination_MAC_Adress: ''
Protocol_ver
On 10/09/2014 10:40 AM, Ernest Szczepaniak wrote:
Greetings,
finnaly got it working :D Problem was with descrambler. Now it gives results
as follows:
Service: 'ok'
Duration: ''
Source_MAC_Adress: '232323232323'
Destinatio
Two things:
1. Martin was right, doing this using messages is cleaner!
2. GRC generates python files when you click the generate button. You
can change these files to your heart's delight; most C++ public
functions are even exported to the encapsulating python class.
Furthermore, you can write bloc
Start with setting up the OFDM Transmitter and -Receiver blocks using
random data. Make sure you've understood all the concepts along the way
(tagged streams etc.).
Once that works, I recommend using the vocoder blocks to generate
compressed digital voice data and pipe that into the OFDM codes.
C
Hi Johannes,
Could you share the LTE record data that you used in gr-lte?
--
Thanks
Tiankun
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thank you so much Marcus,
I've learnt so much from you here :)
The algorithm of finding the Max of a vector by comparing one half to the
other half, is an appropriate idea! I can't use GNURadio blocks for this
calculation because I must do these within my own block.
Unfortunately, I'm not familia
Hello guys,
I have a problem with installing GNURadio on Debian i86 7.6. After
executing "./pybombs install gnuradio", I got the following error related
to boost:
"
File "/home/alizadeh/gnuradio_src/pybombs/mod_pybombs/recipe.py", line 649,
in fetch
raise Exception("Failed to Fetch package '%
Hi Mostafa,
pybombs tries to install boost from source because 1.49 is known to be
buggy.
It seems like it can't download the file. Since this works here, that
might have been a temporary issue (try again!) or it might be caused by
the need to use a proxy to access websites from where you are wor
Compilers are good, just use a linear comparison:
float *current= input;
float max = *current;
float *end = first + length_of_array;
while(current < end){
max = (*current > max) ? *current++ : max;
:)
On 09.10.2014 13:09, Mostafa Alizadeh wrote:
> Thank you so much Marcus,
>
> I've learnt so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tiankun,
the recorded files are simply to large to share. (> 1GB)
Also, you probably want to record your own data.
This gets us to the second option. Generated test data. Using the
integrated Python files to generate test data is unfortunately
inc
On Wed, Oct 8, 2014 at 7:25 PM, Jeff Long wrote:
> Hi Thanasis,
>
> 1. The flow you showed could not have worked because Packet Decoder takes
> unpacked bytes. The graph should be:
>
> File Source -> Encoder -> Packed-to-Unpacked -> Decoder -> File Sink
>
> 2. The payload length defaults to 512 i
I could provide storage space for such a file, but only at an upstream of 10
Mbps.
Ralph.
> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Johannes Demel
> Sent: Thursday, October 9,
Hi Marcus,
Thanks for your reply. I think the best way to us is to find the new
version of Hydra package which is based on the recent GNU Radio version
working with current USRP produces.
Another question is that, if we development the software with GNU Radio and
USRP in Ubuntu, is it easy to tra
Jeff, Tom,
The packet framer/deframer is mostly identical to the stream-based one in
GNU Radio proper. It's not a bad starting point, but a more general
implementation that could be configured for a variety of applications,
codes, and frame formats would be very interesting. I think this would b
Hi everyone,
I am a new user of GNU radio. I am trying to communicate between Tmote Sky
sensor node and USRP N210.
I use the Tmote Sky sensor node as transmitter to broadcast messages by
flashing the example code into the node. The messages are broadcast in radio
channel 26. (The code is this one
If there aren't any GR-specific issues, you might consider moving this to
the UHD-users mailing list.
- Presumably, you're using an SBX?
- Is there any chance the bursts are just very short? Experiment with
the trigger settings on the scope to see if you can catch any bursts.
-John
On
Yes. Nothing in GNU Radio or UHD (the USRP driver framework) is
distribution-specific, so transition from Ubuntu to Fedora should not be
a problem
Good luck with finding a "new version" of Hydra; I didn't find any
publication after 2009 on a quick first glance on google scholar[1]. And
I couldn't
Hi John,
Thanks for your reply.
I am using RFX2400 2.3-2.9GHZ RX/TX
I increased the message length from 4 to 100 at the sender. But I still can
not observe the signal. (Maybe because of the power of signal is too small?)
The USRP N210 can receive signal at frequency around 2.9GHz. So I think th
4 to 100? What are the units? How long is the actual burst? Just
guessing - a ~100 byte packet at the lowest datarate (250 kbps) of the
CC2420 chip means the packet will e about 3.2 ms. If you're using the 2
mbps rate, obviously it'll be much shorter. Unless you're sending these
packets with v
No I didn't, I had no idea they existed, as I was depending on
http://gnuradio.org/doc/doxygen/page_pmt.html for information instead of
http://gnuradio.org/redmine/projects/gnuradio/wiki/TypePMT which has a
little more info on to_python().
My bad, I guess I wasn't thorough in reading about PMTs. I
Dear Marcus and all,
Many thanks for the advice regarding the Hydra and ORBIT project.
Actually I'm looking for the open-source 802.11 PHY&MAC packages which are
compatible with Recent GNU Radio and USRP N210/X310.
I've searched from internet and got some findings listed below:
1) Hydra PHY & MA
Hi Jiayi,
:) gr-ieee802-11 is, as far as I know, the most comprehensive,
functional implementation so far. It *can* talk to consumer cards -- but
of course, that's not because it has a complete MAC implementation.
Actually, doing a really standards-compliant IEEE802.11agp MAC can't
really be done
Ok. All working fine :D
--
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50731.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@g
Thank you Jeff!
Indeed, it works!
I really appreciate your help.
Thanasis
2014-10-09 18:21 GMT+03:00 John Malsbury :
> Jeff, Tom,
>
> The packet framer/deframer is mostly identical to the stream-based one in
> GNU Radio proper. It's not a bad starting point, but a more general
> implementation
27 matches
Mail list logo
