that have filed issues or directly
contributed to
UHD and meta-ettus. You contributions have helped the continued improvement of
UHD.
As always, please file issues to our GitHub repo [2], by posting in the
USRP-users mailing list, or
contacting supp...@ettus.com.
Thanks!
Steven
[1]
filed issues or directly
contributed to
UHD and meta-ettus. You contributions have helped the continued improvement of
UHD.
As always, please file issues to our GitHub repo [2], by posting in the
USRP-users mailing list, or
contacting supp...@ettus.com<mailto:supp...@ettus.com>.
Thanks!
Stev
records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00284394 s, 360 kB/s
should result in something such like:
sh-4.4$ ls -l fred
-rw-r--r-- 1 barbo barbo 1024 May 16 14:22 fred
On Mon, May 16, 2022 at 2:24 PM user 1 wrote:
> Hi Steven,
>
> Thank you for your suggestion,
Howdy Jeff.
What happens if you use /dev/urandom as file source?
On Mon, May 16, 2022 at 9:09 AM user 1 wrote:
> Hello Cinaed,
>
> Unfortunately scheme doesn't work, even with a bin file.
>
>
>
> jeff
>
>
> --
>
> Le 16/05/2022 à 12:06, Cinaed Simson a écrit :
> > Hi
Morning all (well, it's morning here anyway).
Using the QT GUI LED Indicator with Python 3.10
Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/gnuradio/qtgui/ledindicator.py",
line 123, in paintEvent
centerpoint = QPoint(center_x, center_y)
TypeError: arguments did
ings", "get",
> "org.gnome.desktop.interface", "gtk-theme"], 0x55652906a3d0 /* 75 vars */)
> = 0
> 6456 execve("/usr/bin/python3", ["/usr/bin/python3", "-uc", "import runpy;
> runpy.run_path('/u"...], 0x556
-introspection-1.70.0-1.fc35.x86_64
>
> I have GNU Radio 3.10 (actually 3.11 from master) and GNU Radio Companion
> running here without any problem, so perhaps you may just want to remove
> the older 1.69 version from your system, rebuild GNU Radio (or just GRC),
> and see if it
gt; while the other one is used at runtime when you run 'gnuradio-companion'?
>
> Franco
>
> On 02/08/2022 10:10 AM Steven Barbo via GNU Radio, the Free & Open-Source
> Toolkit for Software Radio wrote:
>
>
> Howdy Josh.
> Thank you for your reply, sorry i s
Hello all, hope this day finds you well.
Having issue with gnuradio-companion, GUI comes up briefly...
dmesg
[ 1341.843803] traps: gnuradio-compan[372] general protection fault
ip:7f81ca4f77c8 sp:7f81c7137010 error:0 in
libgirepository-1.0.so.1.0.0[7f81ca4ed000+2]
have compiled various gr ve
Hi JM.
Wow! Very helpful - thank you.
On Wed, Aug 11, 2021 at 11:53 AM wrote:
> I think I have been trying to address this topic in
> https://www.youtube.com/watch?v=M8dqgqO4TuI
> with complementing 0MQ streaming (target to host) with a TCP-server thread
> running next to the GNU Radio Python fl
This answer may not help but I will offer it up. You can sleep (pause) the
flow graph python script, change parameters such as frequency then run the
flow graph again. Note, in my set up I dumped the first few samples after
the change to clear the old data.
If someone else has a solution go with
Example?
> On 25 Jun 2020, at 18:55, Marcus Müller wrote:
>
> Such a thing exists: all blocks have a "system" message port!
>
>> On 25/06/2020 13.40, Steven Gillies wrote:
>> Thanks Kevin,
>> It's good to know what I am trying to do is possible
works fine in development, when I deploy it for
production (inside Docker container) the process will not terminate, and if I
try to join() then it hangs forever. To solve this I added a timeout and if the
process is still alive I kill it.
All in all a bit of a hack, but I've got to star
that I can manually free up resources from outside of the top_block,
for instance using the uhd library.
Im using GNU Radio 3.7, UHD 3.14 and the USRPs we use are Ettus UHD B210s.
Any help appreciated,
Steven
Hello.
Am using gnuradio 3.8 git (python 3.7.3) and have compiled gr-osmosdr to
work with that.
Having some issue translating from osmosdr_source.xml to
osmosdr_source_block.yml, the new yaml format
Anyone tackled this?
--
If something is requisite, how can it possibly be, prerequisite?
vanitas
the time commands that way.
Have a look at the source and you’ll see what can and cannot be accessed via
the command port.
good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Du bist die Aufgabe. Kein Schüler weit und breit. - Franz
need to let the test run for a short time and then stop
self.tb.start()
time.sleep(1)
self.tb.stop()
self.tb.wait()
if __name__ == '__main__':
gr_unittest.run(qa_random_sequenced_pdu, "qa_random_sequenced_pdu.xml")
Steven Knudsen, Ph.D., P.Eng
.
steven
> On Jan 12, 2017, at 09:11, Steven Knudsen wrote:
>
> Thanks very much, Marcus, for the help.
>
> As requested, I used
>
> self.tb.msg_connect((self.blocks_message_strobe_0,
> pmt.string_to_symbol('strobe')), (self.jitc_random_sequen
Last, I did try to follow the logic/code that tracks the registered ports
starting with gnuradio-runtime/lib/flowgraph.cc <http://flowgraph.cc/>, but I
became a bit lost as things moved through swig…
BTW, my GR version is 3.7.10.1
Again, thanks for your help!
steven
> On Jan 12, 201
ith my module. Is something not generated via/by swig maybe? I tried digging into gr-blocks to look for differences, but so far none that I can see.Sorry this is kind of long, but it’s a weird problem, weird because my stuff works fine in GRC!?!regards, and thanks,steven#!/usr/bin/env python2
# -*-
some references by searching online,
but nothing that has helped.
Thanks very much!
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Du bist die Aufgabe. Kein Schüler weit und breit. - Franz Kafka
___
Di
CE block.
The big flaw with my approach in 1) and 2) is that I am not accounting for
variable receive power such as you’d expect in a multi-radio TDMA system… first
things first, though, gotta see packets received reliably under Tx constant
power.
Steven Knudsen, Ph.D., P.Eng.
www
number
to the algorithm (the first is a multiplier of 4 in the peak thresholding
logic).
Thanks for your patience…
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt ist zu
erreichen
setting it
up correctly, but AFAIK the block parameters are the same.
Thanks for your consideration of this question,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
Correlation Estimator block to find the start of my
packet’s header. The demodulated header data was off by the group delay because
on the transmitter side various length tags used to form the packet were
offset. Sigh…
Thanks for any comments or help!
steven
[1]
http://gnuradio.org/redmine
; fingers crossed.
Thanks, again!
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
> Hi Steven,
>
> what you're witnessing is the automatic tag propagation that
.
Time to go write this up in my HOWTO wiki…
Thanks again!
steven
> Hi Steven,
>
> if you go to cgran.org, you'll find a bunch of OOTs that have external
> dependencies. gr-nacl depends on libsodium, for example. I recommend
> checking those CMake files for examples.
>
&g
,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend.
Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für
nichtig erklären, im Recht, denn es ist noch
.
I like singletons :-)
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
> On Apr 29, 2016, at 11:35, Tom Rondeau wrote:
>
> On Fri, Apr 29, 2016 at 12:24 PM, Steve
) is that maybe there is an issue with an
underlying library that is involved in output to stdout, maybe?
Again, everything works perfectly under Linux. GNU Radio on both Linux and OS X
is completely up-to-date.
I can live with this, but would like to know what may be happening.
Steven Knudsen
class I simply override the
packet_header_default::header_len() to return the right number of bytes. That
seems right to me :-)
Thanks!
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linked
class I simply override the
packet_header_default::header_len() to return the right number of bytes. That
seems right to me :-)
Thanks!
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linked
I'm having issues when attempting to use the wx gui sinks with OpenGL on MacOS
10.7.3:
Executing: "/Users/steven/gnuradio/top_block.py"
Using Volk machine: sse4_1_64_orc
Using device #0 (Generic RTL2832U (e.g. hama nano))
Found Elonics E4000 tuner
Exact sample rate is: 10
On 9 Apr 2012, at 17:41, Tom Rondeau wrote:
>
> Steven,
>
> Try to rebuild GNU Radio using -DTRY_SHM_VMCIRCBUF=Off.
>
> After you rebuild it, make sure you remove
> "~/.gnuradio/prefs/gr_vmcircbuf_default_factory" so you don't confuse
> the system.
>
On 9 Apr 2012, at 01:16, Michael Dickens wrote:
>> Does anyone have any pointers as to where I should be looking?
>
>
> Hi Steven - First, the humor < http://xkcd.com/138/ >.
>
I was waiting for something like that :o)
> Do "ipcs -a" to see how many s
I should try increasing the OS shared memory allocations but this didn't
seem to make any difference.
Does anyone have any pointers as to where I should be looking?
Thanks,
Steven.
smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gn
> Third
> downloaded the git version and after the usual steps with cmake, the
> building crashes at the 3% with the error
>
> cc1: error: unrecognized command line option "-mpopcnt"
> make[2]: ***
> [volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1
> make[1]: *** [volk/lib/CMake
On Sun, Feb 6, 2011 at 1:34 PM, Varun Krishnamurthy <
varun.sumkr...@gmail.com> wrote:
> Hi ,
>
>
> I am new to GNU Radio and am facing difficulties in implementing DQPSK
> modulation on Gnu Radio Companion. The system works fine , but for one small
> glitch. The DQPSK modulator/demodulator's inpu
laying around with
> global memory only so far, but I'll look into the other levels as well to
> see what they can provide & the trade-offs required.
>
> Good & interesting discussion! - MLD
>
>
>
Since FFTS & IFFTs are so speedy on GPUs (CUFFT is quite good now), a
duction, then stream the lower bandwidth data back to the
host to do further (annoyingly serial) operations. You could even (if you
wanted to) implement an entire transmitter or receiver within the GPU, with
the CPU solely shuttling data to or from the ADC/DAC.
In summary, yes please do get e
nect(mult, sink)
>
>
One would think something like this would work, but I've noticed that even
if you're sending 0's to your usrp sink, the transmitter still puts out some
amount of power (plenty strong enough to be detectable via a spec-an). This
po
in a rx signal that is distorted from the original.
Also, why do you have a throttle? You have a USRP sink, let its Interp
factor be the rate-determiner.
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
have still been stumped :)
It's definitely not obvious/intuitive (to me, at least) that changing the
decimation rate just slightly results in adding a whole 'nother additional
set of filtering.
Shouldn't the half-band filters have unity-gain in the pass-band?
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
Your scope sinks aren't using the same sample rate. One is using 500, one is
using 5k.
2:1 is correct for the ratio I believe.
Not sure what is causing your overruns.
Keep in mind that your true sample rate is being determined by your USRPs,
not by your samp_rate variable.
-Steven
__
On Tue, Nov 16, 2010 at 1:26 AM, ton ph wrote:
> Thanks steven ,
> I am able to tune steven , but same old problem in which the tune
> start before and the information which i see is a little bit late , as it
> seems reading from the previous buffer of the fifo. And my tu
On Sat, Nov 13, 2010 at 4:19 AM, ton ph wrote:
> Hi everyone,
>As I was trying to tune usrp from my python thread, I am not able to use
> my thread to tune the USRP. I am trying to tune using my python function,
>
> def tune_usrp(ms,freq):
> print "Tuning to frequency : "+str(freq)
>
> http://old.nabble.com/file/p30200932/Real-RXa_Real_RXb.jpg
>
>
>
Can you copy and paste the section of code where you issue tuning commands
to your daughtercards? This looks similar to something I was seeing earlier,
with 2 WBX cards, which was due to a mis
can still use my USRP1 via GNURadio as before.
Do I need to flash firmware / fpga? If so, where can I find instructions on
doing so?
Thanks
-Steven
PS: Is it ok to send email to both usrp-users and discuss-gnuradio? I know
you guys are probably trying to increase the SNR, but it seems kind of a
On Mon, Nov 8, 2010 at 11:52 AM, Thomas H Kim wrote:
> Steven,
>
> Thank you very much for your email.
> I installed Fedora Core13 x86_64, instead of i386, which I installed on
> last Friday and it works now. But, I don't understand because i386 should
> work on 64bit
s something like
"tar -xvf gnuradio-3.3.0.tar.gz")
cd into the resulting directory, then run:
./configure
make
make check
sudo make install(if you haven't used sudo before, check this out:
http://www.mjmwired.net/resources/mjm-fedora-f9.html#sudo )
If any of those steps give e
ls varying ~+/- 1ms without tuning each time, and ~+/-
10ms when tuning before each burst. I was under the impression that calling
set_rx_freq() to tune just the DUC rather than usrp.tune() should be
faster/more responsive, but I haven't seen this to be true...
Any scheduling / hopping tips would
data (using all bits in the byte). Others work with just
the LSB of the byte. Experiment with using packed_to_unpacked /
unpacked_to_packed blocks.
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
do I have with the DDC alone? Is it +/- 32MHz? IE
after I tune my daughtercard LO to 700MHz, I can tune from x to y solely
with the DDC...what are x and y?
Thanks for any wisdom!
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lis
Hi all-
Any estimate as to the readiness level of the UHD driver? (if open-source
has such a concept...)
Back in April they were called "pre-alpha". How are things progressing? Do
you recommend use of it yet to people whose day-job would (lamentably)
prefer they be productive? :)
As a checklist,
The 100mW transmit spec, is that at +0dB gain, or at +25dB gain (max)?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Oct 14, 2010 at 12:13 PM, Steven Clark wrote:
> Hi all-
>
> I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
> performed the clock synching described here:
> http://gnuradio.org/redmine/wiki/1/MultiUsrp
>
> I'm doing 4-channel receive,
On Wed, Oct 20, 2010 at 7:41 PM, Steven Clark wrote:
> On Thu, Oct 14, 2010 at 12:47 PM, Matt Ettus wrote:
>
>>
>> Probe R201 on all 4 WBX boards with an oscilloscope while running. One
>> side of the resistor is ground and the other side is the reference clock.
>&
; frequency and phase.
>
> Matt
>
>
> On 10/14/2010 09:13 AM, Steven Clark wrote:
>
>> Hi all-
>>
>> I have a multi-usrp setup with 2 USRP 1s and 4 WBX daughtercards. I have
>> performed the clock synching described here:
>> http://gnuradio.org/redmine/wi
swapping daughtercards around, and the problem is not tied to any
one daughtercard, but rather to slave USRP side B.
Any idea what could be causing this? Shouldn't the same clock be going to
both sides of the USRP? (why does blue look fine, but black does not?)
-Steven
___
be 0xf", which this violates.
What gives? Where is this constraint coming from?
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
: George Nychis
To: Daniel Steven
Cc: discuss-gnuradio@gnu.org
Sent: Monday, February 16, 2009 7:05:23 PM
Subject: Re: [Discuss-gnuradio] implement d8psk on benchmark_tx.py
Hello, Tianning/Bill/Daniel!
The performance of 8PSK matches pretty similarly to 16-QAM. So, 8PSK is
usually never used in
Hello, guys!
We are using the file, benchmark_tx.py residing in the directory of
python/digital to do some researches. We found that gmsk, dbpsk and dqpsk are
the supported modulation schemes for that file, but d8psk is not the supported
modulation technique. Is there any reason for the absence
king for interferers,
etc. How "clean" is "clean"? If your signal is strong enough, your SNR
should be plenty high to run your tests. If you truly need a very
quiet environment, you may need access to special facilities, such as
an anechoic chamber.
HTH
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Jun 11, 2008 at 11:01 AM, Firas A. <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> New USRP Documentation (Whenever I become sick and stay at home, I use my
> time to write some GnuRadio documentation).
>
> I hope from Gnuradio experts to examine this document and send to me a
> corrected informati
em.
>
> -- Don W.
>
Don-
Many thanks for keeping the patches up to date.
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Fri, Jun 6, 2008 at 9:30 AM, Long, Jeffrey P. <[EMAIL PROTECTED]> wrote:
> Steven-
>
> Did you actually find that the decision threshold needs to be biased? I
> actually implemented the 2 bit differential detector on a custom asic
> that was targeted at streaming audio(in
n complex. How would one do a 90deg
phase shift of real data? In any case, my implementation works with
the complex baseband coming from the USRP. After the complex multiply,
a complex-to-float block is used. For one-bit diffdetect, you base
your decision on the imag (sin) component, for two-bit you l
xperience. So you would have a
viterbi equalizer to mitigate ISI, and then wrap that in a layer of
forward error correction? Is this computationally feasible for
cpu-based software radio? Sounds like it could get computationally
expensive pretty quick...
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Jun 5, 2008 at 5:28 PM, Gregory Maxwell <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 5, 2008 at 3:25 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> [snip]
>> It should be a
>> drop-in replacement for the existing demodulator in designs, except
>> t
I noticed that many gnuradio files (gmsk.py for example) contain an
unholy mix of spaces and tabs for indentation. Is there any easy way
to standardize our indentation? Many text editors can make it so
hitting tab creates 4 spaces instead of the tab character.
(I like 4 spaces per indent, what ab
>
> Steven,
>
> If you were to generate a patch that had your demodulator show up as a
> new demod called, say, gsm_demod_alt2 that hooked it into the existing
> framework with this new name, we could add it to the tree and it would
> get more testing without having t
I've added a link to
http://gnuradio.org/trac/wiki/Enhanced_GMSK_Demodulator from
http://gnuradio.org/trac/wiki/OurUsers
Summary:
[...] offers an enhanced GMSK demodulator that I believe to be
superior to the GNURadio standard gmsk demodulator. It should be a
drop-in replacement for the existing
often than
not, Viterbi decoding is just used as part of the forward error
correction scheme.
Please look for my next email to the mailing list for an alternate
GMSK demodulator that reduces ISI...
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnurad
>
> It looks like you are missing a patch (attachment:"makefiles6975.patch,
> listed on the Cywin wiki page) needed to include the mblock library in the
> link of qa_inband_usrp_server.
>
> -- Don W.
>
Thanks for the reply. I did in fact try to apply both patches that are
mentioned on the page, bu
> I haven't found information for simple_framer/simple_correlator inputs and
> outputs and have no idea where my "ValueError: source and destination data
> sizes are different" problem comes from. Any hints would be appreciated!
>
> Thank you for your help!
>
> Irene
Make sure you know what type o
adio has a unpacked_to_packed block for this purpose.
On Tue, May 20, 2008 at 12:53 PM, irene159 <[EMAIL PROTECTED]> wrote:
>
>
> Steven Clark-2 wrote:
>>
>> This is not surprising. It is likely that you are getting some initial
>> garbage (non-standard-ascii characters) comi
This is not surprising. It is likely that you are getting some initial
garbage (non-standard-ascii characters) coming out, or that you have
some bit errors.
Don't open it in gedit. Try:
python
f = open('Resultat.txt')
d = f.read()
f.close()
print(len(d))
print(d)
(or if d is really long, print(d[:
Apologies for the necromancy, but I would like to help by adding an
item or two to the FAQ section. How do I get a trac account?
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
A certain daughtercard can support 0-70dB of gain, and the main-board
A/D chip can do 0-20dB of gain.
If I request 50dB of gain from software, how does this get distributed
between these two locations? Is one used preferentially over the
other?
___
Dis
On Sat, Mar 8, 2008 at 11:20 PM, Manav Rohil <[EMAIL PROTECTED]> wrote:
>
> I am getting segmentation fault with the following...
>
> src_data = (0xff,)
> src = gr.vector_source_b(src_data,False)
> #expected_results = (1,0,0,0,0,0,0,0)
> op = gr.packed_to_unpacked_bb(1, gr.GR_MS
On Tue, Mar 4, 2008 at 2:27 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> I like the use of the watcher thread in pkt.demod_pkts, and was
> wondering if I could use a similar technique in the following
> situation:
>
> Two disconnected subgraphs:
> msg_sourc
any danger of messages
being combined?)
Also, if transform_blk_1 has some saved state that I'd like to reset
in between packets, is it possible/safe to do so from the Queue
watcher thread? I'm worried about race conditions...
-Steven
___
, sample_rate)
Hope that helps.
-Steven
On Tue, Mar 4, 2008 at 1:27 PM, Manav Rohil <[EMAIL PROTECTED]> wrote:
> thanks for the replies...
> So that means if i dont have a USRP, i cannot simulate a packet
> transmission/reception entirely in software since the data will never be
>
If you are using the USRP, it handles all the conversion to and from
carrier frequency. The data going across the USB bus is generally
complex baseband.
You instruct the USRP what the carrier frequency should be:
#Set freq
if not(usrp.tune(self.usrp_out, 0, self.out_dcard, tx_freq)
Has anybody had any luck using any form of Forward Error Correction in
GNU Radio in a streaming context?
I'm hoping to compare notes / techniques.
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/lis
> Your msg_source, which is a gr.message_source, is blocked, waiting for
> new messages to arrive. In order to allow the second block chain to
> exit, you need to send it a message that causes it to unblock. The
> flowgraph scheduler thread that is running this chain will then see
> the indication
On Jan 31, 2008 1:13 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 31, 2008 at 10:49:50AM -0500, Steven Clark wrote:
> > Pardon the bump. Maybe I should simplify the question:
> >
> > With the packet modulator, is it possible to run the packet payload
> &
Pardon the bump. Maybe I should simplify the question:
With the packet modulator, is it possible to run the packet payload
bits through any kind of flow-graph/block during the rx_callback?
On Jan 27, 2008 6:39 PM, Steven Clark <[EMAIL PROTECTED]> wrote:
> 'lo all.
>
> I woul
Should Rx1 be a vector_source_f rather than a vector_sink_f?
-Steven
On Jan 29, 2008 10:17 PM, Jonas <[EMAIL PROTECTED]> wrote:
> Hi everyone!
>
> I have this problem with using gr_float_to_complex. I wanted to connect two
> sptr types wherein one contains floats while the oth
imag component went to another pin. One pin was data, the
other clock. We used the Quartus software to generate another .rbf
file, in other words. Just set the gain of the tx dboard to the min
and ignore its analog output. This worked fine for us.
-Steven
On Jan 28, 2008 2:04 PM, Tyrel Newton &l
duration of the callback. But wouldn't this interfere
with the top-block/flowgraph that was already existing for the packet
demod framework?
Any thoughts?
-Steven
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mail
> You might be able to run unpacked_to_packed followed by
> packed_to_unpacked to get what you want. It's ugly, but you don't
> have to write any code ;)
>
> pack = gr.unpacked_to_packed_ss(2, gr.GR_MSB_FIRST)
> unpack = gr.packed_to_unpacked_ss(1, gr.GR_MSB_FIRST)
>
> Eric
>
Aha! Shame on me
0, 1)
rather than:
(1,0,1,1,0,1)
*bang head on keyboard in search of enlightenment*
On Jan 10, 2008 4:51 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 04:43:17PM -0500, Steven Clark wrote:
> > Hey folks-
> >
> > Let's say I have a str
Hey folks-
Let's say I have a stream of shorts whose values are one of [0,1,2,3] (in
other words, the bottom 2 bits are active). I want to split these bits, so
that:
[2,3,3,1,0] -> [1,0,1,1,1,1,0,1,0,0], etc.
What block(s) can help me achieve this?
___
This article might be helpful. It's targeted at matlab, but easily
transferable to python.
http://www.transcrypt.com/resources/all/files/19388/_fn/bit-error-rate_simulation_using_matlab.pdf
On Nov 10, 2007 11:15 AM, Meenaktchi Venkatachalam <[EMAIL PROTECTED]>
wrote:
>
>
> On Nov 9, 2007 11:46 AM
I'm just trying to gather information about what types of FEC are currently
available in GNURadio.
A quick scan of directories shows me:
Reed-Solomon (no changes in 4 years)
Trellis / Viterbi (created by Achilleas?)
Are there any others? (could we maybe reorganize them into a unified /fec/
direct
On 10/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:
> One approach then would be to ensure this never happens, i.e., add a
> small epsilon to each input stream, and make epsilon small enough to not
> sufficiently impact the results for "typical" input values. Normalizing
> the conjugate prod
1) Has anybody ever noticed a case where gr.head doesn't seem to limit the
amount of data that flows through it? I have (some data source) -> (head) ->
(file sink), and sometimes the writing to the file shuts off appropriately,
other times it seems to skip over the limit and would happily consume m
All-
I was hoping I could get some advice on what is a good block-design strategy
for the following problem.
I have two streams of complex samples coming in. I want a block or sequence
of blocks which outputs the cosine of the phase difference between the two
input streams.
If we could assert th
1))
self.connect(self.mult, self.c2f)
self.connect((self.c2f, 0), self.pre_cr_filt, self.sub,
self.clock_recovery, self.slicer, self)
----- Original Message -
>
> *From:* Steven Clark <[EMAIL PROTECTED]>
> *To:* gnuradio mailing list
> *Sent:* Monday, October 15, 200
1 - 100 of 140 matches
Mail list logo
