[Discuss-gnuradio] Input items vs Output items
I am slightly confused with the way you implement a general work
function - here is my AX25 decoder which takes in bits and outputs
decoded packets in text format as a stream of 8 bit integers. This was
based on the general work example in the GR tutorial.
int ax25_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
int i;
const char *bit = (const char *) input_items[0];
out = (char *) output_items[0];
d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}
// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}
I keep a tally of how many characters I output in the class member
variable d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using
the strlen() function to find out how long the out string is.
It works for a while, perhaps 200-300 packets and then crashes with a
segfault and error 7. I know the crash is related to the number of
output items because if I reduce the number of characters I output it
will run for longer. If I don't output anything its fine, but not very
useful.
It gets complicated because the block outputs nothing at all until it
decodes a packet, then it outputs that entire packet, which might be
up to 1000 characters or so.
I think I have made a fundamental error somewhere. Finding it is
proving problematic. I am also confused by ninput_items and
noutput_items variables as to me they appear reversed but that is how
they are in the tutorial.
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input items vs Output items
Hi Mike,
you might actually be doing something redundant here:
GNU Radio actually keeps tabs on how many items you produced; just call
nitems_written(0) to get that number.
I don't really understand where your string comes from or where it ends
up, but do make sure your string isn't going to be longer than your
noutput_items.
Generally, this is something that can most probably best be analyzed
using appropriate debugging methods -- I'd like to point you to [1].
As soon as you find out where your segfault happens, it will be easier
to understand under which conditions it happens. Also, GDB allows you to
`print` the value of local variables, so that might actually shine quite
a light on what goes wrong :)
On a more general note: what your block seems to do looks very much like
what tagged stream blocks (probably after gr-ax25) were designed to do.
Have a look at [2]; maybe I'm misjudging the situation, maybe you're
already using the TSB facilities.
Greetings,
Marcus
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
[2] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html
On 04/18/2015 03:36 PM, Mike Willis wrote:
I should have added, the packet decoding is based on Volkers rather nifty
gr-ax25, which I think is based on earlier implementations so I don't think
that is where the bug is. I have heavily modified that code as I am using
BPSK demodulator but the hdlc parts are the same.
Mike
-Original Message-
From: Mike Willis [mailto:willis...@gmail.com]
Sent: 18 April 2015 13:58
To: GNURadio Discussion List
Subject: Input items vs Output items
I am slightly confused with the way you implement a general work function -
here is my AX25 decoder which takes in bits and outputs decoded packets in
text format as a stream of 8 bit integers. This was based on the general work
example in the GR tutorial.
int ax25_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items) { int i; const char *bit
= (const char *) input_items[0]; out = (char *) output_items[0];
d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}
// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}
I keep a tally of how many characters I output in the class member variable
d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using the
strlen() function to find out how long the out string is.
It works for a while, perhaps 200-300 packets and then crashes with a
segfault and error 7. I know the crash is related to the number of output
items because if I reduce the number of characters I output it will run for
longer. If I don't output anything its fine, but not very useful.
It gets complicated because the block outputs nothing at all until it decodes
a packet, then it outputs that entire packet, which might be up to 1000
characters or so.
I think I have made a fundamental error somewhere. Finding it is proving
problematic. I am also confused by ninput_items and noutput_items variables
as to me they appear reversed but that is how they are in the tutorial.
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rts/cts on gnuradio
Hello all, I am trying to implement rts/cts handshake scenario on gnuradio prior to packet transmission. I intend to work on gr-mac which was created by john malsbury, i.e by adding the functions on the simple mac block,in this case, the block will perform most functions of the IEEE802.11 DCF. I have started editing the block by adding some lines of codes to the simple mac python file. So far, i haven't been able to get it to work, i guess maybe i am missing something crucial somewhere which i don't have an idea what it is as yet. So far, i defined functions to generate the rts/cts packets and i also created scenarios using if commands on when to send the rts and cts packets. I am not sure if that is what i should be doing. Please i need an head start on how to go about this implementation, maybe there is something i am missing or i'm going about it the wrong way. Thank you all and best regards, Abdullahi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input items vs Output items
Hi Mike, I don’t quite understand – when you say “do make sure your string isn't going to be longer than your noutput_items” I don’t know what that means because that’s something coming from the scheduler isn’t it? I was assuming you vsprintf into the output buffer, hence the recommendation that you make not to print beyond the end of what you're allowed to fill. Maybe you could share what you print where :) Best regards, Marcus On 04/18/2015 04:01 PM, Mike Willis wrote: Hi Marcus Thanks for the quick answer. I didn’t know about nitems_written(0) but I did wonder why the system didn’t already know. It’s been a while since I used GDB but I will have a go. I don’t quite understand – when you say “do make sure your string isn't going to be longer than your noutput_items” I don’t know what that means because that’s something coming from the scheduler isn’t it? If so how can I know beforehand what that number is? I know a few hundred bytes that will be triggered by the one last input bit for the packet. I am afraid any of the tagged streams or messages are a bit of a mystery to me. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input items vs Output items
I should have added, the packet decoding is based on Volkers rather nifty
gr-ax25, which I think is based on earlier implementations so I don't think
that is where the bug is. I have heavily modified that code as I am using BPSK
demodulator but the hdlc parts are the same.
Mike
-Original Message-
From: Mike Willis [mailto:willis...@gmail.com]
Sent: 18 April 2015 13:58
To: GNURadio Discussion List
Subject: Input items vs Output items
I am slightly confused with the way you implement a general work function -
here is my AX25 decoder which takes in bits and outputs decoded packets in text
format as a stream of 8 bit integers. This was based on the general work
example in the GR tutorial.
int ax25_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items) { int i; const char *bit =
(const char *) input_items[0]; out = (char *) output_items[0];
d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}
// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}
I keep a tally of how many characters I output in the class member variable
d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using the
strlen() function to find out how long the out string is.
It works for a while, perhaps 200-300 packets and then crashes with a segfault
and error 7. I know the crash is related to the number of output items because
if I reduce the number of characters I output it will run for longer. If I
don't output anything its fine, but not very useful.
It gets complicated because the block outputs nothing at all until it decodes a
packet, then it outputs that entire packet, which might be up to 1000
characters or so.
I think I have made a fundamental error somewhere. Finding it is proving
problematic. I am also confused by ninput_items and noutput_items variables as
to me they appear reversed but that is how they are in the tutorial.
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Input items vs Output items
Hi Marcus Thanks for the quick answer. I didn't know about nitems_written(0) but I did wonder why the system didn't already know. It's been a while since I used GDB but I will have a go. I don't quite understand - when you say do make sure your string isn't going to be longer than your noutput_items I don't know what that means because that's something coming from the scheduler isn't it? If so how can I know beforehand what that number is? I know a few hundred bytes that will be triggered by the one last input bit for the packet. I am afraid any of the tagged streams or messages are a bit of a mystery to me. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Writing text to a QT Gui Window
Have a look at https://github.com/dl1ksv/gr-display -- Volker Am 18.04.2015 um 12:04 schrieb Mike Willis: I am wondering how I might write stuff to a gui window from my OOT blocks rather than to the console. I don’t see anything in the standard blocks – a gui text sink for example. I assume I will need to write something but am short on examples of gui output Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-nacl: OOT module for data encryption using NaCl
Hi! I want to present you a OOT module which provides the functionality of the NaCl crypto library for GNU Radio. The NaCl library is a well known library written by Daniel J. Bernstein, Tanja Lange and Peter Schwabe [0]. Because the library is not maintained by themselves, I have chosen the well maintained fork libsodium [1]. This fork is also used by the crypto messenger tox (awesome project! - [2]). NaCl is also used by the messenger Threema (smartphone app). The features of the OOT module are: Public-key en-/decryption, secret-key en-/decryption and key-pair (public/secret) or key (only secret) generation. The system is based on the message API. Furthermore, I have implemented a byte stream en-/decryption using stream ciphers. This one uses tagged streams for processing. If you are interested, you can check out the repo on GitHub [3]. In the folder examples/ are flowgraphs which explain the functionality. As well, there are unit-tests ;) So far everything works fine. I have no idea whether this is already done and I am not a crypto expert, but here it is! Greetings Stefan [0] http://nacl.cr.yp.to/ [1] http://doc.libsodium.org/, https://github.com/jedisct1/libsodium [2] https://github.com/irungentoo/toxcore [3] https://github.com/stwunsch/gr-nacl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input items vs Output items
Also, to point out existing work, there is an HDLC framer and deframer in
Gnuradio now. The deframer takes in a byte stream, 1 bit per byte, and
outputs PDUs with your HDLC frames.
--n
On Sat, Apr 18, 2015 at 6:46 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Hi Mike,
you might actually be doing something redundant here:
GNU Radio actually keeps tabs on how many items you produced; just call
nitems_written(0) to get that number.
I don't really understand where your string comes from or where it ends
up, but do make sure your string isn't going to be longer than your
noutput_items.
Generally, this is something that can most probably best be analyzed
using appropriate debugging methods -- I'd like to point you to [1].
As soon as you find out where your segfault happens, it will be easier
to understand under which conditions it happens. Also, GDB allows you to
`print` the value of local variables, so that might actually shine quite
a light on what goes wrong :)
On a more general note: what your block seems to do looks very much like
what tagged stream blocks (probably after gr-ax25) were designed to do.
Have a look at [2]; maybe I'm misjudging the situation, maybe you're
already using the TSB facilities.
Greetings,
Marcus
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
[2] http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html
On 04/18/2015 03:36 PM, Mike Willis wrote:
I should have added, the packet decoding is based on Volkers rather
nifty gr-ax25, which I think is based on earlier implementations so I don't
think that is where the bug is. I have heavily modified that code as I am
using BPSK demodulator but the hdlc parts are the same.
Mike
-Original Message-
From: Mike Willis [mailto:willis...@gmail.com]
Sent: 18 April 2015 13:58
To: GNURadio Discussion List
Subject: Input items vs Output items
I am slightly confused with the way you implement a general work
function - here is my AX25 decoder which takes in bits and outputs decoded
packets in text format as a stream of 8 bit integers. This was based on the
general work example in the GR tutorial.
int ax25_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items) { int i; const char
*bit = (const char *) input_items[0]; out = (char *) output_items[0];
d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}
// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}
I keep a tally of how many characters I output in the class member
variable d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using the
strlen() function to find out how long the out string is.
It works for a while, perhaps 200-300 packets and then crashes with a
segfault and error 7. I know the crash is related to the number of output
items because if I reduce the number of characters I output it will run for
longer. If I don't output anything its fine, but not very useful.
It gets complicated because the block outputs nothing at all until it
decodes a packet, then it outputs that entire packet, which might be up to
1000 characters or so.
I think I have made a fundamental error somewhere. Finding it is proving
problematic. I am also confused by ninput_items and noutput_items variables
as to me they appear reversed but that is how they are in the tutorial.
Mike
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Input items vs Output items
Thanks for the HDLC tip. A neat bit of code. I have not worked with message ports before. I have looked at the examples and managed to get PDUs displayed in the console as hex dumps using the debug block, but how can I do things with them? My own block takes the packet data, extracts the payload, adds a timestamp to the front, saves to an ascii file and optionally prints and/or sends over the network. Is there a simple message block example anywhere? Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with installation via PyBOMBS, on Ubuntu 14.04.2 LTS
Gents, Thanks again - to the pair of you. I am now up-up-and-away on the Core2Quad, (running under Ubuntu14.04.2LTS), and although Ubuntu ain't as cruzy boot'n'go as OS X, (especially when it comes to 'keeping it fresh and updated'), the extra wallop from double the cores and double the RAM - certainly makes up for it! Still running on USB2 though... (Don't bother with any tips concerning the whole 'which USB3 PCIe Card to buy' minefield, as I'll do a little more research across the numerous threads and forums first, before I come back to this playground for some extra help. Once again - well done, and thank you both very VERY much. Random. -- View this message in context: http://gnuradio.4.n7.nabble.com/Trouble-with-installation-via-PyBOMBS-on-Ubuntu-14-04-2-LTS-tp53314p53350.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Message Strobe Block Stopping Unexpectedly
I'm having a problem with the Message Strobe block. I have a simple flowgraph, which can be found here: http://pastebin.com/WCa5npiP There are two independent dataflows in the flowgraph: Flow 1: noise source - throttle - selector(w /wx chooser) - null sink - null sink Flow 2: message strobe(w /wx chooser) - message debug Both the message in the message strobe and output index of the selector are wx chooser controlled. I am able to change the message fine, but when I change the output index of the selector of a running flow, the stop method of the message strobe gets called. Why is this happening and can I prevent it? I want the messages to continue. Im using GNU-Radio: 3.7.6.1 (built from build-gnuradio) -Travis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New UHD seems to break a lot...
Yes, I can confirm hash 2fe3..., and the images were downloaded with the supplied uhd_image_downloader, what is configured like this: _DEFAULT_BASE_URL = http://files.ettus.com/binaries/images/; _AUTOGEN_IMAGES_FILENAME = uhd-images_003.008.003-rc1.zip _AUTOGEN_IMAGES_CHECKSUM = 8522b02386f5fe0bb51baa3ba0001ef0 The GRC filkes are accessible now, the only modifications I made were due to Ron Economos' hints regarding sampling rate, and I added a frequency slider to choose the correct European TV channel without having to know the frequency. Ralph. From: Ian Buckley [mailto:i...@ionconcepts.com] Sent: Saturday, April 18, 2015 03:45 To: Ralph A. Schmid, dk5ras Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List' Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot... Ralph, I'm not able to access either of the .grc files on your website, but using the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same as your uhd_master screen shot. I don't see the truncated bandwidth of your uhd_rc1 screenshot. http://ianbuckley.net/dvbt.jpg Can you verify please that you have UHD at the current 003.008.003-RC1 tag position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the downloaded FPGA images are from: http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip I'll need your exact flow graph if I'm to debug this anymore. -Ian On Apr 17, 2015, at 11:48 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: I have put it all here, flow graphs and screenshots of the flow graphs: http://dk5ras.dyndns.org/tmp/DVB/ This way we can keep it on the list without sending attachments. They were taken from the VM container before all the upgrades were made, but I did not change anything when upgrading. Ralph. -Original Message- From: Ian Buckley [mailto:i...@ionconcepts.com] Sent: Friday, April 17, 2015 19:25 To: Ralph A. Schmid, dk5ras Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List' Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot... Great Ralph, thats a big help. Can you send me your exact flow graph used to generate these 2 plots off list please. I want to re run this scenario and see your exact configuration. Thanks -Ian On Apr 17, 2015, at 10:00 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: OK, here we go. The hotel TV was dvb-c only, so I had to do the tests back at home. I took my perfectly working Kubuntu 14.04 64 bit VM container together with my B210, made a copy and updated this one, first I made a git pull to get latest master, built it, rebuilt gnuradio, rebuilt gr-dvbt, updated the FPGA images, and everything still was fine. The chosen dvb-t bandwidth is 8 MHz. Then I changed to 003_008_003_rc1, did the same procedure, fired up grc, and the signal was not decodable both with a dvb-t PC receiver and with an dvb-x analyzer. The analyzer saw the RF level, but no data, no constellation, nothing, it looked to him like interference. When you have a look at the two uhd screenshots here http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then you will find that RC1 produces a somehow narrower signal, so it really looks something gets cut at the ends with all the filtering and DSP stuff. Adjusting the channel bandwidth in the uhd sink block from 0 to a sensible value changes nothing. Btw., the dvb-t2 package behaves identical. Ralph. -Original Message- From: Martin Braun [mailto:martin.br...@ettus.com] Sent: Wednesday, April 15, 2015 21:14 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List' Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot... master works, but RC1 does not? Huh, I'm confused now. Can you give some detail on what's going on, so we can try and reproduce this? Thanks, Martin On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote: RC1, master seems to work. Ralph. -Original Message- From: Martin Braun [mailto:martin.br...@ettus.com] Sent: Wednesday, April 15, 2015 15:44 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List' Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot... Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean 3.8.3-RC1, or latest master? Martin On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote: It is a B210, but as a note, due to the up to now missing FPGA images I used 003.008.003-RC1, not the latest master. Still I had no access to a spectrum and DVB-T analyzer, so I have no idea what is happening, I just can confirm that RF is transmitted, and the receiver doesn't get a picture, while with the snapshot of the same VM before the upgrade is received without problems. I will know more in about three hours. Ralph. -Original Message- From:
[Discuss-gnuradio] Writing text to a QT Gui Window
I am wondering how I might write stuff to a gui window from my OOT blocks rather than to the console. I don't see anything in the standard blocks - a gui text sink for example. I assume I will need to write something but am short on examples of gui output Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
