What about the passive radar - didn't the author daisy chain the clocks of
several RTLSDR?
Regards,
Vanush
On Wed, May 14, 2014 at 4:31 PM, Imre wrote:
> We must not forget that each device has its own USB connection.
> One reason that getting all in sync on a ' per sample' base must be
> imp
On 14.05.2014 09:03, Vanush Vaswani wrote:
What about the passive radar - didn't the author daisy chain the clocks
of several RTLSDR?
That was two dongles sharing a clock. Not exactly daisy-chained, and it
didn't look easily extendible :)
http://kaira.sgo.fi/2013/09/passive-radar-with-16-dua
On 14.05.2014 08:11, Activecat wrote:
Dear gurus,
I am learning gnuradio Message Passing feature, but couldn't get
desirable result.
The Message seems published successfully, but not subscribed by the
Message receiver.
How to correct the error ..?
Just to make sure: You did connect the ports i
On 14.05.2014 04:36, Ron Economos wrote:
If you're sending packets, then Length Tag Key should be
set to the packet length you're using. If you're sending
a stream (like DVB-T), then this field is not used (and
left blank).
It needs an empty string, in this case.
The OFDM cyclic prefixer is u
On 13.05.2014 19:27, Mostafa Alizadeh wrote:
Hi,
I recently encountered a problem with the large number of items. I wanna
pass about 75000 items from one block to the another. I thought that I
could do this with setting the min of output items in the constructor of
the block but I got the follow
I am confused about the terms full duplex and half duplex in context of
USRP...If i am using two antennas attached on the same channel on B210(one
on TX/RX and other on RX2).I am Rxing through one antenna and
retransmitting the signal with the other antenna..Am i operating on full
duplex or half du
Full duplex implies simultaneous transmission and reception, almost always
on different frequencies. In the cellular world this is called frequency
division duplexing, or FDD. Full duplex on a USRP implies transmitting on
one connector (TX/RX) and receiving on the other (RX2).
Half duplex means
Thank you Matt!
On Wed, May 14, 2014 at 2:13 PM, Matt Ettus wrote:
>
> Full duplex implies simultaneous transmission and reception, almost always
> on different frequencies. In the cellular world this is called frequency
> division duplexing, or FDD. Full duplex on a USRP implies transmitting
On Wed, May 14, 2014 at 4:26 PM, Martin Braun wrote:
> On 14.05.2014 08:11, Activecat wrote:
>
>> Dear gurus,
>>
>> I am learning gnuradio Message Passing feature, but couldn't get
>> desirable result.
>> The Message seems published successfully, but not subscribed by the
>> Message receiver.
>> H
On 14.05.2014 11:14, Activecat wrote:
Both blocks (message sender block, message receiver block) are source
blocks, both are directly connected to the inputs of a divider blocks,
i.e. the message receiver block is not at the downstream of the message
sender block. I guess this is ok because Mess
Hi Martin,
Yes you're right, 75000 items isn't so large! But after passing these items
through an encoder, the number of items becomes about 227000!! That's a big
number!
However, I skewed over the problem and till now I've reached to this point
that I may use 3 or 4 inputs-ouputs ports per block
It's better to say in this way: *how could I use stop(), start(), lock(),
unlock() of the topblock methods? Is there any example of them?*
Thanks,
On Wed, May 14, 2014 at 1:20 PM, Martin Braun wrote:
> On 13.05.2014 15:56, Mostafa Alizadeh wrote:
>
>> Thank you martin,
>>
>> I saw examples bef
On Wed, May 14, 2014 at 5:26 PM, Martin Braun wrote:
> There's no msg_connect() call here -- that would be your problem.
> M
>
I build the flowgraph using GRC. How to make correction?
The complete top_block.py is as follows.
#!/usr/bin/env python
#
Hi,
>> There's no msg_connect() call here -- that would be your problem.
>> M
>
>
> I build the flowgraph using GRC. How to make correction?
> The complete top_block.py is as follows.
Did you define the message port in the .grc XML file for your blocks ?
Something like :
portname
mes
I try to get B200 to work with OpenBTS and I see some frequency offset in the
internal reference clock.
Does anyone know if the numbers I get from kalibrate, could cause phones not to
be able to register to OpenBTS?
What is the quickest and the cheapest way fix a problem with a clock? I
think B2
On 14.05.2014 11:35, Activecat wrote:
On Wed, May 14, 2014 at 5:26 PM, Martin Braun mailto:martin.br...@ettus.com>> wrote:
There's no msg_connect() call here -- that would be your problem.
M
I build the flowgraph using GRC. How to make correction?
To correct this, connect the messag
On 14.05.2014 12:12, Robert Light wrote:
I try to get B200 to work with OpenBTS and I see some frequency offset in the
internal reference clock.
Does anyone know if the numbers I get from kalibrate, could cause phones not to
be able to register to OpenBTS?
What is the quickest and the cheapes
On Wed, May 14, 2014 at 5:50 PM, Sylvain Munaut <246...@gmail.com> wrote:
> Did you define the message port in the .grc XML file for your blocks ?
>
> Something like :
>
>
> portname
> message
> 1
>
>
> Then they should show as message port in the GRC UI and you need to
> connect
On Wed, May 14, 2014 at 6:18 PM, Activecat wrote:
>
> On Wed, May 14, 2014 at 5:50 PM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> Did you define the message port in the .grc XML file for your blocks ?
>> Something like :
>>
>>
>> portname
>> message
>> 1
>>
>>
>> Then they sh
On 05/14/2014 12:29 PM, Activecat wrote:
> I have then tested few combinations, it seems that a source block cannot
> have a message sink port.
> Is there such a restriction ..?
Not that I know of...
Test
message_sink_complex_source_test
Custom
None
in
message
True
On Wed, May 14, 2014 at 6:49 PM, Koslowski, Sebastian (CEL) <
sebastian.koslow...@kit.edu> wrote:
> On 05/14/2014 12:29 PM, Activecat wrote:
> > I have then tested few combinations, it seems that a source block cannot
> > have a message sink port.
> > Is there such a restriction ..?
>
> Not that I
Hi,
> I
> think B200 has TCVCXO, so is there a way to write some tuning voltage offset
> to
> correct the frequency?
There is no way to trim the TCVCXO manually. It's included in the loop
of a PLL for external locking but you can't control it directly.
It seems that manual control was consider
On Mon, May 12, 2014 at 2:45 AM, Mostafa Alizadeh wrote:
> Hi Nemanja,
>
> I think the best possible way is to connect the trigger to the block as a
> message. To to that, you need to write a file_sink block for yourself
> again, for instance named my_file_sink.
>
The main drawback to the message
On Wed, May 14, 2014 at 7:06 AM, Activecat wrote:
>
> On Wed, May 14, 2014 at 6:49 PM, Koslowski, Sebastian (CEL) <
> sebastian.koslow...@kit.edu> wrote:
>
>> On 05/14/2014 12:29 PM, Activecat wrote:
>> > I have then tested few combinations, it seems that a source block cannot
>> > have a message
On Tue, May 13, 2014 at 11:11 AM, Irfan Ullah wrote:
> Hi all,
>
> I have a problem here with polyphase clock synchronization block when i
> set the output samples per symbol to one the constellation have much more
> ISI and noise and when output sps value is 2 the constellation have no
> noise an
On Wed, May 14, 2014 at 6:16 AM, Martin Braun wrote:
> On 14.05.2014 12:12, Robert Light wrote:
>> UHD Warning:
>> The hardware does not support the requested RX sample rate:
>> Target sample rate: 0.270833 MSps
>> Actual sample rate: 0.271186 MSps
>
> Robert,
>
> as long as you see this w
On 05/14/2014 11:44 AM, Tom Tsou wrote:
On Wed, May 14, 2014 at 6:16 AM, Martin Braun wrote:
On 14.05.2014 12:12, Robert Light wrote:
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.270833 MSps
Actual sample rate: 0.271186 MSps
Robert
> 2 kHz offset is within tolerance for 1900 MHz. Locking to a stable 10
> MHz reference, generally an OCXO or GPSDO, is the recommended
> approach.
I applied external 10MHz reference, the best I had at hand.
Now kalibrate says I have about 200Hz offset at 900MHz and 420Hz at 1800MHz,
but phones
Hi,
Thanks Mr. Economos and Mr. Braun,
I left this parameter in blank (I guess this is the same as an empty
string), it seems that it is working now.
Actually I am trying to modulate ISDB-T data stream. I am working with
vectors, instead of data stream.
Thanks again.
2014-05-14 5:28 GMT-03:00
On 05/14/2014 01:12 PM, Robert Light wrote:
2 kHz offset is within tolerance for 1900 MHz. Locking to a stable 10
MHz reference, generally an OCXO or GPSDO, is the recommended
approach.
I applied external 10MHz reference, the best I had at hand.
Now kalibrate says I have about 200Hz offset at 90
Hi all,
It's been a while since we've had a VOLK working group call, and I
think there's some things worth discussing that have built up. If
you're interested in attending put in available hours here:
http://whenisgood.net/gnuradio/volk/june14
In the next day or two when I see results from the us
If you haven't already, you may want to take a look
at this GnuRadio DVB-T implementation.
https://github.com/BogdanDIA/gr-dvbt
Ron
On 5/14/2014 1:50 PM, Yuri P.M wrote:
Hi,
Thanks Mr. Economos and Mr. Braun,
I left this parameter in blank (I guess this is the same as an empty
string), it s
Hi Marcus,
what do you mean by *"run to completion" *?
best,
Mostafa
On Thu, May 15, 2014 at 10:40 AM, Mostafa Alizadeh
wrote:
> Hi Martin,
> Thank you so much, :)
> The last example you mentioned, gr-uhd/examples/c++/tags_demo.*cc*, this
> will help me!!
> It's interesting example.
>
> Thank
Hi Martin,
I finally found the solution. I the method *set_align(int ), * to tell the
scheduler output is multiple of a number but this is different than
set_output_multiple(int ). The set_align will decrease the amount of buffer
if the output number of items is less than the actual number of writt
34 matches
Mail list logo