Re: [Discuss-gnuradio] (no module specified) in the block tree

[Tom Early]

Thanks Johnathan. I had the  tags, but didn't have the square 
brackets! (And now I see the hint about the brackets in the first part 
of the tool-tip.)


I guess it would be helpful if the on-line documentation were updated 
(at least in the OOT tutorial) with:


[HOWTO]

and maybe a short sentence that states the importance of the square 
brackets.


On 11/09/2016 06:58 PM, Johnathan Corgan wrote:
On Wed, Nov 9, 2016 at 3:39 PM, Tom Early > wrote:


The tool-tip on this branch says the modules should have a module
name in their GRC Block Descriptions or their Block Tree. I have
been unsuccessful in figuring out how fix this. Can someone point
me in the correct direction?


Just add [NAME] to the XML description for each 
block, right after the name and key entries (change NAME to your 
module name as you want it listed.)


This was something that was added in 3.7.10 to help clean up the 
category tree and to allow OOT modules to have all their blocks 
grouped together separately from the pre-supplied GNU Radio modules.


-Johnathan


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

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Geof Nieboer]

>
> Could you please confirm that indeed in this version the audio block DOES
> NOT BLOCK regardless of the setting


Yes, that's is exactly what I was saying... the blocking option is not
currently implemented but the fix is already in the repo awaiting release.

apologies if the email was not clear: I guess for me getting some sound was
> not considered good enough :-)


When troubleshooting, it is just helpful to get as much information as
possible.  No sound is technically very different than distorted sound, not
a question of good or bad.



On Monday, November 7, 2016, Achilleas Anastasopoulos 
wrote:

> I think I figured out what is going on:
>
> The audio block DOES NOT BLOCK no matter what the value of the "OK to
> block" setting is.
>
> The reason that the 440 Hz tone was heard perfectly was that although
> samples were dropped by the audio device, the remaining samples where
> enough to reconstruct a nice tone.
>
> This unfortunately does not work with other audio signals.
>
> The solution of putting a throttle unfortunately does not work well: it
> produces a very choppy sound on-off all the time.
>
>
> Geof: thanks for all the help. I guess I will have to wait for version
> 3.7.10.2.
>
> Could you please confirm that indeed in this version the audio block DOES
> NOT BLOCK regardless of the setting.
>
> thanks again,
> Achilleas
>
>
>
> On Mon, Nov 7, 2016 at 3:24 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi Geof,
>>
>> apologies if the email was not clear: I guess for me getting some sound
>> was not considered good enough :-)
>>
>>
>> The audio sink IS BLOCKING (OK to block is indeed set to YES)
>> and as I mentioned in the last email, a nice 440Hz tone generated by a
>> signal source is PERFECTLY audible.
>>
>> As I mentioned earlier, I am starting to believe that the "wav file
>> source" is not working properly.
>>
>> Can anyone confirm a working configuration with:
>>
>> Wav File Source --> Audio Sink
>>
>> Thanks
>> Achilleas
>>
>>
>> On Mon, Nov 7, 2016 at 2:49 PM, Geof Nieboer 
>> wrote:
>>
>>> OK, so you are getting *some* sound.  Your first email seemed to
>>> indicate nothing at all was happening.
>>>
>>> In that case, please add a throttle block to your flowgraph, set to the
>>> audio sample rate you desire.
>>>
>>> The audio sink is being overwhelmed with data from the file source and
>>> is not blocking.
>>> When 3.7.10.2 is released the windows audio sink will block when "OK to
>>> block" is set to true.
>>>
>>> Geof
>>>
>>>
>>> On Mon, Nov 7, 2016 at 1:25 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
 oopps I meant "a nice 440 Hz" cosine can be heard nicely.

 Achilleas

 On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <
 anas...@umich.edu> wrote:

> I also would like to report that a nice 440KHz cosine can be heard
> perfectly OK with the default audio sink.
>
> So now I have my doubts about the wav file source block instead of the
> audio sink block
>
> Any ideas?
>
> thanks
> Achilleas
>
> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi Geof,
>>
>> thank you for your suggestions.
>>
>>
>> Here is some more information from my Windows 7 running gnuradio
>> binaries 3.7.10.1
>>
>> 1)
>> When I use a simple wav file source with audio sink and without
>> setting the "Device Name" entry I get the following output:
>>
>> INFO: Audio sink arch: windows
>> gr::pagesize: no info; setting pagesize = 4096
>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>
>> I can hear the sound but it is not coming out at the right speed/etc
>> regardless of what sample rate I choose.
>>
>> So I tried the second method that Geof suggested: entering explicitly
>> the device ID and/or the string representing the device's name.
>>
>> 2)
>> Following Geof's advice I went to the "Device Manager" and the
>> "Sounds, video and game controllers" section and I see a device "High
>> Definition Audio Device". I clink on the "Details" tab and under the
>> Property "device description" i see "High Definition Audio Device", so 
>> this
>> is what I put as the string under the "Device Name" property of the audio
>> sink.
>>
>> The output then is:
>>
>> INFO: Audio sink arch: windows
>> INFO: Warning: waveOut device 'High Definition Audio Device' was not
>> found, defaulting to WAVE_MAPPER
>> gr::pagesize: no info; setting pagesize = 4096
>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>> aOaOaOaOaOaOaOaOaOa
>> aOaOaOaOaOaOaOaOaOaO
>>
>> And the sound is the same as above.
>>
>> So my question is the following:
>>
>> How exactly can I find in the control panel the name of 

Re: [Discuss-gnuradio] (no module specified) in the block tree

[Johnathan Corgan]

On Wed, Nov 9, 2016 at 3:39 PM, Tom Early  wrote:


> The tool-tip on this branch says the modules should have a module name in
> their GRC Block Descriptions or their Block Tree. I have been unsuccessful
> in figuring out how fix this. Can someone point me in the correct direction?
>

Just add [NAME] to the XML description for each block,
right after the name and key entries (change NAME to your module name as
you want it listed.)

This was something that was added in 3.7.10 to help clean up the category
tree and to allow OOT modules to have all their blocks grouped together
separately from the pre-supplied GNU Radio modules.

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

[Discuss-gnuradio] (no module specified) in the block tree

[Tom Early]

I did a clean install of ubuntu 16.10 and then installed gnuradio 3.7.10 
from apt. I also installed my own OOT module. My OOT blocks end up in a 
"(no module specified)" branch.


The tool-tip on this branch says the modules should have a module name 
in their GRC Block Descriptions or their Block Tree. I have been 
unsuccessful in figuring out how fix this. Can someone point me in the 
correct direction?


Thanks!

PS. The blocks in gr-osmosdr also end up in this "(no module specified)" 
branch.



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

Re: [Discuss-gnuradio] Flow control with message ports

[West, Nathan]

I'm not sure I understand. There was once a proof of concept flowgraph
called pmt_smasher that would effectively keep publishing messages and the
queue grows without bounds which was generally considered a low-priority
issue (having no back pressure/flow control on message ports).

You're describing different behavior than I understand the message ports to
have. Is the queue that's overflowing some custom queue in your block that
you dump new messages on to? If so just make that queue grow as more
messages come in.

Nathan

On Tue, Nov 8, 2016 at 7:27 PM, Michael Wentz  wrote:

> Hi,
>
> I've made a block in Python that has one message port out and no other
> ports. What the block does is simple: read from a file, parse data into a
> dict, convert to a PMT, and publish as a message. The port is connected to
> a sync_block that is acting on these messages when it deems fit. My desired
> behavior is for the publisher to fill up the queue as fast as possible and
> block if the queue is full (waiting for room to open up). What I've
> observed is that the queue will instead overflow and messages will be
> dropped. Is there any way to have a blocking call to message_port_pub()?
>
> Looking through the code I do see a method in basic_block to get the
> number of messages in the queue, which I could use to decide to publish a
> message or not - but this isn't brought out in the SWIG interface. Is there
> a reason why? If not, I was thinking about re-defining the SWIG interface
> for basic_block in my OOT with additional methods, but was wondering if
> that would create conflicts/weird issues.
>
> Any other ideas for how to do this would be appreciated. I realize I could
> parse the file in my sync_block, but that's my last resort here.
>
> -Michael
>
> ___
> 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] Change frequency USRP sink/source block on the run

[Dat Luu]

Thank you for the answer, I found the command is freq. I think I will need
to develop a trigger block, so that if it sees a change-frequency message,
it will trigger a command to USRP sink/source.

On Wed, Nov 9, 2016 at 1:55 PM, Osama Riad  wrote:

> I think you should use stream tags.In uhd you can send a command with each
> Burst this command is to be executed by the usrp one command is called
> tx_freq I think.
> You can check this through the internet.
> Br,
> Osama
>
>
> On Wednesday, November 9, 2016, Dat Luu  wrote:
>
>> Hello everyone,
>>
>> I have been working on tx/rx data using USRP B210. I am able to transmit
>> a message and verify the correct content on the receiver side. The next
>> step I want to do is:
>>
>> 1. upon sending a specific message (frequency change), I want to change
>> the frequency of the USRP sink (tx side)
>> 2. upon receiving a specific message (frequency change) I want to change
>> the frequency of the USRP source (rx side)
>>
>> My question is what will be the best way to do it? I know that I will
>> need to pause the flow graph on tx/rx side, and reload the USRP blocks with
>> the new frequency. But, I dont know when the message will arrive; I cannot
>> do a timing triggering on the flow graph.
>>
>> Thank you in advance.
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Change frequency USRP sink/source block on the run

[Osama Riad]

I think you should use stream tags.In uhd you can send a command with each
Burst this command is to be executed by the usrp one command is called
tx_freq I think.
You can check this through the internet.
Br,
Osama

On Wednesday, November 9, 2016, Dat Luu  wrote:

> Hello everyone,
>
> I have been working on tx/rx data using USRP B210. I am able to transmit a
> message and verify the correct content on the receiver side. The next step
> I want to do is:
>
> 1. upon sending a specific message (frequency change), I want to change
> the frequency of the USRP sink (tx side)
> 2. upon receiving a specific message (frequency change) I want to change
> the frequency of the USRP source (rx side)
>
> My question is what will be the best way to do it? I know that I will need
> to pause the flow graph on tx/rx side, and reload the USRP blocks with the
> new frequency. But, I dont know when the message will arrive; I cannot do a
> timing triggering on the flow graph.
>
> Thank you in advance.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Fons Adriaensen]

On Wed, Nov 09, 2016 at 05:12:25PM +, Benny Alexandar wrote:

> So the logic is whenever an audio compressed frame arrives at the audio codec,
> it is timestamped with the current time (Ti) and after uncompressed each audio
> frame blocks (24ms) is timestamped by adding 24ms ( Ti + ( frame_no * 
> frame_duration )),
> where Ti is the start time and frame_no is the decoded uncompressed frames 
> ranges from
> 0 to n and frame_duration is 24ms.

That doesn't make much sense, for at least two reasons.

First, the time when a compressed frame arrives at the codec has no
meaning. At that point the signal is just data stored in memory, not
a physical one. The only time that would make sense would be the
timestamp at the A/D converter of the RF sample that in some way
corresponds to the start of the compressed frame. And even that
assumes that there is simple linear relation between the RF samples
and audio samples.

Now that doesn't mean that such timestamps can't be used. But you
can't use them in the naive way you describe.

Second, if you read the timer once and then just add the nominal 24ms
for all following timestamps, you don't get any information about the
data rate at all. Simple reason is only the first timestamp contains
any new information, all the others are redundant because they can be
computed from the first. But maybe I misunderstand that part of your
scheme.

> ... After some N seconds this accumulated value is averaged by dividing
> by N sec. So I get the drift in sampling rate in terms of samples.  
> Then all I need to do is slow down or speed up the sampling rate based
> on which side the drift is.

You'd need to do this continuously. A single correction can't be perfectly
accurate, and any remaining error is integrated w.r.t. time and will grow
without bound. And you can't assume the sample rate ratio is fixed, it
will drift as well.
 
> Is it possible to change the sample rate of ALSA by drift amount ?

On a few professional (and very expensive) audio cards allow continuous
control of the sample rate, e.g. RME's MADI interfaces.


Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)


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

[Discuss-gnuradio] Change frequency USRP sink/source block on the run

[Dat Luu]

Hello everyone,

I have been working on tx/rx data using USRP B210. I am able to transmit a
message and verify the correct content on the receiver side. The next step
I want to do is:

1. upon sending a specific message (frequency change), I want to change the
frequency of the USRP sink (tx side)
2. upon receiving a specific message (frequency change) I want to change
the frequency of the USRP source (rx side)

My question is what will be the best way to do it? I know that I will need
to pause the flow graph on tx/rx side, and reload the USRP blocks with the
new frequency. But, I dont know when the message will arrive; I cannot do a
timing triggering on the flow graph.

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

[Discuss-gnuradio] New Public Course Offerings for SDR and GNU Radio

[Johnathan Corgan]

New Public Course Offerings for SDR and GNU Radio

Based on feedback and demand from the GNU Radio conference held this year
in September in Boulder, Colorado, Corgan Labs is reintroducing new public
courses that are designed for individuals and small teams. These courses
are built upon the experience Corgan Labs has accumulated as we’ve trained
hundreds of users how to efficiently use GNU Radio and SDR platforms.

We will be conducting these hands-on courses once per quarter on each of
the United States east and west coasts, with the following two as our first:

   - US East Coast - Columbia, MD, 7th December 201
   6
   
   - US West Coast - Santa Clara, CA, 27th January 201
   7
   

These courses provide a brief introduction to GNU Radio, the USRP hardware
platform, and general SDR concepts.  After this introduction, attendees
will be immersed in hands-on exercises that accelerate learning with a
building-block approach. By the end of the course, users with no previous
experience will be able to build simple analog and digital applications.
Each attendee will receive a *USRP B200*
 to be used for the
hands-on exercises, which they keep after the course.



Corgan Labs also offers customized, on-site courses for teams.  For more
information or to register for a course, please visit the *Corgan Labs
Training Services Page* .


Best Regards,

Johnathan Corgan

+1 408 463 6614

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

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons/Marc,


For Digital radio the audio data is received in compressed format. Using audio 
codec it is uncompressed. The uncompressed audio will be sent to audio sink 
with a block size of 24ms. Before sending  these audio blocks are timestamped 
using PC microsecond timer. To access the clock value of timer, I do a "direct" 
read of memory mapped hardware register (TSC) to avoid OS delays and jitter 
etc.  So the logic is whenever an audio compressed frame arrives at the audio 
codec, it is timestamped with the current time (Ti) and after uncompressed each 
audio frame blocks (24ms) is timestamped by adding 24ms ( Ti +   ( frame_no * 
frame_duration ) ), where Ti is the start time and frame_no is the decoded 
uncompressed frames ranges from 0 to n and frame_duration is 24ms.


When these audio frames reaches the audio sink, it reads the current time (Tc) 
from   same clock (TSC) and measure the elapsed time ,   diff  =( ( Tk + 
delay )  -  Tc ),   where  Tk  = ( Ti +   ( frame_no * frame_duration ) ) 
and delay is 2 frame delay (48ms) . Every time the audio sink call back happens 
   (aftre streaming an aduio frame(24ms) interrupt happens) , the diff is 
calculated and  accumulated. Ideally if the audio sink is sending at the 
"nominal sample rate" the delay should be constant.  After some N seconds this 
accumulated value is averaged by dividing by N sec. So I get the drift in 
sampling rate in terms of samples.  Then all I need to do is slow down or speed 
up the sampling rate based on which side the drift is.



Is it possible to change the sample rate of ALSA by drift amount ?




-ben


From: Fons Adriaensen 
Sent: Monday, November 7, 2016 1:34:07 AM
To: Marcus Müller
Cc: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 07:32:47PM +0100, Marcus Müller wrote:

> under the hood, sinks are sync_blocks.

Which is what surprises me. Sinks have no outputs, and
sources have no inputs, so the whole 'sync' concept seems
out of place...

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

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

Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations

[Benny Alexandar]

Hi Felix,


Any update on DRM+, I'm planning to use DRM+ transmission using gr-drm. Is it 
fully functional and tested ?  DREAM doesn't support DRM+ reception. Any open 
source receiver available to receive DRM+ ?


-ben


From: Felix Wunsch 
Sent: Monday, November 7, 2016 5:44:16 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations


Hi Ben,


even though the stable version should work, please use the master branch, which 
contains all the recent changes. As you can see in the commit log, we moved our 
activity towards the kit-cel fork.


Regarding the DRM receiver: Actually, a student of mine wrote some code during 
his Master's thesis this year.We did not yet merge it into gr-drm, you can find 
the code here: https://github.com/florianbrauchle/gr-rxdrm. The code probably 
won't run in real-time, though. As the audio decoder is still missing, we never 
had to look into issues like clock drift.


- Felix



On 11/05/2016 05:31 AM, Benny Alexandar wrote:

Hi Felix,




I'm happy to hear that gr-drm is being used! I hope you are using the newest 
version, I did quite some refactoring some time ago.,

I pulled the git stable version from this link,
https://github.com/kit-cel/gr-drm/tree/stable

Which is the latest version of gr-drm ?  I see another git version
https://github.com/fewu/gnuradio_drm

which one to use to get the latest changes ? Please send me the link. Do you 
have anyworking version of DRM receiver available on git ?

I'm using USRP N210 for transmission. Have you looked at receiver audio 
tracking to make sure the DRM receiver is compensating the drift in audio 
sample rates, to prevent overflow/uderrun etc ?

-ben



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


Cheers
Felix

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRCon16 Talk Recordings

[Ben Hilburn]

Hey all -

The second half of the GRCon16 recordings are now posted!

https://www.youtube.com/channel/UCceoapZVEDCQ4s8y16M7Fng

If you're interested, a playlist of all the recorded talks from the
conference is here - 51 in total!

https://www.youtube.com/playlist?list=PLbBQHMnVMR43iHZRQ2Uw_UVQb65rOEnow

Enjoy =)

Cheers,
Ben

On Fri, Oct 28, 2016 at 1:58 PM, Ben Hilburn  wrote:

> Hi all -
>
> I'm really excited to announce that the first batch of recorded talks from
> GRCon16 are now live. You can find them on the GNU Radio YouTube channel:
>
> https://www.youtube.com/channel/UCceoapZVEDCQ4s8y16M7Fng
>
> All of the talks from Monday and Tuesday have been posted, and about half
> of the talks from Wednesday are up. We'll post the rest as soon as we
> receive them from the videography team.
>
> Don't forget that the slides are available here:
> http://gnuradio.org/grcon-2016/talks/
>
> And the technical proceedings are available here:
> pubs.gnuradio.org
>
> Thanks, and let me know if you have any questions!
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Digital Video Transmission

[Ron Economos]

Digital video transmission for world wide standards is fully supported 
in GNU Radio. The following standards have been implemented:


ATSC
DVB-S
DVB-S2
DVB-T
DVB-T2
ITU-T J.83B (CATV 64QAM)

Take a look at the examples directory in gr-dtv. In the README files, 
there are links to test Transport Streams.


https://github.com/gnuradio/gnuradio/tree/master/gr-dtv/examples

For ATSC and DVB-T, there are receiver implementations that will run on 
USRP's (although a high performance CPU is required). For the other 
standards, commercial receivers can be used.


Here's a video showing GNU Radio sending DVB-S2 with LimeSDR.

https://www.youtube.com/watch?v=Ed7iy0gVywo

Ron

On 11/09/2016 03:56 AM, David Halls wrote:


Hi guys,


It's been a long time!


I am trying to send some digital video over USRPs, we are using this 
to show the quality of some transmission technique we are working on, 
can someone please point me towards a good example or thread?



We just want to transmit a prerecorded .TS file, and ideally play at 
the receiver side, e.g. using VLC.



Thanks for any pointers!!


David




NOTE: The information in this email and any attachments may be 
confidential and/or legally privileged. This message may be read, 
copied and used only by the intended recipient. If you are not the 
intended recipient, please destroy this message, delete any copies 
held on your system and notify the sender immediately.


Toshiba Research Europe Limited, registered in England and Wales 
(2519556). Registered Office 208 Cambridge Science Park, Milton Road, 
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl





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

[Discuss-gnuradio] Digital Video Transmission

[David Halls]

Hi guys,


It's been a long time!


I am trying to send some digital video over USRPs, we are using this to show 
the quality of some transmission technique we are working on, can someone 
please point me towards a good example or thread?


We just want to transmit a prerecorded .TS file, and ideally play at the 
receiver side, e.g. using VLC.


Thanks for any pointers!!


David



NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio