1
00:00:09,930 --> 00:00:15,840
Herald: Alright, well thank you for your
patience and now we are starting our talk:

2
00:00:15,840 --> 00:00:21,040
"My journey into FM-RDS"
- radio data system by Oona Räisänen.

3
00:00:21,040 --> 00:00:27,850
Please give her a warm round of applause!
*applause*

4
00:00:27,850 --> 00:00:34,510
Oona: Thank you!
Sorry I brought my MacBook Pro.

5
00:00:34,510 --> 00:00:40,570
My name is Oona I'm a signals hacker
and electronics hobbyist

6
00:00:40,570 --> 00:00:44,200
and I do this thing only for hobby.

7
00:00:44,200 --> 00:00:52,500
And let's see my slides here. Some of you may

8
00:00:52,500 --> 00:00:55,520
remember my blog or have read it.

9
00:00:55,520 --> 00:01:00,990
And you may have seen this one,

10
00:01:00,990 --> 00:01:09,840
that I also made - the dialup diagram.

11
00:01:09,840 --> 00:01:14,440
This talk is not about that, just to give you some context.

12
00:01:14,440 --> 00:01:18,710
Okay, so, into the story:

13
00:01:18,710 --> 00:01:22,250
One night in 2007 I was listening to my radio

14
00:01:22,250 --> 00:01:28,680
just an FM channel and some music going on.

15
00:01:28,680 --> 00:01:32,810
And I was looking at the spectrum of course

16
00:01:32,810 --> 00:01:38,810
on my PC while doing that. And I noticed,

17
00:01:38,810 --> 00:01:42,250
I see the audio, that's normal, then above

18
00:01:42,250 --> 00:01:46,630
the audio, at about 19 kHz something weird

19
00:01:46,630 --> 00:01:51,490
is going on. There is a persistent sinusoidal tone.

20
00:01:51,490 --> 00:01:54,850
And something, looking like sidebands,

21
00:01:54,850 --> 00:01:58,690
on both sides of it. And I wanted to find out,

22
00:01:58,690 --> 00:02:06,900
what could it be up there? Actually I have

23
00:02:06,900 --> 00:02:15,510
some audio on my other computer:

24
00:02:15,510 --> 00:02:23,970
[Audio: rds-mixdown.wav]
This is just a radio channel played,

25
00:02:23,970 --> 00:02:26,610
and I'm shifting the frequencies down to here,

26
00:02:26,610 --> 00:02:31,200
what it sounds like up there.

27
00:02:41,130 --> 00:02:44,190
Now at the moment it just sounds like a very piercing
[Sounds from the radio]

28
00:02:44,190 --> 00:02:47,920
tone of 19 kHz. That's the tone,

29
00:02:47,920 --> 00:02:50,670
and I'm not actually hearing just yet

30
00:02:50,670 --> 00:02:56,390
whats around it. Let's turn it down a bit further.

31
00:03:04,460 --> 00:03:07,030
Now this is one of this sidebands that you

32
00:03:07,030 --> 00:03:10,230
are seeing there.

33
00:03:10,230 --> 00:03:13,663
I'm also now filtering out the music

34
00:03:13,663 --> 00:03:16,589
to make it clearer.

35
00:03:20,289 --> 00:03:22,360
It sounds very periodic.

36
00:03:22,360 --> 00:03:25,607
So it means it could be data of some kind.

37
00:03:25,607 --> 00:03:29,568
And it also brings up the memories of modem sounds.

38
00:03:29,568 --> 00:03:33,398
So, I started to investigate this matter

39
00:03:33,398 --> 00:03:35,128
a bit further.

40
00:03:39,248 --> 00:03:47,480
I knew already that in the FM signal there

41
00:03:47,480 --> 00:03:58,620
is the RDS data, that is used to send to car

42
00:03:58,620 --> 00:04:03,420
radios the station name and the program currently

43
00:04:03,420 --> 00:04:07,210
running on it and also some other information

44
00:04:07,210 --> 00:04:12,410
like alternate frequencies [AF on the slide]

45
00:04:12,410 --> 00:04:14,230
that this channel is broadcasted on,

46
00:04:14,230 --> 00:04:18,850
CT which is clock time, and something else,

47
00:04:18,850 --> 00:04:20,970
information about other programs

48
00:04:20,970 --> 00:04:25,730
and other frequencies and the program type,

49
00:04:25,730 --> 00:04:29,840
radio text, traffic announcements,

50
00:04:29,840 --> 00:04:34,546
and something called TMC or Traffic Message Channel.

51
00:04:34,546 --> 00:04:40,830
So I thought, could this be it? So I downloaded

52
00:04:40,830 --> 00:04:43,360
the 200 page RDS Standard,

53
00:04:43,360 --> 00:04:47,840
or RDBS, as its called in the United States

54
00:04:47,840 --> 00:04:51,980
and started to do some analysis. Actually I

55
00:04:51,980 --> 00:04:54,870
spent nights reading this,

56
00:04:54,870 --> 00:04:56,540
and many times I fell asleep reading it.

57
00:04:56,540 --> 00:05:00,380
*laughter*
If you suffer from insomnia,

58
00:05:00,380 --> 00:05:04,960
I suggest you read something like this.

59
00:05:04,960 --> 00:05:10,270
And, what I found - well it was very well documented,

60
00:05:10,270 --> 00:05:13,040
the protocol, there was for example this diagram

61
00:05:13,040 --> 00:05:15,840
about an example receiver for RDS.

62
00:05:15,840 --> 00:05:18,216
There's all the parts out there:

63
00:05:18,216 --> 00:05:23,720
The FM signal is coming in, the audio is taken out,

64
00:05:23,720 --> 00:05:27,720
and we are mixing it with some frequencies

65
00:05:27,720 --> 00:05:30,500
to get out the RDS signal

66
00:05:30,500 --> 00:05:38,830
and all that stuff. So, well using this information

67
00:05:38,830 --> 00:05:42,770
I wrote a decoder in Perl. Everything must

68
00:05:42,770 --> 00:05:49,495
be in perl *clapping* Thank you.

69
00:05:49,495 --> 00:05:52,480
And I came up with this. Its showing a lot

70
00:05:52,480 --> 00:05:55,729
of the information going on on the frequency.

71
00:05:55,729 --> 00:05:58,520
And whats special about this is that it's only

72
00:05:58,520 --> 00:06:02,840
decoded from the signal you were hearing on

73
00:06:02,840 --> 00:06:07,990
the 19 kHz band. And it turns out this is actually

74
00:06:07,990 --> 00:06:09,750
an error in the working of my radio.

75
00:06:09,750 --> 00:06:13,999
Because I dropped it on the floor when I was moving,

76
00:06:13,999 --> 00:06:17,840
and it started behaving weirdly. And I - it

77
00:06:17,840 --> 00:06:19,730
was then when i got this weird signal on

78
00:06:19,730 --> 00:06:22,890
the 19 kHz band. And it turns out that

79
00:06:22,890 --> 00:06:26,310
the stereo decoder in my radio has somehow

80
00:06:26,310 --> 00:06:33,170
started not to filter anymore the stereo signal,

81
00:06:33,170 --> 00:06:38,800
which is near the RDS signal. So this is actually

82
00:06:38,800 --> 00:06:41,280
being decoded from the audio, from the line

83
00:06:41,280 --> 00:06:45,360
out of my radio. Nothing else was involved

84
00:06:45,360 --> 00:06:49,830
in this. But then, well, its a bit noisy,

85
00:06:49,830 --> 00:06:54,420
its near the 16 bit quantisation noise limit

86
00:06:54,420 --> 00:06:57,750
of my soundcard. So I was thinking of better

87
00:06:57,750 --> 00:07:01,520
ways to decode it with less noise.

88
00:07:01,520 --> 00:07:03,820
And I started to look at my radio -

89
00:07:03,820 --> 00:07:05,570
the schematics of my radio

90
00:07:05,570 --> 00:07:08,140
and I found there is actually a decoder circuit

91
00:07:08,140 --> 00:07:11,610
for RDS that it uses to display the data on

92
00:07:11,610 --> 00:07:13,970
the screen, just the station name

93
00:07:13,970 --> 00:07:18,230
and updates its clock. And unlike in todays

94
00:07:18,230 --> 00:07:20,730
receivers the RDS chip is actually on its own

95
00:07:20,730 --> 00:07:25,260
chip and its not a one-chip-wonder receiver.

96
00:07:25,260 --> 00:07:31,580
So I found the 4 pins that I needed for data,

97
00:07:31,580 --> 00:07:35,840
clock signal and ground and just a quality bit,

98
00:07:35,840 --> 00:07:41,430
that I'm not actually using. And I did some

99
00:07:41,430 --> 00:07:43,820
ugly soldering work because I didn't want to

100
00:07:43,820 --> 00:07:50,630
remove the RF shielding from this chip to hook

101
00:07:50,630 --> 00:07:57,621
some cords to the decoder chip.

102
00:07:57,621 --> 00:08:01,750
And then I used my soundcard to sample that.

103
00:08:01,750 --> 00:08:05,140
Because it happens that the voltages that soundcard

104
00:08:05,140 --> 00:08:07,830
is using are very close to the logic voltages

105
00:08:07,830 --> 00:08:17,050
of [?] Voltages of ICs in the 1 to 3.3 volt range.

106
00:08:17,050 --> 00:08:20,830
So I actually used a sound card to sample

107
00:08:20,830 --> 00:08:27,240
the logic coming out of there. And its 1 kbaud

108
00:08:27,240 --> 00:08:33,850
so its not even very fast. And this is what

109
00:08:33,850 --> 00:08:38,159
I was getting - at first. Well,

110
00:08:38,159 --> 00:08:41,519
it looks like some bits, kind of.

111
00:08:41,519 --> 00:08:43,610
Then after some filtering

112
00:08:43,610 --> 00:08:47,180
and resoldering this is what i got.

113
00:08:47,180 --> 00:08:50,950
Red is the left channel in the soundcard that

114
00:08:50,950 --> 00:08:54,380
I hooked up in the clock signal output.

115
00:08:54,380 --> 00:08:58,840
And green is what I hooked up to the data signal.

116
00:08:58,840 --> 00:09:02,548
And its very clear that the data can be decoded

117
00:09:02,548 --> 00:09:07,650
with no errors from this.

118
00:09:07,650 --> 00:09:17,140
Afterwards I also made a raspberry pi version of all this,

119
00:09:17,140 --> 00:09:19,860
so the perl code is actually running on my

120
00:09:19,860 --> 00:09:22,590
raspberry pi and displaying it on an little

121
00:09:22,590 --> 00:09:29,580
lcd next to it. But then - okay this is fun,

122
00:09:29,580 --> 00:09:32,850
I can actually see more than
my radio is displaying there.

123
00:09:32,850 --> 00:09:36,550
I can see the radio text, I can see a numerical

124
00:09:36,550 --> 00:09:40,850
code for each station so I can log the stations

125
00:09:40,850 --> 00:09:45,340
and I only need to decode the number to know

126
00:09:45,340 --> 00:09:48,840
what I'm listening to. But there was something

127
00:09:48,840 --> 00:09:53,780
more on the frequency. I was getting an application -

128
00:09:53,780 --> 00:09:58,480
some application running there that I didn't

129
00:09:58,480 --> 00:10:03,230
recognize right away, but reading the standard

130
00:10:03,230 --> 00:10:07,090
it became apparent that this TMC that is used

131
00:10:07,090 --> 00:10:12,500
in these car navigators to just send information

132
00:10:12,500 --> 00:10:15,350
about traffic jams and construction works

133
00:10:15,350 --> 00:10:18,650
and things like that. And of course,

134
00:10:18,650 --> 00:10:26,230
for the fun, I had to see whats going on there.

135
00:10:26,230 --> 00:10:29,550
Now it turns out that in Finland the RDS signal

136
00:10:29,550 --> 00:10:34,610
is encrypted, for reasons of commercial stuff.

137
00:10:34,610 --> 00:10:38,500
I mean its a business model, they encrypt

138
00:10:38,500 --> 00:10:41,480
the signal and they sell the encryption keys

139
00:10:41,480 --> 00:10:45,170
along with these navigator devices

140
00:10:45,170 --> 00:10:47,040
and what they tell about the encryption in

141
00:10:47,040 --> 00:10:49,510
the standard - they actually tell everything

142
00:10:49,510 --> 00:10:55,260
about except the keys there. But one sentence

143
00:10:55,260 --> 00:10:58,270
especially caught my mind there:

144
00:10:58,270 --> 00:11:01,990
The encryption is only light, but was adjust

145
00:11:01,990 --> 00:11:04,280
to be adequate to deter other than the most

146
00:11:04,280 --> 00:11:14,314
determined hacker."
*laughter**clapping*

147
00:11:14,314 --> 00:11:19,644
Yeah, and obviously for hacker this is like an challenge

148
00:11:19,644 --> 00:11:23,770
*laughter*
so I got to work. It was textually documented,

149
00:11:23,770 --> 00:11:26,950
there was no encryption diagrams

150
00:11:26,950 --> 00:11:29,020
or anything like that, but this is what I came

151
00:11:29,020 --> 00:11:35,099
up with: It's a pretty simple cipher.

152
00:11:35,099 --> 00:11:38,570
The location is a 16 bit database reference

153
00:11:38,570 --> 00:11:42,400
to a database of locations that can be obtained

154
00:11:42,400 --> 00:11:47,804
from the manufacturer of the navigators.

155
00:11:47,804 --> 00:11:52,940
The keyspace is 16 bits, and different parts

156
00:11:52,940 --> 00:11:57,230
of the key are used to like parameters for

157
00:11:57,230 --> 00:11:59,990
the different operations in this cipher.

158
00:11:59,990 --> 00:12:04,660
It's an easy enough cipher
to be used on paper also

159
00:12:04,660 --> 00:12:12,510
so when cryptanalyzing it I made some tests

160
00:12:12,510 --> 00:12:17,390
on paper. So, how do I begin? I checked I can't

161
00:12:17,390 --> 00:12:20,860
just brute force it - knowing nothing about

162
00:12:20,860 --> 00:12:24,765
the transmission. So I
made some assumtions:

163
00:12:24,765 --> 00:12:28,520
The bandwidth is very low,
several hundred baud,

164
00:12:28,520 --> 00:12:33,530
so it must be some kind of
filtering with this locations.

165
00:12:33,530 --> 00:12:36,120
I was thinking, it could be
that they are sending

166
00:12:36,120 --> 00:12:39,950
only the locations - I mean only the announcements

167
00:12:39,950 --> 00:12:42,930
that are near the transmitter like 100 miles

168
00:12:42,930 --> 00:12:47,350
range or something. I looked
at the location database,

169
00:12:47,350 --> 00:12:49,690
that I by the way obtained by telling

170
00:12:49,690 --> 00:12:52,000
the manufacturers that I'm an engineer

171
00:12:52,000 --> 00:12:54,160
and I want to do some tests

172
00:12:54,160 --> 00:12:57,340
and maybe some development
of RDS-TMC-Software

173
00:12:57,340 --> 00:13:05,050
- and now I have the database.
So I started mapping,

174
00:13:05,050 --> 00:13:10,714
actually listening to the annoucements.

175
00:13:10,714 --> 00:13:14,950
I took one announcement and I figured

176
00:13:14,950 --> 00:13:17,390
one announcement is used for several days in

177
00:13:17,390 --> 00:13:19,030
an row - actually several weeks,

178
00:13:19,030 --> 00:13:21,060
because when there
are roadworks on it

179
00:13:21,060 --> 00:13:24,390
could last for months, weeks or something.

180
00:13:24,390 --> 00:13:29,890
So, one day, I get the announcements

181
00:13:29,890 --> 00:13:33,080
and I get the key-ID, which they are sending

182
00:13:33,080 --> 00:13:36,370
in cleartext - thats how they signal which

183
00:13:36,370 --> 00:13:38,740
key is in use today, because its a changing

184
00:13:38,740 --> 00:13:42,520
key scheme and there is a different key for

185
00:13:42,520 --> 00:13:49,000
every day. And then they send
the encrypted location.

186
00:13:49,000 --> 00:13:52,890
So I listened for several weeks in a row,

187
00:13:52,890 --> 00:13:56,490
documenting the encryption key id

188
00:13:56,490 --> 00:14:00,930
and the location and then I just bruteforced

189
00:14:00,930 --> 00:14:05,220
through the whole vast 16 bit keyspace to find

190
00:14:05,220 --> 00:14:11,480
all the keys that decrypt into locations that

191
00:14:11,480 --> 00:14:17,150
are near the transmitter. And eventually I

192
00:14:17,150 --> 00:14:21,230
came up with all the keys. And here they are -

193
00:14:21,230 --> 00:14:24,240
and because wouldn't want
to get into any more

194
00:14:24,240 --> 00:14:30,440
trouble with this, well,
yeah, I ended up finding

195
00:14:30,440 --> 00:14:34,430
all the keys. And here is a prototype receiver

196
00:14:34,430 --> 00:14:40,160
I wrote. Its receiving the messages

197
00:14:40,160 --> 00:14:46,666
and showing a little map of the announcements.

198
00:14:46,666 --> 00:14:51,012
So then I published this in a blog,

199
00:14:51,012 --> 00:14:55,670
and I got an interesting reply from someone

200
00:14:55,670 --> 00:15:01,447
who is involved in developing this:

201
00:15:01,447 --> 00:15:04,460
Sad to request, but can you take this offline?

202
00:15:04,460 --> 00:15:18,882
It is kind of our service you hacked."
*laughing* *applause*

203
00:15:18,882 --> 00:15:19,970
I had promised in

204
00:15:19,970 --> 00:15:23,670
the beginning of my blog post, that if anyone

205
00:15:23,670 --> 00:15:25,620
of the involved parties requests to take this

206
00:15:25,620 --> 00:15:28,340
offline I will take it offline. But of course,

207
00:15:28,340 --> 00:15:31,940
there are, well, my definitions of an involved

208
00:15:31,940 --> 00:15:39,580
party are quite strict. And I replied by requesting

209
00:15:39,580 --> 00:15:43,680
just the same message, but signed with their

210
00:15:43,680 --> 00:15:47,700
cryptographic signature and preferably I could

211
00:15:47,700 --> 00:15:52,560
fetch their public key from under their company domain.

212
00:15:52,560 --> 00:15:55,860
And they never replied, so the blog post is

213
00:15:55,860 --> 00:16:06,975
still on.
*laughing* *applause*

214
00:16:06,975 --> 00:16:09,280
And actually while this conversation was going on,

215
00:16:09,280 --> 00:16:11,900
it was of course being copied around

216
00:16:11,900 --> 00:16:15,740
the world, in cryptome also, so there was no

217
00:16:15,740 --> 00:16:18,120
point in replying anymore. So yeah,

218
00:16:18,120 --> 00:16:25,580
this is the first part of my adventure into RDS-Subcarriers.

219
00:16:25,580 --> 00:16:29,160
Then I heard an rumour when presenting about this:

220
00:16:29,160 --> 00:16:32,950
That the Bus-Stop-Displays in Helsinki also

221
00:16:32,950 --> 00:16:40,474
receive their data about the next buses on the RDS-Signal.

222
00:16:40,474 --> 00:16:43,600
So I started to look a bit more in the applications,

223
00:16:43,600 --> 00:16:46,480
but there was nothing in the application list

224
00:16:46,480 --> 00:16:52,760
about bus stops or anything else than TMC.

225
00:16:52,760 --> 00:16:58,840
For reference these are the displays I am talking about.

226
00:16:58,840 --> 00:17:02,090
So they are displaying the busnumber

227
00:17:02,090 --> 00:17:04,510
and the minutes and where it is going

228
00:17:04,510 --> 00:17:07,589
and it's updating live. And these are battery-operated

229
00:17:07,589 --> 00:17:11,445
and they are not connected to anything by wire.

230
00:17:11,445 --> 00:17:13,608
So there must be some kind of a radio protocol.

231
00:17:13,608 --> 00:17:17,770
But yeah, this was a nice clue.

232
00:17:17,770 --> 00:17:20,600
So i started googling about this - there was

233
00:17:20,600 --> 00:17:22,770
not very much information about it,

234
00:17:22,770 --> 00:17:26,700
except for the finnish communication authorities

235
00:17:26,700 --> 00:17:31,180
internal magazine. They were telling about

236
00:17:31,180 --> 00:17:35,780
all kinds of - sorry about my finnish text

237
00:17:35,780 --> 00:17:39,660
of course - they were telling about all kinds

238
00:17:39,660 --> 00:17:42,090
of everyday radio signals,

239
00:17:42,090 --> 00:17:45,230
and they confirmed my guess, that its being

240
00:17:45,230 --> 00:17:48,900
transmitted on the FM radio and they even told

241
00:17:48,900 --> 00:17:50,970
the channel, but that's all they told.

242
00:17:50,970 --> 00:17:53,820
They were just telling it's being transmitted

243
00:17:53,820 --> 00:17:57,200
on "YLE 1" frequencies. No protocol.

244
00:17:57,200 --> 00:18:02,850
Nothing about RDS. So I fired up my other radio,

245
00:18:02,850 --> 00:18:06,570
which can do a larger spectrum. Which is of

246
00:18:06,570 --> 00:18:11,050
course the realtek rtl-sdr packaged in an aluminium

247
00:18:11,050 --> 00:18:20,093
tin here. *applause*

248
00:18:20,093 --> 00:18:30,803
So I demodulated the "YLE 1" station signal on a bigger bandwidth.

249
00:18:30,803 --> 00:18:34,020
And here is what I saw. On the left is

250
00:18:34,020 --> 00:18:43,315
the audio, here is the obnoxious tone you just heard.

251
00:18:43,315 --> 00:18:47,020
Here is the stereo seperation signal that tells

252
00:18:47,020 --> 00:18:49,380
the relation of the left channel

253
00:18:49,380 --> 00:18:53,230
and the right channel. Here is RDS where it

254
00:18:53,230 --> 00:18:56,800
actually should be, but for some reason it

255
00:18:56,800 --> 00:19:00,760
was aliased to around the pilot tone in my

256
00:19:00,760 --> 00:19:06,090
older radio. And this fourth harmonic of

257
00:19:06,090 --> 00:19:10,090
the pilot tone contains obviously some data,

258
00:19:10,090 --> 00:19:12,890
on a very wide bandwidth compared to

259
00:19:12,890 --> 00:19:16,850
the RDS.

260
00:19:16,850 --> 00:19:22,280
What could it be and
how could I ever find out? Well,

261
00:19:22,280 --> 00:19:26,250
it's centered around 76 kHz on the demodulated signal,

262
00:19:26,250 --> 00:19:31,500
the composite signal. So I started by googling

263
00:19:31,500 --> 00:19:36,710
for 76 kHz, and I found something called DARC

264
00:19:36,710 --> 00:19:40,660
or "Data Radio Channel". It's not to be confused

265
00:19:40,660 --> 00:19:44,850
with RDS which is the Radio Data System of course.

266
00:19:44,850 --> 00:19:48,528
These are very imaginative names.

267
00:19:48,528 --> 00:19:51,450
I found out that it is a very much more complex

268
00:19:51,450 --> 00:19:59,960
modulation scheme. It uses QPSK which is a

269
00:19:59,960 --> 00:20:04,500
four phase modulation scheme. Well I'm not

270
00:20:04,500 --> 00:20:07,380
a engineer, I'm not an DSP specialist,

271
00:20:07,380 --> 00:20:12,490
I am a DSP hacker, but I don't know much about

272
00:20:12,490 --> 00:20:17,730
demodulating QPSK. So I decided to treat it

273
00:20:17,730 --> 00:20:20,980
as an FSK signal, because that is possible

274
00:20:20,980 --> 00:20:30,020
with QPSK. It is suboptimal, but it works -

275
00:20:30,020 --> 00:20:37,610
I can get the data out. The upper part is

276
00:20:37,610 --> 00:20:42,350
the DARC signal filtered. Here is the DARC

277
00:20:42,350 --> 00:20:47,750
signal using two band-pass filters that are

278
00:20:47,750 --> 00:20:53,380
on 76+4 and 76-4 and superimposed in red

279
00:20:53,380 --> 00:20:59,600
and blue, like an FSK. And here is just blue

280
00:20:59,600 --> 00:21:02,770
minus red, or the other way around,

281
00:21:02,770 --> 00:21:14,990
which is actually binary data. So I had to

282
00:21:14,990 --> 00:21:16,680
treat the error correction

283
00:21:16,680 --> 00:21:19,550
and error detection, and it was very complicated.

284
00:21:19,550 --> 00:21:24,700
And I had to write general CRC subroutine in

285
00:21:24,700 --> 00:21:30,940
Perl because I had to deal with such large

286
00:21:30,940 --> 00:21:34,260
numbers that I couldn't use just integers -

287
00:21:34,260 --> 00:21:37,550
I had to actually use string magic.

288
00:21:37,550 --> 00:21:40,920
So I'm actually concatenateing strings of ones

289
00:21:40,920 --> 00:21:44,180
and zeroes. And using this kind of general

290
00:21:44,180 --> 00:21:50,570
CRC routing for calculating the error correction

291
00:21:50,570 --> 00:21:56,570
and detection. So, this is DARC

292
00:21:56,570 --> 00:21:58,830
and I actually getting packets out,

293
00:21:58,830 --> 00:22:02,107
but I have no idea what the packets mean.

294
00:22:02,107 --> 00:22:05,020
So I started looking for any human readable

295
00:22:05,020 --> 00:22:08,020
data out of there, because there is no documentation

296
00:22:08,020 --> 00:22:17,290
about this. For example, this was one type

297
00:22:17,290 --> 00:22:22,640
of packet that I've found: RUSKEASUO BRUKAKÄRR,

298
00:22:22,640 --> 00:22:26,400
that means something for finns - that's a place

299
00:22:26,400 --> 00:22:32,730
in helsinki, where the bus 23N happens to go.

300
00:22:32,730 --> 00:22:36,010
So I figured this could be a packet telling

301
00:22:36,010 --> 00:22:42,317
something about, just generally about buses.

302
00:22:42,317 --> 00:22:46,020
And actually I went so far as to label all

303
00:22:46,020 --> 00:22:49,980
the fields in the end, because I collected

304
00:22:49,980 --> 00:22:52,660
so many of them. And I found out,

305
00:22:52,660 --> 00:22:57,420
the system is sending one of these packets

306
00:22:57,420 --> 00:23:01,710
to every display once a day. So it's updating

307
00:23:01,710 --> 00:23:05,190
the information about all possible buses that

308
00:23:05,190 --> 00:23:11,427
are passing this bus stop today.

309
00:23:11,427 --> 00:23:13,930
It's using such low bandwidth that updating

310
00:23:13,930 --> 00:23:18,338
all the displays takes one day.

311
00:23:18,338 --> 00:23:20,920
Then I found another type of packet,

312
00:23:20,920 --> 00:23:27,800
with no actual strings. But I found definite

313
00:23:27,800 --> 00:23:33,200
references to the above packet. And I found

314
00:23:33,200 --> 00:23:35,750
this is the packet used to update the minutes

315
00:23:35,750 --> 00:23:38,440
information in these displays. It's being sent

316
00:23:38,440 --> 00:23:47,210
very fast, 3 times per minute, to every display.

317
00:23:47,210 --> 00:23:55,450
It contains minutes for 8 buses per packet,

318
00:23:55,450 --> 00:24:00,480
and information about whether they are actually

319
00:24:00,480 --> 00:24:05,320
GPS located or if it's a guess based on time tables.

320
00:24:08,110 --> 00:24:13,340
And I used all this information, I had a functional goal:

321
00:24:13,340 --> 00:24:18,010
to build my own display, because the tram stop

322
00:24:18,010 --> 00:24:19,830
is 200 metres from my house,

323
00:24:19,830 --> 00:24:27,200
and I want to know when the tram is actually coming.

324
00:24:27,200 --> 00:24:29,740
Because this information is actually

325
00:24:29,740 --> 00:24:34,810
the GPS located information. So this is what

326
00:24:34,810 --> 00:24:45,331
I built
*applause*

327
00:24:45,331 --> 00:24:51,306
Its just a basic HD77480 display

328
00:24:51,306 --> 00:24:53,560
controlled by a Raspberry Pi,

329
00:24:53,560 --> 00:24:59,280
decoding the signal from the RTL-SDR. For some

330
00:24:59,280 --> 00:25:02,560
reasons I blogged about it

331
00:25:02,560 --> 00:25:04,300
and it became very popular in Finland,

332
00:25:04,300 --> 00:25:07,980
in Helsinki especially, and there was an news

333
00:25:07,980 --> 00:25:14,550
article about it. And a representant of

334
00:25:14,550 --> 00:25:16,830
the bus company was saying that "OK,

335
00:25:16,830 --> 00:25:19,690
she can decode the signal, but transmitting

336
00:25:19,690 --> 00:25:27,250
will be difficult. "
*laugther*

337
00:25:27,250 --> 00:25:31,570
I haven't actually done it yet.
But he was saying that

338
00:25:31,570 --> 00:25:34,830
it's difficult because you have to shout louder

339
00:25:34,830 --> 00:25:37,080
than everyone else on the frequency.

340
00:25:37,080 --> 00:25:41,290
And even then it becomes mangeled, because

341
00:25:41,290 --> 00:25:44,990
it becomes a mix of those two signals.

342
00:25:44,990 --> 00:25:47,880
I don't think he really knew
what he was talking about,

343
00:25:47,880 --> 00:25:52,050
because there is something called the FM capture effect.

344
00:25:52,050 --> 00:25:56,890
That if you send stronger than another FM transmission

345
00:25:56,890 --> 00:26:00,020
on the same frequency, only the stronger signal

346
00:26:00,020 --> 00:26:07,877
becomes captured and the weaker
becomes actually attenuated.

347
00:26:07,877 --> 00:26:13,380
That is a very useful phenomenon. Right now

348
00:26:13,380 --> 00:26:18,220
I am actually in the process of making my own

349
00:26:18,220 --> 00:26:30,500
display updater.
*laughter* *applause*

350
00:26:30,500 --> 00:26:33,080
Possibly for showing all kinds of funny stuff on

351
00:26:33,080 --> 00:26:37,320
the displays. Someone at the bus company actually

352
00:26:37,320 --> 00:26:41,390
donated one of those displays to me after this,

353
00:26:41,390 --> 00:26:44,160
so I have something to test it on.

354
00:26:44,160 --> 00:26:46,640
Because obviously I'm not going to transmit

355
00:26:46,640 --> 00:26:52,460
any high-power signals with this ever.

356
00:26:52,460 --> 00:26:53,990
But right now, I'm building it.

357
00:26:53,990 --> 00:26:56,060
The only problem that I'm having right now

358
00:26:56,060 --> 00:26:59,510
is that my soundcard that I am using to generate

359
00:26:59,510 --> 00:27:04,510
the signal fully digitally of course is to slow.

360
00:27:04,510 --> 00:27:09,040
The DARC signal is 76 kHz, so i need at least

361
00:27:09,040 --> 00:27:12,920
162 kHz soundcard, i mean DAC,

362
00:27:12,920 --> 00:27:18,400
to create my analogue signal. I only have a

363
00:27:18,400 --> 00:27:22,930
96khz soundcard right now, so I only can generate

364
00:27:22,930 --> 00:27:27,910
the stereo signal. Perhaps in the future,

365
00:27:27,910 --> 00:27:31,970
that will be the next project. Thank you.

366
00:27:31,970 --> 00:27:47,880
*applause*

367
00:27:47,880 --> 00:27:50,200
Herald: Well, thank you very much, Oona,

368
00:27:50,200 --> 00:27:52,970
I think we're all impressed with hacking a radio,

369
00:27:52,970 --> 00:27:55,940
I never thought about this opportunity.

370
00:27:55,940 --> 00:27:58,110
Now we have time for questions from

371
00:27:58,110 --> 00:27:59,780
the room. If you want to ask questions,

372
00:27:59,780 --> 00:28:02,900
could you please line up at the microphones

373
00:28:02,900 --> 00:28:07,380
right here. In the mean time, let me ask our

374
00:28:07,380 --> 00:28:09,310
signal angel if he has a question from

375
00:28:09,310 --> 00:28:11,840
the internet. Could you tell us please?
Signal Angel: Yeah,

376
00:28:11,840 --> 00:28:14,300
so the internet wants to know: Is there any

377
00:28:14,300 --> 00:28:16,950
open hardware radio receiver that you can recommend

378
00:28:16,950 --> 00:28:19,590
for tinkering at home?
Oona: Yeah,

379
00:28:19,590 --> 00:28:25,300
the RTL-SDR is a very good
piece of hardware to start with

380
00:28:25,300 --> 00:28:28,270
I think I have one of those with me right now,

381
00:28:28,270 --> 00:28:31,110
I mean the one I showed with the Hello Kitty

382
00:28:31,110 --> 00:28:35,070
tin around it. I've using a tin to attenuate

383
00:28:35,070 --> 00:28:38,590
any local interference. But its just a DVB

384
00:28:38,590 --> 00:28:47,400
digital tv stick some wise guy on the internet

385
00:28:47,400 --> 00:28:49,930
found to be possible to hack

386
00:28:49,930 --> 00:28:58,090
and tune to any frequency from 30 to 1.700 MHz

387
00:28:58,090 --> 00:29:01,690
And it's very useful. Doesn't go higher

388
00:29:01,690 --> 00:29:03,800
than that, doesn't go lower than that,

389
00:29:03,800 --> 00:29:07,750
but it is a good start.
Herald: Okay. Questions from

390
00:29:07,750 --> 00:29:13,030
the room?
Mic: I've just a bit of input on

391
00:29:13,030 --> 00:29:17,270
the transmitter thing. There is a project that

392
00:29:17,270 --> 00:29:21,190
uses the raspberry pi DMA controller,

393
00:29:21,190 --> 00:29:23,370
where you can use to send signals at about

394
00:29:23,370 --> 00:29:28,320
140 MHz on the GPIO pins, so maybe that could

395
00:29:28,320 --> 00:29:31,060
be used.
Oona: Ooh, thanks for the [?] That will

396
00:29:31,060 --> 00:29:33,660
be very useful. I've been thinking about

397
00:29:33,660 --> 00:29:36,640
the GPIO but it's unfiltered of course.

398
00:29:36,640 --> 00:29:42,150
Mic: The raw DMA controller output gets dumped on

399
00:29:42,150 --> 00:29:47,340
one of the GPIO pins. As far as I know it's

400
00:29:47,340 --> 00:29:50,490
good enough to transmit FM stereo audio.

401
00:29:50,490 --> 00:29:53,960
Oona: Okay, yeah. It would be worthwhile testing

402
00:29:53,960 --> 00:29:56,850
with RDS first maybe. Thank you for

403
00:29:56,850 --> 00:30:00,270
the tip, yeah, it's very useful.
Herald: So maybe we

404
00:30:00,270 --> 00:30:02,220
could buy them at the next congress,

405
00:30:02,220 --> 00:30:03,600
right? *laughter*
Oona: Could be,

406
00:30:03,600 --> 00:30:09,730
could be. Herald: Go ahead please.
Mic: Thanks for the interesting talk,

407
00:30:09,730 --> 00:30:18,120
I've two questions. You said that you can decode Q-PSK as FSK by

408
00:30:18,120 --> 00:30:21,700
a simple trick. How much less quality do you

409
00:30:21,700 --> 00:30:25,270
get? 3db, 6db, what is it?
Oona: I'm not sure

410
00:30:25,270 --> 00:30:28,720
about the details, but well it just crossed

411
00:30:28,720 --> 00:30:34,140
my mind that you can do it. It's actually MSK

412
00:30:34,140 --> 00:30:37,690
but its a sort of an Q-PSK signal.

413
00:30:37,690 --> 00:30:41,240
So its a minimum shift keying. And essentially

414
00:30:41,240 --> 00:30:46,570
its being generated in the transmitter as FSK,

415
00:30:46,570 --> 00:30:50,580
but thats a special form of FSK,

416
00:30:50,580 --> 00:30:53,390
so thats why it can be decoded as FSK.

417
00:30:53,390 --> 00:30:55,500
Mic: Okay, and a brief second question: In

418
00:30:55,500 --> 00:30:58,630
the picture where you took the signal from

419
00:30:58,630 --> 00:31:01,530
your digital radio, it was a Sangean ATS 909

420
00:31:01,530 --> 00:31:09,390
or what radio you used? I've got one of those

421
00:31:09,390 --> 00:31:11,290
and I was wondering if I could pick up

422
00:31:11,290 --> 00:31:15,700
the signals in there as well. [...]

423
00:31:15,700 --> 00:31:19,660
Oona: The Radio is a Sangean ATS 909,

424
00:31:19,660 --> 00:31:22,530
I've modified it a bit, you can take a look

425
00:31:22,530 --> 00:31:26,500
if you want.
Herlad: Any other question from

426
00:31:26,500 --> 00:31:29,270
the internet? Oh, our signal angel has nothing,

427
00:31:29,270 --> 00:31:32,630
then lets go ahead right here please.

428
00:31:32,630 --> 00:31:35,030
Mic: Have you considered what [...]

429
00:31:35,030 --> 00:31:38,550
going to be beyond transmitting the signal.

430
00:31:38,550 --> 00:31:41,960
What are you going to be next challenges you're

431
00:31:41,960 --> 00:31:44,160
taking out? Are you going to look at other

432
00:31:44,160 --> 00:31:47,360
wireless services that are around there in

433
00:31:47,360 --> 00:31:50,690
terms of utilities, because traditionally there

434
00:31:50,690 --> 00:31:52,030
are many.
Oona: There are many, yeah,

435
00:31:52,030 --> 00:31:56,750
it's an very interesting world. And I'm actually

436
00:31:56,750 --> 00:31:58,970
listening to serveral signals at the moment

437
00:31:58,970 --> 00:32:04,240
in my home right now.
Mic: Mind telling us a little

438
00:32:04,240 --> 00:32:07,290
glimpse?
Oona: There is the local taxi company

439
00:32:07,290 --> 00:32:11,800
that is using the frequency range from 40 to

440
00:32:11,800 --> 00:32:17,430
70 MHz, they send information about next clients

441
00:32:17,430 --> 00:32:22,120
and also locating all their cabs,

442
00:32:22,120 --> 00:32:25,540
and I'm trying to decode whats it's about.

443
00:32:25,540 --> 00:32:30,590
Perhaps I'll make a map of all their cars. -

444
00:32:30,590 --> 00:32:32,740
Of course there is also TETRA.

445
00:32:32,740 --> 00:32:35,980
Not many people know that TETRA is not encrypted,

446
00:32:35,980 --> 00:32:38,020
it's usually encrypted, but not always.

447
00:32:38,020 --> 00:32:42,480
And many applications in TETRA are in clear text.

448
00:32:42,480 --> 00:32:46,210
You can listen to it, if you really want to.

449
00:32:46,210 --> 00:32:52,660
Mic: Which sort of teases me now to ask a question:

450
00:32:52,660 --> 00:32:55,990
What's the legal situation for you in finland

451
00:32:55,990 --> 00:32:59,150
when it comes to decoding such transmissions

452
00:32:59,150 --> 00:33:01,170
when they are not encrypted.
Herald: You have

453
00:33:01,170 --> 00:33:03,200
the right to remain silent.
Mic: Yeah,

454
00:33:03,200 --> 00:33:06,470
you don't have to answer that
Oona: Well,

455
00:33:06,470 --> 00:33:09,470
I believe that it its legal to decode them.

456
00:33:09,470 --> 00:33:19,060
I don't care if it's not *laughter*
*applause*

457
00:33:19,060 --> 00:33:21,920
Yeah, of course, actually making an FM transmitter would be illegal

458
00:33:21,920 --> 00:33:28,600
if its an high enough power.

459
00:33:28,600 --> 00:33:32,440
Herald: Okay, over there. Let's go, please?
Mic: Could you

460
00:33:32,440 --> 00:33:36,520
maybe elaborate a bit about the bus stop packet contents,

461
00:33:36,520 --> 00:33:38,250
so currently they are not encrypted,

462
00:33:38,250 --> 00:33:42,380
is there any signature to verify its an legit

463
00:33:42,380 --> 00:33:45,160
packet?
Oona: No they aren't using any encryption

464
00:33:45,160 --> 00:33:48,560
or signature overhead, because its so an low-banded channel.

465
00:33:48,560 --> 00:33:53,140
So you can spoof it. I guess it should be trivial.

466
00:33:53,140 --> 00:33:55,220
Actually the are some types of packets that

467
00:33:55,220 --> 00:33:58,590
I don't know the meaning of. But they are non changing,

468
00:33:58,590 --> 00:34:01,890
so they obviously can't be anything [?]

469
00:34:01,890 --> 00:34:07,740
or anything like that.
Herald: Okay, go ahead please.

470
00:34:07,740 --> 00:34:10,699
Mic: I wanted to add some information on

471
00:34:10,699 --> 00:34:13,980
the situation in Germany: We have two types

472
00:34:13,980 --> 00:34:16,159
of radio stations, the public radio stations

473
00:34:16,159 --> 00:34:20,949
broadcast RDS that are unencrypted, so if you

474
00:34:20,949 --> 00:34:25,110
get the RDS data, you can get the raw location codes.

475
00:34:25,110 --> 00:34:30,470
And the TMC messages are usually sent by private

476
00:34:30,470 --> 00:34:34,100
radio stations. The fun thing is,

477
00:34:34,100 --> 00:34:37,740
that you get both the unencrypted location

478
00:34:37,740 --> 00:34:40,550
codes and encrypted location codes.

479
00:34:40,550 --> 00:34:42,580
So if you listen to two radio stations in

480
00:34:42,580 --> 00:34:46,920
the same area, you can actually cross-correlate

481
00:34:46,920 --> 00:34:50,719
these and try to figure out the key.

482
00:34:50,719 --> 00:34:52,480
And the other thing I wanted to say:

483
00:34:52,480 --> 00:34:55,719
If somebody is just interested in RDS,

484
00:34:55,719 --> 00:34:59,480
there are relatively cheap usb sticks that

485
00:34:59,480 --> 00:35:01,290
will do all the decoding for you. -

486
00:35:01,290 --> 00:35:09,010
Oona: Yeah, FM Radio sticks.

487
00:35:09,010 --> 00:35:14,950
Mic: Is there any book you can recommend
in getting started for processing

488
00:35:14,950 --> 00:35:17,110
of digital radio transmissions.
Oona: Well,

489
00:35:17,110 --> 00:35:21,380
I've read a few chapters of the - I don't know

490
00:35:21,380 --> 00:35:23,990
the name actually - but the DSP [?] guided

491
00:35:23,990 --> 00:35:28,160
commerce[?] - The engineers guide to DSP,

492
00:35:28,160 --> 00:35:33,410
It's a blue book, thats all I know.

493
00:35:33,410 --> 00:35:39,020
Its freely available online, try it with google.

494
00:35:39,020 --> 00:35:46,280
Mic: Thank you.
Herald: Any more questions,

495
00:35:46,280 --> 00:35:50,565
or from the internet? Nothing right there.

496
00:35:50,565 --> 00:35:52,170
Well, Oona, thank you very much.

497
00:35:52,170 --> 00:35:54,229
That was a very interesting talk,

498
00:35:54,229 --> 00:35:56,188
and we look forward having you next year

499
00:35:56,188 --> 00:35:57,728
with more signals.

500
00:35:57,728 --> 00:36:02,953
*Applause*