Re: vector source python block
Hello Barry. The flowgraph and you epy_block whas really helpful with my understanding of pmt and messages, which was not the point of the email Thank you so much for your time Στις Πέμ, 19 Δεκ 2019 στις 3:44 π.μ., ο/η Barry Duggan έγραψε: > Hi, > > For those who are interested I have added the flowgraph to the README.md > page of https://github.com/duggabe/gr-morse-code-gen > > Yes, I was trying to show how vectors generated in a Python block can be > fed into a flowgraph. In my case it is to key a tone with Morse code. > > --- > Barry Duggan KV4FV > > > On 2019-12-18 04:43, Kyeong Su Shin wrote: > > Hello Sarandis (and to whom it may concern): > > > > The GRC file in concern is apparantly written for GNU Radio 3.8, and > > is not backward compatible to GNU Radio 3.7. I suspect that you are > > using GNU Radio 3.7. > > > > I can provide the compiled version of the flowgraph, but it will > > require GNU Radio 3.8 to run anyway. Instead, you can look at > > "epy_block_0_0.py ( > > > https://github.com/duggabe/gr-morse-code-gen/blob/master/epy_block_0_0.py > > )", because I guess that is what Barry wants to show you (maybe I am > > wrong, though). You may need to make a few changes due to Python 2 / > > Python 3 compatibility issues, but with that, you should be able to > > embed that code to your flowgaph using a "Python Block" (for testing > > purposes, maybe). > > > > Regards, > > Kyeong Su Shin > > > > 보낸 사람: sarandis. Doulgeris 대신 > > Discuss-gnuradio > > > > 보낸 날짜: 2019년 12월 18일 수요일 오후 5:53 > > 받는 사람: Barry Duggan > > 참조: Discuss Gnuradio > > 제목: Re: vector source python block > > > > Thanks Barru but i have a minor problem opening the grc file > > Loading: "C:\Users\infrared\Documents\gnuradi_whatevers\MorseGen.grc" > > Error: > > > file:/C:/Users/infrared/Documents/gnuradi_whatevers/MorseGen.grc:1:1:FATAL:PARSER:ERR_DOCUMENT_EMPTY: > > Start tag expected, '<' not found > Failure > > > > Στις Τρί, 17 Δεκ 2019 στις 11:34 μ.μ., ο/η Barry Duggan > > mailto:ba...@dcsmail.net>> έγραψε: > > Hi, > > > > Without seeing your flowgraph, it is hard to tell what you plan to do > > with the vectors. In gereral, the "speed" ultimately is determined by > > input and/or output devices such as USB or a sound card. If you have > > neither one, a throttle block will limit the throughput. > > > > As an example of a custom vector source, see > > https://github.com/duggabe/gr-morse-code-gen which generates vectors of > > dots and dashes for Morse Code. If you start at the audio output > > (48khz) > > and work backwards, you will see how the sample rates determine the > > desired speed in words per minute. > > > > If you haven't already done so, it would be helpful for you to work > > through the > > https://wiki.gnuradio.org/index.php/Tutorials#Guided_Tutorials > > > > Let us know if you have more specific questions. > > > > Best wishes, > > -- > > Barry Duggan KV4FV >
Re: Xlating FIR filter delay
Hi Angilberto, am I right to assume that you already are considering the group delay of the filter that you specified and there's "excess" delay beyond that? Best regards, Marcus On Wed, 2019-12-18 at 19:59 +, Angilberto Muniz Sb wrote: > Hi all, > > I have a dual tone signal that I down convert and split into two common > frequency signals with the Xlating-fir filter. So far so good. > > However I noticed there is a phase shift between the signals generated (I > assume this is due the filter delay). I have to compensate for that. > > The question: How to determine or estimate that delay? > > Thank you, > > > Angilberto. smime.p7s Description: S/MIME cryptographic signature
Re: Xlating FIR filter delay
Yes Marcus, I'm interested in the "excess" delay, thats why I need to cancel the group delay. Guess I've found the answer: (len(filter_taps) - 1) / 2 Will try it.. Angilberto. Em quinta-feira, dezembro 19, 2019, 9:16 AM, Müller, Marcus (CEL) escreveu: Hi Angilberto, am I right to assume that you already are considering the group delay of the filter that you specified and there's "excess" delay beyond that? Best regards, Marcus On Wed, 2019-12-18 at 19:59 +, Angilberto Muniz Sb wrote: > Hi all, > > I have a dual tone signal that I down convert and split into two common > frequency signals with the Xlating-fir filter. So far so good. > > However I noticed there is a phase shift between the signals generated (I > assume this is due the filter delay). I have to compensate for that. > > The question: How to determine or estimate that delay? > > Thank you, > > > Angilberto.
Re: Xlating FIR filter delay
Ah, no! So, what you're seeing is no processing delay caused by our implementation of the xlating FIR filter, but simply *group delay*, which every linear system has. I don't know your background, so it's a bit hard to recommend some literature, but group delay would be covered in a "signals and systems" text book. > Guess I've found the answer: > (len(filter_taps) - 1) / 2 That is true ONLY if your filter has linear phase. It has linear phase iff it's symmetric to the center tap. Best regards, Marcus On Thu, 2019-12-19 at 14:08 +, Angilberto Muniz Sb wrote: > Yes Marcus, I'm interested in the "excess" delay, thats why I need to cancel > the group delay. > > Guess I've found the answer: > > (len(filter_taps) - 1) / 2 > > Will try it.. > > > Angilberto. > > > Em quinta-feira, dezembro 19, 2019, 9:16 AM, Müller, Marcus (CEL) > escreveu: > > > Hi Angilberto, > > > > am I right to assume that you already are considering the group delay > > of the filter that you specified and there's "excess" delay beyond > > that? > > > > Best regards, > > Marcus > > > > On Wed, 2019-12-18 at 19:59 +, Angilberto Muniz Sb wrote: > > > Hi all, > > > > > > I have a dual tone signal that I down convert and split into two common > > > frequency signals with the Xlating-fir filter. So far so good. > > > > > > However I noticed there is a phase shift between the signals generated (I > > > assume this is due the filter delay). I have to compensate for that. > > > > > > The question: How to determine or estimate that delay? > > > > > > Thank you, > > > > > > > > > Angilberto. smime.p7s Description: S/MIME cryptographic signature
Re: Xlating FIR filter delay
Hi Angilberto, On Thu, 2019-12-19 at 15:13 +, Angilberto Muniz Sb wrote: > In the docs it says the xlating fir filter is a symmetric one, certainly not in general. The FIR filter can whatever filter you put in there. You're thinking of an example somewhere! So, what docs *specifically* say that? > has linear phase shift and causes no phase distortion. I'd agree with "if it's symmetric, it's got a linear phase shift". I wouldn't fully agree with "no phase distortion", because it's still a frequency-dependent shift. > Lets say I have the following setup: > > x(t) = cos(wt), > s1(t) = x(t) upshiffted to w1, s2(t) = x(t) upshiffted to w2 > > s(t) = s1(t) + s2(t). > > Now, I apply two xlating filters to s(t): > > r1(t) = s(t) filtered and downconverted to w > r2(t) = s(t) filtered and downconverted to w > > I see a phase shift (or time delay) between x(t) and r1(t) or r2(t). Yes, that's *group delay*. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: More on C++11 requirements
Pip install cmake is also a quick and dirty remedy on most systems. On Mon, 25 Nov 2019, 15:21 Marcus D. Leech, wrote: > On 11/25/2019 05:52 PM, Maitland Bottoms wrote: > > "Marcus D. Leech" writes: > >> /me shuffles feet nervously: > >> > >> cmake version 2.8.12.2 > > For those suffering with RHEL / CentOS 7*... > > - yum install devtoolset-8 > >`. /opt/rh/devtoolset-8/enable` > >will bring you into the gcc 8.3 era. > > - install cmake3 from EPEL will get you CMake 3.14.6 > > > > Much sharper than the old stone knives! > > -Maitland > > > > (...not that I'll admit to knowing these things.) > > > > * You do know there's an 8 release now. Even CentOS 8. > > and if you are still using a 7, it should be 7.7 these days. > > > > Good luck. > > > This is just on a couple of old lappies running Fedora 21.I should > upgrade. But, pain. > > > >
GNU Radio Hackfest at ESA in the Netherlands and at FOSDEM ’20
Dearest SDR Community, we've just finished a [news post]( https://www.gnuradio.org/news/2019-12-19-fosdem/). As a special service to browser-wary people, here's the plaintext version! Cheers, Marcus Just as the year closes, it's time to remind people that two fantastic events are going to take place at the end of January / the beginning of February: # FOSDEM 2020 FOSDEM is *the* Free- and Open Source conference in Europe! GNU Radio has had a strong presence there for the last few years, and 2020 will be no different. Whilst you can be sure to find GNU Radio users and developers sitting and actively partaking in a lot of relevant tracks (Embedded, Policy, IoT, Python, ...), the concentration of SDR content in the [Free Software Radio](https://fosdem.org/2020/schedule/track/free_software_radio/) makes it impossible for a lot of us to miss that session. The session organizers have gone through lengths to make sure that room has a good mixture of topics, and isn't focused on GNU Radio alone – check out the schedule. FOSDEM happens anually at the ULB campus in Brussels, Belgium, and is free for anyone. Its multitude of small session rooms makes it the perfect event to watch exactly the talks one is interested in, whilst meeting the main figures behind your favourite open source project. We're looking forward to having a chat with you in Brussels! ## Last year's recordings If you're not sure what is expecting you: good news! You can last year's [schedule in the FOSDEM 2019 archive]( https://archive.fosdem.org/2019/schedule/track/free_software_radio/), and that includes video recordings! # Pre-FOSDEM Hackfest at ESA ESTEC in Noordwijk Nordwijk has a high concentration of communications engineers – and not the least of these is Andrej Rode, who's been a long-term pillar of GNU Radio! He's gone through lengths to organize the *Pre-FOSDEM GNU Radio Hackfest 2020 at ESA/ESTEC*. It takes places January 28 to January 30, giving you enough time to get to see the beautiful city of Leiden, the space museum, and enjoy a fair bit of ESA atmosphere! It'll concern itself with compute infrastructure, metadata tools, build chains and CI systems, or whatever we find workgroups for. You'll definitely want to read the [wiki page](https://wiki.gnuradio.org/index.php/Hackfest2001) and get up to speed on what you can do and contribute! This is a limited headcount event – the free [tickets](https://tickets.gnuradio.org/hackfest2001/) are running low, so if you can and want to contribute to GNU Radio and its ecosystem, do hurry up.
