Paper: Evaluating_GSM_hopping_V1.2.pdf

github source code for hopping airprobe: https://github.com/BogdanDIA/airprobe-hopping

I thought I should put my USRP at work and also exercise some of the gnuradio features that I plan to use in the future.

I got interested by the GSM security reading some of the stories about GSM A5/1 and how it has been cracked by some smart guys. I knew about Airprobe and the fact that it does not have support for GSM hopping channels and I thought that adding support for that will help the community to advance the research in the security on this matter.

That was it and after couple of weeks of work the support for hopping channels in Airprobe is ready. There are many things to do in order to make it fully automatic but the whole point is to use it for security research not for unattended use.

I captured the whole story in the following paper, the source is available as patches to Airprobe here: Evaluating_GSM_hopping, Evaluating_GSM_hopping_V1.1.pdf, Evaluating_GSM_hopping_V1.2

Patches for airprobe: airprobe_hopping.tgz

Very important note: One some machines the pfb check for N/i oversampling ratio does not work. You will get the following error:

RuntimeError: gr_pfb_channelizer: oversample rate must be N/i for i in [1, N].

The only fix I have for now is commenting the check in  gr-filter/lib/pfb_channelizer_ccf_impl.cc and rebuilding gnuradio:

//if(fltp != 0.0)

//throw std::invalid_argument(“pfb_channelizer: oversample rate must be N/i for i in [1, N]”);

LE: seems on gnuradio 3.7 this does not happen anymore

Couple of months ago I bought an USRP N210 from Ettus research (www.ettus.com) and since then I did not have time to test what it can do until today. I have big plans with this SDR and another one I also own – QS1R but today I will tell only about this fine hardware which is USRP N210.

The above picture shows USRP N210 with RFX900 board, Basic RX and Basic TX boards. Inside is already mounted the WBX board. Here are the frequencyes:

WBX – 50Mhz to 2.2Ghz, one Rx, one Tx – 100mW output

RFX900 – 800Mhz to 1Ghz, one Rx, one TX – 200+mW output

Basic RX, Basic TX – made to be interfaced with external RF hardware

What I am going to use USRP N210 for?

I am interested in the use of SDR for Tetra decoding, GSM decoding, Radar, what else? The ADC and DAC of the boards have 100Msps which gives pretty good spectrum bandwidth. It’s amazing how many people use this SDR and how many applications are out there on the web so I decided to test couple of them before starting to change the FPGA and firmware. The good news are that Matlab can work direct with USRP N210. This is really great news.

The board works great in conjunction with GNUradio (www.gnuradio.org) open source software and uses the new UHD (Universal Hardware Driver). Some of the applications one could find on the web are written for non-UHD USRP and do need converting to UHD.

I decided to see what I can run in a day of weekend so here it is: OpenBTS – an open source GSM software. And a WFM receiver as a plus. I won’t go into details on what I did to configure various bits since everything worked out of the box without too much tweaking. Though, I’ll point out only where documentation is available on the web so that you’ll have the starting point.

1. Need 1Gbps network card in your PC. The USRP N210 comes with address 192.168.10.2. Then configured the PC eth to have IP 192.168.10.1, netmask 255.255.255.0

2. Installing UHD driver from git: http://code.ettus.com/redmine/ettus/projects/uhd/wiki

Test if USRP N210 is found with find_uhd_devices. It won’t show the serial number unless you install latest firmware.

3. Installed the latest FW and FPGA images with usrp_n2xx_net_burner.py

test the connection with uhd_find_devices and uhd_usrp_probe

4. Installed gnuradio: www.gnuradio.org

You need to satisfy all dependencies in order to be able to run GRC examples.

5. Installed OpenBTS-uhd: http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSUHD

6. Installed Asterisk (I’m using Ubuntu 10.04) and added all Asterisk configs from OpenBTS to /etc/asterisk/

7. Run Asterisk, OpenBTS, smqueue. Searching manually for GSM network I discovered a new network ( I used ARFCN 51 on GSM900 band). Connected to the network.

8. Found my phones IMSI: sent a SMS message to 411 and got the replay with phone’s IMSI.

9. Add a phone number to the related IMSI in the sip.conf and add a SIP rule in the extensions.conf

10. Now when I send an empty SMS to 411 I get also the phone number together with IMSI.

11. To verify that phone is connected to the network send a SMS to 101 with the phone number in the body. You’ll get a replay saying the phone is registered.

12. Now I’m able to do phone calls and SMSs between the two phones I have with the arbitrarily chosen numbers 2101 and 2102.

13. To be able to see various GSM messages on the Um interface I installed latest version of wireshark which knows gsmtap and is able to show what USRP board transmits and receives.

OpenBTS is a nice tool to play with even though it is not production ready. It helps me a lot in learning how GSM is working.

One tool used together with USRP N210 was Kalibrate which not only helps in calibrating the USRP clocks by using the neighbor networks but also scans the local environment and prints what it finds:

kal -s 900

GSM-900:

chan: 18 (938.6MHZ + 14.186kHz) power 18032.11

chan: 22(939.4Mhz + 14.288kHz) power 3554.23

FM radio test

Gnuradio comes with a graphical IDE called GRC (Gnuradio Companion) that will speed-up the process of creating various SDR projects. I found out OZ9AEC page (http://www.oz9aec.net/index.php/gnu-radio/grc-examples) where couple of working GRC examples are presented. They are also converted to UHD so it is just a matter of running GRC to see what’s all about. One comment about the GRC: when building gnuradio one needs to bring in all the dependencies so that all Vx and Qt widgets will be in the release.  Here are the screen shots with a FM receiver implemented in GRC:

As a conclusion, I like this new USRP N210 and as I said I’m planning to write a lot of code for it to implement my ideas. One thing on the down side is that in order to build the FPGA image one needs a tool from Altera that is not free and if you add this to the price of the board … On the good size I would love the openess of gnuradio, the integration with Matlab and the options that Ettus offers through their large list of daughter cards.

I’m so busy with the projects now that I’m not able to write anything on the blog. That’s why I thought I should post some pictures only. I worked at some point for almost 6 years for a Danish company called Bang&Olufsen doing high end audio video products. The experience was incredible. The filling that there is a product made with your hands that people will use for many years and also will pay a lot of money for 🙂 cannot be told. Enjoy the museum:

I’m running a project together with YO3KSR ham radio club in Bucharest. It aims at running app_rpt on an small WL500 router in order to make radio-VoIP-radio network. In the picture below one could see a router connected with a GM300 rig and the power supply for the rig. This article is just a short list of information on how to replicate the solution.

The router

It’s actually a WL500 Deluxe board together with a GPRS board (not used in this project) in a different box. It’s sold as Topex BYTTON GPRS.

The connections

Three USB connections are used:

– USB sound card – I’m using CM108 based card as of now but you may try a different card because I use chan_alsaradio driver.

– Mass storage flash card

– USB to RS232 converter for signaling (PTT and COR) – I’m not using the GPIO pins on the CM108 card because the requirement was to be able to use any kind of the USB sound cards that may not have GPIO pins.

The order of physical USB ports is important, it should be like in the picture. Otherwise you need to adjust configuration files.

Here is the connection board schematics for the PTT and COR:

The software:

The application is made to run on OpenWRT 10.03. You need to install it before attempting to install app_rpt.

Since the board has so less flash memory (4MB),  the USB flash drive is used to keep the new root filesystem.  In order to boot from flash drive you need to replace /sbin/init on your onboard flash filesystem with the following script: init. The script will switch from on-board flash root to the root mounted from USB flash drive.

Download the new root filesystem: from here

You need to make two partitions on the flash drive:

1. swap (~100M)

2. ext3 (the rest) – copy the content of the archive on this partition

Adjusting various bits:

Accessing the system after mounting USB root filesystem(user root, password admin): ssh root@192.168.1.3

Changing the default IP address (192.168.1.3): use your web browser and access the LuCI interface: http://192.168.1.3

Adjusting audio levels: after you login with ssh use “alsamixer -V all”

Changing default node number (27237) and relation between node number and IP address: modify node number in /etc/asterisk/rpt.conf, and node number and IP in /usr/lib/asterisk/rpt_extnodes .

Inverting PTT signal: set invertptt=1 in /etc/asterisk/alsaradio.conf

Inverting COR signal: set carrierfrom=serialdsr or serialdsrinvert in /etc/asterisk/alsaradio.conf

Using the system:

Suppose you have two systems, first one with node number 27111 and the second with node number 27222. In order to dial from one node (27111) to the other:

*327222 from node 27111.

To disconnect: *127222.

You could configure and use any options app_rpt has.

Overclocking the router:

If the sound is chopped you may try to overclock the router . DO IT AT YOUR OWN RISKS!

For WL500 Deluxe:

nvram set clkfreq=264,132

nvram commit

reboot

I hope this is enough for someone to get started.

73, YO3IIU

Just in a discussion with a fellow motorcyclist, I found out that people wants to send Twitter messages (to tweet – a new verb 🙂 ) from various kind of devices like PDA-s, phones, radios. Knowing that APRS could be used to send short messages that are even shorter than Twitter ones made me think why shouldn’t I make an application to allow ham radio enthusiasts  sending APRS messages to its own Twitter account? This seemed to be an easy task, just couple of days of work. For the impatients here is the link to what you need:

http://www.yo3iiu.ro/twitter.html

I’ve seen two sub tasks to accomplish the main task of sending the message from Twitter to APRS: Authentication and Message passing between the two networks.

There are some differences between Twitter and APRS when talking about authentication. APRS has no authentication, Twitter has a good authentication as of 2010, OAuth.

The message passing is easily accomplished once the authentication is done, the application needs just to listen to a connection to one of the main APRS-IS servers and when receiving a message, will send it to Twitter server.

How it works:

Authentication is done on a perl CGI that receives user’s callsign and then proceed to authentication with Twitter. You’ll be asked to accept access from APRS to Tweet application. Once the authentication is finished, the user callsign and its Twitter OAuth tokens are stored in a local database. Remember that OAuth does not know at any time your Twitter user and password, therefore no such info is stored on the server.

Sending the message to Twitter is simple: you send the message from APRS to callsign YO3IIU-11 and it is mandatory that the message have “tweet:” included at the beginning of the message. Otherwise the message will be rejected. It is designed like this just to filter broadcast messages that will come to YO3IIU-11.

That’s all folks,

73, YO3IIU

Looking on the APRS Google map one could see that there are not so many weather stations in Romania that hams could use.  Knowing that weather data could be gathered form the airports around the country, I decided to make possible that radioamateurs could use METAR weather information through APRS.

The idea is to make weather stations showing on the APRS map, presenting the METAR data. As one could see further down this article, not all METAR information could be sent through APRS but only the more interesting ones. The software will be presented and provided as open source package under GNU GPL license. The language used is C since the intention is to run the application on small, low power embedded Linux systems like home routers.

Couple of words about METAR, APRS and weather:

It seems to be gathering a large consensus that METAR come from french phrase:  message d’observation météorologique pour l’aviation régulière.

METAR is a way (one could say protocol) to convey weather information mainly for pilots use during pre-flight briefing. However, it is also used in other situations like moving weather data from one point to the other. It could contain many data fields that a pilot may be interested in like temperature, dew point, barometric pressure, visibility, wind speed and direction, runway visibility, etc.

APRS means Automatic Packet Reporting System and is a trademark of Bob Bruniga. It is a protocol able to convey various kind of information over AX25 protocol with primarily target being the radio networks.  Therefore APRS is a layer 3 OSI protocol over AX25 link layer. It uses AX25 somehow different in some details I will explain below.

Weather APRS message could include Latitude and Longitude, Wind direction/ Wind speed, Wind gusts speed, temperature, rain, last hour, rain last 24 hours, rain since midnight, humidity, barometric pressure.  Beside those information it could include a timestamp and possible some other arbitrarily message.

Looking at METAR and APRS weather messages one could see that some conversions are needed beside the fact that not all METAR information could fit in the APRS message. One example of such conversion is the wind speed which in METAR could be given in mph, knots, kmph but in APRS they should be given as mph.

Another mismatch between METAR and APRS is that METAR seems not to provide relative humidity (RH), therefore one need to calculate the RH from temperature and dew point. I used Magnus-Tetens formula to calculate RH and since it needs some floating point arithmetic it will need to be adapted when  running on embedded systems without hardware/software floating point.

The weather stations are identified using IDs given by different authorities. For example there could be ICAO (International Civil Aviation Organization) which is four letters ID (e.g. LROP) and WMO (World Meteorological Organization) which is a 5 digit number ID. Unfortunately, only weather data from stations having ICAO ID is provided on the NoAA servers (National Oceanic and Atmospheric Administration) in US. I would very much like to know how to access the data from stations listed only with WMO ID.

Being able to add text message to the normal APRS weather message made me add some more information from METAR like DEW point, prevail visibility and whether is CAVOK or not. CAVOK means Ceiling And Visibility OK.

How metarAPRS program works:

In short, the program accesses the NoAA ftp server, gets the latest METAR data from there, converts the relevant fields to APRS and sends it to the local PC Ax25 stack or directly to APRS-IS servers. When using the AX25 stack, the weather data could be output to a radio and when using APRS-IS servers connection, the data is fed directly to the servers through a TCP/IP connection.

A typical METAR message looks like:

date: 2010/10/31 14:30
METAR: LRBM 311430Z 00000KT CAVOK 14/02 Q1018

metarAPRS program has a configuration file ~/.metar-aprs/data.csv which needs to have listed all the station one needs to show on the APRS map. The ID (callsign in APRS parlance) of the station could be entered and also the position of the station needs to be added since it is not given by the METAR data. However, the position could be obtained by using following link: www.nws.noaa.gov/tg/siteloc.shtml

A typical line in the configuration file looks like this:

LRBM-1, LRBM, 4740.00N/02335.00E – where LRBM-1 is the APRS callsign given to the station and LRBM is the ICAO ID for the station.

System configuration for metarAPRS:

If using a direct connection to one APRS-IS server, there is no need for an IGate. Just the proper command line options needs to be given. For example if one need to connect to the server france.aprs2.net:14580, using password “1234” and callsign YO3IIU-10, the following command needs to be given:

metarAPRS -s france.aprs2.net -n 14580 -w 1234 -c YO3IIU-10

If want to use ax25 option in order to send the weather to a radio connected to your system, one needs to have an AX25 port configured. It is done by having axports (/etc/ax25/axports) filled in with the needed information (see man axports for details). For example, this is one line my axports file has:

sm0 YO3IIU 9600 256 7 144.800 APRS (9600 bps)

The port is sm0 and the callsign of the interface in this case is YO3IIU.

Now you need to initialize the port:

kissattach /dev/ttyS0 sm0 192.168.1.200

If all went smoothly you will see an interface called ax0 when listing existing interfaces on your system.

If you’ve already used soundmodem then you don’t need to do anything since the Ax25 is already configured.

Using an IGate:

One could use any IGate he/she has access to. I use aprsd but the most interesting application is XASTIR (www.xastir.org). It is not an IGate “per se” but it has this functionality among other features I like at it.  One of the best features it has is the ability to use the OSM (Open Street Maps) – www.openstreetmap.org directly in it’s latest version from svn.

For XASTIR you need to configure one internet interface and one Ax25 TNC interface with sm0 as port.

Options for metarPRS:

I’ve added couple of command line options to the program and they could be seen in the help.

$ metarAPRS –help
Usage: metar-aprs [OPTONS]

-h –help                  help
-V –verbose          verbose
-v –version            version
-p –port                   port
-d –destination    destination (default IDENT)
-i –interval             interval (minutes)
-a –ax25                  use ax25 stack instead of direct connection
-s –server                APRS-IS server name
-n –server-port     APRS-IS server port
-w –pass                   APRS-IS server password
-c –callsign             callsign used for server login

Practical results:

Screen shot of one METAR weather station when using the direct server connection ( you could see the TCPIP*,qAS construct which means data comes from a direct connection):

Screen shot of the same METAR weather station when using Ax25 stack. The data now comes from a radio link (see the qAR construct):

After setting data file, configuring the Ax25 and the IGate, one will just need to run metarAPRS. Here are some screenshots with METAR weather stations showing on APRS map in both web browser and XASTIR:

Screenshot showing the wisibility data:

XASTIR screenshot with Open Street Map:

Things TODO:

– use other sources of weather data (what about WMO source or RSS feed?)

– find a way to show more data

– daemonize the application

Source code released as Open Source under GNU GPL license:

metarAPRS application sourcecode (v01): metarAPRS.tar.gz

metarAPRS application sourcecode (v02): metarAPRS_02.tar.gz

metarAPRS application sourcecode (v03): metarAPRS_03.tar.gz

In the previous DCS article I presented a general overview of the technology together with the problems that an implementer of the decoder may fight with. In this article I will present the functional blocks of the decoder and how they interact each other. The complete information could be gathered from the implementation which is presented as open source packages in the end of the article.

Building blocks:

The goal of the project was set to decode the DCS signal in noisy conditions, having distorted signal and accepting a broad range of audio volume level. In the following sub-chapters each block is presented.

Aquisition of signal

ALSA is used for aquisition of signal at the sampling rate of 8Khz and S16_LE format. Note that libdcscodec uses a buffer as input and does not depend on ALSA or other input method. The acquired signal is looking like in the following picture:

LP Filter

The Low Pass Filter is implemented as a FIR filter and is designed using Parks-McClellan algorithm for optimum approximation of a generalized linear phase systems. Basically the algorithm aims for equiripple in both passband and stopband of the filter. The filter is designed to have maximum ripple as 0.5dB and 60dB attenuation in stopband. Giving this numbers together with the Fp=84.4Hz and Fs=134.4hz, parks McClellan algorithm will calculate a filter with order n=357 which is quite high and therefore the filter is a Type II FIR filter.

The signal after LP filtering is presented below:

DC filter

This filter is actually a combination of a differentiator followed by an integrator having therefore the differential equation like the following: y(t) = x(t) – x(t-1) +ay(t-1).  Its need comes from the observation that the signal from the receiver seems to be shifted up or below the zero level line. The coefficient a could be tweaked in order to adjust to the cut-on frequency.

Resample

Just to recap the input data we have, the sampling frequency is 8khz and the DCS signal has a rate of 134.4Hz. In order to correctly process the data and be able to find the moments when a switch from “0” to “1” and “1” to “0” is done, we must have a sampling frequency which is multiple of the 134.4Hz rate. That is why resampling is needed and the resampled rate is chosen 8*134.4Hz. Therefore we will have 8 samples per symbol. Resampling has been implemented using the SRC library which works very well and gives the proper results. However I plan to implement my own resampling function just to reduce the code size of the DCS codec.

Integrate and Dump

From the theory of digital communication it is know that a matched filter could be used to reduce the ISI (Inter Simbol Interference) and therefore to increase the BER. Integrate and dump is a simple matched filter that works by integrating (adding) the samples through a period, use the result, dump the result and then start all over. In our case the integration is done in a period of eight samples T=8*1/134.4[s] and therefore taking in consideration the new sampling frequency.

There is a discussion here regarding the start of the sampling period. In an optimum case the sampling period should have the peak of signal at its center so that the integrate and dump method should work proper. However, there is no clear start and stop for this integrating period and one big question arises: when to start the integrate period? Some methods have been developed for that among them being the “early late gate” which uses three samples in order to determine the proper start of the integrating period. However, what I’m currently doing is integrating the signal considering each of the 8th samples as starting point for the integration process. Each result of the integration will be sent to the detector algorithms and redundant data is eliminated. I know this is not optimum and this is one of the points to be changed in the near future.

AGC

One of the goals of making the DCS codec is to be able to use a broad range of audio volume level. This is important because the soundcard may have preamplifiers or dividers and also the radio receiver may output different audio level from discriminator. The AGC block is not properly an Automatic Gain Control but it is a mean to determine the threshold level above which the signal is considered to be a peak by the peak detector. The threshold level is calculated using the standard deviation (std) of a signal over the entire buffer.  See the source code for the implementation.

Peak detector

As previously stated, the peak detector is used to determine signal’s peaks and therefore the transition form “0” to “1” and “1” to “0”. Starting with a peak, the next peak should be at a time distance of k*1/134.4[s] with k being integer.  After the peak detector a bitstream of “0” and “1” will be output to the next processing block.

Golay decode

having the bitstream from peak detector as an input, this block does calculate the check bits taking in consideration the new arrived bit. If the calculated check bits match with the received check bits then we have a match and the corresponding Golay is looked up in a table containing all Golay codes.  The “standard” Golay code is taken from the table and then send to the next processing block.

Display of DCS code

This is simple console display of the DCS code. One more thing is done, due to the fact that polarity of the signal is not known by the software both positive and negative polarity codes are presented. It is users responsibility to decide which code to take in consideration. Normally the polarity should be communicated by the user of the transmitter.

Practical results

The tests were done using a Yaesu FT-857D as receiver and a Yaesu VX-7R portable as transmitter. All the above graphics were saved from the program and exported using gnuplot.

One interesting point to note regarding the VX-7R is when the portable is enabled as dual receive. It seems the DCS code it sends on transmission is the selected one together with another random code.

TODO

– optimize buffer utilization

– use own resampling method

– use early-late gate method for determining the proper start of integration

– implement transmitter

– optimize for embedded processors with no floating point

Sourcecode released as Open Source under GNU GPL license:

library that implements DCS codec – libdcscodec.tar.gz

test program for libdcscodec – dcscodec.tar.gz

libresample package needs to be installed in your system as it is a dependency.

Looking for a Digital Coded Squelch package that I could include in one of my projects I found out that there is no such package released for open source.  Looking for more information I found no DCS detailed information related to physical levels, how it is modulated etcaetera. Therefore I decided trying to implement a DCS codec that could be included as a library in any project. I present below the steps I followed in making the DCS codec library and the tests I’ve done for it.

Introduction

The DCS stands for Digital Coded Squelch and is a method of controlling the squelch of a radio by sending a digital code over the audio signal. It is a further development of the CTCSS method (Continuous Tone Coded Squelch System) ans it is called sometimes CDCSS (Continuous Digital Coded Squelch System). Various manufacturers calls this method different, for example Motorola (TM) calls it DPL (Digital Private Line), General Electric (TM) calls it DCG (Digital Channel Guard).

The DCS not only opens the squelch for a radio but it is also used to close the squelch before the carrier goes off in order to eliminate the squelch tail. It was an unfortunate decision to use the word “Private” on the squelch technologies because no privacy is added to the system when these are used. A lot of discussions were held regarding the “Private” meaning of these technologies many times ethical reasons being the major argument.

One will find on internet a lot of information about DCS including history and its preceding technologies but for what I needed I have found only two resources with valuable information. They are presented below:

http://onfreq.com/syntorx/dcs.html

http://mmi-comm.tripod.com/dcs.html

For short, DCS sends digital signals with 134.4Hz rate using golay (23, 12) codes over the audio signal. The golay (23, 12) means DCS uses 23 bit words with 12 bit data included the 23 bits.  The spectrum of the DCS signal contains major components in the 0 to 300hz band and therefore a LPF (Low Pass Filter) could be used on the receive side to get rid of the DCS signal and remain only with the audio signal. That’s what most of the receivers do noadays. Because of the existence of LPF in the receiver, it is indicated to get the signal for the DCS receiver just after the discriminator so that the DCS signal will be available together with audio signal.

Having available the mix of audio signal with DCS signal it is not a good thing for DCS decoding just because voice audio will interfere with the digital signal and therefore the DCS decoder will need a good low pass filter in order to eliminate the unwanted audio component. Some radio equipment vendors are doing voice filtering under 300hz before sending it to transmitter so that the receiver’s DCS decoder does not need to do LPF. However more vendors forget to do that and therefore the receiver decoder has to do it. I present below some captures of the DCS signal in varius conditions:

The picture above captures the signal after discriminator before and after the PTT on the transmitter is released. One could see three main zone:

1st zone – normal DCS code – in this specific case the code is 205.

2nd zone – the PTT is released, the transmitter sends squelch off signal. In this case it is a sine wave with frequency 134.4hz.

3rd zone – the carrier is gone and the receiver outputs white nose.

Given the 134.4hz rate of the digital signal it could be calculated that sending one word (23bits) takes up less than 0.2 seconds.

The major problem I encountered in implementing the DCS decoder was the big level of voice audio signal compared with the level of the DCS signal. This made the need for a good LP filter and other signal processing techniques in order to make the signal usable and correctly decoded with the DCS decoder. I present below an example of the signal when the user whistle into the microphone:

One could see the level of audio signal is three times more than the level of the DCS signal.

One word about modulation and Golay codes

The DCS signal is obviously a digital modulated analog signal. Each pulse represents a transition from 0 to 1 or reverse. There is no start or stop bit in the signal, therefore DCS decoder needs to look each bit it receives form the stream and decide whether it matches or not a Golay code together with the bits it received up to now.

Golay (23, 12) words contains 12bit of data represented in 8th base (octal). From this 12bits only 9bits are actual data, the rest 3bits are fixed as “100”. A Golay word is represented like this:

P11-P10-P9-P8-P7-P6-P5-P4-P3-P2-P1-100-C9-C8-C7-C6-C5-C4-C3-C2-C1

where Px are check bits and Cx are data bits.

Golay words are having some interesting properties, one of them being the fact that if a Golay word is circularly shifted left or right, another valid Golay word is obtained. This property together with the fact that no start/stop bits are given results in multiple matches depending on where the start bit is considered.  This made the maximum number of so called “standard” DCS codes be reduced so that just one match is taken in consideration.

Another property of Golay codes is the fact that if “1” and “0” is swapped into the bitstream of a valid code, then another valid code is obtained. This is in connection with what is considersd “1” and what is “0” when looking at the signal. Therefore one could talk about positive polarity and negative polarity for a DCS signal. For example +023 code produces the same pattern as -047 code. The current implementation gives both positive and negative matching.

It worth mentioning another property of the Golay codes that are not used for DCS. It is possible to recover up to three bits using the check bits.

In the next article I will present in detail how the DCS decoding is achieved in software and what software blocks I used for successfully doing this. To be continued.

As a last article about designing transmission-line transformers I present a practical example aiming at adapting a whip antenna to a 50ohm/100W system using a Ruthroff 1:9 transformer and a common-mode RF choke. I have chosen the well known Amidon FT140-43 core  for transformer and FT240-43 for RF choke.

Ruthroff 1:9

1. Core parameters taken from vendor’s catalog for FT140-43

9.02	0.807	7.280

Now we could calculate form factor F:

2. Material parameters:

850	2750	952

Complex permeability is given by a plot of and versus frequency. Then we calculate with formula and

	1.5	4	7	10	15	20	30	40	50
	600	400	310	270	200	140	95	65	48
	170	280	270	250	210	200	170	140	120
	624	488	411	368	290	244	195	154	129
	3.53	1.43	1.15	1.08	0.95	0.70	0.56	0.46	0.40

Amidon offers a table with maximum inductance (flux density) versus frequency:

	0.1	1	7	14	21	28
	500	150	57	42	36	30

The equation for the curve is:

which allows us to calculate the induction at any missing frequency in the table:

	0.1	1	1.8	3.5	7	14	21	28
	500	150	113	82	57	42	36	30

3. Calculating impedance

Using the 4x rule we could calculate the impedance for the low impedance winding:

Z=4*50ohm =200ohm

4. Calculating inductance at lowest frequency of operation (1.8mhz)

the the number of turns

5. Calculating maximum inductance (flux density) at lowest frequency

then

We see that this value is above the maximum value recomended by the vendor and therefore we need to increase the number of turns. Therefore we will use 7turns.

With this we could now calculate inductance, reactance, loss and modulus of impedance:

6. Calculating maximum voltage due to dissipation

We will allow maximum raise in temperature of Celsius, thus we calculate:

and the maximum voltage allowed for maximum dissipation:

The above formula is for continue power and could be improved in the case of manual keying and depending on the modulation type. For SSB the multiplying factor is K=3.2.

7. Calculating maximum voltage due to induction

With the new chosen number of turns (7 turns) we could now calculate the maximum allowed voltage due to induction.

All calculations are presented in the table below.

It is easily seen that lines corresponding to first two frequencies in the table gives maximum voltage due to induction less than the voltage for maximum power (71V) and therefore we should increase the number of turns further or use a bigger core.

8. Calculating characteristic impedance

Remember that for Ruthroff 1:9 we calculated optimum impedance of the upper transmission-line as being 150ohm and for lower transmission-line 75ohm. Let’s see how close we are if we use closely coil three wires on the core.

The calculation with various isolation gives the following result:

We could see that there is a mismatch between the optimum characteristic impedance and the impedance of the cables.

An Excel file with all calculations in this article could be found in wideband_transformers.xls.

This transformer has been realized in practice and used extensively on the field with a whip antenna.

In the previous post I derived formulas that could be used to calculate inductors on ferrite and iron powder cores. In this chapter I present various types of transmission-line transformers. The goal in designing a good transmission-line transformer is to make it usable in matching generator with the load over a broad range of frequencies, therefore making it a wideband transformer.

From the functioning principle point of view there are two main categories of transformers:

– transformers based on induction in the core.

– transformers based on transmission line techniques that use the core only to isolate the output from input.

Induction transformer

One could employ a regular transformer design with primary winding and secondary winding on a ferrite core so that the impedance is matched between the generator and the load but it turns out that the more the number of turns is, the more parasitic capacities are and therefore the cutoff frequency for the transformer is lowered. A core with high permeability could be used to reduce the number of turns and therefore to reduce the parasitic capacities.

Since this type of transformer is based on the magnetic flux inside the core, any leakage in the flux will be seen as a loss. Coupling between primary winding and secondary winding is much more important and one could use different winding techniques in order to make the coupling better. For example primary and secondary winding could be put together when rolled on the core.

Magnetic Longwire Balun

This is a transformer made by RF-systems in 1988 and registered to that name (MLB). They claim to use a special ferrite to obtain a broad frequency range (0.1 to 40Mhz) in matching a longwire antenna. It is actually a 1:3 voltage UnUn.

Current induction transformer

This type of induction transformer is based on principle of two currents producing same value of induction in the core but with oposite directions so that inductions will cancel each other. This is exactly what happens inside a transmission line and therefore it is also known as a transmission-line transformer.

Transformers based on transmission lines

Model of a tranmission line

Inside a transmission line the electromagnetic fields of the two conductors cancels each other so that there is no radiating outside. Therefore it is not important for the differential electromagnetic field between the two conductors what is the form of the transmission line. However if we coil up the transmission line on a core we will make a much bigger impedance for the common-mode currents, allowing us to isolate the input from the output, thus allowing us to connect input to output in various ways. This method is used in designing transmission-line transformers and a model of transmission-line in which common-mode impedance is seen is presented below:

Therefore if we have a decoupling between input and output then we have both conductors of the transmission line floating at the end,  we could feed a symetrical load like the following, making a BalUn:

This design was called by Guanella (see below) Basic building block.

The 4x rule

We will see that for some designs the equivalent impedance will be connected in parallel with the generator. In order to minimize its influence on the generator impedance, we will use the rule saying that will be four times the impedance:

Characteristic impedance

If we have a transmission line with – generator imput and impedance load, we could calculate a maximum power transfer between the generator and the load when characteristic impedance is:

Guanella and Ruthroff designs

These designs uses the following rules:

–  Currents in the coupled conductors of a transmission-line are equal in magnitude but opposite in phase (total coupling rule).

–  For every transmission-line the output voltage will be identical (magnitude and phase) to the input voltage (no loss rule).

– There is no other connection between the transformer input and output other than through the transmission-line (total decoupling rule).

In 1944 Guanella extended the previous design in an article called ‘Novel Matching Systems for High Frequencies‘ by adding two transmission-lines fed by the generator whose output are connected in series
to double the voltage(1:2 voltage, 1:4 impedance):

In 1959 Ruthroff analysed the design of Guanella and came up with an article called ‘Some broadband transformers’ in which the output of the transmission line is added to the input to produce a double voltage (1:2 voltage, 1:4 impedance)

Since the output is partially added to the input ( Bootstrap effect), this kind of design is more prone to errors when there is a unbalance in the load.

The various designs based on Guanella and Ruthroff will be discussed further on in this chapter.

Guanella 1:4 impedance

The following pictures presents the Guanella 1:4 UnUn and BalUn respectively together with relevant currents and voltages:

For both Guanella UnUn and Balun we could calculate:

It can be seen that is at potential so that it become in parallel with the generator.

– using the rule of 4x

It is interesting that the is given by the upper transmission-line since the lower transmission-line will have no differential voltage between its ends. The two windings could be done also on the same core.

Example:

and

Ruthroff 1:4 impedance

The following pictures presents the Ruthroff 1:4 UnUn and BalUn respectively together with the relevant currents and voltages:

For both Ruthroff UnUn and BalUn we could calculate:

It can be seen that is at potential so that it become in parallel with the generator.

– using the rule of 4x

Example:

and

Guanella 1:9 impedance

The following pictures presents the Guanella 1:9 UnUn together with relevant currents and voltages:

It can be seen that Z across input is in parallel with giving thus

– using the rule of 4x, thus:

Example:

and

Ruthroff 1:9 impedance

The following pictures presents the Ruthroff 1:9 UnUn together with relevant currents and voltages:

For the we observe that the two lines have different characteristic impedance:

For optimum transfer we need transmission lines with different characteristic impedance.

What we could see from the picture is that the outer conductor of the two transmission-lines are connected together, therefore they could be put on the same core.

Example:

and

Models using winding impedance:

When constructing Guanella transmission-line transformers using coils, the following is the equivalence with the transmission-line version (only BalUn is presented):

When Ruthroff transmission-line transformers are built using coils, the following is the equivalence with the transmission-line version (only BalUn is prezented):

Modeling characteristic impedance:

When making transmission-line transformers and not using transmission lines but cables either twisted or not, it is hard to make characteristic impedance resulted from the above formulas. One way to know the characteristic impedance is to calculate it with the following formula which gives the impedance of a bifilar cable:

where

D – distance between center of the cables

d – diameter of the cable

– permeability of the cable dielectric (we’ll discuss it in the next chapter).

If D become larger then the characteristic impedance will raise. Therefore one can improve impedance matching by using isolator tubes around winding cables.