about & FAQ

absorptions is a blog about my hobbies. So far it's mostly about signals and programming, but may pick up a random new field at any point. It's a place for me to direct my need to talk nerdy. Why? I like the smell of unsolved mysteries. Call them obsessions or special interests; I call them absorptions.

Here I've collected some questions often asked in the comments section etc.

• Contact info
• Who?
• Why?
• What are your rates for a sponsored article or guest post?
• How did you learn about signals? How could I learn, too?
• Do you do talks or workshops?
• How could I support this blog?
• What's your decoding software of choice?
• What kind of radio hardware you've used in this blog?
• What's the software you use to draw graphics and waveforms?
• Could you release source code for this project you wrote about?
• Are you a hacker that breaks into computers?
• Will you decode this signal / write this program for me?
• What are you working on right now?
• What's that weird language?
• How is your name pronounced?
• I have questions!

Contact info

• blog author: Oona Räisänen
• inquiries via david.bientechmedia@gmail.com
• please browse through this FAQ first
• currently not open for talks or work assignments
• @windytan@mastodon.social

Who?

Hi, I'm Oona, a computer geek from Finland. This is a blog about stuff I've found interesting along the years. In my working life I'm a software engineer. You can follow me on Twitter for updates about new blog posts, although I don't tweet that much otherwise: @windyoona. There might be some fun stuff on my Youtube channel.

Why?

I write this blog because I want to share the joy of researching something interesting. And sound and waves are pretty interesting.

I'm one of those people who enjoy absorbing information about something very specific and solving mysteries for no apparent reason. Maybe it feels natural for us; maybe we see patterns in everything and are tempted to get to the bottom of them. Or maybe we never wanted to stop playing. Some would say there are lots of similarities with putting together puzzles. Perhaps you would like this Quora answer: Why do people like puzzles?

Sometimes I may do things the hard way, instead of the obvious way. Why? As a great composer once said, "only difficult solutions are worthwhile in art".

How did you learn about signals? How could I learn, too?

See my nerd story. I learnt by spending much of my free time experimenting with computers, playing musical instruments, and reading for many, many years. This geeky stuff is what I've always enjoyed doing and I find it relaxing as well. It's like when some people like listening to heavy metal or reading manga, and end up having a lot of knowledge on the subject as a byproduct.

Here are some sources that might be suitable for beginners:

• Seeing Circles, Sines, and Signals – a compact primer on digital signal processing
• Let's learn about waveforms by Josh Comeau
• RTL-SDR Quick Start Guide – set up a cheap radio scanner based on the RTL-SDR

And maybe not-so-beginners:

• Tutorials on Digital Communications Engineering by Charan Langton
• The Scientist and Engineer's Guide to Digital Signal Processing by Steven W. Smith, Ph.D.
• Signal Analysis for Radio Monitoring, a book on Amazon (I haven't read it myself)

What are your rates for a sponsored article or guest post?

I don't do those at all, sorry.

Do you do talks or workshops?

Currently I do not give talks, but there are some videos of past talks:

• SDR Analog Video Decoding Adventures (GRCon 2020)
• "My journey into FM-RDS" (30C3 2013)
• "Solving mysterious signals – a case study" (Reaktor Dev Day 2013)

How could I support this blog?

Maybe leave a nice comment, or better yet, get inspired to investigate some mystery yourself and blog about it :) It's a nice way to have a diary of past projects for yourself, too.

What's your decoding software of choice?

Some command-line tools I use (Linux and macOS):

• csdr does many kinds of basic low-level DSP tasks and can be used with Unix pipes on the command line. It can, for example, demodulate AM and FM, shift frequencies up and down, and convert integer data to floating point and back. It also works quite fast.
• SoX can do brick-wall sinc filtering and arbitrary resampling. It's sometimes easier to use than csdr because the frequency parameters are in Hertz. I also use it to change the number of channels, to write WAV file headers, and to convert between file types.
• For simple FSK stuff, minimodem is the perfect choice.
• multimon-ng for many digital modes.

For visually browsing the live radio spectrum and listening to carriers by ear I use the GnuRadio-based gqrx (macOS/Linux) and SDR# (Windows). For all kinds of offline measurements and visual inspection I use baudline.

I also write my own tools, many of them in C++ using the liquid-dsp C library. Some of these are open source:

• redsea for RDS
• deinvert for inversion scrambling

What kind of radio hardware you've used in this blog?

In most radio-related projects I've used a cheap USB DVB-T receiver stick, also known as RTL-SDR. Currently I use the Airspy R2 as my main receiver. Some FM radio related projects were done using a modified "worldband receiver".

What's the software you use to draw graphics and waveforms?

For waveforms I use my own program called oscille (explained in a blog post). Baudline renders beautiful spectrograms. For graphics design and compositing I use free software like Inkscape, GIMP, ImageMagick, and librsvg.

Could you release source code for this project you wrote about?

Short answer: no, unfortunately not.

Because I get this question a lot, here's a long answer: I like to write about my projects but I only occasionally release full source code. There are a couple of reasons behind this:

Firstly, publishing big software projects is a commitment. I would have to sacrifice a lot of my free time, and it would become less fun. And I want to keep writing this blog fun.

How can it be extra work just to release something I already wrote anyway? Well, here's a few examples:

• Software is expected to work on different OS distributions, hardware configurations, and compiler versions. There is already plenty of dysfunctional software in the wild, and I wouldn't want to contribute to that.
• I must be legally allowed to release all parts of the software. A single snippet of copy-paste from a tutorial or example that has no licensing information means I cannot release the software.
• Published code has to be well-documented, preferably in English which is not my first language. Manuals and usage help should be up to date and internally consistent.
• User input should be validated and all possible errors and exceptions should be foreseen and handled. "Dirty hacks" should be avoided.
• Once published, software needs to be maintained to work with current libraries and operating systems, and for possible portability and security issues.
• Users require support. I wouldn't want to leave my users without support.

Also, I feel partly responsible for things people do with my tools.

Instead of source code I prefer to share ideas, blog posts, diagrams, flow charts, algorithms; this is much more portable.

However, I have published many of my command-line tools on GitHub. These include:

• redsea, an RDS decoder that aims to be fast and light-weight while still supporting most if not all RDS features.
• deinvert, for descrambling a type of voice encryption known as voice inversion scrambling.
• darc2json, for receiving DARC carriers. At the moment it only supports a few types of data packets.
• squelch, a noise gate to facilitate RLE compression of PCM signals.

Are you a hacker that can break into computers?

No. I used the word 'hacker' half-jokingly in a blog post because I reverse engineered a simple cipher that mentioned the word in its specification. I then decided to embrace the term for some time, because 'hacker' can also mean someone who does 'hacks', i.e. weird solutions to technical problems. People who build weird little electronic circuits can be called 'hardware hackers', and so on.

However, it unfortunately causes a common confusion with a more popular meaning: infosec people (security researchers) can also be called 'hackers', even though they do quite a different kind of thing, and are even professionals at that. Also, it often refers to computer criminals. Security research isn't really my forte, and I don't want to claim otherwise by using that term.

There's a Wikipedia article that discusses these definitions.

Will you decode this signal / write this program for me?

Currently I don't accept commissions.

What are you working on right now?

I always have some posts as drafts, but there are no rigid plans or schedules. When the blog starts to become a burden I take pauses of several months – even years – to think about other things. These would be outside the subject matter of this blog.

For example, I make sleepy music (EP on Spotify). I also like bike rides, gaming, and making 3D art.

What's that weird länguääge?

It's Finnish, the official language where I live and also my native language. Later I've learned English, Swedish, some Estonian, and the absolute basics of German and French. By the way, languages are fun, and it's actually never too late to start learning. You can start right now. Look up an online newspaper in the language you wish to learn, and try to read an article with a dictionary in another tab. Make a note of every new word you encounter. You'll learn quicker than you'd think!

How is your name pronounced?

Take the 'oo' from 'door' and the 'na' from 'Anna'. Then put them together. I absolutely won't be offended if you adapt the sounds to your language. For reference, here's a classic meme clip where the name is mentioned several times. It's from Salatut Elämät.

I have questions!

I'm on ask.fm.