Re: [Discuss-gnuradio] Import GNURadio data to matlab
There exists a small utility function for this purpose in the gnuradio sources. It can be found here: https://github.com/gnuradio/gnuradio/blob/master/gr-utils/octave/read_float_binary.m Either use it directly, or as an example how to do it. Markus Am 23.06.2018 um 16:40 schrieb PRIYANKA PRIYADARSHINI: > Hello Everyone, > > How can we import the data stored in a file by GNURadio to MATLAB using fread > and fseek function?? > > Thanks, > Priyanka > ___ > 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] State of Github Pull Requests and Issues
Dear Community! As of now, we got 29 outstanding¹ PRs on github, many of these being months old. That's not how it should be! As you might have read in my other recent mails, we're currently in the process of "getting GNU Radio future-proof", which mainly means getting the `next` branch (incorporating changes like enabling Python3 support or Qt5) ready for getting into the `mastery` branch. Does that mean development on `master` is on hiatus? A clear "no". I'll get back to each one of the contributors with outstanding PRs, and inform them why it's stuck. In most cases, it's got nothing to do with the PR itself – and I shall catch upon things as soon as possible! A couple of things I won't do right now (please don't send in automated spell checking PRs - these will only lead to merge conflicts that are completely avoidable), but other than that: develop away! Also, of course, the faster we get `next` into a working state that can be merged into `master`, the more time everyone has to review each other's PRs – so, if you've got some spare CPU cycles, or always wanted to know how GRC looks if you've got curved connectors, then go ahead, check out and build `next`, and report and/or fix your (maybe) first GNU Radio bug. So, happy hacking, and apologies for me being behind on the PR queue, Marcus ¹outstanding meaning PRs which are all the following: * not by me * not blocked by licensing * not marked as "Don't merge" ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] `next` branch: Now incorporating Python3
Dear Developer Community! As you probably know, we've long had a `next` branch, in which the "medium to long term" development happened – breaking changes are allowed there, we experimented with Qt5 and a lot of other interesting technologies. Then, a really important change came upon us (more than that we chose to have it): getting Python 3 compatibility became a necessity, as multiple platform vendors announced they were planning on cutting out Python2. Thus, from `next` there was a separate `python3` branch; and from that, many more feature and other development branches. We finally managed to merge that back into `next`, hopefully to the fullest extent permitted by ISO C++. So, frankly, `next` now is *really* exciting. And if you got but a spark of experience in your body, you know what /exciting/ means: Yes, we could use some help spotting and fixing bugs. We can build GNU Radio `next` on many machines (not all, Ubuntu seems to break with Python3 somewhere in VOLK), we can /start/ GRC, but not fully use it, and a lot of unit tests fail, because SWIG doesn't seem to do the same magic with Python array-like objects for std::vectors, and so on. What will happen with next when we've fixed those? Well, as soon as we can build everywhere we want (which is "in short, the same systems as before, minus things as ancient as Ubuntu14.04, plus Systems that only have Qt5 and Python3 instead of Qt4 and Py2") and don't have regressions in our unit tests, we'll merge `next` into `master`. Then, we'll have two weeks of "letting master proliferate in the wild", and if that works out well, we'll focus on fixing the outstanding `master` issues, and then will have a 3.8 release candidate! I'll address the state of the current `master` branch in a separate mail. Hope this does as much for a couple of people as much as it does for my happiness :) Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Frequency Selective Fading Model - Rician K Factor
Hi everyone, while trying to understand what exactly the above frequency selective model does (which I now mostly do, after reading the relevant papers and some recent threads here), I started getting some doubts about the Rice channel implementation. In short: the K factor is defined as the power ratio of the LOS component (i.e. first tap) to the NLOS components (rest of the taps). This means that in the case of a very large K factor, the NLOS paths become negligible and the channel converges towards a flat channel. This should hold regardless of the doppler frequency. Please correct me if I'm wrong here or anywhere. However, the current implementation does not show this behaviour -- setting high K values seems to only have very minor effect on the channel's frequency response. I'm aware of the changes made in the 'next' branch - they do not fix the problem (I backported the changes locally into maint-3.7 since next is pretty broken for me at the moment and I didn't feel like troubleshooting that...). Test flowgraph: Fast noise source -> Freq. Sel. Fading Model -> Qt freq. or fosphor sink. The current implementation uses the K factor to compute the first tap but ignores it for the rest of the taps. A quick, ugly and probably wrong solution is to multiply the taps returned by flat_fader_impl::next_samples with the respective LOS/NLOS scaling factors. This actually works (in the sense of giving a flat channel for large values of K) but I didn't try to validate this any further. I suspect it might be the wrong approach since it uses the K factor twice (once for computing first tap, then for weighting). PS: by 'taps' I mean the raw taps returned from all the flat faders, before interpolation. Any thoughts on this? Am I completely off? :) Cheers, Tal ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Text transmission using usrp
Yes! As you can see, the whole chain takes PDUs. You can generate PDUs from tagged streams using the appropriately named block. You can convert a normal stream to a tagged stream using the appropriately named block! A normal stream is what a file source produces. This is the one case where a throttle within a hardware-limited flow graph makes sense: Throttle the output of your file source to a reasonable byte rate, connect it to the tagged stream converter, that to the pdu converter. Best regards, Marcus On Thu, 2018-06-28 at 12:31 +0200, Trueblues 17 wrote: > Is there a way to use packet_loopback_hier.grc to send a text file in other > words is it possible to packetize a text file and use it? > On Wed, Jun 27, 2018, 11:49 AM Müller, Marcus (CEL) wrote: > > Hi Trueblues, > > > > the packet encoder and decoder blocks are known to be broken – that's > > why they are in the "deprecated" category! It'll be gone with the next > > minor release of GNU Radio, even. (same will happen to WX GUI, so > > switch to Qt now!) > > > > So, please don't use them; I don't expect them to work. > > Instead, you'll find, within the examples that came with GNU Radio¹ the > > digital/packet/packet_rx.grc and digital/packet/packet_tx.grc examples. > > > > These I expect to work. They are hierarchical blocks, which you can > > generate and through reloading of the block library also find in GRC's > > block library. > > > > in digital/packet_loopback_hier.grc you'll find a fully fledged > > transceiver – that has all the bells and whistles of a minimal > > communication system, including error correction, and phase and clock > > corrections. Much, much better than "packet decoder" ever has been. > > > > As soon as you have a rough idea what happens in the loopback flow > > graph, replace the "Channel Model" with your pair of USRP sink and > > source, and try it over the air :) > > > > As we're trying to stay atop of documentation, can I ask you how you > > came to build your flow graph with the packet en- and decoder? Is it > > completely a design of our own, or is there resources within our sphere > > of influence that we might clean up? > > > > Best regards, > > Marcus > > > > ¹typically /usr/[local/]share/gnuradio/examples > > > > On Wed, 2018-06-27 at 02:54 +0200, Trueblues 17 wrote: > > > I'm having a problem sending a text file between two usrp 2922 > > > devices. I'm running gnuradio companion on both laptops on windows. > > > The FFT sink in the receiver detects an incoming signal however the > > > file sink size is 0 byte.I attached both tx and rx flow graphs i > > > used. I previously implemented an FM transceiver without any problems > > > but when it comes to text, image and video i can't get an output > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Text transmission using usrp
Is there a way to use packet_loopback_hier.grc to send a text file in other words is it possible to packetize a text file and use it? On Wed, Jun 27, 2018, 11:49 AM Müller, Marcus (CEL) wrote: > Hi Trueblues, > > the packet encoder and decoder blocks are known to be broken – that's > why they are in the "deprecated" category! It'll be gone with the next > minor release of GNU Radio, even. (same will happen to WX GUI, so > switch to Qt now!) > > So, please don't use them; I don't expect them to work. > Instead, you'll find, within the examples that came with GNU Radio¹ the > digital/packet/packet_rx.grc and digital/packet/packet_tx.grc examples. > > These I expect to work. They are hierarchical blocks, which you can > generate and through reloading of the block library also find in GRC's > block library. > > in digital/packet_loopback_hier.grc you'll find a fully fledged > transceiver – that has all the bells and whistles of a minimal > communication system, including error correction, and phase and clock > corrections. Much, much better than "packet decoder" ever has been. > > As soon as you have a rough idea what happens in the loopback flow > graph, replace the "Channel Model" with your pair of USRP sink and > source, and try it over the air :) > > As we're trying to stay atop of documentation, can I ask you how you > came to build your flow graph with the packet en- and decoder? Is it > completely a design of our own, or is there resources within our sphere > of influence that we might clean up? > > Best regards, > Marcus > > ¹typically /usr/[local/]share/gnuradio/examples > > On Wed, 2018-06-27 at 02:54 +0200, Trueblues 17 wrote: > > I'm having a problem sending a text file between two usrp 2922 > > devices. I'm running gnuradio companion on both laptops on windows. > > The FFT sink in the receiver detects an incoming signal however the > > file sink size is 0 byte.I attached both tx and rx flow graphs i > > used. I previously implemented an FM transceiver without any problems > > but when it comes to text, image and video i can't get an output > > ___ > > 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
