Hi Kevin,
I don't know about using the config line in .gnuradio/config.conf as mine
looks something like this:
[ControlPort]
on = True
edges_list = True
[PerfCounters]
on = True
export = True
When I use gr-ctrlport-monitor or gr-perf-monitorx I always specify a host
IP address and a port like
Hi,
>From what I remember the tunnel.py scripts connect to 1 USRP.
If you run the script twice it is going to try and open a second
usrp_source and usrp_sink but you only have 1 USRP hooked up to your
computer.
If what you want to do is send packets on an interface then have those
packets go
Hi Naceur,
I think this question has more to do with GNU Radio and GRC than with USRPs
per say, so I added the GNU Radio mailing list.
I'll try and answer some of your questions.
1/ Your WX GUI looks old and ugly indeed. I've never had this issue before.
But WX widgets are "deprecated" and not
Hi all,
The packet decoder block uses packet_utils module (namely the
packet_utils.unmake_packet() function) found in gr-digital.
The crc check occurs in the unmake_packet function.
The logic in that function is correct, what do you think is wrong with
returning actual == expected?
Regards,
Apparently using a boost::shared_ptr seems to
work, contrary to a gr::fec::generic_encoder::sptr.
Problem solved
2016-02-16 10:32 GMT+01:00 Jawad Seddar <jawad.sed...@gmail.com>:
> Hi all,
>
> I'm trying to create a block that takes a gr::fec::generic_encoder::sptr
> as
Hi all,
I'm trying to create a block that takes a gr::fec::generic_encoder::sptr as
an argument (like the async_encoder block found in gr-fec).
Everyhting compiles and installs fine (I included
)but when I try using my block in a python
flowgraph, I get a TypeError : argument 1 of type
to 0, iirc.
>
>
> Best regards,
> Marcus
>
>
> On 11.01.2016 11:42, Jawad Seddar wrote:
>
> Hi Derek,
>
> I set my USRP source block to use the GPSDO as a Time source, then set the
> Sync parameter to "Unknown PPS".
> All it does is reset the USRP tilme to 0 on t
UHD 3.8.5 which works for me.
Regards,
Jawad
2016-01-08 20:10 GMT+01:00 Jawad Seddar <jawad.sed...@gmail.com>:
> Thanks Derek, I will try that when I get a chance.
>
> I didn't try setting the "Sync" parameter to "Unknown PPS" but was
> guessing it might have
; or the correct settings, but I will check this when I get a chance, but it
> may not be until Monday.
>
> Regards,
> Derek
>
> On Fri, Jan 8, 2016 at 10:40 AM, Jawad Seddar <jawad.sed...@gmail.com>
> wrote:
>
>> Hello Derek,
>>
>> Thanks for your a
->get_mboard_sensor("gps_time") return the same time.
>
> Regards,
> Derek
>
>
> On Fri, Jan 8, 2016 at 4:50 AM, Jawad Seddar <jawad.sed...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Yesterday, I decided to update from GNU Radio 3.7.7.1 + UH
+01:00 Jawad Seddar <jawad.sed...@gmail.com>:
> Hi Ralph,
>
> I did this 2 and half years ago and I basically followed the directions in
> pages 60-61 of the ETSI document linked by Marcus to generate the signals.
>
> By watching the channel on which the WiFi card wa
Hi Ralph,
I did this 2 and half years ago and I basically followed the directions in
pages 60-61 of the ETSI document linked by Marcus to generate the signals.
By watching the channel on which the WiFi card was operating, I generated
the signal at the right frequency and I could see the card
Hi all,
Yesterday, I decided to update from GNU Radio 3.7.7.1 + UHD 3.8.4 to GNU
Radio 3.7.9 + UHD 3.9.1.
I used pybombs and everything went well, my OOT modules compile and my
blocks run just like they used to.
My issue comes from the time that is set on the USRP. It seems like the
time on the
Hi,
The gitrev corresponds to the following commit I believe :
https://github.com/apache/thrift/commit/dd89dce84b73ca671c8e0b3cf597f1888e2a75dc
I personally had problems compiling that version of thrift (on Ubuntu
14.04) so I went back to 0.9.2 using gitrev 591e20f9.
Jawad
Le 2 janv. 2016
Hi Tim,
Just jumping in the conversation, I had the same problem as Piotr
described. I had hier block message ports working on 3.7.8 but not on
3.7.9. Unlike Piotr though, my hier blocks are not generated through GRC.
I had only installed 3.7.9 before Christmas holidays and couldn't figure
out
Hey Jason,
When you create a new OOT module for a pybombs install, you don't need to
create the folder in the pybombs/src directory.
Then when you do your cmake in the OOT module, you need to pass along the
path to your target using the flag -DCMAKE_INSTALL_PREFIX=/path/to/target .
And if your
e same. Clearly I'm
> > making a mistake, but I'm not able to identify what it is. In view of the
> > configuration used, someone could tell me which are my mistakes?
> > Also, I would like to know how to configure the block Channel Model
> > correctly.
> >
> > Than
Hi Antonio,
The problem might be due to delay introduced by the processing blocks.
Your OFDM modulator and demodulator don't work instantaneously, they take
some time to do their processing and forward their outputs to the next
block in line. Therefore, there is a delay between the output of the
Maybe something like this?
for(int i=0;inoutput_items;i++){
current_item = nitems_read() + i;
}
Le 3 juil. 2015 12:17 AM, Richard Bell richard.be...@gmail.com a écrit :
Is there a way to access the counter used to give tag offsets for debug
purposes without using tags? I'd like to be able to
Hi,
If I understand correctly you want to stream a video from one node to the
other. You could use VLC for that and UDP source and sink in GNU Radio.
Basically use a UDP Source on the sender side and use VLC to stream a video
to the UDP source's port.
On the receiver side, use a UDP Sink and use
Hi everyone,
I am currently trying to get 2 N210 to transmit coherently to a third N210.
All devices have GPSDO kits and the gps_locked status is on locked,
there is no MIMO cable in the setup.
I am currently doing some preliminary tests where I feed both sinks with
the same signal i.e a
Hi xianda,
I found out that using a factor of 0.05 in the multiply const works best
for me, with USRPs about 50 - 100 cm appart and rx and tx gains set to 0.
Try using a sample rate of 200k and you shouldn't get that sample rate
error again.
Regards,
Jawad
Hi everyone,
I have several USRP N210 and I want all of them to transmit using the same
frequency. Since I cannot use FDMA (this is one of my requirements, not a
GNU Radio/USRP limitation) then I thought I would give TDMA a try.
I want to be able to tell a node not to transmit when it is not its
/2014 11:46 AM, Jawad Seddar wrote:
Hi everyone,
I have several USRP N210 and I want all of them to transmit using the
same frequency. Since I cannot use FDMA (this is one of my requirements,
not a GNU Radio/USRP limitation) then I thought I would give TDMA a try.
I want to be able
Ok, thanks for the quick reply, this clarifies things for me.
2014-04-02 13:49 GMT+02:00 Martin Braun martin.br...@ettus.com:
On 04/02/2014 01:45 PM, Jawad Seddar wrote:
Yes I am using only stock GNU Radio blocks.
I don't mind creating my own block for this, I just want to be sure
Hello,
I currently have N210 devices with GNU Radio 3.7.0 installed. I am
currently using them to send and receive packets between them through a
tun/tap interface.
i would like to be able to send different packets (e.g depending on the MAC
address for instance) on different frequencies.
For
Hello,
Could you send the exact options you are using with both scripts?
2013/3/26 Nada ABDELKADER nada.abdelka...@etu.upmc.fr
Hi,
I'm trying to run benchmark_tx.py and benchmark_rx.py with two USRPs
(usrp1) connected to the same machine (Ubuntu 11.10).
I named my usrps dev0 and dev1
Hello,
I am getting the same problem you described here i.e very high packet loss
in discontinuous mode (first and last packet received with ok=False).
Could you please elaborate on how to adjust the synchronisation loops
bandwidth?
I have tried adjusting the --timing-bw and --phase-bw
.
Applying faster tracking algorithm may solve this problem, but I think it
takes long time to develop for a new guy.
On Wed, Mar 6, 2013 at 3:44 AM, Jawad Seddar jawad.sed...@gmail.comwrote:
Hello,
I am getting the same problem you described here i.e very high packet
loss in discontinuous
In my case I am inclined to think that the problem might come from the
emitter, here is why :
First, I am mostly getting errors on the last packet of the burst rather
than the first (95% of the time).
I have tweaked the benchmark_tx file a bit so that I could adjust the
length of the burst and
30 matches
Mail list logo
