Re: GNU Radio Project Mission Statement -- Looking for Your Thoughts!
El 13/8/20 a las 22:40, Martin Braun escribió: > GNU Radioers, > > as the GNU Radio project matures, we're going to spend some time > evolving the actual organization behind it. We'll keep you posted on > updates on that, but as a first step, we'd like to define the mission > statement of the GNU Radio organization. Hi Martin, That sounds like a great idea! Maybe I don't have my ideas in enough order to condense them into some form of mission statement yet (maybe something will occur in the next few days), but I thought I'm going to launch them here now to contribute to the discussion. As you said, the GNU Radio project is much more than the GNU Radio software. Around this software there is a whole community of people doing DSP and RF, sharing their ideas, code and results in an open and friendly manner, in the spirit of the FOSS ideals. We've had a few talks in GRcon where GNU Radio isn't used a single time, yet the subject of the talk is very in line with the spirit of the GNU Radio community. FOSDEM is another great example. It's not technically GNU Radio, but it has a large presence of GNU Radio people. Most of the talks are not about GNU Radio, but still completely relevant to GNU Radio. Personally, I think that I use GNU Radio in only about half of my projects. However, in all of them I draw ideas from the GNU Radio community, be it in the form of code, theory, or just inspiration. I can say that GNU Radio and its community shapes my way of viewing this field of technology. Another random example: if one wants to learn about how to actually do PLLs in practice, they might go and read Tom Rondeau's post http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html or browse the GNU Radio code. The ideas might end up implemented somewhere else (hopefully open source). So the GNU Radio software is the central piece to the GNU Radio project, but there are many more activities surrounding it. My vague idea of the GNU Radio project's mission would be something along the lines of "to promote and foster this kind of activities". Now we have to come up with a good definition of these activities. Best, Dani. signature.asc Description: OpenPGP digital signature
2020 IEEE Vehicular Networking Conference (VNC)
Greetings, The call for papers for the 2020 IEEE Vehicular Networking Conference (VNC 2020) is now available. We appreciate disseminating this call for papers among your organization and forward it to other interested parties. * IEEE VNC 2020 - CALL FOR PAPERS ** The 2020 IEEE Vehicular Networking Conference (VNC 2020) December 16–18, 2020 | Virtual Conference https://urldefense.com/v3/__http://www.ieee-vnc.org__;!!KGKeukY!maPg-9R9kDaIO9cT8ScGGB8rVCUDdagBz5YC7Odw8nJIlj59Zwde7erDI6TQtE0JYA$ ** The Conference The IEEE Vehicular Networking Conference (VNC) is the premiere conference on vehicular networks and applications. It brings together researchers, professionals, and practitioners to share the latest results and to brainstorm the next phases of exploration in the foundations, technologies, and applications of vehicular communication networks. The 2020 VNC will be held virtually between December 16-18, 2020. Important Dates Full/short paper submission deadline: September 18, 2020, 23:59 AOE (Anywhere on Earth, UTC-12) Demo/Poster paper Submission Deadline: September 30, 2020, 23:59 AOE (Anywhere on Earth, UTC-12) Acceptance notification: November 6, 2020 Camera ready paper due: November 20, 2020 Presentation videos due: December 4, 2020 Conference: December 16-18, 2020 Topics of Interest Connectivity * 5G technologies for connected vehicles * Emerging V2X communication technologies, including dynamic spectrum sharing, mmWave, massive MIMO, beamforming, and vehicular visible light communications (VLC) * Networking, transport and QoS management for vehicular networks * In-vehicle communication and networking systems * Radio for vehicular networks: channel measurements, propagation models, antenna design, etc Architecture and System Design * Heterogeneous vehicular networking (e.g., multi-radio, multi-channel, multi-application, multi-technology) * Architectures and system designs for connected, automated driving * Edge computing and cloud * Security, privacy, liability, and dependability of vehicular networks * Integration of V2C with on-board systems and networks Tools & Methods * Hardware and software platforms for the simulation, emulation, prototyping, measurement, and/or real-world deployment of vehicular networks and applications * Field measurements and/or real-world deployments of vehicular networks and applications * Modeling, design, and analysis of vehicular networks and applications Connected & Automated Driving and Other Applications * Cooperative perception and cooperative driving * Innovative vehicular network applications and their communication requirements * Vulnerable road user protection * Vehicular networks and IoT integration * Impact assessments of vehicular networks on transportation Manuscript submissions The submitted papers must be written in English and be formatted in the standard IEEE two-column format and with a font size no less than 10-point. The mandatory IEEE template in Microsoft Word and LaTeX format can be found at the IEEE templates page. Only Adobe PDF files will be accepted for the review process. All submissions must be made electronically through EDAS. Details will be available at the conference webpage https://urldefense.com/v3/__http://www.ieee-vnc.org/__;!!KGKeukY!maPg-9R9kDaIO9cT8ScGGB8rVCUDdagBz5YC7Odw8nJIlj59Zwde7erDI6SoHwLzjQ$ soon. The conference will consider four categories of submissions: • Full papers should describe novel research contributions and are limited in length to eight (8) printed pages including figures, tables, and references. Papers exceeding 8 pages will be declined automatically and will not be reviewed. • Short papers should be more visionary in nature and may report on work-in-progress without fully finished results. They are meant to present novel perspectives, so as to foster discussions about innovative directions and new points of view. They are limited to at most four (4) pages including figures, tables, and references, but might in many cases be even shorter. Accepted short papers will be included in the proceedings and will be given (a shorter) time for oral presentation at the conference. • Posters are especially suited for presenting controversial research directions that may generate discussion, or promising ideas not yet fully validated through complete extensive evaluation. • Demonstration (demo) papers are suited for
Re: audio sink RuntimeError: audio_oss_sink
Hi Rick, does it work when you put nothing in the device field? (because that should select the default audio architecture, ALSA in your case, and use the default device, which would be Pulse Audio sitting behind "default".) Using "sysdefault" can normally fail, since that might not be a shareable device. "default" is really what you'd normally be going for. A program I like to use to see which programs use Pulseaudio, natively or through the "default" ALSA device, by the way, is `pavucontrol`. Best regards, Marcus On 14.08.20 00:27, aardric wrote: > Hail, > > I am introducing myself to SDR technology and gnuradio through > whatever project documentation I find, dissecting the code and executing > simple experimental flow graphs to test understanding of concepts, > hoping to avoid forum queries (this is my first). Although the audio > sink is not critical to my ultimate use of gnuradio and a bit of a > diversion I will eventually start digging into it. However, I thought to > submit a query on whether there is something obvious I should try in > order to get it working. I am using gnu radio companion 3.8.1.0 (Python > 3.6.10) and feeding the audio sink with a 1 kHz tone from the signal > source block. > > (1) staring with: > :~> aplay -L > null > Discard all samples (playback) or generate zero samples (capture) > default > Default ALSA Output (currently PulseAudio Sound Server) > sysdefault:CARD=PCH > HDA Intel PCH, ALC892 Analog > Default Audio Device > front:CARD=PCH,DEV=0 > HDA Intel PCH, ALC892 Analog > Front speakers > surround21:CARD=PCH,DEV=0 > HDA Intel PCH, ALC892 Analog > 2.1 Surround output to Front and Subwoofer speakers > (...) > hdmi:CARD=PCH,DEV=0 > HDA Intel PCH, HDMI 0 > HDMI Audio Output > hdmi:CARD=PCH,DEV=1 > HDA Intel PCH, HDMI 1 > HDMI Audio Output > hdmi:CARD=PCH,DEV=2 > HDA Intel PCH, HDMI 2 > HDMI Audio Output > hdmi:CARD=PCH,DEV=3 > HDA Intel PCH, HDMI 3 > HDMI Audio Output > hdmi:CARD=PCH,DEV=4 > HDA Intel PCH, HDMI 4 > HDMI Audio Output > > (2) using sysdefault:CARD=PCH for the audio sink device name, > both 44.1 kS/s and 48 kS/s the following runtime error results: > > (3) > gr::log :INFO: audio source - Audio sink arch: oss > audio_oss_sink: sysdefault:CARD=PCH: No such file or directory > Traceback (most recent call last): > File "/gnuradio/examples/audiotest.py", line 136, in > main() > File "/gnuradio/examples/audiotest.py", line 112, in main > tb = top_block_cls() > File "/gnuradio/examples/audiotest.py", line 78, in __init__ > self.audio_sink_0 = audio.sink(samp_rate, 'sysdefault:CARD=PCH', True) > File > "/usr/local/lib64/python3.6/site-packages/gnuradio/audio/audio_swig.py", > line 220, in make > return _audio_swig.sink_make(*args, **kwargs) > RuntimeError: audio_oss_sink > > >>> Done (return code 1) > > (4) Fixing this isn't critical and in time I will get to the bottom of > it; the forum query just removes the possibility of an obvious answer > that most everyone else knows about. My guess is that I have to disable > the Pulse audio server. > > > Rick > > > >
