Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Audio File transmission using Qpsk modulation (JONNY LEYIKUN)
2. Re: RTP block / Opus vocoder (Adrian Musceac)
3. Re: Tx Burst for Chirp signals (Yeo Jin Kuang Alvin (IA))
4. Re: Tx Burst for Chirp signals (M?ller)
5. Re: Tx Burst for Chirp signals (Yeo Jin Kuang Alvin (IA))
6. Rx to tx GNU Radio (Yeo Jin Kuang Alvin (IA))
7. Re: Issue while adding streaming data : Integrating MRC in
gr-ieee 80211 (Sumit Kumar)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 May 2018 17:29:25 -0400
From: JONNY LEYIKUN <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Audio File transmission using Qpsk
modulation
Message-ID:
<CALfqmmekXruoRV+k9Q03+hhutrtgdC=a2SUFwbS3+address@hidden>
Content-Type: text/plain; charset="utf-8"
HI Jeff Long
Yaah 15K is very minimum to use in USRP sink
I use 15K sample rate in order to get clear Audio File. but I also use
large sample rate in USRP sink but the result is more or less the same
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/32df669c/attachment.html>
------------------------------
Message: 2
Date: Fri, 11 May 2018 00:34:06 +0300
From: Adrian Musceac <address@hidden>
To: Albin Stig? <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] RTP block / Opus vocoder
Message-ID:
<CA+yUT9-f1b9QjxKD3gx6XDg+Ns-5kYCp=q3ZfH_gj498a3P6+address@hidden>
Content-Type: text/plain; charset="UTF-8"
Hi Albin,
Sorry, I was under the impression that RTP would be transmitted over
the air, which in some cases might make sense... like IP multicast
over MPEG-TS over DVB-S. But for Codec2 it does seem like raw audio
transmission is better suited. So then why the need for a Codec2/Opus
RTP block? I would think it would be better left to the application
layer outside GNU Radio to handle IP routing of audio streams?
My previous approach was to use GNU Radio blocks only for the PHY
layer, and use a simple and robust VOIP protocol (Mumble) to
distribute audio over TCP/IP, with some transcoding involved in case
of FM and Codec2 digital voice. With a single GNU Radio instance I
could then serve up to 4 voice channels and one control channel using
FDMA, with a mix of analog and digital channels.
Then again, this is just an amateur radio perspective, where network
capacity is not such a big issue and infrastructure density or SNR
performance are the limiting factor.
Regards,
Adrian YO8RZZ
On 5/10/18, Albin Stig? <address@hidden> wrote:
> Hi Adrian,
>
> UDP and RTP adds a lot of overhead to a codec like Codec2 and doesn't
> make any sense at all unless you wan't to route your packets over an
> IP WAN like the internet. Then it makes a lot of sense.
>
> I imagine the only use case for an RTP/Codec2 or RTP/Opus block is
> streaming audio from a remote receiver/transceiver over an existing IP
> network. If you only stream over LAN, UDP is good enough but the
> Internet an stack RTP is better. All streaming software like skype,
> facetime, hangouts etc use RTP.
>
>
> --Albin SM6WJM
>
> On Thu, May 10, 2018 at 10:05 PM, Adrian Musceac <address@hidden>
> wrote:
>>>
>>> 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.
>>>
>>
>> Hi Michelle,
>>
>> This is very interesting to me. I did some work with Codec2, Opus and
>> GNU Radio myself.
>> I'm curious though: RTP and UDP + IP encapsulation, isn't that a bit
>> too much overhead for a low bitrate codec like Codec2? A 40 msec audio
>> frame encoded with Codec2 1400 is only 48 bits, so the encapsulation
>> overhead is quite large. How does that affect low SNR performance?
>>
>> Regards,
>> Adrian YO8RZZ
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 3
Date: Fri, 11 May 2018 02:03:19 +0000
From: "Yeo Jin Kuang Alvin (IA)" <address@hidden>
To: M?ller, Marcus (CEL) <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="utf-8"
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:address@hidden]
Sent: Thursday, 10 May 2018 9:09 PM
To: Yeo Jin Kuang Alvin (IA); address@hidden
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 +0000, 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:address@hidden]
> Sent: Thursday, 10 May 2018 5:34 PM
> To: Yeo Jin Kuang Alvin (IA); address@hidden
> 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 +0000, 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:address@hidden]
> > Sent: Thursday, 10 May 2018 5:06 PM
> > To: Yeo Jin Kuang Alvin (IA); address@hidden
> > 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 +0000, 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
> > > address@hidden
> > >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 4
Date: Fri, 11 May 2018 07:04:18 +0000
From: M?ller, Marcus (CEL) <address@hidden>
To: "address@hidden" <address@hidden>,
"address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
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 +0000, 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:address@hidden]
> Sent: Thursday, 10 May 2018 9:09 PM
> To: Yeo Jin Kuang Alvin (IA); address@hidden
> 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 +0000, 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:address@hidden]
> > Sent: Thursday, 10 May 2018 5:34 PM
> > To: Yeo Jin Kuang Alvin (IA); address@hidden
> > 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 +0000, 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:address@hidden]
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); address@hidden
> > > 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 +0000, 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
> > > > address@hidden
> > > >
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 +0000
From: "Yeo Jin Kuang Alvin (IA)" <address@hidden>
To: M?ller, Marcus (CEL) <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
Message-ID:
<address@hidden>
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 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:address@hidden]
Sent: Friday, 11 May 2018 3:05 PM
To: Yeo Jin Kuang Alvin (IA); address@hidden
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 +0000, 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:address@hidden]
> Sent: Thursday, 10 May 2018 9:09 PM
> To: Yeo Jin Kuang Alvin (IA); address@hidden
> 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 +0000, 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:address@hidden]
> > Sent: Thursday, 10 May 2018 5:34 PM
> > To: Yeo Jin Kuang Alvin (IA); address@hidden
> > 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 +0000, 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:address@hidden]
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); address@hidden
> > > 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 +0000, 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
> > > > address@hidden
> > > >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 6
Date: Fri, 11 May 2018 08:02:25 +0000
From: "Yeo Jin Kuang Alvin (IA)" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Rx to tx GNU Radio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
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 "LLLLLL" 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180511/04afdd8f/attachment.html>
------------------------------
Message: 7
Date: Fri, 11 May 2018 17:13:04 +0200
From: Sumit Kumar <address@hidden>
To: Bastian Bloessl <address@hidden>, GNURadio Discussion List
<address@hidden>
Subject: Re: [Discuss-gnuradio] Issue while adding streaming data :
Integrating MRC in gr-ieee 80211
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 500000, 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
>> address@hidden
>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180511/230dea59/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configuration_sbmrc.png
Type: image/png
Size: 71329 bytes
Desc: not available
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180511/230dea59/attachment.png>
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 187, Issue 13
*************************************************
