Re: [Discuss-gnuradio] Divide frequency by a constant
Ah, I think I see where you're going :) So, here, we're really talking about digital clock division! That is, a counter :) While that'd be totally possible to piece together (counting edges, then emitting an edge every N input edges), it's not how DSP works: the things you handle *are* already with respect to a common time source. That also means that you don't have to worry about phase coherence: If you start two different oscillators at the same phase, they will stay coherent, as long as math doesn't fail. Because I think this is easier to show with binary signals than with an oscillation generation, try the following: 1. Add a vector source, output type "byte", values [0, 0, 0, 0, 0, 1, 1, 1, 1, 1] 2. Add a vector source, output type "byte", values [0, 0, 0, 0, 0, 0 1, 1, 1, 1, 1, 1] 3. use the "And" block from the "boolean operations" category, input type "byte"; connect the two vector sources to it. 4. add three "UChar to float" blocks. Connect one to the output of the first signal source, one to the output of the second, and one to the output of the And block. 5. Add a "Qt GUI time sink", input type float, number of inputs 3. 6. Connect the outputs of the UChar to float blocks to the inputs of the Qt GUI time sink. Let the whole thing run. You'll see how everything stays phase coherent, the AND of the two clocks just is the let's call it beat signal of the two clocks and everything is fine. > Why don't I just switch between 1277 and 1064 signal sources? > Because > the result is not phase-coherent. Luckily, that's not true :) (I've built something very much like that as a quick example for some stranger on the internet a couple years back, see [1]). This is software! All the signals in GNU Radio are just sequences of numbers. When you apply an operation to two sequences, the math just handles the two sequences coherently :) So, all the digital-logic problems of the real world, namely having things that drift off arbitrarily, don't apply. Now, you can imagine that this is not really how you'd build an FSK modem in GNU Radio. You can just simply go in, * "multiply const" and "add const" to your input signal, so that it makes sense as baseband frequency values; (in your case, I'd go with +- 213/2 Hz as frequencies), * Repeat (that's a block!) them for as many samples in your samp_rate one FSK symbol takes, and then * use a "Frequency Mod"¹ block straight away. (I'd go with sensitivity = 2*3.141 / samp_rate) You'd get CPFSK in baseband. Attach a Qt Frequency sink to see! If you used an interpolating FIR with a sensible pulse shape as taps instead of the Repeat block, you'd get CPFSK with a pulse shape. Best regards, and loads of fun, Marcus -- ¹ btw: the "sensitivity" parameter of the Frequency Mod block gives the factor between input sample amplitude and output "phase advance in radians per sample"; e.g if your input is 10, 10, 10... , and your sensitivity is pi/200, then you produce a signal with a phase increase of 1/40 of a full cycle every sample, i.e. has a period of 40 samples, which means it has a frequency of f_sample/40. [1] https://stackoverflow.com/questions/36898574/fsk-demodulation-with-gnu-radio/36915550#36915550 On Wed, 2019-06-19 at 12:55 -0400, Barry Duggan wrote: > Marcus, Chris, and others: > > What I am really trying to do is replicate a time-domain FSK modem I > designed in 1972 (using discrete components of course). It used a > crystal oscillator at 12,770 hz (square wave) and divided that by 5 > and > then ANDed with the input signal. The other path divided by 6 and > ANDed > with the inverted input signal. The two paths were ORed together and > divided by 2, giving a fairly good phase-coherent FSK with 1277 / > 1064 > frequencies. Low pass filtering followed. > > Why don't I just switch between 1277 and 1064 signal sources? > Because > the result is not phase-coherent. > > My other objective is just to learn what I can do with Gnu radio :) > > Cheers! > --- > Barry Duggan 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] Multiple-Transmitter OFDM
On Thu, Jun 20, 2019 at 6:24 AM Ramazan Çetin wrote: > At the end, i decided to give some gap between transmitters. So, 36 to > 90 and -36 to -90 are assigned to transmitters. But, result is same. I > have attached two pictures of spectrum. They represents state of one and > two transmitters are active. You can check the situation from there. > I'm not familiar with the details of OFDM systems but that looks like quite adequate separation in the spectrum. Therefore, it seems to me that the problem is most likely your receiver's filter — it is not adequately selecting one signal and not the other. Consider visualizing the output of your low pass filter, and telling us what blocks and parameters you are using. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Divide frequency by a constant
Hi Barry, On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote: > Marcus, > > Thank you for that. So now I have three questions: > 1) Does it matter if one uses [brackets] or (parentheses) to enclose a > vector? It appears not. That's Python syntax; [] means Python list (a mutable sequence of references to the contained elements), () means python tuple (immutable seq...). The difference is irrelevant in this case; it's just that [ 1 ] is a list containing the element 1 only, and ( 1 ) is just the number one (with parentheses around it, meaning nothing), so when explaining stuff, I'd prefer the more "explicit" []. (You'd need to do (1,) if you wanted a single-element tuple.) > 2) What determines the rate at which the vector contents are presented > to the output? Nothing :) This is just the exact sequence of numbers that are produced. It doesn't have a physical rate. GNU Radio will just repeat the vector on its output as fast as that output is emptied. The speed at which that happens is completely (!!) irrelevant to the math happening with that. I'd recommend trying to completely forget about these signals having something to do with an analog signal that changes over time, just for a moment. It's just a bunch of zeros and ones, one after the other. That goes through some processing steps, let's say it gets multiplied by 213 first and then 106.5 gets subtracted. Now it's still a bunch of numbers. Simply a sequence of numbers flowing through that flow graph. There's no rate, or speed notion attached to that. Now, these +106.5 and -106.5 values reach the frequency modulator. What that does is it takes each number, multiplies it with its sensitivity, adds the result to its internal phase accumulator, and produces a new number on its output, which is simply exp(j·phase); still, everything is just a sequence of numbers. Some of these numbers might have a value that depends on a variable that might for example be called samp_rate, or f_samp or whatever. But that just changes the values of the numbers, not the fact that their existence and calculation has nothing to do with real-world time. Now, at some point, these numbers are sent to a DAC of some kind. And now, that DAC actually is actually driven by some hardware clock that forces it to take one sample every so and so many nanoseconds. Double the speed of that clock, and you'd change the physical (frequency) "meaning" of the digital signal you convert to analog, but not the digital signal as is – it'd still be the same sequence of numbers. > 3) If one were to add a 'throttle', where would it go? Is it needed > here? Don't do it at all if you're actually building a modem. A throttle is just a "copy input sequence to output" block, that goes to sleep (as in: ask the operating system of your computer to wake it in so and so many microseconds) for a while to limit the average number of samples that it copies per second. You'd only do that if you're in a simulation, and don't want signal processing to happen as fast as it can (there not being a DAC that limits the rate at which they are consumed), but still e.g. want to look at the signal with a human eye at a sensible speed. In your modem example, the DAC already limits the speed; don't "double limit" it. From your obvious experience with digital clocked circuits, you know that in the wake of two independent clocks (your DAC's clock and your PC/operating system clock) there only lies madness, FIFO over- and underflows and tears. (same of course applies to reception: The ADC only gives us one sample per sampling period; then, we process the resulting sequence as fast as possible.) Of course, one of the main things you'd use GNU Radio for is to first design your modem in simulation before attaching real analog/digital or digital/analog conversion hardware to it. In that case: 1. If you want to test whether the modem works end-to-end, you'd attach your TX modem flowgraph to your RX modem flow graph (maybe with a block that simulates a wireless channel in between), and not throttle at all, but just send some finite amount of test data and check whether the result at the other end is the same. 2. But very often, you'd e.g. want to look at the output of your pulse shaper in real time (or slow motion); then you'd just add exactly one Throttle to your simulation, typically right at the visualization (that position doesn't matter too much, however – as you can infer from my description above, the whole flowgraph will always get the chunk of samples that your Throttle passed through, and process it as fast as it can, then go back into waiting for more data, while the throttle sleeps for as long as it needs to sustain the requested average copying rate). > > BTW, a minor correction: the second vector is missing a comma after the > last 0. oh, yeah! Cheers, Marcus > > Thanks > --- > Barry Duggan > > > On 2019-06-20 05:14, Müller wrote: > > Ah, I think I see where you're going :) > >
Re: [Discuss-gnuradio] Divide frequency by a constant
Marcus, Thank you for that. So now I have three questions: 1) Does it matter if one uses [brackets] or (parentheses) to enclose a vector? It appears not. 2) What determines the rate at which the vector contents are presented to the output? 3) If one were to add a 'throttle', where would it go? Is it needed here? BTW, a minor correction: the second vector is missing a comma after the last 0. Thanks --- Barry Duggan On 2019-06-20 05:14, Müller wrote: Ah, I think I see where you're going :) So, here, we're really talking about digital clock division! That is, a counter :) While that'd be totally possible to piece together (counting edges, then emitting an edge every N input edges), it's not how DSP works: the things you handle *are* already with respect to a common time source. That also means that you don't have to worry about phase coherence: If you start two different oscillators at the same phase, they will stay coherent, as long as math doesn't fail. Because I think this is easier to show with binary signals than with an oscillation generation, try the following: 1. Add a vector source, output type "byte", values [0, 0, 0, 0, 0, 1, 1, 1, 1, 1] 2. Add a vector source, output type "byte", values [0, 0, 0, 0, 0, 0 1, 1, 1, 1, 1, 1] 3. use the "And" block from the "boolean operations" category, input type "byte"; connect the two vector sources to it. 4. add three "UChar to float" blocks. Connect one to the output of the first signal source, one to the output of the second, and one to the output of the And block. 5. Add a "Qt GUI time sink", input type float, number of inputs 3. 6. Connect the outputs of the UChar to float blocks to the inputs of the Qt GUI time sink. Let the whole thing run. You'll see how everything stays phase coherent, the AND of the two clocks just is the let's call it beat signal of the two clocks and everything is fine. Why don't I just switch between 1277 and 1064 signal sources? Because the result is not phase-coherent. Luckily, that's not true :) (I've built something very much like that as a quick example for some stranger on the internet a couple years back, see [1]). This is software! All the signals in GNU Radio are just sequences of numbers. When you apply an operation to two sequences, the math just handles the two sequences coherently :) So, all the digital-logic problems of the real world, namely having things that drift off arbitrarily, don't apply. Now, you can imagine that this is not really how you'd build an FSK modem in GNU Radio. You can just simply go in, * "multiply const" and "add const" to your input signal, so that it makes sense as baseband frequency values; (in your case, I'd go with +- 213/2 Hz as frequencies), * Repeat (that's a block!) them for as many samples in your samp_rate one FSK symbol takes, and then * use a "Frequency Mod"¹ block straight away. (I'd go with sensitivity = 2*3.141 / samp_rate) You'd get CPFSK in baseband. Attach a Qt Frequency sink to see! If you used an interpolating FIR with a sensible pulse shape as taps instead of the Repeat block, you'd get CPFSK with a pulse shape. Best regards, and loads of fun, Marcus -- ¹ btw: the "sensitivity" parameter of the Frequency Mod block gives the factor between input sample amplitude and output "phase advance in radians per sample"; e.g if your input is 10, 10, 10... , and your sensitivity is pi/200, then you produce a signal with a phase increase of 1/40 of a full cycle every sample, i.e. has a period of 40 samples, which means it has a frequency of f_sample/40. [1] https://stackoverflow.com/questions/36898574/fsk-demodulation-with-gnu-radio/36915550#36915550 On Wed, 2019-06-19 at 12:55 -0400, Barry Duggan wrote: Marcus, Chris, and others: What I am really trying to do is replicate a time-domain FSK modem I designed in 1972 (using discrete components of course). It used a crystal oscillator at 12,770 hz (square wave) and divided that by 5 and then ANDed with the input signal. The other path divided by 6 and ANDed with the inverted input signal. The two paths were ORed together and divided by 2, giving a fairly good phase-coherent FSK with 1277 / 1064 frequencies. Low pass filtering followed. Why don't I just switch between 1277 and 1064 signal sources? Because the result is not phase-coherent. My other objective is just to learn what I can do with Gnu radio :) Cheers! --- Barry Duggan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problema REX OFDM
Hi Jale - OK; thanks for the updates & for translating to English :) In the
future, please "reply all" to include the GNU Radio discussion list: more eyes
on your issue are more likely to help you.
Suppose you create a GRC flowgraph where the OFDM Mod goes through a virtual
channel (there's a GR block that does this) and then into an OFDM Demod (using
the same OFDM setttings for both the Mod and Demod) ... does that work? - MLD
On Wed, Jun 19, 2019, at 11:08 PM, Jale Ocampo wrote:
>
> I thank you for your great help. * I have already changed the file and the
> amplitude that I have is [-1, +1]. * In effect, the transmission is wireless.
> But at the moment I'm doing tests at short distances. But after the OFDM MOD
> block, in the part of the receiver I do not get the demodulated signal, I
> only have one continuous signal. * I have already changed to the default
> parameters for now.
>
> El mié., 19 jun. 2019 a las 19:04, Michael Dickens
> () escribió:
>> __
>> Hi Jale -
>>
>> From translate.google.com
>> {{{
>> Best regards, apologies for not writing in English.
>> I'm doing a project for a tx and rx with OFDM modulation.
>> The transmitter does not present any kind of problem to traffic.
>> But in the receiver after the OFDM DEMOD block, the original signal is not
>> regenerated.
>> If someone could help me, please.
>> It should be noted that I am working with USRP B10 cards
>> Subsequently, I must calculate the BER of the Recepted signal
>> I attach the files.
>> Thank you.
>> }}}
>>
>> My reply:
>> {{{
>> translate.google.com is your friend ... feel free to use it but also please
>> note in your emails that you're using it.
>>
>> A few thoughts:
>>
>> * get the Tx signal to be closer to [-1, +1] ... [-0.6, +0.6] isn't full
>> scale, and the Tx signal will be that much weaker.
>>
>> * you don't note how you are transmitting the data from Tx to Rx ...
>> wirelessly? via a cable (hopefully with in-line attenuation)? the Rx signal
>> could be very small if the Tx -> Rx distance is too great.
>>
>> * If you change the OFDM parameters, does the system work ... for example
>> using the default values that the OFDM Mod and Demod use? At least in some
>> cases for GR OFDM, using anything but the defaults doesn't work without
>> significant effort and knowledge of how to get it working.
>>
>> Hope this is useful! - MLD
>> }}}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple-Transmitter OFDM
Hi Ramazan - My primary wondering about your specific OFDM setup is whether the sync preambles are abiding by your carrier separation (256 carriers: -120:-1 for one Tx and 1:120 for the other). It certainly looks from the images that the payload portion is working as you desire. Depending on the payload length, when using a spectrum analyzer you might not even see the blip of the sync preambles ... Are you using pre-existing GR OFDM blocks in GRC, or something you created yourself? Do you have GRC or Python / C++ scripts you'd be willing to share? Some of the more involved (typically hierarchical) GR blocks such as OFDM provide settable variables that sometimes don't work well if not the default or not set -very- carefully. Hope this is useful! - MLD ps> Reminder to "reply all" to keep the discussion on the GR email list. More eyes reading means greater chances of someone providing useful help! On Thu, Jun 20, 2019, at 9:27 AM, Ramazan Çetin wrote: > Hello all, > > I have implemented OFDM system that has one receiver and two > transmitters. Receiver can receive signals correctly, when one of the > transmitters is active. However, when both of them are active, receiver > cannot receive all the packets. They are interfering each other. > > To overcome this situation, i tried to allocate different carriers to > transmitters. For example; in 256 carriers OFDM system, 1 to 120 is for > transmitter 1 and -120 to -1 is for transmitter 2. In this situation, > receiver cannot still receive entire packets, when both of them are active. > > At the end, i decided to give some gap between transmitters. So, 36 to > 90 and -36 to -90 are assigned to transmitters. But, result is same. I > have attached two pictures of spectrum. They represents state of one and > two transmitters are active. You can check the situation from there. > > > So, can you suggest a way to receive from two transmitters without > interference? > > Best regards. > > Ramazan > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > *Attachments:* > * s2.jpeg > * s1.jpeg ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Divide frequency by a constant
OK, I think I understand all that (it IS a shift in mind-set from my history;), BUT, at some point I need to send the bits at a fixed baud rate (e.g. 45.45). That is what was behind my question #2. Where / how can I do that? --- Barry Duggan On 2019-06-20 09:55, Müller wrote: Hi Barry, On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote: Marcus, Thank you for that. So now I have three questions: 1) Does it matter if one uses [brackets] or (parentheses) to enclose a vector? It appears not. That's Python syntax; [] means Python list (a mutable sequence of references to the contained elements), () means python tuple (immutable seq...). The difference is irrelevant in this case; it's just that [ 1 ] is a list containing the element 1 only, and ( 1 ) is just the number one (with parentheses around it, meaning nothing), so when explaining stuff, I'd prefer the more "explicit" []. (You'd need to do (1,) if you wanted a single-element tuple.) 2) What determines the rate at which the vector contents are presented to the output? Nothing :) This is just the exact sequence of numbers that are produced. It doesn't have a physical rate. GNU Radio will just repeat the vector on its output as fast as that output is emptied. The speed at which that happens is completely (!!) irrelevant to the math happening with that. I'd recommend trying to completely forget about these signals having something to do with an analog signal that changes over time, just for a moment. It's just a bunch of zeros and ones, one after the other. That goes through some processing steps, let's say it gets multiplied by 213 first and then 106.5 gets subtracted. Now it's still a bunch of numbers. Simply a sequence of numbers flowing through that flow graph. There's no rate, or speed notion attached to that. Now, these +106.5 and -106.5 values reach the frequency modulator. What that does is it takes each number, multiplies it with its sensitivity, adds the result to its internal phase accumulator, and produces a new number on its output, which is simply exp(j·phase); still, everything is just a sequence of numbers. Some of these numbers might have a value that depends on a variable that might for example be called samp_rate, or f_samp or whatever. But that just changes the values of the numbers, not the fact that their existence and calculation has nothing to do with real-world time. Now, at some point, these numbers are sent to a DAC of some kind. And now, that DAC actually is actually driven by some hardware clock that forces it to take one sample every so and so many nanoseconds. Double the speed of that clock, and you'd change the physical (frequency) "meaning" of the digital signal you convert to analog, but not the digital signal as is – it'd still be the same sequence of numbers. 3) If one were to add a 'throttle', where would it go? Is it needed here? Don't do it at all if you're actually building a modem. A throttle is just a "copy input sequence to output" block, that goes to sleep (as in: ask the operating system of your computer to wake it in so and so many microseconds) for a while to limit the average number of samples that it copies per second. You'd only do that if you're in a simulation, and don't want signal processing to happen as fast as it can (there not being a DAC that limits the rate at which they are consumed), but still e.g. want to look at the signal with a human eye at a sensible speed. In your modem example, the DAC already limits the speed; don't "double limit" it. From your obvious experience with digital clocked circuits, you know that in the wake of two independent clocks (your DAC's clock and your PC/operating system clock) there only lies madness, FIFO over- and underflows and tears. (same of course applies to reception: The ADC only gives us one sample per sampling period; then, we process the resulting sequence as fast as possible.) Of course, one of the main things you'd use GNU Radio for is to first design your modem in simulation before attaching real analog/digital or digital/analog conversion hardware to it. In that case: 1. If you want to test whether the modem works end-to-end, you'd attach your TX modem flowgraph to your RX modem flow graph (maybe with a block that simulates a wireless channel in between), and not throttle at all, but just send some finite amount of test data and check whether the result at the other end is the same. 2. But very often, you'd e.g. want to look at the output of your pulse shaper in real time (or slow motion); then you'd just add exactly one Throttle to your simulation, typically right at the visualization (that position doesn't matter too much, however – as you can infer from my description above, the whole flowgraph will always get the chunk of samples that your Throttle passed through, and process it as fast as it can, then go back into waiting for more data, while the throttle sleeps for as long as it needs to sustain the requested avera
Re: [Discuss-gnuradio] Divide frequency by a constant
ha! That's easier than I think you think it is :) So, you have some hardware to actually transmit. Let's, for the time being, assume we're doing an acoustocoupler using your soundcard. That's cool, because a) you very likely have that and b) it's easy to observe :D So, you use GNU Radio's Audio Sink block to send a sequence of numbers to the sound card, and also configure the sound card to run at 44.1 kilosamples per second. (44.1 kS/s is the most common rate that all soundcards can work at – I'm not 100% sure why Philips/Sony picked that rate when they designed the CD, but it has really stuck since that audio storage medium was introduced.) That sets the "meaning" of a sample period on the stream going into the Audio Sink. For example, a cosine going into that that takes 100 samples for a period will be a 441 Hz sound. Now, you want a 45.45 bd transmission. So, you need to make all the rate conversions from your symbol source to your audio sink implement a rate change by 44100 / 45.45. Let's say we use the simple idea from the StackOverflow answer I've linked to: * Use a (float) vector source to produce test input data; some [0,1,1,0,1, …] * Use the "repeat" block to repeat that 100× * Signal Source (let's call it "A"), float, amplitude 0.5, freq=1046, 4545 sampling rate (which really just tells the source to produce a cosine that has a period of 4545/1046 samples) * Multiply A with output of Repeat * Also connect output of repeat to "Add const, const=-1", and the output of that to "multiply const, const = -1"; that way, you get an "inverted" repeated bit stream * Signal Source, float, amplitude 0.5, freq=1277, 4545 sampling rate (which really just tells the source to produce a cosine that has a period of 4545/1277 samples) * multiply with the above inverted thing, let's call the result "B" * Use the Add block on A & B * Use a Rational Resampler block, decimation = 4545, interpolation = 44100 * Finally, connect to both a Qt GUI time sink (make sure to use 44100 as rate of that; it changes nothing, but makes the time axis be scaled like you want it) * and to the input of an Audio Sink, set to sampling rate 44100 * Don't turn up the volume on your speakers very much * Run the flowgraph In conclusion: Again, you nowhere actually use any software to set a processing / generation speed. You use your digitization / analogization (is that a word?) hardware to define what your signal means, and just use sample rate-converting processing blocks (in this case: a repetition by 100, and a resampler of rate 44100/4545) to make the sequences of numbers mean the right thing. Go "backwards", from the soundcard running at 44.1 kHz, through your flow graph, and notice what the rate of the input side of each must be to produce the rate on the output side: I hope it all makes sense then :) The resampler needs to consume 4545 samples on its input if its to produce 44100 on its output (that's why we picked the decimation and interpolation like we did). The add block needs one sample on each of its inputs per sample of output it produces, so we're still at 4545. Same for the Multipliers. The repeat block needs 0.01 input sample per output sample, so that gives you exactly the data rate at your input that you wanted. Best regards, Marcus On Thu, 2019-06-20 at 10:43 -0400, Barry Duggan wrote: > OK, I think I understand all that (it IS a shift in mind-set from my > history;), BUT, at some point I need to send the bits at a fixed baud > rate (e.g. 45.45). That is what was behind my question #2. Where / how > can I do that? > > --- > Barry Duggan > > > On 2019-06-20 09:55, Müller wrote: > > Hi Barry, > > > > On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote: > > > Marcus, > > > > > > Thank you for that. So now I have three questions: > > > 1) Does it matter if one uses [brackets] or (parentheses) to enclose a > > > vector? It appears not. > > > > That's Python syntax; [] means Python list (a mutable sequence of > > references to the contained elements), () means python tuple (immutable > > seq...). The difference is irrelevant in this case; it's just that > > [ 1 ] is a list containing the element 1 only, and ( 1 ) is just the > > number one (with parentheses around it, meaning nothing), so when > > explaining stuff, I'd prefer the more "explicit" []. (You'd need to do > > (1,) if you wanted a single-element tuple.) > > > > > 2) What determines the rate at which the vector contents are presented > > > to the output? > > > > Nothing :) > > > > This is just the exact sequence of numbers that are produced. It > > doesn't have a physical rate. > > GNU Radio will just repeat the vector on its output as fast as that > > output is emptied. The speed at which that happens is completely (!!) > > irrelevant to the math happening with that. > > > > I'd recommend trying to completely forget about these signals having > > something to do with an analog signal that changes over time, just
Re: [Discuss-gnuradio] Multiple-Transmitter OFDM
Hi Ramazan - Hmmm ... I'm not coming up with anything greatly useful when using a single OFDM block for Tx. Alternatively you could use a 2 channel PFB synthesizer on Tx, with 2 separate OFDM Tx and feed them into the synthesizer. On Rx use a PFB channelizer and take its 2 outputs to 2 separate OFDM Rx. The complexity of the PFBs will depend on the filtering required to keep the OFDM channels separate enough. Maybe others have useful ideas of how to do what you're looking for? Hope this is useful! - MLD On Thu, Jun 20, 2019, at 10:49 AM, Ramazan Çetin wrote: > Hi MLD, > You are right. I guess, one of the transmitters' preamble overlaps another's > data. (Because gnuradio sends preamble in all carriers). I have attached my > receiver and transmitters' FGs. Both of them uses 256 carrier OFDM. One > transmitter use half of the carriers as occupied and another uses other half. > I guess our receiver structure is wrong. > Can you suggest a way for implementing multi user OFDM system? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calling a function after every N samples
Hello, Thanks for the reply! More specifically, what I'm aiming for is to change frequency after transmitting some number of samples. I've tried having the sink call the set frequency commands each time 'work' is run, but that doesn't seem to help me set the length. I've tried using message passing, but that's not sufficient because that uses a sleep timer which is too inconsistent for what I'm doing. As for the vectorised data, it still doesn't time correctly since what I think the sink is doing is writing to a buffer in hardware. Though despite that, the timing result is consistent in the first method I listed. Is there a way to trigger command execution in response to specific samples? Or any way to precisely time frequency changes? Thanks, Kevin On Thu, Jun 13, 2019, 4:33 PM Michael Dickens wrote: > Hi Kevin - Maybe use the tagged_stream or a PDU or vectorized data? There > are various ways to do what you want that will guarantee N samples that you > could then trigger a function call on. The better one to use really depends > on what you actually want to do once you have your N samples. - MLD > > On Thu, Jun 13, 2019, at 3:32 PM, Kevin Lee wrote: > > Hello all, > > I'm working on a project that requires that I synchronously issue a > command to the sink I wrote after processing every "N" samples. In my > reading, I came to the understanding that a good way to do this would be to > use tagged streams or PDUs with message passing. I've read through the > Guided Tutorial Programming Topics page, so I have a basic understanding of > the above concepts. Adding a tag every N samples is simple enough but I'm > struggling on figuring out how to get a block to send a message as a > reaction to a sample being processed, since GR blocks work in groups of > samples and the 'get_tags_in_*' functions can only return tags in ranges, > so that rules out tags, and message passing uses asynchronous timers. If > anyone can offer any insight that would be greatly appreciated. > > Thanks for your help, > Kevin > ___ > 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] Divide frequency by a constant
Marcus, OK, so that works. Now I have more questions! 1) Since the vector source has a repeat option, why use the Repeat block? Does it still need a 'vector to stream' function? 2) What criteria did you use to pick the 4,545 sample rate? If there were no repeat, what would you do? The repeat of 100 seems to go with the sample rate. 3) If I change the frequencies to the US standard 2295 / 2125 Hz, do I need to change the sample rate? It's not quite twice the 2295 frequency. 4) Looking at the output of the rational resampler, it needs a low-pass filter. How can I add one without messing up the timing? I *really* appreciate all your help on this! --- Barry Duggan On 2019-06-20 11:10, Müller wrote: ha! That's easier than I think you think it is :) So, you have some hardware to actually transmit. Let's, for the time being, assume we're doing an acoustocoupler using your soundcard. That's cool, because a) you very likely have that and b) it's easy to observe :D So, you use GNU Radio's Audio Sink block to send a sequence of numbers to the sound card, and also configure the sound card to run at 44.1 kilosamples per second. (44.1 kS/s is the most common rate that all soundcards can work at – I'm not 100% sure why Philips/Sony picked that rate when they designed the CD, but it has really stuck since that audio storage medium was introduced.) That sets the "meaning" of a sample period on the stream going into the Audio Sink. For example, a cosine going into that that takes 100 samples for a period will be a 441 Hz sound. Now, you want a 45.45 bd transmission. So, you need to make all the rate conversions from your symbol source to your audio sink implement a rate change by 44100 / 45.45. Let's say we use the simple idea from the StackOverflow answer I've linked to: * Use a (float) vector source to produce test input data; some [0,1,1,0,1, …] * Use the "repeat" block to repeat that 100× * Signal Source (let's call it "A"), float, amplitude 0.5, freq=1046, 4545 sampling rate (which really just tells the source to produce a cosine that has a period of 4545/1046 samples) * Multiply A with output of Repeat * Also connect output of repeat to "Add const, const=-1", and the output of that to "multiply const, const = -1"; that way, you get an "inverted" repeated bit stream * Signal Source, float, amplitude 0.5, freq=1277, 4545 sampling rate (which really just tells the source to produce a cosine that has a period of 4545/1277 samples) * multiply with the above inverted thing, let's call the result "B" * Use the Add block on A & B * Use a Rational Resampler block, decimation = 4545, interpolation = 44100 * Finally, connect to both a Qt GUI time sink (make sure to use 44100 as rate of that; it changes nothing, but makes the time axis be scaled like you want it) * and to the input of an Audio Sink, set to sampling rate 44100 * Don't turn up the volume on your speakers very much * Run the flowgraph In conclusion: Again, you nowhere actually use any software to set a processing / generation speed. You use your digitization / analogization (is that a word?) hardware to define what your signal means, and just use sample rate-converting processing blocks (in this case: a repetition by 100, and a resampler of rate 44100/4545) to make the sequences of numbers mean the right thing. Go "backwards", from the soundcard running at 44.1 kHz, through your flow graph, and notice what the rate of the input side of each must be to produce the rate on the output side: I hope it all makes sense then :) The resampler needs to consume 4545 samples on its input if its to produce 44100 on its output (that's why we picked the decimation and interpolation like we did). The add block needs one sample on each of its inputs per sample of output it produces, so we're still at 4545. Same for the Multipliers. The repeat block needs 0.01 input sample per output sample, so that gives you exactly the data rate at your input that you wanted. Best regards, Marcus On Thu, 2019-06-20 at 10:43 -0400, Barry Duggan wrote: OK, I think I understand all that (it IS a shift in mind-set from my history;), BUT, at some point I need to send the bits at a fixed baud rate (e.g. 45.45). That is what was behind my question #2. Where / how can I do that? --- Barry Duggan On 2019-06-20 09:55, Müller wrote: > Hi Barry, > > On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote: > > Marcus, > > > > Thank you for that. So now I have three questions: > > 1) Does it matter if one uses [brackets] or (parentheses) to enclose a > > vector? It appears not. > > That's Python syntax; [] means Python list (a mutable sequence of > references to the contained elements), () means python tuple (immutable > seq...). The difference is irrelevant in this case; it's just that > [ 1 ] is a list containing the element 1 only, and ( 1 ) is just the > number one (with parentheses around it, meaning nothing), so when > explaining stuff, I'd prefer th
Re: [Discuss-gnuradio] Divide frequency by a constant
Hi Barry, on my way to bed, so really quick: On Thu, 2019-06-20 at 17:48 -0400, Barry Duggan wrote: > Marcus, > > OK, so that works. Now I have more questions! > > 1) Since the vector source has a repeat option, why use the Repeat > block? Does it still need a 'vector to stream' function? The vector source's "repeat" option just says the vector source should just repeat producing its sequence on the output forever. Without that, it emits the vector once, and then says "I'm done; shut down this thing". The repeat block takes every input sample, and repeats it. Illustration: Vector source, sequence = A B C D, repeat = True: A B C D A B C D … Repeat block, input stream = A B C D, repetitions = 4 A A A A B B B B C C C C D D D D > 2) What criteria did you use to pick the 4,545 sample rate? If there > were no repeat, what would you do? The repeat of 100 seems to go with > the sample rate. I just used the 45.45 bd you said you'd wanted to use and rolled with it, and the fact that I used a factor of 100 and not say, 101 or 7 was just because 100 is such a nice number :) > 3) If I change the frequencies to the US standard 2295 / 2125 Hz, do I > need to change the sample rate? It's not quite twice the 2295 frequency. Yep; but that just means that you for example repeat by 200, and thus use 9090 as "intermediate" rate, or so. As you can guess, one could computationally optimize the hell out of this, but at these rates, your computer is not even beginning to break a sweat. > 4) Looking at the output of the rational resampler, it needs a low-pass > filter. How can I add one without messing up the timing? > The Rational Resampler block *should* automatically use a low-pass filter if your enter nothing in the "Taps" field. Does it not? > I *really* appreciate all your help on this! You're welcome :) It's fun to talk about all this once in a while. Best regards, Marcus > > --- > Barry Duggan > > > On 2019-06-20 11:10, Müller wrote: > > ha! That's easier than I think you think it is :) > > > > So, you have some hardware to actually transmit. Let's, for the time > > being, assume we're doing an acoustocoupler using your soundcard. > > That's cool, because a) you very likely have that and b) it's easy to > > observe :D > > > > So, you use GNU Radio's Audio Sink block to send a sequence of numbers > > to the sound card, and also configure the sound card to run at 44.1 > > kilosamples per second. (44.1 kS/s is the most common rate that all > > soundcards can work at – I'm not 100% sure why Philips/Sony picked that > > rate when they designed the CD, but it has really stuck since that > > audio storage medium was introduced.) > > > > That sets the "meaning" of a sample period on the stream going into the > > Audio Sink. For example, a cosine going into that that takes 100 > > samples for a period will be a 441 Hz sound. > > > > Now, you want a 45.45 bd transmission. So, you need to make all the > > rate conversions from your symbol source to your audio sink implement a > > rate change by 44100 / 45.45. > > > > Let's say we use the simple idea from the StackOverflow answer I've > > linked to: > > > > * Use a (float) vector source to produce test input data; some > > [0,1,1,0,1, …] > > > > * Use the "repeat" block to repeat that 100× > > > > * Signal Source (let's call it "A"), float, amplitude 0.5, freq=1046, > > 4545 sampling rate (which really just tells the source to produce a > > cosine that has a period of 4545/1046 samples) > > * Multiply A with output of Repeat > > > > * Also connect output of repeat to "Add const, const=-1", and the > > output of that to "multiply const, const = -1"; that way, you get an > > "inverted" repeated bit stream > > * Signal Source, float, amplitude 0.5, freq=1277, 4545 sampling rate > > (which really just tells the source to produce a cosine that has a > > period of 4545/1277 samples) > > * multiply with the above inverted thing, let's call the result "B" > > > > * Use the Add block on A & B > > > > * Use a Rational Resampler block, decimation = 4545, interpolation = > > 44100 > > > > * Finally, connect to both a Qt GUI time sink (make sure to use 44100 > > as rate of that; it changes nothing, but makes the time axis be scaled > > like you want it) > > * and to the input of an Audio Sink, set to sampling rate 44100 > > > > * Don't turn up the volume on your speakers very much > > * Run the flowgraph > > > > > > > > In conclusion: Again, you nowhere actually use any software to set a > > processing / generation speed. You use your digitization / > > analogization (is that a word?) hardware to define what your signal > > means, and just use sample rate-converting processing blocks (in this > > case: a repetition by 100, and a resampler of rate 44100/4545) to make > > the sequences of numbers mean the right thing. > > > > Go "backwards", from the soundcard running at 44.1 kHz, through your > > flow graph, and notice what the
