HarryWilly
Member
- Joined
- Jul 4, 2007
- Messages
- 270
Hey all! Sorry in advance for the wall of text. I have Trunk Recorder up and running for a system in my area, and I wanted to provide a guide so that others can replicate my results and hopefully be encouraged to move over to the new platform. Also hopefully this can provide suggestions from others about improvement, including some of my own that I have made. I am not trying to claim to be the expert on this, I just have this setup working well. If you have suggestions on how I can do this better, I am all ears. My goal is to make this approachable for all.
I did this post here instead of posting to a blog and linking here because I didn't want it to appear as my goal was self-promotion, rather helping the community. So sorry for the multiple posts in a single thread, but I have a limit I am working against!
I personally have found that Docker is the easiest way to deploy Trunk Recorder, especially now that Broadcastify calls platform has native support. As new versions are released it takes about a minute to update the software and be back up and running. Trunk Recorder can be frustrating for those of us who don't regularly build software from source. I ran into a lot of hiccups when I first tried it as a lot of dependencies had changed versions and requirements, and required changes in the instructions to get it running, which was to say the least, frustrating.
This is also a good project for someone looking to learn Docker and Linux - fairly basic. So I will do my best to explain a lot of what is going on.
This will cover setting up monitoring for a trunking system since to feed Broadcastify calls that seems like it is likely to be the biggest use case. Won't get too much into the basics since you can do a quick search and find out about what Luke Berndt's amazing software is, what it can do, etc.
Pre-Reqs
You will need at least one SDR receiver. In my case I am using two RTL-SDR v3 blog dongles. Although technically these can handle more than 2MHz, I have found that one for every 2MHz of spectrum is a good rule of thumb, you can probably push the envelope a bit, but I have found the lower the sample rate (which correlates to simultaneous bandwidth coverage) the better.
Another note for my setup - with the RTL dongles (and probably other SDRs) as well, a broadcast FM filter will go a long way to enhancing your sensitivity/coverage. In my setup, I actually use a NMO antenna on a TRAM NMO to N base mount fed to a RTL-SDR FM Broadcast Filter which is then fed to a 8-way cable TV amplifier/splitter. That will probably make some people freak out about impedance matching and such, but the reality is RTL-SDR were originally designed as TV receives which use 75 Ohm antennas, so the loss of the 50 Ohm antenna going into 75 Ohm designed splitter is likely negligible. I am not a super RF engineer, but if someone want to help me calculate what kind of loss I am seeing, I am willing to learn.
You will need a computer that is running Linux for this - I haven't tried using Docker on other platforms, but your biggest hurdle is going to be getting the device to be read inside the container. The container itself as of this writing is based on Ubuntu, and you need to pass the SDR as a readable device into the console, so if you can support those things I suppose it will work on other platforms. I have not tested this on a Raspberry Pi (yet) - if someone wants to test and report back, that would be helpful. I suspect there may be an issue since it's an ARM processor and I am using x86 platform in this case, but won't know until it's tested. I may go back and see if there is a way to copy the image file as it sits and switch to an ARM-supported container base.
Learning Your SDR's Behavior
The next step in this process is going to be getting your antenna and SDR setup. Will not go into excruciating detail for this part, but what I did was use SDR# inside of a Windows laptop to do that. You can do this whatever computer/software you want. Your goal is to make sure you can actually receive the control channel clearly and confirm the even minuscule amount of drift your dongle has. Even the RTL-SDR v3 with a <1ppm temperature controlled oscillator will benefit significantly from knowing how far the drift is. Make sure you run your receiver software on the control channel for several minutes to bring the SDR to operational temperature. Trunk Recorder accepts the drift value in Hertz, so be as accurate as you want. Basically just compare where the actual center of the control channel is on your SDR vs what is reported by the RadioReference Database. If using SDR# like I did, best thing to do is make sure you turn off the automatic frequency steps and and frequency correction so you can be as accurate as possible. Make sure you record these value(s) for later. You will need to do this for every device you plan to use as even two otherwise made exactly the same at the same time can have different offsets.
The more difficult thing you need to figure out is the gain requirement. Yes, Trunk Recorder has the ability to use AGC like SDR#, but even the documentation says this isn't as accurate. I haven't even tried it to see if it's reliable. All the SDR software out there I have seen offers the ability to manually adjust this. With the RTL-SDR v3 my gain setting is somewhere in the 40-ish dB range, but your values may be different.
In general when checking for drift, the best piece of advice I can give is tune your SDR until you can sit on the control channel for several minutes without hearing "hiccups" or "burps" of the control channel, and do your best to remove all static noise.
Getting Started
Now that you have your RF ingest setup, it's time to set up the computer. I used Ubuntu Server, which for all intents and purposes is Ubuntu minus GUI and a very bare minimum set of packages. For those dipping their toes into Linux via command line for the first time, either Ubuntu Server or Debian is probably going to be your best bet (again, just my humble opinion). I understand there is a lot of debate on this subject, but Debian in general seems to have enough adoption and Ubuntu seems to be the most popular distribution of a Debian-based Linux and hence why I chose it, but you do you.
You will need two key pieces of software - Docker and Docker-Compose. With Ubuntu as part of install, you can actually have the installer on more recent versions of Ubuntu handle this for you. I have no doubt in my mind that whatever flavor of Linux you choose, there are guides on how to install these.
If you are newer to Docker, before you get into Trunk Recorder, I would just play a little. Try setting up a basic "hello, world" web server, or some other service. Get familiar with the concepts, how to pass data in, etc. There are containers for just about everything out there. A fun one you might want to try is code-server which will spin up a container running Visual Studio Code you can access from a web browser. BTW Visual Studio Code is what I use for messing with a lot of these configuration files because most of the syntax is supported out of the box, but Notepad++ is another good option.
Next you need to get a copy of Trunk Recorder for Docker from its GitHub page. The reason I don't recommend pulling it from docker hub (for example, running "docker run robotastic/trunk-recorder") is because the configuration files you need to create are copied as part of the image creation process, and I found it's just easier to download the entire thing from GitHub and manually modify on your local desktop then copy to your Linux box. If I actually get free time (lol) I have the aspiration of forking it so that you can generate the config for use with Broadcastify via environment variables, but again that it a little advance for me without allocating a ton of time. If someone wants to take that project on, I will be happy to lend a hand.
Optional, But Very Helpful Step
Some flavors of Linux have RTLSDR (the software) already pre-loaded as part of repositories, but most software distro libraries should have some flavor of it out there. What I would do is unplug all of your dongles and one by one plug them into your Linux box. This will let you set the serial number for the dongles. The dongles come out the box with a hodgepodge serial number, so this helps a ton. In my example, I numbered them 101 and 102, then actually took a label maker and stuck the labels on the dongles. This ensured if I needed to troubleshoot a dongle I could. It also helps with configuring and tracking the unique settings needed to keep your SDR tuned in accurately.
The command to set the serial number on your dongle in Debian is:
where the number after -s is the serial number you want to use. You may need to use -d, for exampled "-d 0" to declare using the first device it finds.
This also works for Windows with rtl_eeprom.exe available from several sources. That command is:
You can make the serial number a single digit, but I think it makes more sense to make it an 8 digit value with leading zeroes if you want to make it a single digit. I just used 00000101, 00000102, etc since odds are low I would plug in another SDR with that serial number.
Tell Broadcastify You Want To Send Calls
Next you need to get some important information so Broadcastify you actually want to send calls to the system. Follow the steps here to get system ID (which is not the same a trunking system ID) and an API key.
I did this post here instead of posting to a blog and linking here because I didn't want it to appear as my goal was self-promotion, rather helping the community. So sorry for the multiple posts in a single thread, but I have a limit I am working against!
I personally have found that Docker is the easiest way to deploy Trunk Recorder, especially now that Broadcastify calls platform has native support. As new versions are released it takes about a minute to update the software and be back up and running. Trunk Recorder can be frustrating for those of us who don't regularly build software from source. I ran into a lot of hiccups when I first tried it as a lot of dependencies had changed versions and requirements, and required changes in the instructions to get it running, which was to say the least, frustrating.
This is also a good project for someone looking to learn Docker and Linux - fairly basic. So I will do my best to explain a lot of what is going on.
This will cover setting up monitoring for a trunking system since to feed Broadcastify calls that seems like it is likely to be the biggest use case. Won't get too much into the basics since you can do a quick search and find out about what Luke Berndt's amazing software is, what it can do, etc.
Pre-Reqs
You will need at least one SDR receiver. In my case I am using two RTL-SDR v3 blog dongles. Although technically these can handle more than 2MHz, I have found that one for every 2MHz of spectrum is a good rule of thumb, you can probably push the envelope a bit, but I have found the lower the sample rate (which correlates to simultaneous bandwidth coverage) the better.
Another note for my setup - with the RTL dongles (and probably other SDRs) as well, a broadcast FM filter will go a long way to enhancing your sensitivity/coverage. In my setup, I actually use a NMO antenna on a TRAM NMO to N base mount fed to a RTL-SDR FM Broadcast Filter which is then fed to a 8-way cable TV amplifier/splitter. That will probably make some people freak out about impedance matching and such, but the reality is RTL-SDR were originally designed as TV receives which use 75 Ohm antennas, so the loss of the 50 Ohm antenna going into 75 Ohm designed splitter is likely negligible. I am not a super RF engineer, but if someone want to help me calculate what kind of loss I am seeing, I am willing to learn.
You will need a computer that is running Linux for this - I haven't tried using Docker on other platforms, but your biggest hurdle is going to be getting the device to be read inside the container. The container itself as of this writing is based on Ubuntu, and you need to pass the SDR as a readable device into the console, so if you can support those things I suppose it will work on other platforms. I have not tested this on a Raspberry Pi (yet) - if someone wants to test and report back, that would be helpful. I suspect there may be an issue since it's an ARM processor and I am using x86 platform in this case, but won't know until it's tested. I may go back and see if there is a way to copy the image file as it sits and switch to an ARM-supported container base.
Learning Your SDR's Behavior
The next step in this process is going to be getting your antenna and SDR setup. Will not go into excruciating detail for this part, but what I did was use SDR# inside of a Windows laptop to do that. You can do this whatever computer/software you want. Your goal is to make sure you can actually receive the control channel clearly and confirm the even minuscule amount of drift your dongle has. Even the RTL-SDR v3 with a <1ppm temperature controlled oscillator will benefit significantly from knowing how far the drift is. Make sure you run your receiver software on the control channel for several minutes to bring the SDR to operational temperature. Trunk Recorder accepts the drift value in Hertz, so be as accurate as you want. Basically just compare where the actual center of the control channel is on your SDR vs what is reported by the RadioReference Database. If using SDR# like I did, best thing to do is make sure you turn off the automatic frequency steps and and frequency correction so you can be as accurate as possible. Make sure you record these value(s) for later. You will need to do this for every device you plan to use as even two otherwise made exactly the same at the same time can have different offsets.
The more difficult thing you need to figure out is the gain requirement. Yes, Trunk Recorder has the ability to use AGC like SDR#, but even the documentation says this isn't as accurate. I haven't even tried it to see if it's reliable. All the SDR software out there I have seen offers the ability to manually adjust this. With the RTL-SDR v3 my gain setting is somewhere in the 40-ish dB range, but your values may be different.
In general when checking for drift, the best piece of advice I can give is tune your SDR until you can sit on the control channel for several minutes without hearing "hiccups" or "burps" of the control channel, and do your best to remove all static noise.
Getting Started
Now that you have your RF ingest setup, it's time to set up the computer. I used Ubuntu Server, which for all intents and purposes is Ubuntu minus GUI and a very bare minimum set of packages. For those dipping their toes into Linux via command line for the first time, either Ubuntu Server or Debian is probably going to be your best bet (again, just my humble opinion). I understand there is a lot of debate on this subject, but Debian in general seems to have enough adoption and Ubuntu seems to be the most popular distribution of a Debian-based Linux and hence why I chose it, but you do you.
You will need two key pieces of software - Docker and Docker-Compose. With Ubuntu as part of install, you can actually have the installer on more recent versions of Ubuntu handle this for you. I have no doubt in my mind that whatever flavor of Linux you choose, there are guides on how to install these.
If you are newer to Docker, before you get into Trunk Recorder, I would just play a little. Try setting up a basic "hello, world" web server, or some other service. Get familiar with the concepts, how to pass data in, etc. There are containers for just about everything out there. A fun one you might want to try is code-server which will spin up a container running Visual Studio Code you can access from a web browser. BTW Visual Studio Code is what I use for messing with a lot of these configuration files because most of the syntax is supported out of the box, but Notepad++ is another good option.
Next you need to get a copy of Trunk Recorder for Docker from its GitHub page. The reason I don't recommend pulling it from docker hub (for example, running "docker run robotastic/trunk-recorder") is because the configuration files you need to create are copied as part of the image creation process, and I found it's just easier to download the entire thing from GitHub and manually modify on your local desktop then copy to your Linux box. If I actually get free time (lol) I have the aspiration of forking it so that you can generate the config for use with Broadcastify via environment variables, but again that it a little advance for me without allocating a ton of time. If someone wants to take that project on, I will be happy to lend a hand.
Optional, But Very Helpful Step
Some flavors of Linux have RTLSDR (the software) already pre-loaded as part of repositories, but most software distro libraries should have some flavor of it out there. What I would do is unplug all of your dongles and one by one plug them into your Linux box. This will let you set the serial number for the dongles. The dongles come out the box with a hodgepodge serial number, so this helps a ton. In my example, I numbered them 101 and 102, then actually took a label maker and stuck the labels on the dongles. This ensured if I needed to troubleshoot a dongle I could. It also helps with configuring and tracking the unique settings needed to keep your SDR tuned in accurately.
The command to set the serial number on your dongle in Debian is:
Bash:
rtl_eeprom -s 00000001
This also works for Windows with rtl_eeprom.exe available from several sources. That command is:
Code:
rtl_eeprom.exe -s 00000001
You can make the serial number a single digit, but I think it makes more sense to make it an 8 digit value with leading zeroes if you want to make it a single digit. I just used 00000101, 00000102, etc since odds are low I would plug in another SDR with that serial number.
Tell Broadcastify You Want To Send Calls
Next you need to get some important information so Broadcastify you actually want to send calls to the system. Follow the steps here to get system ID (which is not the same a trunking system ID) and an API key.