I was playing a bit around with gr-fosphor for audio.
To make it look nice, I tried to increase the number of samples per second without changing the spectral shape.
(And no, that’s not just upsampling.)
That’s probably a stupid approach, but it worked somewhat.
What would you do if you were stranded on a lonely island?
I guess, learn how to prepare staple food – at least that’s what I did.
But seriously, in Ireland I just found toast, but no real bread.
After I listened to the German CRE podcast episode about bread, I gave it a try.
Still pretty bad, but already better than toast :-)
The breads are with sourdough and without yeast.
So only water, flour, and salt. Nothing else.
Marcus Mueller and I just gave a GNU Radio workshop at the Software Defined Radio Academy, held in conjunction with the HAMRADIO exhibition.
We were not sure how many people would show up since we had only 11 registrations, but, in the end, the room was completely full with about 80 people.
Great to see so much interest in SDR and GNU Radio also in the amateur radio community.
About 35 people had a laptop with them and were following us, creating an FM receiver that we successively extended for voice and, finally, APRS.
While we deliberately excluded installation, we heard that quite some people had issues.
That was not a problem for the workshop since Marcus prepared a live image that could be booted from an USB stick, but maybe we should consider making a GNU Radio install party next year.
In case you are interested, the material for the workshop is on GitHub.
I hope people had some fun at the workshop and will have a closer look at GNU Radio.
I always wanted to try some alternative approaches to make the spectrum visible and audible.
In the last days, I was playing a bit around; not with the whole spectrum, but, at least, with WiFi channel 1.
SpectroPhone – Channel 1 in C Major
What happens here?
The canvas on the right is a live representation of the WiFi traffic on channel 1.
Of course, I cannot see the content of the (mostly) encrypted signals.
But I can record the signal strength, the size, and the hardware address of the sender.
The hardware addresses are not assigned randomly.
Each manufacturer gets a certain range allocated by IEEE.
A list of these address ranges is available on their website.
With this list, I can map each WiFi signal to the manufacturer of the chip that sent it.
What can I see?
For each signal that I overhear, I place a circle randomly on the canvas.
I use the following mapping to represent the WiFi traffic:
- Color: manufacturer
- Radius: amount of data
- Fade duration: signal strength
Radius and fade duration are straight forward.
To map the manufacturer, I hashed the name to an RGB color.
(That’s the same thing as picking a random color for the first signal and sticking to the choice for the following.)
I took some screenshots in different environments.
Left: Dublin’s buses use Realtek chips (yellow).
Right: Apple is green. Here, my mobile phone was uploading something when I came in range of the university network.
Left: The “green college” uses infrastructure from Dell and D-Link, which were (by chance) both mapped to greenish colors.
Right: The “pink streets” around the parliament.
Overall, the number and the size of frames indicate spectrum utilization, while the colors show the diversity of the hardware.
What can I hear?
To create an audio representation of the WiFi spectrum, I hash each manufacturer to a note in the c major scale.
The WiFi signals then play the note.
That means each WiFi signal increases the volume of the note proportional to the amount of data that it transmits.
After that, the volume decays exponentially.
If there many signals from a manufacturer, the note will stay active as each signal pushes the volume up.
If there are no signals, the volume goes down.
In the video, you might have noticed a constant beat from the small dark green circles.
They are beacons from Virgin Media routers that are deployed everywhere in my neighborhood.
I took another walk through the spectrum.
This time I created a starfield-like animation to visualize the frames.
It doesn’t always render at full frame rate.
So no happy eyeballs yet :-)
In addition, I down-scaled the volume a bit.
The idea was to not clip at maximum volume if there are only beacon frames.
That way, actual data transmissions would increase the volume, which was not always the case before.
It didn’t work too well though.
Apart from that, I found it a bit unintuitive that frames that had very similar colors could produced totally different tones.
Therefore, I mapped the colors first to their hue and used the hue to map to notes on the tone scale.
This is a bit like mapping the spectrum of the rainbow to the scale.
I’m really excited to join SRS (www.softwareradiosystems.com) to work on srsLTE, their Open Source LTE implementation.
So it really happened; I moved to Ireland.
To be honest, I didn’t think much before I actually went there.
It was more like: what can possibly go wrong.
My plan was to throw everything in my car and just go there by ferry.
That worked out pretty good and also the trip on the ferry was a cool experience.
I didn’t have a flat when I went there but had to spent the first days in a hostel.
As it turns out, the housing market in Dublin is plain crazy.
I took me about two weeks to find something that I could afford and that was not totally run-down.
Now I pay absurd amounts for a tiny studio.
Unfortunately, my car, with all my stuff in it, was broken and everything that had some value was stolen.
My mountain bike, my PC, my cloth, etc… all gone.
Now my possessions align pretty well with the space in my flat :-/
Some first impressions from around Dublin.
Christ Church Cathetral (left) and Trinity College Dublin (right).
Howth, a small fisher village at the cost north of Dublin.
The cliff walk between Bray and Graystone is beautiful.
I won a Marie Skłodowska-Curie Post-Doc Fellowship, which funds me for the next two years.
During the time I will work at CONNECT, Ireland’s Research Centre for Future Networks and Communications.
CONNECT is spread across many institutions.
I’ll be located at Trinity College Dublin and work in Prof. Linda Doyle’s research group.
For the fellowship, I had to come up with a project proposal that was peer reviewed.
The review was positive and I was invited to an interview where I gave a short presentation and was asked (quite detailed) about the project.
I’m very happy that all went well.
Especially, since the proposal was one of the first things I made on my own.
(And the ability to conduct more self-guided research is the goal of doing a PhD.)
Overall, I was ranked second of 41 submission in my category, where 59% percent of the applicants had over four years of post-doc experience.
Since the single-threaded scheduler was recently deleted in GNU Radio’s next branch, we’re left with the multi-threaded version.
I guess this change doesn’t hurt too much.
The multi-threaded scheduler is the default and, therefore, already used by the vast majority of users.
This scheduler starts one thread per block to distribute the load and parallelize processing to benefit from modern multi-core CPUs.
To understand how GNU Radio works under the hood, I wanted to see how these threads are created.
What I expected to find were threads that run a static function that takes a block as parameter and handle its execution.
What I found was a bit more complicated.
The scheduler maintains a thread pool.
During startup it creates one
thread_body_wrapper per block.
This wrapper mainly masks signals like
Inside the wrapper, there is a
Actually, this should be the function, but the
tpb_container is a copy-able object that overwrites the
operator() to appear like a function.
Inside this overloaded operator, it instantiates a
tpb_thread_body, which isn’t a function, but a class that implements the actual functionality in its constructor.
tpb_thread_body doesn’t actually execute the block.
It has a member of type
block_executor, which takes care of running
So to execute
work() one just uses the
block_executor which is a member of
tpb_thread_body, which is inside a
tpb_container, which is inside a
thread_body_wrapper, which is a
boost::thread, collected in a
Easy as that…
I think this part of the code is not really accessible to potential contributors.
In my opinion, we should try to reduce complexity as good as we can.
Some initial thoughts:
- The scheduler is overly generic since it still contains code to select different schedulers.
I think we should delete all unnecessary complexity and merge
- We could transform
tpb_thread_body into what it actually is, a static function run by the thread.
tpb_thread_body becomes a function, it can be directly used by
tpb_container can go.
- It would be strange to have one file and one class only for a single static function. This function could, for example, be added to
block_executor, having something like
static void block_executor::run().
We’d end up with something like:
auto f = boost::bind(&block_executor::run, blocks[i], block_max_noutput_items);
If you are interested, join the discussion.
Recently, I visited the Mobile World Congress in Barcelona.
Knowing only academic conferences, it was very interesting to attend an industry exhibition.
MWC was huge. Much bigger than I expected.
In December I visited 33c3 and thought that this was already incredibly big with about 13k visitors.
MWC had about 108k.
I found it most interesting to see what industry is currently up to.
And compare it to what academia is currently up to.
I know it shouldn’t be compared.
The self-perception of most academics might be that they are working on stuff that will be at MWC 2020.
Still interesting to see the different trends.
With regard to my dissertation topic (Vehciular Ad Hoc Networks), for example, I had the impression that academia is going for IEEE 802.11p, while industry seems to be all in on LTE for V2X.
I somehow seem to receive more and more emails.
Would be great if they were part of interesting conversations, but that’s, unfortunately, not the case.
Most emails are about my Open Source work and, in particular, about my GNU Radio IEEE 802.15.4 and IEEE 802.11 modules.
As you might have guessed, most emails are not from users who are so super happy with my software that they just have to tell me.
That itself wouldn’t be a problem.
But people spam me with very low-quality help requests.
Most email would need a lot of back and forth until we arrive at a question that could actually be answered.
When I talk about this with friends, they think that I might just be too critic.
But if I show them my inbox, they usually change their mind.
The problem is that this is not only annoying, but I find it very stressful to deal with such non-sense on a daily basis.
Since it’s unlikely that people will change, I had to adapt my work flow.