Any amateur radio in the list?

[Vincenzo Mone]

Please I would like to know if there is any amateur radio that works

Satellite and especially the BY70-2 one.

 

73's de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *

  **   GSM  +39 328 7110193  **

  * SMS  +39 328 7110193*

  *

 

Re: is there anybody who can search at the GR manual?

[Derek Kozel]

Hi Ali and Fabian,

Someone reported this a few days ago, there were some infrastructure
changes during GRCon a week ago and this change in headers must have
happened as a result of that. It's being looked into and we'll get that
removed/fixed. It might take a few more days.

Regards,
Derek

On 03/10/2020 12:11, Fabian Schwartau wrote:
> Hi,
> I have the same problem. Seems like this is a more or less valid
> security thing. The embedded page needs to set the X-Frame-Options to
> SAMEORIGIN in the HTTP header:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
> For some reason the server is sending this setting twice:
> x-frame-options: SAMEORIGIN
> x-frame-options: DENY
>
> And firefox obiously takes the last one, which is not good. So, someone
> who is running the website should re-configure the web-server and remove
> the second x-frame-options, I guess. At least for this particular file,
> I guess you can do that with an additional .htaccess or similar file.
>
> Best regards,
> Fabian
>
> Am 03.10.20 um 12:57 schrieb Ali G. Dezfuli:
>> Hi all,
>> I still have a problem with the GR manual
>> (https://www.gnuradio.org/doc/doxygen/)
>> In firefox I receive this error:
>>
>> Firefox Can’t Open This Page
>>
>> /*To protect your security, www.gnuradio.org 
>> will not
>> */
>> /*allow Firefox to display the page if another site has
>> */
>> /*embedded it. To see this page, you need to open it in a
>> */
>> /*new window.
>>
>> Learn more…*/
>> /*
>> */
>> is there anybody who is ok with searching at the manual?
>> Thanks
>> AGD
>> **/**/
>

Re: How to plot BER vs SNR in GNU Radio

[farhan pishe]

Barry, thank you so much for your time, but unfortunately, it wasn't
helpful for me and still, I am seeking a way to plot the BER vs SNR. I
don't know what is wrong with GNU Radio! Even it doesn't have complete
documentation so that I can understand how to do things like this. I hope
that someone guides me in a clear way. I want to plot a BER vs SNR for the
OFDM simulation which already exists as one of the examples of GNU Radio,
but it gives me constant line.

On Tue, Sep 29, 2020 at 3:50 PM Barry Duggan  wrote:

> Farhan,
>
> I don't know much about BER curves, but this example may help you some:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/examples/ber_curve_gen.grc
>
> Also search the archives of this newsletter. IIRC, there is a discussion
> about the bus inputs.
>
> Remember to CC discuss-gnuradio in your reply. I forgot on the first
> time for this!
>
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>
> On Tue, 29 Sep 2020 00:00:51 +0330, farhan pishe wrote:
>
> Hello,
>
> I am trying to plot the BER vs Es/N0 using QT Bercurve Sink which has 16
> inputs. But the result is always a constant line and I don't know the
> reason and it is blowing my mind. Also, I don't know whether there is an
> alternative way to plot BER vs SNR. I would really appreciate it if
> anyone could help me in this regard. I just want to plot a simple bit
> error rate curve.
>
> Regards,
> Farhan
>

Re: is there anybody who can search at the GR manual?

[Ron Economos]

Just scroll down in that warning window and click on "Open Site in New 
Window".


Ron

On 10/3/20 03:57, Ali G. Dezfuli wrote:

Hi all,
I still have a problem with the GR manual 
(https://www.gnuradio.org/doc/doxygen/)

In firefox I receive this error:

Firefox Can’t Open This Page

/*To protect your security, www.gnuradio.org  
will not

*/
/*allow Firefox to display the page if another site has
*/
/*embedded it. To see this page, you need to open it in a
*/
/*new window.

Learn more…*/
/*
*/
is there anybody who is ok with searching at the manual?
Thanks
AGD

Re: is there anybody who can search at the GR manual?

[Fabian Schwartau]

Hi,
I have the same problem. Seems like this is a more or less valid
security thing. The embedded page needs to set the X-Frame-Options to
SAMEORIGIN in the HTTP header:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
For some reason the server is sending this setting twice:
x-frame-options: SAMEORIGIN
x-frame-options: DENY

And firefox obiously takes the last one, which is not good. So, someone
who is running the website should re-configure the web-server and remove
the second x-frame-options, I guess. At least for this particular file,
I guess you can do that with an additional .htaccess or similar file.

Best regards,
Fabian

Am 03.10.20 um 12:57 schrieb Ali G. Dezfuli:
> Hi all,
> I still have a problem with the GR manual
> (https://www.gnuradio.org/doc/doxygen/)
> In firefox I receive this error:
> 
> Firefox Can’t Open This Page
> 
> /*To protect your security, www.gnuradio.org 
> will not
> */
> /*allow Firefox to display the page if another site has
> */
> /*embedded it. To see this page, you need to open it in a
> */
> /*new window.
> 
> Learn more…*/
> /*
> */
> is there anybody who is ok with searching at the manual?
> Thanks
> AGD
> **/**/

is there anybody who can search at the GR manual?

[Ali G. Dezfuli]

Hi all,
I still have a problem with the GR manual (
https://www.gnuradio.org/doc/doxygen/)
In firefox I receive this error:

Firefox Can’t Open This Page


*To protect your security, www.gnuradio.org  will
not *

*allow Firefox to display the page if another site has *

*embedded it. To see this page, you need to open it in a *


*new window.Learn more…*

is there anybody who is ok with searching at the manual?
Thanks
AGD

Re: Problem with porting an OOT module to 3.8 (sampling speed)

[Marcus Müller]

Aha! That's examctl the "*very* specific" case Iwas referring to earlier.

This is going to be pretty specific to how you interact with libusb, but 
in essence:
The 3.7 / 3.8 paradigm is still to block in work() until you have data, 
as a source. That's architectually not pretty, but it is what it is.


I think somewhere in the later 3.7 and definitely for 3.8 we introduced 
a delay before work() gets re-called in case it returns 0, as that would 
lead to a CPU core just spinning on that block (although it actually has 
nothing to do, which means that the less data your block produces, the 
more persistently it grabs CPU).


You can remedy that:

* for the current scheduling, block in work, with a timeout, instead of 
using the non-blocking libusb receive methods. I.e. use the synchronous 
libusb API. (not blocking but then relying on your work() being called 
in a spinlock manner so that no overflows happen is not a sensible use 
of the async IO API in libusb.)
* Use libusb's async io[0] with a callback: libusb_fill_bulk_transfer(), 
and set the callback function to a function that sends a 
`pmt::cons(pmt::intern("done"), pmt::mp(false))`¹ to your block's 
"system" message port. That should "cancel" the 250ms wait between 
work() calls (if one is currently going on). This will require an 
addition copy from a buffer you've filled, but that might be less costly 
than one would fear (data is hot anyways)
* what I'll call the sleeper/waker pattern: keep your block as it is. 
follow [1] to get a file descriptor to your libusb handle. Have a thread 
that uses `epoll`, `poll` or `select`² to passively monitor the USB 
endpoint (without using CPU for that). Then, when new data arrived, 
you'd wake up your block using the same "system" port method above. In 
the block's work function, you'd then use the non-blocking libusb 
functions to get the data (which now is there - otherwise the callback 
wouldn't have been called).


Best regards,
Marcus

¹ performance hint: have a single object that you hold on to (e.g. 
`static pmt::pmt_t done_msg = pmt::cons...`) and re-send; constructing 
PMT symbols is expensive; keeping a single PMT with refcounter isn't)
² I'm not too deep into the details of these APIs/syscalls, but epoll is 
probably the thing you want in most cases, especially if you're watching 
more than one file descriptor.


[0] http://libusb.sourceforge.net/api-1.0/group__libusb__asyncio.html
[1] http://libusb.sourceforge.net/api-1.0/group__libusb__poll.html

On 10/2/20 10:27 PM, w...@ire.pw.edu.pl wrote:

Hi Wojciech,

On 02.10.20 15:51, Wojciech Kazubski wrote:
I suppose that in 3.8 the source block has to signal required sample 
rate to

GR runtime. Is this correct?


No, that's not correct. The runtime doesn't care about required rates at
all. It just makes blocks produce items as fast as they can.


How to fix the code?


Good question! Unless you're doing something *very* specific in your
code, I'd honestly blame this on a bug that was introduced during
porting – but I might be wrong.

Two very common tools to investigate this are rather simple:

1. htop (a `top`-alike program with a bit better visualization), with
thread names enabled – that way you can see which block occupies the CPU
the most, because all blocks run in their own thread
2. `perf` (especially, `perf top -a`), which allows you to sample in
which function your CPU cores are most often. That way, you can identify
functions that might be the blockers there.

Best regards,
Marcus



I thik that the problem is not related to CPU load by my blck. The 
total CPU load is very low, less than 5%. I made some debugging by 
addin some test messages printed each time data is  written to or read 
from the internal buffer. Data is written to the buffer by libusb and 
read by calling a "work" function (in bloccks of 4096 samples at a time).


In 3.7 I see great number of messages indicatig tha data ie read from 
the buffer. Part (about half) of the messages show 0 bytes read, due 
to lack of new data from usb. By this, data rate is reduced from  
~30Msps to 16.368Msps.


In contrast in 3.8 the work function is called only about 4 times a 
second, giving 16ksps. This is some 2000 times less than in 3.7.


--
Best regards
Wojciech