Re: LimeSDR USB parameter help
First investigate if your problem is related to LimeSDR source. Simply connect a time sink to the output of thee Lime Source. Autoscale to see if the signal is present . In one of my attempt, this signal was very low and has only 2 different values like a binary noise. In that case, the spectrum do not exhibit a maximum at the radio station frequency. Did you set the LimeSDR Gain to a large value (up tu 70 dB for the LimeSDR Mini) On 29/01/2020 23:41, jane wrote: hi, Christophe Seguinot i have downloaded your .grc file. i ran it on my laptop with changing audio sink to 44.1, 32, 24. Of course, freq is a fm radio in my area. But i still saw aUaUaU. i heard noise only. my info is: hardware: Limesdr USB OS: ubuntu18.04 gnuradio: 3.8.0.0 gr-limesdr: gr-3.8 LimeSuite: v19.04.1-ga5b3a10f and i also do as gracid said: https://github.com/myriadrf/gr-limesdr/issues/55 I see that I've left the default value of "ok to block" in the audio sink, set it to "No" and leave it like that. Try different audio sink rates, for that you would need to change rational resampler and quadrature values (44.1k example: Decimation=2000, Interpolation 441, Quadrature rate: 441e3). Try adding a couple seconds of delay by inserting "Delay" block just before audio sink. I really didnt know why it did not work. i saw @Christophe Seguinot said :In the meantime, I used LimeSuiteGui to calibrate the LimeSDR Mini receiver. Don't know if that step was requested, but it now works! how to calibrate the LimeSDR USB? Is there anybody who can give other recommendations for my case? I am not sure if gnuradio3.7 is ok. But i have no confidence with it.
RE: gr version hell gets bigger and bigger...
Hi, > > I know, this is mainly a matter of the people who maintain such > > projects...and I have no idea how the awareness for this could be sharpened. > > Paying the maintainer usually helps. Sure, in a commercial world things work this way. In a hobbyists world however the projects just die :) > Cheers, > > Sylvain With best regrads Ralph.
Re: gr version hell gets bigger and bigger...
Hi, > > > I know, this is mainly a matter of the people who maintain such > > > projects...and I have no idea how the awareness for this could be > > > sharpened. > > > > Paying the maintainer usually helps. > > Sure, in a commercial world things work this way. In a hobbyists world > however the projects just die :) In the real world things work that way. If nobody cares about those project to either pay someone to update them or to update them themselves, they die. And that's the way it should be. If nobody cares about those project, there is no need for them to build or be up to date ... Anything relying on < 3.7 is a dead project and has been for a long time. Anything relying on 3.7 is still in the transition period (I'd say 6 month is reasonable). Either it will be updated if any body cares enough or it will die. That's just the way life works for software. Regards, Sylvain
Re: gr version hell gets bigger and bigger...
Hi Ralph, thanks for reaching out! Well, I'm coming from exactly the other side as you: GNU Radio's version hell is finally getting reduced. You see, we've been stuck with GNU Radio 3.7 for what feels like forever. That meant that a lot of technically necessary stuff, like using Python 3, because Python 2 is no longer officially supported, couldn't be done. Also, development-wise, GNU Radio was stuck in the early 2000's; now at least we can use C++11. It literally is not possible to remedy that without breaking compatibility with existing code – hence the 3.8 release. In other words, while GNU Radio was slowly withering in 3.7 lately, 3.8, after about six years of stability and stagnation, was a change of environment that was __impossible__ to not have. I hence have little regrets: yes, some (many) modules have not been ported (yet). That's too bad, but guess what: We can make zero guarantees about GNU Radio 3.7 even being buildable on a modern OS. For example, GNU Radio 3.7 was kicked out of debian at one point, because the python and Qt used were no longer available in debian. So, one version bump in six years: hardly hell, but necessary. Consider gr-limesdr not working on GNU Radio 3.8 (I didn't even know that): 3.8 has been announced for years, and I think Lime would actually be the party in need of keeping up with their customers' needs, not us. I think they might be pretty positive if you just contact them and tell them that, hey, to use the hardware you paid for in a wide range of applications, you'd need them to update their GNU Radio adapter. In the end, it's in their best interest, and they'll definitely like knowing the priorities of their customers! Best regards, Marcus On Wed, 2020-01-29 at 12:44 +0100, Ralph A. Schmid, dk5ras wrote: > Hi out there, > > only a common remark :) I am using gnuradio for around six or seven > years > now, and such issues were always present, but I never experienced > them in > the extent like nowadays. > > More and more I am trapped in version conflicts. Only one simple > example, > for being able to use gnuradio with my gr-limesdr I need to use gr > 3.7, > however a LoRaWAN project I wanted to use requires gr 3.8. In other > cases > projects I wanted to use combined required even three different gr > versions. > > > As I am not a coder, no, I can't contribute and update the projects - > I am > only a user. And also I was not yet motivated enough modifying the > cmake > file to fool the procedure, in the hope, it may work somehow if I > simply > extend the accepted version range. > > I know, this is mainly a matter of the people who maintain such > projects...and I have no idea how the awareness for this could be > sharpened. > > > As a matter of fact, the most stuff I want to play with still loves > 3.7, > even going to 3.8 breaks way too much. > > Ralph. > > -- > > Ralph A. Schmid, dk5ras > Mondstr. 10 > 90762 Fürth > +49-171-3631223 > +49-911-21650056 > ra...@schmid.xxx > http://www.bclog.de/ > > > >
Re: gr version hell gets bigger and bigger...
El 30/1/20 a las 16:09, Marcus Müller (GNU Radio maintainer) escribió: > Consider gr-limesdr not working on GNU Radio 3.8 (I didn't even know > that): 3.8 has been announced for years, and I think Lime would > actually be the party in need of keeping up with their customers' > needs, not us. I think they might be pretty positive if you just > contact them and tell them that, hey, to use the hardware you paid for > in a wide range of applications, you'd need them to update their GNU > Radio adapter. In the end, it's in their best interest, and they'll > definitely like knowing the priorities of their customers! Hi all, Something that I just learned from a quick Google search. It seems that GNU Radio 3.8 support in gr-limesdr is now done: https://github.com/myriadrf/gr-limesdr/issues/44 Best, Daniel. signature.asc Description: OpenPGP digital signature
Re: gr version hell gets bigger and bigger...
On 01/30/2020 01:56 PM, Daniel Estévez wrote: Hi all, Something that I just learned from a quick Google search. It seems that GNU Radio 3.8 support in gr-limesdr is now done: https://github.com/myriadrf/gr-limesdr/issues/44 Best, Daniel. There are bunches of us who write applications that are, largely, hardware agnostic. So, while having gr-limesdr work on 3.8 GR is great, the *real* thing is getting gr-osmosdr/soapysdr support in place, which is why I haven't moved to 3.8 yet.
