User:Bertrik Sikken

From RevSpace
Revision as of 09:03, 10 June 2017 by Bertrik Sikken (talk | contribs) (Fix heading level)
Jump to navigation Jump to search
User info Bertrik Sikken
Name Bertrik Sikken
Nick bertrik
Tagline heb ik niet

You can reach me at or

Studied Electrical Engineering at Twente University.

Main interests:

  • reverse-engineering things (USB stuff, mp3 players), working on
  • studying bats and making electronics for recording/listening to bat sounds
  • radio stuff, in particular software-defined radio

Projects I work(ed) on (refresh):

 Project Status
Pico TrackersAbandoned
Secure iButtonCompleted
AntiLostIn progress
CJMCU-811In progress
DecodingLoraIn progress
EspAudioSensorIn progress
Esp32camIn progress
EncodingLoraIn progress
ISSOIn progress
LoraWanDustSensorIn progress
RC522HackingIn progress
RevRadioIn progress
STM32In progress
StereoBatRecorderIn progress
StofAnanasIn progress
StofradarIn progress
UltrasonicPlayerIn progress

Project ideas

This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.

Understand Bluetooth AP

I'm trying to understand how to set up a bluetooth AP on a basic Linux system, such that you can connect to it using an Android phone or tablet.

The idea is that there is some kind of useful application running on the Linux system, and that the "app" on the tablet/phone provides the user interface, connecting to the Linux system using REST.

Possible useful links:

My starting point is:

  • a Yocto based Linux distribution
  • a Linux 4.1 kernel
  • Bluez 5

Understanding the various Linux drivers and tools in the Linux bluetooth stack

  • btusb: the Linux kernel driver module for many USB/bluetooth adapters, 'modprobe'-ing this module also magically takes care of downloading firmware needed
  • hciconfig, low-level configuration utility for manipulating a bluetooth controller. A bit like ifconfig, it can bring the interface up or down, set options, etc.
  • hcitool, yet another utility to perform low-level bluetooth operations, like querying the name of paired devices
  • bluetoothd, the bluetooth daemon
    • /etc/bluetooth/main.conf : supposedly (one of) the configuration files for bluetoothd
    • bluetoothd can be accessed over DBUS apparently, see Bluez docs
  • bluetoothctl, a more high-level configuration utility, basically a command line user interface towards bluetoothd as I understand it.

And some acronyms:

  • NAP: network access protocol
  • PAN: personal area network
  • BNEP: bluetooth network encapsulation protocol

Getting somewhere: ?

investigate quadcopter remote control

It turns out that the typical little cheap Chinese quadcopters use a remote-control protocol that can be easily recreated using the famous NRF24L01+ chip (< $1 and easily connected to an arduino). This gives nice opportunity to either:

  1. transmit our own control signal, to control a quadcopter from something different than the manual remote control, e.g. automatic control
  2. receive the control signal, so the manual remote control that comes with a quadcopter can be used to steer other things (like a model car).

I haven't found a good overview of quadcopter remote control protocol specifications yet, there seem to be plenty examples of "here-is-the-code" however.

mini word clock in dutch

Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.

This git repo has the current code.

See here for a demo running on an arduino nano.

The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP. The time offset will be fixed to Dutch local time, i.e. GMT+1 taking into account summer time. Summer time will be determined using the general rule "from 2:00 local time on the last sunday of March until 3:00 local time on the last sunday of October".

Local date calculation:

Understanding LoRa

Ultimate goal is to create an SDR algorithm to decode LoRa without the need for dedicated LoRa hardware. This could be useful when tracking HABs transmitting LoRa for example. See DecodingLora and EncodingLora.

In particular, I should definitely check out this gr-lora project. Perhaps make it work for decoding balloon telemetry modes.

Cypress PSOC5

Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See RadarOnAStick.

Simple Doppler motion sensors

You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example

Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg. The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.

See also for a reverse engineering effort of these doppler radar modules.


Investigate the rust language.


I have a Wemos "LOLIN32 V1.0.0" ESP32 board, play with it. Discover Bluetooth capabilities, low power modes. Compare it with ESP8266.

Bare-bones Arduino bat detector

This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.

The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.

Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal. So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.

How this can be done in an AVR Arduino:

  • sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.
  • apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.
  • multiply by the detection frequency, this means just inverting the odd samples.
  • low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.
  • output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.

The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz). The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain. The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range. The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.

AVR Arduino sample rate

As far as I understand, the ADC clock can be set to 1 MHz. Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.

Example C code

(this is the general idea, but I don't know if it compiles):

#define BUF_SIZE    16

static void ISR(void)
    static int16_t buffer[BUF_SIZE];
    static int16_t lowpass = 0;
    static int32_t sum = 0;
    static bool even = false;

    int16_t input, signal, mixed;

    // sample signal as 16 bits (10 bits significant)
    input = ....

    // HPF input signal
    signal = input - lowpass;
    lowpass += signal >> 4;

    // multiply by carrier
    mixed = even ? signal : -signal;
    even = !even;

    // calculate moving average sum
    sum += mixed ;
    sum -= buffer[index];
    buffer[index] = mixed ;
    index = (index + 1) % BUF_SIZE;

    // output LPF as 8-bit number
    out = sum >> 7;

ADS-B multilateration

This idea is about determining position of aircraft that don't transmit GPS position themselves.

Many commercial aircraft transmit ADS-B/MODE-S signals containing all kinds of interesting information: aircraft id, altitude, flight number, speed, heading and position. This way you can plot the trajectory of aircraft on a map and get an interesting view of the air traffic around. The arrival of cheap software-defined-radios like the rtl-sdr made it possible for everyone to receive these signals.

Typically, small aircraft like single-engine air planes and helicopters do not transmit the position information, only the aircraft id, altitude and sometimes flight number. Websites like flightradar24 receive information about these small aircraft from many different receivers, and can infer the position by multilateration. Mulitlateration means that the position can be calculated from the relative delay that the ADS-B signal arrived at the different receiver stations (the radio signal moves at the speed of light!). The required accurate time synchronisation needed for this can be calculated in a smart way from the ADS-B signals themselves.

As far as I know, there is no open-source implementation of this.

Stuff needed for this to work:

  • receiver stations at diverse locations are needed, so you get a good 'constellation' receiving aircraft signals from many different angles
  • each receiver station should be able to time-stamp the ADS-B signals it receives. It doesn't really matter if it is accurate in an absolute sense, just needs a certain time resolution.
    • so we need a common convention on how/what to time-stamp ADS-B, take something that is present in each message, e.g. the exact instant that the first bit of the ICAO address is transmitted
  • about time resolution: radio signals move at the speed of light; one sample at 2 Mbps sample rate is 0.5 microsecond, representing a distance of 150m.
  • a central server receives all the ADS-B signals from the multiple receiver stations
    • it matches up the same message from different receivers, knows where each receiver is, and performs the multilateration calculation
    • it continually monitors the time offset of each receiver, by comparing timestamps from ADS-B message that DO contain GPS information
    • since rtl-sdr receivers drift like crazy (up to 100 ppm), the server probably also needs to estimate the drift rate of each receiver. At 100ppm, a one second old timestamp could already be off by 100 us, or 30km!
  • some kind of network protocol to get all the ADS-B data from each receiver to the central server