Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
Hello Aditya, 1. I tried checking for the average power but that doesn't work. Even with two transmitters transmitting at the same time the energy detected by the receiver doesn't change much. It remains in the same order. 2. Is there any other simpler way of detecting collisions other than the mentioned paper? Regards, Sumedha On Fri, Nov 8, 2013 at 8:32 PM, Aditya Dhananjay wrote: > Hi Sumedha, > > 1. You could perhaps look at the average power received over that time > slot. If there is a collision, the receive power would ostensibly be higher. > > 2. Traditionally, a collision implied that nothing could be done, and the > data was lost (unless one transmitter overwhelmed the other transmitter's > signal, leading to the capture effect). However over the past couple of > years, there have been techniques developed to recover packets from > collisions. You could read the "Zig-Zag decoding" paper by Shyamnath > Gollakota and Dina Katabi from SIGCOMM 2008. > > > http://groups.csail.mit.edu/netmit/wordpress/wp-content/themes/netmit/papers/ZigZag.pdf > > Aditya > > > > On Fri, Nov 8, 2013 at 8:44 AM, Sumedha Goyal wrote: > >> I have a setup of one receiver and two transmitters. I am implementing a >> TDMA structure (using USRPs and GNURADIO) where only one packet is sent in >> each slot. When both transmitters try to transmit in the same slot, >> collision occurs. I would like to know >> 1. How can the receiver detect whether a collision has occurred or not? >> 2. What happens to the collided packets? >> >> >> Regards, >> Sumedha >> >> ___ >> 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] I couldn't observe 2.4G Wi-Fi signal and didn't know why
Hi Howard, as for things that can cost you a lot of time to figure out, until you start all over again with calibration: Have you made sure that you attach the antenna to the correct RF port of the USRP, and connect that port to the correct connector on the daughterboard? Greetings, Marcus On 2013-11-10 04:53, Howard He wrote: I know this may due to stupid reasons while I have no idea how to achieve it. Ubuntu 13.04(32-bit); gnuradio-3.6.5; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-154-ge6a1de6d; USRP N210; RFX2400 There are two Wi-Fi APs in our lab with 802.11g and 802.11n standard. I use a simple software "wavemon" to get their information about channel and signal strength. I use four antennas for test. Two are official VERT2400, others are 2.4G antennas. I use the given example "uhd_fft.grc" (a simple FFT block) hoping to observe frequency spectrum of Wi-Fi signal. No matter what antenna I set up (even without antenna) and what central frequency I tune, the FFT window only shows something like noise around -50--60dB on whole spectrum (sample rate=25M) which is unlike the 802.11 standard. There is low possibility of bad hardware I guess. I doubt that there may be some problems with my test methods and hope for some advice. Thanks! -- Howard He Southeast University, Nanjing, China ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
On Mon, Nov 11, 2013 at 03:14:04PM +0530, Sumedha Goyal wrote: > Hello Aditya, > > 1. I tried checking for the average power but that doesn't work. Even with two > transmitters transmitting at the same time the energy detected by the receiver > doesn't change much. It remains in the same order. > 2. Is there any other simpler way of detecting collisions other than the > mentioned paper? Sumedha, this problem is a very fundamental one, and there is no one single correct answer. Using power as a metric is tricky, as in practice, you never know the initial power levels of the inidivual received signals. And if you had a test, how could you be sure it correctly identified a collision, and you didn't simply lose a packet due to a bad wave propagation situation? Perhaps you should try and tackle this on the MAC layer. When there is a collision, you will receive neither packet correctly, perhaps that will trigger an ARQ etc. You can allocate slots to users, or something like that. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpusaDfKnl3S.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
> > 1. I tried checking for the average power but that doesn't work. Even with > two transmitters transmitting at the same time the energy detected by the > receiver doesn't change much. It remains in the same order. > It is expected behavior to be in the same order. Try looking at the received power in absolute (not dB) scale. 2. Is there any other simpler way of detecting collisions other than the > mentioned paper? > Not that I am aware of. Sorry! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
On Mon, Nov 11, 2013 at 9:33 AM, Aditya Dhananjay wrote: >> 1. I tried checking for the average power but that doesn't work. Even with >> two transmitters transmitting at the same time the energy detected by the >> receiver doesn't change much. It remains in the same order. > > > It is expected behavior to be in the same order. Try looking at the received > power in absolute (not dB) scale. Even that's not likely to work because of the variations in wireless channels. This is why 802.11 uses CSMA/CA (collision avoidance) instead of the 802.2 CSMA/CD (collision detection). You can do things on wired channels that you can't on wireless ones. The collision avoidance is to do the carrier sensing and combine it with RTS/CTS to help with avoiding collisions. When not using RTS/CTS, you have to rely on higher layers to detect a missing packet and/or out of order packets and request retransmission or just fail to ACK. Fundamentally a very hard problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
> > > Fundamentally a very hard problem. > Yes, this is a very hard problem. Sumedha, you are implementing a TDMA scheme right? In a correctly implemented TDMA, there shouldn't be any collisions between transmitters that are using your TDMA protocol. If you are using a probabilistic TDMA (like Slotted Aloha), then I suppose the best protocol is "transmit and pray". If the CRC check fails, simply retransmit. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to collect the complex data of a dpsk modulator in a text file
I am experimenting with the one of the flowgraph examples "uhd_tx_dpsk.grc". I am able to see the complex number output in WX GUI NUMBER SINK block but I want to collect this output in a text file. If I use a "FILE SINK" block, it shows some symbols but nothing in the form of x+jy. Kindly suggest some technique to do this. Regards, Sumedha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to collect the complex data of a dpsk modulator in a text file
> I am experimenting with the one of the flowgraph examples > "uhd_tx_dpsk.grc". I am able to > see the complex number output in WX GUI NUMBER SINK block but I want to > collect this > output in a text file. If I use a "FILE SINK" block, it shows some symbols > but nothing in the > form of x+jy. Kindly suggest some technique to do this. > You need to use Matlab/Octave to read these files. http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
Fundamentally a very hard problem. Yes, this is a very hard problem. Sumedha, you are implementing a TDMA scheme right? In a correctly implemented TDMA, there shouldn't be any collisions between transmitters that are using your TDMA protocol. If you are using a probabilistic TDMA (like Slotted Aloha), then I suppose the best protocol is "transmit and pray". If the CRC check fails, simply retransmit. Aditya This all falls under the category of "wireless channel access protocols". There have been a huge number of them over the years, and a certain amount of research with google and papers on the subject would be a good thing(tm). If you have a reliable collision-detector scheme, you can use CSMA/CD. If not, there's P-persistent CSMA. And CSMA/CD, and TDMA schemes, and... -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [User Experience] Hangout Thursday
Hi everyone, Thursday is our first post-conference hangout regarding everything user experience related. This includes: - The web site (in particular: state of the in-wiki docs, FAQ) - Tutorials - General user experience At the conference, this spawned many different discussions and I've received lots of feedback, so I'm expecting a busy call. For people who have joined the community recently: This is a good place to help and contribute. In order to improve docs etc., we need GNU Radio beginners to give us feedback or, better still, write stuff yourself. The call starts 19:00 CET. Please head over to our Google Plus community page (https://plus.google.com/communities/105194615257651755927) to find out more and convert the time to your timezone. Please also join the #gnuradio IRC channel during the call. This way we can coordinate people who have trouble joining (and no matter how tech-savvy you think you are, G+ has ways of keeping you out of the call :). Also, we might run into participant limits, because hangouts only take 10 people max. Looking forward to new faces and good discussions! Martin -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpibhqBw4e3L.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FOSDEM '14 - Call for Participation
On Mon, Oct 14, 2013 at 04:36:33PM +0200, Martin Braun (CEL) wrote: > Dear friends and colleagues, > > next year's FOSDEM (the free and open source developer's meeting in Brussels, > Europe) will feature a new track on Software Defined Radio. > Therefore, we invite developers and users from the free software radio > community and to join us for this track and present your talks or demos. > > [...] > The track's web site resides at: > http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM14 Hi guys, once again, I'd like to invite everyone to submit presentations! We are very open to anything you have, and the slots don't have fixed lengths, so be it short or long, tutorial or presentation, come and participate! Quick reminder: FOSDEM is a "free software" happening in Brussels, Belgium. It's February 1st and 2nd, and it's free (although you'll have to pay your own beers). So have you... - Made something cool with SDRs? - Hacked wireless telecommunications? - Used SDR sensors for something new and awesome? - Some random project? We are looking to get a diversity of talks, ranging from signal processing, SDR hardware, projects, out-of-tree modules... Also, to make sure this is not misunderstood: This is *not* solely a GNU Radio event. We are looking to mix people from different projects, and bring FLOSS devs together from all over the world. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpwtZUx6QvAU.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?
On Sun, Nov 10, 2013 at 11:56 AM, Sylvain Munaut <246...@gmail.com> wrote: >> I'm having a couple of issues when trying to switch from >> FindGnuradioRuntime to GnuradioConfig > > Attached a patch that deals with issue 1 & 3. Issue 2 doesn't seem to > be an issue since ALL_LIBRARIES has absolute path in it. > > Cheers, > > Sylvain Thanks, Sylvain. I was actually working on a tutorial for gnuradio.org to describe the use of GnuradioConfig when I noticed the exact same issue with the _ALL_ variables. Your patch did the trick and has been pushed. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Userexperience - ideas about new live DVD
Martin Brauns post about the user experience hangout this thurday inspired me. I am no sure if I can make it to the hangout, but here are some thoughts: I was asked to do a presentation about Satellite Tracking, SDR and Gnuradio to a group of teachers next Monday and thought it would be good to check out the live DVD, because they may like to have something to take home. I think the idea of a live DVD is great, but I would suggest a couple of changes to further live DVD releases. The main reason for my feedback is that I guess the live DVD will most likely be used by Gnuradio newbies and probably even Linux beginners. So the live DVD should be as easy as possible for these people: - Distro: XUbuntu instead of using standard Ubuntu. While the "Unity" desktop of standard Ubuntu is completely different to Windows and MacOS desktops, XFCE is in my opinion much more intuitive to someone who comes from Windows, Mac and many other Linux distros. The most disturbing thing is that the current DVD does not mention Gnuradio on the desktop at all and there is not even a shortcut to the terminal. And compared to other desktop environments XUbuntu is much more light weight and less taxing on CPU / GPU. - No display compositing (transparency effects). Compositing and other bells and whistles can slow down the whole desktop if the graphics driver does not support it well - e.g. when running the live DVD as a virtual machine (I usually test live CDs/DVDs as VMs within Virtualbox), or on older computers. - Gnuradio installation: I would suggest a Pybombs build system with the main gnuradio components already installed. Probably in a build directory that sits in the default users home folder (/home/ubuntu/gnuradio), so no root installation needed. setup_env.sh can be called on login to put this build directory into the path. With this configuration people can install additional packages and can become familiar with Pybombs if they want to. - Additional software / packages: Things that might be interesting for radio amateurs and DSP / SDR interested people like: Audacity, Sonic Visualiser (www.sonicvisualiser.org), GPredict and more. - Desktop tailored for Gnuradio: Menus and launchers for gnuradio-companion, relevant documentation and GQRX. Not to forget a "ReadMe" on how to use this DVD. Browser (Firefox) with Gnuradio relevant bookmarks. I have never made, customized a liveCD DVD before, but I will try to get such an image ready with uck (Ubuntu Customization Kit). Any help, ideas and food for thought is welcome. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I'm using ControlPort to monitor transmissions through a USRP. I have a
flowgraph responsible for generating burst traffic and streaming to a uhd_sink.
Then I have a uhd_source tuned to the same frequency as the uhd_sink, and I
connect it to a ctrlport_probe2_c block with length=128. I have ControlPort
support compiled-in and enabled from a config file. I'm able to connect to a
remotely running flowgraph using gr-ctrlport-monitor and plot the PSD of the
"samples" vector pulled from the probe2 block every 100 milliseconds. The
problem is that after (what seems to be) a nondeterministic time, the ICE port
stops responding and gr-ctrlport-monitor reports an error:
ctrlport-monitor: radio.get threw exception (exception
::Ice::ConnectTimeoutException
{
}).
When I close and restart, gr-ctrlport-monitor times out and segfaults:
2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error: Traceback
(most recent call last):
File "/usr/lib/pymodules/python2.7/Ice.py", line 984, in main
status = self.doMain(args, initData)
File "/usr/lib/pymodules/python2.7/Ice.py", line 1031, in doMain
return self.run(args)
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
line 97, in run
radio = self.getRadio(host, port)
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
line 36, in getRadio
radio = GNURadio.ControlPortPrx.checkedCast(base)
File "/usr/local/lib/python2.7/dist-packages/gnuradio_ice.py", line 1257, in
checkedCast
return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
'::GNURadio::ControlPort', facetOrCtx, _ctx)
ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
{
}
Segmentation fault (core dumped)
So there are two issues to note here:
- Something in the ICE instance is breaking on the GNU Radio flowgraph
side. The port is still open; it just times out. Trying to instantiate
gr-ctrlport-monitor to an incorrect port just says "connection refused," as
expected.
- gr-ctrlport-monitor is not robust to connection-related errors like
timeouts or refused connections.
Is there any advice of what I can turn on or enable in GNU Radio or my
flowgraph to debug the first problem? I can live with the second problem as
long as I can make sure ICE doesn't break on me.
Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?
Hi Tom, > Thanks, Sylvain. I was actually working on a tutorial for gnuradio.org > to describe the use of GnuradioConfig when I noticed the exact same > issue with the _ALL_ variables. Your patch did the trick and has been > pushed. Great. I updated gr-fosphor to use the new stuff. But for now I use a "bundled" version (renamed FindGnuradio inside the OOT so that it has precedence over the system-wide GnuradioConfig) Once 3.7.3 has been out for some time and I can reasonably expect people to be up to date, I'll remove it and let the system one do the job. Cheers, Sylvain PS: BTW, in the tutorial, maye it should be "find_package(Gnuradio 3.7.2 REQUIRED)" or it will just be a warning but still try (and fail) to build ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Announce OOT module for IEEE-802.15.4g MR-FSK
I have reached release functionality of out-of-tree module I use to help in PHY conformance/interoperability to the MR-FSK standard in IEEE-802.15.4g. This work was done because this standard is currently being implemented in Japan, utilities for the whole country. It consists of four blocks: packet generator, TX switch, preamble detector, and packet sink. The TX switch and preamble detector are generic for FSK, and packet blocks should provide example for others to implement their own protocol. I hope some gnu-radio people in the know of OOT things could give it a once over. preamble detector was necessary because the clock_recovery_mm_ff is not good for a non-continuous signal. For more info, see the wiki for it https://github.com/dudmuck/gr-ieee802154g ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
