Re: [Discuss-gnuradio] B100 clock with UHD
I thought OpenBTS would use Transceiver52MHz to communicate with B100 and to configure the AD9522 to output 52MHz sampling clock. However, with OpenBTS working with B100 and WBX I measure 64MHz sampling clock. And I am confused here. I didnt compile OpenBTS with resampling option. So where does the resampling happen? Or, am I wrong thinking that OpenBTS uses Transceiver52MHz ? Where is the UHD in this chain ? Regards, Robert Gesendet:Dienstag, 21. Januar 2014 um 02:28 Uhr Von:Ben Hilburn b...@ettus.com An:Robert Light robert.li...@gmx.de Cc:GNURadio Discussion List discuss-gnuradio@gnu.org Betreff:Re: [Discuss-gnuradio] B100 clock with UHD Hi Robert - The B100 has a configurable clock rate, specifically so that applications that require specific clock rates can tune it accordingly (e.g., OpenBTS). You can pass master_clock_rate=rate into the args string of the device and set the master clock rate to what works for your application. I havent personally used OpenBTS recently, but if you arent resampling on the host, that is probably how the host is using the device. Cheers, Ben On Mon, Jan 20, 2014 at 8:29 AM, Robert Light robert.li...@gmx.de wrote: Hi, I run B100 with OpenBTS. I thought the reconfigurable clock on B100 board would run with OpenBTS at 52MHz but I actually measure the sampling clock as 64MHz. So, where is the resampling done? Is the driver Transceiver52MHz used with B100 or not? Can someone shine some light on how it actually works? ___ 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] Cannot add an additional parameter to custom block
Hi all, I got my things working, up to the point where I decided that an additional parameter in my custom block would be very helpful. But for some reason, GRC keeps holding on to my previous version of the block with 3 parameters instead of my new one with 4 parameters. In the end, after numerous fails, I did the following: * I deleted the existing block from my module using gr_modtool rm MY_BLOCK * I deleted the build folder * I added MY_BLOCK again using gr_modtool and filled in some additional C++ code * I changed the XML file to reflect the additional parameter * I deleted various files from /user/..., such that 'sudo make install' did not report files already up-to-date: everything was newly installed In GRC the custom block shows the additional parameter (a bool, with options 'On' or 'Off'), but when trying to run GRC it reports: TypeError: Required argument 'XXX' (pos 4) not found. It boils down to top_block.py, where I see a call to my block with only 3 parameters while in all files I can see, 4 parameters are defined. If I delete this file, it is of course regenerated with the same error. Somewhere a file resides which still has the previous definition of the block with only 3 parameters instead of the new one with 4 parameters and GRC relies on that. Any ideas how to solve this are very welcome :-) Jeroen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does wx-gui work in GRC on Windows
Hi all, I just installed the latest stable GNURadio and GRC on windows 7. I am having problems running the fm radio example on GRC. The error shown on runtime is Cannot import name wx-gui. I have PYTHONPATH configured with C:\Program Files (x86)\gnuradio\lib\site-packages and I have wx-gui package inside the gnuradio in this path. Any help to resolve this issue? Thanks a lot. Best, Hemant ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot add an additional parameter to custom block
Hi Jeroen, On 01/21/2014 01:57 PM, jer...@boschma.com wrote: * I changed the XML file to reflect the additional parameter ... It boils down to top_block.py, where I see a call to my block with only 3 parameters while in all files I can see, 4 parameters are defined. Sounds like you haven't updated the template in make.../make (in your blocks' XML description). If that doesn't help, could you maybe post the XML? Sebastian -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Sebastian Koslowski Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe, Germany Phone: +49 721 608-46275 Fax: +49 721 608-46071 Email: sebastian.koslow...@kit.edu Web: http://www.cel.kit.edu/ KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot add an additional parameter to custom block
Koslowski, Sebastian (CEL) schreef op 2014-01-21 15:16: Hi Jeroen, On 01/21/2014 01:57 PM, jer...@boschma.com wrote: * I changed the XML file to reflect the additional parameter ... It boils down to top_block.py, where I see a call to my block with only 3 parameters while in all files I can see, 4 parameters are defined. Sounds like you haven't updated the template in make.../make (in your blocks' XML description). If that doesn't help, could you maybe post the XML? Sebastian How could I be so stupid to overlook that line, spent nearly 3 hours on this... In my first attempt I apparently only added the additional param, and in further attempts (newly generated block) I also copied the erroneous make line into the new xml-file. :-| Anyway, you saved my day, it works again. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-fcdproplus now in MacPorts
Volker (dl1ksv) and I fixed the build issues with gr-fcdproplus on OSX in the past couple of days, and this morning I pushed the gr-fcdproplus port to MacPorts https://trac.macports.org/changeset/116194 ; I also changed the gr-osmosdr port to by default include this new gr-fcdproplus port https://trac.macports.org/changeset/116196 . These changes should be live by 10:30 AM/US/ET. I do not have a FCD of any type (normal, pro+, whatever) on which to do testing ... so, anyone out there with one I'd love to hear some feedback if these changes work for you. If things don't work with gr-fcdproplus or gr-osmosdr on OSX please be in contact with me and we'll try to get things fixed up. Happy hacking! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz carrier freq: centered around 2.437GHz It is easier to reproduce if I replace the noise block with one that adds CFO errors. a) Increase this CFO error until header CRCs fail. Let this stand for a few seconds. b) Reduce CFO offset errors to 0. c) Go to step a and repeat a few times. I observe that after doing this a few times, the RX path freezes up. In any case, thank you very much for trying to reproduce this error. I really appreciate your help. :) best regards, aditya On Thu, Jan 16, 2014 at 10:11 AM, Martin Braun martin.br...@ettus.comwrote: On Wed, Jan 15, 2014 at 07:55:45PM -0500, Aditya Dhananjay wrote: There is a variant of this issue that I discovered and would like to point it out to the community. Synopsis: After the first time the header CRC fails, *all* subsequent packets fail. Setup: - GRC examples of Tx/Rx OFDM - Noise source with a variable slider to control the amount of noise. The output of the Tx block is added with the output of the noise source. - The output of this adder is connected to the Rx block. Procedure: - Start the experiment with 0 noise. We see that the packets are successfully decoded. - Increase the noise, and we observe that the packet success rate begins to drop (payload CRC failures) - Further increase the noise to force a header CRC failure. - Decrease the noise back to 0. Notice that the packet success rate remains 0, even though the noise is 0. This is highly repeatable. Any help would be greatly appreciated. Hm, can't repeat it. I used the loopback example. Increasing noise does make packets drop (as expected), but setting it back makes them come again. A noise amplitude of ~2 causes most packets to fail, but some come through. What are your OFDM specs? MB ___ 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] gr-fcdproplus now in MacPorts
On 21 jan 2014, at 15:55, Michael Dickens m...@alum.mit.edu wrote: Volker (dl1ksv) and I fixed the build issues with gr-fcdproplus on OSX in the past couple of days, and this morning I pushed the gr-fcdproplus port to MacPorts https://trac.macports.org/changeset/116194 ; I also changed the gr-osmosdr port to by default include this new gr-fcdproplus port https://trac.macports.org/changeset/116196 . These changes should be live by 10:30 AM/US/ET. I do not have a FCD of any type (normal, pro+, whatever) on which to do testing ... so, anyone out there with one I'd love to hear some feedback if these changes work for you. If things don't work with gr-fcdproplus or gr-osmosdr on OSX please be in contact with me and we'll try to get things fixed up. Happy hacking! - MLD Michael, I just tried it with my Funcube Dongle Pro+ with the following command: osmocom_fft -a fcd,device=hw:2,type=2 It works fine. /Ulf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Hi Martin, Making good progress with the relay but on another topic, I find if I use a random data source (rather than the 1...range in the original example) the trigger signal arrives occasionally one or two samples earlier than expected. Say we have 96B data this gives 768/48 = 16 data symbols. Adding 3 preamble gives 19×80 samples = 1520. Sometimes there are only 1519 or 1518 samples between triggers. This means that in the HPD code, too many items are consumed by the processing of the previous packet and thus the next trigger = 1 item is consumed in error so it is never found. A simple hack is to consume 'x' fewer samples in the HPD code I.e. In the line consume_each (d_header_len * (d_items_per_symbol + d_gi)); And the equivalent in the payload case, we can append ' - 3' A slightly more robust way would be to check where the next trigger occurs and remove the corresponding number of times. Are you able to recreate this issue? I realise that the problem only occurs when using a different data source than the standard demo, so of course it's not a bug as such at all. Many thanks, 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Hello David, I was facing the exact same issue, and the fix I use is identical to yours. I consume 4 symbols less than I need to, so the subsequent packet is not lost. Best, Aditya On Tue, Jan 21, 2014 at 11:14 AM, David Halls david.ha...@toshiba-trel.comwrote: Hi Martin, Making good progress with the relay but on another topic, I find if I use a random data source (rather than the 1...range in the original example) the trigger signal arrives occasionally one or two samples earlier than expected. Say we have 96B data this gives 768/48 = 16 data symbols. Adding 3 preamble gives 19×80 samples = 1520. Sometimes there are only 1519 or 1518 samples between triggers. This means that in the HPD code, too many items are consumed by the processing of the previous packet and thus the next trigger = 1 item is consumed in error so it is never found. A simple hack is to consume 'x' fewer samples in the HPD code I.e. In the line consume_each (d_header_len * (d_items_per_symbol + d_gi)); And the equivalent in the payload case, we can append ' - 3' A slightly more robust way would be to check where the next trigger occurs and remove the corresponding number of times. Are you able to recreate this issue? I realise that the problem only occurs when using a different data source than the standard demo, so of course it's not a bug as such at all. Many thanks, 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 -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote: Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz Sure you don't mean 2 MHz? At this BW, I'm surprised if it worked at all. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On 01/21/2014 04:23 PM, Aditya Dhananjay wrote: Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz carrier freq: centered around 2.437GHz Do you see these only over-the-air, or only in simulation? MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On 01/15/2014 09:26 PM, Aditya Dhananjay wrote: Issue B: Additionally, I notice that sometimes the header gets so corrupted that the CRC check passes (I suppose these false positives cannot be helped, unless we have a longer CRC for the header, but that's probably a waste). For the record: The default is 8 bits CRC, so there's a 1/256th chance a packet will fail and pass. But then there's also the payload CRC, which has 32 bits. Unlikely they'll both pass. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Oops, that was a typo. Sorry. I meant 200KHz. On Tue, Jan 21, 2014 at 12:17 PM, Martin Braun martin.br...@ettus.comwrote: On 01/21/2014 04:23 PM, Aditya Dhananjay wrote: Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz Sure you don't mean 2 MHz? At this BW, I'm surprised if it worked at all. MB ___ 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] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
On 01/21/2014 05:55 PM, Aditya Dhananjay wrote: Hello David, I was facing the exact same issue, and the fix I use is identical to yours. I consume 4 symbols less than I need to, so the subsequent packet is not lost. Best, Aditya On Tue, Jan 21, 2014 at 11:14 AM, David Halls david.ha...@toshiba-trel.com mailto:david.ha...@toshiba-trel.com wrote: Hi Martin, Making good progress with the relay but on another topic, I find if I use a random data source (rather than the 1...range in the original example) the trigger signal arrives occasionally one or two samples earlier than expected. Yes, I have seen this happen. To recap (please correct me if this is in fact not exactly your problem): Say the input signal looks like this: 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items ^ ^ - triggers ...everything is fine. Now, the trigger might be early (because of noise etc.): 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items ^ ^- triggers In this case, the trigger is consumed with the first packet, and the second one can't be won't be detected. Your solution will work, but you have to admit it's a hack. Who says my payload is 3 or 4 symbols long? I'm currently working on the HPD, and I'll figure out a way to get this in. I guess not consuming the last symbol would be sufficient in most cases, and since a payload must have at least one, this would be OK. For OFDM, this must work since one OFDM symbol is longer than the detection timing ambiguity. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Your solution will work, but you have to admit it's a hack. Who says my payload is 3 or 4 symbols long? I'm currently working on the HPD, and I'll figure out a way to get this in. Absolutely; this is an unclean hack. I guess not consuming the last symbol would be sufficient in most cases, and since a payload must have at least one, this would be OK. For OFDM, this must work since one OFDM symbol is longer than the detection timing ambiguity. Assume that the FFT size is 64 and the CP length is 16. As long as the trigger comes within the first 16 time-domain samples, we should be fine. The following applies probably to my unique problem domain (which is to design a better channel interpolation technique): I would like the trigger to come in at exactly at the end of the CP, as this would eliminate spurious channel rotations. If the trigger comes in during the CP, we will see rotations in the frequency domain (the channel changes very quickly across subcarriers). To eliminate this, I would like the trigger to come in exactly at the end of the CP. In this case, a trigger offset of 1-4 can cause the subsequent packet to not be detected by the HPD. If your channel interpolation method is DFE, then these rotations are irrelevant. best, aditya MB ___ 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] Fwd: Questions on rx_ofdm example in GR 3.7.1
For the record: The default is 8 bits CRC, so there's a 1/256th chance a packet will fail and pass. But then there's also the payload CRC, which has 32 bits. Unlikely they'll both pass. I agree. While false positives in the header CRC so happen from time to time, I've never noticed a false positive with payload CRC. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
sorry - I meant to say that adding the additional hack removed the rotation on
the constellation eq'd by h2_est but not the rotation on the constellation eq'd
by h1_est, thus there is still some timing issue. This can seen in the *.png
Aditya - am I to understand that you want to have perfect timing sync?
In my case I am happy to have a few samples offset, because the FDE can remove
this problem, as long as the samples in the header where the channel taps are
calculated are synchronized with those in the payload where the taps are
applied.
From: David Halls
Sent: 21 January 2014 17:50
To: Martin Braun; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when
using random bit stream (variable trigger location)
Thanks Martin and Aditya,
Yes Martin your recap is correct.
Indeed our solutions are hacks. I had an initial worry that not consuming all
of the items would end up with some sort of back-log. I am not sure I can get
my head around why this in fact doesn't cause a problem?! But it hasn't stopped
me sleeping at night just yet.
BUT, as with all hacks, it has come back to bite me. The exact nature is *very*
difficult to explain, but I have implemented a 2x1 MISO system, and this uses
orthogonal headers, so in HPD it receives header from tx1, then header from tx2
(rather than moving straight to payload), then receives (a superimposed tx1 +
tx2) payload.
The hack caused some kind of timing issue and so rotation of the superimposed
constellation was caused if I tried to equalize the superimposed constellation
with h1 or h2.
(N.B. I realise (x1h1 + x2h2 + n)/h2 does not give x1 or x2; I am working on
Wireless (PHY) Network Coding and the receiver will soon be a relay performing
Hierarchical NC)
Anyway, adding another hack of:
case STATE_PAYLOAD:
if (check_items_available(d_curr_payload_len, ninput_items,
noutput_items, nread))
{
.blah blah
}
else
{
// Bug-fix for rotation on EQ2
consume_each(VARIABLE_TRIGGER);
}
where VARIABLE_TRIGGER = 3.
I can't expect anyone to solve my specific problem - but if a more elegant fix
to the initial problem was possible, then this would most likely resolve my
issue too.
Many thanks,
David
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: 21 January 2014 17:26
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when
using random bit stream (variable trigger location)
On 01/21/2014 05:55 PM, Aditya Dhananjay wrote:
Hello David,
I was facing the exact same issue, and the fix I use is identical to
yours. I consume 4 symbols less than I need to, so the subsequent packet
is not lost.
Best,
Aditya
On Tue, Jan 21, 2014 at 11:14 AM, David Halls
david.ha...@toshiba-trel.com mailto:david.ha...@toshiba-trel.com wrote:
Hi Martin,
Making good progress with the relay but on another topic, I find if
I use a random data source (rather than the 1...range in the
original example) the trigger signal arrives occasionally one or two
samples earlier than expected.
Yes, I have seen this happen. To recap (please correct me if this is in
fact not exactly your problem):
Say the input signal looks like this:
1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items
^ ^ - triggers
...everything is fine. Now, the trigger might be early (because of noise
etc.):
1 1 1 1 1 1 1 2 2 2 2 2 2 2 2- items
^ ^- triggers
In this case, the trigger is consumed with the first packet, and the
second one can't be won't be detected.
Your solution will work, but you have to admit it's a hack. Who says my
payload is 3 or 4 symbols long? I'm currently working on the HPD, and
I'll figure out a way to get this in.
I guess not consuming the last symbol would be sufficient in most cases,
and since a payload must have at least one, this would be OK. For OFDM,
this must work since one OFDM symbol is longer than the detection timing
ambiguity.
MB
___
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 Research Europe Limited, registered in England and Wales (2519556).
Registered Office 208 Cambridge Science Park, Milton
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Ah, I see. You want to isolate the effect of the channel. I believe it will be difficult, if not impossible, to remove the slight jitter of the trigger, even in very high SNR - perhaps others can comment/help? From: Aditya Dhananjay [adi...@cs.nyu.edu] Sent: 21 January 2014 17:57 To: David Halls Cc: Martin Braun; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location) Aditya - am I to understand that you want to have perfect timing sync? Correct. This is because I want to study how the channel changes across OFDM subcarriers (caused due to multi-path). Having rotations in the channel across subcarriers caused by trigger timing offsets is what I want to eliminate. best, aditya 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
...having said that, I never saw the trigger jitter until I started using a random data source rather than 'range(packet_len)', do you get jitter in this case? From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of David Halls [david.ha...@toshiba-trel.com] Sent: 21 January 2014 18:03 To: Aditya Dhananjay Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location) Ah, I see. You want to isolate the effect of the channel. I believe it will be difficult, if not impossible, to remove the slight jitter of the trigger, even in very high SNR - perhaps others can comment/help? From: Aditya Dhananjay [adi...@cs.nyu.edu] Sent: 21 January 2014 17:57 To: David Halls Cc: Martin Braun; discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location) Aditya - am I to understand that you want to have perfect timing sync? Correct. This is because I want to study how the channel changes across OFDM subcarriers (caused due to multi-path). Having rotations in the channel across subcarriers caused by trigger timing offsets is what I want to eliminate. best, aditya 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/trlhttp://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 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 --- 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
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
On Tue, Jan 21, 2014 at 1:03 PM, David Halls david.ha...@toshiba-trel.comwrote: Ah, I see. You want to isolate the effect of the channel. I believe it will be difficult, if not impossible, to remove the slight jitter of the trigger, even in very high SNR - perhaps others can comment/help? Yes, that is correct. It is impossible to *eliminate* the jitter in triggers from Schmidl-Cox. But I want to minimize it, and have edited the plaueau/peak detector code to do just that. (all in a hackish manner!) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Aditya - am I to understand that you want to have perfect timing sync? Correct. This is because I want to study how the channel changes across OFDM subcarriers (caused due to multi-path). Having rotations in the channel across subcarriers caused by trigger timing offsets is what I want to eliminate. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] B100 clock with UHD
On Tue, Jan 21, 2014 at 5:45 AM, Robert Light robert.li...@gmx.de wrote: I thought OpenBTS would use Transceiver52MHz to communicate with B100 and to configure the AD9522 to output 52MHz sampling clock. However, with OpenBTS working with B100 and WBX I measure 64MHz sampling clock. And I am confused here. I didn't compile OpenBTS with resampling option. So where does the resampling happen? Or, am I wrong thinking that OpenBTS uses Transceiver52MHz ? Where is the UHD in this chain ? Please post subsequent questions to the OpenBTS mailing list. Note there is no longer any user configurable resampling option. Device specific rate configuration (clocking and sampling) is handled by the code internally. http://wush.net/trac/rangepublic/wiki/BuildInstallRun#AllOtherDevicesexceptforUSRP1 OpenBTS and B100 runs at 64 MHz. This was changed from 52 MHz because of significantly better performance and stability. https://wush.net/trac/rangepublic/wiki/USRP The host transceiver operates internally at 1.0833 Msps transmit and 270.833 ksps receive. These sample rates are converted and matched to device specific values on the host side in between the GSM processing and device I/O. For B100 the conversion rate is 65/96, which is selected to keep both halfband filters in place on the FPGA minimizing pass band distortion. The name 'Transceiver52M' is historical, which is admittedly confusing. The name originates from the initial public OpenBTS release, which only supported the USRP1. Back then, there were completely separate implementations for 64 MHz and 52 MHz for this single device. Eventually, all USRP code was merged into the 52 MHz code that is the active version remaining today. -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Num Steps in WX GUI Slider
Hi, I am having a basic question about the WX GUI Slider I am wondering why the Num Steps in WX GUI Slider have to be double the value than I calculate. For example, if I have minimum set at 86 MHz and maximum at 108 MHz and I want steps of 100 kHz I distract 86 from 108 which leaves me with 22 MHz, so for 100 kHz steps I think I should use Num Steps value of 220. That way I get steps of 200 kHz and I have to set Num Steps to 440 to get 100 kHz steps. Is there some logical explanation for this ? Running GNU Radio Companion 3.7.2 TnX, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qa_fft_filter make test failed - seg fault
How can we diagnose make test failures? All tests passed initially, but I had GRC disabled, so I recompiled everything w/ GRC enabled and this test failed. Also, is there a way to re-compile just parts of gnuradio, instead of recompiling everything? 99% of tests past, only qa_fft_filter failed on arm build ubuntu 13.10 from source. ubuntu@ubuntu-armhf:~/gnuradio/build$ ctest -V -R qa_fft_filter UpdateCTestConfiguration from :/home/ubuntu/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/home/ubuntu/gnuradio/build/DartConfiguration.tcl Test project /home/ubuntu/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 86 Start 86: qa_fft_filter 86: Test command: /bin/sh /home/ubuntu/gnuradio/build/gr-filter/python/filter/qa_fft_filter_test.sh 86: Test timeout computed to be: 9.99988e+06 86: Segmentation fault 1/1 Test #86: qa_fft_filter ***Failed 17.72 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 18.32 sec The following tests FAILED: 86 - qa_fft_filter (Failed) Errors while running CTest How should I go about diagnosing these problems? Launch GDB and see whats happening? Strange that this is the only test that failed. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
