> The problem I am having right now is that the timing information is not
> matching up to the signal I am inputting to the PPS port. I started off
> with inputting a signal that has an IPP of 1ms, but each PPS Trigger output
> incremented in values of 5ms. I made additional changes to the input
I managed to get gr-rds built tonight, and was able to test it planted
inside my FM receiver.
Even for a local station, there are *lots* of errors, and more distant
stations get even more.
I'm going to play around a bit with filter bandwidths, etc, to see if
I can improve it.
Looking at the mod
On Thu, Feb 23, 2012 at 6:08 PM, Nowlan, Sean
wrote:
> Hi Tom,
>
> ** **
>
> I tested with your merged branch. No segfault and same tests fail as
> expected.
>
> ** **
>
> I noticed several weird numbers in the orc results. Some of them
> correspond to the failed cases. Do you know what i
Hi Tom,
I tested with your merged branch. No segfault and same tests fail as expected.
I noticed several weird numbers in the orc results. Some of them correspond to
the failed cases. Do you know what is causing these? Printf formatting issue?
Hitting bounds of float type and wrapping around? R
The problem with many of these types of appliances is that they include
MODEM functions inside the module. For use with a USRP, you will need to
dissect them to get to the physical interface to the powerline.
_
From: discuss-gnuradio-bounces+evan=syndetix@gnu.org
[mailto:discuss-g
Oooh, yeah. I forgot about X10!
I once used an X10 control system
to turn a stirrer on and off under program control for an
electrochemical cell I was running for a month. Long story, unrelated to
Gnu Radio :-)
On Thu, 23 Feb 2012 08:59:06 -0800, Hugh and Irene Pett
wrote:
> Hi George,
>
Hi George,
The problem of connecting electronics cheaply to house wiring was
implemented maybe 20 years ago in the X10 system, in which simple
controllers would turn lights etc. on and off. There are inexpensive
computer interfaces as well. Here is just one example of the sort of
device th
On Tue, Feb 21, 2012 at 10:48 AM, Ryan Pape wrote:
>
>
> On Mon, Feb 20, 2012 at 10:28 AM, Tom Rondeau wrote:
>
>> On Sun, Feb 19, 2012 at 6:29 PM, Ryan Pape wrote:
>>
>>> I have an application with some nasty race conditions I am trying to
>>> pin-point.
>>>
>>> The application starts with a
i think i install all correkt, i use the digital blocks in my flow graphs and
the run also in Grc but with the problem i described
--
View this message in context:
http://old.nabble.com/GRC%3A-Problem-with-workspace-tp33352651p33379085.html
Sent from the GnuRadio mailing list archive at Nabbl
The audio for the GNU Radio Conference 2011 is now available:
http://www.trondeau.com/grc2011-abstracts
I think I'm still missing one presentation but working on getting my hands
on it.
I was hoping to listen to all of the audio to make sure they were all ok,
but I realized that I'm never going t
On Wed, Feb 22, 2012 at 10:19 PM, Nowlan, Sean
wrote:
> I confirmed this works on E100 insofar as I no longer get a segfault on
> volk_32fc_s32fc_multiple_32fc_a. But volk_32fc_s32f_magnitude_16i_a and
> volk_32fc_x2_multiply_32fc_a still fail as expected.
>
> ** **
>
> Sean
>
Sean,
I just
On Thu, Feb 23, 2012 at 10:57 AM, larst wrote:
>
> hi,
>
> i figure it out ... it happens cause an invalid import tag in the wrapper
> file.
>
> in my case i want to import >> from gnuradio import digital
> the module exist but i dont know why, Grc force this kind of Problem.
>
> should i do some
hi,
i figure it out ... it happens cause an invalid import tag in the wrapper
file.
in my case i want to import >> from gnuradio import digital
the module exist but i dont know why, Grc force this kind of Problem.
should i do something to register this module for Grc?
regards lars
--
View t
2012/2/23 Wu Ting
> Hi! Thank you for your response. I've kept working on this problem for two
> days, but still cannot find a way to solve it.
>
> I simplified the program and have determined that the 'O' is produced is
> this while loop:
>
> while msgCount<1:
>msg = tb.queue.delete_head
As I said, your system is not processing the samples fast enough and a
buffer overflows and samples are lost. You say it happends durring that
loop, that might use enough CPU time to cause these problems. Your options
are to get a faster system, sample at a lower rate or find a way to make
your cod
On Thu, Feb 23, 2012 at 4:39 AM, Sebastian Döring
wrote:
> Hello,
>
> in the context of spectrum sensing in the 2.4 GHz band using a modified
> version of the usrp_spectrum_sense.py script, I am having problems with
> high latency times.
> Since the time for recording samples and all the tuning st
>
>
>
> Maybe something a little more accessible from MAXIM:
>
> http://www.maxim-ic.com/products/powerline/
>
> They have an evaluation kit which might have some testpoints to
> connect up to a USRP, or try to ship off samples through their 10/100
> ethernet interface.
>
>
Thanks, Brian!
I will
Hi, thanks for the hints!
I was thinking about the clock recovery too. Its pretty complicated in
there, but I keep trying.
I just discovered that the performance of sender and receiver also
depends on the interpacket times of the sender ...
(remember I mentioned before that the sender sen
Hmm,
there is a clock recovery block (gr.clock_recovery_mm_ff) that may lock to the
stronger signal. Maybe you can find a way to stop it from changing things after
you found an SFD, and turn it on again after the packet. I don't know what the
block is doing exactly, but changing its parameter
Hi,
Quote "you can modify the receiver to just continue receiving anyway"
This is already done within the packet_sink by saying
if (min_threshold < d_threshold or true)
hence as soon as the receiver got into the decode_chips loop, it
should stay there! ((c == 0xff) should never hapen!)
cou
Hi,
you should check out ucla_ieee802_15_4_packet_sink.cc, the receiver checks if a
valid chipping sequence for a payload symbol was found (after synch), and
starts searching for a new SFD in case there is no possibly matching symbol.
...
unsigned char c = decode_chips(d_shift_reg);
if(c == 0x
Hi Matthias,
Thanks a lot for your suggestions.
The thing is, one transmitter (jammer) is sending packets nonstop at a
constant transmit power, while the second transmitter (sender) sends a
packet every millisecond or so.
In this scenario, the receiver is always synchronized with the jamme
Hi! Thank you for your response. I've kept working on this problem for two
days, but still cannot find a way to solve it.
I simplified the program and have determined that the 'O' is produced is
this while loop:
while msgCount<1:
msg = tb.queue.delete_head()
payload = msg.to_string()
Hi Bjoern,
the receiver uses FM demodulation to track phase changes, and when two signals
collide the stronger one simply has the larger influence on the overall phase.
This is actually a good property, because you still have the chance to receive
one of the colliding packets.
Do you want to
Hello,
in the context of spectrum sensing in the 2.4 GHz band
using a modified version of the usrp_spectrum_sense.py
script, I am having problems with high latency times.
Since the time for recording samples and all the tuning
stuff is supposed to be much less than what I am currently
dealing
25 matches
Mail list logo
