Re: [Discuss-gnuradio] Questions about burst communication

[Martin Braun]

On 24.09.2015 16:31, lwas...@ostatemail.okstate.edu wrote:
> Julian and Martin,
> 
> Typically 2 U's appear then a stream of O's. Ya, I don't have any sort
> of correlation block on the receiver side so that is definitely a
> problem. Next week I'll work on implementing a correlation block with a
> barker code preamble.
> 
> Do you have any suggestions for quick testing and validation? What I've
> been doing to check the bytes, if my acknowledgment fails, is to save
> the bytes to a file and use MATLAB to inspect them. Is there an easier
> way to quickly look at individual bytes?

If you have lots of O's, looking at bytes won't help -- the O's are
because your receive part is somehow too slow or stalling. You'll need
to fix that first.

Does your receiver have it's own dedicated thread?

M


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

Re: [Discuss-gnuradio] Fwd: Re: Transmission error

[Marcus Müller]

Hi Dave,

obviously 95% success means a 5% packet error rate. That sounds pretty
physically sound -- for most constellations, you can calculate the
symbol error rate from the SNR, and from the symbol error rate it's a
matter of combinatorics to derive the lower boundary for packet error rate.
Again, this is wireless communication. It's not a "works perfectly/works
not at all" world, but a "works stochastically" world. 5% packet error
rate might or might not be acceptable, depending on a specific application.

Best regards,
Marcus

On 09/25/2015 12:07 AM, Rama V wrote:
> Hi all,
> I have tried to send packets to the receiver from /digital/narrowband
> folder and it has mostly succeeded. The output I was able to get when
> I sent the following commands were
>
> Sender: ./benchmark_tx.py -p 4 -M 2 -f 2.43561G --tx-gain=28 -r 25
> Receiver: ./benchmark_rx.py -p 4 -f 2.43561G --rx-gain=54 -r 25
>
> ok =  True  pktno = 1323  n_rcvd = 1303  n_right = 1294
> ok =  True  pktno = 1324  n_rcvd = 1304  n_right = 1295
> ok =  True  pktno = 1325  n_rcvd = 1305  n_right = 1296
> ok =  True  pktno = 1326  n_rcvd = 1306  n_right = 1297
> ok =  True  pktno = 1327  n_rcvd = 1307  n_right = 1298
> ok =  True  pktno = 1328  n_rcvd = 1308  n_right = 1299
> ok =  True  pktno = 1329  n_rcvd = 1309  n_right = 1300
> ok =  True  pktno = 1330  n_rcvd = 1310  n_right = 1301
> ok = False  pktno = 1331  n_rcvd = 1311  n_right = 1301
>
> But there were a few packets where I have not received them correctly.
> I guess only 95% of them were efficient in transmitting.  I have tried
> changing the gain settings and what I observed was that if I decrease
> the gain from its normal value, the reception of packets are somewhat
> less efficient. Can I kindly know what I might be able to do in order
> to receive those packets in a more efficient way or is that what
> generally happens in a real world transmission? Thanks
>
> Regards,
> Dave
>
> On Tue, Sep 22, 2015 at 1:02 PM, Marcus Müller
> > wrote:
>
> Ok,
>> This is because I have changed my folder to /digital/ofdm, I have
>> started to receive packets.
> this means that you're using something *completely* different than
> before. It's simply a completely different transceiver system.
>> kindly advise if I need to figure out the combination settings
>> till most of them receive properly? 
> Yes. You will need to figure out the optimum settings. Increase
> gain on the RX end, see if things get better or worse. Find an
> optimum for that. Do the same with the TX gain.
>> Because even though I did not set any sample rate, the
>> transmitter sent the information. 
> As mentioned before multiple times: run the programs with
> "--help". They will show you what default settings they have.
>
>> Please help. Please excuse me if I am being naive in asking these.
> It's alright to ask questions, but please remember to apply the
> things we tell you.
>
> Best regards,
> Marucs
>
>
> On 22.09.2015 00:59, Rama V wrote:
>> Hi,
>> As advised, the problem has been solved to a little extent where
>> I have got the below results by giving the commands as
>>
>> Sender : ./benchmark_tx.py -f 2.435G --tx-gain=25
>> Receiver: ./benchmark_rx.py -f 2.435G --rx-gain 50
>>
>> ok: True  pktno: 1971  n_rcvd: 1687  n_right: 358
>> ok: False  pktno: 1972  n_rcvd: 1688  n_right: 358
>> ok: False  pktno: 1973  n_rcvd: 1689  n_right: 358
>> ok: False  pktno: 1974  n_rcvd: 1690  n_right: 358
>> ok: True  pktno: 1975  n_rcvd: 1691  n_right: 359
>> ok: False  pktno: 1976  n_rcvd: 1692  n_right: 359
>> ok: True  pktno: 1977  n_rcvd: 1693  n_right: 360
>> ok: False  pktno: 1978  n_rcvd: 1694  n_right: 360
>> ok: True  pktno: 1979  n_rcvd: 1695  n_right: 361
>> ok: True  pktno: 1980  n_rcvd: 1696  n_right: 362
>> ok: False  pktno: 1981  n_rcvd: 1697  n_right: 362
>> ok: True  pktno: 1982  n_rcvd: 1698  n_right: 363
>> ok: False  pktno: 1983  n_rcvd: 1699  n_right: 363
>> ok: True  pktno: 1984  n_rcvd: 1700  n_right: 364
>> ok: False  pktno: 1985  n_rcvd: 1701  n_right: 364
>> ok: True  pktno: 1986  n_rcvd: 1702  n_right: 365
>> ok: False  pktno: 1987  n_rcvd: 1703  n_right: 365
>> ok: True  pktno: 1988  n_rcvd: 1704  n_right: 366
>>
>> This is because I have changed my folder to /digital/ofdm, I have
>> started to receive packets. But I guess this is only 50%
>> efficient in receiving packets. Not all of them have been
>> receiving properly. kindly advise if I need to figure out the
>> combination settings till most of them receive properly? Because
>> 

Re: [Discuss-gnuradio] Help with building GNU Radio for Android

[Schuyler St. Leger]

I have made some progress, though I am having problems with running the
gr-template app on my Android device, a Nexus 6 running Android version 5.1
and API level 22.

Although, now that I think about it, there's no reason to SWIG gr-grand.
>> You'll never use that in Python on Android; we only use the c++ library
>> out, and specifically the static libgnuradio-grand.a library.
>>
>> Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line?
>>
> ENABLE_PYTHON is not an available option, and there is no option to
> disable Python or SWIG (the cmake user settable variables can be listed
> using -LAH).
>
I was able to get CMake to disable SWIG by adding
-DSWIG_DIR=SWIG_DIR-NOTFOUND this will cause CMake to fail to find SWIG and
disable it.

With this I was able to successfully build GNU Radio for Android on OS X.

To summarize what I had to do to build GNU Radio for Android on OS X:
- When building boost add toolset=gcc-android as an option. I did this for
both stage and install, though I am not sure if this is necessary for
install.
- I changed -DPYTHON_EXECUTABLE=/usr/bin/python to
-DPYTHON_EXECUTABLE=/opt/local/bin/python so the correct Python version is
used. This is /opt/local/bin/python for MacPorts. UHD also needs Cheetah to
be installed to build it.
- When configuring gr-grand I disabled SWIG to fix problems with Python by
passing -DSWIG_DIR=SWIG_DIR-NOTFOUND to CMake.
- I added the -DENABLE_AIRSPY=False -DENABLE_PYTHON=False options when
configuring gr-osmosdr to disable Airspy and SWIG.

I am able to build the GrTemplate example, but when running it gets stuck
when calling FgStart() on a Nexus 6 running. This causes problems with
https://github.com/trondeau/GrTemplate/blob/master/app/src/main/java/org/gnuradio/grtemplate/GrTemplate.java#L18

This covers my problems with Ubuntu, though I have not done any more work
with this since I was able to successfully build GNU Radio for Android on
OS X.

> The real problem here is that android-toolchain/arm-linux-androideabi/bin/
> is empty and not symlinked to the tools in android-toolchain/bin/ like it
> normally is. I have tried rebuilding the toolchain multiple times, but it
> is not making the symlinks. I just copied the symlinks from OS X and it
> works on Ubuntu 14.04 (tested for FFTW).
>
I also had a similar problem when running ndk-build for libusb. I just
symlinked android-toolchain/bin/arm-arm-linux-androideabi-ld.gold to ld
 with android-toolchain/bin in the path, and was able to build libusb
successfully.

On Fri, Sep 25, 2015 at 7:01 AM, Tom Rondeau  wrote:

> Hey Schuyler,
>
> Any progress on your side of things? I've been busy with other aspects of
> the project and haven't been able to get back to this. However, I just
> picked up a new Android device, so I'm going to try to start from scratch
> with that and a VM to walk through the instructions and see what might need
> tuning or fixing. I'm on the road the next two weeks, but hope I can get
> this done when I'm settled for a bit in Dublin the week after next.
>
> Tom
>
>
> On Fri, Aug 21, 2015 at 3:34 PM, Schuyler St. Leger <
> schuyler.st.le...@gmail.com> wrote:
>
>> Although, now that I think about it, there's no reason to SWIG gr-grand.
>>> You'll never use that in Python on Android; we only use the c++ library
>>> out, and specifically the static libgnuradio-grand.a library.
>>>
>>> Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line?
>>>
>> ENABLE_PYTHON is not an available option, and there is no option to
>> disable Python or SWIG (the cmake user settable variables can be listed
>> using -LAH).
>>
>>
>> Are you sure you want armv7-m? Most of what we're using is armv7-a. But
>>> you might just try "armv7" instead to use a more generic v7 architecture.
>>> Take a look at the gcc man page for a list of supported machines. This
>>> might be something you'll need to play around with.
>>>
>> I made a mistake in copying the error, here is the correct error.
>> Assembler messages:
>> Fatal error: invalid -march= option: `armv7-a'
>>
>> I was able to get Boost to build. The problem is that when
>> arm-linux-androideabi-g++ calls the assembler it looks in the path for as the
>> problem with this is that the assembler for Android is named
>> arm-linux-androideabi-as . To fix this I symlinked
>> arm-linux-androideabi-as to as and android-toolchain/bin needs to be in
>> your path (it should be from setting up the android toolchain). However
>> this must be done after running bootstrap.sh or Boost will fail to build
>> Boost.Build. Running hash -r may be required to get bash to find the
>> correct assembler.
>>
>> The real problem here is that
>> android-toolchain/arm-linux-androideabi/bin/ is empty and not symlinked to
>> the tools in android-toolchain/bin/ like it normally is. I have tried
>> rebuilding the toolchain multiple times, but it is not making the symlinks.
>> I just copied the symlinks from OS X and it works on Ubuntu 14.04 (tested
>> for 

Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input

[Tom Rondeau]

On Wed, Sep 23, 2015 at 4:06 PM, Piotr Krysik  wrote:

> Hi all,
>
> Fractional resampler has additional "rate" signal input for supplying
> resampling ratio for each input signal sample.
> Changes of the signal on the "ratio" input might result in loss of tags
> that are close in time to these changes.
>
> I observed the problem when I was implementing frequency offset
> corrector (attached flowgraph screenshot).
> Short description what is going on there:
> -when message comes to ppm_in port of the block "Controlled const
> source" changes value of constant at the output,
> -when Controlled rotator observe this change on its input, it emits
> stream tag,
> -for changes of about +/-50ppm (and above) on the 'ratio' input of the
> Fractional Resampler, tags coming from the Controlled rotator are not
> going through.
>
> Just by looking at the Fractional Resampler implementation
> (
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L104
> )
> I'm not able to locate source of the problem.
>
> I can implement minimal working example if needed.
>
> Best Regards,
> Piotr Krysik
>

Piotr,

Looking at the block, I was hoping it was as easy as putting a
set_relative_rate call in the set_resamp_rate to adjust how the tags are
being propagated. But it's not that simple. See Issue #846 (
http://gnuradio.org/redmine/issues/846) for details on the problem.

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

Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[mleech]

 

If the sending machine sets DF in the IP header, then any interstitial
machine that must fragment will drop the packet as well. 

Best to stick to MTU-sized payloads with UDP, since IP fragmentation is
handled poorly in many cases--either due to policy, or bad
implementations. 

On 2015-09-25 15:17, Andy Walls wrote: 

>> From: David Halls Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: 
>> send
> 
> error:send_to: Message too long
> 
>> Date: Fri, 25 Sep 2015 09:05:56 +
> 
>> Dear All, When I increase my packet length in a transmission flow graph to 
>> over 16,000 bits, I get the following error "ERROR: send error:send_to: 
>> Message too long​"
> 
> This looks like the underlying sendto() system call is returning
> EMSGSIZE. From man sendto:
> 
> EMSGSIZE
> The socket type requires that message be sent atomically, and
> the size of the message to be sent made this impossible.
> 
>> this is from the UDP block which I am using in order to send the transmitted 
>> bits to the destination in order to perform BER. I am sending the packets in 
>> bursts, one packet every two seconds.
> 
>> I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set 
>> to true.
> 
>> Is this some fundamental limit, or can I overcome the issue?
> 
> 16,000 bits is 2000 bytes. The default MTU is usually 1500 bytes (for
> IP header, UDP header, and payload together). Try modifying the MTU on
> your machine's network interface to something larger, say 4000.
> 
> The MTU of the receiving machine or other network hardware might still
> be only 1500, so the the UDP packet could get IP fragmented. I'm not
> sure how well UDP works when fragmented.
> 
> -Andy
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

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

[Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[Andy Walls]

> From: David Halls
>Subject:   [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send
error:send_to: Message too long
>Date:  Fri, 25 Sep 2015 09:05:56 +

>Dear All,
>
>
>When I increase my packet length in a transmission flow graph to over
>16,000 bits, I get the following error
>
>
>"ERROR: send error:send_to: Message too long​"

This looks like the underlying sendto() system call is returning
EMSGSIZE.  From man sendto:

 EMSGSIZE
  The  socket  type  requires that message be sent atomically, and
  the size of the message to be sent made this impossible.




>this is from the UDP block which I am using in order to send the
>transmitted bits to the destination in order to perform BER. I am
>sending the packets in bursts, one packet every two seconds.


>I currently have the Payload size set to 147.2k and Send Null Pkt as
>EOF set to true.


>Is this some fundamental limit, or can I overcome the issue?

16,000 bits is 2000 bytes.  The default MTU is usually 1500 bytes (for
IP header, UDP header, and payload together).  Try modifying the MTU on
your machine's network interface to something larger, say 4000.

The MTU of the receiving machine or other network hardware might still
be only 1500, so the the UDP packet could get IP fragmented.  I'm not
sure how well UDP works when fragmented.

-Andy


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

Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[Andy Walls]

On Fri, 2015-09-25 at 15:17 -0400, Andy Walls wrote:
> > From:   David Halls
> >Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send
> error:send_to: Message too long
> >Date:Fri, 25 Sep 2015 09:05:56 +
> 
> >Dear All,
> >
> >
> >When I increase my packet length in a transmission flow graph to over
> >16,000 bits, I get the following error
> >
> >
> >"ERROR: send error:send_to: Message too long​"
> 
> This looks like the underlying sendto() system call is returning
> EMSGSIZE.  From man sendto:
> 
>  EMSGSIZE
>   The  socket  type  requires that message be sent atomically, and
>   the size of the message to be sent made this impossible.
> 
> 
> 
> 
> >this is from the UDP block which I am using in order to send the
> >transmitted bits to the destination in order to perform BER. I am
> >sending the packets in bursts, one packet every two seconds.
> 
> 
> >I currently have the Payload size set to 147.2k and Send Null Pkt as
> >EOF set to true.
> 
> 
> >Is this some fundamental limit, or can I overcome the issue?
> 
> 16,000 bits is 2000 bytes.  The default MTU is usually 1500 bytes (for
> IP header, UDP header, and payload together).  Try modifying the MTU on
> your machine's network interface to something larger, say 4000.
> 
> The MTU of the receiving machine or other network hardware might still
> be only 1500, so the the UDP packet could get IP fragmented.  I'm not
> sure how well UDP works when fragmented.

A little more Linux specific detail:
http://man7.org/linux/man-pages/man7/udp.7.html

"  By default, Linux UDP does path MTU (Maximum Transmission Unit)
   discovery.  This means the kernel will keep track of the MTU to a
   specific target IP address and return EMSGSIZE when a UDP packet
   write exceeds it.  When this happens, the application should decrease
   the packet size.  Path MTU discovery can be also turned off using the
   IP_MTU_DISCOVER socket option or the
   /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details.  When
   turned off, UDP will fragment outgoing UDP packets that exceed the
   interface MTU.  However, disabling it is not recommended for
   performance and reliability reasons."

-Andy




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

[Discuss-gnuradio] CDMA

[alfred noble]

Hi everyone
I've downloaded a code from the link below
https://github.com/anastas/gr-cdma
but I can not add the blocks used in the codes , I've also followed the
readme.txt file accompanied with the code , but it didn't work out either.
there are some commands like

import cdma
help(cdma)

but I don't know what to do with them and where I should run them
I would be so grateful if anybody could help me here
Thank you all

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

Re: [Discuss-gnuradio] RFNoc and data rates

[Simon Olvhammar]

Hi,
Looks like very interesting techniques. The current Gnuradio application 
has been up for about two weeks and it works very well and spectrums 
(frequency-switched) are what's expected. To account for delay, besides 
looking at transition signal, I also wait 0.001 seconds before i collect 
FFT:s when a S/R signal is introduced to the GPIO/RX. However, as you 
said, I might have to increase this wait time if I introduce the IIR 
block instead of python averaging.
Would you perhaps have a method to check the delay so can get some sort 
of mean value and add to this so I know that I'm always on the safe 
side? Or maybe guide me in the right direction so I can "get a feeling" 
for delays in gnuradio?  The "oblivious synchronous detection" might be 
a solution (not sure it would work with frequency-switching however?) 
but I would like to try getting the current setup optimized first.


Yes, CPU loads and data rates are big and we'd like to use the full 160 
Mhz of the UBX card, why I'm looking at RFNoC. I expect that delay times 
will become alot smaller as well with RFNoC?


Den 2015-09-25 kl. 03:31, skrev Marcus D. Leech:

On 09/24/2015 06:37 PM, Simon Olvhammar wrote:
Yes, in my current Python Gnuradio application I have implemented 
Dicke-switching by syncing it with external signals that indicate S/R 
as well as transition state of RF. I have not seen any issues with 
overlapping fft:s. The switch frequency is 1 Hz and the transition 
state signal has an interval of perhaps 100us where no storing of 
ffts is done.


I'm still very new to signal processing and I'm having trouble to 
understand the relation between alpha and how much is averaged, I 
just see a scale factor in the transfer function? 0.01 seconds seems 
quite alot and to reduce this to 0.001 seconds I could perhaps choose 
alpha=0.1 and N=10 if I'm understanding you right? Are we talking 
same delay times if I were to implement this is my current non FPGA 
gnuradio app?
You can chose the latency tradeoffs yourself.  If you want data 
delivered to the host faster, you'd likely choose a shorter integration

  time, by playing with alpha values.

But if your Dicke-switching time is on the order of 1s, then you could 
discard several FFT frames and still have very-high-quality data.


There's also a technique called "oblivious synchronous detection" 
developed by Ken Tapping at DRAO, and I did an implementation of it in
  my gr-ra_blocks package.  If the difference between "sky" and 
"reference" is more than a few dB, then you can just take buffers of data
  and "sort them into their houses"  (ref or sky) by "slicing" based 
on the distinct populations of samples, without having to worry about
  strict synchronization with your (external) switching source--the 
samples themselves tell you what "house" they belong in.






I have attached a flowgraph and it would be greatly appreciated if 
you could check if it looks right for the purpose of just storing 
averaged FFT:s.




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

Re: [Discuss-gnuradio] CDMA

[Achilleas Anastasopoulos]

Alfread,

I am willing to help you get started with this.

Let's take the README file and go over the "For the impatient:" section.

Which of the steps have you completed?

Achilleas



For the impatient:

1) Download gr-cdma from github
> git clone https://github.com/anastas/gr-cdma.git

2) Edit the file gr-cdma/python/cdma_parameters.py (line 97)
and set the prefix variable with your gr-cdma trunk directory.

prefix="YOUR_PREFIX_HERE/gr-cdma"  # put the prefix of your gr-cdma trunk

2) Build the package
> mkdir build_cdma

> cd build_cdma

> cmake -DENABLE_DOXYGEN=ON ../gr-cdma

> make

> sudo make install

> sudo ldconfig


3) compile hierarchical blocks and play with built in app
> cd gr-cdma/apps

> gnuradio-companion &

In the gnuradio-companion environment

-- Load the hier blocks  (compile one at a time and reload each time)

"amp_var_est_hier.grc",

"cdma_tx_hier.grc",

"chopper_correlator.grc",

"cdma_rx_hier.grc",

"cdma_tx_hier1.grc",

"cdma_rx_hier1.grc"

and compile them

-- Reload all blocks in grc

-- Load the application "cdma_txrx.grc" or "cdma_txrx1.grc" and have fun

Experiment with manual acq/tra, auto acq/tra, changing freq and timing
offset, SNR, modulation/coding type, etc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cdma_txrx

[Achilleas Anastasopoulos]

Let's try to investigate the error messages you are receiving.

When you run cdma_txrx.grc and you lower the SNR (the first slider) then
the receiver cannot anymore track/acquire the packet and a message appears
on the screen:


*** MESSAGE DEBUG PRINT 
((packet_num . 711) (packet_len . 54))

*** MESSAGE DEBUG PRINT 
((packet_num . 712) (packet_len . 54))

INFO: Detected an invalid packet at item 25668
*** MESSAGE DEBUG PRINT 
#f

*** MESSAGE DEBUG PRINT 
((packet_num . 714) (packet_len . 54))

*** MESSAGE DEBUG PRINT 
((packet_num . 715) (packet_len . 54))


When the SNR is up again the receiver goes back to acquisition/tracking and
recovers the remaining messages.
This is how the system is supposed to work.
BTW, the messages titled "*** MESSAGE DEBUG PRINT " are coming
from the message debug block,
while the messages "INFO: Detected an invalid packet at item 25668" are
coming from the  packet_headerparser_b block.


So far so good.

Now, if you want to run the cdma system with an actual usrp you should use
the two SEPERATE files:
cdma_tx.grc and cdma_rx.grc
For this you can disable the fifo sink/source and enable the already
present usrp blocks.

Suppose you do all these. Then you run the tx and the rx applications.

Now you are saying the what you see is a message like this:

Sgr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item
0
*** MESSAGE DEBUG PRINT 
#f


Clearly the first line is coming from the block packet_headerparser_b0 and
the other 3 from the message_debug block.
(why is does the first log message have a different fromat than above? ie,
why does it start with "Sgr::log :"--I don't know ... )

Neither seems to be a surprise (according to the previous discussion).
So the question is why the application stops (DOES IT STOP?)

For this you have to help us a little bit.
Can you figure out which process/thread stops?
It is interesting that the error happens at the very first sample 0.

Can you run JUST the cdma_rx.py and report the messages you are seeing.
Also using a debugger can you identify the thread that hangs.



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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

Guys,

The RAM came a day late (thanks USPS) and I installed it and ran the
script again Thursday and it finished this time with no errors. Now I
have to see if I actually ended up with a usable "GNU Radio"
installation.

Thanks for the help!

Mike

On Wed, Sep 23, 2015 at 9:58 AM, Mike Gilmer  wrote:
> LOL... good thing I already ordered some and am getting RAM in the mail today!
>
> Mike
>
> On Wed, Sep 23, 2015 at 9:53 AM, Marcus Müller  
> wrote:
>> "Killed" in almost all cases means "killed by the out-of-memory watchdog of
>> your operating system". You'll still need more RAM, need to reduce the
>> number of parallel compilation threads or at least swap storage to
>> successfully compile GNU radio. I recommend getting more RAM - that is
>> always a good thing to have, especially if planning to do some buffer
>> intense signal processing.
>>
>> Best regards,
>> Marcus
>>
>> Am 23. September 2015 15:48:37 MESZ, schrieb Mike Gilmer
>> :
>>>
>>> I worked my way up though the email chain and ran some of the
>>> "updates" suggested and reran the script
>>>
>>> It has gotten further along than before, but still fails...
>>>
>>>  Scanning dependencies of target volk_profile
>>>  [  5%]  [32mBuilding CXX object
>>> volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
>>>  mc++: internal compiler error: Killed (program cc1plus)
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See  for instructions.
>>> make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o]
>>> Error 4
>>> make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
>>> make: *** [all] Error 2
>>> make failed
>>> Exiting Gnu Radio build/install
>>>
>>> The complete output is at http://pastebin.com/jpA005nP  <--
>>> sorry
>>> about the control chars- next time maybe!
>>>
>>> Mike
>>>
>>> 
>>>
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[David Halls]

Dear All,


When I increase my packet length in a transmission flow graph to over 16,000 
bits, I get the following error


"ERROR: send error:send_to: Message too long?"


this is from the UDP block which I am using in order to send the transmitted 
bits to the destination in order to perform BER. I am sending the packets in 
bursts, one packet every two seconds.

I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set to 
true.


Is this some fundamental limit, or can I overcome the issue?


Regards,


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

Re: [Discuss-gnuradio] Function Probe and OOT Blocks

[David Halls]

​Thanks Patrick,


There may be many ways to skin a cat, but this method was very quick and easy 
to implement and does exactly as I need :)


From: Patrick Sathyanathan 
Sent: 24 September 2015 21:27
To: Kevin McQuiggin; David Halls
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Function Probe and OOT Blocks

Hi David, Making the parameter vary at runtime is simple and just needs some 
extra XML and python code. The parameter should be an argument to the __init__ 
method (constructor) of your block and should have a "" declaration in the 
matching XML file. Let's say the parameter name is "variable_param" with a 
declaration like: Variable parameter variable_param 42 int Then you need to add 
the following in the XML file: set_variable_param($variable_param) And you need 
to implement the "set_variable_param" method in your python class to take 
whatever action is needed when the parameter value changes. This method will be 
called every time the value of the expression in the underlined "Variable 
parameter" box in the GUI changes. The method will look like: def 
set_variable_param(self, new_value): whatever code This should make GRC 
underline the variable_param in the GUI and it will be variable at runtime. 
Thanks, --Patrick  > From: mcqui...@sfu.ca > 
Date: Thu, 24 Sep 2015 10:35:34 -0700 > To: david.ha...@toshiba-trel.com > CC: 
discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Function Probe and 
OOT Blocks > > Hi David: > > I'm a relative newbie myself, but I can say that I 
had this same issue. > I had a block with a static parameter that I wanted to 
be able to > change dynamically at runtime. > > I looked at the block's source 
code, and also at a block that had a > dynamically adjustable parameter. > > 
Basically, and with a little help from the list (Marcus Muller in > particular) 
as I had to learn c++, I was able to use the code from the > dynamic block as 
an example, and modify the static block to change the > parameter to be 
dynamically changeable. It all came down to at most a > couple dozen lines of 
code. The bigger challenge was learning about > Gnuradio's architecture, to 
know what to do. > > I would suggest a similar approach. You will find the list 
members > very helpful. I'd also look at the guided tutorials, there are good > 
examples there under "how to write a c++ block". > > I will help if I can but 
alas, I am still quite a newbie, so others > will be able to help much more 
efficiently! > > Kevin > > Sent from my iPad > > On Sep 23, 2015, at 4:12 AM, 
David Halls > > > wrote: > > > ​Hi guys, > > > I am familiar with using 
function probes to update values to blocks. > This is straightforward with 
built in blocks like Multiply Const, where > the input is underline in the GRC 
dialogue box. > > > How do I create a block, specifically a Python block, that 
allows me to > update parameters in this fashion so that they are not fixed at 
> runtime? > > > Regards, > > > 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 > > 
___ Discuss-gnuradio > mailing list 
Discuss-gnuradio@gnu.org > 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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 

Re: [Discuss-gnuradio] Help with building GNU Radio for Android

[Tom Rondeau]

Hey Schuyler,

Any progress on your side of things? I've been busy with other aspects of
the project and haven't been able to get back to this. However, I just
picked up a new Android device, so I'm going to try to start from scratch
with that and a VM to walk through the instructions and see what might need
tuning or fixing. I'm on the road the next two weeks, but hope I can get
this done when I'm settled for a bit in Dublin the week after next.

Tom


On Fri, Aug 21, 2015 at 3:34 PM, Schuyler St. Leger <
schuyler.st.le...@gmail.com> wrote:

> Although, now that I think about it, there's no reason to SWIG gr-grand.
>> You'll never use that in Python on Android; we only use the c++ library
>> out, and specifically the static libgnuradio-grand.a library.
>>
>> Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line?
>>
> ENABLE_PYTHON is not an available option, and there is no option to
> disable Python or SWIG (the cmake user settable variables can be listed
> using -LAH).
>
>
> Are you sure you want armv7-m? Most of what we're using is armv7-a. But
>> you might just try "armv7" instead to use a more generic v7 architecture.
>> Take a look at the gcc man page for a list of supported machines. This
>> might be something you'll need to play around with.
>>
> I made a mistake in copying the error, here is the correct error.
> Assembler messages:
> Fatal error: invalid -march= option: `armv7-a'
>
> I was able to get Boost to build. The problem is that when
> arm-linux-androideabi-g++ calls the assembler it looks in the path for as the
> problem with this is that the assembler for Android is named
> arm-linux-androideabi-as . To fix this I symlinked
> arm-linux-androideabi-as to as and android-toolchain/bin needs to be in
> your path (it should be from setting up the android toolchain). However
> this must be done after running bootstrap.sh or Boost will fail to build
> Boost.Build. Running hash -r may be required to get bash to find the
> correct assembler.
>
> The real problem here is that android-toolchain/arm-linux-androideabi/bin/
> is empty and not symlinked to the tools in android-toolchain/bin/ like it
> normally is. I have tried rebuilding the toolchain multiple times, but it
> is not making the symlinks. I just copied the symlinks from OS X and it
> works on Ubuntu 14.04 (tested for FFTW).
>
>
> Yeah, when this is right, you should see 'yes' for 32-bit and arm.
>>
> That is what I got when using OS X with Boost and specifying
> toolset=gcc-android .
>
> How hard would it be to get fosphor working on Android?
>
> Schuyler, there might have been a change in something in Android (they
>> really don't care about changing things between versions) when building the
>> standalone SDK. Take a look at the options you passed when building that
>> part of the project. Also, make sure you are using GCC 4.8 and NOT 4.9. We
>> have other issues with 4.9.
>>
> I am using GCC 4.8.
>
> ___
> 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