So as it stands I have a one node system. I have another URI on the way and will have BBB soon. The eventual plan is to have a few repeaters and some simplex nodes at people's houses for RF hot spot access. What is the best way to tie these together? I understand you can set permanent links that will reestablish connection if lost. Is there other ways of accomplishing this? I only ask because I have my one node setup with email, autopatch and all other kinds of bells and whistles. I'd like to be able to do all of this from other RF locations and I wonder if I need to just set each node up accordingly or can one node be the workhorse and the other nodes just be dumb connections. Did I make any sense with that question?
There are a few ways to do what you want — that is permanently tie multiple repeaters together — if I understand your question. First, permanent connections are not as permanent as you might expect. If the computer that initiated the permanent connections goes down the connection will not reestablish. However you can have a startup macro make the connection as Asterisk starts. Also, there seems to be some intermittent bug, which I’ve never pinned down, where permanent connections won’t reestablish with out forcing a disconnect first. Second way is with RTCMs. They are a whole lot easier to deploy and way more reliable than a bunch of USB type nodes, with the trade off in expense. Although by the time you buy a BBB and a URI you’re getting close to the expense of an RTCM. Of course you can go with a cheep sound dongle and an eBay used thin client PC. It’s the ‘ol time/money/reliability trade off. I strongly recommend the RTCM approach. And a third option is called app_radbridge. If you don’t want to buy RTCMs this is probably the way to go. I’ve never tried to use it. The only documentation I am aware of is in the source which is reproduced here. /* This application is intended to provide a generic "bridging" functionality for radio-oriented Asterisk channels. The idea here is that certain radio applications lend themselves to needing a "generic" (passes audio and tx/rx keying completely transparently) to and from two or more endpoints. An example of such an appication might be replacing (or providing equivlent new functionaliy of) one or more full-duplex UHF control links with an IP-based one(s). app_radbridge allows multiple instances of radio-oriented channels transparently "bridged" together. The config file (radbridge.conf) allows specification of each "bridging" instance and what radio-oriented Asterisk channels are to be associated with it. There is no need for any other specificaiton of configuration. The file format for radbridge.conf departs somewhat from the standard usage (at least for radio stuff) of the Asterisk config file architecture. In most other radio-oriented cases, an instance of whatever it is gets defined as a "Stanza" in the config file. In this case, because of limitations in the way that Asterisk parses config files, that was not possible. Instead, all config information goes into the [general] stanza, and each line of config info defines a different instance of radio bridging. For example: [general] instance1 = Voter/1234,Radio/5678 instance2 = Voter/1235,Radio/5679 This example would define two radio bridging instances "instance1" and "instance2", each with 2 channels associated with them. The supported channel types are "Voter" (chan_voter), "Radio" (chan_usbradio), "SimpleUsb" (chan_simpleusb), and "Zap" ("Dahdi") (chan_dahdi, for the couple of devices that use this channel driver, such as the PCIRadio card, and separate analog channels using an ARIB board or such). Rather then "adding" (which would actually be a lot of *removing* optionally) this functionality in app_rpt, it made more sense to create a separate application specifically for this purpose. In addition, this allows for a system that is merely provided for doing this bridging application and nothing else radio-oriented, to not have to run app_rpt at all. */ -- Tim :wq On Sep 28, 2014, at 12:28 PM, Robert Newberry <N1XBM@amsat.org> wrote:
So as it stands I have a one node system. I have another URI on the way and will have BBB soon. The eventual plan is to have a few repeaters and some simplex nodes at people's houses for RF hot spot access.
What is the best way to tie these together? I understand you can set permanent links that will reestablish connection if lost.
Is there other ways of accomplishing this? I only ask because I have my one node setup with email, autopatch and all other kinds of bells and whistles. I'd like to be able to do all of this from other RF locations and I wonder if I need to just set each node up accordingly or can one node be the workhorse and the other nodes just be dumb connections.
Did I make any sense with that question?
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
Tim, Not to debate some of your statements, but I am from Kansas and maybe our math is different. My BBB cost 55 bucks, and the URI was 70. The RTCM is 269 bucks.... What am I missing? Chuck K0XM Allstar 41153 Portable BBB repeater 927.2375 in San Diego (until the end of 2014) On Sun, Sep 28, 2014 at 2:00 PM, Tim Sawyer <tim.sawyer@mac.com> wrote:
There are a few ways to do what you want — that is permanently tie multiple repeaters together — if I understand your question.
First, permanent connections are not as permanent as you might expect. If the computer that initiated the permanent connections goes down the connection will not reestablish. However you can have a startup macro make the connection as Asterisk starts. Also, there seems to be some intermittent bug, which I’ve never pinned down, where permanent connections won’t reestablish with out forcing a disconnect first.
Second way is with RTCMs. They are a whole lot easier to deploy and way more reliable than a bunch of USB type nodes, with the trade off in expense. Although by the time you buy a BBB and a URI you’re getting close to the expense of an RTCM. Of course you can go with a cheep sound dongle and an eBay used thin client PC. It’s the ‘ol time/money/reliability trade off. I strongly recommend the RTCM approach.
And a third option is called app_radbridge. If you don’t want to buy RTCMs this is probably the way to go. I’ve never tried to use it. The only documentation I am aware of is in the source which is reproduced here.
/* This application is intended to provide a generic "bridging" functionality for radio-oriented Asterisk channels.
The idea here is that certain radio applications lend themselves to needing a "generic" (passes audio and tx/rx keying completely transparently) to and from two or more endpoints.
An example of such an appication might be replacing (or providing equivlent new functionaliy of) one or more full-duplex UHF control links with an IP-based one(s).
app_radbridge allows multiple instances of radio-oriented channels transparently "bridged" together.
The config file (radbridge.conf) allows specification of each "bridging" instance and what radio-oriented Asterisk channels are to be associated with it. There is no need for any other specificaiton of configuration.
The file format for radbridge.conf departs somewhat from the standard usage (at least for radio stuff) of the Asterisk config file architecture.
In most other radio-oriented cases, an instance of whatever it is gets defined as a "Stanza" in the config file. In this case, because of limitations in the way that Asterisk parses config files, that was not possible. Instead, all config information goes into the [general] stanza, and each line of config info defines a different instance of radio bridging. For example:
[general]
instance1 = Voter/1234,Radio/5678 instance2 = Voter/1235,Radio/5679
This example would define two radio bridging instances "instance1" and "instance2", each with 2 channels associated with them.
The supported channel types are "Voter" (chan_voter), "Radio" (chan_usbradio), "SimpleUsb" (chan_simpleusb), and "Zap" ("Dahdi") (chan_dahdi, for the couple of devices that use this channel driver, such as the PCIRadio card, and separate analog channels using an ARIB board or such).
Rather then "adding" (which would actually be a lot of *removing* optionally) this functionality in app_rpt, it made more sense to create a separate application specifically for this purpose. In addition, this allows for a system that is merely provided for doing this bridging application and nothing else radio-oriented, to not have to run app_rpt at all. */
-- Tim :wq
On Sep 28, 2014, at 12:28 PM, Robert Newberry <N1XBM@amsat.org> wrote:
So as it stands I have a one node system. I have another URI on the way and will have BBB soon. The eventual plan is to have a few repeaters and some simplex nodes at people's houses for RF hot spot access.
What is the best way to tie these together? I understand you can set permanent links that will reestablish connection if lost.
Is there other ways of accomplishing this? I only ask because I have my one node setup with email, autopatch and all other kinds of bells and whistles. I'd like to be able to do all of this from other RF locations and I wonder if I need to just set each node up accordingly or can one node be the workhorse and the other nodes just be dumb connections.
Did I make any sense with that question? _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- Chuck K0XM Backyard Repeater Group k0xm@byrg.net
Well of course I am prejudiced towards the BBB but the cost difference is a lot more than you are stating. RTCM,s are $280 and you could put together a BBB system for around $150 or alot less if you want to mod a USB FOB. Of course this is minus radio in both cases. I have no experience with an RTCM. I think it has many nice features but many that the average person would never use. The upside to the RTCM is you would have one server that you could configure to do what you want rather than handling each individual BBB server. The end product would be the same but the administration would be different. You could administer remote BBB nodes via SSH/SCP very nicely. The downside of the one server multi RTCM is that if that server or its connection goes down the whole system is hosed. The RTCM's while maintaining local control would not be connected to anywhere. The BBB approach would be a stand alone server capable of anything an Allstar system could do. It is also very reliable and the new code that is coming out in a few days will be rock solid and suitable for remote locations. We have a basically BBB network here in PA/NJ with a central PC hub that they all connect to with mostly permanent connections. If the hub or internet connections to the hub goes down it will reconnect. The hub uses a startup macro to establish certain key connections. I find it is best to have the various nodes connected to the hub use permanent connections to the hub with a startup macro. If anything goes down it will come back up and reconnect will take place. 73 Doug WA3DSP http://www.crompton.com/hamradio From: tim.sawyer@mac.com Date: Sun, 28 Sep 2014 14:00:00 -0700 To: N1XBM@amsat.org CC: app_rpt-users@ohnosec.org Subject: Re: [App_rpt-users] Multiple nodes There are a few ways to do what you want — that is permanently tie multiple repeaters together — if I understand your question. First, permanent connections are not as permanent as you might expect. If the computer that initiated the permanent connections goes down the connection will not reestablish. However you can have a startup macro make the connection as Asterisk starts. Also, there seems to be some intermittent bug, which I’ve never pinned down, where permanent connections won’t reestablish with out forcing a disconnect first. Second way is with RTCMs. They are a whole lot easier to deploy and way more reliable than a bunch of USB type nodes, with the trade off in expense. Although by the time you buy a BBB and a URI you’re getting close to the expense of an RTCM. Of course you can go with a cheep sound dongle and an eBay used thin client PC. It’s the ‘ol time/money/reliability trade off. I strongly recommend the RTCM approach. And a third option is called app_radbridge. If you don’t want to buy RTCMs this is probably the way to go. I’ve never tried to use it. The only documentation I am aware of is in the source which is reproduced here. /* This application is intended to provide a generic "bridging" functionality for radio-oriented Asterisk channels. The idea here is that certain radio applications lend themselves to needing a "generic" (passes audio and tx/rx keying completely transparently) to and from two or more endpoints. An example of such an appication might be replacing (or providing equivlent new functionaliy of) one or more full-duplex UHF control links with an IP-based one(s). app_radbridge allows multiple instances of radio-oriented channels transparently "bridged" together. The config file (radbridge.conf) allows specification of each "bridging" instance and what radio-oriented Asterisk channels are to be associated with it. There is no need for any other specificaiton of configuration. The file format for radbridge.conf departs somewhat from the standard usage (at least for radio stuff) of the Asterisk config file architecture. In most other radio-oriented cases, an instance of whatever it is gets defined as a "Stanza" in the config file. In this case, because of limitations in the way that Asterisk parses config files, that was not possible. Instead, all config information goes into the [general] stanza, and each line of config info defines a different instance of radio bridging. For example: [general] instance1 = Voter/1234,Radio/5678instance2 = Voter/1235,Radio/5679 This example would define two radio bridging instances "instance1" and "instance2", each with 2 channels associated with them. The supported channel types are "Voter" (chan_voter), "Radio" (chan_usbradio), "SimpleUsb" (chan_simpleusb), and "Zap" ("Dahdi") (chan_dahdi, for the couple of devices that use this channel driver, such as the PCIRadio card, and separate analog channels using an ARIB board or such). Rather then "adding" (which would actually be a lot of *removing* optionally) this functionality in app_rpt, it made more sense to create a separate application specifically for this purpose. In addition, this allows for a system that is merely provided for doing this bridging application and nothing else radio-oriented, to not have to run app_rpt at all. */ -- Tim :wq On Sep 28, 2014, at 12:28 PM, Robert Newberry <N1XBM@amsat.org> wrote:So as it stands I have a one node system. I have another URI on the way and will have BBB soon. The eventual plan is to have a few repeaters and some simplex nodes at people's houses for RF hot spot access. What is the best way to tie these together? I understand you can set permanent links that will reestablish connection if lost.Is there other ways of accomplishing this? I only ask because I have my one node setup with email, autopatch and all other kinds of bells and whistles. I'd like to be able to do all of this from other RF locations and I wonder if I need to just set each node up accordingly or can one node be the workhorse and the other nodes just be dumb connections. Did I make any sense with that question? _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. _______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
participants (4)
-
Chuck Kraly -
Doug Crompton -
Robert Newberry -
Tim Sawyer