Re: [Discuss-gnuradio] Scheduler enhancement?

[Sylvain Munaut]

Hi,

> It's a little bit off-topic but if someone will change the gr-osmosdr,
> it would be great to have other stream tags that we are used to see at
> the output UHD source. For example if the source prints on the output
> that there is some problem with transmission it would be great to add a
> stream tag at that moment. In Multi-RTL
> (https://github.com/ptrkrysik/multi-rtl/) currently any such event means
> that synchronization of channels is lost until user manually calls
> resynchronization. Because there is no way to detect samples loss
> resynchronization can't be called automatically.

rtl-sdr can't detect sample loss ...

With USRP, the hw reports overflows to the host, but the rtl-sdr has
no such thing, it will drop sample silently if its internal buffers
overflow.


Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] Scheduler enhancement?

[Piotr Krysik]

W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze:
> Hi,
>
>> It's a little bit off-topic but if someone will change the gr-osmosdr,
>> it would be great to have other stream tags that we are used to see at
>> the output UHD source. For example if the source prints on the output
>> that there is some problem with transmission it would be great to add a
>> stream tag at that moment. In Multi-RTL
>> (https://github.com/ptrkrysik/multi-rtl/) currently any such event means
>> that synchronization of channels is lost until user manually calls
>> resynchronization. Because there is no way to detect samples loss
>> resynchronization can't be called automatically.
> rtl-sdr can't detect sample loss ...
>
> With USRP, the hw reports overflows to the host, but the rtl-sdr has
> no such thing, it will drop sample silently if its internal buffers
> overflow.
>
Here is some form of detection of overflows:

http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305


What you are saying means it doesn't detect 100% of overflows?


Best Regards,

Piotr Krysik


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

Re: [Discuss-gnuradio] Scheduler enhancement?

[Marcus Müller]

Hi Piotr,

As far as I grok the gr-osmosdr rtl_souce, this is an overflow
indication purely based on the fact that in the rtl_source itself, the
number of the last used buffer is compared with the maximum number of
buffers that should be – and if that happens, that is an indication that
the software side noticed things ran over how much buffer there's
available.

That's pretty different from the USRP approach: It is indeed a kind of
overflow indication, but it gives no chance whatsoever to recover, since
the rtl dongle isn't aware of it, and also has no means to actually time
stamp data. If things get really bad, and USB buffers get lost before
they even reach userland, librtl can't even notice, I think (the USB
bulk transfer packets are pretty much samples only, as far as I read
librtlsdr's librtlsdr.c in combination with rtl_source_c.cc), so there's
no timing/"original sample count" info available. USRPs actually keep
track of ACKs coming from the PC.

Best regards,
Marcus

On 22.07.2016 10:45, Piotr Krysik wrote:
> W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze:
>> Hi,
>>
>>> It's a little bit off-topic but if someone will change the gr-osmosdr,
>>> it would be great to have other stream tags that we are used to see at
>>> the output UHD source. For example if the source prints on the output
>>> that there is some problem with transmission it would be great to add a
>>> stream tag at that moment. In Multi-RTL
>>> (https://github.com/ptrkrysik/multi-rtl/) currently any such event means
>>> that synchronization of channels is lost until user manually calls
>>> resynchronization. Because there is no way to detect samples loss
>>> resynchronization can't be called automatically.
>> rtl-sdr can't detect sample loss ...
>>
>> With USRP, the hw reports overflows to the host, but the rtl-sdr has
>> no such thing, it will drop sample silently if its internal buffers
>> overflow.
>>
> Here is some form of detection of overflows:
>
> http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305
>
>
> What you are saying means it doesn't detect 100% of overflows?
>
>
> Best Regards,
>
> Piotr Krysik
>
>
> ___
> 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] Scheduler enhancement?

[Piotr Krysik]

Hi Marcus,

Ok, it is therefore indication of problem with an overflow happening in
rtl-sdr source block on the side of PC (there is no more free buffers to
store incoming sample). I'm aware that with RTL-SDR's it is not possible
(as far as anyone knows) to read how many samples were lost. But any
communication error (on side of the device or on side of a PC) will
cause synchronization loss in multiple RTL-SDR's that were synchronized
beforehand. Knowing at least some communication errors will enable
recovering from them - that means calling a function that will make
RTL-SDR receivers to be synchronized again.

Of course information that something went wrong with transmission on the
side of the device would be much more valuable (overflows on the side of
PC can be tackled by increasing number of buffers and speeding up
processing).

Best Regards,
Piotr Krysik

W dniu 22.07.2016 o 12:01, Marcus Müller pisze:
> Hi Piotr,
>
> As far as I grok the gr-osmosdr rtl_souce, this is an overflow
> indication purely based on the fact that in the rtl_source itself, the
> number of the last used buffer is compared with the maximum number of
> buffers that should be – and if that happens, that is an indication that
> the software side noticed things ran over how much buffer there's
> available.
>
> That's pretty different from the USRP approach: It is indeed a kind of
> overflow indication, but it gives no chance whatsoever to recover, since
> the rtl dongle isn't aware of it, and also has no means to actually time
> stamp data. If things get really bad, and USB buffers get lost before
> they even reach userland, librtl can't even notice, I think (the USB
> bulk transfer packets are pretty much samples only, as far as I read
> librtlsdr's librtlsdr.c in combination with rtl_source_c.cc), so there's
> no timing/"original sample count" info available. USRPs actually keep
> track of ACKs coming from the PC.
>
> Best regards,
> Marcus
>
> On 22.07.2016 10:45, Piotr Krysik wrote:
>> W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze:
>>> Hi,
>>>
 It's a little bit off-topic but if someone will change the gr-osmosdr,
 it would be great to have other stream tags that we are used to see at
 the output UHD source. For example if the source prints on the output
 that there is some problem with transmission it would be great to add a
 stream tag at that moment. In Multi-RTL
 (https://github.com/ptrkrysik/multi-rtl/) currently any such event means
 that synchronization of channels is lost until user manually calls
 resynchronization. Because there is no way to detect samples loss
 resynchronization can't be called automatically.
>>> rtl-sdr can't detect sample loss ...
>>>
>>> With USRP, the hw reports overflows to the host, but the rtl-sdr has
>>> no such thing, it will drop sample silently if its internal buffers
>>> overflow.
>>>
>> Here is some form of detection of overflows:
>>
>> http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305
>>
>>
>> What you are saying means it doesn't detect 100% of overflows?
>>
>>
>> Best Regards,
>>
>> Piotr Krysik
>>


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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi list,

in week 9 of my GSoC I finally managed to implement a working OFDM
parameter estimation block. Read here about it:
https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/

Next up is a frequency and timing synchronization block.

Cheers
Sebastian

2016-07-18 9:57 GMT+02:00 Sebastian Müller :

> Hi Martin,
>
> I have no problem with keeping the 'old' algo in the toolbox. But still
> I'm not sure if it is usable in real-world scenarios with sampling offsets.
> Maybe someone can improve it if interested.
>
> Cheers, Sebastian
>
> 2016-07-15 19:22 GMT+02:00 Martin Braun :
>
>> To clarify, if Koslowski's algorithm (since you already coined the
>> term...) is *as* good as your original one, but also faster, you should
>> not have duplicates. But if you did all the work to create software that
>> actually outperforms the fast algorithm in some other aspect, there's no
>> harm in keeping it around.
>>
>> Cheers,
>> M
>>
>> On 07/15/2016 10:20 AM, Martin Braun wrote:
>> > Sebastian,
>> >
>> > thanks for sharing, and your awesome work! I would suggest if you have
>> > an algorithm with great detection characteristics, you should keep it.
>> > If you want another suboptimal but fast one, create a second block (or
>> > whatever it is). The first algorithm did cost you time, and its superior
>> > detection performance might be interesting to other people.
>> >
>> > Cheers,
>> > Martin
>> >
>> > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>> >> Hi list,
>> >>
>> >> week 8 of GSoC is over and the latest news on gr-inspector are online:
>> >>
>> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
>> >>
>> >> This week was a bit disappointing because the algorithm for the OFDM
>> >> estimation, which did show nice estimation results, and which I dealt
>> >> with 2 weeks now, had to be replaced because of performance issues. Now
>> >> I'll try a more straight-forward algorithm and hope to get started with
>> >> synchronization in two weeks.
>> >>
>> >> Cheers,
>> >> Sebastian
>> >>
>> >> Sebastian Müller mailto:gse...@gmail.com>> schrieb
>> am
>> >> Fr., 8. Juli 2016 um 13:48 Uhr:
>> >>
>> >> Hi all,
>> >>
>> >> week 7 of GSoC is over and I have written a blog post about what
>> >> I've been up to:
>> >>
>> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>> >>
>> >> I started implementing an OFDM parameter estimation block in
>> python.
>> >> Also, I did some performance tests, which look quite good. Next, I
>> >> will implement this algorithm in C++. Stay tuned!
>> >>
>> >> Cheers,
>> >> Sebastian
>> >>
>> >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>> >>> Hi all,
>> >>>
>> >>> this week's GSoC blog post is ready! Check it out here:
>> >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>> >>>
>> >>> I have finished the GUI so far and improved the Signal Separator.
>> >>> In the next time I will start with an OFDM parameter estimation,
>> >>> so stay tuned.
>> >>>
>> >>> Cheers,
>> >>> Sebastian
>> >>>
>> >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller > >>> >:
>> >>>
>> >>> Hi Ben,
>> >>>
>> >>> thanks for your interest. The manual signal selection is like
>> >>> the demod function in gqrx. You can move and resize an overlay
>> >>> that will determine the signal information that gets passed
>> >>> downstream. I have not dealt with AMC for now, but based on my
>> >>> own experience with manual modulation recognition I don't see
>> >>> a problem when not exactly hitting the signal edges. If your
>> >>> concern is too narrow selection, there is an oversampling
>> >>> factor parameter in the Signal Separator block, that will
>> >>> allow filtering wider than actually from the GUI specified, to
>> >>> compensate the naturally underestimated bandwidth when using
>> >>> energy detection. Also, the GUI now supports zooming so a user
>> >>> can work really precise if needed :)
>> >>>
>> >>> Thanks again for the feedback!
>> >>> Cheers,
>> >>> Sebastian
>> >>>
>> >>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn
>> >>> <bhilb...@gnuradio.org
>> >>> >:
>> >>>
>> >>> Hi Sebastian -
>> >>>
>> >>> Thanks for the great update!
>> >>>
>> >>> I'm curious how the "manual selection with the mouse" will
>> >>> work? For some of the back-end processing that is going
>> >>> on, like Chris's AMC work, not selecting all of the bins
>> >>> of the signal seems like it could seriously impact the
>> >>> success of those functions. If the the FFT is, for
>> >>> example, 1024 bins, it seems like it may be hard for a
>> >>> user to accurately select the bins that

Re: [Discuss-gnuradio] About closing flowgraph automatically

[Martin Braun]

Simone,

a file source *will* terminate the flow graph once its read the file
(unless you specify 'repeat').

M

On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote:
> Goodmorning,
> I would like to Know some methods to Close flowgraph automatically when
> it has finished. Some example, stop when USRP has no more samples to
> transmits, or a file source has read until EOF.
> The Run of completion option works when (for instance) you have a file
> source connected to other non-PMT Message block and a sink (USRP or null
> sink...). However, when the file source output is converted to pmt
> Message, then the flowgraph does not stop anymore when rhe file source
> has finished. Probably because the PMT Message block continue to waits
> for messages. In this case, How I can stop automatically the flowgraph?
> I would like to Close the flowgraph when EOF or USRP has no more sample
> to transmit, for example, in a situation like the following:
> 
> FILE SOURCE -> STREAM TO PMT MESSAGE -> PROCESSING BLOCKS -> PMT MESSAGE
> TO FILE SOURCE -> USRP SINK
> 
> Thank for yours support and for the great utility of the list 😊
> simone
> 
> ___
> 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] Understanding tags_demo.cc example in gr-uhd

[Martin Braun]

A basic principle of GNU Radio flow graphs is the concept of
backpressure. Let's ignore the bursts for a second, and assume you set
your USRP to consume at a rate of 200 ksps (so, a very low value). At
its input, you have a signal source, and no other throttling mechanism
(which is the right thing to do).

Can you computer generate signal source samples at more than 200 ksps?
Well yes, easily and happily! So how doesn't it overwhelm the USRP? The
reason is, you can't actually send() data to the USRP if its input
buffer is already full. UHD simply won't let you do that.

When that happens, GNU Radio will eventually call the UHD sink's work()
function, and the work() function will return 0, saying "I can't handle
this data right now". GNU Radio knows now that it can't call work() on
the signal source, either, because if it would, that would generate data
with no buffer to put it. No samples are lost.
Maybe next time we call work() on the USRP sink again, the USRP has
created some space, and work() can consume. And so the flow continues.

Now, let's add the timed bursts again. In principle, nothing changes
w.r.t. the unbursty case. The only difference is when the USRP will
empty its own input buffer. If you transmit a signal that is tagged 10
seconds into the future, GNU Radio might try and call work() for 10
seconds without anything budging, but that's fine.

Hope this was clear!

Cheers,
M

On 07/21/2016 05:04 PM, Lakshay Narula wrote:
> Hello all,
> 
> I have been trying to understand the mechanics of stream tags and USRP.
> To this end, I am reading through the tags_demo.cc example found in
> gr-uhd/examples/c++.
> 
> The example provides two options for burst control: using SOB/EOB tags,
> and using tagged stream blocks. For clarity, let us assume that we
> choose to use SOB/EOB tags, that is, we pass an empty tsb_tag_name. This
> choice does not affect my question that follows later.
> 
> From the code it looks like the flowgraph does not stay idle at any
> point. It takes a bunch of samples, and stamps the SOB tag along with a
> time tag on the first sample. The flowgraph keeps running till the burst
> is on. Once the number of samples in a burst are exhausted, it stamps an
> EOB tag. At this point, it immediately starts a new burst with an SOB
> tag, but with a delayed time tag to accommodate for the idle period. In
> contrast, the USRP transmission must stay off during the idle period.
> 
> In this flowgraph the sample rate is clearly controlled by the USRP sink
> hardware. If the flowgraph produces samples at this rate and does not
> stay idle, then will it not eventually overwhelm the USRP sink? Assuming
> default values of sample rate (1e6) and burst and idle time (0.1 and
> 0.05, respectively), the flowgraph would produce 50,000 samples in each
> idle period. These samples will keep on accumulating endlessly.
> 
> I believe I am missing something here, because this example has been
> clearly reported to work just fine. Any comments?
> 
> Thanks,
> Lakshay.
> 
> 
> ___
> 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] Problem/bug with cmake config for gr-uhd using pybombs.

[Martin Braun]

Eugene,

I've seen something similar, and I'm not even sure it's a PyBOMBS
problem. I think it's more likely an issue with gr-uhd's (or even GNU
Radio's) CMake.

Not sure what the fix is though. I'll post an issue.

Cheers,
M

On 07/18/2016 01:31 PM, Eugene Grayver wrote:
> There's a subtle problem with the FindUHD.cmake as used from PyBombs.
>  If the system has UHD installed in the 'standard' location
> (/usr/include/uhd, etc), this path will be used *instead* of the path
> set by pybombs prefix.  I.e. if I install gr into /etc/gr1: uhd is
> installed in /etc/gr1/src/uhd, but gr-uhd will use /usr/.../uhd.  This
> leads to very difficult to diagnose problems if the UHD versions are
> slightly different.  If they are very different, the build simply fails
> due to undefined symbols.
> 
> 
> I am not familiar enough with the pybombs environment to suggest a fix.
>  Perhaps pybombs should set the UHD_DIR env variable?
> 
> 
> 
> 
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
> 
> 
> 
> ___
> 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] Understanding tags_demo.cc example in gr-uhd

[Lakshay Narula]

Thanks Martin, that was exactly what I was looking for.

Would the following statement be correct: the GNU Radio flowgraph always
produces samples as fast as the CPU can (irrespective of the set sample
rate or throttle), and stops producing whenever the USRP sink buffer is
full.

Also, does the throttle block work in a similar fashion?

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

Re: [Discuss-gnuradio] Understanding tags_demo.cc example in gr-uhd

[Martin Braun]

On 07/22/2016 04:38 PM, Lakshay Narula wrote:
> Thanks Martin, that was exactly what I was looking for. 
> 
> Would the following statement be correct: the GNU Radio flowgraph always
> produces samples as fast as the CPU can (irrespective of the set sample
> rate or throttle), and stops producing whenever the USRP sink buffer is
> full.

Yup.

> Also, does the throttle block work in a similar fashion?

That block blocks work() such that the average rate through it is what
it's set to to.

M
> 
> Thanks again,
> Lakshay.


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

Re: [Discuss-gnuradio] About closing flowgraph automatically

[Piotr Krysik]

Hi Simone and all,

Can you provide your GRC flow-graph? I think that source of the problem
might be somewhere in this part
"PMT MESSAGE TO FILE SOURCE" as there is message to samples stream
conversion involved here. But it's not clear for me what it actually is
as you described it.

I have problems with automatic closing of a flow-graph that uses a block
that converts messages to samples. In my case it is PDU to Tagged Stream
block that caused problems with automatic exiting of the flow-graph.

The constant problems with exiting of flow-graphs lead me to think if
these problems can be solved once for all with some change in gnuradio's
internals.

Maybe it can be some "exit" tag that would be propagated to all blocks
in a flowgraph. This tag would be processed by all blocks and would
cause them to be marked as ready for the program exit. Blocks that have
stream inputs and message outputs would convert the tag to an "exit"
message, which would be propagated through the outputs.
Blocks with message inputs ans stream outputs would convert "exit"
message to an "exit" tag. When all blocks would be marked as ready for
closing the program would end.

In this concept there is problem how to propagate the information to
blocks upstream, that might not have information about ending of a
flow-graph. So the method I described might be used as an addition to
current method of ending flowgraphs.

What do you think?

Best Regards,
Piotr Krysik

W dniu 22.07.2016 o 18:40, Martin Braun pisze:
> Simone,
>
> a file source *will* terminate the flow graph once its read the file
> (unless you specify 'repeat').
>
> M
>
> On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote:
>> Goodmorning,
>> I would like to Know some methods to Close flowgraph automatically when
>> it has finished. Some example, stop when USRP has no more samples to
>> transmits, or a file source has read until EOF.
>> The Run of completion option works when (for instance) you have a file
>> source connected to other non-PMT Message block and a sink (USRP or null
>> sink...). However, when the file source output is converted to pmt
>> Message, then the flowgraph does not stop anymore when rhe file source
>> has finished. Probably because the PMT Message block continue to waits
>> for messages. In this case, How I can stop automatically the flowgraph?
>> I would like to Close the flowgraph when EOF or USRP has no more sample
>> to transmit, for example, in a situation like the following:
>>
>> FILE SOURCE -> STREAM TO PMT MESSAGE -> PROCESSING BLOCKS -> PMT MESSAGE
>> TO FILE SOURCE -> USRP SINK
>>
>> Thank for yours support and for the great utility of the list 😊
>> simone
>>

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