[Discuss-gnuradio] CDMA
*Thank you *Achilleas *I did the first step completely and then about the second step , I changed the Prefix from ("/home/anastas/gr-cma"**) to ("/home/gr**-cdma"* *) since after cloning the the given address, gr-cdma is built under the home directory. * *then I did what I am supposed to do. Up to the end of the command "sudo ldconfig" every things seem to work fine and I did not receive any errors , then I ran the following command"*cd gr-cdma/apps*" after that this command "*gnuradio-companion & *" then I pressed Enter , and received the followings in my terminal and the GNUradio opened up showing NOTHINGMy terminal amp_var_est_hier.grc,: command not foundcdma_tx_hier.grc,: command not found...and so on Error: Block key "cdma_tx_hier" not found in Platform - grc(GNU Radio Companion)I would be so grateful if could help me thanks Alfred * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio installation script
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
Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
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] Soundcards / alsa block / sample rates
Hi Marcus, i changed the audio_sink.xml and add the sample option of 192k sample rate. Now ich could choose them in the flow graph. The parameter seems to be set by alsa because the alsa output on the terminal tells me nothing about setting a lower sample rate below 192k in the device. The device is: hw,HD,0 Now im wondering because there should be signals from 57 khz to 76 khz and not more. If i put my speakter to the soundcard i can hear signals. If i remember corretly all signals over 25khz couldnt be heared ?! The FFT Sink of gnuradio shows the signals correctly between 57 khz and 76khz. regards, Andy Gesendet: Montag, 21. September 2015 um 22:39 Uhr Von: "Marcus Müller" An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] Soundcards / alsa block / sample rates What device string are you using? On 21.09.2015 22:32, Andreas Ladanyi wrote: Hi Tom, > I'm not sure that I understand. What "alsa block"? Are you talking about the audio source/sink blocks? And I'm assuming you mean inside GRC? Yes, sorry, I mean the audio sink block which talks to the alsa system. >The sample rate of this blocks is a combo box that is editable, which means you can set your own value there. The drop-down selections are just a handful of known sample rates. Yes, but i couldnt change the sample rate to 192k. So the block seems not to negotiate / recognize the possible sample rates. So i asking myself how i could set the correct sample rate of 192k or how it could be detected and used by the audio sink automatically. Andy ___ 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 ___ 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
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
Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long
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] UDP Sink Size Limit - ERROR: send error:send_to: Message too long
> 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] cdma_txrx
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] CDMA
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] RFNoc and data rates
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] Help with building GNU Radio for Android
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 FFTW). >> >> >> Yeah, wh
[Discuss-gnuradio] CDMA
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] Fwd: Re: Transmission error
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 > mailto:marcus.muel...@ettus.com>> 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 >> even though I did not set a
Re: [Discuss-gnuradio] Questions about burst communication
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] Help with building GNU Radio for Android
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
Re: [Discuss-gnuradio] Function Probe and OOT Blocks
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 http://www.mimecast.com -
[Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long
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