wimax chain
Hi, any solution to the reception (rx) or tx of wimax using gnuradio? could not find any proper chain that finds the preamble. -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the message.
Re: wimax chain
Hi Eitan, it's been a while since I've looked into IEEE802.16, but that's a very regular OFDM system, isn't it, with a fixed OFDM symbol as short preamble (for the downlink bursts), and a 2-symbol preamble for the start of frame? A simple correlation detector might do in that case; a bit nicer on the acquisition speed per computational effort might be a fixed-length correlator that detects the position of cyclic prefixes and could be applied to a whole burst or even frame to get a good timing estimate before you start decoding OFDM symbols. Best regards, Marcus PS: Your email signature is kinda funny on a publicly archived mailing list :D On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > Hi, > any solution to the reception (rx) or tx of wimax using gnuradio? > could not find any proper chain that finds the preamble. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
Hi Eitan, please keep replies on the list! I don't think there's a readymade solution for you. I'm not quite sure what you mean with "resemble OFDM": could you elaborate? I really thought that IEEE802.16 is a pure OFDM system, so this comes as a surprise. In which way is it not? Best regards, Marcus On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > thanks for the rapid reply, > it does resemble ofdm, however as a beginner in the field i was hoping to > find a readymade chain to tweak with? > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) wrote: > > Hi Eitan, > > > > it's been a while since I've looked into IEEE802.16, but that's a very > > regular OFDM system, isn't it, with a fixed OFDM symbol as short > > preamble (for the downlink bursts), and a 2-symbol preamble for the > > start of frame? > > > > A simple correlation detector might do in that case; a bit nicer on the > > acquisition speed per computational effort might be a fixed-length > > correlator that detects the position of cyclic prefixes and could be > > applied to a whole burst or even frame to get a good timing estimate > > before you start decoding OFDM symbols. > > > > Best regards, > > Marcus > > > > PS: Your email signature is kinda funny on a publicly archived mailing > > list :D > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > > > Hi, > > > any solution to the reception (rx) or tx of wimax using gnuradio? > > > could not find any proper chain that finds the preamble. > > > > > > The information transmitted is intended only for the person or entity to > > > which it is addressed and may contain confidential and/or privileged > > > material. Any review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon, this information by persons or > > > entities other than the intended recipient is prohibited. If you received > > > this in error, please contact the sender and delete all copies of the > > > message. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
hello, it is an ofdm system, but i could not get to tweak the ofdm_Rx example to find the preamble in the transmission i was looking to capture. On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) wrote: > Hi Eitan, > > please keep replies on the list! > I don't think there's a readymade solution for you. > > I'm not quite sure what you mean with "resemble OFDM": could you > elaborate? I really thought that IEEE802.16 is a pure OFDM system, so > this comes as a surprise. In which way is it not? > > Best regards, > Marcus > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > > thanks for the rapid reply, > > it does resemble ofdm, however as a beginner in the field i was hoping > to find a readymade chain to tweak with? > > > > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) > wrote: > > > Hi Eitan, > > > > > > it's been a while since I've looked into IEEE802.16, but that's a very > > > regular OFDM system, isn't it, with a fixed OFDM symbol as short > > > preamble (for the downlink bursts), and a 2-symbol preamble for the > > > start of frame? > > > > > > A simple correlation detector might do in that case; a bit nicer on the > > > acquisition speed per computational effort might be a fixed-length > > > correlator that detects the position of cyclic prefixes and could be > > > applied to a whole burst or even frame to get a good timing estimate > > > before you start decoding OFDM symbols. > > > > > > Best regards, > > > Marcus > > > > > > PS: Your email signature is kinda funny on a publicly archived mailing > > > list :D > > > > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > > > > Hi, > > > > any solution to the reception (rx) or tx of wimax using gnuradio? > > > > could not find any proper chain that finds the preamble. > > > > > > > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete all copies of > the message. > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the > message. > -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the message.
Re: wimax chain
Hi, ah! OK, yeah, that's unfortunate. So, the easy thing about OFDM: as soon as you know where your symbol starts, all you need to do is apply an FFT – and you're done. (you will still have to "equalize" your reception, but that is a point-wise multiplication at the output of the FFT.) So, if I was to recommend a methodology for solving this: Start with building a fixed-lag correlator to find the beginning of symbols. You're not the first person to have to do that: The gr-dab module [1] contains one such, that you'd only have to parameterize to use the length and sizes of OFDM symbols in WiMaX instead of these in DAB+. (I actually recommend looking at gr-dab's receiver; it's a nice display of how to demodulate OFDM downlinks.) You'll be getting output that you can threshold to get the beginnings of symbols, then you just start taking FFTs at these positions, and in those, you look for the preamble symbols to get the equalizer taps. Best regards, Marcus [1] https://github.com/kit-cel/gr-dab On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote: > hello, > it is an ofdm system, but i could not get to tweak the ofdm_Rx example to > find the preamble in the transmission i was looking to capture. > > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) wrote: > > Hi Eitan, > > > > please keep replies on the list! > > I don't think there's a readymade solution for you. > > > > I'm not quite sure what you mean with "resemble OFDM": could you > > elaborate? I really thought that IEEE802.16 is a pure OFDM system, so > > this comes as a surprise. In which way is it not? > > > > Best regards, > > Marcus > > > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > > > thanks for the rapid reply, > > > it does resemble ofdm, however as a beginner in the field i was hoping to > > > find a readymade chain to tweak with? > > > > > > > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) > > > wrote: > > > > Hi Eitan, > > > > > > > > it's been a while since I've looked into IEEE802.16, but that's a very > > > > regular OFDM system, isn't it, with a fixed OFDM symbol as short > > > > preamble (for the downlink bursts), and a 2-symbol preamble for the > > > > start of frame? > > > > > > > > A simple correlation detector might do in that case; a bit nicer on the > > > > acquisition speed per computational effort might be a fixed-length > > > > correlator that detects the position of cyclic prefixes and could be > > > > applied to a whole burst or even frame to get a good timing estimate > > > > before you start decoding OFDM symbols. > > > > > > > > Best regards, > > > > Marcus > > > > > > > > PS: Your email signature is kinda funny on a publicly archived mailing > > > > list :D > > > > > > > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > > > > > Hi, > > > > > any solution to the reception (rx) or tx of wimax using gnuradio? > > > > > could not find any proper chain that finds the preamble. > > > > > > > > > > The information transmitted is intended only for the person or entity > > > > > to which it is addressed and may contain confidential and/or > > > > > privileged material. Any review, retransmission, dissemination or > > > > > other use of, or taking of any action in reliance upon, this > > > > > information by persons or entities other than the intended recipient > > > > > is prohibited. If you received this in error, please contact the > > > > > sender and delete all copies of the message. > > > > > > The information transmitted is intended only for the person or entity to > > > which it is addressed and may contain confidential and/or privileged > > > material. Any review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon, this information by persons or > > > entities other than the intended recipient is prohibited. If you received > > > this in error, please contact the sender and delete all copies of the > > > message. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
RE: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Glen: >The spectra from the PlutoSDR look good, and I can use a wide range of >bandwidths, Great. >but for bandwidths larger than 3.2 MHz I don’t get all the data captured (I >know this by calculating how >long I should have to wait for all N samples at a given data rate, and measure >the actual time it >takes to get N samples. Just to confirm - to capture 3.2 MHz, the output sample rate is set to 3.2 MSPS (Mega Samples per Second?) I can pretty easily set things to 7 MSPS (7 MHz of total RF bandwidth), and not drop samples (over USB). Buffer size impacts this a lot. See the insightful presentation that Travis did as part of GNU Radio Conference 2019: See: https://www.gnuradio.org/grcon/grcon19/presentations/gr-iio_nuances_hidden_features_and_new_stuff/Travis%20Collins%20-%20gr_iio.pdf page 38 Set your buffers to 16k - 64k samples for fastest performance. What is your target sample rate? Libiio is not threaded, and that is an exercise left for the user, or top level application. I think there have been discussions on the mainlining IIO about what is the "right" way to do things for GNU Radio. I think this bottomed out, and we were doing it the right way - but would need to confirm with Travis -Robin -Original Message- From: Glen Langston Sent: Tuesday, November 19, 2019 4:39 PM To: Getz, Robin Cc: Marcus D. Leech ; discuss-gnuradio@gnu.org Subject: Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation Hi Robin, When using the AIRSPY (and mini) this summer I was finding some flashes in the RF band that were on for a few 100 micro-seconds, then off. (The plots are on my home computer so I’ll have to send these on Friday). The fraction of time the flashes are on is very small, less than a total of one second in 24 hours. The spectra from the AIRSPY look very good and the AIRSPY is very reliable in sending all data at the 10 MHz bandwidth (20 MHz I+Q samples). I could see these transients even when my horns were pointing at the ground, so were not likely due to internal sources. However since my project is looking for transient events, the flashes are an issue for me, but would not be noticed at all by most users. The PlutoSdr does not seem to be generating many (any?) transients internally, which is very good. Ie when I point the horns at the ground I get very few/no transients appear above 5 sigma, compared to the noise level. The spectra from the PlutoSDR look good, and I can use a wide range of bandwidths, but for bandwidths larger than 3.2 MHz I don’t get all the data captured (I know this by calculating how long I should have to wait for all N samples at a given data rate, and measure the actual time it takes to get N samples. The PlutoSDR does not seem to be reliable sending data at rates faster than 3.2 MHz bandwidth (6.4 MHz I+Q samples). I think it is sending blocks of data on USB but then not sending for a while while the data are buffered in some part of the USB processing. The PlutoSDR code in GNuradio does not generate the Overflow or Underflow letters that other software generates for other devices. So the rate issues are probably not noticed by other users of gnuradio-companion. I’m working on a version of the Gnuradio code that does not generate any plots and could run entirely internally on the PlutoSDR. This might be able to capture all events at the full 56 MHz sample rate. The current code is obtainable by git clone http://www.github.com/WVURAIL/gr-radio_astro This requires some building and compiling. It works for me on the Raspberry Pi 4 and Odroid N2 (Both with 4GB). I’ve downloaded and installed some else’s PlutoSDR .dfu files, that did run gnuradio on the Pluto. That was working well but I could not figure out how to modify it to build my own c++ libraries. I might try again. Regards Glen > On Nov 19, 2019, at 2:55 PM, Getz, Robin wrote: > > On Friday, November 15, 2019 1:22 PM , Glen I Langston wrote: > [snip] >> I’ve not yet fully checked the SDRPlay for short term transients. >> >> Note that the Pluto SDR has no (or at least few) short term transients in >> the RF. >> I did find the AIRSPY did have some transients that seem to be due to the >> device. >> These occur a few thousand times a day, but for shorter than 100 micro >> seconds. >> Total time on is less than a second a day. >> > > Glen: > > I would be interested in what you mean by this. I assume it's mostly > "anomalous data", and while it's "not right", you aren't sure if it is coming > from the RF (air interference) or via some transport scheme issue. > > If you have a bursty/intermittent adjacent channel (where adjacent can be > within ~200 MHz of your LO, depending on your hardware), it could cause > anomalous reception. (This highly depends on your external filters, and > shielding)... > > If you have bursty/intermittent data on harmonics of the LO (again, depending > on your hardwar
