 Hi everyone. Thanks for being here and thanks for wireless village for having me. My name is Eric Reuter. I'm not sure how to introduce myself to this crowd. My work is not in anything that I'm going to talk about today. I teach and consult in acoustics and noise control. But my education is electrical engineering and I've been a lifelong electronics, and I'm not in training and so I look for ways occasionally to bridge those gaps although it's rare that those opportunities work out. But with the advent of consumer SDR devices in the last five years or so, I've been inspired to look at some of the wireless protocols that the railroads use. And my interest in this isn't to find ways to exploit them or break them. It's really to figure out where the trains are so I can go and take pictures of them and things of that nature. I'm part of a subculture of people who likes to chase trains around and photograph them. This photograph was taken in Apex which is just a few miles north of here a couple of years ago. I'm a ham AB1XO for the hams in the room. And then I'm on Twitter but I've only ever tweeted four times and two of them were in the last 48 hours. So I will send out some of the material from this after. I'm going to release some code as well. So if you want to find that stuff you can follow me and I hope I won't disappoint you. So when I put this together and wrote the abstract, I had planned to sort of break this into three parts. First looking at a survey of all the different wireless systems that railroads use in the United States. And then look at two specific protocols that I've spent a lot of time reverse engineering for no particular reason except to use them as learning tools for learning about SDR and getting radio and Python and RFID and things. So I'm going to go through that. I decided though to spend the time on those two things and not spend much time on the other protocols, but just very quickly. These are kind of the major uses of RF that the railroads use. There's voice communications. These have been around forever. They got narrow banded a few years ago but they're all still in the same block of frequencies. PTC and ATCS are both traffic control and protocols. PTCs had a lot of press lately. Distributed power, DP is a remote control protocol for locomotives. And then the two that I want to talk to you about today are the end of train, head of train telemetry system, the EOT system, and the automatic equipment identification system, AEI. So I'm going to jump right into the EOT system first. To really understand the purpose of the EOT, I'm going to spend a few slides on mechanical stuff and that's the braking systems for railroads. So if you have a locomotive or a set of locomotives and then a string of cars, you have to have brakes on the individual cars or you'll never stop the train. They're easily overwhelming the locomotives. So in the early days this was accomplished by having people run down the top of the train and turn wheels. It was very dangerous and inefficient. You really had to plan ahead if you wanted to stop the train. And that went on until the late 1800s and just around 1869 or so, George Westinghouse when he was 22, came up with and patented the first railroad air brake system which is very similar to what's still used. And the important thing to understand is that the way these brakes work is that they're intended to be fail-safe which is to say that the brake cylinders on the cars are actuated by air that's stored on each car. And so to apply the brakes, you actually reduce the pressure that you send to the cars from the engine. And that's important in the context of the device that we're going to look at here. This is how it goes together. You have in the engine the red stuff there, a compressor, a reservoir for air, it's fairly high pressure. And then there's a pipe that runs the whole length of the train and carries the air to each car which has a special valve called a triple valve, a reservoir, and then the brake cylinder and brake shoe and then that applies to the wheel. So there are three basic conditions that are important in the context of this discussion. The kind of standing state condition is when the brakes are off, the release condition. And during that time, there's about 90 psi of air being supplied by the engine to the cars. That charges up the reservoirs on the cars. So they're always being charged, sort of topped off. And then if you want to slow down the train, you do what's called a service application which means that you reduce, gradually reduce the pressure from the engine. The pressure in the reservoir on the car becomes higher than the reservoir on the car. And then that in the brake pipe, and some of that then moves the valve and bleeds off and applies the brakes. The other condition is called an emergency application. That's when there's a car stuck in the tracks or something and you need to stop the train right now. And to do that you vent the brake line to the atmosphere, you dump the air. So instead of reducing it, slowly reduce it to zero immediately. And that applies the brakes very quickly. The engine is very close to the the propagation rates essentially limited by the speed of sound. So the service application propagation is about 6 to 7 under feet per second. And then an emergency application gets up to about 900 feet per second. But a train can be miles long. So it takes a few seconds even an emergency application to get air all the way to the back of the train. Which means that the brakes are on at the front but not at the back. And the momentum of those cars are still pushing until that propagates to the back. So it's important for the engineer to know what the pressure is at the back of the train. For several reasons. When you start moving you need to know when the brakes are off. You need to know that the brake pipe is intact. That it hasn't pulled apart. And then if you're actually moving and the knuckle couple of breaks you want to know that the train hasn't pulled apart. So it's important to monitor that pressure at the back of the train. And for the first 110 years or so that was done by a human in a caboose. This is one of the principal functions of the caboose was to monitor the brake pressure. And then in about 1980 the caboose was no longer required by the FRA and they were quickly replaced by these EOT devices. Which is in the photo there. So the EOT hangs on a coupler on the back. It connects to the brake line. Monitors the pressure. And radios the pressure back to the engine. So the system is a two part two way system. Full duplex system. It's a frequency pair. And the EOT sends telemetry data forward. And the engine has a couple of commands that it can send back. And I'll get to that in just a second. But it is full duplex so if you want to hear both of them you have to monitor both frequencies. So some functions. The first one I've talked about. It also provides a flashing red light on the back of the train which is required for night operations by the FRA. These are sometimes called FREDS for flashing rear end device. And in that case the HOT is called Wilma. And then the last function there is that an emergency stop situation. The HOT the head end unit which sits in the engine can tell the EOT to dump the air. And that effectively dumps the air from both ends of the train at once. And applies it brakes much more quickly. This is the source of a security concern. That we'll talk about here. Specifications. This is the frequency pair I mentioned earlier. The RF power of the EOT is 2 watts. The antenna is in a terrible position. It's blocked by the bulk at end of a rail car. So the reception is actually much better any place but the engine. So it's easy to monitor these things. The modulation is a continuous phase fast frequency shift keying. Also called minimum shift keying. And the mark and space frequencies it's a 1200 bot signal. Mark and space frequencies are 1200 and 1800 hertz. And the way that MSK or FFSK works is that you have one cycle of your... Each symbol is either a single cycle of the lower frequency or one and a half cycles of the higher frequency. And the benefit to this is that the phase is continuous. Every time you get to a zero crossing you don't have a discontinuity. So it doesn't create a lot of harmonic noise. So you can use a very narrow transmission channel. For this to work you have to have either a marker space frequency that equals the baud rate. And so what I've plotted here is a 0101 sequence and you can see that you have for the ones a full cycle of 1200 hertz and for the zeros one and a half cycles of 1800 hertz. The phase is arbitrary. It's dependent on the previous symbol. So if you look at every other sine wave or every other one the phase is opposite. So it's the frequency that matters not the phase. So frequency shift keying or fast frequency shift keying of this type is a type of AFSK audio frequency shift keying which means that it's a sort of two part modulation demodulation process. So to modulate it essentially you take a bit stream and you generate audio. And that audio may never be heard or see the light of day but it becomes an audio signal. And then you can transmit that through an audio channel or a channel that's designed for voice communication. So in the early days of data modems that was the type of transmitter that was available. So you see a lot of this in older protocols like this. And then on the other end you do the opposite. You can demodulate the audio and then demodulate the bit stream. And I'll show you that processing in your radio. Alright so these telemetry packets have been used for a long time by rail fans, people who like trains, to tell when a train is coming. If you're out waiting for a train that you want to see and you start to hear these chirps, telemetry chirps, that's how you know there's a train approaching. But I always wondered what they were actually saying. And so that was sort of the motivation for this project. And there is a Windows software called Soft EOT that does this but it's not open source and I really wanted to dig into it and understand it. So the first clue I got was this figure from a patent. The patent was from some proposed improvement or something that probably didn't go anywhere but they had this figure in there that has the packet format. So they have up at the top the bit sink and the frame sink and then what's in the actual packet. And so starting with this I was able to do some additional research and come up with what I think is the packet contents for a modern EOT. This has evolved a bit over the last 40 years as the technology's gotten better. The important things here though are the unit ID and the pressure. And then there are some other flags for things like battery condition, whether the rear end light is flashing. A lot of these units now are powered by a turbine that bleeds some air off of the brake line to charge the batteries to keep them running indefinitely. And so these fields are all clear. You can, if you know where to look inside of the packet you can get the data. They are validated though by a set of 18 check bits using BCH air correction. And I'll explain a bit about that in a moment. But here's a first attempt at decoding this. I just recorded an audio sample off of a scanner or one of my HTs or something. And this is Audacity which everyone who works in SDRs has seen in many demonstrations. Since this is 12-in-ear BOD, if you record at 48 kilohertz, sampling rate, every symbol is 40 cycles or 40 samples. So if you get lost kind of going through this looking for whether it's one cycle or one-and-a-half you can just measure 40 samples and kind of figure out where you are. So I put a comment track down at the bottom there, or two actually, and went through the whole thing and just typed 0101 and then correlated that to what I knew those fields were. I knew the unit ID for this unit. The unit IDs are all printed on the side of the BOT. So if you can see it you can get the unit ID from there. And I discovered that it was all of the multi-bit fields are little Indians. So you have to reverse them before you convert them to decimal. But this is unit 10603 and the pressure was 66. All right, the BCH code. If you just want to know what the data contains then you can just look at these fields. If you want to actually validate the packet you need the BCH code. So BCH code is a type of CRC forward error correction. How to actually calculate the generator polynomials is another lecture that I'm not qualified to give. But I'll give you an example of how to calculate the check bits if you know the generator polynomial. And this is similar to any CRC calculation. So this example is the simplest one that you can use. The seven four code and what that means is that there are seven bits in a code word. And four of those are actual information. And the other three are the checksum. And typically you would take the information in the checksum and concatenate them to come up with a check word or a code word. So here's an example of calculating that. The first step is to take the order of the generator polynomial which is third order. The generator polynomial is 1011 in binary form. And then you pad your information with the same number of zeros as the order of the polynomial which ends up being the number of bits in the polynomial minus one. And then you just mod that. So we don't care what the quotient is, we just care about the remainder. And the remainder is the check, are the check bits, is the check bits. So in this case we take 011 because we know it's three bits and concatenate that with 1010. And that's our code word. So there are 127 possible seven bit binary numbers but only 16 of them are valid, valid code words. And you'll notice here that any code word, any valid code word, if you rotate it, that's also a valid code word. So that's the sort of cyclic nature of this. I've done a sort of linear list of valid code words and not valid code words which is a gross over simplification because what you're really after is the hamming distance which is the number of bits that you would have to change in an invalid code word to get to a valid code word. And for that, for this code it's very small. You can only correct one error in this code because the hamming distance is like three or a minimum of three. But in the BCH code for the T packets we have a lot more check bits. So we can correct a lot more errors. However, there are two ways to validate a packet. One is to actually do the error correction and the other one is to just recalculate what you know the check bits should be and make sure they're the same. So in a non-critical application like this one certainly is, that's a much easier way to do it. So you basically just, you know, use your generator polynomial, mod it with the data and see if the bits that you received are the same as the bits you calculated. At least that's what I assumed would be the case. It turns out it's not quite the case for this. So the BCH code in the EOT packet is a 6345 type. So there are 45 bits of information and then 18 bits of check bits. And this took, this probably took the longest time of any of this to figure out. They actually first reverse the order of the whole data block and then they calculate the, then they calculate the check bits here, the BCH check bits. And then for some reason they XOR that with a 18 bit string. I think there's probably some technical reason for that. I don't have the sense it's a security reason, but because obviously you could just, if you know the right answer, you could just XOR it with what you have and get the key. So I don't think it's a security thing and maybe one of you has an idea about why they do that. But anyway, then they take the encrypted, I hesitate to use that word, but encrypted check bits and concatenate those with the original packet, not the reverse packet. So this took a lot of futzing around to figure out, but once I got it, I could reliably recreate the check bits and compare them to validate my packets. Alright, so the decoder that I put together is in two parts. The first part is GNU radio and in GNU radio I'm going to take the IQ data from the SDR and demodulate it to audio and then take the audio and demodulate that to a bit stream and then send that to a ZMQ socket. And then in a separate Python script which could be local host or anywhere, I'm going to grab that ZMQ pub sub socket and parse out the data fields, compute the check sum and validate the packet. So here's the whole flow chart. It's very simple. I've tried to keep everything very simple here. I'm going to zoom in on this, but that's the whole thing. So basically RF stuff on the top and audio stuff on the bottom. So the upper right, upper left corner, I have the Osmocom source there. Low pass filter drops it to 4kHz bandwidth which is still more than we need. A squelch which I actually haven't been using and I'll explain why in a moment. And then moving over I have a resampler to get it down to 48kHz audio and that's way more than we need for this application but I wanted this to also be able to read a wave file. So I just did everything at 48kHz so I can read a wave file in for testing. And actually if you feed a source, an audio source from the laptop microphone into this and just put a radio next to it, it will decode the packets. It's a pretty slow data rate, pretty robust format. Audio sync if you want to hear it. And then the line that goes back across is audio at this point. Then I go into a frequency translating FIR filter and what I'm doing here is shifting the center to a point that's halfway between the mark and space frequencies. So the zero point now, the zero hertz point used to be 1500Hz and what that does is it makes the space frequency positive and the mark frequency negative. And so the complex output that that creates goes into the quadrature D-mod block and in simple terms the quadrature D-mod output is proportional to the frequency of the input or the instantaneous frequency of the input. So if you shift the input such that you have positive and negative frequencies relative to that midpoint, it's very easy for the quadrature D-mod block to figure out whether it's a mark or a space, essentially with two samples. I'm using four but even that's more than we need. The mark frequency is the lower frequency so I have to invert the logic which is why I'm multiplying by negative one. And then I'm resampling that down, oh smoothing it, resampling it down to four cycles per symbol instead of 40, so just dividing by ten. And then clock recovery, binary slicer and then the CMQ pub socket or pub sync. The output of the binary slicer is bytes. So there's a byte that represents each bit so it effectively increases the data rate by eight. And the bytes are like 0x00 and 0x01 so they're not ASCII 0 and 1, they're actual hex 0 and 1. Just to quickly show you the steps in this graphically, this is just that same 0101 test signal that I showed you earlier in green. And then the output of the quadrature D-mod block is blue. So you can see when the frequency is 1200 it goes down, the kind of sinusoidal signal goes down and when it's 1800 it goes up. And then the binary data that's after the slicing and the logic's been inverted. So it's very clean and seems to be pretty reliable. I don't think you'll be able to read this but this is up on GitHub. This is the routine that essentially connects to the socket. And what's coming in is arbitrary chunks of 1s and 0s. So it might be 1 byte, it might be 20 bytes. If we have time I can kind of show you that. What's coming through. So what I'm doing is I'm putting each of the new blocks that comes in that I read, 1 byte at a time into a deck that has a finite length that's more than I need more than the packet length. And then every time I put a byte in I take the whole thing put it in a buffer and see if my frame sync sequence is at the top of the buffer. And if it is I know that it might have a packet. And so I go then into a class that parses out the data and does all the acrobatics to figure out the checksum. And if the checksum checks out it sets a flag and then the main function prints it, calls another function to print it to the screen which I'll show you. This will be easier to see if it's in front of you. But that's the process. There may be a more efficient way to handle that but I'm not very good at pythons. So this is, but it works. It seems to work reliably. All right, so here's a field test and I, I'm going to just, sorry, just wanted to have audio for this is not important but it makes it more dramatic. So there are two packets arriving. There's no reason to be this close to the train. You could be a mile away. In fact, I was testing this this morning in my hotel room on the other side of the strip and I was getting packets from a train going by, no problem inside the building. So it's, it's, you can, you can receive these things pretty far away. All right, so I want to do a live demo. I have loaded up here on my HackRF with Portapak audio files that are packets and this is going to transmit them. I'm using one of the handbands, the 440, 70, centimeter handband so that we don't transmit on the actual railroad frequencies and I can ID and all that to keep this legal. So really there are just two parts of this. I'm going to hit play on the flow graph here and then I'm going to run once it's up and, you know, once it gets settled here, I'm going to go over here and run this, oops, pi e o t dot pi. I wrote all this stuff in Python 3 because it's 2018 but of course GNU radio is still Python 2 so you kind of have to run them separately at the moment but hopefully in the future that will, you know, kind of get integrated. And I'm just going to play, I'm just going to loop here a kind of demo sequence that has a number of packets in it. And I have my ht on here so you can hear the chirps. And we're not getting all the packets. This is a noisy environment. Oh, there we go. I put an attenuator on this and I probably shouldn't have but you can see there are three different packets that are kind of flowing in there. And what, I've just picked some interesting fields to display. This isn't all of them but I have the ID and the pressure and whether the train is moving, whether the marker lights on, that sort of thing. One of the things about, another thing about, I'm going to stop this. Hold on. The other thing that Detail might be helpful in this is that railroad cars, the couplers all have slack in them. They're in gearboxes so when the engine starts moving, the first car starts moving and then the second car starts moving and then you'd never be able to start a two mile train if it were all rigid. So this helps the engineer, this motion marker helps the engineer know when the back of the train is actually started moving. And some of the more advanced DOTs use discretionary data to actually tell the direction to. That's the thing, they're kind of, you know, the standard came out and then different companies kind of use different discretionary fields to do different things. I'm going to go back to PowerPoint here. So security, I haven't talked much about the HOT part of this. The standard has two commands for the HOT. One is a status request. The EOT broadcasts its data every minute, give or take 10 seconds, but if the HOT hasn't heard from it for a while it can request status. The other command is that emergency breaking command. The security that's built into this is sort of to prevent a rogue HOT from initiating an emergency stop for an EOT. And so there's an arming sequence where you press a button on the EOT and then you press a button on the HOT and then it acknowledges and then that HOT is allowed to send the emergency signal. The problem though is that there's no way for the EOT to know if that actually came from the HOT. So 40 years ago that wasn't really a big concern, but now it is. And this is something, this is not, I didn't discover this, this is known about in the industry for years. There's a paper from 2005 from the Joint Rail Conference in Pueblo where Paul and Stephen Craven, who I seem to be related, wrote about the vulnerability of spoofing the signal and provided some recommendations for a key exchange. As far as I know that's never been done. So the code that I'm putting up on GitHub does not deal with the HOT at all. It decodes the EOT and that's it. It doesn't generate packets for either and it doesn't even decode the HOT. It's not especially interesting to look at the HOT. It rarely broadcasts and the chances of catching that emergency packet are very small and for that reason a replay attack isn't really a big concern because it's such a rare event. Alright, so the other protocol that I want to talk about, and we're right at 430, so that's good, I'm halfway there. Give me just a second here. Is the automatic equipment identification system, AEI system, and this is an RFID system that's used for identifying equipment as it passes a reader, essentially. So back in the 60s the rail industry started looking for a way to do automatic equipment identification and what they came up with initially was one of the first bar codes. This is a system called car track, oh I'm sorry let me put this, make it back here so you can see it. Come on. Alright. Car track, which is a bar code, a colored bar code that went on the side of the cars, and they worked really well until they got dirty and then they didn't work at all. So the whole thing, the whole mess was abandoned in 1977 and then through the 80s they tried to come up with another way to do this and settled on RFID. So by 1994, 1991 this mandate went out and by 1994 every rail car engine in the U.S. had an AEI tag on it. This is an actual AEI tag here. So it's a RFID tag. Some of these slides I made for a less technical crowd so I'll go through them quickly but essentially in any RFID system you have a reader and a tag and the tag is usually a passive device, sometimes they're battery assisted but essentially the idea is that the reader sends out RF power and that powers the tag which then spits back some data. And there are a couple of different, broadly a couple of different types of RFID. The lower frequency ones where antennas would be impractical, they're very long, are inductively coupled. So most of the access, like door access systems and things of that nature, you have a coil in the tag and you have a coil in the reader and you get them close together and they couple like a transformer. At higher frequencies it's practical to have antennas that are, you know, reasonable relative to the size of a reader. And so you can do some long range stuff where you actually send the power out pretty far and get it back. So a common application is tolling, for example, you know, high speed tolling. The system that we're going to look at is in the 900 megahertz ISM band and what else do I have here? Yeah, long range, et cetera. There are two standards that apply to AEI. One is this ISO 10374 which is an old, you know, antiquated by any other standard outside of the real industry. Air interface protocol. The air interface protocol essentially defines the exchange, the way the data is exchanged and the format of the ID, the data that comes back. In this case, it's 128 bits. And so then whatever your application is, you decide what those 128 bits mean. And so the AARS 918, AARS, the Association of American Railroads, S918 protocol or standard then defines what those 128 bits mean and where the tag should go on the car and things of that nature. I think that's been replaced now by S9203 and then by S6009, but I don't have copies of these so I don't know for sure. S918 is pretty old but nothing's changed, you know, in this. Here are the fields that the tag contains. There's the type of equipment whether it's an engine or a car or there are others trailers, you know, some other special types of equipment. The reporting mark which is a four-letter identifier that tells you who owns it. So if it's UP, it would just be UP, you know, Pacific. If it's a company that isn't an actual railroad but so up to four letters, isn't an actual railroad but leases equipment then it would be there would be an X at the end. So like GATX is not a common carrier but they own equipment so there are reporting marks assigned to anyone who owns rail cars. And then you have the which side you're looking at. There's two tags in each car and that's related to the end that has the handbrake looking from the end that has the handbrake. The length of the vehicle, the car or engine, how many axles it has, what type of bearings it has. They're all roller bearings now but back in the early 90s there were still some friction bearings. And then there are a number of additional equipment dependence parameters like engines have slightly different data than cars and then there are actually some provisions in there for active tags that would tell you things like how much fuel is left in the engine or things like that. As far as I know those don't exist but they are on the standard. So the performance depends on basically two things. The effective radiative power of the reader and the speed of the train. So you get more ERP by narrowing the the polar pattern of the antenna but then you have less time to read as the train goes by within that window. Now, typically I'm seeing dozens of tag reads for each tag as it goes by so it's pretty fast. The maximum I was able to get was about 20 feet for a 70 mile an hour Amtrak train. And that was at 32 watts ERP using a two watt radio but a very high gain antenna. The ERP calculation is an example if you have a two watt transmitter and a nine dbi antenna. It's two watts times 10 to the nine over 10. So you end up with about 16 watts ERP. So if you go up to 11 dbi antenna or 12 dbi antenna you'll double that again. There are a couple of different readers on the market. And to be clear I'm not doing this in GNU radio. That's possible but it exceeds my skill level. So I went for a commercial reader on eBay essentially. So there are two types you can get. One is a kind of low power one watt and the other is a high power two watts. And the one was a part 15 device which means anyone can use it without a license. But for a railroad application you have to be very close to the train and it's unlikely that you could get that close and not be trespassing. So the low power option is kind of off the table. The high power reader you can run at two watts and attach any antenna you want. And for a commercial application you would get a part 90 license from the FCC which is a site specific license. I did my experiments using my amateur radio license privileges. So amateurs can operate up to 1500 watts in the 900 Hertz band. I operated two. So not a big deal. And I found that I could ID by toggling the radio using Morse code and toggling the radio in the device to keep it all legal. So the one that I bought on eBay was a Sirat ID 5100. Sirat was a really great company and then 3M bought them and scuttled the whole thing. But this product was it's about this big. And it was designed for tolling and like parking garage access applications. It happens to support ISO 10374. Although you have to find somebody who can install that key for you. I found a former sirat employee who was able to do it. And you can use it. It has a built in antenna or you can use an external antenna. I used a 90 BI Yagi from my experiments because it's less obvious than this big panel thing. And it's a pretty robust device. It runs Linux internally and you can upload over TCP pythons or JavaScript scripts and it has internal storage so you can have it do logging on its own. All it needs is power. It has GPIO lines. It has a serial port. Most of the communications over ethernet. So it's a really cool device. I've never seen another one on eBay since I bought this one. So you may have trouble finding one. But what I got out of it is 128 bits. So then I took the AAR standard which I easily found in a Google search and took those fields and wrote Python to parse them out so I could make it readable. So this is actually the first test which went unusually well of that software that does the parsing. So this is Amtrak about 70 miles an hour. And you can see the tag data populating as the cars go by. Oh, thank you. That's very kind. Thanks. So the fields going across we have a time stamp down to millisecond and then Amtrak, the car number or engine number, whether it's a car or an engine or locomotive. And then what side we're looking at. So you can tell which way the train's going from the side because the engine's either facing left or right. And then the length of each car, how many axles it has, et cetera. So I wanted to, I mentioned earlier that my work is in noise control and I do rail noise occasionally. So the pretense that I used to get information on this, to do this project was that I wanted to try to correlate noise data with AEI tag, you know, the equipment that creates the noise. And then it turned out to be a viable research project so I went ahead and did it. So I wanted to do logging long term. So I found some, I found a property owner who was cool with it that was very close to the tracks but not on the railroad property. And to do this, you really want to do triggering because you don't want to just spew 32 watts of square wave all the time in any environment, especially in the ISM band. So the railroads do this with wheel flange detectors. I couldn't do that obviously. I couldn't touch the track. So I used ground vibration. This is a seismic geophone. Geophone's like a microphone that you bury and it outputs essentially audio but there's nothing above a couple hundred hertz. And we use these for measuring propagation of vibration through the ground. But I put this one as close as I could get it to the tracks and I wanted to make sure that the ground wave that precedes the train would arrive soon enough to get the radio turned on to get the first tag. So this is a wave file down here. And essentially I have about one second of warning at 70 miles an hour, which is plenty of time. So that was the kind of proof of concept. This is a little circuit I built to do the actual triggering. So it's just a dual op amp. On the left side is a differential amplifier. The output of the thing is differential. About 70, what was it specifically? 73 dB of gain, which is arbitrary. This side is just a comparator and then I have a threshold control that's the other side of the comparator. So I could basically set this up with an LED and just turn up the threshold until it stopped blinking under normal conditions and then when the train goes by it'll trigger. So this goes into a GPIO line on the reader. And I have a Python script running on the reader that looks at that and then toggles the power of the radio, either puts it from standby into active mode and vice versa. So here's a video of that. The little circuit's down in the left corner there. I don't know if this is playing. Whoops. I really want to play this, let's see. I guess it is playing, okay. So the circuit's down in the left corner there. You'll see the lights start to blink. And then the top terminal window, which you probably can't read, says that it went into active mode and then it's reading the tags and then after the ground vibration drops below the threshold on the comparator, the script drops it back into passive mode. And if it goes into active mode, when a truck goes by it doesn't really matter, you're not going to lose any data or cause a significant amount of RF pollution. So that worked pretty well. So I put this box out there with the reader in the box. Sorry, can't see that. With the reader in the box and then I have an ethernet hub and a cellular modem and a Raspberry Pi and a sound level meter. And essentially this is about 30 miles from my office so I just had the Raspberry Pi do a reverse tunnel out to a digital ocean droplet and then I could get to it from there and experiment with it remotely. It's also the remote control of the radio which is important for amateur privileges and the reader's just logging all of the data so I log for about five weeks. This is the Yagi, it's on an old shed, about 15 feet from the rail. And then there's also a microphone on a stand that's logging the sound level meters, logging the data from that. So this is what comes out of the reader, raw tag data. So we have 128-bit tag IDs and then I can translate into something like this. So this is a single train and you see a locomotive at the top and then all the stats and then the EOT actually has its own AEI tag. So at the bottom you see the EOT tag with that's one of the possible devices. So we have locomotive car, car, car, car, car, EOT. And since I know the length of the train and I know the time stamps, I can actually calculate the speed also. So I've got the length of the train, the speed and then I can, in most cases, can summarize the direction from the direction the engine's pointing. Then I can take that and turn it into a list of trains. So this is a list of trains where I have a time stamp and then the number of engines plus the number of cars, which direction it was going, how long it was, how many axles and how fast it was going. You see only a few of them have EOTs. EOT only has a tag on one side. So if it's going the other way, you won't catch it. Railroads have readers on both sides of the track so they can, for redundancy, but they can also catch if there's a missing tag or whatever. So I didn't catch all the EOTs but you'll see there's one train in here that's like 8,000 feet long. So that's a very long train. And this is in New England. We don't get a lot of 8,000 foot trains, so that was an exception. All right, so here's an automatic correlation of sound data down on the bottom. So these are one-minute LEQs or one-minute average levels and then each blue dot is a train from the AEI data. So you see they line up very well. Every time there's a spike in sound pressure level there's a train and we can do some interesting things like look at eastbound Amtrak trains versus westbound. You can see the westbound ones are much louder and that's because there are trees over here and not over here from the microphone position. And you can look at anomalies like that one at the end of the red trace is lower than the others. There was a slow order or something so it was going slower than usual. So a lot of interesting data from this and my conclusion was that this is pretty useful for noise surveys when you need to know what the equipment is. Instead of having an intern with a clipboard writing down everything, you can log the stuff automatically. But the problem is that it uses a lot of power which is you can overcome that but also you need a site license. It's not a license for the thing, it's a license for the thing at the place it's gonna go. So for a short-term project it doesn't make any sense. But it does work so it was an interesting, turned into an interesting research project that started as just trying to see if I could do it. Security, there's nothing on these tags that isn't also painted on the side of the car. The number and the owner and all that stuff. So you could conceivably do this with machine vision or an observer or videotaping it writing stuff down. So I don't really think that there's any meaningful security concern with this. There's no indication of the type or presence of the load in the car. So we don't know if it's anything's in it at all or what it might be. But there is a sensitivity in the industry to private readers, which I think is just kind of a knee-jerk reaction. And a lot of that, it really flamed up about five years ago when this company called Clipper Data bought 30 readers and rented people's backyards along rail lines within internet connections and they were gonna aggregate the data and sell it back to the shippers or something, some sort of commodities thing. And BNSF found a couple of the readers and flipped out. And the end of the story was that Clipper Data had only applied for an FCC license, or been granted an FCC license for one of the 30, which I think was just a misunderstanding, but they got fined a quarter million dollars by the FCC for the other 29. So the whole project got put to rest. But this is actually what got me thinking that maybe I could do this. Because I always assumed it was kind of a proprietary thing that the railroads had locked down, but there are actually very few things like that I've learned in the last three years. And then finally, if you're gonna try this, make sure you have a license of some sort, whether it's a commercial license for this application or an amateur license with privileges. Actually, any amateur license has privileges in this band. And make sure you're not at railroad property. That's really important for any of the stuff I'm showing you today. Railroads do not like trespassers and they will prosecute. So I'm not an attorney, certainly. Do any of this at your own risk, but I recommend those as a starting point or starting points for any kind of experimentation. And that's about it. Here are some resources. The PIEOT software that I demoed is up on GitHub. And I've listed here a couple of Windows applications that do railroad telemetry decoding. One is SoftDOT, which I mentioned earlier, which takes in an audio signal, so you have to have a radio external to the computer and decodes the OTs. The other one that's interesting is ATCS monitor. ATCS is one of those traffic control systems. And things like signals and switches and other devices spit out data with their status and they're also controlled with RF link. And there are people all over the place that monitor these things and the data get aggregated. It's sort of like the ADS-B stuff for planes. And you can use ATCS monitor to look at a panel. For example, in Las Vegas, you can look at 100 miles north of here and see this aspect of every signal, whether it's red or green, and which blocks of track are occupied. So it makes it very easy to find trains, but we don't have this in New England, so I've never really done much work with it, but it's pretty cool. And then if you wanna read more about BCH code, Wikipedia page is a good starting point. There are also a couple of good articles that you'll find right at the top of a Google search. It's pretty interesting stuff. And that's all I've got. So thanks for your kind attention. I appreciate it. I think there's a couple of minutes. If there are any questions, yeah. Yeah, so the question is, I think, if you stand behind an existing reader, can you read the tag data? And the answer is not, I'm not sure. I tried that in my office a little bit, but there aren't any readers that I have access to that are out there. So I would have to set up one and then I just haven't done that exercise, but it is something that I've played around with a little bit, because that obviously is a much less intrusive way to do this. Yeah. Crossing signals generally use track circuits. So essentially the train shunts the rails and then there's the fancy ones use like TDR to figure out the distance and the velocity of the train. So a faster train, the gates will go down sooner. As far as I know, that stuff doesn't have a wireless component to it. If it's anything, it would be that ATCS data, but I haven't really dug into that. Oh yeah, that's an important point. So this is really only, the EOT stuff is only freight. So passenger trains have electrical connections all the way through so they don't need it. As far as light rail, that would be really specific to the, if there's no interchange service with other railroads, then there's no requirement to comply with the AEI tagging, for example. I know that some of the light rail systems have their own RFID systems for tracking. Whether they're compatible, I don't know. I haven't played with that. All right, well, oh yeah. Oh, I would be happy to. You'd need a reader for it to make any sense. So it's a little, there's a higher barrier to entry, but yeah, I can put that up there too. Great, well thanks very much.