So, I'm hoping to get some opinion on this. I've been having a discussion with our RF guys on replacing our existing 3 port RLC repeater controller with an app_rpt setup, since we have more than 3 things to connect. There's some apprehension from non PC guys (and even myself, as a PC guy) about the reliability of a PC based system. We're not using our repeater for emergency or disaster response, and it's not operating at the top of a mountain, but, nobody wants something that they have to horse around with to keep it running. My thought would be not to stack a machine with USB dongles, but rather to connect each standalone repeater system to a RTCM. The RTCM would then connect to a hub PC (or multiple if it supports fall through to a second host). That way, if the hub computer failed, the standalone repeaters would revert to simple CW ID repeaters. However, I realize that everything's computers nowadays. I don't know if the RTCM is actually running a small embedded Linux, or if it's arbitrary code of some other nature. I can't tell. I'm trying to get a feel for their reliability thus far. I know that Asterisk and linux will pretty much just sit there, unless I trigger some sort of bug, for a long time. I actually had a HDD failure that took my Allstar node to read-only FS and it continued to run pretty much just fine until I got a drive out there to repair it, so I'm confident that we won't have issues. But, I gather that chan_voter is still a work in progress, I'm not sure if it's advisable to pursue this at this time, or wait until things are further along. I also ran into some comment about duplex being a problem for linked users - there was not any timer available to allow, on a full duplex system or link, non full duplex users to connect to the system and be able to transmit and talk, as their system would be in use until everyone else cleared out, a difficult scenario. Can't say for sure since we haven't gotten there yet but I could see it.
imho, you want absolute reliability...stay with hardware controllers. typically, my hubs and nodes stay up for months at a time, on an old althon mini tower with 5 dongles attached. get rid of the spinning media and go full solid state, and you,are probably looking at year or more. allstar is a work in progress...but, knowing what jim has done with what he built...being open source and community debugged, i'd probably not use it to distribute the launch codes, but i'd want to have it the after the tubes were emptied. i don't think 1) the rtcm has been out there long enough and 2) there is a big enough critical mass to say, with any sort of reliable metric, what the mtbf, mttr, or whatever have you, is. -- Bryan Sent from my iPad On Jan 8, 2013, at 12:04 PM, "Pawlowski, Adam" <ajp26@buffalo.edu> wrote:
So, I’m hoping to get some opinion on this. I’ve been having a discussion with our RF guys on replacing our existing 3 port RLC repeater controller with an app_rpt setup, since we have more than 3 things to connect. There’s some apprehension from non PC guys (and even myself, as a PC guy) about the reliability of a PC based system. We’re not using our repeater for emergency or disaster response, and it’s not operating at the top of a mountain, but, nobody wants something that they have to horse around with to keep it running. My thought would be not to stack a machine with USB dongles, but rather to connect each standalone repeater system to a RTCM. The RTCM would then connect to a hub PC (or multiple if it supports fall through to a second host). That way, if the hub computer failed, the standalone repeaters would revert to simple CW ID repeaters.
However, I realize that everything’s computers nowadays. I don’t know if the RTCM is actually running a small embedded Linux, or if it’s arbitrary code of some other nature. I can’t tell. I’m trying to get a feel for their reliability thus far. I know that Asterisk and linux will pretty much just sit there, unless I trigger some sort of bug, for a long time. I actually had a HDD failure that took my Allstar node to read-only FS and it continued to run pretty much just fine until I got a drive out there to repair it, so I’m confident that we won’t have issues. But, I gather that chan_voter is still a work in progress, I’m not sure if it’s advisable to pursue this at this time, or wait until things are further along.
I also ran into some comment about duplex being a problem for linked users – there was not any timer available to allow, on a full duplex system or link, non full duplex users to connect to the system and be able to transmit and talk, as their system would be in use until everyone else cleared out, a difficult scenario. Can’t say for sure since we haven’t gotten there yet but I could see it.
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
I also ran into some comment about duplex being a problem for linked users – there was not any timer available to allow, on a full duplex system or link, non full duplex users to connect to the system and be able to transmit and talk, as their system would be in use until everyone else cleared out, a difficult scenario. Can’t say for sure since we haven’t gotten there yet but I could see it.
What you can do about the above it to provide a no-radio node (a hub node) for non-duplex users to link to. You set the timers on that node to have almost zero hang time (and llittle or no courtesy beep). That gives them pretty much an equal; chance to start talking as the users on the full-duplex ports.
73 Ken _______________________________________________ pp_rpt-users mailing list pp_rpt-users@ohnosec.org ttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
participants (3)
-
Bryan D. Boyle -
Ken -
Pawlowski, Adam