Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 187, Issue 12

[F salem]

Dear all,

I have mini project I need to implement it with SDR-RTL the idea is gathering 
sensors data by SDR.

if you have any resources that can help me please share it

Sincerely
Fahad

From: Discuss-gnuradio  
on behalf of discuss-gnuradio-requ...@gnu.org 
Sent: Thursday, May 10, 2018 11:49:46 PM
To: discuss-gnuradio@gnu.org
Subject: Discuss-gnuradio Digest, Vol 187, Issue 12

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org

You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: RTP block / Opus vocoder (Albin Stig?)
   2. Audio File transmission using Qpsk modulation (JONNY LEYIKUN)
   3. Re: Audio File transmission using Qpsk modulation (Jeff Long)
   4. Re: RTP block / Opus vocoder (Adrian Musceac)
   5. Re: RTP block / Opus vocoder (Albin Stig?)


--

Message: 1
Date: Thu, 10 May 2018 18:49:24 +0200
From: Albin Stig? 
To: Michelle Thompson 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] RTP block / Opus vocoder
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Hi Michelle,

Well my need for RTP/Opus is because of a Raspberry Pi FPGA based
shortwave transceiver for remote ham radio I'm building together with
Daniel, sm6vfz.

Today I sat down and wrote an RTP/Opus sink block and I have to say
it's working really well. I'm using libopus and jrtplib. My original
plan was to create two blocks: an Opus vocoder and and an RTP block
but after a while I found that that didn't make a lot of sense. RTP is
not designed to be a standalone protocol and is very application
specific. So in the end I wrote a combined block. It's probably not
more than 100 lines of C++ more than the boilerplate. Of course I will
have to add a bit more to make it fully configurable. I also haven't
written the xml for grc yet.

I will of course open source my work when I'm a bit further...

Next on my list is to add clock drift compensation on the alsasink.


--Albin SM6WJM

On Thu, May 10, 2018 at 4:54 PM, Michelle Thompson
 wrote:
> Hi Albin,
>
> We have a similar interest in getting RTP functionality in GNU Radio.
>
> Phil Karn recently wrote and published an SDR package for Phase 4 Ground
> that includes RTP multicast functionality. We have been talking about
> getting this functionality into GNU Radio. Another person interested in
> seeing this happen is David Rowetel from FreeDV. He and Phil have started
> talking about this.
>
> Ron and Marcus are of course correct in that RTP streams are already handled
> pretty well in GNU Radio. No, we do not want to reinvent the wheel.
>
> We would like to combine Opus/CODEC2 and RTP multicast to have stereo field
> audio. The sources of the audio appear at different points in the stereo
> field, so that a roundtable conversation feels more like a roundtable, or so
> that two streams from two different SDRs are distinct.
>
> Everyone is welcome to comment and contribute. The repository with the RTP
> multicast code from Phil Karn is here:
> https://github.com/phase4ground/ka9q-sdr
>
> If it can be done without a new block, then great. If there is value in
> handling bookkeeping, or functions in RTP multicast that would be much
> easier or much more useful in flowgraphs with a new block, then that's what
> we want to do. I have advice that it would be useful to get it into blocks.
> We want to do the right thing and we want comment and critique.
>
> Phase 4 Ground will have a "block party" at GNU Radio Conference 2018. The
> overall goal of Phase 4 Ground is to get DVB-S2 and DVB-S2X receive in GNU
> Radio. We have a dedicated room/lab for the week of the conference and will
> bring as much test equipment as we can fit into a minivan. Several
> satellite/modem/DVB docents have signed up and we're working on swag! If you
> have interest or expertise in any area of DVB-S2 receiver design, then we
> enthusiastically welcome you. We have a Slack and a mailing list.
> https://lists.openresearch.institute/
>
> One of the hard parts of the receiver is the LDPC FEC decode. We have one
> working implementation from Charles Brain, written for a GPU. It needs some
> work to get adaptive coding and modulation (we want ACM) working due to the
> architectural choices. It's a big achievement 

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 187, Issue 13

[Ed Criscuolo]

If you just hit reply, it only goes back to the poster. You need to hit "reply 
all" to get it to go back to the list. 

@(^.^)@ Ed
Sent from my iPhone

> On May 11, 2018, at 1:40 PM, F salem  wrote:
> 
> Dear all 
> 
> I made alot of post but it didn't shown in the list why?
> 
> sincerely
> Fahad Alqurashi
> 
>  
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GsoC'18] Updates

[Luca Schmid]

Hi all,

I just published my weekly blog post about the progress of this week[1]. I
worked on the diversity combining block.

Best
Luca

[1]  https://mimognuradio.wordpress.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus E310 sample rate

[Derek Kozel]

Hello Laura,

The ADCs and DACs do support running at 61.44 MS/s. However the ARM
processor is not able to handle data traffic at that rate so some of the
processing must be done in the FPGA. Depending on the application about 10
MS/s is an achievable rate.

Both 12 MS/s and 8 MS/s are not integer divisors of 61.44 MHz so the ADC
rate is being changed behind the scenes to support those rates, probably to
16 or 32 MHz. You can explicitly set that by adding an argument to the
benchmark_rate or similar utility.

benchmark_rate --args master_clock_rate=36e6 --rx_rate 12e6 --tx_rate 12e6
http://files.ettus.com/manual/page_configuration.html

Regards,
Derek


On Fri, May 11, 2018 at 7:37 PM, Laura Huddleston <
laura.huddles...@ierustech.com> wrote:

> Happy Friday,
>
>
>
> What is the max sample rate for the Ettus e310?
>
>
>
> When I ssh in and perform the benchmark_test, I get the following:
>
>
>
> $/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
>
> .
>
>  . [other stuff here]
>
>.
>
> UHD Warning:
>
> The hardware does not support the requested TX sample rate:
>
> Target sample rate: 12.00 MSps
>
> Actual sample rate: 8.00 MSps
>
> Testing transmit rate 8.00 Msps on 1 channels
>
>
>
> When I set the target sample rate to 16MS/s, I get OO.
>
>
>
> Does this mean that 8MS/s is the highest sample rate which the e310 will
> work?
>
>
>
> The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so shouldn’t
> I be able to stream data at a divisible of this?
>
>
>
> ~
>
> Laura Huddleston
>
>
>
>
>
> ___
> 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] Ettus E310 sample rate

[Nick Foster]

Oh, in addition -- there's a single "radio clock" which is picked based on
the transmit and receive sample rates. This means that, while you have
nearly infinite flexibility as to the sample rate used for just RX or just
TX, when you are using both simultaneously their rates will be tied to each
other as divisors of the common radio clock rate. You can see this clock
rate printed as "master clock rate" when UHD initializes your flowgraph.

Nick

On Fri, May 11, 2018 at 11:46 AM Nick Foster  wrote:

> 8MS/s is about what you can stream *through the host processor* on E310.
> Full-rate streaming is supported just fine through the FPGA fabric. If you
> need to do faster rate streaming on the E310, you need to do the processing
> in the FPGA.
>
> Nick
>
>
> On Fri, May 11, 2018 at 11:39 AM Laura Huddleston <
> laura.huddles...@ierustech.com> wrote:
>
>> Happy Friday,
>>
>>
>>
>> What is the max sample rate for the Ettus e310?
>>
>>
>>
>> When I ssh in and perform the benchmark_test, I get the following:
>>
>>
>>
>> $/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
>>
>> .
>>
>>  . [other stuff here]
>>
>>.
>>
>> UHD Warning:
>>
>> The hardware does not support the requested TX sample rate:
>>
>> Target sample rate: 12.00 MSps
>>
>> Actual sample rate: 8.00 MSps
>>
>> Testing transmit rate 8.00 Msps on 1 channels
>>
>>
>>
>> When I set the target sample rate to 16MS/s, I get OO.
>>
>>
>>
>> Does this mean that 8MS/s is the highest sample rate which the e310 will
>> work?
>>
>>
>>
>> The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so
>> shouldn’t I be able to stream data at a divisible of this?
>>
>>
>>
>> ~
>>
>> Laura Huddleston
>>
>>
>>
>>
>> ___
>> 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] Ettus E310 sample rate

[Nick Foster]

8MS/s is about what you can stream *through the host processor* on E310.
Full-rate streaming is supported just fine through the FPGA fabric. If you
need to do faster rate streaming on the E310, you need to do the processing
in the FPGA.

Nick


On Fri, May 11, 2018 at 11:39 AM Laura Huddleston <
laura.huddles...@ierustech.com> wrote:

> Happy Friday,
>
>
>
> What is the max sample rate for the Ettus e310?
>
>
>
> When I ssh in and perform the benchmark_test, I get the following:
>
>
>
> $/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
>
> .
>
>  . [other stuff here]
>
>.
>
> UHD Warning:
>
> The hardware does not support the requested TX sample rate:
>
> Target sample rate: 12.00 MSps
>
> Actual sample rate: 8.00 MSps
>
> Testing transmit rate 8.00 Msps on 1 channels
>
>
>
> When I set the target sample rate to 16MS/s, I get OO.
>
>
>
> Does this mean that 8MS/s is the highest sample rate which the e310 will
> work?
>
>
>
> The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so shouldn’t
> I be able to stream data at a divisible of this?
>
>
>
> ~
>
> Laura Huddleston
>
>
>
>
> ___
> 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] Ettus E310 sample rate

[Laura Huddleston]

Happy Friday,

What is the max sample rate for the Ettus e310?

When I ssh in and perform the benchmark_test, I get the following:

$/usr/lib/uhd/examples/benchmark_rate --rx_rate 12e6 --tx_rate 12e6
.
 . [other stuff here]
   .
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 12.00 MSps
Actual sample rate: 8.00 MSps
Testing transmit rate 8.00 Msps on 1 channels

When I set the target sample rate to 16MS/s, I get OO.

Does this mean that 8MS/s is the highest sample rate which the e310 will work?

The data sheet says the max ADC/DAC sample rate is 61.44MS/s, so shouldn't I be 
able to stream data at a divisible of this?

~
Laura Huddleston


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 187, Issue 13

[F salem]

t;
> > > 1)  I would like to transmit burst signals of the chirp
> > > generated  from the flowgraph attached. I tried using the ?stream
> > > to
> > > Tagged stream? way, but when I ran the GNU Radio Companion, it?s
> > > being  transmitted continuously. Nothing seems to be happening.
> > > Am
> > > I
> > > doing  something wrong and is there a better way for burst
> > > transmission?
> > >
> > > Does anyone know this?
> > >
> > > Thanks in advanced!
> > >
> > > -Original Message-
> > > From: M?ller, Marcus (CEL) [mailto:muel...@kit.edu]
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > >
> > > Hi!
> > >
> > > your receiver low pass filter is incorrectly parameterized,
> > > probably
> > > (sampling rate isn't 32 MS/s). And so is the rest of your flow
> > > graph
> > > ?
> > > your USRP is using a sampling rate of 2 MS/s, but you act as if
> > > it's
> > > running at 32 MS/s. Start with 2 MS/s and make it work with that
> > > ?
> > > then
> > > later scale up (the processing load of 32 MS/s is harder than you
> > > probably think).
> > > Remember that GNU Radio is pure DSP, so all the axis labels on
> > > your
> > > visualizations are just that ? labels, interpreting relative
> > > frequencies (i.e. frequencies divided by the sampling rate) by
> > > multiplying them with the value you entered in bandwidth. The
> > > "physical
> > > meaning" of your signal is defined by the sampling rate of your
> > > physical device.
> > > Thus, you want to use the same sampling rate everywhere in your
> > > flow
> > > graph. These things mean! something.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Thu, 2018-05-10 at 08:31 +, Yeo Jin Kuang Alvin (IA)
> > > wrote:
> > > > Hi everyone,
> > > >
> > > > There are two questions that I would like to ask.
> > > >
> > > > 1)  I would like to transmit burst signals of the chirp
> > > > generated
> > > > from the flowgraph attached. I tried using the ?stream to
> > > > Tagged
> > > > stream? way, but when I ran the GNU Radio Companion, it?s being
> > > > transmitted continuously. Nothing seems to be happening. Am I
> > > > doing
> > > > something wrong and is there a better way for burst
> > > > transmission?
> > > >
> > > > 2)  I noticed something with the sampling rates of the
> > > > blocks.
> > > > When I use the same sampling rate for all the blocks, I get
> > > > underflow
> > > > ?UUU?. However, when I changed all the block?s sampling rate to
> > > > 32MHz
> > > > and leave the USRP Sink and Source to 2MHz, no underflow is
> > > > seen
> > > > but
> > > > there is still overflow (seen in the attached screenshot).
> > > >
> > > > What is the difference between the USRP?s sampling rate
> > > > compared
> > > > to
> > > > the other block?s sampling rate?
> > > >
> > > > Thank you in advanced!
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6582 bytes
Desc: not available
URL: 
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180511/9325cae6/attachment.bin>

--

Message: 5
Date: Fri, 11 May 2018 07:23:02 +
From: "Yeo Jin Kuang Alvin (IA)" <yjink...@dso.org.sg>
To: M?ller, Marcus (CEL) <muel...@kit.edu>, "discuss-gnuradio@gnu.org"
<discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
Message-ID:
<bf2ea3e2db941c44bb80f1758ede3f4049b...@gawain.dsonet.corp.root>
Content-Type: text/plain; charset="utf-8"

Hi,

I want to simulate the radar delay by having real time receive, modulation and 
transmission of radar signal for ground testing purposes. Therefore, I need 2 
TX channel and 1 RX, the first TX is to transmit out the sign

Re: [Discuss-gnuradio] Rx to tx GNU Radio

[Brent Stapleton]

Hi Yeo,

Could you provide more details? Providing a GRC file would be helpful. What
kind of USRP are you using? What physical connections do you have on the
device? What version of GNU Radio are you using? From a high level, you
should be able to TX and RX simultaneously without error.

Best Regards,
Brent

On Fri, May 11, 2018 at 1:02 AM, Yeo Jin Kuang Alvin (IA) <
yjink...@dso.org.sg> wrote:

> Hi all,
>
>
>
> I’ve seen some examples and managed to do a tx and rx loopback to file
> using both C++ and GNU Radio. However, now I would like to receive and
> transmit the same signal out. I tried connecting USRP Source block to USRP
> Sink, and I see lots of “LL” which is late packets. Anyone has any idea
> on how to do a receive and transmit the same signal out in real time using
> GNU Radio Companion?
>
>
>
> Thank you in advanced!
>
> ___
> 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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Sumit Kumar]

Hi bastian,

To solve the following issue (as you predicted):

*"Consider what happens if one branch receives frames while the other 
one doesn't,Consider what happens if one branch receives frames while 
the other one doesn't."


*I combine the LLR of the SIGNAL fields from two branches and use that 
to decode the SIGNAL filed. The decision is used to decode both the 
branches. As of now it works, I mean doesn't crash at all! *




*Could you comment on this configuration.

Regards

Sumit
*

*
On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals according 
to their SNR, we combine the LLRs from separate branches and send 
them to Soft Decision Viterbi Decoder (SDVD). For this, I have 
modified gr-ieee 80211 which generates soft bits and integrated a 
SDVD with it. It works good when I use either single branch or both 
branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx 
A and Tx/Rx B ports as my receive branches. The LEDs go green for a 
second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so I 
am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and the 
results when I use simulations.






___
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] Rx to tx GNU Radio

[Yeo Jin Kuang Alvin (IA)]

Hi all,

I've seen some examples and managed to do a tx and rx loopback to file using 
both C++ and GNU Radio. However, now I would like to receive and transmit the 
same signal out. I tried connecting USRP Source block to USRP Sink, and I see 
lots of "LL" which is late packets. Anyone has any idea on how to do a 
receive and transmit the same signal out in real time using GNU Radio Companion?

Thank you in advanced!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tx Burst for Chirp signals

[Yeo Jin Kuang Alvin (IA)]

Hi,

I want to simulate the radar delay by having real time receive, modulation and 
transmission of radar signal for ground testing purposes. Therefore, I need 2 
TX channel and 1 RX, the first TX is to transmit out the signal to simulate a 
device transmitting to me elsewhere. Then the RX will take in this signal and 
do some DSP and then re-transmit back out to the device using the 2nd TX port 
in the USRP B210. The signal I am tasked to do is a radar signal and I have to 
transmit out one pulse width of the chirp and wait for certain amount of time 
before sending another pulse.

Thank you in advanced!

-Original Message-
From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
Sent: Friday, 11 May 2018 3:05 PM
To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals

Could you be a little more specific, please, than "receive, digitize
and re-transmit"? For what purpose? Why a chirp? Can you please give us
the bigger picture, here? What's the thing you need to build?

Best regards,
Marcus
On Fri, 2018-05-11 at 02:03 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hello,
> 
> I am currently trying to work on the USRP B210 to act as a
> transceiver. Basically, what I am tasked to do is to receive,
> digitize, modulate and re-transmit. So what I am planning to do now
> is to create a chirp signal in the USRP B210 and transmit back to
> itself to the RX port. As a result, I have to send a pulse and stop
> for a moment while it is receiving and then transmit again.
> 
> Thank you in advanced!
> 
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 10 May 2018 9:09 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> 
> sure, but it's not the way I'd recommend for perfectly periodic
> transmissions and I'm almost certain this will just lead us further
> down your XY problem: https://xyproblem.info
> 
> Can you maybe explain in detail what you need chirps for, why you
> need
> them at this low repitition rate, what the purpose of all this is? We
> might be better at helping you that way.
> 
> thank you,
> Marcus
> 
> On Thu, 2018-05-10 at 09:58 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi,
> > 
> > Thank you again. Are there any examples or guides I can refer to
> > regarding the tx_time tags? Will this allow me to transmit every
> > few
> > seconds?
> > 
> > Thank you in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 10 May 2018 5:34 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > 
> > Hi!
> > 
> > So, you're continuously generating data to send, so it continuously
> > sends data – it works as you've designed it. Maybe you want to
> > somehow
> > add "tx_time" tags every "packet length" samples?
> > Also, make sure that one packet really contains one chirp. In your
> > previous flow graph, that wasn't the case, so make sure the packet
> > length corresponds to the number of samples per chirp.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-05-10 at 09:20 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi, 
> > > 
> > > Thanks Marcus! Corrected it and thanks for the info!
> > > 
> > > 1)  I would like to transmit burst signals of the chirp
> > > generated  from the flowgraph attached. I tried using the “stream
> > > to
> > > Tagged stream” way, but when I ran the GNU Radio Companion, it’s
> > > being  transmitted continuously. Nothing seems to be happening.
> > > Am
> > > I
> > > doing  something wrong and is there a better way for burst
> > > transmission?
> > > 
> > > Does anyone know this?
> > > 
> > > Thanks in advanced!
> > > 
> > > -Original Message-
> > > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > > 
> > > Hi!
> > > 
> > > your receiver low pass filter is incorrectly parameterized,
> > > probably
> > > (sampling rate isn't 32 MS/s). And so is the rest of your flow
> > > graph
> > > –
> > > your USRP is using a sampling rate of 2 MS/s, but you act as if
> > > it's
> > > running at 32 MS/s. Start with 2 MS/s and make it work with that
> > > –
> > > then
> > > later scale up (the processing load of 32 MS/s is harder than you
> > > probably think).
> > > Remember that GNU Radio is pure DSP, so all the axis labels on
> > > your
> > > visualizations are just that – labels, interpreting relative
> > > frequencies (i.e. frequencies divided by the sampling rate) by
> > > multiplying them with the value you entered in bandwidth. The
> > > "physical
> > > meaning" of your signal is defined by the sampling rate of your
> > > physical device.
> > > Thus, you want to use the same sampling rate 

Re: [Discuss-gnuradio] Tx Burst for Chirp signals

[CEL]

Could you be a little more specific, please, than "receive, digitize
and re-transmit"? For what purpose? Why a chirp? Can you please give us
the bigger picture, here? What's the thing you need to build?

Best regards,
Marcus
On Fri, 2018-05-11 at 02:03 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hello,
> 
> I am currently trying to work on the USRP B210 to act as a
> transceiver. Basically, what I am tasked to do is to receive,
> digitize, modulate and re-transmit. So what I am planning to do now
> is to create a chirp signal in the USRP B210 and transmit back to
> itself to the RX port. As a result, I have to send a pulse and stop
> for a moment while it is receiving and then transmit again.
> 
> Thank you in advanced!
> 
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 10 May 2018 9:09 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> 
> sure, but it's not the way I'd recommend for perfectly periodic
> transmissions and I'm almost certain this will just lead us further
> down your XY problem: https://xyproblem.info
> 
> Can you maybe explain in detail what you need chirps for, why you
> need
> them at this low repitition rate, what the purpose of all this is? We
> might be better at helping you that way.
> 
> thank you,
> Marcus
> 
> On Thu, 2018-05-10 at 09:58 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi,
> > 
> > Thank you again. Are there any examples or guides I can refer to
> > regarding the tx_time tags? Will this allow me to transmit every
> > few
> > seconds?
> > 
> > Thank you in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 10 May 2018 5:34 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > 
> > Hi!
> > 
> > So, you're continuously generating data to send, so it continuously
> > sends data – it works as you've designed it. Maybe you want to
> > somehow
> > add "tx_time" tags every "packet length" samples?
> > Also, make sure that one packet really contains one chirp. In your
> > previous flow graph, that wasn't the case, so make sure the packet
> > length corresponds to the number of samples per chirp.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-05-10 at 09:20 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi, 
> > > 
> > > Thanks Marcus! Corrected it and thanks for the info!
> > > 
> > > 1)  I would like to transmit burst signals of the chirp
> > > generated  from the flowgraph attached. I tried using the “stream
> > > to
> > > Tagged stream” way, but when I ran the GNU Radio Companion, it’s
> > > being  transmitted continuously. Nothing seems to be happening.
> > > Am
> > > I
> > > doing  something wrong and is there a better way for burst
> > > transmission?
> > > 
> > > Does anyone know this?
> > > 
> > > Thanks in advanced!
> > > 
> > > -Original Message-
> > > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > > 
> > > Hi!
> > > 
> > > your receiver low pass filter is incorrectly parameterized,
> > > probably
> > > (sampling rate isn't 32 MS/s). And so is the rest of your flow
> > > graph
> > > –
> > > your USRP is using a sampling rate of 2 MS/s, but you act as if
> > > it's
> > > running at 32 MS/s. Start with 2 MS/s and make it work with that
> > > –
> > > then
> > > later scale up (the processing load of 32 MS/s is harder than you
> > > probably think).
> > > Remember that GNU Radio is pure DSP, so all the axis labels on
> > > your
> > > visualizations are just that – labels, interpreting relative
> > > frequencies (i.e. frequencies divided by the sampling rate) by
> > > multiplying them with the value you entered in bandwidth. The
> > > "physical
> > > meaning" of your signal is defined by the sampling rate of your
> > > physical device.
> > > Thus, you want to use the same sampling rate everywhere in your
> > > flow
> > > graph. These things mean! something.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Thu, 2018-05-10 at 08:31 +, Yeo Jin Kuang Alvin (IA)
> > > wrote:
> > > > Hi everyone,
> > > >  
> > > > There are two questions that I would like to ask.
> > > >  
> > > > 1)  I would like to transmit burst signals of the chirp
> > > > generated
> > > > from the flowgraph attached. I tried using the “stream to
> > > > Tagged
> > > > stream” way, but when I ran the GNU Radio Companion, it’s being
> > > > transmitted continuously. Nothing seems to be happening. Am I
> > > > doing
> > > > something wrong and is there a better way for burst
> > > > transmission?
> > > >  
> > > > 2)  I noticed something with the sampling rates of the
> > > > blocks.
> > > > When I use the same sampling rate for all