Re: [Discuss-gnuradio] Make fails and gives the following
Hi Sanjeeb, it looks like there are some leftover make configuration from an older bootstrap run on another debian version. Is there any cause why you need to use a very very very old GNU Radio? Greetings Marcus On 08/21/2013 07:40 AM, sanjeeb wrote: Hi there, after ./bootstrap and ./configure when i run make i get the following: libtool: Version mismatch error. This is libtool 2.4.2 Debian-2.4.2-1ubuntu1, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 Debian-2.4.2-1ubuntu1 libtool: and run autoconf again. make[6]: *** [pmt.lo] Error 63 make[6]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib/pmt' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib/pmt' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio/gruel' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sanjeeb/Desktop/n+/gnuradio' make: *** [all] Error 2 Need help ___ 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] Channel estimation/equalization in OFDM
Dear All, I've been trying to investigate how channel estimation works in OFDM based on the implementation provided in Gnuradio for OFDM transmission. I found that it was done in the block digital_ofdm_frame_acquisition.cc/h. As I understand, the digital_ofdm_frame_acquisition::calculate_equalizer does the job: based on known transmitted symbols (stored in d_known_symbol) and received symbols (stored in symbol), the inverse of the channel coefficient can be obtained according an equation similar to the following: channel_coefficient = symbol/d_known_symbol However, there are two differences in the implementation in relation to this equation: 1) the block computes the inverse of the channel coefficient (d_known_symbol/symbol), and 2) there is a frequency compensation term (coasre_freq_comp) which basically rotates the complex samples by phase corresponding to the frequency deviation and obtained via the preceding sync block. One final note is that channel coefficient is obtained in every other tab, and the coefficient in the inter-taps are obtained via linear interpolation of the acquired channels. Now, my questions are as follows: 1) Does this explanation seems correct? 2) By modifying the VERBOSE variable to be equal to 1 in digital_ofdm_frame_acquisition.cc, the block also plots the estimated channel coefficients in the following order: transmitted symbol --> known symbol --> estimated channel inverse --> output). I noticed that when using a file source/sink to store/receive packets from OFDM benchmark transmitter and receiver, the channel coefficients are still not equal to 1, despite the fact that no receive noise nor wireless fading occurs. What do these coefficients represent? 3) Are the obtained coefficients eligible to be used in further precoding of transmitted packets, assuming that the channel between Tx/Rx is reciprocal, and that a receiver can switch roles with the transmitter? Thank you -- *---* *Mohammed Hassan Karmoose* *Teaching Assistant, Electrical Engineering Dept.* *Faculty of Engineering, Alexandria University* *Al-Horeya Rd, El-Hadara,* *Alexandria, Egypt - 21544* *Tel: **(++203)592-1852* | *Fax: **(++203)592-1853* *Email: m _h_karmoose@a lexu.edu.eg* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel estimation/equalization in OFDM
Mohammed, you should also check the new OFDM implementation (see examples/ofdm/rx_ofdm.grc and python/digital/ofdm_txrx.py). Much more modular. On Wed, Aug 21, 2013 at 11:33:26AM +0200, Mohammed Karmoose wrote: > However, there are two differences in the implementation in relation to this > equation: 1) the block computes the inverse of the channel coefficient > (d_known_symbol/symbol), and 2) there is a frequency compensation term > (coasre_freq_comp) which basically rotates the complex samples by phase > corresponding to the frequency deviation and obtained via the preceding sync > block. One final note is that channel coefficient is obtained in every other > tab, and the coefficient in the inter-taps are obtained via linear > interpolation of the acquired channels. > > > Now, my questions are as follows: > > > 1) Does this explanation seems correct? Hm... coarse freq compensation deals with freq. offsets larger than one sub-carrier spacing. Interpolation is done in frequency direction (the Schmidl & Cox sync algo requires double sub-carrier spacing on the sync symbol). > 2) By modifying the VERBOSE variable to be equal to 1 in > digital_ofdm_frame_acquisition.cc, the block also plots the estimated channel > coefficients in the following order: transmitted symbol --> known symbol --> > estimated channel inverse --> output). I noticed that when using a file > source/ > sink to store/receive packets from OFDM benchmark transmitter and receiver, > the > channel coefficients are still not equal to 1, despite the fact that no > receive > noise nor wireless fading occurs. What do these coefficients represent? Most likely phase rotation due to cyclic prefix and timing errors. Have you checked the magnitude? It's probably 1. > 3) Are the obtained coefficients eligible to be used in further precoding of > transmitted packets, assuming that the channel between Tx/Rx is reciprocal, > and > that a receiver can switch roles with the transmitter? That's more of a signal processing question, and as such the (annoying) answer is: Depends on your application. Are you attempting some kind of waterfilling algorithm? In any case, discard the phase before you do so, and make sure you have some kind of limiter. 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-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp6VZMEUc_60.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] inefficient large vectors
Hi! I have many sync blocks that work with large fixed size vectors, e.g. converts one vector of size 12659 to another with size 18353. I have just multiplied the sizeof(gr_complex) with 12659 and 18353 in the signature. However, when the flow graph is running, then I get a warning about paging: the circular buffer implementation allocates large buffers (e.g. 4096 many to make the paging requirement). I do not want really large buffers. I have implemented the whole thing with padding, but that becomes also really inefficient, since when you want to switch between vectors and streams, then you have to jump through extra hoops with the padding. In a previous version I had streams everywhere, but then there is absolutely no verification whether I messed up the sizes of my "virtual vectors". So is there a way to work with large odd length vectors which does not have this buffer allocation problem, and does not require padding? It seems to me that it could be supported: regular streams but the vector size would be verified separately at connection time and would not be used to multiply the item size. Any advice is appreciated... Best, Miklos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Processing multiple signals off single source block
I am working on a processing multiple signals using a single source block. The background is below, but I had a couple of high level questions: - What is the best approach performance wise for selecting multiple ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR Filter with a low-pass? Is it more efficient to use a SIN Sig source & Multiply Block with a low-pass FIR Filter? Is there a better way to extract a filter? - What is the best way to have different bunch of blocks processing each signal run independently and not block each other? I want to do this as a GR C++ program is there any way to run the signal source and chanelizers as one thread and then have the different processing chains run as separate threads? Is there a way to put a queue or buffer inbetween blocks that would allow for a chain of blocks to be separated between threads? Or am I better off doing the basic signal/channel processing for everything in a single process and then writing the results to a file and then having a process which goes through the files and does the more intensive vocoder work in non-real time? Any pointers or examples of how to do threading with GR C++ code would be really helpful. I am not sure of the best architectual approach. Background: I have taken the gr-smartnet code and done a skeleton implementation in C++. I want to process the digital trunking channel and then decode and record the digital audio from all of the different talk groups. Since it is trunked, channels will be randomly be turning on and off and talk groups will be switching from channels. It would be good to have a separate thread for the trunk decoding and the separate digital audio recorders. Ideally, I would like to be able to do this over 8 or 10Mhz using my HackRF. My code, which is working enough to decode the trunking channel, is here: https://github.com/robotastic/sdr Thanks! - Luke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Processing multiple signals off single source block
Hi Luke, I've found using the FFT blocks are the most cpu efficient way to extract a channel from the whole 20MHz of the HackRF. Have a look at my latest Scanoo release built in GRC which uses the 'Keep X in N' block to select the channel required. There's also a spectrum sense mode which locks on to the strongest signal within the 20MHz bandwidth if it is not in the blocked frequency list: https://github.com/m0mik/scanoo Cheers, Mike -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web: http://scanoo.com On Wed, Aug 21, 2013 at 7:15 PM, Luke B wrote: > I am working on a processing multiple signals using a single source block. > The background is below, but I had a couple of high level questions: > > - What is the best approach performance wise for selecting multiple > ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR > Filter with a low-pass? Is it more efficient to use a SIN Sig source & > Multiply Block with a low-pass FIR Filter? Is there a better way to extract > a filter? > > - What is the best way to have different bunch of blocks processing each > signal run independently and not block each other? I want to do this as a > GR C++ program is there any way to run the signal source and chanelizersas > one thread and then have the different processing chains run as separate > threads? Is there a way to put a queue or buffer inbetween blocks that > would allow for a chain of blocks to be separated between threads? > > Or am I better off doing the basic signal/channel processing for > everything in a single process and then writing the results to a file and > then having a process which goes through the files and does the more > intensive vocoder work in non-real time? > > Any pointers or examples of how to do threading with GR C++ code would be > really helpful. I am not sure of the best architectual approach. > > > Background: > I have taken the gr-smartnet code and done a skeleton implementation in > C++. I want to process the digital trunking channel and then decode and > record the digital audio from all of the different talk groups. Since it is > trunked, channels will be randomly be turning on and off and talk groups > will be switching from channels. It would be good to have a separate thread > for the trunk decoding and the separate digital audio recorders. Ideally, I > would like to be able to do this over 8 or 10Mhz using my HackRF. > > My code, which is working enough to decode the trunking channel, is here: > https://github.com/robotastic/sdr > > Thanks! > > - Luke > > ___ > 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] inefficient large vectors
On Wednesday, August 21, 2013, Miklos Maroti wrote: > > I have many sync blocks that work with large fixed size vectors, e.g. > converts one vector of size 12659 to another with size 18353. I have > just multiplied the sizeof(gr_complex) with 12659 and 18353 in the > signature. However, when the flow graph is running, then I get a > warning about paging: the circular buffer implementation allocates > large buffers (e.g. 4096 many to make the paging requirement). I do > not want really large buffers. I have implemented the whole thing with > padding, but that becomes also really inefficient, since when you want > to switch between vectors and streams, then you have to jump through > extra hoops with the padding. In a previous version I had streams > everywhere, but then there is absolutely no verification whether I > messed up the sizes of my "virtual vectors". > > So is there a way to work with large odd length vectors which does not > have this buffer allocation problem, and does not require padding? It > seems to me that it could be supported: regular streams but the vector > size would be verified separately at connection time and would not be > used to multiply the item size. Any advice is appreciated... > The best technique here is to round up your itemsize to the next integer multiple of the machine page size, typically 4K. You can still operate a vector at a time, but you'll have to do a little math to identify the start of each vector in the input and output buffers, as they will no longer be contiguous. It sounds like you might have already tried something like this. -- Johnathan Corgan Corgan Labs - SDR Training and Development Services http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inefficient large vectors
Yes, this is what I am doing, but it is not very nice, and you cannot easily mix in blocks that want to work at the stream level. What really bugs me that I think the scheduler could figure all out, and treat my vectors as a stream, allocate nice buffers (who cares if the vector fits in the buffer in an integer multiple times). Am I wrong with this? I think this would be a nice further development... Miklos On Wed, Aug 21, 2013 at 9:04 PM, Johnathan Corgan wrote: > On Wednesday, August 21, 2013, Miklos Maroti wrote: > >> >> I have many sync blocks that work with large fixed size vectors, e.g. >> converts one vector of size 12659 to another with size 18353. I have >> just multiplied the sizeof(gr_complex) with 12659 and 18353 in the >> signature. However, when the flow graph is running, then I get a >> warning about paging: the circular buffer implementation allocates >> large buffers (e.g. 4096 many to make the paging requirement). I do >> not want really large buffers. I have implemented the whole thing with >> padding, but that becomes also really inefficient, since when you want >> to switch between vectors and streams, then you have to jump through >> extra hoops with the padding. In a previous version I had streams >> everywhere, but then there is absolutely no verification whether I >> messed up the sizes of my "virtual vectors". >> >> So is there a way to work with large odd length vectors which does not >> have this buffer allocation problem, and does not require padding? It >> seems to me that it could be supported: regular streams but the vector >> size would be verified separately at connection time and would not be >> used to multiply the item size. Any advice is appreciated... > > > The best technique here is to round up your itemsize to the next integer > multiple of the machine page size, typically 4K. You can still operate a > vector at a time, but you'll have to do a little math to identify the start > of each vector in the input and output buffers, as they will no longer be > contiguous. It sounds like you might have already tried something like > this. > > > > -- > Johnathan Corgan > Corgan Labs - SDR Training and Development Services > http://corganlabs.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inefficient large vectors
Yes, this is what I am doing, but it is not very nice, and you cannot easily mix in blocks that want to work at the stream level. What really bugs me that I think the scheduler could figure all out, and treat my vectors as a stream, allocate nice buffers (who cares if the vector fits in the buffer in an integer multiple times). Am I wrong with this? I think this would be a nice further development... Miklos The aligned-to-page-size buffer management is due to the way that mmap() is used to mutliply-map these buffers into the address space. That only "works" if the sizes are multiples of the native page size. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] inefficient large vectors
On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote: > So is there a way to work with large odd length vectors which does not > have this buffer allocation problem, and does not require padding? It > seems to me that it could be supported: regular streams but the vector > size would be verified separately at connection time and would not be > used to multiply the item size. Any advice is appreciated... Miklos, if Johnathan's tips aren't helping, you *might* be able to use tags to delimit vectors and then pass them as streams of scalars. You then have to keep up with vector boundaries internally in your block. Depending on what your application is, this could be a solution or can make things even more inefficient. But it's worth a try! 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-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpfI_PB2W6RQ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Send & receive a character through USRP
Evariste, you can tx anything that's in digital format. Check out some of the examples in gr-digital. MB On Wed, Aug 21, 2013 at 02:18:17PM -0400, Evariste Some wrote: > Hi all, > > Is it possible to send & receive a character via USRPs? > > My curiosity brought me to such thing though my DSP knowledge is basic. > > I joined the flow-graph for any suggestion. I have no way to input or output a > message. > > I also tried in Python but still have some issues with the packing and > unpacking. Any idea or suggestion or scripts are welcome. > > > Thanks for the sharing, > > > Eva > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgphNkJh4rFMY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Processing multiple signals off single source block
Mike, does this work with the Funcube Dongle Pro+? On Thu, Aug 22, 2013 at 4:39 AM, Mike Jameson wrote: > Hi Luke, > > I've found using the FFT blocks are the most cpu efficient way to extract > a channel from the whole 20MHz of the HackRF. Have a look at my latest > Scanoo release built in GRC which uses the 'Keep X in N' block to select > the channel required. There's also a spectrum sense mode which locks on to > the strongest signal within the 20MHz bandwidth if it is not in the blocked > frequency list: > > https://github.com/m0mik/scanoo > > Cheers, > > Mike > > -- > Mike Jameson M0MIK BSc MIET > Email: m...@scanoo.com > Web: http://scanoo.com > > > On Wed, Aug 21, 2013 at 7:15 PM, Luke B wrote: > >> I am working on a processing multiple signals using a single source >> block. The background is below, but I had a couple of high level questions: >> >> - What is the best approach performance wise for selecting multiple >> ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR >> Filter with a low-pass? Is it more efficient to use a SIN Sig source & >> Multiply Block with a low-pass FIR Filter? Is there a better way to extract >> a filter? >> >> - What is the best way to have different bunch of blocks processing each >> signal run independently and not block each other? I want to do this as a >> GR C++ program is there any way to run the signal source and chanelizersas >> one thread and then have the different processing chains run as separate >> threads? Is there a way to put a queue or buffer inbetween blocks that >> would allow for a chain of blocks to be separated between threads? >> >> Or am I better off doing the basic signal/channel processing for >> everything in a single process and then writing the results to a file and >> then having a process which goes through the files and does the more >> intensive vocoder work in non-real time? >> >> Any pointers or examples of how to do threading with GR C++ code would be >> really helpful. I am not sure of the best architectual approach. >> >> >> Background: >> I have taken the gr-smartnet code and done a skeleton implementation in >> C++. I want to process the digital trunking channel and then decode and >> record the digital audio from all of the different talk groups. Since it is >> trunked, channels will be randomly be turning on and off and talk groups >> will be switching from channels. It would be good to have a separate thread >> for the trunk decoding and the separate digital audio recorders. Ideally, I >> would like to be able to do this over 8 or 10Mhz using my HackRF. >> >> My code, which is working enough to decode the trunking channel, is here: >> https://github.com/robotastic/sdr >> >> Thanks! >> >> - Luke >> >> ___ >> 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] Processing multiple signals off single source block
Hi Vanush, It uses the gr-osmosdr GRC block and the Funcube Dongle Pro+ is second in the list of compatible devices so yes it will work: http://sdr.osmocom.org/trac/wiki/GrOsmoSDR However, In order to work using the 192KHz bandwidth of the Funcube Pro+ you will need to fiddle with the sample rates and make sure that they are something like the following: 1) samp_rate = 192e3 2) channel_samp_rate = (quad_samp_rate * 1) 3) quad_samp_rate = (audio_samp_rate * 1) 4) audio_samp_rate = (48e3) I'll update Scanoo to have an option in the GUI for the 'channel_samp_rate' and 'quad_samp_rate' multipliers for easy Funcube use and better flexibility. Thanks for asking the question! Regards, Mike -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web: http://scanoo.com On Wed, Aug 21, 2013 at 11:40 PM, Vanush Vaswani wrote: > Mike, does this work with the Funcube Dongle Pro+? > > > > > On Thu, Aug 22, 2013 at 4:39 AM, Mike Jameson wrote: > >> Hi Luke, >> >> I've found using the FFT blocks are the most cpu efficient way to extract >> a channel from the whole 20MHz of the HackRF. Have a look at my latest >> Scanoo release built in GRC which uses the 'Keep X in N' block to select >> the channel required. There's also a spectrum sense mode which locks on to >> the strongest signal within the 20MHz bandwidth if it is not in the blocked >> frequency list: >> >> https://github.com/m0mik/scanoo >> >> Cheers, >> >> Mike >> >> -- >> Mike Jameson M0MIK BSc MIET >> Email: m...@scanoo.com >> Web: http://scanoo.com >> >> >> On Wed, Aug 21, 2013 at 7:15 PM, Luke B wrote: >> >>> I am working on a processing multiple signals using a single source >>> block. The background is below, but I had a couple of high level questions: >>> >>> - What is the best approach performance wise for selecting multiple >>> ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR >>> Filter with a low-pass? Is it more efficient to use a SIN Sig source & >>> Multiply Block with a low-pass FIR Filter? Is there a better way to extract >>> a filter? >>> >>> - What is the best way to have different bunch of blocks processing >>> each signal run independently and not block each other? I want to do this >>> as a GR C++ program is there any way to run the signal source and >>> chanelizers as one thread and then have the different processing chains >>> run as separate threads? Is there a way to put a queue or buffer >>> inbetween blocks that would allow for a chain of blocks to be separated >>> between threads? >>> >>> Or am I better off doing the basic signal/channel processing for >>> everything in a single process and then writing the results to a file and >>> then having a process which goes through the files and does the more >>> intensive vocoder work in non-real time? >>> >>> Any pointers or examples of how to do threading with GR C++ code would >>> be really helpful. I am not sure of the best architectual approach. >>> >>> >>> Background: >>> I have taken the gr-smartnet code and done a skeleton implementation >>> in C++. I want to process the digital trunking channel and then decode and >>> record the digital audio from all of the different talk groups. Since it is >>> trunked, channels will be randomly be turning on and off and talk groups >>> will be switching from channels. It would be good to have a separate thread >>> for the trunk decoding and the separate digital audio recorders. Ideally, I >>> would like to be able to do this over 8 or 10Mhz using my HackRF. >>> >>> My code, which is working enough to decode the trunking channel, is >>> here: https://github.com/robotastic/sdr >>> >>> Thanks! >>> >>> - Luke >>> >>> ___ >>> 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] inefficient large vectors
Hi Marcus, Yes, I understand the page size limitation. However, if your vector is 1234 bytes, then you can happily allocate 4096 size buffer, but the the block you always give out the multiple of 1234 byes (i.e. 1, 2 or 3 vectors). The address space wrapping would work fine, so the start of the vectors would not be always at the same place. I think it could be done, the question is whether it is worth to do it. Miklos On Wed, Aug 21, 2013 at 9:46 PM, Marcus D. Leech wrote: >> Yes, this is what I am doing, but it is not very nice, and you cannot >> easily mix in blocks that want to work at the stream level. What >> really bugs me that I think the scheduler could figure all out, and >> treat my vectors as a stream, allocate nice buffers (who cares if the >> vector fits in the buffer in an integer multiple times). Am I wrong >> with this? I think this would be a nice further development... Miklos >> >> > The aligned-to-page-size buffer management is due to the way that mmap() is > used to mutliply-map these buffers into the address space. > That only "works" if the sizes are multiples of the native page size. > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > ___ > 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] inefficient large vectors
Hi Martin, Yes, I know of stream tags, but it would just make the blocks complicated: now I can rely on the fact that data is coming in a multiple of the vector length. For now, padding solves my immediate needs, but it is not an ideal solution. Miklos On Wed, Aug 21, 2013 at 11:18 PM, Martin Braun (CEL) wrote: > On Wed, Aug 21, 2013 at 07:59:37PM +0200, Miklos Maroti wrote: >> So is there a way to work with large odd length vectors which does not >> have this buffer allocation problem, and does not require padding? It >> seems to me that it could be supported: regular streams but the vector >> size would be verified separately at connection time and would not be >> used to multiply the item size. Any advice is appreciated... > > Miklos, > > if Johnathan's tips aren't helping, you *might* be able to use tags to > delimit vectors and then pass them as streams of scalars. You then have > to keep up with vector boundaries internally in your block. > > Depending on what your application is, this could be a solution or can > make things even more inefficient. But it's worth a try! > > 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-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ > 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
