--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I have a question regarding a few lines in qa_atsc.py .
In test_loopback_000, we have:
src = vector_source_ts(src_data)
rand = atsc.randomizer()
and skipping a few lines:
self.tb.connect(src, rand, derand, dst)
The definition of vector_source_ts:
class vector_source_ts(gr.hier_block2):
"""
MPEG Transport stream source for testing.
"""
def __init__(self, ts):
"""
Pad tranport stream packets to 256 bytes and reformat appropriately.
@param ts: MPEG transport stream.
@type ts: sequence of ints in [0,255]; len(ts) % 188 == 0
"""
src = gr.vector_source_b(pad_transport_stream(ts))
s2v = gr.stream_to_vector(gr.sizeof_char,
atsc.sizeof_atsc_mpeg_packet)
gr.hier_block2.__init__(self, "vector_source_ts",
gr.io_signature(0, 0, 0),
s2v.output_signature())
self.connect(src, s2v, self)
=================================
It is clear that in "src = vector_source_ts(src_data)",
src_data is a tuple of integers, and src is a gnuradio_vector datatype
with elements guradio_characters and each vector length is
atsc.sizeof_atsc_mpeg_packet
That is, "src = vector_source_ts(src_data)" does *not* create any
atsc_mpeg_packet type data, as required by atsc_randomizer.
In other words, I am claiming that in test_loopback_000() of qa_atsc.py,
the input to atsc.randomizer() is *not* atsc_mpeg_packet, but rather a
gnuradio_vector data type. Notice that no special atsc.pad() is being run
(which converts a gnuradio_vector/stream(?) into an atsc_mpeg_packet).
I originally believed some casting was being done, but atsc_mpeg_packet is
not easy to convert to and fro, it contains numerous data arrays, and
variables.
Can someone please explain the input/output datatypes in
test_loopback_000() in qa_atsc.py?
Thanks very much,
Jonathan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
From 3 of my machines, it works, and from my lowly Pentium-D eMachines
Intel Mobo machine,
it fails. I wonder if perhaps the display hardware is missing some
vital capability that GL requires,
and rather than it failing gracefully, it drops a load of poop on its
shoes.
So 3 out of 4 machines work just fine--they're all running F12 and
up-to-date. But the 3rd one,
the eMachines one, seems to provoke a core dump in the app if the app
is being *displayed* on that
machine--note that the app is *running* on the same machine in all cases.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Performance is one thing, but dumpething of the core is quite another.
Interestingly enough,
GRC works over an X11-over-SSH connection, and I thought it used the
GL rendering.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> I have not yet seen any problems tuning the USRP in nongl mode (using
> F9 I was able to control the USRP without worrying about OpenGl
> remotely).
>
> Crypted stuff sure will slow down (like SSH),
> Patrik
>
Encryption slows things down only a tiny little bit these days, even on
"whimpy" things like
the Atom series CPUs.
>
>
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
We seem to have the same system setup.
Can you give us a screenshots using nongl and gl that isnt rendered
properly, I'm interested to see if I can replicate it
I have not yet seen any problems tuning the USRP in nongl mode (using F9 I
was able to control the USRP without worrying about OpenGl remotely).
Crypted stuff sure will slow down (like SSH),
Patrik
----- Original Message -----
From: "Marcus D. Leech" <mleech@ripnet.com>
To: <Discuss-gnuradio@gnu.org>
Sent: Saturday, July 31, 2010 21:12
Subject: [Discuss-gnuradio] OpenGL GUI bits and ssh and segmentation faults
> It seems that when I try to run a GUI-based Gnu Radio app across an SSH
> connection
> (using ssh -X), it provokes a fairly rapid segmentation fault and
> dies. Doesn't seem to
> matter whether it's my own app, or a "standard" one like usrp2_fft.py.
>
> If I switch to using "nongl", it doesn't segfault, but the scope sink
> isn't rendered properly in that
> case :-(
>
> This is on a Fedora 12 system, totally up-to-date, with Gnu Radio GIT
> from July 30th, 2010. It's
> a 32-bit Atom D512 system with 4G of memory.
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 07/31/2010 11:12 AM, Marcus D. Leech wrote:
> It seems that when I try to run a GUI-based Gnu Radio app across an SSH
> connection
> (using ssh -X), it provokes a fairly rapid segmentation fault and
> dies. Doesn't seem to
> matter whether it's my own app, or a "standard" one like usrp2_fft.py.
>
> If I switch to using "nongl", it doesn't segfault, but the scope sink
> isn't rendered properly in that
> case :-(
>
> This is on a Fedora 12 system, totally up-to-date, with Gnu Radio GIT
> from July 30th, 2010. It's
> a 32-bit Atom D512 system with 4G of memory.
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
If I switch to using "nongl", it doesn't segfault, but the scope sink
isn't rendered properly in that
case :-(
This is on a Fedora 12 system, totally up-to-date, with Gnu Radio GIT
from July 30th, 2010. It's
a 32-bit Atom D512 system with 4G of memory.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
An external python script, via xmlrpc, operates the "switched" variable
that switches the
flow between the "reference" branch and the live data branch.
Switching occurs with a 50%
duty cycle.
What I discovered is that after only a few seconds of switching, I get
errors from USRP2:
usrp2: channel 0 not receiving
rx_samples() failed
Initially, I thought that perhaps it was XMLRPC interfering somehow, so
I replaced the switching
control with a manual GUI "check box" control. Again, after manually
switching after a few seconds,
I get the above errors.
The bandwidth is quite modest--250KHz, and the variable sink gets a
filtered/decimated version of
the data flow, so the requisite "python guts" are only being called
occasionally, relative to the
data rates.
So, I switched (no pun intended, tee hee) to a different approach
entirely, and that is working fine.
No "valves", and no variable sinks. Instead, the input stream is
multiplied either by 1 or -1,
depending on the value of the "switched" variable, and this is then
low-pass filtered via a
single-pole IIR filter. That works as you'd expect--the switching
hardware isn't in place yet, so
it's presenting alternately the "normal" and "negated" versions of the
input data to the IIR filter,
which is, as you would expect, converged to near zero.
There are a plethora of approaches to this problem (a switched
radiometer), but I was disappointed
that my first try not only didn't work, but seemed to exercise some
kind of weird bug in Gnu Radio.
I'm running the "as of late last night (July 30th, 2010)" GIT of Gnu
Radio, if that matters.
I wasn't able to determine whether it was the valves provoking the usrp2
receive errors, or the
variable sink, and it seems to be related to the branch that
terminates in the variable sink--if I
never activate the "switch" so that the data always goes down the
"normal" path, the flow-graph
just runs and runs normally forever.
!Cheers
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
True is not in the list of options, and the type is int.
$option() == 1
-Josh
> <option>
> <name>First Order</name>
> <key>1</key>
> </option>
> <option>
> <name>Second Order</name>
> <key>2</key>
> </option>
> <option>
> <name>Third Order</name>
> <key>3</key>
> </option>
>
>
> <name>N</name>
> <key>N</key>
> <value>4</value>
> <type>int</type>
>
> (for some reason the param and /param tags may be hidden in my message)
>
> So I mean I want to display the equation order on the block and hide N.
>
> Any workarounds, please?
>
> Cheers,
>
> Zohair
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I am writing some blocks and I need help in XML file.
1- I have a drop down menu and I want the chosen option to be displayed on
the block.
2- I have an integer parameter that is by default displayed on the block but
I want to hide it.
In my current file I wrote:
<name>Equation</name>
<key>option</key>
<value>1</value>
<type>int</type>
<hide>#if $option() == 'True' then 'none' else 'part'#</hide>
<option>
<name>First Order</name>
<key>1</key>
</option>
<option>
<name>Second Order</name>
<key>2</key>
</option>
<option>
<name>Third Order</name>
<key>3</key>
</option>
<name>N</name>
<key>N</key>
<value>4</value>
<type>int</type>
(for some reason the param and /param tags may be hidden in my message)
So I mean I want to display the equation order on the block and hide N.
Any workarounds, please?
Cheers,
Zohair
--
View this message in context: http://old.nabble.com/Display-Hide-parameters-from-an-XML-Files-tp29313876p29313876.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I use the 25MHz sample-rate to test algorithms. In one application I
transmit during 0.1ms and then use 10ms to process the data. This is for
doing research on algorithms. It's still different from pure off-line
processing as I can do feedback, MAC-algorithms and so on.
I would actually like to have more than 25MHz maybe 100MHz to be able to
work with bandwidths such as 40MHz.
BR/
Per
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi,
I am unfamiliar with Octave, so I cannot be sure about your particular
scenario, but a potential problem could be internal buffering between
writes... Maybe try flushing the stream more?
Thanks,
~Jeff
--
~Jeffrey Lambert, K1VZX
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Their infinite resources are in fact limited by their management's mindset and inability to think clearly about the
consequences of their business model, the impact of the Internet, etc. A guy like Ballmer is just a much a reason why
Linux exists as is Linus himself. His rhetoric about GPL being a cancer, Linux developers are communists, etc. has
provided "infinite inspiration" to the guys with limited resources.
SORA may be a useful data point, but advise to carefully consider the source.
-Jeff
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I think that should be thought of as a lower bound not an upper bound :).
They accomplished their goal of handling dot11g and haven't (that I'm
aware of) moved on to anything harder (yet).
Aside: reading the paper doesn't come with any licensing terms, and
there's even ASM code in the appendix for a SIMD-enabled FIR filter at the
end.
Dan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
There may be data format conversion happening. What data types are you
using?
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I'm calibrating my USRP setup using a function generator. I remember
seeing that someone else had done this before in the past and written down
a bunch of (input voltage, ADC output) pairs on the web somewhere, but I'm
unable to find it on the wiki even with google site: search.
Does anyone have a pointer?
Thanks,
Dan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The IRA code does a number of things
o compute total power over the entire bandwidth
o compute an FFT with 1Hz resolution (that's a 16 million point FFT)
o do a SETI analysis of the resulting FFT
o do a transient signal analysis of the total power data
o run a narrowband interference filter based on an FFT filter
o run a GUI with lots of bells 'n whistles
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I don't think you need to read the license carefully to realize you do
not want to download the code.
1) No commercial use clause.
2) You cannot distribute derived works.
3) You grant MS the right to use your modifications to the code.
Even if you are in an academic situation, you need to think about your
future in the commercial space before looking at the code.
Philip
>
> http://research.microsoft.com/en-us/projects/sora/
>
> and the original paper:
>
> http://research.microsoft.com/apps/pubs/default.aspx?id=79927
>
> Dan
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
For 'speed record' type information, you might be interested in SORA, a
software radio project from Microsoft Research. They use different
hardware and custom software, but the fundamentals are the same.
As Matt points out, efficiency is a function of engineering. Using modern
processors, 64-bit architecture, multicore, software LUTs, and a variety
of other optimizations they were able to fully process 802.11g signals of
20 MHz bandwidth and sustain reception of 54 Mbps signals including
Viterbi decoding, etc. I see no reason this couldn't be done with
USRP(2) / GNU Radio... but looking at Microsoft's author list they had a
lot of developers working pretty hard on it!
There's not a ton of detail in the original paper, and what code is
available is almost certainly not something you want to look at without
reading the license very carefully, but here's the link to the project
website:
http://research.microsoft.com/en-us/projects/sora/
and the original paper:
http://research.microsoft.com/apps/pubs/default.aspx?id=79927
Dan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s
recording to disk. With 4 and 6 core systems and the i7 architecture
you can get more than 5X the performance of your laptop.
There are a lot of applications using the full 25 MHz of RF bandwidth.
You just need to pay a lot of attention to efficiency of your program
and algorithms.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
For reference I have a ~2.4 GHz core 2 duo laptop. For a 200 kHz FM demodulator I consume about 40% of one cpu. That's pretty much the simplest useful thing anyone can do so that maps to my laptop might be able to process 1 MHz bandwidth continuously.
Similarly, my hard drive can't really keep up with 32 Mbyte/s recording. So if samples are 16-bit and you really can't afford lost data it seems like recording is limited to maybe 10 MHz or so bandwidth.
However, with gigabit Ethernet you can send 100 Mbyte/s or more. What's the most anyone has recorded or processed continuously? What level of compexity was the processing?
Thanks,
Clark
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I am unfamiliar with Octave, so I cannot be sure about your particular
scenario, but a potential problem could be internal buffering between
writes... Maybe try flushing the stream more?
Kunal
On Fri, Jul 30, 2010 at 11:09 AM, George Nychis <gnychis@gmail.com> wrote:
> Hi all,
>
> Has anyone had any luck achieving high throughput (e.g., supporting
> interpolation of 8 or 16 with USRP2) from Octave to a GNU Radio flowgraph?
> I am trying to stream a signal to my GR flowgraph, and at first I tried
> sockets but then realized it was way too slow, and so I moved to pipes but I
> am also finding it cannot keep up.
>
> I have tried writing/reading in larger blocks, such as using an fwrite() in
> Octave of size 20480, and then attempting a larger read within GNU Radio
> using a gr.file_source(20480,'/tmp/mypipe') and then converting it to a
> stream for the USRP2 with gr.vector_to_stream(gr.sizeof_gr_complex,20480).
> But alas, still no luck... I am under-running like crazy from the looks of
> my spectrum.
>
> Has anyone had any better luck?
>
> Thanks!
> George
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I think that simply depends on gr-usrp due to the usrp_*.py scripts. It
should work once usrp is up and running, it doesn't have much stuff of
it's own.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
I don't know if this'll work without any modifications to
usrp_rx_cfile.py, but of course you can simply use a named pipe as file.
Your other process could read this file in the same manner.
Note that you must kind of sync the process initialisations, since named
pipes won't return from an 'open()' call until the other end was opened,
too.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
Eric Blossom wrote:
>
> On Sun, Jul 25, 2010 at 07:50:10PM -0700, tonygc wrote:
>>
>> thank you for your reply, Eric! our team plans to integrate USRP with
>> other
>> functions, so we first want to copy the USRP motherboard to convince our
>> PCB
>> design. PCB has been tested, all is ok. after finishing the soldering,
>> first
>> load the firmware of FX2(with build_eeprom.py), then LEDs blinks. the
>> daughterboard can be detected by Probe. but can't receive any signals,
>> neither transmitting... is there something we omit? in addition, how to
>> test
>> whether FPGA image is loaded into FPGA?
>
> There could be any number of things that you have omitted...
>
> Either you, or somebody on your team will have to really understand
> what is going on, how code is loaded into the FX2, how the fpga image
> is loaded, etc, or you will have no hope of debugging this.
>
> Once you have an understanding of what you expect to happen, then you
> can look to see if it's happening. If it is, good, go on to the next
> thing. If it isn't, then figure out why what you expect to be
> happening isn't happening.
>
>
> Suggested reading:
>
> USB 2.0 Specification
> FX2 Technical Reference Manual
> The USRP schematics
> The source code for the FX2: usrp/firmware/*
> The source code for usrp/host/apps/usrper.cc
> The source code in usrp/host/*
> Datasheets for all parts on the board
> The FPGA source code
>
> Eric
>
>
>
>> Eric Blossom wrote:
>> >
>> > On Wed, Jul 21, 2010 at 08:48:46PM -0700, tonygc wrote:
>> >>
>> >> who can tell me the reason? any help will be appreciated...
>> >
>> > Bringing up new hardware (even if you think it's a perfect copy of
>> > somebody else's design) is always a challenge. It requires a wide
>> > range of skills, patience, test equipment and the ability to figure
>> > out how to debug a problem.
>> >
>> > Most people I know learned these skills by working side-by-side at a
>> > bench with people who had more experience than they did, both looking
>> > at the same board...
>> >
>> > A couple of things to check:
>> >
>> > Are the power supplies as expected?
>> > Do the clocks look good?
>> > Can you load code into the FX2?
>> > Can you load an FPGA image into the FPGA?
>> > ...
>> >
>> > Good luck!
>> > Eric
>> >
>> >
>> >
>> >> tonygc wrote:
>> >> >
>> >> > although there's no PCB of USRP motherboard, i make the PCB by
>> myself.
>> >> > there's no change of the motherboard, according to the schs. after
>> >> > finishing the PCB and all components soldering, i burn the eeprom of
>> >> the
>> >> > motherboard by /gnuradio/usrp/firmware/src/usrp2/burn-usrp4-eeprom.
>> >> > finally, its leds blinks. that's a small success for me. when i plug
>> in
>> >> > the rfx400 and run benchmark_tx.py, there's a sign that it's working
>> >> > because it displays it's transmitting signals with
>> >> > .......................... unfortunately, the receiver receives
>> >> nothing...
>> >> > then i use the probe to detect whether USRP works, and the probe
>> >> displays
>> >> > that it can detect the USRP and the daughterboard. it's the same as
>> the
>> >> > board bought from Ettus. i'm confused. the daughterboard is also ok
>> on
>> >> > the USRP motherboard bought from Ettus.
>> >> > anyone can help me? i don't know how to deal with this problem...
>> thank
>> >> > you for your help!
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context: http://old.nabble.com/some-problems-about-usrp-motherboard-that-i-make-by-myself-tp29225435p29303365.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
| Hello, I have acoustic modem which uses ALSA source as interface to outside world. I use a preamble based time synchronization technique to find start of data in the frame. But my synchronization method is taking too long and in the process i think i am loosing incoming samples from ALSA source. Is there a way to buffer samples from ALSA source , until i finish synchronization. Please provide me some suggestions. Thanks in advance, Ram |
1. Sending 2 input signals parallel to USRP:
My idea is:
- Sending these 2 Signals in 2 separate daughter-boards LFRX
- (Or) Put them two on only one LFRX through the 2 SMA connectors.
- How about using digital I/O pins ?
- What is the maximum voltage can I feed the daughter-board through SMA ?
- Will the inputs be synchronously sent and sampled ?
Zero-crossings detection:
- How can I find out the zero-crossing time, esp. of the signal S2 ?
Thanks in advance for your reply.
--
View this message in context: http://old.nabble.com/Multiple-inputs-on-LFRX---phase-difference-and-zero-crossings-detection-tp29300504p29300504.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
1. Sending 2 input signals parallel to USRP:
My idea is:
- Sending these 2 Signals in 2 separate daughter-boards LFRX
- (Or) Put them two on only one LFRX through the 2 SMA connectors.
- How about using digital I/O pins ?
- What is the maximum voltage can I feed the daughter-board through SMA ?
- Will the inputs be synchronously sent and sampled ?
2. Zero-crossings detection:
- How can I find out the zero-crossing time, esp. of the signal S2 ?
Thanks in advance for your reply.
--
View this message in context: http://old.nabble.com/Multiple-inputs-on-LFRX---phase-difference-and-zero-crossings-detection-tp29300504p29300504.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Jul 22, 2010 at 07:40:29PM -0700, Eric Blossom wrote:
> On Thu, Jul 22, 2010 at 10:18:41PM -0400, alfayez@aol.com wrote:
>
> > I think I'm running into some scheduler issues in GNU Radio that I
> > don't really understand. I've been working on running GNU Radio
> > blocks on the Beagleboard's DSP by writing new DSP specific custom
> > signal processing blocks When I run simple QA python test scripts
> > everything works fine.
>
Sorry, I should have mentioned this earlier.
Try enabling the scheduler logging by
#define ENABLE_LOGGING 1
In gr_block_executor.cc, line 38.
This will create a separate ascii log file for each block.
They'll be created in the current directory and have names
"sst-%3d.log", where the numbers are unique. The log files contain
the name of the block as the first line.
Good luck, and let us know what you find out!
Eric
You don't really need to post twice.
You can grep through the output of configure for "skipping" or
something similar and see what failed. It's usually pretty
descriptive what it can't find.
Brian
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
