Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????
Hi Rob, IMO the easiest way to setup GNURadio on Rpi is to use Archlinux [1]. You could find platform specific installation instructions on the website itself. Rpi-1 is underpowered and make sure that you are not running any GUIs while running a flowgraph. Create your flowgraphs on a local machine and run the generated python file on Pi (if you are using Pi-1). Performance results for some simple tests on Pi-1 and 2 with RTLSDRs are given below (GPU FFT not enabled on both, works without any overflows). Rpi-1 : 2MS/s, 512pt FFT with a block decimation of 16 (with UDP streaming to local PC) Rpi-2 : 2MS/s, 512pt FFT, bounded by USB throughput (with UDP streaming to local PC) [1] https://archlinuxarm.org/ Best regards Sreeraj Rajendran On Fri, Apr 15, 2016 at 4:21 PM, Rob Roschewsk wrote: > Thanks for all the good feedback folks! > > I think I'm going to stick to the precompiled packages in the repo for the > short term . so I'll probably be back with more questions soon :) > > ___ > 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] 3.7.9.2 Win64 binaries ready + Build scripts
I installed the binary files gnuradio_3.7.9.2_win64.msi on a Win-8 machine succefullyon the default directory. After running gnuradio-companion file from the Gnuradio 3.7 start menu folder I see a command window opening with message "setting gnuradio environment", then a couple of warnings of the sort: ** (python.exe:5392): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (python.exe:5392): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (python.exe:5392): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' and then the "standard" gnuradio window appears with the import-error warning Cannot import gnuradio. Is the python path environment variable set correctly? All OS: PYTHONPATH Is the library path environment variable set correctly? Linux: LD_LIBRARY_PATH Windows: PATH MacOSX: DYLD_LIBRARY_PATH (DLL load failed with error code -1073741795) --- any thoughts as to what is going wrong? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts
Yep, my bad on UHD, used to doing git builds and seeing 3.10. Cool yeah gqrx would be the priority, baz is just a nice to have (and its a bit dated as its all in WX which seems to be going the route of deprecation). So for some feedback, I installed the binaries and everything seems to work good. Hooked up the UHD and was able to receive a decent sample rate without issue. Only small issue is was a popup on first run that said: "The xterm executable 'xterm' is missing. You can change this setting in your gnuradio.conf, in section [grc], 'xterm_executable'. (This message is shown only once)" Which is understandable, as xterm is not built. Anyway, after clicking ok everything works. On the build side, first off, I'll say while I'm quite proficient on the Linux side, on the windows side I'm pretty noobish, so the first errors I received (missing io.h header, among other errors), appeared to be due to me having old VS 2012 only half removed which confused 14.. Anywho, after figuring that out and cleaning it up everything went good till the WX python build. But first I'll throw in that I did install VS2014 into an alternate path, this caused several issues with checks, I ended up creating the windows equivalent of a symlink (or maybe multi-disk hardlink, think its called a junction) and that solved that issue, but also the scripts ask for a location to place its build files, I tried I:/gr-build but received errors where directories in C:/gr-build were missing, I just symlinked C:/gr-build to I:/gr-build and things seemed fine. I only bring it up since the build scripts asked for a location. Perhaps it was something I did as I first ran setup.ps1 before I saw the ~RUNME_FIRST.ps1. Anyway, back to the WX error: Got the error "Validation Failed, C:/gr-build\src-stage2-python\gr-python27\lib\site-packages\wx-3.0-msw\wx\_core_.pyd was not found and is required" which seems to just be a sanity check that something we expected to build was not(i did independently verify its not there, theres no wx* in site-packages), I've uploaded the log for wx-python[1], let me know if you need any more info. The build appears to stop there. Not sure where to go with debugging as there appears to be no error, only some warnings? I'm also not familiar with wheel, though one would assume it produces the whl installer files. I did test removing the WX block and Step4 runs to completion. So it appears to be something with WX. I did see in the comments something about debug builds not working correctly, and there's a workaround. For completeness, I went ahead and commented out the Verify line and all builds (AVX, ReleaseDLL, Debug ) appear to generate this same log (except for folder names and such), and all do not generate the appropriate pyd file. Any ideas what could be wrong? Or maybe whats special about wx as compared to the other python modules? If it was a bunch I would suspect something in my env may just be incorrect(Which, very well may be the case), but it seems just that one library. P.S. I did just try to bypass it for debugging purposes, but I ended up with a different error on the consolidation step(not with WX) but lets take those one at a time. Also, if you want, I can take this to github/issues. -Anon [1] http://filebin.ca/2e5LIv6ROV29/39-ReleaseDLLwxpython.txt On Fri, Apr 15, 2016 at 3:43 AM, Geof Nieboer wrote: > Anon, > > UHD 3.9.3 is the most current release from Ettus. > > gqrx is on my to-do list, and in fact there are code stubs in the scripts > already for it. What stopped me is that it needs qt5 built, whereas GR is > on qt4 still, so I wanted to get out what I had first before re-attacking > that one. But once I have that done (and Qt5 appears way easier to build > than 4), then I'll get cracking on it. gr-baz I have not taken a look at, > but I will do so. > > On the downloads page in the website, I tried to keep track of which > library required what other libraries as I was going through it, so you'll > see that listed, perhaps that might be useful in creating a dependency > graph. I don't guarantee it's 100% complete, though. > > Yes, please let me know how the build goes. Take a look at the "Issues" > in the readme. Biggest recurring irritation I had was downloads that would > fail partway through then appear later as build failures. I would like to > move to a hash verification step after the download, but for the moment it > is what it is. And once the downloads have been successful once, you > should be smooth sailing as it will keep them cached in the 'packages' > subdir. > > Geof > > On Fri, Apr 15, 2016 at 9:41 AM, Anon Lister wrote: > >> This is awesome, I will test out the build process this weekend on 10. >> Any reason for the slightly older uhd release? I'd love to get gr-baz and >> gqrx working on Win. >> >> I'm also somewhat interested in stealing a pre-compiled list of >> dependencies for my somewhat crazy project of building GR + some OOTs on >> RHEL 6. Talk about d
Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk
Hi Andy, Just a quick update - I changed sps from 10 to 5 to repeat your trimming procedure. Works like a charm. Certainly clear why you picked the 2nd preamble copy and not the 1st.. as expected correlation is not as strong with decreasing sps (assuming unmod preamble stays same size). Looks like it is possible to come up with an "auto-trimming" algorithm after all. if the number of lost samples (distorted, nulled, etc) is a function of sps, modulation order, and preamble length (and lost samples in digital.generic_mod that I guess just don't get shifted out), then exact placement can be calculated based on these parameters alone and some initial experimentation. i'll try experimenting, lets see if this holds :) Best Regards, Arik From: Landsman, Arik Sent: Sunday, April 10, 2016 4:25 PM To: Andy Walls Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk Hi Andy, Sorry for delayed response, the weekend finally arrived.. added some comments inline below. Your comments on zero-IF receiving are well taken - going to try a low-IF approach instead. This maybe the source of some phase noise issues I had on the hardware last night. Using the USRP N210 btw. Overall, the aim in this case, at least for now, is three-fold: - design / fine tune a QPSK Rx capable of performance similar to a diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. Or possibly just non-diff if the latter outperforms. - implement it as a testbed for encoding/networking algorithms for heterogeneous networking (big topic for 5G). Not an expert in networking, but we have RA's devoted to the topic. So ultimately the Tx-Rx network should work reliably enough to allow performance testing their algorithms without hardware bottlenecking the performance. - on the personal front I am here for the long howl, as the topic is of personal interest. And contribute back into gnu-radio. Looks like this flowgraph is going in the "psk mod" footsteps as a non diff-encoding implementation. so if it appears feasible to create a python wrapper and a block i'll certainly start there. the big hurdle is the hand-tuning the corr_est block, which I'm going to contemplate a way to auto-cal it. Best Regards, Arik Andy Walls [a...@silverblocksystems.net] Sent: Tuesday, April 05, 2016 7:23 PM To: Landsman, Arik Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote: > Hi Andy, > > Added a few comments inline (marked with "==" in lieu of a better email > client).. > > But overall corr_est works very consistently. I did have a few observations: Hi Arik: For my responses to the next two, I'm assuming that ultimately you'll be working with a radio modem that sends bursts of energy and then cuts off RF energy. And that yoHi Andy, Sorry for delayed response, the weekend finally arrived.. added some comments inline below. Your comments on zero-IF receiving are well taken - going to try a low-IF approach instead. This maybe the source of some phase noise issues I had on hardware last night. Using the USRP N210 btw. Overall, the aim in this case, at least for now, is three-fold: - design / fine tune a QPSK Rx capable of performance similar to a diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. Or possibly just non-diff if the latter outperforms. - implement it as a testbed for encoding/networking algorithms for heterogeneous networking (big topic for 5G). Not an expert in networking, but we have RA's devoted to the topic. So ultimately the Tx-Rx network should work reliably enough to allow performance testing their algorithms without hardware bottlenecking the performance. - on the personal front I am here for the long howl, as the topic is of personal interest. And contribute back into gnu-radio. Looks like this flowgraph is going in the "psk mod" footsteps as a non diff-encoding implementation. so if it appears feasible to create a python wrapper and a block i'll certainly start there. the big hurdle is the hand-tuning the corr_est block, which I'm going to contemplate a way to auto-cal it. Best Regards, Arik Andy Walls [a...@silverblocksystems.net] Sent: Tuesday, April 05, 2016 7:23 PM To: Landsman, Arik Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote: > Hi Andy, > > Added a few comments inline (marked with "==" in lieu of a better email > client).. > > But overall corr_est works very consistently. I did have a few observations: Hi Arik: For my responses to the next two, I'm assuming that ultimately you'll be working with a radio
Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts
Some more information about the problem I have running the installed
version.
In the GNYRADIO command prompt shell I run python and then
>> from gnuradio import filter
and I get the following:
Traceback (most recent call last):
File "", line 1, in
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
.py", line 32, in
from filter_swig import *
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
wig.py", line 28, in
_filter_swig = swig_import_helper()
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
wig.py", line 24, in swig_import_helper
_mod = imp.load_module('_filter_swig', fp, pathname, description)
ImportError: DLL load failed with error code -1073741795
=
Any help is welcome,
thanks
Achilleas
On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos wrote:
> I installed the binary files
> gnuradio_3.7.9.2_win64.msi
> on a Win-8 machine succefullyon the default directory.
>
> After running gnuradio-companion file from the Gnuradio 3.7
> start menu folder I see a command window opening with message
> "setting gnuradio environment",
> then a couple of warnings of the sort:
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GMountMountFlags' as
> enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as
> enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
>
>
> and then the "standard" gnuradio window appears with the import-error
> warning
>
>
>
> Cannot import gnuradio.
>
> Is the python path environment variable set correctly?
> All OS: PYTHONPATH
>
> Is the library path environment variable set correctly?
> Linux: LD_LIBRARY_PATH
> Windows: PATH
> MacOSX: DYLD_LIBRARY_PATH
>
>
> (DLL load failed with error code -1073741795)
> ---
>
>
> any thoughts as to what is going wrong?
>
> thanks
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk
So the generic_mod() shifts the expected output by 50 samples to the right, thus dropping 50 samples off the end. with this in mind, generating *two* modulated vectors should do the trick: - generate an untrimmed sequence 2 preambles long (seq1) - generate another sequence 3 preambles long (seq2) - samples_per_preamble = (preamble_length_bytes * [8*2/mod_order] * sps) #[8*2/mod_order] is the symbols_per_byte for a given mod_order - in seq2, start_of_preamble = len(seq1) + - in seq2, end_of_preamble = len(seq1) + samples_per_preamble + - lost_samples = seq1 - 2 * samples_per_preamble #remainder after subtracting all preamble lengths from seq1 this works, at least manually, and should be generic enough to work for all cases, e.g. mod orders, preamble lengths, etc and regardless of the inner workings of generic_mod (which is good in case it gets changed). Just need to python it into the Rx in a neat way. From: Landsman, Arik Sent: Sunday, April 17, 2016 7:44 PM To: Andy Walls Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk Hi Andy, Just a quick update - I changed sps from 10 to 5 to repeat your trimming procedure. Works like a charm. Certainly clear why you picked the 2nd preamble copy and not the 1st.. as expected correlation is not as strong with decreasing sps (assuming unmod preamble stays same size). Looks like it is possible to come up with an "auto-trimming" algorithm after all. if the number of lost samples (distorted, nulled, etc) is a function of sps, modulation order, and preamble length (and lost samples in digital.generic_mod that I guess just don't get shifted out), then exact placement can be calculated based on these parameters alone and some initial experimentation. i'll try experimenting, lets see if this holds :) Best Regards, Arik From: Landsman, Arik Sent: Sunday, April 10, 2016 4:25 PM To: Andy Walls Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk Hi Andy, Sorry for delayed response, the weekend finally arrived.. added some comments inline below. Your comments on zero-IF receiving are well taken - going to try a low-IF approach instead. This maybe the source of some phase noise issues I had on the hardware last night. Using the USRP N210 btw. Overall, the aim in this case, at least for now, is three-fold: - design / fine tune a QPSK Rx capable of performance similar to a diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. Or possibly just non-diff if the latter outperforms. - implement it as a testbed for encoding/networking algorithms for heterogeneous networking (big topic for 5G). Not an expert in networking, but we have RA's devoted to the topic. So ultimately the Tx-Rx network should work reliably enough to allow performance testing their algorithms without hardware bottlenecking the performance. - on the personal front I am here for the long howl, as the topic is of personal interest. And contribute back into gnu-radio. Looks like this flowgraph is going in the "psk mod" footsteps as a non diff-encoding implementation. so if it appears feasible to create a python wrapper and a block i'll certainly start there. the big hurdle is the hand-tuning the corr_est block, which I'm going to contemplate a way to auto-cal it. Best Regards, Arik Andy Walls [a...@silverblocksystems.net] Sent: Tuesday, April 05, 2016 7:23 PM To: Landsman, Arik Cc: discuss-gnuradio@gnu.org; t...@trondeau.com Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote: > Hi Andy, > > Added a few comments inline (marked with "==" in lieu of a better email > client).. > > But overall corr_est works very consistently. I did have a few observations: Hi Arik: For my responses to the next two, I'm assuming that ultimately you'll be working with a radio modem that sends bursts of energy and then cuts off RF energy. And that yoHi Andy, Sorry for delayed response, the weekend finally arrived.. added some comments inline below. Your comments on zero-IF receiving are well taken - going to try a low-IF approach instead. This maybe the source of some phase noise issues I had on hardware last night. Using the USRP N210 btw. Overall, the aim in this case, at least for now, is three-fold: - design / fine tune a QPSK Rx capable of performance similar to a diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use diff encoding. Or possibly just non-diff if the latter outperforms. - implement it as a testbed for encoding/networking algorithms for heterogeneous networking (big topic for 5G). Not an expert in networking, but we have RA's devoted to the topic. So u
Re: [Discuss-gnuradio] Synced MIMO cable clock of both boards changes at every call to tb.start()?
Hi Martin, Thank you for getting back to me. I'm still a bit confused though. You are saying that I need to call set_time_now() or set_time_unknown_pps() to sync the clocks? So, simply connecting the MIMO cable between the two USRPs is not sufficient for the clocks to be synced? And as far as the start() function is concerned, you are saying that calling it constantly will NOT reinitialize the clock? Is that correct? My concern is that I have a while loop in which I call tb.start() in every iteration, and I want to make sure that the random phase offset between the two boards that is generated (MIMO cable between the two) stays the same through these iterations. Please keep me posted! Thank you. -- Pavan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts
Achilleas,
To troubleshoot that problem:
1- download a program called "Dependency Walker", (www.*dependencywalker*
.com/)
2- Then with that, open the _filter_swig.pyd file located at C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
default settings. It will give a dialog saying something wasn't found,
that's normal.
3- Go to Options->Configure Module Search Order
4- On the bottom right of the window, go to "Browse" and select C:\Program
Files\GNURadio-3.7\bin and click "Add Directory", then say "Yes"
5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
Now on the top left you will see huge tree of all the dependencies...
something in there is missing. IGNORE the entries that look like
"API_MS_WIN...", those are fine to be missing.
Please tell me what you are missing.
I suspect since you are running Windows 8, it's the MSVC 14.0 runtime that
is missing. If the missing entries are "UCRTBASE.DLL", "MSVCP140.DLL", and
VCRUNTIME140.DLL", that is the problem. That's a download from Microsoft
here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
Geof
On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos wrote:
> Some more information about the problem I have running the installed
> version.
>
> In the GNYRADIO command prompt shell I run python and then
> >> from gnuradio import filter
>
>
> and I get the following:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
> .py", line 32, in
> from filter_swig import *
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
> wig.py", line 28, in
> _filter_swig = swig_import_helper()
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
> wig.py", line 24, in swig_import_helper
> _mod = imp.load_module('_filter_swig', fp, pathname, description)
> ImportError: DLL load failed with error code -1073741795
>
> =
>
> Any help is welcome,
>
> thanks
> Achilleas
>
>
> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> I installed the binary files
>> gnuradio_3.7.9.2_win64.msi
>> on a Win-8 machine succefullyon the default directory.
>>
>> After running gnuradio-companion file from the Gnuradio 3.7
>> start menu folder I see a command window opening with message
>> "setting gnuradio environment",
>> then a couple of warnings of the sort:
>>
>> ** (python.exe:5392): WARNING **: Trying to register gtype
>> 'GMountMountFlags' as
>> enum when in fact it is of type 'GFlags'
>>
>> ** (python.exe:5392): WARNING **: Trying to register gtype
>> 'GDriveStartFlags' as
>> enum when in fact it is of type 'GFlags'
>>
>> ** (python.exe:5392): WARNING **: Trying to register gtype
>> 'GSocketMsgFlags' as
>> enum when in fact it is of type 'GFlags'
>>
>>
>> and then the "standard" gnuradio window appears with the import-error
>> warning
>>
>>
>>
>> Cannot import gnuradio.
>>
>> Is the python path environment variable set correctly?
>> All OS: PYTHONPATH
>>
>> Is the library path environment variable set correctly?
>> Linux: LD_LIBRARY_PATH
>> Windows: PATH
>> MacOSX: DYLD_LIBRARY_PATH
>>
>>
>> (DLL load failed with error code -1073741795)
>> ---
>>
>>
>> any thoughts as to what is going wrong?
>>
>> thanks
>> Achilleas
>>
>
>
> ___
> 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] Feedback with Transmitters and Receiver
Hi Martin, Thank you again for getting back to me. Let me elaborate on the process that I am doing, and hopefully what I need will be clarified. I have two USRPs connected via MIMO cable that are transmitting a sin wave and one USRP receiving that sin wave. I am trying to implement a system in which I determine the power of the received signal, feed it back to the transmitters, adjust weights that I'm multiplying the transmitted signals by (according to some algorithm), and then send again to the receiver, and this goes on for a certain number of iterations. The problem I am having is that I have no idea how to make sure that the received signal is the one that I am transmitting with my correct weights. In other words, I want to turn that receiver on only for it to receive my signal that I transmitted, then turn it off again as I adjust the weights, and then transmit again, and have it receive again. So, it's basically a full feedback loop that is sequential: transmit new signal, receive that signal, send back some information about that, transmit new signal, receive that signal, etc. I still feel like I'm not able to describe this articulately, so please keep me posted. I am a bit unclear on how the rx_time could work in this above scenario. Thank you so much again! -- Pavan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
