GUI checkbox with a default value set to bool(lo_locked).
> When you run your flowgraph, the checkbox will indicate
> whether the LO is locked.
>
> In your own non-GRC application you can use name>.get_dboard_sensor("lo_locked", 0) to check the status of the
> daug
> > Hi,
> >
> > While I was testing the DQPSK-(de)modulation blocks in GRC.
> I found a frequency region where the reception failed. I
> started with the ISM-band (433 MHz) as the center frequency,
> and the reception didn't work. After checking my code several
> times I decided to change the c
Hi,
While I was testing the DQPSK-(de)modulation blocks in GRC. I found a frequency
region where the reception failed. I started with the ISM-band (433 MHz) as the
center frequency, and the reception didn't work. After checking my code several
times I decided to change the center frequency to 2
> My conclusion from these small tests is that the
> ERROR_CODE_TIMEOUT occurs when the USRP2s are synchronized. I
> don't see the reason why it works with the HEAD block and not
> without it. Do you have any clue? I attach my test file for
> testcase 2.
We have done some more tests and found
Hi Josh,
> Can you try this diff, I think it solves the problem if my
> hunch above is correct: http://pastebin.com/zMCP6LHh
Thanks four your reply!
I've tried this patch and I don't get the error anymore, but my application
still doesn't work though. It seems that the UHD-source doesn't produc
Hi,
After I stop a top_block, is it possible to create a new top_block and start it
without exiting my python application?
My experience is that it doesn't work very well. I get the following error when
I instantiate a new top_block and start it.
"UHD source block got error code 0x1
gr_block_ex
On Thu, Mar 24, 2011 at 6:29 AM, Patrik Eliardsson
mailto:patrik.eliards...@foi.se>> wrote:
Hi,
I've tried the new stream tags and like them, but when I've a block in my
flowgraph that change the stream rate I'm not sure how the absolute sample
number is calculated.
C
. My default setting was TPP_ALL_TO_ALL. When I changed it to
TPP_ONE_TO_ONE I got the following error "gr_block_executor: propagation_policy
'ONE_TO_ONE' requires ninputs == noutputs", I tested it on the flowgraph above.
With the TPP_ONE_TO_ONE policy, shouldn't the tags only
> > It would be really nice if the send-function in the API have a TDMA
> > mode where fragments of samples are dropped when an underrun occur so
> > that the majority of the samples are aligned to the
> > start_of_burst_time (see above example (1) and (3)). With this feature
> > it is not ne
> > Underflows occur on transmit, nothing can drop because this is a lack
> > of samples.
That's true! But I don't want the rest of the samples to be delayed due to the
underrun.
>
> If I understand correctly, the transmit situation that Patrik
> describes is behaviour _after_ the underflow. F
> -Original Message-
> From: thomast...@gmail.com [mailto:thomast...@gmail.com] On
> Behalf Of Thomas Tsou
> Sent: Thursday, December 09, 2010 6:44 PM
> To: Patrik Eliardsson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Expected behavior during
Dear list,
What is the expected behavior when we get underruns with the UHD and the flow
control using the USRP2?
1) When we get underruns, does the usrp2 send some random samples until the
host computer manage to feed the usrp2 and then starts to consume the 'old'
samples from the host comput
Thanks for all your replies!
We did some additional experiments where we divided our program into 2 phases.
In phase 1 we did all the initialization like setting rx rate, center
frequency, gain, synchronizing to ref clock, and finally issued a stream
command to receive samples. The received sam
and the interface in the *_path files so it fits
your configuration.
Does anyone have a clue?
br,
Patrik
Från: discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org
[discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org] för Patrik
Eliards
ith the following sequence:
top_block.lock()
top_block.disconnect()
top_block.connect()
top_block.unlock()
The error occurs after a random number of switches of the different paths
(sometimes it works for 30 switches and sometimes just for 3) and the program
requires a restart to get rid of
Dear List,
We are heading to the end of February, what is the status of the message
passing functionality between blocks? I've been looking around in the
developers branches but haven't found anything yet...
Can someone update me, please?
Best regards,
Patrik Eliardsson
>
etween the transmitter and the
receiver? Depending on your surrounding environment you may have to tweak the
length of the CP.
I have the same configuration as you, but I have the RFX2400 instead of the
XCVR2450.
Regards,
Patrik Eliardsson
> -Original Message-
> From:
> discu
Thank you Eric!
We are glad that this is on your 'short list', we look forward to see the
results and try it out (assume the changes will happen in your branch?).
We are especially interested in synchronized message passing and the ability to
tweak parameters at runtime, perhaps even alter bloc
. However, if we don't want to wait too long, can
this be achieved with m-blocks at the moment? What functionality is missing in
the m-blocks? Or has anyone solved this in another way?
Regards,
Patrik Eliardsson
___
Discuss-gnuradio mailing
Hi,
Yes we have solved it but it is not perfect yet, probably due to jitter in
clocks, the threshold level at the 1PPS input and the quality of the 1PPS and
10MHz signals. The topic have also been touched here:
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-08/msg00173.htmlhttp://lists.
receiving the samples synchronous we then just polled the timestamp
and when we received a sample with timestamp = 0 we started our process.
-Patrik Eliardsson
Från: discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org
[mailto:discuss-gnuradio-bounces
Hi everyone,
Since we try to improve the ddc performance, (see
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-06/msg00075.html) I
have to simulate my modifications to the FPGA.
Is there any testbenches for the complete system? I've found single_u2_sim.v,
but when I simulate this file
We have already implemented start_streaming_at(0) (see attached file). The
problem is that the FPGA doesn't reset the ddc on PPS so the sample marked with
'time stamp' = 0 is delayed by an unknown fractional number of samples realtive
to the output rate.
regards
Patrik and Ulrika
23 matches
Mail list logo
