Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you so much for your kindly reply.So kindly of you.I understand it. Best regards, zs At 2015-02-02 18:24:25, Martin Braun martin.br...@ettus.com wrote: I'll try and keep it short and simple: First: What's the difference between a cyclic shift and a non-cyclic shift? It means that sub-carriers from one end are moved the other end. So, if we have 8 subcarriers arranged like this: 0, 1, 2, 3, 4, 5, 6, 7 and do a cyclic shift, we get something like 1, 2, 3, 4, 5, 6, 7, 0 Right? OK, here's why this would never even be an issue in practice: As you know, a subcarrier has the same width as the corresponding FFT bin. But you never use all FFT bins. Best example is Wi-Fi, where you have an FFT length of 64 in the modulation/demodulation phase, but only use 52 carriers (outside of the DC carrier). So, all bins at the edge of your Nyquist zone are not used. Using the example before, it would be something like: x, x, 0, 1, 2, 3, x, x Now, if do a shift (cyclic or not) of length 1 (note that in the SC setup, you'd have multiples of 2 for the shift), you get this: x, 0, 1, 2, 3, x, x, x Now, in the implementation, I can copy the left-most 'x' to the right, but what's the point? There's no information there. So I just do a memcpy with an offset. Much simpler, does the same. So, you might be tempted to say non-cyclic or cyclic, it doesn't really matter. In practice, given what I just discussed, that's kind of correct. But, assume you have a really, really big frequency offset. Your relevant carriers will be cut off by the resampling filters (or even the analog filters) before they even hit the FFT. So, you'd have something like this: 1, 2, 3, x, x, x, x, x No shifting, cyclic or non-cyclic, can save you now. So where does this cyclic stuff come from? Well, in the pure discrete domain, when you do frequency shifts by multiplying with complex sinusoids, a frequency offset *will* be cyclic. You might even run into this in reality even, because in Schmidl Cox, before you correct the integer FO, you correct the fine FO with such a sinusoid multiplication. So, cyclic isn't wrong, per se. But it's not really required. However, if you take away a single piece of information from this, let it be this: In practice, you design your parameters such that it doesn't matter if you shift cyclically or non-cyclically. In that case, the latter is less computationally heavy. M On 02/02/2015 09:09 AM, zs wrote: Hi Martin: Thank you in advance.I have read many papers on the topic integer cfo of OFDM.They all said it make the subcarriers cyclic shift. For example: http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm It said Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers... Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, Martin Braun martin.br...@ettus.com wrote: On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ 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] Adding EOB when using Vectors
Thanks Martin,
Unfortunately I couldn't get this to work, even when adding packet_len.
To solve the problem I added another custom sync block called 'add_EOB' that
takes in packet_len and adds EOB on the relevant item.
for(int i=0; inoutput_items; i++)
{
if( nitems_written(0)+i == (d_samples-1)+d_burst_num*d_samples )
{
add_item_tag(0, //stream ID
nitems_written(0)+i,
pmt::string_to_symbol(tx_eob), //tag name
pmt::from_bool(1)//, //set this true to indicate end of burst
//pmt::string_to_symbol(id.str())
);
d_burst_num++;
}
out[i] = in[i];
}
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on behalf of
Martin Braun martin.br...@ettus.com
Sent: 23 January 2015 18:56
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Adding EOB when using Vectors
It hast to be whatever you set it to when you make the block. See the
make() function in the manual for a description.
Cheers,
M
On 01/23/2015 07:20 PM, David Halls wrote:
Thanks. Does it matter what the tag is, does it have to be packet_len?
DH
From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org on
behalf of Martin Braun martin.br...@ettus.com
Sent: 23 January 2015 18:18
To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Adding EOB when using Vectors
Use tagged streams. usrp_sink will place the EOB on your last sample,
even if bursts are of different lengths in that case.
M
On 01/23/2015 06:47 PM, David Halls wrote:
Dear All,
I am trying to use TX_TIME, SOB, EOB. How do I add the EOB when I am
using a vector?
The block I have created takes in vector of 47520 samples, i.e. one
item, I want to add TX_TIME and SOB to the first sample. This is no
problem, I add it to the item. After the following 'vector_to_stream'
conversion, the TX_TIME and SOB map through to item 0, 47520, 95040 etc.
But how do I get the EOB to be on item 47519?
Regards,
David
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
http://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
NOTE: The information in this email and any attachments may be
confidential and/or legally privileged. This message may be read, copied
and used only by the intended recipient. If you are not the intended
recipient, please destroy this message, delete any copies held on your
system and notify the sender immediately.
Toshiba Research Europe Limited, registered in England and Wales
(2519556). Registered Office 208 Cambridge Science Park, Milton Road,
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
http://www.toshiba.eu/research/trl
This email has been scanned for email related threats and delivered
safely by Mimecast.
For more information please visit http://www.mimecast.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
NOTE: The information in this email and any attachments may be confidential
and/or legally privileged. This message may be read, copied and used only by
the intended recipient. If you are not the intended recipient, please destroy
this message, delete any copies held on your system and notify the sender
immediately.
Toshiba
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
I'll try and keep it short and simple: First: What's the difference between a cyclic shift and a non-cyclic shift? It means that sub-carriers from one end are moved the other end. So, if we have 8 subcarriers arranged like this: 0, 1, 2, 3, 4, 5, 6, 7 and do a cyclic shift, we get something like 1, 2, 3, 4, 5, 6, 7, 0 Right? OK, here's why this would never even be an issue in practice: As you know, a subcarrier has the same width as the corresponding FFT bin. But you never use all FFT bins. Best example is Wi-Fi, where you have an FFT length of 64 in the modulation/demodulation phase, but only use 52 carriers (outside of the DC carrier). So, all bins at the edge of your Nyquist zone are not used. Using the example before, it would be something like: x, x, 0, 1, 2, 3, x, x Now, if do a shift (cyclic or not) of length 1 (note that in the SC setup, you'd have multiples of 2 for the shift), you get this: x, 0, 1, 2, 3, x, x, x Now, in the implementation, I can copy the left-most 'x' to the right, but what's the point? There's no information there. So I just do a memcpy with an offset. Much simpler, does the same. So, you might be tempted to say non-cyclic or cyclic, it doesn't really matter. In practice, given what I just discussed, that's kind of correct. But, assume you have a really, really big frequency offset. Your relevant carriers will be cut off by the resampling filters (or even the analog filters) before they even hit the FFT. So, you'd have something like this: 1, 2, 3, x, x, x, x, x No shifting, cyclic or non-cyclic, can save you now. So where does this cyclic stuff come from? Well, in the pure discrete domain, when you do frequency shifts by multiplying with complex sinusoids, a frequency offset *will* be cyclic. You might even run into this in reality even, because in Schmidl Cox, before you correct the integer FO, you correct the fine FO with such a sinusoid multiplication. So, cyclic isn't wrong, per se. But it's not really required. However, if you take away a single piece of information from this, let it be this: In practice, you design your parameters such that it doesn't matter if you shift cyclically or non-cyclically. In that case, the latter is less computationally heavy. M On 02/02/2015 09:09 AM, zs wrote: Hi Martin: Thank you in advance.I have read many papers on the topic integer cfo of OFDM.They all said it make the subcarriers cyclic shift. For example: http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm It said Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers... Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, Martin Braun martin.br...@ettus.com wrote: On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ 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] GUI window position
On Fri, Jan 30, 2015 at 2:08 PM, Jon West west...@gmail.com wrote: Is there any way to set the position of a gui window? Not the position of elements inside the winow, but that actual window itself. For my need I am running multiple flow graphs with TCP sources, so nothing pops up until a TCP connection is established. I'd like the windows to pop up where I want them No, not directly. You'll have to look into the GUI backend you're using (wx or qt) and see how you can use their calls to do this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FOSDEM attendee? Re: 802.15.4 CSS PHY
Hi, that was me ;). I also talked to Bastian Bloessl and we agreed that I will create a pull request to gr-ieee802-15-4 once I finish my master's thesis and have it all cleaned up. In the meantime, you can find my fork of Bastian's repo here: https://github.com/fewu/gr-ieee802-15-4. The branch with my work is called css_phy. Currently I'm working on the synchronization for the CSS PHY. My previous work focused on evaluating PHY and MAC performance with the assumption of perfect sync. It's also not really complete yet (e.g. preamble and PHR are dropped in the receiver because their content is assumed to be known) and endianness might be wrong at some points. But I will try to fix that in the next weeks. Feel free to contact me if you have any questions! Greetings Felix 2015-02-02 7:52 GMT+01:00 Christopher Friedt chrisfri...@gmail.com: Hi list, this is just a shot in the dark, but I forgot to get the name of an attendee during the Internet of #allthethings talk. If you are, or know who is, the person who said he had implemented an 802.15.4 CSS PHY in the question period, please get in touch with me or pass on the message. It would be very beneficial to collect the 15.4 related work into one repository to reuse some amount of code. The 800 900 MHz PHY would be very useful to have in there and would be relatively painless to design. The CSS PHY is obviously much more interesting :-) Also, in particular, any future UWB PHY designers would be helpful. The SDR hardware for such a PHY might be a bit pricey. Even a unit-test driven PHY design would be helpful or simulation. As of this point, I have not heard of any major silicon vendors are even speaking about offering an UWB PHY, so it would be nice to be ahead of the game. Cheers, C ___ 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] UHD Error: recv packet demuxer unexpected sid
Hi Jorge, On 02/02/2015 08:21 AM, Jorge Gallo wrote: Hi Marcus, Many thanks for your answer. I got 3.8 version. linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.008.001-42-g8c87a524 3.8.1 is quite recent; there's only the 3.8.2 Release Candidate that you could update to, so this is good. Then is it USB driver related? Possibly, but it often is. Is it right the way I reconfigure my flowgrahp in order to change my center frequency ? I don't think that has anything to do with the problem at hand. Still: which sampling rate are you using? Can you try with a lower one? Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FOSDEM attendee? Re: 802.15.4 CSS PHY
Hi Christopher, in your talk you mentioned some bugs that you found. Would be great if you could create some patches and a make pull request. If someone is interested in the 800 MHz phy I will look for cheap HW and try to implement them. Best, Bastian On 2015-02-02 15:39, Felix W. wrote: Hi, that was me ;). I also talked to Bastian Bloessl and we agreed that I will create a pull request to gr-ieee802-15-4 once I finish my master's thesis and have it all cleaned up. In the meantime, you can find my fork of Bastian's repo here: https://github.com/fewu/gr-ieee802-15-4. The branch with my work is called css_phy. Currently I'm working on the synchronization for the CSS PHY. My previous work focused on evaluating PHY and MAC performance with the assumption of perfect sync. It's also not really complete yet (e.g. preamble and PHR are dropped in the receiver because their content is assumed to be known) and endianness might be wrong at some points. But I will try to fix that in the next weeks. Feel free to contact me if you have any questions! Greetings Felix 2015-02-02 7:52 GMT+01:00 Christopher Friedt chrisfri...@gmail.com mailto:chrisfri...@gmail.com: Hi list, this is just a shot in the dark, but I forgot to get the name of an attendee during the Internet of #allthethings talk. If you are, or know who is, the person who said he had implemented an 802.15.4 CSS PHY in the question period, please get in touch with me or pass on the message. It would be very beneficial to collect the 15.4 related work into one repository to reuse some amount of code. The 800 900 MHz PHY would be very useful to have in there and would be relatively painless to design. The CSS PHY is obviously much more interesting :-) Also, in particular, any future UWB PHY designers would be helpful. The SDR hardware for such a PHY might be a bit pricey. Even a unit-test driven PHY design would be helpful or simulation. As of this point, I have not heard of any major silicon vendors are even speaking about offering an UWB PHY, so it would be nice to be ahead of the game. Cheers, C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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 -- Dipl.-Inform. Bastian Bloessl Distributed Embedded Systems University of Paderborn, Germany http://www.ccs-labs.org/~bloessl/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] phase shift block
On 02/02/2015 11:20 AM, Johannes Schmitz wrote: Hi, Application Note Synchronization and MIMO Capability with USRP Devices from Ettus includes a phase_shift block in Figure 5. Whatever happend to that block? Can't find it, did it get replaced? Regards Johannes ___ I'll observe that a multiply-const block can be used to effect a phase-shift on complex samples. make the constant math.complex(math.cos(shift_in_radians),math.sin(shift_in_radians)) -- 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] phase shift block
Hi, Application Note Synchronization and MIMO Capability with USRP Devices from Ettus includes a phase_shift block in Figure 5. Whatever happend to that block? Can't find it, did it get replaced? Regards Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issue with Results from GR-CDMA
Frank, see some comments inline. Achilleas Hello sorry for the last message thought i attached my screenshot results at first. I am having some problems as to whether the information from the cdma transmission and reception are accurate. I have posted my screenshots for clarification hopefully. http://imageshack.com/a/img633/757/Yx8B7r.png The first screenshot is from executing the cdma_txrx.grc which seems to test well I believe because moving the sliders around and threshold I am able to notice when it performs tracking and acquisition of the signal automatically. A: I do not recall a noise voltage block in the cdma_txrx application. The SNR is controlled by the slider aptly called EsN0dB. http://imageshack.com/a/img631/8451/CDqdTM.png The second screenshot is me loading two USRP's. This is the execution of the cdma_tx.grc file with the UHD:USRP Sink and its WX GUI FFT Plot. My issue here is the FFT plot doesn't look right to. By the way the channel model for this is AWGN. A: You are saying FFT plot doesn't look right. What is it that you expect to see and you don't ? Can you please elaborate on what does not look right about this? BTW, you don't need the cdma_tx to get this FFT plot: the cdma_txrx should give you exactly the same at the output of the tx. http://imageshack.com/a/img538/7792/1xXqN4.png After running the cdma_tx.grc file, I proceed to go to my other laptop and run the cdma_rx.grc file which is connected to that USRP(UHD USRP SOURCE. The image above is what I get. In the beginning it seems to be acquiring the packets then a few seconds later a lot of invalid packets get detected. Overall all are these images close to what I should be seeing. A: you have not told us anything about your system, so we cannot help you. For instance, what is your hardware setup (daughtercards, carrier frequency, sample rate, etc), what is the expected frequency error, what are the RX parameters that you have set? are they compatible with you working environment? is your laptop handling well the acquisition load (have you checked the load on your CPU cores?) Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CMake/ninja error?
I'm having trouble with Cmake and the produced ninja make-files All seems to go well with Cmake -GNinja, but the commands to produce a .res file is wrong. It includes a /MP E.g. if I do a 'ninja.exe gnuradio-runtime', which gives: [1/2] Building RC object gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gnuradio-runtime.rc.res FAILED: G:/MingW32/bin/CMake/bin/cmcldeps.exe RC ... /MP /bigobj ... /fognuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gnuradio-runtime.rc.res .. fatal error RC1106: invalid option: /MP ninja: build stopped: subcommand failed. Not sure if this is the fault of Cmake, Ninja or GnuRadio. -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ofdm_chanest_vcvc_impl.cc
Hi Martin: Thank you in advance.I have read many papers on the topic integer cfo of OFDM.They all said it make the subcarriers cyclic shift. For example: http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm It said Integer CFO does not introduce ICI between sub-carriers, but does introduce a cyclic shift of data sub-carriers... Is it right?And the source code ofdm_chanest_vcvc_impl.cc is right?Maybe I'm wrong.Can you explain it?Thank you. Best regards, zs At 2015-01-25 19:27:30, Martin Braun martin.br...@ettus.com wrote: On 01/25/2015 08:10 AM, zs wrote: Hi Martin: Thank you for your reply.And we know this block do Estimate channel and coarse frequency offset for OFDM from preambles.And the coarse frequency offset is a integer.And it make the subcarriers cyclic shift.Just illustration as this: No cyclic shift. There must be enough space between the out subcarriers and the Nyquist zone boundaries. Hope this clears things up! And please respond to the list. M ___ 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
