Dear Osmocom community,
as the pandemic continues and physical meetings are out of the question
for the forseeable future, it would be a good idea to have a periodic
virtual online meeting of the interested Osmocom community.
I was thinking of a format where we would serve two major purposes:
1) technical talks about osmocom relevant topics - ideally
current/recent developments
* can be pre-recorded to avoid any problems with technical setup,
streaming, ...
* should ideally have a Q+A session at their initial "airing" during
one OsmoDevCall
2) unstructured solicited social event (USSE)
* random chat in audio (optionally video)
* not recorded, obviously
The recording of the technical presentation should then be permanently
made available (like the presentations of our prior OsmoCon /
OsmoDevCon).
Not every OsmoDevCall would neccessarily need the two parts, but I think
it would be great if we can make that happen. We could also have e.g. a
two-weekly schedule for the USSE and a monthly schedule for the
technical presentation.
We'd need somebody to volunteer to "manage" the "broadcast" side of
this, preferably somebody with at least some prior exposure to online
events (like the c3voc).
I'm using https://osmocom.org/issues/4928 to collect a tentative list
of topics. Feel free to add your ideas there, as well as any comment/
feedback you may have.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear friends and fans of software-defined radio and free/open-source radio
topics in general,
FOSDEM 2021 (the free and open-source developer's meeting usually in
Brussels, Europe but **this time virtually**) will again feature a track on
Software Defined Radio and any other radio-related topics in the Free
Software Radio devroom. Therefore, we invite developers and users from the
free software radio community to join us for this track and present your
talks or demos.
Given the current circumstances and the virtual nature of this event in
2021, we are asking the presenters to pre-record the talks, which will then
be gathered by us and streamed during the event. Presenters are also asked
to be present online during their timeslot for live Q&A.
Software Radio has become an important tool to allow anyone to access the
EM spectrum. Using free software radio libraries and applications and cheap
hardware, anyone can now start hacking on wireless communications, remote
sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM,
we hope to network all these projects, and improve collaboration, bring new
ideas forward and get more people involved.
The track's website resides at the link below. The final schedule will be
available through Pentabarf and the official FOSDEM website. Notice that
the reference time will be Brussels local time (CET).
https://fosdem.org/2021/schedule/track/free_software_radio/
Additional Information will be also available at:
https://wiki.gnuradio.org/index.php/FOSDEM_2021
** Submit your presentations
To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM21 and
follow the instructions (you need an account, but can use your account from
last year if you have one. Please do NOT create a new account if you
already have one). You need to create an 'Event'; make sure it's in the
Free Software Radio track! Your submission should have the following
information:
* Your contact Email
* A descriptive title and subtitle of your talk
* A short abstract
* Links related to the project
* [Optional] A longer description of the content of your talk.
Lengths aren't fixed, but give a realistic estimate, and please don't
exceed 30 minutes unless you have something special planned (in that case,
contact one of us). We will typically go for 30-minute slots -- shorter
talks, unless they're really short, usually tend to screw up the schedule
too much.
You aren't limited to slide presentations, of course. Be creative. However,
FOSDEM is an open-source conference, therefore we ask you to stay clear of
marketing presentations and present something relevant to free/open
software. We like nitty-gritty technical stuff.
Topics discussed in this devroom include:
* SDR Frameworks + Tools
* Cellular/telecoms software
* Free/Open SDR hardware
* Wireless security
* Random fun wireless hacks
* SDR in education
* Satellite/spacecraft communication
* Ham radio related topics
** Important Dates
* Submission deadline: 26 December 2020
* Announcement of selected talks: 31 December 2020
* Conference dates 6 & 7 February 2021 online
* Free software radio devroom date: Sunday 7 February 2021 online
In the last years we were always full to the brim with presentations, so if
you want to present, please make sure to submit your abstracts soon!
** Following steps for accepted talks
When your talk is accepted, you will be contacted by a deputy who will help
you with the pre-recording of your talk. Together you will make sure that
the content has the required quality and is stream-ready. When complete,
the recording will be located into the streaming system, and Bob's your
uncle.
Don't forget that you **must** be available during the allocated timeslot
of your talk for live Q&A.
** Steering Committee
The track committee consists of:
* Phil Balister - "Crofton"
* Derek Kozel - "dkozel"
* Nicolas Cuervo - "primercuervo"
* Martin Braun - "mbr0wn"
Hope to hear from you soon! And please forward this announcement.
- Nicolas
Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.
Now:
* Sleep for up to 100ms each time waiting for the cond to be kicked;
* Check whether streaming is still enabled each time rather than
only when the function is entered.
This fixes hangs where consumers like gqrx via gnuradio
will do a stop_rx/start_rx very quickly to change something, and
the buffer receive path is waiting for a buffer.
---
lib/hackrf/hackrf_source_c.cc | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 662d04a..03ea3bd 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -30,6 +30,7 @@
#include <stdexcept>
#include <iostream>
+#include <chrono>
#include <gnuradio/io_signature.h>
@@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items,
{
std::unique_lock<std::mutex> lock(_buf_mutex);
- while (_buf_used < 3 && running) // collect at least 3 buffers
- _buf_cond.wait( lock );
+ while (_buf_used < 3 && running) { // collect at least 3 buffers
+ _buf_cond.wait_for( lock , std::chrono::milliseconds(100));
+
+ // Re-check whether the device has closed or stopped streaming
+ if ( _dev.get() )
+ running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
+ else
+ running = false;
+ }
}
if ( ! running )
--
2.28.0
Hi,
i try to transmit 2.48 ghz radio packets (beacons) at a fixed time
interval (e.g. every 1 s) via hackrf using the osmocom sink in gnuradio.
Without exception, the beacons are all received by my sniffer "golden
device" hardware, but burst.
It seems that the packets are only transferred via USB to the hackrf
device hardware when the buffer with the fixed BUF_LEN 262144
(32*16*512) is completely filled. For my setup this are e.g. 18 beacon
frames, which are transmitted as burst. When I look at the USB
interface, I can see this burst of data every 18 seconds in a full USB
request block (URB) of size 262144 byte. All other URBs (also of size
262144 - every approx. 200us) transferred via USB are filled with zeros
only. So this burst behavior should be caused by gnuradio.
How can I achieve that the complex data of the osmocom sink's input is
immediately (with the next URB) transferred to the hackrf hardware? Am I
missing any options of the GRC module?
Thank You in advance!
Regards,
Sebastian
--
__________________________________________________________
Sebastian Boehm
Brandenburg University of Technology Cottbus - Senftenberg
Computer Networks Communication Systems Group
E-Mail: sebastian.boehm(a)b-tu.de <mailto:Sebastian.Boehm@b-tu.de>
P.O. Box: 10 13 44
D-03013 Cottbus
GERMANY
Hello list!
I've been digging a bit into the osmo-bts project to explore the GSM
stack, and only ever see config information assuming you have a
full-duplex TRX radio. I have a HackRF One I'd like to use for TX and
an RTL-SDR I'd like to use for RX (both operating on the 900MHz GSM
band), but cannot seem to find any configuration information for setting
this up - even though I've seen some mentions in passing to osmo-bts-trx
supporing RTL-SDR devices. I really don't have the budget to drop a few
hundred more on a USRP device just to tinker with GSM and was hoping I
could get away with two dedicated radios.
Can anyone tell me 1. if this kind of setup is even supported and 2. if
so, point me to reference material that might help me make the connection?
Thanks in advance!
-Rob
--
==========
Robert Bates
Octobang
rob(a)octobang.com
https://keybase.io/arpieb
