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

[Derek Kozel]

Hello Fahad,

That sounds like a great starting place for learning about digital communications and SDR. It is a very broad project description though so it is hard to give specific advice.

If you have not done the GNU Radio Tutorials, that's a great place to start. Also Great Scott Gadget's SDR tutorials are excellent.
https://wiki.gnuradio.org/index.php/Tutorials
https://greatscottgadgets.com/sdr/

If there are specific sensors that you are interested in you should be able to look up what type of modulation they use and whether anyone has written code to work with them or a similar sensor before.

The CGRAN site contains a list of software modules written to use GNU Radio for different applications, one of them may be useful for your project or as reference for you writing your own.
http://www.cgran.org/

Regards,

Derek

On Fri, May 11, 2018 at 10:20 PM, F salem <address@hidden> wrote:

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 <discuss-gnuradio-bounces+fahad-v=address@hidden> on behalf of address@hiddenorg <address@hiddenorg>
Sent: Thursday, May 10, 2018 11:49:46 PM
To: address@hidden
Subject: Discuss-gnuradio Digest, Vol 187, Issue 12

 

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@hiddenorg

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: 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? <address@hidden>
To: Michelle Thompson <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] RTP block / Opus vocoder
Message-ID:
        <CAMc++1X7MuQnfpO7EZzE5mNJC6jkv7UgL+c27g7tV+Mk6=address@hiddencom>
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
<address@hidden> 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 and it puts success more
> within reach. There are other hard parts in this receiver, but LDPC is
> challenging work. Having an open source version is a big step forward.
>
> Aside from ACM, we want to use generic stream encapsulation or GSE, which
> replaces the MPEG transport layer with a protocol that supports, well, you
> guessed it, generic data. This makes the downlink much more useful as a
> multiple access amateur radio system, which is where we're trying to go with
> all this work. Several of us have contributed GSE work that can be found in
> Wireshark and in GNU Radio, so working with GSE streams can be easier.
>
> -Michelle W5NYV
>
> "Potestatem obscuri lateris nescis."
>
>
> On Wed, May 9, 2018 at 9:54 AM, Albin Stig? <address@hidden> wrote:
>>
>> I'm looking specifically to improve the audio streaming of the GQRX
>> program which is based on gnuradio so it needs to be a block. I'll
>> experiment and see if I can come up with something useful.
>>
>> Thanks for all the suggestions though!
>>
>>
>> Albin
>>
>>
>> On Wed, May 9, 2018, 18:30 M?ller, Marcus (CEL) <address@hidden> wrote:
>>>
>>> Well, I think you and Ron basically recommend the same functionality,
>>> but Ron is hesitant to reinvent the wheel:
>>>
>>> For local transport, UDP between your flowgraph and VLC works just
>>> fine. Also fine would be simply using a named pipe (FIFO, as in `man
>>> mkfifo`, if you're on something vaguely resembling UNIX) and a simple
>>> file sink (or source).
>>>
>>> Then, use VLC to receive those UDP packets containing raw samples, and
>>> encode them with Opus, and encapsulate them with RTP. (In the opposite
>>> direction, use VLC to receive an RTP stream, decompress the audio to
>>> raw audio samples, and send them via UDP to your flow graph)
>>>
>>> That would alleviate the need to have all this in a block, and test it
>>> yourself.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-05-09 at 12:30 +0200, Albin Stig? wrote:
>>> > >  RTP is encapsulated in UDP. If you send an RTP stream to the GNU
>>> > > Radio UDP block, you will get an RTP stream.
>>> >
>>> > Exactly. But do you know if there already is a project to handle RTP
>>> > bookkeeping..? Otherwise I will start one. RTP is very application specific
>>> > but I'm looking to implement raw audio and opus. I'll try to make it modular
>>> > so that others can be built on top.
>>> >
>>> > --Albin
>>> >
>>> >
>>> > On Wed, May 9, 2018, 10:38 Ron Economos <address@hidden> wrote:
>>> > > RTP is encapsulated in UDP. If you send an RTP stream to the GNU
>>> > > Radio
>>> > > UDP block, you will get an RTP stream.
>>> > >
>>> > > VLC is just a suggestion. It can send RTP containing Opus.
>>> > >
>>> > > Ron
>>> > >
>>> > > On 05/09/2018 01:10 AM, Albin Stig? wrote:
>>> > > > Well RTP provides important functionality when streaming over the
>>> > > > internet. Especially time stamping and sequence numbering which
>>> > > > allows
>>> > > > to reassemble out of order data (UDP provides no such guarantee)
>>> > > > and
>>> > > > adjustment for clock drift which, among other things, allows you to
>>> > > > keep the receiver buffer smaller for "real time" tuning.
>>> > > >
>>> > > > RTP also provides a "telemetry" channel over RTCP for network
>>> > > > statistics.
>>> > > >
>>> > > > Not sure why you assume I will use VLC?
>>> > > >
>>> > > > Of course if you are just streaming over a LAN raw UDP might be ok
>>> > > > since the risk of out of order packets is essentially zero.
>>> > > >
>>> > > >
>>> > > > --Albin
>>> > > >
>>> > > >
>>> > > > On Wed, May 9, 2018 at 9:35 AM, Ron Economos <address@hidden>
>>> > > > wrote:
>>> > > >> RTP runs over UDP. Why would you need a block? Just let VLC do all
>>> > > >> the dirty
>>> > > >> work.
>>> > > >>
>>> > > >> Ron
>>> > > >>
>>> > > >>
>>> > > >> On 05/08/2018 11:59 PM, Albin Stig? wrote:
>>> > > >>> Hi all,
>>> > > >>>
>>> > > >>> Is there an RTP (real time protocol) streaming block? I know
>>> > > >>> about the
>>> > > >>> UDP block but I want RTP/RTCP.
>>> > > >>>
>>> > > >>> If not I will start writing one... Just don't want to start a new
>>> > > >>> project if there already is one.
>>> > > >>>
>>> > > >>> Also, what happened to Opus in the gr-vocoder? Thinking about
>>> > > >>> writing
>>> > > >>> an opus block as well.
>>> > > >>>
>>> > > >>> The goal is streaming opus encoding audio from gnuradio from
>>> > > >>> remote
>>> > > >>> locations.
>>> > > >>>
>>> > > >>>
>>> > > >>> --Albin
>>> > > >>>
>>> > > >> _______________________________________________
>>> > > >> Discuss-gnuradio mailing list
>>> > > >> address@hidden
>>> > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > > > _______________________________________________
>>> > > > Discuss-gnuradio mailing list
>>> > > > address@hidden
>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>



------------------------------

Message: 2
Date: Thu, 10 May 2018 12:52:48 -0400
From: JONNY LEYIKUN <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Audio File transmission using Qpsk
        modulation
Message-ID:
        <CALfqmmeMgOOE5J3+f=iDmWK-eWhM+U8B6nPxfkzr_TBYKrLJ1A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear All

I try to  transmit Audio File using QPSK modulation and Raised cosine
waveform on GNU radio platform
I can transmit a clear audio file, constellation sink, and amplitude graph.
but when I try to receive using another Laptop the USRP cannot receive the
transmit signal so  I cannot hear the audio file
see the file here and please help me if I made a mistake

1.even The USRP transmitter give red light and also the USRP receiver side
gives the green light  but I don't know why
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/5c71b652/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ashe5.grc
Type: application/gnuradio-grc
Size: 51127 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/5c71b652/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ashe6.grc
Type: application/gnuradio-grc
Size: 86826 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/5c71b652/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sam.png
Type: image/png
Size: 264776 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/5c71b652/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sam2.png
Type: image/png
Size: 348790 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20180510/5c71b652/attachment-0001.png>

------------------------------

Message: 3
Date: Thu, 10 May 2018 13:42:50 -0400
From: Jeff Long <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Audio File transmission using Qpsk
        modulation
Message-ID: <7ce8ec9f-e5f7-cdf2-7aa6-address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

A USRP doesn't work at 15k S/s, and your audio sink probably doesn't
work at 120k. On the TX side you have 2 different blocking sinks (audio
and USRP) which can mess things up. Not sure about the rest of it. It
seems like there might be some filtering and oversampling missing.

On 05/10/2018 12:52 PM, JONNY LEYIKUN wrote:
> Dear All
>
> I try to? transmit Audio File using QPSK modulation and Raised cosine
> waveform on GNU radio platform
> I can transmit a clear audio file, constellation sink, and amplitude
> graph. but when I try to receive using another Laptop the USRP cannot
> receive the transmit signal so? I cannot hear the audio file
> see the file here and please help me if I made a mistake
>
> 1.even The USRP transmitter give red light and also the USRP receiver
> side gives the green light? but I don't know why
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



------------------------------

Message: 4
Date: Thu, 10 May 2018 23:05:03 +0300
From: Adrian Musceac <address@hidden>
To: Michelle Thompson <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] RTP block / Opus vocoder
Message-ID:
        <CA+yUT9-ieKgoMvFnv4UU-vx2j5Wo2Jgh_32BdAkeMSD5rPKgXw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

>
> 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



------------------------------

Message: 5
Date: Thu, 10 May 2018 22:49:40 +0200
From: Albin Stig? <address@hidden>
To: Adrian Musceac <address@hidden>,        GNURadio Discussion List
        <address@hidden>
Subject: Re: [Discuss-gnuradio] RTP block / Opus vocoder
Message-ID:
        <CAMc++1X-SVA17cQyS1LVKmJSCLrwTtp3NbJw9uaddress@hidden>
Content-Type: text/plain; charset="UTF-8"

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



------------------------------

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 12
*************************************************

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