Re: [Discuss-gnuradio] Confusion over data formatting for a waveform in QT GUI Time Sink, File Sink, and RFNoC noc_block_moving_avg
Craig, If what you are trying to do is build a verilog test bench and use this data as stimulus then stay within GR, multiply your float data by 2^16 and then convert it to short integer before passing to file sink(s). That will give you two's complement signed integer signal data. Assemble your packet level tdata[63:0] from file data as follows (where I1/Q1 follows I0/Q0 in time): [63:56] I0 MSB [55:48] I0 LSB [47:40] Q0 MSB [39:32] Q0 LSB [31:24] I1 MSB [23:16] I1 LSB [15:8] Q1 MSB [7:0] Q1 LSB If this block is expecting packetized data, rather than a simple sample stream then assume you already understand the packet header format you need to add also? My tip for the day, especially since right now you are just building a loop back to bring up your test bench is generate simple waveforms entirely within your test bench. A saw tooth or triangle wave is incredibly easy to generate by incrementing a signed integer type, and visually easy to check in a waveform viewer. In terms of number format, try to think of the integer data as Q1.15, not Q16. In otherwords 0x8000 represents -1.0 and 0x7fff represents 0.9when you actually analyze your DSP architecture it makes it easier to keep track of word growth knowing that 1.15+1.15 = 2.15 and 1.15*1.15 = 2.30 -Ian On Wed, May 18, 2016 at 1:52 PM, Martin Braun wrote: > On 05/18/2016 12:56 PM, Swanson, Craig wrote: > > gnuradio-companion. Here are my steps and questions: > > Craig, > > short answer: What Ian said, and also: > > > 8. Once I can agree that my 32 bit real and imaginary numbers are > > making sense in QT GUI Time Sink and File Sink, then I have to > > convert that 32 bit hex value into Q16 format which RFNoC > > noc_block_moving_avg is expecting to be sent to i_tdata (64 bits=two > > sets of real and imag) and then m_axis_data_tdata(32 bits=one set of > > real and imag, sent twice=64 bits)? > > 9. How do I convert the 32 bit IEEE 754 data (gnuradio) into Q16 > (RFNoC)? > > You do *not* have to convert anything. UHD does that for you. You feed > it fc32 data (std::complex) and tell the streamer to convert it > to sc16. Which is the default. > > M > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to extract stable fine frequency offset based on the benchmark program?
Hi DingJing, I'm not sure what's going on here, but I think it could be likely that your estimate of the preamble-autocorrelation simply doesn't work all too well. Generally: ditch benchmark_rx and the blocks it uses. They are really superseeded by the OFDM blocks that were introduced in 2013 – they are far better, and also, will simply give you the estimates you want, I think. Make sure you have a recent version of GNU Radio, and look for the rx_ofdm.grc example (likely somewhere in /usr/share/gnuradio/examples/digital/ofdm). The "Schmidl & Cox OFDM synch." block /actually/ has an output "freq_offset", and the "OFDM Channel Estimation" block adds a stream tag containing the full subcarrier offset (if any). ** Other than that: > I've been trying to figure out the frequency offset of USRP recently. Could you specify this a bit more? Best regards, Marcus On 19.05.2016 05:53, DingJing wrote: > Hi all,I've been trying to figure out the frequency offset of USRP > recently. So I run the OFDM benchmark program and output the > compensation value of fine offset.For detail,in benchmark.rx.py, we > import ofdm_receiver,and ofdm_reciver import ofdm_sync_pn to calculate > the fine offset and do time synchronization.The main procedure of > ofdm_sync_pn(using Schmidl and Cox algorithm) is as following: > > And I output the S/H(sample and hold) block to file sink block to > record the fine offset.However,the result figure are as following: > X label can be regarded as time,Y label is the output fine offset by > angle between -Pi to Pi.It is fiercely different from my expectation > in which the figure should be a straight line approximately.I wonder > why this happens.Thank you so much! > > > > > > > ___ > 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] UDP Source Error (on windows)
> > OK, I was able to reproduce the issue, and it appears to me to a core > GNURadio issue not specifically related to the installer > > > udp_source_impl.cc is setting the SO_LINGER option on the UDP socket, > which at least on Windows, causes a WSAENOPROTOOPT exception, because > linger doesn't really mean anything for a UDP socket. > > > Perhaps the Linux folks can help here, but I'm guessing that this > option must be simply ignored on Linux so there is no error for most > users. Looking at the man pages doesn't specify any particular > behavior required. > > > Geof SO_LINGER gets processed by the Linux kernel generically here: http://lxr.free-electrons.com/source/net/core/sock.c#L644 with no check against socket type. The UDP socket handling doesn't use the resulting SOCK_LINGER flag setting. http://lxr.free-electrons.com/source/net/ipv4/udp.c http://lxr.free-electrons.com/source/net/ipv6/udp.c Only TCP and the Bluetooth SCO protocol in the Linux kernel care about SO_LINGER. Regards, Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Source Error (on windows)
Thanks Andy, I will submit a change to remove this set_option from the udp source then. Geof On Thu, May 19, 2016 at 3:59 PM, Andy Walls wrote: > > > > OK, I was able to reproduce the issue, and it appears to me to a core > > GNURadio issue not specifically related to the installer > > > > > > udp_source_impl.cc is setting the SO_LINGER option on the UDP socket, > > which at least on Windows, causes a WSAENOPROTOOPT exception, because > > linger doesn't really mean anything for a UDP socket. > > > > > > Perhaps the Linux folks can help here, but I'm guessing that this > > option must be simply ignored on Linux so there is no error for most > > users. Looking at the man pages doesn't specify any particular > > behavior required. > > > > > > Geof > > > SO_LINGER gets processed by the Linux kernel generically here: > > http://lxr.free-electrons.com/source/net/core/sock.c#L644 > > with no check against socket type. > > The UDP socket handling doesn't use the resulting SOCK_LINGER flag > setting. > http://lxr.free-electrons.com/source/net/ipv4/udp.c > http://lxr.free-electrons.com/source/net/ipv6/udp.c > > Only TCP and the Bluetooth SCO protocol in the Linux kernel care about > SO_LINGER. > > Regards, > Andy > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Source Error (on windows)
I'll comment that the Windows socket implementation isn't in compliance with the spirit of the robustness principle. But, whatevs. Easy enough to just remove that option for the UDP case. On 2016-05-19 08:59, Andy Walls wrote: >> OK, I was able to reproduce the issue, and it appears to me to a core >> GNURadio issue not specifically related to the installer >> >> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket, >> which at least on Windows, causes a WSAENOPROTOOPT exception, because >> linger doesn't really mean anything for a UDP socket. >> >> Perhaps the Linux folks can help here, but I'm guessing that this >> option must be simply ignored on Linux so there is no error for most >> users. Looking at the man pages doesn't specify any particular >> behavior required. >> >> Geof > > SO_LINGER gets processed by the Linux kernel generically here: > > http://lxr.free-electrons.com/source/net/core/sock.c#L644 > > with no check against socket type. > > The UDP socket handling doesn't use the resulting SOCK_LINGER flag > setting. > http://lxr.free-electrons.com/source/net/ipv4/udp.c > http://lxr.free-electrons.com/source/net/ipv6/udp.c > > Only TCP and the Bluetooth SCO protocol in the Linux kernel care about > SO_LINGER. > > Regards, > Andy > > ___ > 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] UDP Source Error (on windows)
On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote: > I'll comment that the Windows socket implementation isn't in > compliance with the spirit of the robustness principle. But, whatevs. > Easy enough to just remove that option for the UDP case. > I think it's a bit of a security failing of Linux to allow injection of 4 unused bytes into the kernel space from user-space for every locally opened UDP socket. I'm not sure how I could exploit it (perhaps coding a jump instruction to a no-op sled somewhere nearby?), but I'm not that creative. Meh. -Andy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP Source Error (on windows)
Not sure how this would get leveraged by itself. But there are likely lots of kernel calls that have parameters that are ignored in certain contexts. I would be astonished if a general-purpose, long-lived, operating existed without that being the case from time to time. On 2016-05-19 11:58, Andy Walls wrote: > On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote: > >> I'll comment that the Windows socket implementation isn't in >> compliance with the spirit of the robustness principle. But, whatevs. >> Easy enough to just remove that option for the UDP case. > > I think it's a bit of a security failing of Linux to allow injection of > 4 unused bytes into the kernel space from user-space for every locally > opened UDP socket. I'm not sure how I could exploit it (perhaps coding > a jump instruction to a no-op sled somewhere nearby?), but I'm not that > creative. > > Meh. > > -Andy___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNUradio & LimeSDR?
Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E -- *David* KD4E ARES-EC Bulloch County, Nevils, Georgia USA Safe & Secure Search Engine: duckduckgo.com Android for Hams: groups.yahoo.com/group/hamdroid Creative Tech: groups.yahoo.com/group/ham-macguyver Raspi Alternative: groups.yahoo.com/group/beagleboneblack/ Restored to design-spec at Heaven's gate 1Cor15:22 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNUradio & LimeSDR?
On 05/19/2016 09:07 PM, q...@kd4e.com wrote: Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E David: You should probably ask the limesdr folks what their plans are for Gnu Radio support. As to different modes and frequencies, Gnu Radio is a generic environment for construction DSP applications. There are applications "out there", based on Gnu Radio, that provide HF operating modes on various hardware. Check www.cgran.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNUradio & LimeSDR?
Marcus, LimeSDR lists GNUradio as supported. Will check out cgran.org Thanks! David On 05/19/2016 09:07 PM, q...@kd4e.com wrote: Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E David: You should probably ask the limesdr folks what their plans are for Gnu Radio support. As to different modes and frequencies, Gnu Radio is a generic environment for construction DSP applications. There are applications "out there", based on Gnu Radio, that provide HF operating modes on various hardware. Check www.cgran.org -- *David* KD4E ARES-EC Bulloch County, Nevils, Georgia USA Safe & Secure Search Engine: duckduckgo.com Android for Hams: groups.yahoo.com/group/hamdroid Creative Tech: groups.yahoo.com/group/ham-macguyver Raspi Alternative: groups.yahoo.com/group/beagleboneblack/ Restored to design-spec at Heaven's gate 1Cor15:22 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNUradio & LimeSDR?
This seems to imply AM, CW, SSB, FM modes. https://sourceforge.net/projects/sdr/ Yes? Thanks - David KD4E Marcus, LimeSDR lists GNUradio as supported. Will check out cgran.org Thanks! David On 05/19/2016 09:07 PM, q...@kd4e.com wrote: Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E David: You should probably ask the limesdr folks what their plans are for Gnu Radio support. As to different modes and frequencies, Gnu Radio is a generic environment for construction DSP applications. There are applications "out there", based on Gnu Radio, that provide HF operating modes on various hardware. Check www.cgran.org -- *David* KD4E ARES-EC Bulloch County, Nevils, Georgia USA Safe & Secure Search Engine: duckduckgo.com Android for Hams: groups.yahoo.com/group/hamdroid Creative Tech: groups.yahoo.com/group/ham-macguyver Raspi Alternative: groups.yahoo.com/group/beagleboneblack/ Restored to design-spec at Heaven's gate 1Cor15:22 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNUradio & LimeSDR?
On 05/19/2016 10:34 PM, q...@kd4e.com wrote: This seems to imply AM, CW, SSB, FM modes. https://sourceforge.net/projects/sdr/ Yes? Thanks - David KD4E Could be. I'd contact the author of that app. A quick look indicates that it was written specifically for USRPs, and likely using the very, very obsolete "libusrp" interface. Marcus, LimeSDR lists GNUradio as supported. Will check out cgran.org Thanks! David On 05/19/2016 09:07 PM, q...@kd4e.com wrote: Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E David: You should probably ask the limesdr folks what their plans are for Gnu Radio support. As to different modes and frequencies, Gnu Radio is a generic environment for construction DSP applications. There are applications "out there", based on Gnu Radio, that provide HF operating modes on various hardware. Check www.cgran.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNUradio & LimeSDR?
Marcus, OK, will do. "Programming toolchain packages: GNU Radio, Pothos, SoapySDR, UHD. Downloadable apps: Snappy Ubuntu Core, licensing up to app developers." David KD4E On 05/19/2016 10:34 PM, q...@kd4e.com wrote: This seems to imply AM, CW, SSB, FM modes. https://sourceforge.net/projects/sdr/ Yes? Thanks - David KD4E Could be. I'd contact the author of that app. A quick look indicates that it was written specifically for USRPs, and likely using the very, very obsolete "libusrp" interface. Marcus, LimeSDR lists GNUradio as supported. Will check out cgran.org Thanks! David On 05/19/2016 09:07 PM, q...@kd4e.com wrote: Does anyone know if GNUradio is ready to transmit and receive SSB, digi, etc 160-10m on the new LimeSDR "dc-daylight" board? Dual transmitters (10mw) and dual receivers. Open source. https://www.crowdsupply.com/lime-micro/limesdr Thanks - David KD4E David: You should probably ask the limesdr folks what their plans are for Gnu Radio support. As to different modes and frequencies, Gnu Radio is a generic environment for construction DSP applications. There are applications "out there", based on Gnu Radio, that provide HF operating modes on various hardware. Check www.cgran.org -- *David* KD4E ARES-EC Bulloch County, Nevils, Georgia USA Safe & Secure Search Engine: duckduckgo.com Android for Hams: groups.yahoo.com/group/hamdroid Creative Tech: groups.yahoo.com/group/ham-macguyver Raspi Alternative: groups.yahoo.com/group/beagleboneblack/ Restored to design-spec at Heaven's gate 1Cor15:22 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to extract stable fine frequency offset based on the benchmark program?
Marcus Müller ettus.com> writes: > > Hi DingJing, > > I'm not sure what's going on here, but I think it could be likely that > your estimate of the preamble-autocorrelation simply doesn't work all > too well. > > Generally: ditch benchmark_rx and the blocks it uses. They are really > superseeded by the OFDM blocks that were introduced in 2013 – they are > far better, and also, will simply give you the estimates you want, I think. > > Make sure you have a recent version of GNU Radio, and look for the > rx_ofdm.grc example (likely somewhere in > /usr/share/gnuradio/examples/digital/ofdm). The "Schmidl & Cox OFDM > synch." block /actually/ has an output "freq_offset", and the "OFDM > Channel Estimation" block adds a stream tag containing the full > subcarrier offset (if any). ** > > Other than that: > > I've been trying to figure out the frequency offset of USRP recently. > Could you specify this a bit more? > > Best regards, > Marcus > Dear Marcus Müller: Thank you for you reply. I just try out the benchmark in /usr/share/gnuradio/examples/digital/ofdm with little modification. As you known,the benchmark use ofdm_sync_pn by default for synchronisation.The "ofdm_sync_pn" block uses a block named "sample_and_hold" which I think is the value of fine_offset,so I created a block_file_sink and wrote "self.connect(self.sample_and_hold,self.offset_file_sink) " to output the offset value instead of set logging=Ture.Maybe I have some misunderstanding. Best wishes~ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
