[Discuss-gnuradio] XCVR2450 Daughterboard and its MAX2829 chip
Hi everyone, Thanks for reading this! I'm using the XCVR2450 Daughterboard (together with the USRP1) I was wondering if anyone knows about the MAX2829 Single-/Dual-Band 802.11a/b/g World-Band Transceiver IC on that board. I searched through the datasheet but couldn't really solve my issue. Does anyone know how this chip (or the XCVR2450 in general) behaves with respect to the capture effect? Is there a predefined value for the capture threshold (Capture ratio)? Help would be highly appreciated! Thank you! B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect
Hi LRK, Thanks for the reply! I thought so too, that this capture effect or phase locking or limiting should come from the demodulator or clock recovery block, but looking at the c++ files, I couldn't find anything related to this. Did I miss something? The receiver is connected as follows: self.fmdemod = gr.quadrature_demod_cf(1) self.freq_offset = gr.single_pole_iir_filter_ff(alpha) self.sub = gr.sub_ff() self.clock_recovery = gr.clock_recovery_mm_ff(omega, gain_omega, mu, gain_mu,omega_relative_limit) self.connect(self, self.fmdemod) self.connect(self.fmdemod, (self.sub, 0)) self.connect(self.fmdemod, self.freq_offset, (self.sub, 1)) self.connect(self.sub, self.clock_recovery, self) But looking at eigher gr_clock_recovery_mm_ff.cc http://gnuradio.sourcearchive.com/documentation/3.2.2.dfsg/gr__clock__recovery__mm__ff_8cc-source.html or gr.quadrature_demod_cf.cc http://gnuradio.sourcearchive.com/documentation/3.2.2.dfsg/gr__quadrature__demod__cf_8cc-source.html didn't help me... any suggestions? In front of the demodulator is also the Low pass filter: self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs) best regards, B Quoting LRK : On Thu, Feb 23, 2012 at 03:31:03PM +0100, bjoe...@ee.ethz.ch wrote: > This sounds more like an AGC effect. If the gain gets reduced a bit, >the decoder may not see sync from the weaker jammer. FM or PSK receivers >usually have very fast limiting rather than AGC. Fast limiting is what >you want so you can receive all packets possible. This sounds promissing...! But how would I access the settings from the limiting mechanism or the AGC? I'm using the XCVR2450 Daughterboard on the USRP1. I guess the AGC should be somewhere on there, The gain is set in the hardware but the 'automatic' should be in the software. I think you said you combined the zigbee and tunnel.py. I use the usrp_fft.py to look at the spectrum and adjust the gain slider to be just above the point where the noise baseline starts going up. Mine shows a setting about 34. Then I set my software receive gain there. Obviously the code needs to be similar and I think the UHD code may be a lot different. Your receiver should not need automatic gain control since it should be either fsk or psk. The demodulator should do the limiter part. -- The computer is supposed to work for YOU, not the other way around. LRK gr-user . ovillatx.sytes.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect
Hi, thanks for the hints! I was thinking about the clock recovery too. Its pretty complicated in there, but I keep trying. I just discovered that the performance of sender and receiver also depends on the interpacket times of the sender ... (remember I mentioned before that the sender sends a packet every millisecond while the jammer transmits nonstop (actually the jammer sends nonstop SHR PHR SHR PHR SHR PHR ...)) ... The performance gets worse when I increase the interpacket times at the sender from one millisecond to 10 ms and it drops to 0 % packet delivery rate when I set it to 100ms. Would this confirm that the issue must be in the clock recovery part? However, if there is some lower level behavior, you should rather see damaged packet (such as a preamble in the payload) than only correct (sender) packets, right? When two preambles collide, then the stronger packet is received, if packet and preamble collide then the first packet should be damaged, in the best case containing symbols from the stronger (second) packet at some point. I guess so, but I think its rather going to be nonsence symbols due to different clock recoveries...!? best B Zitat von "Matthias Wilhelm" : Hmm, there is a clock recovery block (gr.clock_recovery_mm_ff) that may lock to the stronger signal. Maybe you can find a way to stop it from changing things after you found an SFD, and turn it on again after the packet. I don't know what the block is doing exactly, but changing its parameter at runtime might have such an effect. However, if there is some lower level behavior, you should rather see damaged packet (such as a preamble in the payload) than only correct (sender) packets, right? When two preambles collide, then the stronger packet is received, if packet and preamble collide then the first packet should be damaged, in the best case containing symbols from the stronger (second) packet at some point. --Matthias Am 23.02.2012 um 12:29 schrieb bjoe...@ee.ethz.ch: Hi, Quote "you can modify the receiver to just continue receiving anyway" This is already done within the packet_sink by saying if (min_threshold < d_threshold or true) hence as soon as the receiver got into the decode_chips loop, it should stay there! ((c == 0xff) should never hapen!) couldn't there be something in some lower level influenceing this behavior? I need to figure out what mechanism it is, that enables the increase in packet delivery rate between sender and receiver. any suggestions? best regards and thanks again B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect
Hi,
Quote "you can modify the receiver to just continue receiving anyway"
This is already done within the packet_sink by saying
if (min_threshold < d_threshold or true)
hence as soon as the receiver got into the decode_chips loop, it
should stay there! ((c == 0xff) should never hapen!)
couldn't there be something in some lower level influenceing this
behavior? I need to figure out what mechanism it is, that enables the
increase in packet delivery rate between sender and receiver.
any suggestions?
best regards and thanks again
B
Zitat von "Matthias Wilhelm" :
Hi,
you should check out ucla_ieee802_15_4_packet_sink.cc, the receiver
checks if a valid chipping sequence for a payload symbol was found
(after synch), and starts searching for a new SFD in case there is
no possibly matching symbol.
...
unsigned char c = decode_chips(d_shift_reg);
if(c == 0xff){ // something is wrong. restart the search for a sync
enter_search();
} ...
What might happen is the following:
preamble, SFD (jammer) -> sync ... payload (jammer) ... first 0 of
preamble (sender) completely destroys a symbol such that the
receiver gives up ... receiver syncs with the rest of the preamble
(sender) and happily receives packet (sender).
To prevent such "re-capture", you can modify the receiver to just
continue receiving anyway, and picking some symbol at random when no
decision can be made. Or you can fiddle with the threshold of how
many chips must match, it may be too conservative (decode_chips
should always return a symbol in this case). I think this is also
what most COTS receivers do, they honor the packet length in the PHY
header and try to find symbols in any case.
--Matthias
Am 23.02.2012 um 11:49 schrieb bjoe...@ee.ethz.ch:
Hi Matthias,
Thanks a lot for your suggestions.
The thing is, one transmitter (jammer) is sending packets nonstop
at a constant transmit power, while the second transmitter (sender)
sends a packet every millisecond or so.
In this scenario, the receiver is always synchronized with the
jammer and even if the signal from the sender is stronger, the
receiver only decodes a fraction of the packets from the sender
(around 1%). This sounds reasonable as the receiver locks itself to
the signal from the jammer when nothing else is around and stays
locked (remains decoding the incoming signal) even if a stronger
signal from the sender arives. (Only between the jammers packets,
when the receiver looks for new preambles, there's a chance for the
receiver to sync with the sender instead of the jammer.)
But at some point, when the signal from the sender is significantly
stronger (around 7-10db), the behavior changes and all the packets
from sender 2 get decoded.
Now it surprised me that this happend at all, that the packet
delivery rate from sender to receiver increased at some point
instead of only relying on the timings of preamble and sfd of
sender and jammer. That's why I'm looking for any phase lock loops
and control mechanisms related to the capture effect.
Any suggestions?
best regards and thanks again for your time
B
Zitat von "Matthias Wilhelm" :
Hi Bjoern,
the receiver uses FM demodulation to track phase changes, and when
two signals collide the stronger one simply has the larger
influence on the overall phase. This is actually a good property,
because you still have the chance to receive one of the colliding
packets.
Do you want to go on receiving the weaker packet? This may be
quite tricky, because you cannot just separate the signals. One
way I can think is successive interference cancelation, first
receive the stronger packet, and subtract its signal and start
receiving the weaker one. There is a ("CS-style") paper on this:
Daniel Halperin, Thomas Anderson, and David Wetherall. 2008.
Taking the sting out of carrier sense: interference cancellation
for wireless LANs. In Proceedings of the 14th ACM international
conference on Mobile computing and networking (MobiCom '08). ACM,
New York, NY, USA, 339-350. DOI=10.1145/1409944.1409983
http://doi.acm.org/10.1145/1409944.1409983
Regards,
Matthias
Am 22.02.2012 um 11:42 schrieb bjoe...@ee.ethz.ch:
Hi everyone,
First of all thanks a lot for any support!
I'm use the UCLA zigbee PHY (IEEE 802.15.4) on three nodes, of
which one is a dedicated receiver and the other two nodes are
transmitting simultaneously (No CSMA!).
I noticed that something like a capture effect is taking place,
meaning that even though the signal is synchronized to a weaker
signal (signal 1), the receiver appears to jump to the stronger
signal (signal 2) as soon as it arrives at the receiver (if the
second signal is significantly stronger then the first one).
I would like to influence this behavior, and hence am looking for
the related parameters. I just can't find them! Does anyone have
a clue where this is happening?
I am using the XCVR2450 Daughterboard
Re: [Discuss-gnuradio] UCLA ZigBee and the Capture Effect
Hi Matthias,
Thanks a lot for your suggestions.
The thing is, one transmitter (jammer) is sending packets nonstop at a
constant transmit power, while the second transmitter (sender) sends a
packet every millisecond or so.
In this scenario, the receiver is always synchronized with the jammer
and even if the signal from the sender is stronger, the receiver only
decodes a fraction of the packets from the sender (around 1%). This
sounds reasonable as the receiver locks itself to the signal from the
jammer when nothing else is around and stays locked (remains decoding
the incoming signal) even if a stronger signal from the sender arives.
(Only between the jammers packets, when the receiver looks for new
preambles, there's a chance for the receiver to sync with the sender
instead of the jammer.)
But at some point, when the signal from the sender is significantly
stronger (around 7-10db), the behavior changes and all the packets
from sender 2 get decoded.
Now it surprised me that this happend at all, that the packet delivery
rate from sender to receiver increased at some point instead of only
relying on the timings of preamble and sfd of sender and jammer.
That's why I'm looking for any phase lock loops and control mechanisms
related to the capture effect.
Any suggestions?
best regards and thanks again for your time
B
Zitat von "Matthias Wilhelm" :
Hi Bjoern,
the receiver uses FM demodulation to track phase changes, and when
two signals collide the stronger one simply has the larger influence
on the overall phase. This is actually a good property, because you
still have the chance to receive one of the colliding packets.
Do you want to go on receiving the weaker packet? This may be quite
tricky, because you cannot just separate the signals. One way I can
think is successive interference cancelation, first receive the
stronger packet, and subtract its signal and start receiving the
weaker one. There is a ("CS-style") paper on this:
Daniel Halperin, Thomas Anderson, and David Wetherall. 2008. Taking
the sting out of carrier sense: interference cancellation for
wireless LANs. In Proceedings of the 14th ACM international
conference on Mobile computing and networking (MobiCom '08). ACM,
New York, NY, USA, 339-350. DOI=10.1145/1409944.1409983
http://doi.acm.org/10.1145/1409944.1409983
Regards,
Matthias
Am 22.02.2012 um 11:42 schrieb bjoe...@ee.ethz.ch:
Hi everyone,
First of all thanks a lot for any support!
I'm use the UCLA zigbee PHY (IEEE 802.15.4) on three nodes, of
which one is a dedicated receiver and the other two nodes are
transmitting simultaneously (No CSMA!).
I noticed that something like a capture effect is taking place,
meaning that even though the signal is synchronized to a weaker
signal (signal 1), the receiver appears to jump to the stronger
signal (signal 2) as soon as it arrives at the receiver (if the
second signal is significantly stronger then the first one).
I would like to influence this behavior, and hence am looking for
the related parameters. I just can't find them! Does anyone have a
clue where this is happening?
I am using the XCVR2450 Daughterboard together with the USRP1.
Any hints, suggestions or detailed help will be highly appreciated!
best regards and thanks a lot,
B
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UCLA ZigBee and the Capture Effect
Hi everyone, First of all thanks a lot for any support! I'm use the UCLA zigbee PHY (IEEE 802.15.4) on three nodes, of which one is a dedicated receiver and the other two nodes are transmitting simultaneously (No CSMA!). I noticed that something like a capture effect is taking place, meaning that even though the signal is synchronized to a weaker signal (signal 1), the receiver appears to jump to the stronger signal (signal 2) as soon as it arrives at the receiver (if the second signal is significantly stronger then the first one). I would like to influence this behavior, and hence am looking for the related parameters. I just can't find them! Does anyone have a clue where this is happening? I am using the XCVR2450 Daughterboard together with the USRP1. Any hints, suggestions or detailed help will be highly appreciated! best regards and thanks a lot, B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] XCVR2450 Phase Lock Loop, AGC and capture effect
Hi everyone, First of all thanks a lot for any support! I am using the XCVR2450 Daughterboard together with the USRP1. My setup consists of two transmitting nodes and one receiving node, in which both transmitters send messages in overlapping time slots. I was wondering how I can access any settings related to the capture effect when receiving two signals. In my opinion either related to the Phase Lock Loop or Automatic Gain Control. Any hints, suggestions or detailed help will be highly appreciated! best regards and thanks a lot, B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] matched filter in UCLA ZigBee PHy
Hi everyone, I'm trying to build a matched filter into the UCLA ZigBee PHy implementation and am not sure where I should place it. I first thought I could put it into the packet sink, but I don't think that this would make a difference to the best match detector implemented there now. Does anyone have any suggestions where it would make the most sense / benefit to place a matched filter? best and thanks for any suggestions, B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_sub_ff.cc
Hi everyone, I saw the file "gr_sub_ff.cc" Does anyone have an idea what this block does? Also, if anyone know where I can find documentations explaining different gnu-blocks in more detail (than the source code only), that would be highly appreciated. Thanks a lot Have a great day, B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths
Hi, thanks at first for the answer so far! In my code are the following lines: chan_coeffs = gr.firdes.low_pass(1.0, # gain sw_decim * self._samples_per_symbol, # sampling rate 1.0, # midpoint of trans. band 0.5, # width of trans. band gr.firdes.WIN_HANN) # filter type self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs) Now I can see that the channel coefficients fed to the fft_filter_ccc are computed at first using the gr.firdes.low_pass() function (Hence, it's a low pass filter :)) Anyway, there's the fourth parameter given to gr.firdes.low_pass function, which is supposed to represent the width of our transmission band. I guess this is the parameter I need to change to have the low pass filter filtering the correct spectrum containing (only) my signal. But a value of 0.5 looks to me a little strange? Is there a translation to Hz or a realation to the center freqeuncy (here 1.0, also strange)? I guess I'm interpreting something wrong here... Can anyone help? best, B Quoting "Tom Rondeau" : On Thu, Sep 8, 2011 at 9:59 AM, wrote: Hi everyone... I'm currently working on/with the UCLA ZigBee Physical Layer implementation on GnuRadio. Now my sender and receiver will change their bandwidth all the time, hence I need to adjust the BandPassFilter at reception accordingly. Now I have seen that the signal goes through the C++ Signal Processing Block "fft_filter_ccc" which, as I assume, filters the signal as a Bandpass filter or low pass, not sure. Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc" and was wondering if anyone of you knows which parameter of this signal processing block responsible is for the width of the filter? best regards, and thank you all for answering... B Hi B, The fft_filter_ccc can be a bandpass, low pass, high pass, etc... it takes as its arguments the decimation factor and the set of taps as a list of complex numbers. Whatever taps you put into it, it will filter based on that. It has a method called set_taps that also takes a list (or std::vector in C++) of complex numbers that you can use to change the filter structure. But whether or not this is really useful to you depends on how fast you need things to change. Using the set_taps function from Python gives you no guarantee about when the taps will change compared to when the samples are flowing through your flowgraph. What sort of information determines the filter structure that you need? If there is something before the filter that knows that a new set of taps is required starting at a particular sample, then the best bet would be to use the stream tagging interface. You could set the tag with the current sample number for when the new taps are required and also pass the set of taps in the tag itself. You would then have to rewrite the gr_fft_filter_ccc to look at the tag stream, pick out the tags when they arrive, and use the taps passed inside the tag to set up your new filter (keep in mind that if you change the number of taps in your filter, the history is going to change, too). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths
Hi everyone... I'm currently working on/with the UCLA ZigBee Physical Layer implementation on GnuRadio. Now my sender and receiver will change their bandwidth all the time, hence I need to adjust the BandPassFilter at reception accordingly. Now I have seen that the signal goes through the C++ Signal Processing Block "fft_filter_ccc" which, as I assume, filters the signal as a Bandpass filter or low pass, not sure. Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc" and was wondering if anyone of you knows which parameter of this signal processing block responsible is for the width of the filter? best regards, and thank you all for answering... B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Received Signal Power ?
Hi all, Thanks for the answer! But isn't there a functionality in the XCVR2450 daughterboard, which already measures the RSSI value? Isn't there like a function which could output this value? Secondly. Capturing the samples right at the output of the USRP, meaning within "gr.fft_filter_ccc" or maybe within the "gr.probe_avg_mag_sqrd_c"? It's strange, the mailing list archive is full of RSSI related posts, but none of which are able to deliver answers to this issue, or am I missing something here? best regards, and thanks again for helping Quoting "Kresimir Dabcevic" : -Original Message- From: discuss-gnuradio-bounces+kresimir.dabcevic=fer...@gnu.org on behalf of bjoe...@ee.ethz.ch Sent: Fri 9/2/2011 10:26 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Received Signal Power ? Hi, I'm using the UCLA ZigBee PHY by Thomas Schmid, with the benchmark example from gnuradio. Now I need the signal power of each received packet (at the receiver). For the signal power computation: P_S = sum ( all samples squared ) divided by number of samples but the problem is where to fetch these samples, and how to make sure, that only samples of the received packet are considered, and no noise... Distinguishing "useful" samples from noise was a problem when I was playing around with UCLA as well. It wasn't an issue when RSS was good, because with power_squelch block, you could filter out the noise. Thus, try setting different TX amplitude / RX gain values in order to get more distinguishable samples. 1. is there a gnuradio block/function which would already perform this task of received signal power computation, or RSSI determination, which I could use/edit for my task? There isn't (or at least wasn't until few months ago, I haven't looked into gnu radio since), so you'll have to extract that yourself. Try searching forum archives for "RSSI measurement", someone (Josh Blum?) explained it to me quite nicely there... 2. If not, where would be the best spot to capture the received samples? As the clock_recovery looks to be too late, and capturing the packets earlier makes it hard to distinguish between noise and received signal, as no clock recovery nor packet detection is performed, yet. It seems that you'll have to capture the samples right at the exit from USRP, no way around that... Regards, Kresimir ___ 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] how to change the GRC block shape , size and background of GRC window
Hi, I'm using the UCLA ZigBee PHY by Thomas Schmid, with the benchmark example from gnuradio. Now I need the signal power of each received packet (at the receiver). For the signal power computation: P_S = sum ( all samples squared ) divided by number of samples but the problem is where to fetch these samples, and how to make sure, that only samples of the received packet are considered, and no noise... 1. is there a gnuradio block/function which would already perform this task of received signal power computation, or RSSI determination, which I could use/edit for my task? 2. If not, where would be the best spot to capture the received samples? As the clock_recovery looks to be too late, and capturing the packets earlier makes it hard to distinguish between noise and received signal, as no clock recovery nor packet detection is performed, yet. I'd appreciate any help, thanks in advanced! Quoting "Josh Blum" : On 09/01/2011 11:55 PM, patiljagdish154 wrote: hi , i am working on GNURadio since long time . can anyone tell me how to change the look of GRC . is it possible through *.xml file ? thanks.. most of those setting are in here http://gnuradio.org/cgit/jblum.git/tree/grc/gui/Colors.py http://gnuradio.org/cgit/jblum.git/tree/grc/gui/Constants.py -josh ___ 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] Received Signal Power ?
To be more precise, I don't need a calibrated dB value, I just need a value, that is at least proportional to the received signal power. best regards, and thanks again for any help Quoting bjoe...@ee.ethz.ch: Hi, I'm using the UCLA ZigBee PHY by Thomas Schmid, with the benchmark example from gnuradio. Now I need the signal power of each received packet (at the receiver). For the signal power computation: P_S = sum ( all samples squared ) divided by number of samples but the problem is where to fetch these samples, and how to make sure, that only samples of the received packet are considered, and no noise... 1. is there a gnuradio block/function which would already perform this task of received signal power computation, or RSSI determination, which I could use/edit for my task? 2. If not, where would be the best spot to capture the received samples? As the clock_recovery looks to be too late, and capturing the packets earlier makes it hard to distinguish between noise and received signal, as no clock recovery nor packet detection is performed, yet. I'd appreciate any help, thanks in advanced! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Received Signal Power ?
Hi, I'm using the UCLA ZigBee PHY by Thomas Schmid, with the benchmark example from gnuradio. Now I need the signal power of each received packet (at the receiver). For the signal power computation: P_S = sum ( all samples squared ) divided by number of samples but the problem is where to fetch these samples, and how to make sure, that only samples of the received packet are considered, and no noise... 1. is there a gnuradio block/function which would already perform this task of received signal power computation, or RSSI determination, which I could use/edit for my task? 2. If not, where would be the best spot to capture the received samples? As the clock_recovery looks to be too late, and capturing the packets earlier makes it hard to distinguish between noise and received signal, as no clock recovery nor packet detection is performed, yet. I'd appreciate any help, thanks in advanced! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to change the GRC block shape , size and background of GRC window
Sorry, wrong Subject! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] access clock_recovery values from packet_sink
Hi, I'm currently using the UCLA ZigBee PHY implementation by Thomas Schmid and have got the following question: In the file "clock_recovery_mm_ff.cc" is a parameter "omega", which I would like to change from within "ucla_ieee802_15_4_packet_sink.cc". Now there is the public function: void set_omega(float omega) but I wasn't able to access it from within the packet_sink. Does anyone have a clue/idea how I could achieve this? best regards and thank you for any help! Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ignoring every second entry in shift register
Hi, I'm using UCLA ZigBee Phy by thomas schmid: Now i try to ignore every second entry of the variable d_shift_reg in the file ucla_ieee802_15_4_packet_sink.cc. Does anyone have an idea how i could implement something like that? best regards and thank you for any answers, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, I'm using the UCLA ZIGBEE PHY implementation by Thomas Schmid: Does anyone have an idea, how I could build a connection/communication between the files/functions in the files: - ucla_clock_recovery_ff_mm.cc - ucla_ieee802_15_4_packet_sink.cc such that a variable within clock_recovery is changed whenever a symbol has been successfully decoded in the packet_sink? Well I only need to know how I could build up this connection between the two files mentioned above. Does anyone have an idea? I appreciate any comments on this... best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi I figured it out... the problem was just the sender itself. I forgot to change the parameter: static const int SAMPLES_PER_SYMBOL = 4; to: static const int SAMPLES_PER_SYMBOL = 8; in "ucla_qpsk_modulator_cc.cc" At the receiver side, I actually only had to change the variable "sps". I guess the filter and clock recovery still work, as the parameter of those are influenced by the variable sps. Well thank you for all your help! I hope I can get even some day... best regards, Bjorn Quoting "Matthias Wilhelm" : Am 29.07.2011 um 13:44 schrieb bjoe...@ee.ethz.ch: Hi again, Thanks a lot for your mail from yesterday! In order to figure out what changes are needed at the receiver, I do not change the bandwidth per symbol, but constantly, by using the following lines within ucla_qpsk_modulator_cc.cc. *out++ = gr_complex(0.0, 0.0); *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953); *out++ = gr_complex(iphase, qphase); *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343); Now in the file: ieee802_15_4.py @ ieee802_15_4_demod I have changed the variable sps from 2 to 4, as previously suggested. The result is, that the receiver receives half the packet correctly, and the whole second half appears to be random. I don't think that we need to change the file "ucla_ieee802_15_4_packet_sink.cc" in this case. Now it would be great if I could just tweak the parameters in "ieee802_15_4_demod", but how? clock_recovery and the iir filter are gnuradio specific functions, hence tweaking the parameters should in general work in a constant BW case, right? Do you have any suggestions on those parameters? many thanks and have a good weekend soon, Bjorn Hi, to clarify, do you get a good half packet each time a packet arrives, or are 50% of the packets good and 50% broken (or undetected)? I understand that you have something like (g means good symbol, b means bad): g for all packets you see, which would be a rather strange behavior. It would suggest that everything is working fine and robust for the first half, and somehow breaks down in-between. My remote diagnose in this case is that the state machine in the packet sink detects the preamble and SFD (and maybe the header as well) for each packet, but has some hard-coded parts that expects the default bandwidth, producing arbitrary results for the rest of the packet. You should check how far the state machine works correctly, and debug the problem case. You can active the debug symbols in the UCLA code (VERBOSE and VERBOSE2) to see what is happening in the state machine of the receiver. If it's 50/50% good/bad packets, then I would suspect the timing recovery, but the parameters are also rather magical for me. But I think its the standard(?) Mueller&Müller clock recovery algorithm, so there should be some info in textbooks how it works and what parameters are suitable. I found this: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg12723.html Regards, Matthias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi,, As it turns out, the verbose output isn't that helpful either. It just reveals that at some point, the chip-error rate increases drastically. See the verbose output of receiving one packet below: Found 0 in chip sequence Found 1 0 in chip sequence Found 2 0 in chip sequence Found 3 0 in chip sequence Found 4 0 in chip sequence Found 5 0 in chip sequence Found 6 0 in chip sequence Found 7 0 in chip sequence Found first SFD Found sync, 0x7a @ enter_have_sync Header Search bitcnt=0, header=0x Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 @ enter_have_header (payload_len = 25) Packet Build count=101, noutput_items=256, packet_len=25 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 0, payloadcnt: 0, payload 0x1, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 1, payloadcnt: 1, payload 0x0, d_packet_byte_index: 2 Packet Build count=0, noutput_items=132, packet_len=25 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 2, payloadcnt: 2, payload 0xff, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 3, payloadcnt: 3, payload 0xb, d_packet_byte_index: 2 Packet Build count=0, noutput_items=512, packet_len=25 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 4, payloadcnt: 4, payload 0xb, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 5, payloadcnt: 5, payload 0xb, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 6, payloadcnt: 6, payload 0xb, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 7, payloadcnt: 7, payload 0xb, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 8, payloadcnt: 8, payload 0xb, d_packet_byte_index: 2 Found sequence with 0 errors at 0x0 Found sequence with 0 errors at 0x0 packetcnt: 9, payloadcnt: 9, payload 0xb, d_packet_byte_index: 2 Found sequence with 11 errors at 0x10c99928 Found sequence with 13 errors at 0x330985b8 packetcnt: 10, payloadcnt: 10, payload 0x9e, d_packet_byte_index: 2 Found sequence with 11 errors at 0x1350324a Found sequence with 11 errors at 0x24a50958 packetcnt: 11, payloadcnt: 11, payload 0xfc, d_packet_byte_index: 2 Packet Build count=0, noutput_items=508, packet_len=25 Found sequence with 11 errors at 0x24688e44 Found sequence with 10 errors at 0x4938588 packetcnt: 12, payloadcnt: 12, payload 0x97, d_packet_byte_index: 2 Found sequence with 12 errors at 0x3046c256 Found sequence with 10 errors at 0x6ac08430 packetcnt: 13, payloadcnt: 13, payload 0x93, d_packet_byte_index: 2 Found sequence with 10 errors at 0x585a8018 Found sequence with 8 errors at 0x3550840 packetcnt: 14, payloadcnt: 14, payload 0x19, d_packet_byte_index: 2 Found sequence with 11 errors at 0x340181ba Found sequence with 10 errors at 0x540910c6 packetcnt: 15, payloadcnt: 15, payload 0xdf, d_packet_byte_index: 2 Found sequence with 6 errors at 0x5210082 Found sequence with 9 errors at 0x10a224c2 packetcnt: 16, payloadcnt: 16, payload 0xb9, d_packet_byte_index: 2 Found sequence with 10 errors at 0x4c2852a0 Found sequence with 12 errors at 0x42d28a86 packetcnt: 17, payloadcnt: 17, payload 0xac, d_packet_byte_index: 2 Found sequence with 10 errors at 0x26465804 Found sequence with 10 errors at 0x53e02280 packetcnt: 18, payloadcnt: 18, payload 0xfa, d_packet_byte_index: 2 Found sequence with 11 errors at 0x10964dc Found sequence with 9 errors at 0xa202466 packetcnt: 19, payloadcnt: 19, payload 0xbd, d_packet_byte_index: 2 Packet Build count=0, noutput_items=512, packet_len=25 Found sequence with 11 errors at 0x4a502e6 Found sequence with 10 errors at 0x30a641c packetcnt: 20, payloadcnt: 20, payload 0x70, d_packet_byte_index: 2 Found sequence with 11 errors at 0x3c47308 Found sequence with 10 errors at 0x2612aa20 packetcnt: 21, payloadcnt: 21, payload 0xe1, d_packet_byte_index: 2 Found sequence with 10 errors at 0x18e32210 Found sequence with 12 errors at 0x4836a622 packetcnt: 22, payloadcnt: 22, payload 0x53, d_packet_byte_index: 2 Found sequence with 11 errors at 0x68c13908 Found sequence with 12 errors at 0x2d14189a packetcnt: 23, payloadcnt: 23, payload 0x6f, d_packet_byte_index: 2 Found sequence with 12 errors at 0x4a170938 Found sequence with 11 errors at 0x4c059924 packetcnt: 24, payloadcnt: 24, payload 0xc3, d_packet_byte_index: 2 Adding message of size 25 to queue @ enter_search received packet payload: ['0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0x9e', '0xfc', '0x97', '0x93', '0x19', '0xdf', '0xb9', '0xac', '0xfa', '0xbd', '0x70', '0xe1', '0x53', '0x6f', '0xc3'] checksum: 14309, received: 50031 Rx: ok = False len(payload) = 20 802_15_4_pkt: waiting for packet Quoting "Matt
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, Well its the first case (strange behavior) (g means good symbol, b means bad): g more precisely, Preamble, SFD, packet length (PHR) is all received correctly. Additionally, also a part of the payload is received correctly. Here an example: I send the following packet: ['0x0', '0x0', '0x0', '0x0', '0xa7', '0x19', '0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0x68', '0x44', '0x0'] and receive the following: ['0x0', '0x0', '0x0', '0x0', '0xa7', '0x19', '0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xca', '0x8f', '0x45', '0xa5', '0x79', '0xab', '0x35', '0x9a', '0x8c', '0x32', '0xf9', '0x8c', '0xa0', '0xba', '0x2'] If this would be during the packet_sink, then the error would occur somewhere in the middle of decode_chips()... best regards, and thanks again Bjorn Quoting "Matthias Wilhelm" : Am 29.07.2011 um 13:44 schrieb bjoe...@ee.ethz.ch: Hi again, Thanks a lot for your mail from yesterday! In order to figure out what changes are needed at the receiver, I do not change the bandwidth per symbol, but constantly, by using the following lines within ucla_qpsk_modulator_cc.cc. *out++ = gr_complex(0.0, 0.0); *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953); *out++ = gr_complex(iphase, qphase); *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953); *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678); *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343); Now in the file: ieee802_15_4.py @ ieee802_15_4_demod I have changed the variable sps from 2 to 4, as previously suggested. The result is, that the receiver receives half the packet correctly, and the whole second half appears to be random. I don't think that we need to change the file "ucla_ieee802_15_4_packet_sink.cc" in this case. Now it would be great if I could just tweak the parameters in "ieee802_15_4_demod", but how? clock_recovery and the iir filter are gnuradio specific functions, hence tweaking the parameters should in general work in a constant BW case, right? Do you have any suggestions on those parameters? many thanks and have a good weekend soon, Bjorn Hi, to clarify, do you get a good half packet each time a packet arrives, or are 50% of the packets good and 50% broken (or undetected)? I understand that you have something like (g means good symbol, b means bad): g for all packets you see, which would be a rather strange behavior. It would suggest that everything is working fine and robust for the first half, and somehow breaks down in-between. My remote diagnose in this case is that the state machine in the packet sink detects the preamble and SFD (and maybe the header as well) for each packet, but has some hard-coded parts that expects the default bandwidth, producing arbitrary results for the rest of the packet. You should check how far the state machine works correctly, and debug the problem case. You can active the debug symbols in the UCLA code (VERBOSE and VERBOSE2) to see what is happening in the state machine of the receiver. If it's 50/50% good/bad packets, then I would suspect the timing recovery, but the parameters are also rather magical for me. But I think its the standard(?) Mueller&Müller clock recovery algorithm, so there should be some info in textbooks how it works and what parameters are suitable. I found this: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg12723.html Regards, Matthias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi again,
Thanks a lot for your mail from yesterday!
In order to figure out what changes are needed at the receiver, I do
not change the bandwidth per symbol, but constantly, by using the
following lines within ucla_qpsk_modulator_cc.cc.
*out++ = gr_complex(0.0, 0.0);
*out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
*out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
*out++ = gr_complex(iphase, qphase);
*out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
*out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);
Now in the file: ieee802_15_4.py @ ieee802_15_4_demod
I have changed the variable sps from 2 to 4, as previously suggested.
The result is, that the receiver receives half the packet correctly,
and the whole second half appears to be random.
I don't think that we need to change the file
"ucla_ieee802_15_4_packet_sink.cc" in this case.
Now it would be great if I could just tweak the parameters in
"ieee802_15_4_demod", but how?
clock_recovery and the iir filter are gnuradio specific functions,
hence tweaking the parameters should in general work in a constant BW
case, right?
Do you have any suggestions on those parameters?
many thanks and have a good weekend soon,
Bjorn
Quoting "Matthias Wilhelm" :
Am 28.07.2011 um 15:56 schrieb bjoe...@ee.ethz.ch:
Hi,
Do you by any chance know where the corresponding part to:
*out++ = gr_complex(0.0, 0.0);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
*out++ = gr_complex(iphase, qphase);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
is at the receiver?
Could it be that this is in the file: gr_quadrature_demod_cf.cc
for (int i = 0; i < noutput_items; i++){
gr_complex product = in[i] * conj (in[i-1]);
// out[i] = d_gain * arg (product);
out[i] = d_gain * gr_fast_atan2f(imag(product), real(product));
}
that i need to change this part?
best regards, and thanks for your reply
Bjorn
Hi,
reception is a bit trickier ...
The receiver flow graph is constructed in
src/python/ieee802_15_4_pkt.py in class ieee802_15_4_demod_pkts. It
is basically [ ieee802_15_4_demod -> packet_sink/message queue ],
first doing an FM demod, filtering, and clock recovery, then the
packet sink is searching for chips and keep track of the receiver
state (search preamble, SFD, frame content, ...).
I think you need to change two parts:
1) src/python/ieee_802_15_4.py, at the class ieee802_15_4_demod,
make it work at the highest bandwidth you need. quadrature_demod_cf
should work fine (the chips are decided by a slicer, so sample > 0
-> "1" and sample < 0 -> "0", a larger bandwidth only leads to
larger samples after FM demod). There is the variable sps (samples
per symbol), try to increase it for more samples. You must also make
sure that the filter and clock recovery do the right thing, so tweak
the parameters accordingly (no idea how to get the clock recovery
working across several rates). Since at this point you don't know
anything about symbols and their rates, your hope is to modify the
blocks available to support all rates simultaneously.
2) The packet sink (the code is in
src/lib/ucla_ieee802_15_4_packet_sink.cc) expects a fixed rate, so
you should increase the used sampling rate and decimate the low
bandwidth symbols correctly when they arrive (or maybe this is
already solved by clock recovery somehow).
The transmitter must send the preamble with a known rate so that you
know what to look for (to be able to find out when the first real
symbol starts), and then use if clauses again to decimate. For this
to work, the receiver must know beforehand which rate the symbols in
the preamble are in and what the schedule for the packet is, if you
want to find that out on the fly, you will likely have to
re-implement larger parts of the receiver.
Regards,
Matthias
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi,
Do you by any chance know where the corresponding part to:
*out++ = gr_complex(0.0, 0.0);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
*out++ = gr_complex(iphase, qphase);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
is at the receiver?
Could it be that this is in the file: gr_quadrature_demod_cf.cc
for (int i = 0; i < noutput_items; i++){
gr_complex product = in[i] * conj (in[i-1]);
// out[i] = d_gain * arg (product);
out[i] = d_gain * gr_fast_atan2f(imag(product), real(product));
}
that i need to change this part?
best regards, and thanks for your reply
Bjorn
Zitat von "Matthias Wilhelm" :
Hi,
I think you need to change the the O-QPSK modulator, it's in
src/lib/ucla_qpsk_modulator_cc.
Currently, for each chip, it expects 2MChips/s and produces 4
complex samples that specify the shape of the pulse (half a sine
wave up for chip "1" and down for chip "0" or -1):
*out++ = gr_complex(0.0, 0.0);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
*out++ = gr_complex(iphase, qphase);
*out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
If you add more samples per pulse by interpolating in-between (say
8), you halve the bandwidth while using the same chipping sequence,
using only 2 samples doubles it (when you use a fixed sampling rate).
So if you want to increase the bandwidth, you should first adjust
the default sampling rate/decimation of the ZigBee code as defined
in the python script when initiating the USRP source, from 4MSamples
(decim 16) to a higher value, and adjust the modulation block
accordingly (e.g., decim 8 -> use 8 samples/chip), so that you
still have several samples per chip even on larger bandwidths (to
generate smooth pulses).
The changes are then straight-forward, you just specify different
cases/if clauses and produce a different number of samples for each
symbol (i.e., for a sequence of 32 chips), depending on the
bandwidth you want.
The larger problem may be how to get the "schedule" information from
python to the C code so that it's synchronized with the sampling
stream, I don't have much experience on how you can achieve this in
GNU Radio. I think there is a way to attach meta-data to a stream of
samples ... Another approach is in-band signaling (interleaving
special tags into the stream of samples that change settings in the
blocks and are filtered out in the end), but I think it's more of a
hack than sound design.
Matthias
Am 27.07.2011 um 15:22 schrieb bjoe...@ee.ethz.ch:
Hi,
Thanks a lot for your reply!
This is exactly what I was looking for!
Would you by any chance have an idea in what C level files I could
manipulate the interpolation?
best regards and thank you,
Bjorn
Zitat von "Matthias Wilhelm" :
Hi,
i think this would be hard on the python level, you would need to
notify the python code after each symbol to make adjustments,
which will lead to latency between symbols ...
(As I understand you want to keep the chipping sequences, but
change the sampling rate used for each symbol. You can have the
same effect by changing the interpolation between samples, keeping
the rate constant, and oversampling small bandwidths. )
For this, I would suggest that you add a "per packet schedule"
that specifies the bandwidth of each symbol, and hack the C code
to follow the schedule, changing the interpolation between chips
for each symbol.
Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning
1MChips/s for the first symbol, 2MChips/s (the default) for the
second, then 8MChips/s, etc. The benefit is that you can go on
working on the packet level in python.
On the C side, you would need to run the flow graph at 16MSamples
(to get 2 samples per chip @ 8MChips/s, basically fast enough to
support the largest bandwidth you want), and decide for each
symbol the necessary interpolation to generate the specified
bandwidth (e.g., 16 samples/chip @1MChips/s).
Regards,
Matthias
Am 27.07.2011 um 13:31 schrieb bjoe...@ee.ethz.ch:
Hi,
I'm currently using the UCLA ZigBee Phy implementation by Thomas
Schmid and I need to
change the Bandwidth of the used wireless channel on a per symbol basis.
I managed to change it on a per packet basis, which can be done
on the python level
(tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do
the same thing, but on a
per symbol basis, which (up to my knowledge) is not possible from
the python level...
Does anyone have an idea how I could do that? (Changing the
Bitrate of the USRP after
each symbol (e.g. after sending 32 modulated bits (actually chips)))
I would be very happy for any help or suggestions!
Thanks a lot!
best regards,
Bjorn
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
__
Re: [Discuss-gnuradio] Bandwidth switching per symbol
Hi, Thanks a lot for your reply! This is exactly what I was looking for! Would you by any chance have an idea in what C level files I could manipulate the interpolation? best regards and thank you, Bjorn Zitat von "Matthias Wilhelm" : Hi, i think this would be hard on the python level, you would need to notify the python code after each symbol to make adjustments, which will lead to latency between symbols ... (As I understand you want to keep the chipping sequences, but change the sampling rate used for each symbol. You can have the same effect by changing the interpolation between samples, keeping the rate constant, and oversampling small bandwidths. ) For this, I would suggest that you add a "per packet schedule" that specifies the bandwidth of each symbol, and hack the C code to follow the schedule, changing the interpolation between chips for each symbol. Something like send_802_15_4_pkt (packet, "1,2,8,2,4,1"), meaning 1MChips/s for the first symbol, 2MChips/s (the default) for the second, then 8MChips/s, etc. The benefit is that you can go on working on the packet level in python. On the C side, you would need to run the flow graph at 16MSamples (to get 2 samples per chip @ 8MChips/s, basically fast enough to support the largest bandwidth you want), and decide for each symbol the necessary interpolation to generate the specified bandwidth (e.g., 16 samples/chip @1MChips/s). Regards, Matthias Am 27.07.2011 um 13:31 schrieb bjoe...@ee.ethz.ch: Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ 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] Bandwidth switching per symbol
Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bandwidth switching per symbol
Hi, I'm currently using the UCLA ZigBee Phy implementation by Thomas Schmid and I need to change the Bandwidth of the used wireless channel on a per symbol basis. I managed to change it on a per packet basis, which can be done on the python level (tunnel.py, usrp_transmit_path.py etc.). Well now, I need to do the same thing, but on a per symbol basis, which (up to my knowledge) is not possible from the python level... Does anyone have an idea how I could do that? (Changing the Bitrate of the USRP after each symbol (e.g. after sending 32 modulated bits (actually chips))) I would be very happy for any help or suggestions! Thanks a lot! best regards, Bjorn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA ZigBee PHY 64 chip-sequences
Thanks for the reply! Any other suggestions? I'm trying to change the UCLA ZigBee PHY to do spreading and despreading using a table of 16 64-chip-sequences instead of the 16 32-chip sequences. The files I have edited are listed below. Now, as it is still not working, I'm looking for hints, suggestions or anything at all, whether there might be more code to edit in order to achieve this goal... best regards and thanks a lot for the help Quoting "Jason Uher" : [Hide Quoted Text] I have experience with the code, but you might try grep to find references to old number of bits or variables. Jason On Mon, Aug 16, 2010 at 11:34 AM, wrote: Hi everyone, I use the UCLA ZigBee PHYsical Layer with gnuradio and USRP. And now I try to increase the number of chips per symbol within the Symbol-to-chips-table from 32 chips per 4 bit symbol to 64 chips. I adopted the three files - "ucla_ieee802_15_4_packet_sink.cc" - "ucla_ieee802_15_4_packet_sink.h" and - "ucla_symbols_to_chips_bi.cc" . I also generated a 64 bit Symbol_Table, CHIP_MAPPING respectively using the OQPSK -> MSK encoding as described in the papaer: "GNU Radio 802.15.4 En- and Decoding" But still it is not working. I assume that there might be some other parts of the code, which depend on whether the chip-sequences are 32 chips or 64 chips and I was wondering if you might be able to give me a hint where to look!? Even after going through the files from UCLA, i couldn't figure out where this might be!? Help would be highly appreciated! Thanks a lot for your help, Best regards, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UCLA ZigBee PHY 64 chip-sequences
Hi everyone, I use the UCLA ZigBee PHYsical Layer with gnuradio and USRP. And now I try to increase the number of chips per symbol within the Symbol-to-chips-table from 32 chips per 4 bit symbol to 64 chips. I adopted the three files - "ucla_ieee802_15_4_packet_sink.cc" - "ucla_ieee802_15_4_packet_sink.h" and - "ucla_symbols_to_chips_bi.cc" . I also generated a 64 bit Symbol_Table, CHIP_MAPPING respectively using the OQPSK -> MSK encoding as described in the papaer: "GNU Radio 802.15.4 En- and Decoding" But still it is not working. I assume that there might be some other parts of the code, which depend on whether the chip-sequences are 32 chips or 64 chips and I was wondering if you might be able to give me a hint where to look!? Even after going through the files from UCLA, i couldn't figure out where this might be!? Help would be highly appreciated! Thanks a lot for your help, Best regards, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP digital downconverters
Hi, It sais, that the USRP digital downconverters have a programmable decimation rate. What does this decimation rate do? Is this the filter restricting the frequencies of the signal + noise? And how do I change this decimation rate? Thanks a lot for your help! best, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_fft.py axis values and units
Zitat von "Martin Braun" : On Thu, Jul 15, 2010 at 10:51:58AM +0200, bjoe...@ee.ethz.ch wrote: Thanks a lot for the reply! But I have some follow-up questions: About the statement above: "There are other methods for estimating SNR if you indeed want to get that calculation.": What I need to measure is the following: I need the Transmit Power of the USRP (Pt) and the Noise Power at the Input of the USRP (Pn), and if possible also the Received-Signal Power (Pr). These values would then enable me to calculate SNR, distance between Sender and Receiver (of course with an appropriate Path-Loss Model), etc. Those values will then be used for some other calculations and Measurements. Of course it would be great if the measuring of Pn, Pt, Pr would be possible using the USRP itself (e.g. using the usrp_oscilloscope or usrp_fft), but if this is really that bad I'd be happy to get some other suggestions. Any Ideas? Hi Björn, this gets asked so often on this mailing list--you should have another browse through the archives. And like everyone else, I will tell you it's not that easy; measuring real powers means tedious calibration, and even then, it will only work reliably once, and for one specific setup. Even if you had Pt and Pr, calculating SNR still depends on many things. E.g., the typically given equation for a BER for BPSK modulation in AWGN depending on SNR assumes a very specific SNR value (i.e., the noise distributed over the bandwidth related to the pulse shaping filter). For digital signal processing purposes, you very rarely actually need true powers (although of course I don't know what you're up to), but there's usually a way to _estimate_ SNR (for a given definition of SNR) for a specific application. Cheers MB An approximation of those values wouldn't be bad either! But thanks for the reply! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and XCVR2450 Noise Figure
Zitat von "Matt Ettus" : On 07/15/2010 08:51 AM, Jeffrey Lambert wrote: Hello, The noise figure will in large part depend upon the receiver front-end that is attached the USRP or in the daughter board that is used. In that case that you would like to know the noise figure of the USRP without any RF front-end then the results may vary whether you are using a BasicRX board or one of the LFRX boards. For a 50 Ohm system, either of these should yield accurate results. Mainly, the noise figure of the USRP will be derived from the AD9862 digitizer. Since this IC contains an amplifier, the noise figure will vary with the gain of the PGA. I too am interested in measuring the noise figure of the USRP. If you are unable to find anything, I will be able to supply measurement data within the next few weeks for a USRP device and BasicRX daughterboard. The USRP + BasicRX will have a noise figure of around 35dB, since it has no amplification. If designing a daughterboard, you can use that number as the noise figure of the ADC for your calculations of the overall noise figure. Matt Hi, Thanks a lot for your help! Can I also use those 35db as the total noise at the input of the USRP to compute the signal to noise ratio? For that I'd also need the transmitting Power Pt. Would you by any chance also have an idea how i could figure out Pt? best and thanks a lot! Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP and XCVR2450 Noise Figure
Hi, I was wondering if anyone found a datasheet of the USRP and/or XCVR2450 which contain the Noise Figure of those devices, or at least of a combination of the two!? best and thanks a lot, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_fft.py axis values and units
Quoting "Brian Padalino" : On Wed, Jul 14, 2010 at 9:30 AM, wrote: Hi, I'm currently using USRP, GNU Radio and the file usrp_fft.py to find the Signal-to-noise ratio, Noise- and Signal-power. I use the ZigBee PHY from Thomas Schmid to generate the signals at 2.412GHz. My questions are the following: 1. In usrp_fft.py are the axis denoted as "amplitude [db]" and of course "frequency". Now in order to deduce the signal strength or the noise strength respectively, I need the reference amplitude used to compute the db value. In the code there is the setting "--ref-scale" and it's default value is 13490.0. Now is this reference Amplitude 13490.0 mV? (look at units -> milli-volts) It sounds like you're trying to figure out SNR based on an FFT. If that's the case, I don't recommend that. There are plenty of in-band noise sources that would be counted as signal when, in fact, they are noise. There are other methods for estimating SNR if you indeed want to get that calculation. I don't think the amplitude maps directly to milli-volts. The units are literally the integer values after filtering. You need to take into account any gains in the system before and after the digital converter. As a rudimentary example, if you had a converter which gave signed 14-bit numbers (+/- 8191), you may want to set the reference to be 84.28dB (6.02dB/bit * 14bits) and figure out how far down from full scale input you are (this will be a negative number as 84.28dB should be your top end). You can then add and subtract the overall system gain from that point to figure out what power levels are at different locations in the system. NOTE: This is something that requires you to understand all the gains in the entire system. Does that make sense to you? 2. How can I get from here to the signal-power and noise-power? Or maybe the signal-strength isn't bad either... (I need those values to find the transmitting power of the USRP, I guess it could be 1mW, but don't know how to check that) If you just want to find the transmitting power of the USRP, just connect the antenna spigot to a 50Ohm terminated load, set your USRP to output a vector of (1+0i) and measure the voltage. You now know V and R as well as the fact it's a single carrier tone - calculating power should be easy. You can then compare that in ratio to 1mW to calculate dBm. Calculating the exact noise power, on the other hand, ends up being a much more difficult problem. Thanks a lot for your help! best, Björn Good luck. Brian Hi, Thanks a lot for the reply! But I have some follow-up questions: About the statement above: "There are other methods for estimating SNR if you indeed want to get that calculation.": What I need to measure is the following: I need the Transmit Power of the USRP (Pt) and the Noise Power at the Input of the USRP (Pn), and if possible also the Received-Signal Power (Pr). These values would then enable me to calculate SNR, distance between Sender and Receiver (of course with an appropriate Path-Loss Model), etc. Those values will then be used for some other calculations and Measurements. Of course it would be great if the measuring of Pn, Pt, Pr would be possible using the USRP itself (e.g. using the usrp_oscilloscope or usrp_fft), but if this is really that bad I'd be happy to get some other suggestions. Any Ideas? best and thanks a lot for your help! Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_fft.py axis values and units
Hi, I'm currently using USRP, GNU Radio and the file usrp_fft.py to find the Signal-to-noise ratio, Noise- and Signal-power. I use the ZigBee PHY from Thomas Schmid to generate the signals at 2.412GHz. My questions are the following: 1. In usrp_fft.py are the axis denoted as "amplitude [db]" and of course "frequency". Now in order to deduce the signal strength or the noise strength respectively, I need the reference amplitude used to compute the db value. In the code there is the setting "--ref-scale" and it's default value is 13490.0. Now is this reference Amplitude 13490.0 mV? (look at units -> milli-volts) 2. How can I get from here to the signal-power and noise-power? Or maybe the signal-strength isn't bad either... (I need those values to find the transmitting power of the USRP, I guess it could be 1mW, but don't know how to check that) Thanks a lot for your help! best, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to use boost-python to get a shared memory block between c++ and python
Hi, I'm currently working on a project using the ucla ZigBee Phy implementation for the gnuradio framework. I need some help how to use boost python and smart pointers to manage a shared memory block from both sides, the python and the c++ side. It would be great if I could manipulate as little as possible on the c++ side. The goal is, to be able to write to the memory block from the python side and read from it from the c++ side. Is there anyone here who is familiar with boost-python who might be kind enough to help me!? That would be highly appreciated! Thank you very much for your help best regards, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block
Zitat von "Markus Becker" : >> >>> Hi, >> >>> >> >>> I'm currently using the UCLA ZigBee PHY implementation posted on: >> >>> https://www.cgran.org/wiki/UCLAZigBee >> >>> with gnuradio. >> >>> >> >>> My question is the following: >> >>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >> >>> ... e.g. from the "send_pkt(...)" function (or any other) >> >>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >> >>> >> >>> Or more generally speaking: How can I forward a parameter from a >> >>> python application to the c++ processing block? >> >>> If possible it would be great to use the io_signatures... >> >> >> >> during instantiation of the block or during runtime? If it's during >> >> instantiation, you can use a parameter to the constructor of your C++ >> >> block. But, if you want something during runtime I do not think it >> >> is possible given the current architecture. You do not explicitly >> >> call the work() function where the processing is done, this is done >> >> within the GNU Radio framework. >> >> >> >> - George >> > >> > Well I'd need it during runtime. >> > What about using a shared memory block between the python and the >> > c++ block? Or what about calling a function from within the c++ >> > block, which would get the parameter from the python block or a >> > specific memory block >> > >> > Thanks for the help! >> > >> > - Bjoern >> >> Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, >> such that I could have one more stream forwarded from >> "ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? > > For that you need to change the io_signature. > > gr_make_io_signature (1, -1, sizeof (unsigned char)), > to > gr_make_io_signature (2, -1, sizeof (unsigned char)), Ah, great, thanks a lot! But where can I find that new stream to fill!? In other words: -how can I generate a new variable / stream and -where do I submit it, such that it is forwarded to the corresponding c++ block, and -how can I access it from within the c++ block!? that is where the python code comes in. basically you need to connect some other block to the second port of the ucla block, e.g.: self.connect(self.fmdemod, (self.sub, 0)) self.connect(self.fmdemod, self.freq_offset, (self.sub, 1)) try playing around with the gnuradio companion grc and look at the created python code. then the connection between io_signature and block connections becomes clear. Thanks for replying!! I tried that using the GRC, but unfortunately I can't get to the level of io_signatures!? Isn't there a way to uniquely identify , which the streams are that are passed between the c++ and the python blocks? such that one of them could be duplicated in order to forward one more stream? SO main question is how to identify the streams uniquely and how to generate one more!? then to make a block accept more than one signature i have to change the entry: gr_make_io_signature (2, -1, sizeof (unsigned char)), Anything else? Probably the parameters of the work() function within the c++ block, right? Thanks a lot in advanced for your help, best Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block
>>> Hi, >>> >>> I'm currently using the UCLA ZigBee PHY implementation posted on: >>> https://www.cgran.org/wiki/UCLAZigBee >>> with gnuradio. >>> >>> My question is the following: >>> How can I forward a parameter from: src/python/ieee802_15_4_pkt.py >>> ... e.g. from the "send_pkt(...)" function (or any other) >>> to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? >>> >>> Or more generally speaking: How can I forward a parameter from a python >>> application to the c++ processing block? >>> If possible it would be great to use the io_signatures... >> >> during instantiation of the block or during runtime? If it's during >> instantiation, you can use a parameter to the constructor of your C++ >> block. But, if you want something during runtime I do not think it is >> possible given the current architecture. You do not explicitly call the >> work() function where the processing is done, this is done within the >> GNU Radio framework. >> >> - George > > Well I'd need it during runtime. > What about using a shared memory block between the python and the > c++ block? Or what about calling a function from within the c++ > block, which would get the parameter from the python block or a > specific memory block > > Thanks for the help! > > - Bjoern Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, such that I could have one more stream forwarded from "ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? For that you need to change the io_signature. gr_make_io_signature (1, -1, sizeof (unsigned char)), to gr_make_io_signature (2, -1, sizeof (unsigned char)), Ah, great, thanks a lot! But where can I find that new stream to fill!? In other words: -how can I generate a new variable / stream and -where do I submit it, such that it is forwarded to the corresponding c++ block, and -how can I access it from within the c++ block!? thanks a lot best, Bjoern ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block
Hi, I'm currently using the UCLA ZigBee PHY implementation posted on: https://www.cgran.org/wiki/UCLAZigBee with gnuradio. My question is the following: How can I forward a parameter from: src/python/ieee802_15_4_pkt.py ... e.g. from the "send_pkt(...)" function (or any other) to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? Or more generally speaking: How can I forward a parameter from a python application to the c++ processing block? If possible it would be great to use the io_signatures... during instantiation of the block or during runtime? If it's during instantiation, you can use a parameter to the constructor of your C++ block. But, if you want something during runtime I do not think it is possible given the current architecture. You do not explicitly call the work() function where the processing is done, this is done within the GNU Radio framework. - George Well I'd need it during runtime. What about using a shared memory block between the python and the c++ block? Or what about calling a function from within the c++ block, which would get the parameter from the python block or a specific memory block Thanks for the help! - Bjoern Or how could I extend "ucla_symbols_to_chips_bi" to have more inputs, such that I could have one more stream forwarded from "ieee_802_15_4.py" to "ucla_symbols_to_chips_bi"? This then could be used within the work() function, wouldn't it? many thanks to all! -Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block
Hi, I'm currently using the UCLA ZigBee PHY implementation posted on: https://www.cgran.org/wiki/UCLAZigBee with gnuradio. My question is the following: How can I forward a parameter from: src/python/ieee802_15_4_pkt.py ... e.g. from the "send_pkt(...)" function (or any other) to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? Or more generally speaking: How can I forward a parameter from a python application to the c++ processing block? If possible it would be great to use the io_signatures... during instantiation of the block or during runtime? If it's during instantiation, you can use a parameter to the constructor of your C++ block. But, if you want something during runtime I do not think it is possible given the current architecture. You do not explicitly call the work() function where the processing is done, this is done within the GNU Radio framework. - George Well I'd need it during runtime. What about using a shared memory block between the python and the c++ block? Or what about calling a function from within the c++ block, which would get the parameter from the python block or a specific memory block Thanks for the help! - Bjoern ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.15.4 how to forward a parameter to a c++ block
Hi, I'm currently using the UCLA ZigBee PHY implementation posted on: https://www.cgran.org/wiki/UCLAZigBee with gnuradio. My question is the following: How can I forward a parameter from: src/python/ieee802_15_4_pkt.py ... e.g. from the "send_pkt(...)" function (or any other) to the c++ block in : src/lib/ucla_symbols_to_chips_bi.cc ? Or more generally speaking: How can I forward a parameter from a python application to the c++ processing block? If possible it would be great to use the io_signatures... best regards and thanks a lot for your help, Björn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
