Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-23 Thread Bastian Bloessl

Hello Dingwen,

On 04/22/2013 10:13 AM, Dingwen Yuan wrote:


I think the loopback works. I get some logs in the gnuradio-companion
likes this:
Hello World!
ut


I casted the not-0-terminated buffer to char as debug output :)
Should be fixed now.


Changing gain and the direction of antenna really improves the packet
reception rate. I have just one USRP, therefore I tried the
communication between USRP and your contiki code.
The log I got always look like a number of Os folowing by Hello Gun
Radio, like OHello Gnu Radio. What does the O means?



 means that the PC can't keep up with the sampling rate and thus, 
experiences 'O'verruns. That was because I set the sampling rate way 
higher then needed. I just pushed the flow graphs with a rate of 4Msps.


You can play around with that, you just have to set the 'Omega' of the 
'Clock Recovery MM' block accordingly (samp_rate / Omega != 2Msps).




Just out of curiosity, did you try the transceiver? Is it working
for you?

I tried transceiver, it doesn't work. But tx works perfectly.


Maybe because you are using a full-duplex daughterboard while I use a 
half-duplex one. Would be great if you try to set the antenna of the 
USRP source and sink blocks manually to the same value. Then it should 
operate in half-duplex mode. (I think this is possible with your board, 
check 'uhd_usrp_probe' to see a list of options)



BTW, what have you changed in your code in comparison with the original
UCLA Zigbee.
The receiver structure, the parameters of the flow graph (clock 
recovery...), and the 'packet_sink' block is from the UCLA 
implementation. This is where all decoding happens.

It is based on this implementation, so you can see the changes in git.

I just pushed the changes to github.

Hope it helps!
Bastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-22 Thread Dingwen Yuan
Hi Bastian,

Thanks for your reply.


 I use a XCVR2450 with an N210. Up until now I did not do any real
 performance measurements, but with the PCAP output it sould be easy to
 quantify your losses. You can just open the PCAP file, with Wireshark for
 example, and immediately see how many packets you received. Note that
 currently all packets are written to PCAP (i.e. CRC is not checked).

 If you think its a bug in the code and let's say the packet format is
 wrong and thus every n-th packet is wrongly encoded, then you can check it
 with the loopback flow graph.


I think the loopback works. I get some logs in the gnuradio-companion likes
this:
Hello World!
ut
Hello World!
ut
Hello World!
ut
Hello World!
ut




 Some other stuff you could try:
 - more gain
 - less gain :)
 - other channel (if you have a lot of WiFi traffic there)
 - are your USRPs close to each other? Try moving them some meters apart
 from each other.

Changing gain and the direction of antenna really improves the packet
reception rate. I have just one USRP, therefore I tried the communication
between USRP and your contiki code.
The log I got always look like a number of Os folowing by Hello Gun Radio,
like OHello Gnu Radio. What does the O means?



 Just out of curiosity, did you try the transceiver? Is it working for you?

I tried transceiver, it doesn't work. But tx works perfectly.
BTW, what have you changed in your code in comparison with the original
UCLA Zigbee.

Regards,

Dingwen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-19 Thread Dingwen Yuan
Hi Bastian,

I played a bit with your examples. The tx all works perfect. But for rx,
sometimes I get the hello gnuradio messages, sometimes not. What
daughterboard are you using, I use the RFX2400.

Regards,

Dingwen


2013/4/17 Bastian Bloessl bastian.bloe...@uibk.ac.at

 Hi Dingwen,


 On 04/17/2013 10:38 AM, Dingwen Yuan wrote:

 Now the grc examples work with no error. The crash of the system during
 gnuradio compilation is due to the boost version (the version 1.46
 causes the problem). After I switched to version 1.48, the compilation
 of the current gnuradio from the git repository works all right.


 Great that it works now! ...and thanks for reporting the problem.

 Best,
 Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-19 Thread Bastian Bloessl

Hi Dingwen,

On 04/19/2013 05:16 PM, Dingwen Yuan wrote:

I played a bit with your examples. The tx all works perfect. But for rx,
sometimes I get the hello gnuradio messages, sometimes not. What
daughterboard are you using, I use the RFX2400.


Cool, that it compiles and at least does *something* :)

I use a XCVR2450 with an N210. Up until now I did not do any real 
performance measurements, but with the PCAP output it sould be easy to 
quantify your losses. You can just open the PCAP file, with Wireshark 
for example, and immediately see how many packets you received. Note 
that currently all packets are written to PCAP (i.e. CRC is not checked).


If you think its a bug in the code and let's say the packet format is 
wrong and thus every n-th packet is wrongly encoded, then you can check 
it with the loopback flow graph.


Some other stuff you could try:
- more gain
- less gain :)
- other channel (if you have a lot of WiFi traffic there)
- are your USRPs close to each other? Try moving them some meters apart 
from each other.


Just out of curiosity, did you try the transceiver? Is it working for you?

Hope it helps,
Bastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-17 Thread Dingwen Yuan
Hi Bastian,

Now the grc examples work with no error. The crash of the system during
gnuradio compilation is due to the boost version (the version 1.46 causes
the problem). After I switched to version 1.48, the compilation of the
current gnuradio from the git repository works all right.

Regards,

Dingwen


2013/4/16 Bastian Bloessl bastian.bloe...@uibk.ac.at

 Hey Brian,

 first, thank you for your comment.


 On 04/15/2013 03:37 PM, Brian Padalino wrote:


 I think it would be great for the community to get a rundown of the
 entire standard itself, modulation/demodulation within GNU Radio, how
 you handled frequency/sampling offsets, etc.



 I thought about that and as it is all-supervisors-are-at-**infocom-week,
 I tried something...

 I made an IPython notebook, and reimplemented the transmitter iterative
 (i.e. non-stream) in python in the browser. I annotated it with text and
 plots and pictures.
 It leads the reader step by step through the whole encoding process until
 we are at complex baseband representation. Than it writes the samples into
 a file. (The whole stuff happens in the browser, or is controlled through
 the browser).

 I included a script, that creates a Linux pipe and starts the file_tx
 program, which is part of the UHD library. So the samples are really
 transmitted.
 I can receive the signal that I send in the browser with my TelosB mote.

 It's somehow funny and you can look at the signal in every stage of the
 encoding process.

 It's a bit hard to describe and maybe some don't have ipython installed.
 So I made a really, really ugly video [1], but maybe it helps to see what
 going on.

 You can have a look at the notebook here [2]. It is a Gist rendered by the
 notebook viewer. You can download the Gist [3] and run it interactively in
 your browser.

 The whole stuff is not prove read, contains a lot of errors, is just 4 fun
 and should just show the idea.

 Best,
 Bastian


 [1] 
 http://www.youtube.com/watch?**v=OKeRCZGHi1Ehttp://www.youtube.com/watch?v=OKeRCZGHi1E
 [2] http://nbviewer.ipython.org/**5394322http://nbviewer.ipython.org/5394322
 [3] 
 https://gist.github.com/**bastibl/5394322https://gist.github.com/bastibl/5394322



 --
 Dipl.-Inform. Bastian Bloessl
 Institute of Computer Science
 University of Innsbruck, Austria
 Phone: +43 512 507-53288 / Fax: -53079
 http://ccs.uibk.ac.at/~**bloessl/ http://ccs.uibk.ac.at/~bloessl/

 __**_
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-17 Thread Bastian Bloessl

Hi Dingwen,

On 04/17/2013 10:38 AM, Dingwen Yuan wrote:

Now the grc examples work with no error. The crash of the system during
gnuradio compilation is due to the boost version (the version 1.46
causes the problem). After I switched to version 1.48, the compilation
of the current gnuradio from the git repository works all right.


Great that it works now! ...and thanks for reporting the problem.

Best,
Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-16 Thread Dingwen Yuan
Hi Bastian,

I am newbie to USRP and Gnuradio. I did make and make install of your
project. But when I opened the rx.grc, I got some errors. Could you please
take a look what is the cause for that?

Thanks in advance.

 Welcome to GNU Radio Companion 3.6.4.1 

Loading: /home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc
 Error: Block key ieee802_15_4_mac_deframer not found in Platform -
grc(GNU Radio Companion)
 Error: Block key ieee802_15_4_rime_deframer not found in Platform -
grc(GNU Radio Companion)
 Error: Block key ieee802_15_4_packet_sink not found in Platform -
grc(GNU Radio Companion)
 Error: Block key blocks_file_sink not found in Platform - grc(GNU
Radio Companion)
 Error: Block key ieee802_15_4_wireshark_connector not found in
Platform - grc(GNU Radio Companion)
 Error: Connection between digital_clock_recovery_mm_xx_0(0) and
ieee802_15_4_packet_sink_0(0) could not be made.
sink block id ieee802_15_4_packet_sink_0 not in block ids
 Error: Connection between ieee802_15_4_packet_sink_0(out) and
ieee802_15_4_mac_deframer_0(pdu in) could not be made.
source block id ieee802_15_4_packet_sink_0 not in block ids
 Error: Connection between ieee802_15_4_mac_deframer_0(pdu out) and
ieee802_15_4_rime_deframer_0(pdu in) could not be made.
source block id ieee802_15_4_mac_deframer_0 not in block ids
 Error: Connection between ieee802_15_4_rime_deframer_0(pdu out) and
gr_socket_pdu_0(pdus) could not be made.
source block id ieee802_15_4_rime_deframer_0 not in block ids
 Error: Connection between ieee802_15_4_packet_sink_0(out) and
ieee802_15_4_wireshark_connector_0(in) could not be made.
source block id ieee802_15_4_packet_sink_0 not in block ids
 Error: Connection between ieee802_15_4_wireshark_connector_0(0) and
blocks_file_sink_0(0) could not be made.
source block id ieee802_15_4_wireshark_connector_0 not in block ids
 Done

Showing: /home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc


Dingwen

2013/4/15 Bastian Bloessl bastian.bloe...@uibk.ac.at

 Hi all,

 I played a bit around with the 802.15.4 blocks [1]. Maybe someone is
 interested.

 The changes are:
 - It has a transceiver flow graph. (That was really easy with the new PDU
 to tagged stream block)
 - annotate LQI value in dict of PDUs
 - CRC check
 - Wireshark Connector. You can write received packets in a pcap file, that
 can be read by Wireshark, which has 802.15.4 dissectors.
 - and the coolest thing: the whole encoding is now done with standard GNU
 Radio blocks. This includes pulse shaping and the byte to chunk to chip to
 symbol mapping. It's really cool what you can do with plain GNU Radio.

 I tested interoperability it with TelosB motes. I guess it compiles only
 on Linux due to the gettimeofday(?) call.
 Maybe I messed up my installation as I tried the next branch and didn't
 uninstall it cleanly. Now some block names are appended with '(old)'. I
 hope the flow graphs work nevertheless.

 Have fun,
 Bastian

 [1] 
 https://github.com/bastibl/gr-**ieee802-15-4https://github.com/bastibl/gr-ieee802-15-4

 --
 Dipl.-Inform. Bastian Bloessl
 Institute of Computer Science
 University of Innsbruck, Austria
 Phone: +43 512 507-53288 / Fax: -53079
 http://ccs.uibk.ac.at/~**bloessl/ http://ccs.uibk.ac.at/~bloessl/

 __**_
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-16 Thread Bastian Bloessl

Hey Brian,

first, thank you for your comment.

On 04/15/2013 03:37 PM, Brian Padalino wrote:


I think it would be great for the community to get a rundown of the
entire standard itself, modulation/demodulation within GNU Radio, how
you handled frequency/sampling offsets, etc.




I thought about that and as it is all-supervisors-are-at-infocom-week, I 
tried something...


I made an IPython notebook, and reimplemented the transmitter iterative 
(i.e. non-stream) in python in the browser. I annotated it with text and 
plots and pictures.
It leads the reader step by step through the whole encoding process 
until we are at complex baseband representation. Than it writes the 
samples into a file. (The whole stuff happens in the browser, or is 
controlled through the browser).


I included a script, that creates a Linux pipe and starts the file_tx 
program, which is part of the UHD library. So the samples are really 
transmitted.

I can receive the signal that I send in the browser with my TelosB mote.

It's somehow funny and you can look at the signal in every stage of the 
encoding process.


It's a bit hard to describe and maybe some don't have ipython installed. 
So I made a really, really ugly video [1], but maybe it helps to see 
what going on.


You can have a look at the notebook here [2]. It is a Gist rendered by 
the notebook viewer. You can download the Gist [3] and run it 
interactively in your browser.


The whole stuff is not prove read, contains a lot of errors, is just 4 
fun and should just show the idea.


Best,
Bastian


[1] http://www.youtube.com/watch?v=OKeRCZGHi1E
[2] http://nbviewer.ipython.org/5394322
[3] https://gist.github.com/bastibl/5394322


--
Dipl.-Inform. Bastian Bloessl
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-16 Thread Bastian Bloessl

Hello Dingwen,

On 04/16/2013 11:24 AM, Dingwen Yuan wrote:


 Welcome to GNU Radio Companion 3.6.4.1 

Loading: /home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc
  Error: Block key ieee802_15_4_mac_deframer not found in Platform
- grc(GNU Radio Companion)
  Error: Block key ieee802_15_4_rime_deframer not found in Platform
- grc(GNU Radio Companion)
  Error: Block key ieee802_15_4_packet_sink not found in Platform -



I tried to reproduce the error, but without success. I searched in my 
local installation path and assured that I really uninstalled 
everything. Then, I did 'git clean -xdf' and 'git reset --hard' in the 
git repo and installed everything again.


I guess the problem is that GRC can't find the XML files.
Where do you have your other GRC blocks installed? Was the installation 
really successful?


I'm afraid you are the first tester :) So maybe its a CMake bug and the 
files are not placed where they are supposed to be placed.


Best,
Bastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-16 Thread Dingwen Yuan
Hi Bastian,

I am using Ubuntu 12.04. I first try to compile the gnuradio with
build-gnuradio script. But the system crashed after starting making
gnuradio.

So later I use the precompiled gnuradio and uhd directly from ettus. It
seems that the gnuradio is install in the folder
/usr/local/lib/python2.7/dist-packages.

I did compile your gr-ieee802-15-4 and everything works all right. After
sudo make install, it is installed in /usr/share/gnuradio. So I think the
problem is due to the path setting. I will try to set the path properly.

Thanks!

Dingwen



2013/4/16 Bastian Bloessl bastian.bloe...@uibk.ac.at

 Hello Dingwen,


 On 04/16/2013 11:24 AM, Dingwen Yuan wrote:


  Welcome to GNU Radio Companion 3.6.4.1 

 Loading: /home/pdv/work/usrp/gr-**ieee802-15-4/examples/rx.grc
   Error: Block key ieee802_15_4_mac_deframer not found in Platform
 - grc(GNU Radio Companion)
   Error: Block key ieee802_15_4_rime_deframer not found in Platform
 - grc(GNU Radio Companion)
   Error: Block key ieee802_15_4_packet_sink not found in Platform -



 I tried to reproduce the error, but without success. I searched in my
 local installation path and assured that I really uninstalled everything.
 Then, I did 'git clean -xdf' and 'git reset --hard' in the git repo and
 installed everything again.

 I guess the problem is that GRC can't find the XML files.
 Where do you have your other GRC blocks installed? Was the installation
 really successful?

 I'm afraid you are the first tester :) So maybe its a CMake bug and the
 files are not placed where they are supposed to be placed.

 Best,
 Bastian


 __**_
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-15 Thread Bastian Bloessl

Hi all,

I played a bit around with the 802.15.4 blocks [1]. Maybe someone is 
interested.


The changes are:
- It has a transceiver flow graph. (That was really easy with the new 
PDU to tagged stream block)

- annotate LQI value in dict of PDUs
- CRC check
- Wireshark Connector. You can write received packets in a pcap file, 
that can be read by Wireshark, which has 802.15.4 dissectors.
- and the coolest thing: the whole encoding is now done with standard 
GNU Radio blocks. This includes pulse shaping and the byte to chunk to 
chip to symbol mapping. It's really cool what you can do with plain GNU 
Radio.


I tested interoperability it with TelosB motes. I guess it compiles only 
on Linux due to the gettimeofday(?) call.
Maybe I messed up my installation as I tried the next branch and didn't 
uninstall it cleanly. Now some block names are appended with '(old)'. I 
hope the flow graphs work nevertheless.


Have fun,
Bastian

[1] https://github.com/bastibl/gr-ieee802-15-4

--
Dipl.-Inform. Bastian Bloessl
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-15 Thread Martin Braun (CEL)
On Mon, Apr 15, 2013 at 02:34:35PM +0200, Bastian Bloessl wrote:
 I played a bit around with the 802.15.4 blocks [1]. Maybe someone is
 interested.
 
 The changes are:
 - It has a transceiver flow graph. (That was really easy with the
 new PDU to tagged stream block)
 - annotate LQI value in dict of PDUs
 - CRC check
 - Wireshark Connector. You can write received packets in a pcap
 file, that can be read by Wireshark, which has 802.15.4 dissectors.
 - and the coolest thing: the whole encoding is now done with
 standard GNU Radio blocks. This includes pulse shaping and the byte
 to chunk to chip to symbol mapping. It's really cool what you can do
 with plain GNU Radio.

Hi Bastian,

haven't tested it yet, but just want to say that this is really awesome
work you guys are doing!

Cheers,
MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgptDMylfHY4l.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-15 Thread Tom Rondeau
On Mon, Apr 15, 2013 at 8:34 AM, Bastian Bloessl
bastian.bloe...@uibk.ac.at wrote:
 Hi all,

 I played a bit around with the 802.15.4 blocks [1]. Maybe someone is
 interested.

 The changes are:
 - It has a transceiver flow graph. (That was really easy with the new PDU to
 tagged stream block)
 - annotate LQI value in dict of PDUs
 - CRC check
 - Wireshark Connector. You can write received packets in a pcap file, that
 can be read by Wireshark, which has 802.15.4 dissectors.
 - and the coolest thing: the whole encoding is now done with standard GNU
 Radio blocks. This includes pulse shaping and the byte to chunk to chip to
 symbol mapping. It's really cool what you can do with plain GNU Radio.

 I tested interoperability it with TelosB motes. I guess it compiles only on
 Linux due to the gettimeofday(?) call.
 Maybe I messed up my installation as I tried the next branch and didn't
 uninstall it cleanly. Now some block names are appended with '(old)'. I hope
 the flow graphs work nevertheless.

Hi Bastian,

First, great work!

So can you point out where that gettimeofday call is being made? We
should be dealing with that situation in cmake, so if something's
going wrong, let us know.

And the '(old)' block were recently discussed in a mailing list post
from a couple of weeks ago. This is just us telling you that these are
the old-style blocks in 3.6. They will still work for the time being,
but if you upgrade to 3.7, they will have disappeared. The (old)
indication is so that you can switch them out with the new blocks that
are functionally equivalent but now in the 3.7 style so they can be
future compatible when updating to 3.7.

Hope this helps,
Tom



 Have fun,
 Bastian

 [1] https://github.com/bastibl/gr-ieee802-15-4

 --
 Dipl.-Inform. Bastian Bloessl
 Institute of Computer Science
 University of Innsbruck, Austria
 Phone: +43 512 507-53288 / Fax: -53079
 http://ccs.uibk.ac.at/~bloessl/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-15 Thread Bastian Bloessl

Hi Tom,

thanks for your response!

On 04/15/2013 03:55 PM, Tom Rondeau wrote:

So can you point out where that gettimeofday call is being made? We
should be dealing with that situation in cmake, so if something's
going wrong, let us know.
It's not a problem of GNU Radio. I use gettimeofday to time stamp the 
received packets for the pcap trace file. I guess I should search for a 
better function. I will have a look at the UHD blocks.



And the '(old)' block were recently discussed in a mailing list post
from a couple of weeks ago. This is just us telling you that these are
the old-style blocks in 3.6. They will still work for the time being,
but if you upgrade to 3.7, they will have disappeared. The (old)
indication is so that you can switch them out with the new blocks that
are functionally equivalent but now in the 3.7 style so they can be
future compatible when updating to 3.7.
I was just not sure what happens when I upload a flow graph where (at 
least locally) some blocks are marked '(old)' and someone with 3.6.4 
tries to run them. But it looks like it should work, as at least in the 
.grc files there is no 'old'.


Best,
Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Some new 802.15.4 stuff

2013-04-15 Thread Tom Rondeau
On Mon, Apr 15, 2013 at 10:21 AM, Bastian Bloessl
bastian.bloe...@uibk.ac.at wrote:
 Hi Tom,

 thanks for your response!


 On 04/15/2013 03:55 PM, Tom Rondeau wrote:

 So can you point out where that gettimeofday call is being made? We
 should be dealing with that situation in cmake, so if something's
 going wrong, let us know.

 It's not a problem of GNU Radio. I use gettimeofday to time stamp the
 received packets for the pcap trace file. I guess I should search for a
 better function. I will have a look at the UHD blocks.

Ok, good to know. Yeah, there are ways to handle that cross-platform.

 And the '(old)' block were recently discussed in a mailing list post
 from a couple of weeks ago. This is just us telling you that these are
 the old-style blocks in 3.6. They will still work for the time being,
 but if you upgrade to 3.7, they will have disappeared. The (old)
 indication is so that you can switch them out with the new blocks that
 are functionally equivalent but now in the 3.7 style so they can be
 future compatible when updating to 3.7.

 I was just not sure what happens when I upload a flow graph where (at least
 locally) some blocks are marked '(old)' and someone with 3.6.4 tries to run
 them. But it looks like it should work, as at least in the .grc files there
 is no 'old'.

 Best,
 Bastian

Yeah, you'll be fine. The .grc files only keep track of the key tag of
the XML code that defines the block in GRC; that's translated in GRC
to the block's name tag, which is where the (old) string is added.

Tom

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio