Re: [Discuss-gnuradio] config.conf location

[Pol Henarejos]

Dear Tom,

I backtraced this call and there is no implementation of gnuradio
preference file. When it is called the architecture, it returns
gr_prefs::singleton()->get_string("audio", "audio_module", "auto");
Thus, get_string is implemented as this:
const std::string
gr_prefs::get_string(const std::string section, const std::string
option, const std::string default_val)
{
  return default_val;
}

As you can see, it does not parse any value of any config file. It just
returns the default value. Even though it is implemented in a different
way in Python (it is a python written module), in C++ there isn't.
So, are you going to implement it? Have you plans to make working it?

Thanks.

-- 

Pol Henarejos
Research Engineer, MSc
pol.henare...@cttc.es

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70  Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es

On Thu, Sep 13, 2012 at 6:40 AM, Pol Henarejos  wrote:
> Dear list,
>
> I have my c++ app written using the audio module. Even though I placed
the
> [audio] audio_module=oss inside ~/.gnuradio/config.conf, the
audio_make_sink
> loads the ALSA sink. Moreover, if I execute dial_tone.py it takes
correctly
> the configuration in config.conf and uses the oss audio_sink.
>
> It seems that when I use python environment loads correctly the
config.conf
> but not my app. Do you know I have to specify some path, load command or
> something?
>
> Thank you.
> --
> Pol Henarejos
> Research Engineer, MSc
> address@hidden

Pol,

That's one of the problems with working in two languages and having
some things defined one place and others in another place. It looks
like the Python and C++ preferences don't behave exactly the same.

Instead of putting the configuration info into your home directory
('~/.gnuradio/'), try putting it into the system configuration
directory ($prefix/etc/gnuradio/conf.d) into the gr-audio.conf file.

Tom



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [gnuradio]N210 Probe Problems

[Deddi Hariprawira]

Hi All,

I have USRP N210 but I cannot probe it using usrp2_probe.

when I am trying capture packet, it is said "No USRPs found on interface
eth0"
*
*
*sudo usrp2_rx_cfile.py -f 94400 test*
*Traceback (most recent call last):*
*  File "/usr/local/bin/usrp2_rx_cfile.py", line 139, in *
*tb = rx_cfile_block(options, filename)*
*  File "/usr/local/bin/usrp2_rx_cfile.py", line 47, in __init__*
*self._u = usrp2.source_32fc(options.interface, options.mac_addr)*
*  File "/usr/local/lib/python2.7/dist-packages/gnuradio/usrp2.py", line
687, in source_32fc*
*return _usrp2.source_32fc(ifc, mac)*
*RuntimeError: No USRPs found on interface eth0*

When I am trying to burn the eeprome of USRP2, it's failed also
*
*
*./usrp/firmware/src/usrp2/burn-usrp4-eeprom *
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*
*usrper: failed to find usrp[0]*


Can you share what should I do to fix this problem ?.
The IP Address of my N210 is 192.168.2.10.
I am using gnuradio 3.3.0

Thanks,

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

[Discuss-gnuradio] "ctypes.ArgumentError: argument 1: : wrong type" on OS X 10.8.2 in GL.glNewList

[Gian Luca Decurtins]

Hi all

I've had success compiling gnuradio from source on OS X 10.8.2[1].
Now I'm facing the issue mentioned in the subject.
There is already an open bug @ 
http://sourceforge.net/tracker/?func=detail&aid=3526361&group_id=5988&atid=105988


It's the same with my installation, but I'm using OS X 10.8.2 and not 
10.7.3.


Without this bug being fixed I wont be able to run the WX GUI FFT Sink 
and WX GUI Waterfall Sink which I would like to use. I did also try some 
gnuradio-examples from OZ9AEC which did also raise the same error.


As I'm a Python beginner I do not know where to start fixing this 
issue. Can anyone tell me where to look at? As far as I know the issue 
is that the return value of GL.glNewList is not the same on all 
operating systems.


Regards
Luca, HB9FFE

[1] I had to use "cmake .. -DPYTHON_EXECUTABLE=/opt/local/bin/python
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib"
(thanks to Michael Dickens) and I did create a symlink from /usr/local 
to /opt/local.


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

Re: [Discuss-gnuradio] using general_work when output rate is not fixed

[Rahman, Muhammad Mahboob Ur]

Hi Tom & All,

I am now doing consume_each(noutput_items) but my problem is not solved yet. I 
have also made sure that my code effectively sends one sob tag and one eob tag 
per burst of samples.

Questions about new experiment:
Now, I have created yet another simple experiment whose flow-graph is as 
follows:

uhd usrp source --> my custom block --> uhd usrp sink
   |
   --> file sink

The relevant code of my custom block is below:
int
howto_send_discont::general_work (...) {

  int ninput_items_used_in_this_work_call;
  ninput_items_used_in_this_work_call = 0;

  for (int i = 0; i < noutput_items; i++){

samp_count++; 
if (samp_count == 1) { out[i] = gr_complex(0.7,0); 
this->make_sob_tag(this->nitems_written(0)+i);}
else if (samp_count == 2) { out[i] = gr_complex(0.7,0); 
this->make_eob_tag(this->nitems_written(0)+i);}
else if (samp_count == 25000) {
samp_count = 0; send_tx_pkt = true; pkt_no++; }
if (send_tx_pkt) {
pkt_samp_no++;
ninput_items_used_in_this_work_call++;
/*if (total_samps_outputted_so_far == 7761) {
   pkt_samp_no = 1; samp_count = 1; total_samps_outputted_so_far = 
1; pkt_no = 0; }
else if (total_samps_outputted_so_far < 7761){  
   total_samps_outputted_so_far++; }*/
out[i] = gmsk_pkt_samples_2[pkt_samp_no-1];
if (pkt_samp_no == 1) {
this->make_sob_tag(this->nitems_written(0)+i); 
}
else if (pkt_samp_no == 1536) {
this->make_eob_tag(this->nitems_written(0)+i);
pkt_samp_no = 0;
send_tx_pkt = false;
}
}
   
  }

  consume_each (noutput_items);

  // Tell runtime system how many output items we produced.
  return ninput_items_used_in_this_work_call;
}

You can see from the above code that my custom block maintains an internal 
counter samp_count which causes the custom block to output N samples whenever 
internal counter's count equals M (N=1536, M=25000 in my case). I use the same 
counter to initially send a burst of 2 samples to uhd usrp sink after attaching 
sob and eob tags so as to avoid underflow problem at the transmit side. But my 
problems are persistent which are:

- I see many zero-valued samples among the first 7761 output samples of my 
custom block, even when the samples my custom block should output are either 
constant valued samples or pre-recorded GMSK samples (depending upon which line 
is uncommented in my above code). Why it is so? 

- Even though I have avoided the above mentioned problem by noticing that in my 
case, after first 7761 samples, all the subsequent samples are correct. So, I 
use another counter to start all over again (to reset the functionality of my 
block) once my custom block has sent 7761 samples to uhd usrp sink. Now, the 
other issue is, when I send pre-recorded GMSK samples to the uhd usrp sink, I 
still see lot of underruns occuring indefinitely at tx side. Why are the sob 
and eob tags being ineffective? Moreover, when those GMSK packets are received 
at another node, the packet decode rate is too low over there (I guess not all 
of the samples corresponding to many GMSK packets are being transmitted from 
node1, fix me). 


Thanks in anticipation for your help,
Mahboob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Video Transmission over USRP

[priyankar bhattacharjee]

Can i use my own system as both a source as well as sink to test the same ?
It is because i do not have two terminals at my disposal for the time being.

I am proposing the following model :

TX FlowGraph:
 vlc Streaming(UDP) (My PC?) -> GR UDP Source -> GR TX
blocks

RX FlowGraph:
 GR RX blocks -> GR UDP Sink -> vlc Open-Network-stream(My
PC again?)




On Mon, Sep 24, 2012 at 11:03 PM, Adeel Anwar  wrote:

> *Priyankar*,
>
> You can use "vlc player" to stream video at any udp port. In GnuRadio u
> can use UDP Source/sink blocks.
>
> TX FlowGraph:
>  vlc Streaming(UDP) -> GR UDP Source -> GR TX blocks
>
> RX FlowGraph:
>  GR RX blocks -> GR UDP Sink -> vlc Open-Network-stream
>
>
> -Adeel
>
> On Mon, Sep 24, 2012 at 3:36 PM, priyankar bhattacharjee <
> pryan@gmail.com> wrote:
>
>> I am a novice in GnuRadio and am currently considering working on video
>> transmission using USRP. Could you kindly provide me with details of work
>> going on in this area and maybe the challenges faced too so that i that
>> while learning the same, i could focus on finding solutions to some
>> existing problems too ?
>>
>>
>>
>> --
>>
>> *regards,*
>> *priyankar bhattacharjee
>> *
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 

*regards,*
*priyankar bhattacharjee
*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] not able to play fm receiver application

[Sahoo, Anirudha]

I contacted Ettus Tech support. They said that basicRx card samples
at higher Nyquist region. So, it requires external RF gain and filtering
component.
   Can someone suggest such a RF component which I can buy off-the-shelf
which can work with basicRx card?

Thanks.

-Original Message-
From: discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org 
[mailto:discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org] On Behalf Of 
Sahoo, Anirudha
Sent: Friday, September 21, 2012 5:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] not able to play fm receiver application

Hi,
  I have a USRP N210 with basicRX daughterboard. I ran uhd_wbfm_receive.grc 
application. But I cannot tune to any FM radio station. I get warning like

--
UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 88.50 MHz
Actual frequency: -11.50 MHz
>>> gr_fir_ccf: using SSE
>>> gr_fir_fff: using SSE
audio_alsa_sink[hw:0,0]: unable to support sampling rate 4
  card requested 44100 instead.
--

There was a similar post in the archive, but the reply said, it is ok to get 
this warning. If the card supports 88.5 MHz, then why is it not able to receive 
the station?

I read somewhere that basicRX daughterboard needs an external RF component. Is 
the problem arising because I do not have an external RF component? If so, what 
kind of external RF component I should buy (from Ettus?)?

Here is the usrp_probe output

linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4); Boost_104100; 
UHD_003.004.003-221-g9d6f9492

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000

UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
-- Detecting internal GPSDO not found

UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
  _
 /
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: a0:36:fa:25:40:2f
|   |   ip-addr: 192.168.10.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: E2R20PFUP
|   |   FW Version: 12.3
|   |   FPGA Version: 10.0
|   |   
|   |   Time sources: none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |   Freq range: -50.000 to 50.000 Mhz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |   Freq range: -50.000 to 50.000 Mhz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: Basic RX (0x0001)
|   |   |   Serial: EAR00ZFRB
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: AB
|   |   |   |   Name: BasicRX (AB)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -250.000 to 250.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: BA
|   |   |   |   Name: BasicRX (BA)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -250.000 to 250.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: BasicRX (A)
|   |   |   |   Antennas: 
|   |   |   |   Sensors: 
|   |   |   |   Freq range: -250.000 to 250.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: I
|   |   |   |   Uses LO offset: No
|   |   | ___

Re: [Discuss-gnuradio] not able to play fm receiver application

[Marcus D. Leech]

I contacted Ettus Tech support. They said that basicRx card samples
at higher Nyquist region. So, it requires external RF gain and filtering
component.
Can someone suggest such a RF component which I can buy off-the-shelf
which can work with basicRx card?

Thanks.



One of these:

http://www.scott-inc.com/html/fm_bpass.htm

Coupled perhaps with one of these:

http://www.summitsource.com/24-db-dual-output-uhf-vhf-fm-distribution-amplifier-tv-signal-magnavox-m6-booster-tv-aerial-antenna-broad-band-amp-2-way-audio-video-part-m6-p-4642.html

You might need to play connector plumbing.

That was just in 2.5 minutes of googling.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

[Discuss-gnuradio] Fw: Using two daughter boards in USRP1.

[Sajjad Safdar]

Hello,
I have read in your frequently ask questions that we may record data from two 
daughter boards in one USRP. But i have the same question but in different way. 
Can we use one daughter card as sender and the other as receiver, rather using 
two USRP for this purpose.

Best Regards.

- Forwarded Message -
From: Sajjad Safdar 
To: "discuss-gnuradio@gnu.org"  
Sent: Thursday, September 20, 2012 6:46 PM
Subject: Using two daughter boards in USRP1.
 

Hello,
I am trying to use two daughter boards in one USRP1. I have RFX400 on one side 
A and TVRX on side B.
When i try to use two seprate terminals to test the daughter cards in such a 
way that RFX400 is transmitting and TVRX is recieving on the same USRP1 device 
using uhd_fft and benchmark_tx.py for sending data, but this does not work. 
when i run uhd_fft the scanning works but when i try to run benchmark_tx in 
another window, it gives some error tha can not find usrp device, how can i 
make it possible to work with both cards on the same device rather than using 
two different devices.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data

[LD Zhang]

Hello community,

I am trying to use the uhd_rx_cfile command to capture some rx samples in
the hope of recovering what I see as streaming samples in the uhd_fft Scope
mode display. Since I am really new to GR+USRP, I have a couple of
difficulties:

1. The uhd_rx_cfile command help menu does not provide a BW option
2. When using the uhd_rx_cfile command and specifying a frequency, it seems
to record a sinusoid, again possibly a bw issue. However, I am not quite
sure whether I am looking at the same signal port input. I intend to look
at LFRX daughter board port B input.
3. I have not been able to reproduce what I saw in the uhd_fft Scope mode
streaming data. Without any gain, I am seeing streaming data at a level of
+/- 200 units, which may be reasonable noise. How do I capture the same
data into a file. Since my difficulty with "uhd_rx_cfile" command, hence
this question. I have also experimented with the "rx_samples_to_file"
command with worse experience.

I could go directly to GRC GUI directly and try to learn to do everything
there. But I think there is value in being able to do this simple thing
from the command line. Your help and suggestions are appreciated.

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

Re: [Discuss-gnuradio] Fw: Using two daughter boards in USRP1.

[Josh Blum]

Can we use one daughter card as sender
> and the other as receiver, rather using two USRP for this purpose.
> 

USRP1 may have 2 transmitter and 2 receiver frontends.

You may transmit from either frontend and receive from either frontend.
Any combination should be OK.

Cheers,
-josh


> Best Regards.
> 
> - Forwarded Message - From: Sajjad Safdar
>  To: "discuss-gnuradio@gnu.org"
>  Sent: Thursday, September 20, 2012 6:46
> PM Subject: Using two daughter boards in USRP1.
> 
> 
> Hello, I am trying to use two daughter boards in one USRP1. I have
> RFX400 on one side A and TVRX on side B. When i try to use two
> seprate terminals to test the daughter cards in such a way that
> RFX400 is transmitting and TVRX is recieving on the same USRP1 device
> using uhd_fft and benchmark_tx.py for sending data, but this does not
> work. when i run uhd_fft the scanning works but when i try to run
> benchmark_tx in another window, it gives some error tha can not find
> usrp device, how can i make it possible to work with both cards on
> the same device rather than using two different devices.
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://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] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data

[Josh Blum]

On 09/25/2012 07:29 PM, LD Zhang wrote:
> Hello community,
> 
> I am trying to use the uhd_rx_cfile command to capture some rx samples in
> the hope of recovering what I see as streaming samples in the uhd_fft Scope
> mode display. Since I am really new to GR+USRP, I have a couple of
> difficulties:
> 
> 1. The uhd_rx_cfile command help menu does not provide a BW option
> 2. When using the uhd_rx_cfile command and specifying a frequency, it seems
> to record a sinusoid, again possibly a bw issue. However, I am not quite
> sure whether I am looking at the same signal port input. I intend to look
> at LFRX daughter board port B input.
> 3. I have not been able to reproduce what I saw in the uhd_fft Scope mode
> streaming data. Without any gain, I am seeing streaming data at a level of
> +/- 200 units, which may be reasonable noise. How do I capture the same
> data into a file. Since my difficulty with "uhd_rx_cfile" command, hence
> this question. I have also experimented with the "rx_samples_to_file"
> command with worse experience.
> 
> I could go directly to GRC GUI directly and try to learn to do everything
> there. But I think there is value in being able to do this simple thing
> from the command line. Your help and suggestions are appreciated.
> 

I will second this motion.

All of the hooks are available in the USRP source block, most of which
can be changed at runtime with a simple variable widget. Its nice to
change setting at runtime to see the effect.

Also, you can easily attach a file sink and a scope sink and an fft
sink. That way you know that you have captured to file the same thing
you are observing.

Also, be careful with the format of the file data. Its a binary array of
std::complex, not float, not double, etc...

-josh

> LD Zhang
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://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] Second CFP for ICCPS 2013: 4th ACM/IEEE International Conference on Cyber-Physical Systems

[Hongwei Zhang]

CALL FOR PAPERS

 ACM/IEEE ICCPS 2013 
Philadelphia, USA
April 8-11, 2013
http://cesg.tamu.edu/iccps2013/


Cyber-physical systems are systems with a coupling of the cyber aspects 
of computing and communications with the physical aspects of dynamics 
and engineering that must abide by the laws of physics.


The objective of ICCPS 2013, the 4th ACM/IEEE International Conference 
on Cyber-Physical Systems, is to serve as a single-track forum for 
reporting advances in all aspects of cyber-physical systems, including 
but not limited to theory, tools, applications, systems, and testbeds. 
Examples of theoretical advances encompassed by this conference include 
but are not limited to control, real-time, hybrid systems, and sensor 
networks. Similarly, examples of applications include transportation, 
energy, water, medical, and robotic systems, and other challenges for 
the twenty-first century.



SUBMISSION GUIDELINES
Submissions must report results from original research and not have been 
submitted to or published in other conferences or journals. Submissions 
must be a maximum of 10 pages, in 2-column format, and use font sizes of 
no less than 10 pt. Quality of the paper is the primary consideration, 
and is not synonymous with length. The length of a submission should be 
tuned to the nature of the topic addressed.


Each submission will be reviewed using a peer-review process by the 
ICCPS 2013 Program Committee. The review process will be typical of 
high-quality IEEE and ACM conferences. Papers that are clearly not 
appropriate whether in quality or scope will receive an early decision.



IMPORTANT DATES
Submission Deadline:   October 15, 2012 (11:59PM PDT)
Early Decisions:   November 15, 2012
Acceptance Decisions:  December 7, 2012
Final Manuscript:  February 15, 2013
Conference: April 8-11, 2013


ORGANIZERS

General Chair
Chenyang Lu, Washington University, USA

Program Chairs
P.R. Kumar, Texas A&M University, USA
Radu Stoleru, Texas A&M University, USA

Program Committee
Antoine Girard, Universite Joseph Fourie
Aranya Chakrabortty, North Carolina State University
Christopher Gill, Washington University in St. Louis
Eduardo Tovar, Polytechnic Institute of Porto (ISEP-IPP), Portugal
Fan Bai, General Motors
George Pappas, University of Pennsylvania
Guangfeng Liang, DOCOMO Innovations, Inc.
Guoliang Xing, Michigan State University
Hamsa Balakrishnan, Massachusetts Institute of Technology
I-Hong Hou, Texas A&M University
Insup Lee, University of Pennsylvania
Juan Jose Jaramillo, Universidad EAFIT, Colombia
Kang Shin, University of Michigan
Kannan Srinivasan, Ohio State University
Karl-Erik Arzen, Lund University, Sweden
Kyoung-Dae Kim, Texas A&M University
Le Xie, Texas A&M University
Lei Rao, General Motors
Long Le, INRS (Institut national de la recherche scientifique), Canada
Lui Sha, University of Illinois at Urbana-Champaign
Marco Caccamo, University of Illinois at Urbana-Champaign
Panos Antsaklis, University of Notre Dame
Paulo Tabuada, University of California at Los Angeles
Prabir Barooah, University of Florida
Qixin Wang, Hong Kong Polytechnic University
Rahul Mangharam, University of Pennsylvania
Rong Zheng, University of Houston
Sayan Mitra, University of Illinois at Urbana-Champaign
Sujay Sanghavi, University of Texas at Austin
Tarek Abdelzaher, University of Illinois at Urbana-Champaign
Wenbo He, McGill University
Xenofon D. Koutsoukos, Vanderbilt University
Xue Liu, McGill University

Publicity Chair
Hongwei Zhang, Wayne State University
Prabir Barooah, University of Florida

Web Chair
Kyoung-Dae Kim, Texas A&M University

ICCPS Steering Committee
Karl-Erik Arzen, Lund University, Sweden
Bruce Krogh, Carnegie Mellon University, USA
Raj Rajkumar, Carnegie Mellon University, USA (Chair)
John Stankovic, University of Virginia, USA
Janos Sztipanovits, Vanderbilt University, USA
Claire Tomlin, University of California at Berkeley, USA
Marilyn Wolf, Georgia Institute of Technology, USA





















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

[Discuss-gnuradio] Message passing - PSDU block and sink connection

[Jose Torres Diaz]

Hi,

I've just finished my block that generates PSDUs and then, it transmits
downstream subscribers using message passing mechanism. I am using as a
sink "Extras: Blob to Socket", but when I run my flowgraph in GNU Radio
Companion (after connect my new block and the sink), I got the following
error:

Traceback (most recent call last):
  File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 51,
in 
tb = top_block()
  File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 33,
in __init__
0, 0, 0, 0, 0, 1, 1, 1)
TypeError: unbound method make() must be called with my_block instance as
first argument (got int instance instead)

I would really appreciate some help with this issue. Thanks a lot,

Regards,

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

Re: [Discuss-gnuradio] Message passing - PSDU block and sink connection

[Josh Blum]

On 09/26/2012 12:47 AM, Jose Torres Diaz wrote:
> Hi,
> 
> I've just finished my block that generates PSDUs and then, it transmits
> downstream subscribers using message passing mechanism. I am using as a
> sink "Extras: Blob to Socket", but when I run my flowgraph in GNU Radio
> Companion (after connect my new block and the sink), I got the following
> error:
> 
> Traceback (most recent call last):
>   File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 51,
> in 
> tb = top_block()
>   File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 33,
> in __init__
> 0, 0, 0, 0, 0, 1, 1, 1)
> TypeError: unbound method make() must be called with my_block instance as
> first argument (got int instance instead)
> 
> I would really appreciate some help with this issue. Thanks a lot,
> 
> Regards,
> 
> Jose
> 

Can you post your xml and .i file?

-josh

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

Re: [Discuss-gnuradio] Message passing - PSDU block and sink connection

[Jose Torres Diaz]

Hi Josh,

I've attached the xml file for "my_block.xml". I don't have a .i file (like
"my_block.i"), because it is using the "extras_blobs.i" file. I've attached
for you extras_blob.i and I added some lines to that .i file in order to
include "my_block".

All the example is based on blob to stream and socket to block.

Many thanks for your kind help,

Regards,

Jose

On Wed, Sep 26, 2012 at 2:18 PM, Josh Blum  wrote:

>
>
> On 09/26/2012 12:47 AM, Jose Torres Diaz wrote:
> > Hi,
> >
> > I've just finished my block that generates PSDUs and then, it transmits
> > downstream subscribers using message passing mechanism. I am using as a
> > sink "Extras: Blob to Socket", but when I run my flowgraph in GNU Radio
> > Companion (after connect my new block and the sink), I got the following
> > error:
> >
> > Traceback (most recent call last):
> >   File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 51,
> > in 
> > tb = top_block()
> >   File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 33,
> > in __init__
> > 0, 0, 0, 0, 0, 1, 1, 1)
> > TypeError: unbound method make() must be called with my_block instance as
> > first argument (got int instance instead)
> >
> > I would really appreciate some help with this issue. Thanks a lot,
> >
> > Regards,
> >
> > Jose
> >
>
> Can you post your xml and .i file?
>
> -josh
>
/*
 * Copyright 2012 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */


// block headers

%{
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
%}

%include 
%include 
%include 
%include 
%include 
%include 
%include 
%include 
%include 


// block magic

using namespace gnuradio::extras;
GR_EXTRAS_SWIG_BLOCK_FACTORY(blob_to_filedes)
GR_EXTRAS_SWIG_BLOCK_FACTORY(blob_to_socket)
GR_EXTRAS_SWIG_BLOCK_FACTORY(blob_to_stream)
GR_EXTRAS_SWIG_BLOCK_FACTORY(filedes_to_blob)
GR_EXTRAS_SWIG_BLOCK_FACTORY(socket_to_blob)
GR_EXTRAS_SWIG_BLOCK_FACTORY(stream_to_blob)
GR_EXTRAS_SWIG_BLOCK_FACTORY(tuntap)
GR_EXTRAS_SWIG_BLOCK_FACTORY(msg_many_to_one)
GR_EXTRAS_SWIG_BLOCK_FACTORY(my_block)



My Block
extras_my_block
ASRP
import gnuradio.extras as gr_extras
 
  

 gr_extras.my_block($mode, $pkt_len, $max_pkts, $freq_mode, $freq_min, 
$freq_max, $freq_delta,
  $delay_mode, $delay_min, $delay_max, $delay_delta, $combine_mode, 
$combine_min, $combine_max, $combine_delta)
  
 
 

  
PSDU Generation Mode
mode
enum

  Incrementing Bytes
  2


  All Zeros
  0


  All Ones
  1

  

  
PSDU Length
pkt_len
29
int
  

 
Max Packets
max_pkts
10
int
  

 
Frequency Shift Mode
freq_mode
0
int

  Fixed (use min)
  0


  Sweep
  1


  Alternate min/max
  2


  Random (min/max)
  3

  

  
Freq Min
freq_min
-0.1
real
  

  
Freq Max
freq_max
0.1
real
  

  
Freq Delta
freq_delta
-0.01
real
  

  
Sample Delay Mode
delay_mode
0
int

  Fixed (use min)
  0


  Sweep
  1


  Alternate min/max
  2


  Random (min/max)
  3

  

 
Delay Min (samples)
delay_min
0
int
  
  
Delay Max (samples)
delay_max
0
int
  
  
Delay Delta
delay_delta
0
int
  

 
Packet Combining Mode
combine_mode
0
int

  Fixed (use min)
  0


  Sweep
  1


  Alternate min/max
  2


  Random (min/max)
  3

  

  
Combine Min
combine_min
1
int
  
  
Combine Max
combine_max
1
int
  
  
Combine Delta
combine_delta
1
int
  

   
out





  
 Name: My block using message passing 26 Sep 2:20pm
 Based originally on "blob to stream" example
  

Re: [Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data

[LD Zhang]

Hi,

I did try and made a GRC example of using a USRP Source and a fft sink,
scope sink, and a file sink to test out the idea.

When looking at the scope sink, the data is about +/- 2x10^-4. I changed
the gain of the USRP source block to 20 dB. But nothing happened to the
signal amplitude. How is this possible?

Please see the attached GRC if you want to see what I am doing. Thanks.

LD

> I could go directly to GRC GUI directly and try to learn to do everything
> > there. But I think there is value in being able to do this simple thing
> > from the command line. Your help and suggestions are appreciated.
> >
>
> I will second this motion.
>
> All of the hooks are available in the USRP source block, most of which
> can be changed at runtime with a simple variable widget. Its nice to
> change setting at runtime to see the effect.
>
> Also, you can easily attach a file sink and a scope sink and an fft
> sink. That way you know that you have captured to file the same thing
> you are observing.
>
> Also, be careful with the format of the file data. Its a binary array of
> std::complex, not float, not double, etc...
>
> -josh
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


test_fft_scope_file_sinks.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 Reception Problem

[Bilal]

I m using USRP2,I have configured usrp2 and tested
uhd_usrp_probe,uhd_siggen_gui and uhd_fft all works fine.
Now i want to make my own program like uhd_fft but there is a problem that
the terminal prompt returns right after i execute the program with 
notification

root@aqs-desktop:/home/aqs/Desktop# python my_uhd_fft.py 
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-224-gc2e197c0

root@aqs-desktop:/home/aqs/Desktop# 


my_uhd_fft.py program is:

from gnuradio import uhd
from gnuradio import gr
from gnuradio.wxgui import stdgui2,fftsink2
import wx
class top_block(stdgui2.std_top_block):
def __init__(self):
self.addr=uhd.device_addr()
self.u = uhd.usrp_source(self.addr,\
uhd.io_type.COMPLEX_FLOAT32, 1)
self.u.set_samp_rate(4000)
self.scope = fftsink2.fft_sink_c (panel, \
512, 4000)
self.connect(self.u, self.scope)
if __name__ == '__main__()':
app = stdgui2.stdapp(top_block,"FFT",nstatus=1)
app.MainLoop()


Regards 
Bilal Abbasi
Student 
COMSATS Institute of information technology Pakistan.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/USRP2-Reception-Problem-tp37749.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Internship opportunity to work with USRP2 (CSIRO, Australia)

[Wen.Hu]

Internship opportunities in GNU software-defined radio application development 
(Stipend AU$600 to AU$1,200 per week)

CSIRO's Autonomous System lab is a premiere research centre in pervasive 
computing and field robotics. AS lab is seeking a couple of talented 
individuals to join us for a 6-month internship. Based in Brisbane, Australia, 
you will join our research team and contribute significantly to the technology 
development in the field of GNU software defined radios. You will gain valuable 
experience through frequent, direct interaction with CSIRO researchers and 
engineers.

The primary responsibility of this internship is to develop algorithms and 
protocols for radio time-of-flight ranging and localisation. The candidates 
will use cutting edge hardware to implement standardised wireless protocols on 
the GNU platform and extend these protocols to enable localisation. Ideal 
candidates should be able to demonstrate their experience with code examples on 
GNU radios and be self-motivated, creative, and be comfortable working in a 
fast-paced work environment.

Required Skills and Experience
- skilled coder in C and Python
- experience with FPGA programming and GNU software defined radio platforms
- familiarity with building embedded software (e.g., tinyos, contiki, etc.) and 
 wireless networking protocols (WiFi, 802.15.4).

To apply
Email your resume and any other information to Wen Hu 
(wen...@csiro.au). Pointers to previous work are highly 
recommended. International candidates are encouraged and wewill provide 
assistance with obtaining work visa. The positions will remain open until 
filled.

Contacts
Wen Hu (wen...@csiro.au), Brano Kusy 
(brano.k...@csiro.au) and Philipp Sommer 
(philipp.som...@csiro.au)

---
Wen Hu, PhD,  SMACM, SMIEEE
Research Team Leader/Senior Research Scientist
Autonomous Systems Laboratory
CSIRO ICT Centre
Innovative ICT transforming Australian industries

Adjunct Associate Professor
School of EECS
Queensland University of Technology

Adjunct Associate Professor
School of ITEE
University of Queensland

P.O. Box 883, Kenmore, QLD, 4069, Australia
QCAT, 1 Technology Court, Pullenvale, QLD, 4069
T: +61 7 3327 4043, F: +61 7 3327 4455

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