The TransistoriZed logo should be here! But... curses! Your browser does not support SVG!

homelist of postsdocsγ ~> e-about & FAQ

Mechanical combination locks

My new "home" has an idiotic mechanical combination lock at the entrance. One lucky evening I had to spend a few hours outside due to a pure mechanical failure of the lock shown below.

Such primitive and low-reliability mechanical locking systems seem to be used everywhere in England. This made me think how fast can one possibly crack such a lock, provided that he needs very strong fingers and about 5 seconds to type the code in.

For a long time I was thinking that the combinations of a standard mechanical 4-digit lock are not that many because no consecutive digits can be used due to a limitation of the mechanical mechanism. Writing out this trivial solution:

1. The first digit can be from 0 to 9 so we have 10 possibilities.

2. The latter digits until the fourth can be from 0 to 9 but should not repeat with the previous digit, so we have 9 possibilities for all the rest.

We therefore end up with all possible combinations being: $$10\times 9\times 9\times 9 = 7290$$ An intuitive engineering thinking this times did not fail dramatically as after calming down I was imagining about $\frac{2}{3}$ of all the possible combinations which are 10000. If one masters a good code punching technique then $$7290\times 5 \text{sec} = 607 \text{h} = 25 \text{days}$$

At the end of the day, maybe electronic locks are more vulnerable to elegant cracking techniques as compared to their mechanical siblings.

Date:Tue Oct 05 22:11:17 CEST 2014


A strategy for the RTTY receiver implementation

I recently had some spare time to think about the RTTY receiver/decoder I would like to implement. My inital attempt for recovering the FSK bits from an input FSK sample stream was to perform a DFT with window's length roughly equal to the bit burst time of the transmitter. This approach however seems to be extremely inefficient, as the brute force DFT loop I had was too slow. In addition some sort of periodic synchronization is required, as otherwise a single sample mismatch between the input stream and the DFT window would lead to dis-synchronization and potentially wrongly recovered stream bits.

The FFT-based idea above also seems impractical for real applications where we have burst time mismatch and noise. Instead of going forward in the f-domain, one can easily try to filter out specific frequencies and then try to correlate and compare both for the bit recovery. Here is a picture of my receiver implementation thoughts. Apparently this has been a quite common approach in the old QPSK dial-up modem chips.

Now I have a plan for my spare time in the future... one bright and lucky day:

1. Implement a function with single pole LP and HP filters in series.

2. Implement a power/summation/LPF function with zero cross detection.

3. A self-syncing bit-recovery block function.

4. A look-up table translation function.

5. Test all above with a real FSK stream (recorded from a radio transmission /w noise)

6. Glue the TX and RX functions together in a more functional form.

Come to think of it, all this starts to more and more look like a Lab 0 task of a typical Signals and systems course. Well, bar the fact that I am trying to write this in C to avoid cathing rust.

Date:Tue Oct 05 15:17:23 CEST 2014


Inspiring 13-17 y.o. high school students to take the engineering path

I was recently invited to say some "inspiring" words to high school students in Varna (the largest sea port town in Bulgaria). The whole idea of the event was to provoke some thinking from the kids' side and act somehow as a career guide.

The moment I accepted the invitation, I knew that drawing their attention on electronics/microchips would be a very hard task. Being able to give clear explanations, especially about high-level (general) electrical engineering topics is an art that not every engineer can master. I brought some PCBs, demonstrated an FM radio transmission, gave some explanations about time clocks and where the clocks usually get their 1Hz reference from, demonstrated some applications of microcontrollers and their connection with internet, but somehow I felt that the kids were not inspired enough. Here are my pre-demo slides, hopefully someone can give me some criticism. No matter how much I like Latex, beamer seems to be a horribly boring solution for the current purporse.

How can one explain best what electrical engineering is about?

Date:Tue Sep 29 20:52:18 EEST 2014


Reading raw PCM data files into an array in ANSI C

I am working on the Rx part of the RTTY decoder. The first stage to start with is to find a way to read the encoded by the Tx in my previous post raw PCM file and dump it into an array. A natural act was to look online for already existing code for reading little endian 16-bit raw PCM files, to my surprise a lot about PCM is written out there, but strangely nothing in pure ANSI C which is small and selfcontained enough to be copied and used directly. An equivalent in function ANSI C code I am posting here probably exists out there online, but I will anyway print my implementation here, hopefully anyone would benefit from it. It is also a good way of storing it here for my own reference.

// Reads raw PCM file format and prints the samples in signed integer format on the standard output.
// Initial version A, Deyan Levski,, 15.07.2014

#include stdio.h
#include stdlib.h
#include math.h
#include string.h

#define SAMPLE_RATE 44100 // Hz
#define BITS_PER_SAMPLE 16 // bits
#define N_SAMPLES 5000 // n

int convertBitSize(unsigned int in, int bps)
        const unsigned int max = (1 << (bps-1)) - 1;
        return in > max ? in - (max<<1) : in;

int readPCM(int *data, unsigned int samp_rate, unsigned int bits_per_samp, unsigned int num_samp)

	FILE *fp;
	unsigned char buf;
	unsigned int i, j;

	fp = fopen("ttyburst.pcm", "r");

        for (i=0; i < num_samp; ++i) {

		unsigned int tmp = 0;

		for (j=0; j != bits_per_samp; j+=8) {
			fread(&buf, 1, 1, fp);
			tmp += buf << j;

		data[i] = convertBitSize(tmp, bits_per_samp);


int main(void)


	int *data = (int *) malloc(N_SAMPLES * sizeof(int));


	unsigned int i;
	for (i = 0; i < N_SAMPLES; ++i) {
		printf("%d\n", data[i]);

return 0;


Compiles without errors on a standard gcc compiler with standard ANSI C option set. When run, the executable would look for ttyburst.pcm in the root folder and print all samples on the standard output. The raw PCM is assumed to be little endian, signed 16 bit, sampling rate and number of samples are set with the #define statements. Other formats can be supported with minor code modifications.

Date:Tue Jul 15 22:19:53 CEST 2014


Baudot/Murray/ITA2 codes

This post is a proof that losing internet for some time can in fact boost your productivity. Or at least it made me go back to an old and well forgotten project of mine. Back in ?2005? I was very excited about acquiring an MW or HW band transciever and trying get in contact with some radio amateurs. Unfortunately I only ended up experimenting with my home-made pirate FM 88-108 MHz transmitter hooking it up to my PC's sound card and using some radio amateur PSK bursting software to transmit text to another PC, which's sound card was connected to an FM receiver. It did actually work pretty well, tranferring data at about 300~600 baud.

As I do not have internet for a while now, I have decided to spend some time on home-made FSK encoding program. I know there is a plenty of choice when it comes to radio amateur software, but this helped me to slightly rub-off my rust in C and have some fun too.

Baudot/Murray/ITA2 codes, also commonly referred to as five-unit codes are practically the second evolution of the Morse code and were extensively used back in the old days in telegrapy, systems also known as TELEX, machine programming/execution punched cards and many other ingenious well forgotten systems nowadays. Basically a five-bit code is used for alphabet encoding. Apart from the standard (capital letter only) alphabet characters, these systems include also some special symbols as, carriage return, line feed, blank etc...

This page is a good source giving a brief overview of the ITA2 system, however for convenience I am listing the ITA2 (International Telegraph Agency 2) encoding table I used here:

Character 5-bit encoding Character 5-bit encoding
A 11000 B 10011
C 01110 D 10010
E 10000 F 10110
G 01011 H 00101
I 01100 J 11010
K 11110 L 01001
M 00111 N 00110
O 00011 P 01101
Q 11101 R 01010
S 10100 T 00001
U 11100 V 01111
W 11001 X 10111
Y 10101 Z 10001
CR 00010 SPACE 00100
Parts of the ITA2 encoding standard.

In order to be able to distinguish between the character bit-bursts however the teletype systems use start and stop bit sequences. I found various sources online, which suggest different bit sequences. The ones I have used are based on the information provided by this website. As I am not going to contact anyone I didn't really care so much about that. The following image shows a single character burst including start and stop bits. In my program the used start bit is "zero" and as a stop bit I use "one".

Baudot RTTY burst example, as shown in a number of radio-amateur websites.

The most common transmission scheme in the HF amateur bands for RTTY (Radio Teletype) is FSK. This is practically what all the amateur software encpding programs do, read text and "play" FSK bursts encoded in Baudot, when speaking about RTTY of course :). This is what my rusty program also does. Hear some burst examples:

Transmitting the string "I WILL BE BACK HOME SOON PLEASE LEAVE SOME WATER MELONS PEACHES APPRICOTS PLUMS AND GRAPES FOR ME TOO" using 10ms bit bursts with non-integer related shift frequencies (notice the hum/harmonics)
Transmitting the same string but with integer-related shift keying frequencies.
Transmitting the same string but at 100ms burst time.

You might hear the odd low frequency hum in one of the very short burst time samples. This apparently is caused by incorrect stitching of the dual tone sinewaves and can be fixed with proper tuning of the burst time and choice of frequencies such that no "odd stitching effect" appears anymore. Here is what "d-effect" I am referring to:

Sinewave "stitching d-effect" causing discontinuity and therefore harmonics and hum.

This can be fixed by choosing shift keying frequencies together with burst lengths which are integer numbers, for example, $$\frac{f_{FSK_{1}}}{f_{FSK_{2}}} = int$$

Stitching problem solved by using integer proportion shift keying sines, note there is still an issue.

There is still an inssue with my algorithm, I need to delete the last sample of the FSK sine before stitching the new sine, as now there are two repeating samples, which ideally should be one.

I am posting the source as well as the compiled program here, however I should warn you that the code is not very tidy nor efficient. I am basically generating a PCM file, which I then open with and listen to with audacity. I found this to be simplest and most painless format to use.

When importing the PCM you should use signed 16-bit mono, little-endian bit order settings. You can define the sampling frequency from the program, the default used in the precompiled program is 44.1 kHz, however you can choose your own, you will see also some self-explanatory definitions for ZERO_FREQUENCY, ONE_FREQUENCY, SAMPLING_FREQUENCY, BURST_LENGTH etc... The program is reading from a text file named xmit.txt and treats carriage returns as blank space. The file length is also controlled by the MAXTEXTLEN definition.

Link to ttygen and the source code.

Now a question arises, why is it always easier to build a transmitter than a receiver?. In pretty much every aspect in electronics, when you have to deal with transmitters/receivers it is almost always the case that the transmitter is easier to build. Now I have a new project idea, let's write some code which "receives" and decodes these generated transmission sequences ...

Maybe the next time my internet connection drops.

Date:Sun Jul 05 23:02:00 CEST 2014