 Good morning everyone. Welcome to the second talk here in Medientia-Arta. I hope you're well. I would like you to ask to consider becoming a troll. Kitchen needs trolls, the whole venue is run by trolls, and as always we don't have enough trolls. So I would like, I would ask you to consider becoming a troll, which is awesome. Now to the talk. I just learned that Radio Sound is not a denglish word or a German word used in English contexts. It is an English word. This is the telemetry device that hangs below a weather balloon that goes up into the atmosphere to collect data, like temperature, humidity and all sorts of things. He is Bazjo. Yeah, sorry for that. He started getting into the field of Radio Sons by collecting them and ended up being a developer, professional developer for those types of Radio Sons. He is talking about the protocol and all the things around. Please welcome Bazjo. Yeah. Thank you for the introduction. My name is Johannes and I will talk about how Radio Sound telemetry works. So I have, as previously heard, a lot to do with Radio Sons. So this year's Radio Sound talk is going to focus more on the in-depth side of the communications engineering, how the telemetry works and some things we need to know if we want to write our own decoders. So what's on the agenda for today is there will be short introduction into Radio Sons as well. And if we want to talk about telemetry, then I think it's good to give a little bit of a radio and modulation primer because I think not all of you have a foundation in communications engineering. Then I want to talk about how it all started and how I got to work with Radio Sons telemetry and ended up doing what I do. Then we will look into two Radio Sons types in particular, the Weissler RS41 Radio Sons, which is used in Germany, and the Gras DFM Radio Sons, which is used in the United States and some other territories as well. After we discussed those telemetry formats and we'll look a little bit more into how we can decode them and how we can say whether our decoder is any good. So a little bit of a disclaimer. Yeah, I work with Radio Sons for a living. No, I'm not speaking on behalf of my employer here. So all that I'm talking about is stuff that I did in my free time, mainly before I joined my current employer and also some research that I do with my research affiliation. Receiving and decoding Radio Sons might not be legal where you live. Please check your own legislation where you live and transmission in this band is most certainly not. So please don't transmit on Radio Sons frequencies. Also, these things that I'm going to present here were in large part not discovered by myself. There are a lot more knowledgeable people than me. For example, Xilok 80, which is also known as RS1792. He's very knowledgeable on the topic Hans Hansi, Rolf and a lot of other ones as well. So please pay these guys on the minimum as much respect as you may do me for giving this talk. So a little bit of a Radio Sons primer. So I did a talk on this topic last year as well. So I'm going to keep it fairly short. Radio Sons are the measurement devices which fly a lot of weather balloons. So those measurement devices are disposable because you don't know where the weather balloon ends up landing. And they measure something we call PTU data in the industry that's short for pressure, temperature and humidity. And also wind data, so how where the balloon is flying and where it is drifting, so how the wind must be in this part of the atmosphere. And sometimes external data from external instruments is collected via a protocol called Xdata as well. They are very lightweight and battery operated, usually using lithium primary batteries. And they are a backbone to upper troposphere, lower stratosphere weather measurements. So they are heavily used for numeric weather production and WP and also climatology. There are around 1,000 launch sites that report to the WMO's reporting network, each performing about one to four launches per day. There are also some special uses, for example, artillery ranges, research applications and a lot more. There are two large manufacturers, Weissler and Gras on the market and a few smaller ones as well. So as I previously said, there are some other radio sound talks. There is a great talk from Mark Jessup and Michaela Wheeler from the Australian Linux conference from 2019. And my talk from last year about radio sounds is closely on the same track as this talk, let's say. So choose your own adventure, whether you prefer English or German talks. So, I mean, radio sound telemetry, it's a very, let's say, niche or obscure topic. I'm glad that so many came here in this early hour and in a foreign language talk to learn about this. But why should I even care, even if I'm into radio sounds and I enjoy hunting radio sounds? I mean, we got those TT Go boards and I just need to turn it on, tune in the right frequency and it says everything right here. That's a cordon where I need to go to collect this radio sound and why do I need to know how the telemetry format works? And excuse for the German article that I'm going to show here that I read last week when doing the preparations for this talk. It's about some residents in a small German municipality who got a little bit scared of those pesky 5G towers that the T-Mobile wanted to put there. And it had all the, let's say, checkbox marks of such articles like health risks of 5G are totally unknown, particularly feared a birth defect in young animals of a nearby farm and children. And I find particularly funny the protests were initiated by the managing director of a consulting firm that is responsible for implementing digital technology in schools within the county. But ask yourself, like, radio sound telemetry is a very, very simple topic, but let's put it to 5G. Who of you can explain how 5G works and who of you has the tools at home to prove that 5G is not some kind of evil wizardry and that there is some wizard enchanting all the iPhones and some wizard employed at Huawei enchanting all the cell towers? Like, who can prove that? And can you blame people who are not as technically knowledgeable to have a fear of those wizards? And I think that's why we really need to approach this topic on a very basic level. I think radio sound telemetry is a very basic level. And with this knowledge we can prove that all those technologies, they are just incremental small changes from technology that's decades old. And if we understand at least a little bit about the basics, then we can make sure that people don't think that this is wizardry, but in fact understand how it is science and how the science work and how they can prove it for themselves with accessible technology. And I want to do a little bit in this regard with this talk as well. So let's talk a little bit about radio and modulation. So why do we need modulation in the first place? It was a great talk about software-defined radio yesterday. I think maybe some of you saw it as well. It's also on the streaming, but unfortunately it's in Germany for the international viewers. And there some reasoning was given with the principle of the Superheterodyne receiver. I thought about including this one as well, but I felt against it and that was a good decision because it was already talked about yesterday. So I want to give a little bit of a different explanation, which is like a fundamental explanation of the principle. So imagine you want to transmit some information wirelessly. It can be some, let's say it's some analog information, maybe some voice signal, maybe just the audio transmission from the wireless microphone or so on. Why don't you just transmit it in the baseband? Audio is from 20 Hz to 20 kHz. Just use these electromagnetic waves. So first problem is the longer the waves, the more difficult to implement the technology gets. Very large wavelengths is only used for some niche applications because it's very difficult to implement. But also think about it, if there's talks going on here and on the other venues as well and everyone would use this baseband frequency band, then we could only transmit one channel of audio and we couldn't transmit any more than one signal as far as the signal is propagating. So we need some sort of bringing a signal into a different frequency band. And this is what modulation does. So modulation has two signals, the carrier signal and the signal that we want to use. And that is quite an overused picture that I put here. You can see an analog signal at the top that is the data that we want to transmit and there are some two common types of modulation where we use a different wave that's called the carrier. It has the higher frequency that you see here and we modulate the signal on top of the carrier. So with AM or amplitude modulation we modulate the amplitude of the signal. So we increase the intensity when we want to transmit higher values and we decrease it when we want to transmit lower values. And with frequency modulation we increase the frequency of the signal when we want to transmit higher values and decrease the frequency when we want to transmit lower values. values. And one thing that you need to understand here is that each frequency with frequency modulation is transmitting a certain amplitude of the signal and not a frequency. So that is something that I confused at least initially. So that's something to keep in the back of your mind. So of course we're all digital now. So we can look at frequency shift keying as a special case of frequency modulation for binary data. So now we have binary data and we still have our carrier signal but now we have two distinct frequencies. One is for the lower amplitude, one is for the higher amplitude and we just switch those two frequencies and that way we can encode the data. So we can put this into some some formulas as well. So we have the frequency deviation of delta which is a key component to determine the occupied bandwidth and it can be expressed as the difference between the two transmit frequencies. So the two frequencies you see in the bottom graph. And you have the carrier frequency which is the middle frequency. And some important thing to note is that the frequency deviation and the frequency of the of the symbols, so the individual ones and zeros, is not necessarily constrained in like a hard constraint. So you can choose those two of course taking into account some parameters but you have a modulation index that is the quotient of these two values. And you can choose this modulation index within some certain bounds. Why do I talk about symbols here and not bits? I mean obviously there are ones and zeros and this is called bit and not symbol. It's a little bit like with the zero transmissions where you talk about bought rate and not bit rate. So in the simple case of two FSK where you just have two frequencies, one bit is equal to one symbol because you can only encode one bit with each symbol because you only have two symbols. But with some telemetry we will look at later that we can only encode half a bit with each symbol. So or otherwise the other way around. We'll look into this a little bit later on. So how did it all get started? Like in 2018 I did my bachelor's thesis on atmospheric measurements and somewhere stumbled across those radio sounds and at the time I didn't have a Baufang radio I think so I ordered one of eBay or Amazon and tuned into the radio sound channels. I put out my antenna and I heard for the first time those radio sound sounds. I didn't include it in the presentation but on Ciddi-Twitty there are some example signals that you can listen to and yeah it sounds a little bit like old fax machine or analog modulation. And then there's a well-known software toolchain. So of course radio sound enthusiasts use the RTL-SDR software defined radio as well and on Windows the software to go with is SDR-Sharp. So you tune into the radio sound frequency with your SDR-Sharp and you get an audio signal. So we said earlier that FSK is just a special case of frequency modulation so you just use a frequency demodulator in the right bandwidth domain. So 12 kHz usually for radio sound signals and you get out an audio signal and then you can use a virtual loopback interface to pipe this audio signal back into your machine and connect some sort of software to it and the software which visualizes radio sound telemetry for RS41 at least the nicest the nicest is RS41 tracker. So I plugged in my RS41 tracker I set up the loopback interface and right here all the decoded data that's so nice. But then I also wanted to hunt down those radio songs and initially I found the RS41 radio songs and I took a closer look into them and also learned a little bit about the hardware. So I just want to go about this just very briefly. The most interesting part for us here is that we have an STM32 microcontroller and integrated radio transmitter a PsyLab Psy432 and who joined me with my last talk about hardware reverse engineering knows that step number one is reconnaissance. So I took a look into the datasheet and I found like some interesting stuff some not so interesting stuff some regulatory stuff but also some interesting informations about the transmission. So I found a peak to peak deviation 4.8 kHz and the data downlink of 4,800 bits per second. So initial guess modulation index will be one. So that gives the parameters that you can set on your SDR sharp. So then I thought I mean it's audio data so let's have a look into this audio data I want to know how we come from this step where we have some FMD modulated baseband data to this step and that's what the first part of this presentation will focus on. So I used everyone's favorite software for engineering or for working with audio signals may tend to grow proud and used audacity. So this is a screenshot that I used for my Github repository where I explain all this stuff where you can see there are some ones and zeros obviously and they are not so pretty but I guess we can work with them and if you would listen to the RS41 telemetry then you would see that it's about 500 millisecond long frames that are every second and there is also a short beep in front of every frame and this is the preamble so we take a look at where does the data start and we see a high frequency part of the data here that's the preamble and the filter from the FMD modulator needs a little bit time to settle that there is a signal now. So the nice thing when you have telemetry that starts with a preamble is that you know where you need to start looking for a header and where all the telemetry the data actually starts so we can take a look in the datasheet of the transmitter maybe we learned something about the protocol that is used there so this transmitter is actually NRND so that's where there's the great text on top of it we have a preamble which is not optional it needs to be between 1 and 512 bytes we have a sync word which is also not optional it needs to be between 1 and 4 bytes and we have data and everything else the tx header packet lengths and TRC is optional so let's look whether we can find this sync word and I will refer to this as a header so behold we find a header and we can see this is little endian and it uses a non-intuitive byte order so this here is the first nibble it's a 1 and then we have a 0 then we have a b then we have 6 c and an a 1 and a 1 and I was lucky then because I already know what the correct header should be because as I said some reverse engineering had already been done but it was not very well documented so I looked into the code and I found that out of our 1729s decoder this should be a different hex value but there is a catch here the whole transmission is XOS scrambled so there is an XOR mask I think the XOR mask is fairly static within the transmitter I see and there's a PN9 generator and you can set an initial value but there's only a certain number of combinations so you can get to the XOR mask fairly quickly but why is there an XOR mask I mean does they want to make it a little bit harder for us do they don't think that we can figure out how the XOR mask work no it's to make sure that there is always even if there's only a transmission of steady ones or zeros that there are always enough sign changes in the signal because when you consider the signal analog it needs to have a certain frequency for example to pass through some filters or maybe you want to sync your clock to the clock of the signal so you want to have a lot of sign changes on the signal and that's why you scrambled with an XOR mask so then you make sure that even if you have a long stream of ones or zeros you always get enough sign changes so one thing that I need to talk about is there are different variants of the RS41 different telemetry formats there are three models of RS41 that are relevant to us there is the SG variant that does not have a barometric pressure sensor there is the SGP variant that has a barometric pressure sensor and there is the SGM variant that has the ability to send encrypted data and also to send data at a later time so each frame contains two actual data frames and the conventional RS41s also have the possibility in X data mode to transmit longer frames as well that's also the RS41D model but it uses a different frequency and it's continuously transmitting and we don't want to look at this so once we look at the data that comes after our header we find something like this so I wrote our header here as the first first 4 bits already XORD scrambled and then we have some sort of protocol structure so the first 48 bytes in the transmission is actually error correction data it's the parity part of a Reed Solomon code this is an interleaved Reed Solomon code so there are two Reed Solomon code words and every I think second bit or second byte not sure here is belonging to a different a Reed Solomon code word and this is to increase the length of burst errors that this code can correct after this there's a single byte that indicates whether this is a long frame for example for the encrypted dual frame mode or for the X data mode or whether this is a standard frame and that's this is 0F or F0 I suspect this is so even if there's a corruption in one bit you have still the other bits to indicate which frame length this is because this is critical to understanding the frame and then there was a there is a variable amount of let's say fields and each field starts with a unique ID the first field at 79 then the length of the field in byte because fields can have a variable length then the data and at the end there's a CRC 16 checksum and for a standard RS 41 there are I think five fields that we really need to look into and also just a buffer to fill up some empty space I don't want to go through all the all the data that's encoded here individually but I want to point out some things so the status field encodes some information on the general status of the radio son so you can see the frame number which is also coinciding with the second since the radio son was turned on or started the transmission because there's one frame every second there's also the serial number and this is just age character long as key string battery voltage and there are then some field bit fields that indicate in which mode the radio son is transmitting also there is some more information on and let's say engineering data so reference temperatures are the PWM of the humidity sensor heating transmit power and so on and there is some important thing that I'll come to later there's also the subframe then we have the measurement block and in the measurement block the son sense the actual measurement values so the pressure temperature and humidity but these don't really look like physical units and they are not they are raw ADC values and like they are not using the internal ADC of the STM 32 here they're using a completely custom ADC implementation so these are very raw engineering data and you can see that there are three values for each measurement so there is a temperature measurement for the main temperature sensor and for the humidity temperature sensor but then there are two references a high I'm I'm just getting a little bit be a head in front of myself so it's a high reference and a low reference and the same as for the capacitive measurements as well for the humidity and for the pressure and there's also thankfully it's nicely encoded the temperature of the pressure sensor module and in case you don't have a physical pressure sensor fitted on the pressure is just blank also interesting is the GPS info because radio sound hunters they want to hunt the radio sound so they are more interested in the GPS than they are in the PTO values so we have the GPS time we have some parameters on the fix and also some parameters on the satellite that the radio sound is receiving and quite unusually a raw GPS data section so it turns out Weisler actually has their own differential GPS algorithm and they need the raw pseudo ranges and Doppler shifts so I just go a little bit back you can see like almost a third of the of the whole frame is taken up by this GPS raw data all the pseudo ranges and Doppler shifts but we don't really need that because in the next field we already also get a nice GPS fix it's easy F and not that long but a few lines of code will take care of that and you just need to do a little bit of coordinate transformations and also some accuracy estimates as well don't know why I have two of these slides so what's the information that we want to take out of this obviously like the GPS fix is the most important information because we want to find the radio sound also the serial number is for people who want to visualize the radio songs on nice internet sites like sony hub.org they want to know the unique serial number because they don't like it if there are two radio songs with the same serial because they will have the same track so it's very important that if there's a unique serial number somewhere encoded in the transmission that we find it out also the RS 41 has some timers a kill timer and a burst timer so the kill timer activates from the moment that the radio sound is launched and the burst timer from the moment that the balloon bursts and after a certain amount of time that this is defined within these timers the radio song will turn off itself to free the frequency if there is not enough frequencies available and obviously if there's a kill timer then you need to be at the radio song landing site before the kill timer activates in order to get the signal also like the engineering data battery voltage runtime is important as well but the PTU data I mean it's nice to know how warm it is and what the humidity is but I mean we are no meteorologists we just want to get the radio songs right and I want to take you on a small tangent here and want to tell you a little bit about the ground project the ground project is the reference up a network of the WMO so the world meteorological organization and it provides the reference data for example for research climatology and satellite calibration so very important stuff and they use radio songs they have high requirements for their stations and the radio song that will they will use as well and they develop something they call ground data products for each instrument they want to use because they figured out that there's a lot of black box stuff going on with all these meteorological instruments and time has shown that it's not always good to trust manufacturers because if they find out that there's a problem with their data then maybe 20 years of climatology of data relevant for climatology is biased and we don't really know how to correct it so it's very important that we know how this data is being made so the ground data product is open source manufacturer independent peer reviewed and provides a measurement error these are the criteria for a data product to be considered a ground data product and that sounds quite nice for what we in generally want to do like open source sounds nice when you have manufacturer independent sounds nice that's I mean fairly close to what we do but we need to know that this is like the next step after this engineering data if you know where the sound is in time and space you don't really know how the wind is there because there's a pendulum motion effect and you need to correct for this pendulum pendulum motion effect if you know how warm the temperature sensor on top of the radio sound is don't really know how warm the air is in the vicinity of this temperature sensor because this temperature sensor maybe heated up by radiation or it might be cooled by evaporation if it just passed through a cloud and you don't really know what the humidity is because the humidity sensor may experience time lag phenomena where it doesn't change the water the water vapor within the that is the water that is trapped within the humidity sensor can't escape so quickly as the external ambient values change so this is really what the ground project is after so they use the physical ptu values that the manufacturer gives them and then they do this kind of correction with the ground criteria and this is nice for us because if we have the physical ptu values then we get for free with a ground project basically a high reference open source data product that we can use and also I mean you saw those raw engineering values I mean they're not really physical ptu values and who know who knows what sort of magic is going on in coming from these ADC values to physical temperature pressure and humidity values and if maybe something could grow wrong there for example with the calibration data or so on so that's an external layer of security added to what those guys are doing doing with Gruen as well so for the next thing we need to look a little bit on how Weissler does their decoding and they do the physical they do the physical demodulation and the decoding just as I showed you as well and that's the binary binary telemetry you see on the bottom left they also use some sort of non volatile memory data and this is the NVM data you see on the on the top left and then they do the raw ptu calculation and something drops out of there that's called raw ptu.xml file and from that the data product is calculated and the reports and messages are generated and Gruen attaches to the center block so they do their own data product calculation but they still use the raw ptu values as their input so if we could show that the raw ptu values that we can get with our open source approach and the decoding we have done so far is as good as the raw ptu values then we can make a completely open source data product so if we would implement the RS41 Gruen data product ourselves I mean it should be open source but the documentation is not really yet released but they're working on it and we figure out how to calculate the raw ptu values with the same accuracy then we would have a completely open source RS41 data product and I mean that's not something out of the blue the other radios on that are Gruen certified mainly are completely open source so the Gruen data product uses those engineering values so that's maybe just something that's special with this sort of radius on and luckily some firmware reverse engineering happened so in 2019 there was a new you reverse engineering protection law in 2022 the readout protection of the STM32 F100 was broken and then some people started to sending sending me binaries but I'm not really that proficient with STM32 assembly so I couldn't help them but then some TXT files started to go around the interwebs and it turned out that the sound calculates the ptu values internally as well and if you think about it that makes sense because the sound has a heated humidity sensor and in order to know how much the humidity sensor needs to be heated the sound needs to know the physical values as well and there's a hidden service menu and there's a hidden uart machine to machine interface just a little bit more on that one later sorry but first we need to know look a little bit into the second block that's the NVM transmission so when you are a legitimate user of the radio sound you have an NFC readout device and it reads out the NF non-volatile memory data directly out of the radio sound but it turns out and also the non-volatile memory contains all the configuration calibration data and status variables so all the other stuff that we're interested on that's not really part of the telemetry itself it's 800 bytes long and it turns out the sound transmits it as the subframe over 50 individual frames so we just need to con we just need to collect 50 consecutive radio sound frames and then we got the NVM data ourselves luckily and there's a lot of stuff in here a lot of engineering stuff but also here the calibration values humidity matrix calibration values and so on that we need to know to make use of the discovered algorithm also just a little bit about the service menu you can do a lot of stuff in here and it's really nice that's all I'm going to say about it for now but just make sure that I mean you can change the registers of the transmission chip using the service menu but obviously if you turn on the radio sound use those registers to change the transmission of the sound to the amateur frequency band it's not not a good idea to start the radio sound like this because if it resets then it will be back to the original frequency and you don't want that so don't do that please also there's one patent that helps as well because it has some formula that is important for the humidity calculation as well in it but this also means that our initial plan to make an completely open source decoding toolchain is now gone because this formula is patented so we know it but we can't use it don't know whether that really helps but it's nice to have I guess the formula so if we use those formulas and this data we still have the question is that PTU data any good so can we use it and that's what I looked into a little bit more detail while I was doing research at my university so we did a conference paper on that and it turns out that in generally yeah the temperature values they are really close so we're just like you have your histogram that shows the number of occurrences in or the number of data points in a data set that consisted I think about about 20 radio sound launches from a from a German institution that thankfully shared their data with us and it's really close so it's just like 50 milli Kelvin slow and I just put the datasheet values here the combined uncertainty and sounding here just as a reference so sorry the the first one on top is the pressure it's just about 0.05 hectopascals so I don't want to transfer transform that in Pascal's right now but the pressure is specced to 1 hectopascals and we're well below that the temperature is specced to 0.4 Kelvin and I think we're within like 50 milli Kelvin's here and the humidity it's specced at around 1.3% our age and if we use this this patented formula then we find that we are generally with a lot of values you're pretty close but we have some outliers that are up to 2% difference so that would add like half of the manufacturer specified uncertainty on top of that and that's not really something that we want to have so the humidity it still needs a little bit of work but in general you can show that the raw PtU data that we get out of the of the Weisler approach is the same that we can get with our own formulas yeah and that's basically the first part about RS41 telemetry now we want to look into Grodjevm telemetry and to do that we need to go back to the 1980s when radiozones still looked something like this this is the Weisler RS80 radiozone it's a pre pre predecessor of the current radiozone I think and it did not use any of this it has a completely analog transmission so how those kind of radiozones worked is that you had one transmitter an analog transmitter and you still had a you still had some sort of a data converter so you had an oscillator where the frequency determining element was the measurement element so the frequency of this transmitter changed according to the physical values and then you used this analog frequency to modulate the transmitter so you really got an analog frequency modulated on the transmission frequency that was respective of the data that you wanted to transmit and of course you only have one transmitter but you have a lot of sensors that you want to transmit so you use a digital switch to just turn around those if you see some really old pictures of radiozones they sometimes have like a little spinning wheel that's driven by wind that's an analog switch so as this wheel spins and while the radiozone flies it switches the different the different capacitors or resistors in circuit with a transmitter so you can construct this electromechanically as well and the DFM telemetry or the DFM radiozone format the first DFM radiozone was the DFM 90 and 1990 it was the first completely digital radiozone so it had an ADC it digitized all the values and it sent it sends out digital frames but it's still closely resembles how the telemetry of those old radiozones worked so you still have comparatively short frames only 224 milliseconds long and each frame only consists of the sensor data of a single frame of a single sensor sorry so that's quite different to what we saw with the RS41 which use one second frames also just how looks the DFM 17 from the inside that's just a picture from the internet I took and you can see it's basically identical so it has an STM32 microcontroller as well it has a pretty similar Silapse chip and it's interesting that this Silapse chip really is the best fit for radiozones so I think more than half of all the radiozones you can buy use one of those to Silapse transmitter chips you can also compare the telemetry information so you can see that the complete measurement cycle is four times 224 milliseconds so 896 milliseconds for the TU data for the DFM 17 and of course the GPS fix comes every one second so it's one second for the wind frequency range is the same modulation is the same draw has an advantage here because they only have a board rate of 2500 baud but uses similar frequency deviation so you got a higher modulation index and that generally helps with with decoding the radio sound data but with the lower baud rate comes a lower bit rate and GRO uses a Manchester decoding or a two-phase two-state phase shift keying as a line coding here as well so the bit rate is only half of that 1250 bits per second frame size of a single frame is only 35 bytes and GRO uses a different sort of error correction that is not as efficient so the data rate is generally much lower but on the opposite DFM data is much easier to receive than RS 41 data because of all the higher margins that you have here DFM decoding workflow I have some nicer pictures of that because that's already also part of my master's thesis so I prepared some nice pictures for that one as well that I can recycle here you have the raw FSK demodulated data so a baseband stream just as we had with the DFM as well sorry the RS 41 as well and you this consists of 560 half symbols because you have the Manchester line code every two half symbols two following half symbols are decoded as one symbol so then you do the Manchester decoding two half symbols get you gives you one bit and then you have 560 divided by two bits and then you can make bytes out of these and you've got some really nice even numbers here you got a two byte header seven bytes for the sensor and that's like what I said you earlier like just a sensor that's switched between those frames but on at some later stage like GPS was invented and there was still some place in this some space in these frames that was previously not used because the old microcontrollers couldn't transmit and measure at the same time so there was just like a bunch of I don't know really zeros or ones sent during this time so you still have 26 bytes that you can use for data or GPS values in here then there's a step for the interleaving and error correction it's only a hamming code used here so to be able to still have some amount of burst errors that you can correct there's interleaving going on so that way I think it's 13 bits burst errors for the for the data fields not really sure it's in the documentation and the open source documentation and from this intermediate form then you can construct a data frame and this is really what we are looking into in a little bit so for the set from the seven bytes sensor values you make a three byte sensor field and one nibble for a sensor ID because you want to know which sensor is being transmitted and for the data fields you from the 13 bytes you make six data bytes and one nibble for the ID but the ID is in the back not in the front and when you accumulate enough frames like four frames for the PTU data set plus some more frames for the alternating fields and seven or eight data fields for the GNSS data then you get a complete PTU plus GNSS data set so after the last step when we have those data frames decoded how does it look like I think it's very abstract at this point so let's just look at a snippet of data at this point so every frame consists of a sensor field and two data fields and with the sensor field you need to look in the first nibble to see the ID so you have sensor ID 0 1 2 3 0 1 2 4 0 1 2 5 0 1 2 6 so the force sensor field is an alternating sensor field where there's alternating values being sent and for the data fields you look at the last nibble so this is ID 6 7 8 0 1 2 3 4 5 6 7 8 and so on but because 224 does not share a common denominator with one second interval sometimes you have seven data fields sometimes you have eight and in cases no data available you also sometimes have an empty data field so by accumulating enough of these data you can construct a whole a whole telemetry frame so what do these sensor actually mean like you have a value for temperature humidity humidity temperature and then some sort of configuration so that is just an exemplary sensor configuration the general type of telemetry state the same all the way since the 90s and so there's a lot of different configurations of the different sensors and you can do the same for the for the data configuration as well and this is all stuff that is on github in the relevant decoders as well so just one thing that comes up a lot with DFM radius on telemetry that I want to mention as well as far as the telemetry concerned DFM radius on cereals still follow the same coding of the serial year year and then an ongoing number as it was previously but now the product serial additionally features the date of manufacture also there is no encoding of the radius on type within the telemetry so you saw earlier for the hour for the RS 41 in the subframe there was a clear identification in ASCII what sort of RS 41 it is this is not the case with the DFM radius on so there are some hints there's a polarity of the signal because different generations of radio sound use a different polarity there's also the sensor configuration so the number of alternating or fixed sensors and there's the data structure within the sensors so does it look like an in 16 does it look like ASCII basically most importantly it should be taken into account where the radio sound launched from so if you found a radio sound of a particular type from a certain station and you now have a radio sound in the air that has the same telemetry format then it's likely that it will be the same radio sound but if you just see on Sunday hub that it is identified as a DFM 09 maybe doesn't necessarily say that it's a DFM 09 it may be a different type of radio sound because there is some guessing going on with the decoders but there's no way to say for sure with this protocol so now I just want to use the last few minutes to talk a little bit about baseband decoders so what I showed you at the beginning the audacity data so just the FMD modulated baseband stream how can you decode it and a little bit of a disclaimer we will only take a look at analog baseband data as an input which is already FMD modulated direct so IQ FSK demodulation can have some advantages but they are mostly not about what radio sound amateurs radio sound hunters care about the sensitivity but more like frequency stability and so on in regards to sensitivity you can like get a little bit more of out more out of it but not that much getting the highest decoder sensitivity is not always a prime objective and it's a starting point because like in the 1980s and 19s this was all you had you had your your demodulation output on your analog radio and you could put this into a sound card on a on a PC and work with it so that's what I did for my master's thesis previously we had a decoder architecture that was based on a modified cost us loop so it did a full clock recovery and when once the clock was recovered then it did an integrate and dump on the on the passband filter data and then you don't know which Manchester polarity you get so you need to look into both variants so you don't know where your Manchester symbol starts if it's if you're in the middle I knew if you're in the start of the Manchester symbol so you need to decode change chains from this point on and you just add up the Manchester symbols and if that way you can see if you got a valid Manchester symbol or not and then you can correlate like literally with the with the literal header 0x45 CF to see whether you found a frame or not and depending on whether you got the right or the wrong Manchester polarity not polarity like the part where you are in the in the Manchester symbol the even or the odd decoder will output the right data and that was quite problematic because this is a really an analog implementation that's brought into the digital domain and we worked a little bit with a radio sound community and we made this much more similar to what amateur decoders already used so the new decoder architecture just uses a low pass filter at first and we then we just use a sample rate of the signal to calculate two masks the header mask and the symbol mask and then we just do a continuous cross correlation of the mask that we calculated previously and do a peak detection on it and in case we found the header then there will be a strong signal with the peak detection and then we found basically the signal this works of course best if there's long headers because if you have long headers then you have a stronger correlation between the header and the data so that sort of architecture is really targeted to longer headers so yeah that's a little bit of a problem but you can throw more calculating power at it and then it's it's no big deal and then you can do use a symbol mask and do another cross correlation that you just evaluate at the peak points you already know and quantize that and then you have your detected frames so where you previously could only do the correlation at just the numeric phase where you just correlate two binary numbers you can now due to the yeah the computing power computer power increase and so on you can do a correlation in the stream as well and that way you don't need any clock recovery because you say like my transmitter clock it's stable enough that during the duration of a frame it will not drift more than let's say a tenth of a symbol away that's of course the thing that needs to be there but we now have those digital transmitters digital receivers and they are fairly good at it so what can we make out of this DSP SV module here in this graph is the decoder that was previously in use I implemented the principle myself and already got a little bit of a improvement and the header correlation decoder is the decoder I showed you last so what you see here is the signal to noise ratio of a baseband signal a generated baseband signal and gross packet error rate that means you have two steps that you need to consider here first you have the packet detection so is the header recognized with this method but then if the header is recognized you may not have sufficient energy in the bits to be able to decode the field so you may all you may have some bit errors as well so my metric of gross PR takes into account the frames that are unused you unusable because they were missed or that are unusable because they got too many bit errors and you can see that there's almost a 3 dB improvement between those decoders and the bit error rate as well because you don't have this clock recovery step that adds additional clock jitter in the recovery but you're looking at the at the at the limits between the bits directly and the bit clock is usually more stable than the recovered bit clock also the folks over at Radio Sont AutoRX they did some comparison beyond Radio Sonts and this is using two different sorts of demodulation types so there's an FSK demodulator that was written specifically for this purpose but it's just a 2 FSK demodulator and there's also the approach that I just showed you so there's using RTL FM as an FM demodulator and then piping this output signal into the baseband decoder just like I did and generally for most of the Radio Sont type now they use the FSK demodulator because as I said it has advantages when you have frequency offsets there's also a comparison between the FSK and FM demodulators but it requires a little bit more in-depth analysis so I don't put it here you can look it up yourself it's all on GitHub so you can see that the required energy bit energy per noise for 50% packet error rate is much lower with the DFM Radio Sont than with the RS41 Radio Sont and that's to all due to all the overhead in the protocol that I showed you earlier also just as prior to last slide comparing different testing methods so what I did here was I used simulated baseband data with variable signal-to-noise ratio and that's good if you're comparing one decoder to another and just looking at the algorithmic implementation then there's also the variant of using simulated or complex baseband data with the variable EB over N0 and this is good if you're comparing one transmission scheme to another because EB over N0 is basically the variant of comparing different bandwidth requirements from different modulation schemes but both of these don't account for the actual radio receiver and its problems so if you want to take a look into the whole receiving chain then you still need to take a look into your whole receiving chain and what I found is that it's usually best to do the real testing pipe real analog data or real data through the decoder and the whole decoding chain and look how it performs and this also takes into account all the nonlinearities into the receivers and all the different testing scenarios that you might have so what I found is that if you really have a well-defined test case then the generated data is good but it can't replace real-life data which is unfortunately much harder to get also all I said here is published on on github or published in the literature as well and if you have any questions then don't hesitate to contact me I think we have time for a little bit of questions thank you very much this was super interesting we have four minutes so one question my good morning many thanks for the interesting talk what is your take do you expect to be radio sound data to be encrypted in the future or will we amateur still be able to receive it and decode it what do you think that's that's a hard one to answer I think within the meteorological community like generally radio sound hunters have a well-received image but of course that depends on how we all as a community behave and I can't stress that enough like there are a lot of nice people out there but there are also some people out there who are maybe not so nice so you need to take that into account on the side of the of the manufacturers it's difficult to to take a look at how how let's say the requirements will be there but I think with the environmental concerns as well there is a need that radio sounds need to be collected but now something you also need to look at a viscilla did a talk at at last year's tico about the environmental impact of radio sounds and they did an analysis that found that the total life cycle co2 emission of a complete radio sound launch is like I think a equivalent of 30 or 40 kilometer car drive you have to maybe take this numbers with a little bit of grain of salt as those co2 equivalents always are but that's like if we are recovering radio sounds and we're driving more than 40 kilometers are we really doing a good job there so in this field I think there will be a little bit or there will be some movement and it's hard to to give a give a good estimate on how things will go on well just one minute left thank you very much I hope you learned something and you had a good time yeah enjoy day three of gpn consider becoming a troll the venue needs you thank you very much