Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn. Our plan remains the same. We intend to link both MSF's on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn't cost us a recurring fee. With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch.
You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better. Radios are simply extensions on the asterisk system. This makes them very flexible. On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote:
You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn.
Our plan remains the same. We intend to link both MSF’s on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn’t cost us a recurring fee.
With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
This is excellent news! To be clear on random connections, I'd like my own private network, but I'd also like a public server. Can they be the same server? Not a problem either way. I have rack space. The reasons to use Allstar that you state are the reasons we've chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We're getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. _____ From: Don Hackler [mailto:donh@sigma.net] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better. Radios are simply extensions on the asterisk system. This makes them very flexible. On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote: You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn. Our plan remains the same. We intend to link both MSF's on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn't cost us a recurring fee. With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
In your situation, I would use Micro-Node RTCM modules on the repeaters to minimize the computer hardware on mountain tops. All they need is some internet (or private ethernet) connectivity back to the server in the warm cozy datacenter. The RTCM modules don't even need static or public IP addresses as long as they have an IP address for the server in the datacenter.. The RTCM module is effectively a remote URI that uses ethernet instead of a direct USB connection. Ideally, you want the Allstar system to be the repeater controller for the most flexibility, but the RTCM will also do basic repeater control if the internet connection dies. Personally, I have an AllStar server that just talks to local radios over DMK URI modules, and it has an IAX connection to my "production" Asterisk phone servers. The radios can be dialed as extensions from my main phone servers, and I can route an outside trunk directly to a radio if I want. The radios can also dial extensions in my production servers. You can setup dial plans in either the Allstar box (or the Asterisk server) that will only allow certain numbers to be dialed from the radios or codes that dial explicit numbers. It's all very flexible. The biggest issue is that the ACID/apt_rpt distribution for AllStar is a fork of the main Asterisk distribution that is frozen at Asterisk 1.4 It is minimalist command line driven system with very steep learning curve. I use PBX in a Flash Distributions of more modern Asterisk versions to connect to the outside world and do the heavy lifting. It's still a handful to learn, but it's mostly a web GUI that is a lot easier to get things done, and it's a fairly secure distribution (with a very minimal attack surface) if you put it behind a firewall. On Mar 2, 2013, at 10:06 PM, "Bob - AF6D" <bob@af6d.com> wrote:
This is excellent news! To be clear on random connections, I’d like my own private network, but I’d also like a public server. Can they be the same server? Not a problem either way. I have rack space.
The reasons to use Allstar that you state are the reasons we’ve chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We’re getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. From: Don Hackler [mailto:donh@sigma.net] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better.
Radios are simply extensions on the asterisk system. This makes them very flexible.
On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote:
You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn.
Our plan remains the same. We intend to link both MSF’s on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn’t cost us a recurring fee.
With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
I am very impressed with what you have done but must admit that you've scare the stuffing out of me! I have built several complete hosting data centers (behind a main providers infrastructure) and can get around Linux. All I want for now are two mountain tops that will get public links (each repeater can only see one control center) using Ubiquity. I am AT site one and will provide internet. Site 2 can be seen by repeater 2 and he will use Ubiquity to link up. At the end of the day they need to see the datacenter. I'll add phone patching later. We intend to link/vote/simulcast. Step one seems to be to get the RTC installed. But as far as a warm and cozy data center? Ain't gonna happen! They are like refrigerators! LOL. _____ From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 12:37 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) In your situation, I would use Micro-Node RTCM modules on the repeaters to minimize the computer hardware on mountain tops. All they need is some internet (or private ethernet) connectivity back to the server in the warm cozy datacenter. The RTCM modules don't even need static or public IP addresses as long as they have an IP address for the server in the datacenter.. The RTCM module is effectively a remote URI that uses ethernet instead of a direct USB connection. Ideally, you want the Allstar system to be the repeater controller for the most flexibility, but the RTCM will also do basic repeater control if the internet connection dies. Personally, I have an AllStar server that just talks to local radios over DMK URI modules, and it has an IAX connection to my "production" Asterisk phone servers. The radios can be dialed as extensions from my main phone servers, and I can route an outside trunk directly to a radio if I want. The radios can also dial extensions in my production servers. You can setup dial plans in either the Allstar box (or the Asterisk server) that will only allow certain numbers to be dialed from the radios or codes that dial explicit numbers. It's all very flexible. The biggest issue is that the ACID/apt_rpt distribution for AllStar is a fork of the main Asterisk distribution that is frozen at Asterisk 1.4 It is minimalist command line driven system with very steep learning curve. I use PBX in a Flash Distributions of more modern Asterisk versions to connect to the outside world and do the heavy lifting. It's still a handful to learn, but it's mostly a web GUI that is a lot easier to get things done, and it's a fairly secure distribution (with a very minimal attack surface) if you put it behind a firewall. On Mar 2, 2013, at 10:06 PM, "Bob - AF6D" <bob@af6d.com> wrote: This is excellent news! To be clear on random connections, I'd like my own private network, but I'd also like a public server. Can they be the same server? Not a problem either way. I have rack space. The reasons to use Allstar that you state are the reasons we've chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We're getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. _____ From: Don Hackler [mailto:donh@sigma.net] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better. Radios are simply extensions on the asterisk system. This makes them very flexible. On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote: You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn. Our plan remains the same. We intend to link both MSF's on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn't cost us a recurring fee. With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
You shouldn't have that much trouble making it all fly. Nothing is as complicated as say, setting up a Cisco router using IOS... You just have to understand some of the terminology, and get some signal polarities headed the right direction, so get the basics running on the workbench first. Get the radios and the RTCMs talking to the AllStar server and make it vote/repeat like you want. Be sure and have a service monitor handy so you can set audio and modulation levels. At that point you are good to go for installing on the mountains. Let AllStar do as much of the repeater control as you possibly can, it's far more flexible than the built in repeater controllers. Ideally, you would just have access to the RX and TX and feed them back to the AllStar box through the RTCM. The phone stuff can be added later, since it's all done in the server on the ground. I meant warm and cozy compared to the mountain tops... Some of the data centers here in the Silicon Valley are in heavy energy conservation mode, so they run them uncomfortably warm. The voting and linking is working pretty well with the RTCM system, but I hear the simulcast is not working so well. (if you are not trying to do a single frequency simulcast where a receiver can hear both transmitters on the same freq, you are probably OK…) On Mar 3, 2013, at 1:02 AM, "Bob - AF6D" <bob@af6d.com> wrote:
I am very impressed with what you have done but must admit that you’ve scare the stuffing out of me! I have built several complete hosting data centers (behind a main providers infrastructure) and can get around Linux. All I want for now are two mountain tops that will get public links (each repeater can only see one control center) using Ubiquity. I am AT site one and will provide internet. Site 2 can be seen by repeater 2 and he will use Ubiquity to link up. At the end of the day they need to see the datacenter. I’ll add phone patching later. We intend to link/vote/simulcast.
Step one seems to be to get the RTC installed. But as far as a warm and cozy data center? Ain’t gonna happen! They are like refrigerators! LOL. From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 12:37 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
In your situation, I would use Micro-Node RTCM modules on the repeaters to minimize the computer hardware on mountain tops.
All they need is some internet (or private ethernet) connectivity back to the server in the warm cozy datacenter. The RTCM modules don't even need static or public IP addresses as long as they have an IP address for the server in the datacenter..
The RTCM module is effectively a remote URI that uses ethernet instead of a direct USB connection. Ideally, you want the Allstar system to be the repeater controller for the most flexibility, but the RTCM will also do basic repeater control if the internet connection dies.
Personally, I have an AllStar server that just talks to local radios over DMK URI modules, and it has an IAX connection to my "production" Asterisk phone servers. The radios can be dialed as extensions from my main phone servers, and I can route an outside trunk directly to a radio if I want. The radios can also dial extensions in my production servers.
You can setup dial plans in either the Allstar box (or the Asterisk server) that will only allow certain numbers to be dialed from the radios or codes that dial explicit numbers.
It's all very flexible. The biggest issue is that the ACID/apt_rpt distribution for AllStar is a fork of the main Asterisk distribution that is frozen at Asterisk 1.4 It is minimalist command line driven system with very steep learning curve.
I use PBX in a Flash Distributions of more modern Asterisk versions to connect to the outside world and do the heavy lifting. It's still a handful to learn, but it's mostly a web GUI that is a lot easier to get things done, and it's a fairly secure distribution (with a very minimal attack surface) if you put it behind a firewall.
On Mar 2, 2013, at 10:06 PM, "Bob - AF6D" <bob@af6d.com> wrote:
This is excellent news! To be clear on random connections, I’d like my own private network, but I’d also like a public server. Can they be the same server? Not a problem either way. I have rack space.
The reasons to use Allstar that you state are the reasons we’ve chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We’re getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. From: Don Hackler [mailto:donh@sigma.net] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better.
Radios are simply extensions on the asterisk system. This makes them very flexible.
On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote:
You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn.
Our plan remains the same. We intend to link both MSF’s on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn’t cost us a recurring fee.
With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
Your help makes it sound easy and I am looking forward to getting it working. I opened another thread about an echo even though we are already set as a full duplex base and not as a repeater. This was the same as with the RC210 controllers we already have. My technical manager is damn good and he'll get it solved. I understand that the server becomes the repeater controller and I think I understand that everyone has their own. No problem. But I don't understand not using our link controller, the RC210. We have a dedicated weather receiver, for example, that uses a FIPS code for repeater 1's area. Repeater 2's area has a different FIPS. Should I assume that since these devices use COR/PTT that a RTCM should be able to attach? But then routing to the correct repeater. Again, first things first. Repeater 1 (R1) is running at Site 1 (S1) and R2 is going online we hope this week at S2. The voted coverage pattern will be tremendous! I especially like being able to add a fill receiver in an area that can hear the repeater but mobiles and HT's cannot. Thank you for allowing me to be here as a student. I may ask a dumb question and probably get an answer back that I won't understand. If I ask for clarification it won't be out of disrespect. I am hoping that my 15 years experience with high-end Linux hosting will allow me to help others. I see numerous users on the Yahoo group at http://groups.yahoo.com/group/allstarlink/. I know that it's faster but I don't see anyone using it. Is this list switching over to it? As for simulcast I hesitate to name mountain tops. Right now I have a DB224e with its back to S2. S2 will have its back to S1. We expect to set all audio levels with random ladder test tones using a HP 8924C. We'll add the GPSO devices as required. Right now one repeater reliably covers almost all of southern California. Excellent receive, 6,400 feet location and a 1 watt HT can hit it full quieting from 100 miles away. No kidding. Give me a call on 147.705( - ) 167.9. No courtesy tone without the RTCM but all in time. I am getting excited! _____ From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 2:40 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) You shouldn't have that much trouble making it all fly. Nothing is as complicated as say, setting up a Cisco router using IOS... You just have to understand some of the terminology, and get some signal polarities headed the right direction, so get the basics running on the workbench first. Get the radios and the RTCMs talking to the AllStar server and make it vote/repeat like you want. Be sure and have a service monitor handy so you can set audio and modulation levels. At that point you are good to go for installing on the mountains. Let AllStar do as much of the repeater control as you possibly can, it's far more flexible than the built in repeater controllers. Ideally, you would just have access to the RX and TX and feed them back to the AllStar box through the RTCM. The phone stuff can be added later, since it's all done in the server on the ground. I meant warm and cozy compared to the mountain tops... Some of the data centers here in the Silicon Valley are in heavy energy conservation mode, so they run them uncomfortably warm. The voting and linking is working pretty well with the RTCM system, but I hear the simulcast is not working so well. (if you are not trying to do a single frequency simulcast where a receiver can hear both transmitters on the same freq, you are probably OK.) On Mar 3, 2013, at 1:02 AM, "Bob - AF6D" <bob@af6d.com> wrote: I am very impressed with what you have done but must admit that you've scare the stuffing out of me! I have built several complete hosting data centers (behind a main providers infrastructure) and can get around Linux. All I want for now are two mountain tops that will get public links (each repeater can only see one control center) using Ubiquity. I am AT site one and will provide internet. Site 2 can be seen by repeater 2 and he will use Ubiquity to link up. At the end of the day they need to see the datacenter. I'll add phone patching later. We intend to link/vote/simulcast. Step one seems to be to get the RTC installed. But as far as a warm and cozy data center? Ain't gonna happen! They are like refrigerators! LOL. _____ From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 12:37 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) In your situation, I would use Micro-Node RTCM modules on the repeaters to minimize the computer hardware on mountain tops. All they need is some internet (or private ethernet) connectivity back to the server in the warm cozy datacenter. The RTCM modules don't even need static or public IP addresses as long as they have an IP address for the server in the datacenter.. The RTCM module is effectively a remote URI that uses ethernet instead of a direct USB connection. Ideally, you want the Allstar system to be the repeater controller for the most flexibility, but the RTCM will also do basic repeater control if the internet connection dies. Personally, I have an AllStar server that just talks to local radios over DMK URI modules, and it has an IAX connection to my "production" Asterisk phone servers. The radios can be dialed as extensions from my main phone servers, and I can route an outside trunk directly to a radio if I want. The radios can also dial extensions in my production servers. You can setup dial plans in either the Allstar box (or the Asterisk server) that will only allow certain numbers to be dialed from the radios or codes that dial explicit numbers. It's all very flexible. The biggest issue is that the ACID/apt_rpt distribution for AllStar is a fork of the main Asterisk distribution that is frozen at Asterisk 1.4 It is minimalist command line driven system with very steep learning curve. I use PBX in a Flash Distributions of more modern Asterisk versions to connect to the outside world and do the heavy lifting. It's still a handful to learn, but it's mostly a web GUI that is a lot easier to get things done, and it's a fairly secure distribution (with a very minimal attack surface) if you put it behind a firewall. On Mar 2, 2013, at 10:06 PM, "Bob - AF6D" <bob@af6d.com> wrote: This is excellent news! To be clear on random connections, I'd like my own private network, but I'd also like a public server. Can they be the same server? Not a problem either way. I have rack space. The reasons to use Allstar that you state are the reasons we've chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We're getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. _____ From: Don Hackler [mailto:donh@sigma.net <http://sigma.net/> ] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D) You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better. Radios are simply extensions on the asterisk system. This makes them very flexible. On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote: You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn. Our plan remains the same. We intend to link both MSF's on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn't cost us a recurring fee. With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
As far as I know, the ohnosec.org mailing list is still the "official" support mechanism. Are the weather receivers going to be at the mountains or can they be at the datacenter? If they are are at the datacenter, you can use DMK engineering URI interfaces connected with USB directly to the AllStar server. If they are remote, then put them on RTCMs and shoot the data back to the server over ethernet. Just make sure you configure everything properly with respect to pre-emphasized and non pre-emphasized audio. The system can use either mode on a radio by radio basis… The built in DSP will do the conversions for you as needed. CTCSS/digital PL tone detection/generation can be done in the system as well. You can script pretty much anything you want the WX receivers to do at the server level (i.e. sending the WX alerts to the proper repeaters….) and interrogating the WX receivers using DTMF commands front the repeaters. My only concern from a voting/simulcast point of view is this: Are the two repeaters on the same output frequency, and if so, do they overlap coverage areas? The simulcast mode is not quite ready for prime time in that situation. (the RF and audio timing in the overlap areas is not as good as it needs to be so you will actually interfere with yourself….) If the sites are different output frequencies, or there is no overlap area you are concerned about, then the simulcast will work. When you use the GPS receivers on the RTCM units, the RX voting works very well. but there is a delay in the repeated audio. (similar to a cellphone or Nextel delay) The RX voting is seamless. Without monitoring it on the server you won't even know it switched. Disclaimer: I've never done the voting/simulcast game, but there is a group here in the San Francisco Bay area experimenting with it. On Mar 3, 2013, at 3:37 AM, "Bob - AF6D" <bob@af6d.com> wrote:
Your help makes it sound easy and I am looking forward to getting it working. I opened another thread about an echo even though we are already set as a full duplex base and not as a repeater. This was the same as with the RC210 controllers we already have. My technical manager is damn good and he’ll get it solved.
I understand that the server becomes the repeater controller and I think I understand that everyone has their own. No problem. But I don’t understand not using our link controller, the RC210. We have a dedicated weather receiver, for example, that uses a FIPS code for repeater 1’s area. Repeater 2’s area has a different FIPS. Should I assume that since these devices use COR/PTT that a RTCM should be able to attach? But then routing to the correct repeater…
Again, first things first. Repeater 1 (R1) is running at Site 1 (S1) and R2 is going online we hope this week at S2. The voted coverage pattern will be tremendous! I especially like being able to add a fill receiver in an area that can hear the repeater but mobiles and HT’s cannot.
Thank you for allowing me to be here as a student. I may ask a dumb question and probably get an answer back that I won’t understand. If I ask for clarification it won’t be out of disrespect. I am hoping that my 15 years experience with high-end Linux hosting will allow me to help others.
I see numerous users on the Yahoo group at http://groups.yahoo.com/group/allstarlink/. I know that it’s faster but I don’t see anyone using it. Is this list switching over to it?
As for simulcast I hesitate to name mountain tops. Right now I have a DB224e with its back to S2. S2 will have its back to S1. We expect to set all audio levels with random ladder test tones using a HP 8924C. We’ll add the GPSO devices as required. Right now one repeater reliably covers almost all of southern California. Excellent receive, 6,400 feet location and a 1 watt HT can hit it full quieting from 100 miles away. No kidding. Give me a call on 147.705( - ) 167.9. No courtesy tone without the RTCM but all in time. I am getting excited!
From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 2:40 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
You shouldn't have that much trouble making it all fly. Nothing is as complicated as say, setting up a Cisco router using IOS...
You just have to understand some of the terminology, and get some signal polarities headed the right direction, so get the basics running on the workbench first. Get the radios and the RTCMs talking to the AllStar server and make it vote/repeat like you want. Be sure and have a service monitor handy so you can set audio and modulation levels. At that point you are good to go for installing on the mountains.
Let AllStar do as much of the repeater control as you possibly can, it's far more flexible than the built in repeater controllers. Ideally, you would just have access to the RX and TX and feed them back to the AllStar box through the RTCM.
The phone stuff can be added later, since it's all done in the server on the ground.
I meant warm and cozy compared to the mountain tops... Some of the data centers here in the Silicon Valley are in heavy energy conservation mode, so they run them uncomfortably warm.
The voting and linking is working pretty well with the RTCM system, but I hear the simulcast is not working so well. (if you are not trying to do a single frequency simulcast where a receiver can hear both transmitters on the same freq, you are probably OK…)
On Mar 3, 2013, at 1:02 AM, "Bob - AF6D" <bob@af6d.com> wrote:
I am very impressed with what you have done but must admit that you’ve scare the stuffing out of me! I have built several complete hosting data centers (behind a main providers infrastructure) and can get around Linux. All I want for now are two mountain tops that will get public links (each repeater can only see one control center) using Ubiquity. I am AT site one and will provide internet. Site 2 can be seen by repeater 2 and he will use Ubiquity to link up. At the end of the day they need to see the datacenter. I’ll add phone patching later. We intend to link/vote/simulcast.
Step one seems to be to get the RTC installed. But as far as a warm and cozy data center? Ain’t gonna happen! They are like refrigerators! LOL. From: Don Hackler [mailto:donh@sigma.net] Sent: Sunday, March 03, 2013 12:37 AM To: Bob - AF6D Cc: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
In your situation, I would use Micro-Node RTCM modules on the repeaters to minimize the computer hardware on mountain tops.
All they need is some internet (or private ethernet) connectivity back to the server in the warm cozy datacenter. The RTCM modules don't even need static or public IP addresses as long as they have an IP address for the server in the datacenter..
The RTCM module is effectively a remote URI that uses ethernet instead of a direct USB connection. Ideally, you want the Allstar system to be the repeater controller for the most flexibility, but the RTCM will also do basic repeater control if the internet connection dies.
Personally, I have an AllStar server that just talks to local radios over DMK URI modules, and it has an IAX connection to my "production" Asterisk phone servers. The radios can be dialed as extensions from my main phone servers, and I can route an outside trunk directly to a radio if I want. The radios can also dial extensions in my production servers.
You can setup dial plans in either the Allstar box (or the Asterisk server) that will only allow certain numbers to be dialed from the radios or codes that dial explicit numbers.
It's all very flexible. The biggest issue is that the ACID/apt_rpt distribution for AllStar is a fork of the main Asterisk distribution that is frozen at Asterisk 1.4 It is minimalist command line driven system with very steep learning curve.
I use PBX in a Flash Distributions of more modern Asterisk versions to connect to the outside world and do the heavy lifting. It's still a handful to learn, but it's mostly a web GUI that is a lot easier to get things done, and it's a fairly secure distribution (with a very minimal attack surface) if you put it behind a firewall.
On Mar 2, 2013, at 10:06 PM, "Bob - AF6D" <bob@af6d.com> wrote:
This is excellent news! To be clear on random connections, I’d like my own private network, but I’d also like a public server. Can they be the same server? Not a problem either way. I have rack space.
The reasons to use Allstar that you state are the reasons we’ve chosen it. Snow has hampered us somewhat with another storm brewing mid-week. We’re getting about one foot a week at 6,400 feet in So. California. Just enough to snow on my parade. For now then I need to configure each repeater and the Thin Client. From: Don Hackler [mailto:donh@sigma.net] Sent: Saturday, March 02, 2013 9:40 PM To: Bob - AF6D Cc: <app_rpt-users@ohnosec.org> Subject: Re: [App_rpt-users] Motorola Phone Patch (Bob - AF6D)
You won't have much trouble setting up what you want with some config file hackage. Most of the phone patch "secret sauce" is just Asterisk configuration. If you don't want random Allstar connections, you don't need to allow them. The phone patch is easy to control. You will need a sip trunk, either from an external provider, or you can put a SIP adapter on a local POTS line. You will find that a cheap SIP trunk costs less than a POTS line with adapter and works much better.
Radios are simply extensions on the asterisk system. This makes them very flexible.
On Mar 2, 2013, at 7:19 PM, "Bob - AF6D" <bob@af6d.com> wrote:
You have exposed my rookiness! LOL. I am aware that a thin client hooked up acts like a controller. Fallback mode I guess. But I was under the impression that there are open conference servers, or that others may call our node if connected to the internet. I have much to learn.
Our plan remains the same. We intend to link both MSF’s on different mountain tops via our own server. I own the hosting company and have Tier 1 bandwidth at my beckon call. But we want to have our own phone patch and have a phone line at our data center. Both nodes are true public safety (ECS/ARES/SAR) and expenses come out of my wallet. It is my hope that there is a way to add a phone patch that doesn’t cost us a recurring fee.
With regards to our dedicated server I was under the impression that we could have our own private network, and, a public network for others to use. Giving back for fun and for free. But our phone patch would be for our exclusive use. We envision macros that will telephone specific numbers. I am Linux literate if I can create my own phone patch. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (2)
-
Bob - AF6D -
Don Hackler