Homebrew SDR/Trunking/Decoding Project

[botenredwolf]

Yeah, I know there's tons of tools out there for it, Unitrunker's my favorite, as it's a phenomenal piece of software. However, it doesn't run on Linux, even with WINE I haven't been able to get it going yet, so it dawned on me as I come towards the end of my final semester in an Electronics Technology/Engineering degree program, that I could see if home-brew SDR trunking that can run on a small embedded system (like the Atlas SoC board, Raspberry Pi, etc.) would count. Well, the instructor got excited about that. The first non-IoT project presented in a while.

However, I slacked a bit and presented the idea a little late, so I'm hoping I can seek some help from people with inside knowledge of some of these systems. Got about a month, so this isn't a "do my work for me" thread, but I can skip the hardware side of things and focus on software, so that makes things easier.

So, the run-down:

Needs to fit on a small embedded system. Most of the ones used have ARM CPUs, run on Linux. My embedded system also happens to have a 26k LE FPGA on the SoC, but doubt I'll have time to implement anything on that side.

I've got the now-famous "RTL-SDR" receiver(s) to be controlled by the software that is the focus of this project. Due to the technical knowledge required to put this system together, even a tool like GNURadio and the GRC front end don't necessarily make it "too easy" for his requirements.

I've been playing around a little with GRC and have learned enough about how it operates as a front-end, but not necessarily what I'd need to know to acquire a data stream, parse/process it into something usable, and then feed that out in such a way to train another tuner onto a frequency, acquire a data stream, and feed it into a decoder (whether dsd, dsd+, etc.) if it's a digital voice channel. That's where I could use the help.

The radio networks I have available near me to use include the following:

The one I monitor the most using both a Uniden BC898T for being lazy and Unitrunker/RTL-SDR for when I really wanna know what's going on, the City's common SmartNet system. All city-funded services use this system; PD, FD, EMS, Metro Transit, Public Works, Parks, Streets Division, etc.
Madison Area Public Safety Trunking System, Madison, Wisconsin - Scanner Frequencies
This one is what I'm gravitating to by habit, but it seems documentation on the SmartNet systems is nearly non-existent.

Another one in the area that's brand new, and of most interest to me, but I know nothing about how it operates since I'm used to the Motorola network and this one is P25 Phase II. It's our county's new common system for county-wide and outlying town dispatches for sheriff, outlier PD and FD, etc.
DaneCom Trunking System, Madison, Wisconsin - Scanner Frequencies
I believe this one may be more productive since it's a newer system and likely more relevant, as well as being busy enough to get regular traffic on. I do have signal strength issues, but there is another P25 network nearby I could use as well, although much quieter, and of the Phase I variety.
Wisconsin Interoperable System for Communications (WISCOM) Trunking System, Statewide, Wisconsin - Scanner Frequencies

I know this first post is a bit of a mess, but my thoughts will likely narrow down a bit once the discussion starts moving...

Anyone have any thoughts, ideas, productive places to start looking, or other random tips or ideas? Thanks in advance.

 

[slicerwizard]

Due to the technical knowledge required to put this system together, even a tool like GNURadio and the GRC front end don't necessarily make it "too easy" for his requirements.

I've been playing around a little with GRC and have learned enough about how it operates as a front-end, but not necessarily what I'd need to know to acquire a data stream, parse/process it into something usable, and then feed that out in such a way to train another tuner onto a frequency, acquire a data stream, and feed it into a decoder (whether dsd, dsd+, etc.) if it's a digital voice channel. That's where I could use the help.

Using those tools may push the CPU load to where you don't want it to be. Can't say for sure as I don't use them. Working more direectly with an RTL dongle isn't that difficult; the rtlsdr driver gets the device tuned and passes the I/Q data to you.

The one I monitor the most using both a Uniden BC898T for being lazy and Unitrunker/RTL-SDR for when I really wanna know what's going on, the City's common SmartNet system. All city-funded services use this system; PD, FD, EMS, Metro Transit, Public Works, Parks, Streets Division, etc.
Madison Area Public Safety Trunking System, Madison, Wisconsin - Scanner Frequencies
This one is what I'm gravitating to by habit, but it seems documentation on the SmartNet systems is nearly non-existent.

That one would be the simplest to handle as the control channel uses simple two level signaling. You only need to decode a few control messages (channel grants and late entry messages). Also, the voice audio just goes straight to a speaker. Of course, those systems are well on their way out, so it's a bit of a dead end, unless you use it as a stepping stone to P25 down the road. If this is just for your degree, well, might as well KISS.

Another one in the area that's brand new, and of most interest to me, but I know nothing about how it operates since I'm used to the Motorola network and this one is P25 Phase II. It's our county's new common system for county-wide and outlying town dispatches for sheriff, outlier PD and FD, etc.
DaneCom Trunking System, Madison, Wisconsin - Scanner Frequencies
I believe this one may be more productive since it's a newer system and likely more relevant, as well as being busy enough to get regular traffic on.

Phase II introduces a lot of issues, like dealing with phase shift keyed signals and two signaling rates (9600 and 12000 bps, IIRC)

I do have signal strength issues, but there is another P25 network nearby I could use as well, although much quieter, and of the Phase I variety.
Wisconsin Interoperable System for Communications (WISCOM) Trunking System, Statewide, Wisconsin - Scanner Frequencies

Phase I is definitely simpler, but you'd be dealing with four level control channel data, which is considerably more complicated than SmartNet's two level CC data, and you'd have to feed voice data to DSD for decoding. And this assumes that your computing platform has enough power to run DSD alongside your code.

 

[boatbod]

Right now, if you want Linux and P25 Ph2 TDMA, you've got OP25. The AMBE codec is going to give you a major headache since you've only got a month, and even then it's not going to play too well on a small embedded system (even a Rasp Pi 3) unless you figure out a way to integrate a (licensed) hardware codec. Even the P25 spec, which is probably essential for any serious coding effort, is gonna cost you...

Don't bite off more than you can fit into the time available!

 

[botenredwolf]

Using those tools may push the CPU load to where you don't want it to be. Can't say for sure as I don't use them. Working more direectly with an RTL dongle isn't that difficult; the rtlsdr driver gets the device tuned and passes the I/Q data to you.

Yeah, this machine's fairly powerful compared to some embedded systems, although only a dual-core ARM at 900MHz, the software load on it is much lighter than the Pi or something. I've been able to get the control channel for the SmartNet system from the RTL through software down to what's clearly a simple digital signal. Maybe if I had more time (or this summer after I'm done), I could set up a hardware accelerated decoder of some sort for the P25 in one form or another using the FPGA side of this thing, since 40K LE's should be enough for that one function, eh?

That one would be the simplest to handle as the control channel uses simple two level signaling. You only need to decode a few control messages (channel grants and late entry messages). Also, the voice audio just goes straight to a speaker. Of course, those systems are well on their way out, so it's a bit of a dead end, unless you use it as a stepping stone to P25 down the road. If this is just for your degree, well, might as well KISS.

Yeah that's what I'm thinking, do the SmartNet to get the concepts of how data is transmitted and received over the air like this, as well as taking the streams and turning them into user and machine-readable data so that it can be handed out appropriately. By two-level signaling I'm assuming you're talking basically simple binary-based data, either a high or low, in packets (of a structure that I've no idea).

Phase II introduces a lot of issues, like dealing with phase shift keyed signals and two signaling rates (9600 and 12000 bps, IIRC)


Phase I is definitely simpler, but you'd be dealing with four level control channel data, which is considerably more complicated than SmartNet's two level CC data, and you'd have to feed voice data to DSD for decoding. And this assumes that your computing platform has enough power to run DSD alongside your code.

Similar track to the two-level thought back there, is "four-level" a way to have 4 bits in one cycle based on its position? That's more of a curiosity at this point, since we'll just focus on the SmartNet one due to simplicity.


Sorry about delay in the response, got distracted by a small-scale "mass casualty" incident here, car struck at least 4 pedestrians and I was busy monitoring that one.

 

[slicerwizard]

By two-level signaling I'm assuming you're talking basically simple binary-based data, either a high or low

Yep.

Similar track to the two-level thought back there, is "four-level" a way to have 4 bits in one cycle based on its position?

No. Four bits have far more than four possible states.

No offense, but I would've thought that one could've done some basic research on this already (and no, asking questions on a forum doesn't count as research). Also, you have access to control channel streams, but you haven't done any investigating of them at all? Just looking at them should tell you how different their encoding is. I'm getting the impression that you're in over your head. Can you actually do serious coding or were you looking to throw together some scripts to control an existing package?

Two level Type II and four level P25p1 control channel waveforms attached for your edification.

 

[botenredwolf]

Yep.


No. Four bits have far more than four possible states.

No offense, but I would've thought that one could've done some basic research on this already (and no, asking questions on a forum doesn't count as research). Also, you have access to control channel streams, but you haven't done any investigating of them at all? Just looking at them should tell you how different their encoding is. I'm getting the impression that you're in over your head. Can you actually do serious coding or were you looking to throw together some scripts to control an existing package?

Two level Type II and four level P25p1 control channel waveforms attached for your edification.

Just took a closer look at how I typed that, and after looking at those waveforms, I've come to the conclusion that my brain works better really late at night... P25, 4 states would be 2 bits. A positive swing for first bit high, negative swing for second bit high, something along those lines?

"Serious" coding would have to define a reference point. Can I keep up with someone who does it for a living? Nope. I'd like to, but I don't have the practical hands-on yet to get there. Can I hold my own on something I want to go after? Yeah. I've set out on many projects and completed way more than I've had to scrap due to skill-related inability to finish.

The biggest thing here that differs from anything I've done before is acquiring a stream (that I don't have control over), slicing it, and having it do something useful. Basically any sort of communication between controllers, devices, etc. that I've done before was done in such a way where it was something that was polled via serial or other methods where, basically, the line was quiet if the program wasn't on a function that needed it. Here, I'm going to obviously have a process running that's listening through all the noise waiting for a pattern that's going to announce incoming transmissions, then have it acquire the packet(s), slice 'em, and then hand out instructions to the other tuner if needed based on rules or priorities set up. At the same time, I'm not sure what the pattern that will announce incoming will be, nor what the packet structure is. How big's the header, what's it tell us; how big's the payload, what's all in there; error checking? While I can find quite a fair amount of information on what the Type II systems can do and a higher level explanation of how they do it, I can't find much on the lower level stuff, and while I'm sure I could observe and log a ton of traffic off this network and eventually figure it out, I was hoping to come across something that might give me a little primer into how it works on the inside like that.

 

[boatbod]

Have you looked at trunk recorder? I'm under the impression it can handle SmartNet.
https://github.com/robotastic/trunk-recorder

 

[slicerwizard]

P25, 4 states would be 2 bits. A positive swing for first bit high, negative swing for second bit high, something along those lines?

Four deviations from the channel center frequency are defined in the P25 standard. Each deviation communicates a unique two bit value.

Here, I'm going to obviously have a process running that's listening through all the noise waiting for a pattern that's going to announce incoming transmissions, then have it acquire the packet(s), slice 'em, and then hand out instructions to the other tuner if needed based on rules or priorities set up. At the same time, I'm not sure what the pattern that will announce incoming will be, nor what the packet structure is. How big's the header, what's it tell us; how big's the payload, what's all in there; error checking? While I can find quite a fair amount of information on what the Type II systems can do and a higher level explanation of how they do it, I can't find much on the lower level stuff, and while I'm sure I could observe and log a ton of traffic off this network and eventually figure it out, I was hoping to come across something that might give me a little primer into how it works on the inside like that.

I would think that the Trunker source code would adequately convey all of the details. I would start there.