December 2012 - App_rpt-users - lists.keekles.org

Command Mode Timeout
by Kent Ochs 30 Dec '12

30 Dec '12

Our repeater (A two node system consisting of VHF 27833 node linked to a UHF receiver on node 1998) recently experienced a random false dtmf *40 decode. This put the repeater into transmit mode. What bothers me most, is that while in command mode, the transmit timeout parameter (totime) appears to be ignored, not good if there isn't someone around that knows to send "#" or otherwise shutdown the machine. In normal operating mode, totime works as expected, and try as I may, I have not been able to find a "command mode timeout" parameter. Have I missed or mis-configured something to cause this behavior? Is there a problem with the command function not honoring the transmit timeout parameter? I understand that *4 is a mandatory command, but could someone enlighten me as to why I shouldn't just disable this command altogether? An inquired mind wants to know and appreciates your feedback. Thanks. Kent W9KAO

3 4

TM-G707 Interface board
by Jim Duuuude 30 Dec '12

30 Dec '12

For those who have asked, I un-earthed 4 (although 1 is already spoken for, I think) blank TM-G707 to URI/PCI Radio card interface boards. If anyone is interested, they are available for $20 plus shipping. Just send me an email privately. Jim WB6NIL

2 2

URI Replacing Repeater Controller?
by Chris K7AZ 29 Dec '12

29 Dec '12

I have replaced my UHF Repeater¹s RLC-1+ controller with a URIx USB interface. The receiver and transmitter work great on AllStar but no longer function like a repeater for local users. Are there specific settings needed to enable local repeat of audio to the transmitter? Thank you, Chris K7AZ - 29135 Rptr- 29174 Hub 29216 (in work)

3 2

Re: [App_rpt-users] App_rpt-users Digest, Vol 46, Issue 39
by Wayne Hale 29 Dec '12

29 Dec '12

Well blow me down, just for the heck of it, tried Internet Explorer to log into the Zyxel, poof, right in with admin and 1234? Go figure. Don't recall that being a documented feature? Wayne On 12/28/2012 9:00 AM, app_rpt-users-request(a)ohnosec.org wrote: > Send App_rpt-users mailing list submissions to > app_rpt-users(a)ohnosec.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > or, via email, send a message with subject or body 'help' to > app_rpt-users-request(a)ohnosec.org > > You can reach the person managing the list at > app_rpt-users-owner(a)ohnosec.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of App_rpt-users digest..." > > > Today's Topics: > > 1. Re: Fwd: RE: Jim and Ramesh (chan_voter and RPi) (S. Scott) > 2. Fwd: Fwd: RE: Jim and Ramesh (chan_voter and RPi) (Shane Morris) > 3. Raspberry pi (Leon D. Zetekoff) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 28 Dec 2012 02:44:32 -0500 > From: "S. Scott" <8f27e956(a)gmail.com> > To: Shane Morris <edgecomberts(a)gmail.com> > Cc: app_rpt mailing list <app_rpt-users(a)ohnosec.org> > Subject: Re: [App_rpt-users] Fwd: RE: Jim and Ramesh (chan_voter and > RPi) > Message-ID: <-8102833036369711429@unknownmsgid> > Content-Type: text/plain; charset="windows-1252" > > While i understand the appeal of the rPi, the BeagleBone more likely has > the needed horse power, and it can handle its USB and ethernet going at the > same time. To modern O/S, the BEAGLE BONE "looks" like i real mobo, > needing less custom shoehorning. > > 2? > > ????? > iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar > errors ? Thought of the Day ? "With all this manure, there must be a pony > in here somewhere.? > > On 2012-12-27, at 18:25, Shane Morris <edgecomberts(a)gmail.com> wrote: > > ---------- Forwarded message ---------- > From: "Shane Morris" <edgecomberts(a)gmail.com> > Date: 28/12/2012 10:25 AM > Subject: RE: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) > To: "Corey Dean" <n3fe(a)repeater.net> > > Yes, but that function is handled by the DSPiC in the RTCM as far as I > understand. I'm suggesting the RPi be a SIP/ IAX server. And merely that. > No real need for a DSP in the RPi. > On 28/12/2012 10:22 AM, "Corey Dean" <n3fe(a)repeater.net> wrote: > >> My thought on this would be if it couldn't handle the DSP and had to rely >> on simple USB then it wouldn't be able to work as a voter because it >> wouldn't be able to read the RSSI of the discriminator audio. I may be >> way off on my thought, but I know it needs DSP for the discriminator audio. >> >> Corey N3FE >> >> -----Original Message----- >> From: app_rpt-users-bounces(a)ohnosec.org [mailto: >> app_rpt-users-bounces(a)ohnosec.org] On Behalf Of Shane Morris >> Sent: Thursday, December 27, 2012 2:56 PM >> To: app_rpt mailing list >> Subject: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) >> >> Hi all, >> >> I was thinking, even though the RaspberryPi can't handle the audio stream >> from a URI due to the limitations of the USB bus, what is the ethernet >> performance like? I imagine it wouldn't be terribly good, due to the fact >> the ethernet swings off the USB, but hear me out... >> >> chan_voter is a module that communicates via ethernet, am I correct? >> It uses an RTCM connected over an ethernet bus to communicate the voice >> data around, and I can imagine, at a low codec rate like GSM or even Speex, >> throughput wouldn't be as excessive as raw sound data coming from a fob. >> >> So my proposal is, before Jim and Ramesh throw out the baby with the >> bathwater, and consign the RPi effort to the dust, why not take the work, >> which I believe involves getting Zaptel/ DAHDI to work with the RPi, and >> apply it to a purely chan_voter system? Yes, I know the chan_voter is >> dependant upon app_rpt, and in the future, someone, somewhere, is going to >> try to hook up a sound fob, and miserably complain it doesn't work, but we >> get the same questions about Asterisk >> 1.8 over and over too, right? >> >> The advantages here are manyfold - again, low power consumption comes into >> the game, everyone knows I personally need as low a power consumption as I >> can get. The fact the RTCM data (ie, VoIP over >> ethernet) is much more suited to the infrastructure on the RPi is a good >> thing here too. The fact that normal Asterisk just runs, and runs well, on >> RPi is another motivating factor - my friend Andrew is running his house >> PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. >> And yes, simply the cool factor - who else can say they run their voting >> repeater system off something the size of a credit card, with all the >> proprietary, messy, rack mounted stuff out there? >> >> If Jim and Ramesh are unwilling, or unable, to help, due to the fact that >> the RPi is a bit of a letdown (I heard about the USB performance issues - >> ouch!), I would like to take their work, and apply it to a platform I think >> may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - >> the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 >> I/Os? For $49, gets you something good, look it up, www.cubieboard.org - >> I got one for Christmas, and I thought it would be good for this. Its a >> Chinese Allwinnner A10 device. >> >> Since I have gone beyond just simple URI systems since Jim introduced me >> to the RTCM, I would like to get this to work. I recognised the RTCM did >> something I was talking to Andrew about on the way home from Expedition in >> October of this year - "Wouldn't it be nice, Andrew, if we could have a >> voting system that allows us the flexibility to run an Expeditions >> communications in such a way that make it simply easy for us, and easy for >> the users?" Before, we've had users change channels in different places, >> this inevitably leads to confusion. With a chan_voter system, we can run >> the same UHF CB channel across the arena, and access it anywhere. >> >> Andrew had said to me "Shane, do you know how much such a system would >> cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for >> $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how >> much would a PROPRIETARY system cost us? >> >> Anyway, I hope I have Jim and Rameshes blessing on this one - they did >> some great work, and I know it must've been a letdown to find out the >> hardware simply wasn't up to the task. Believe me, this isn't the first >> story I've heard about the lacklustre I/O performance of the RPi, and it >> won't be the last. But by using their work on a much stronger (I hope!) >> platform that it still ARM Linux based, I hope to circumvent at least one >> problem with the RPi. And its only $11 more before shipping! >> >> Looks like I'm going to be reading the Allwinnner A10 device spec sheet >> now, huh? =) >> >> Thanks for putting up with my ramble everyone. >> >> Shane. >> _______________________________________________ >> App_rpt-users mailing list >> App_rpt-users(a)ohnosec.org >> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users >> >> -- >> This message was scanned and is believed to be clean. >> Click here to report this message as spam. >> http://simba.repeater.net/cgi-bin/learn-msg.cgi?id=E18C4221F.A9108 >> >> >> _______________________________________________ > App_rpt-users mailing list > App_rpt-users(a)ohnosec.org > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users >

1 1

All-Star link repeater
by Ham Radio 29 Dec '12

29 Dec '12

Hello I am working on getting my advance license so I can put up a All-Star link repeater in the 220 Band But am will to use 2m and 440 as well. I know I have to contact the repeater council for my area which is wnysorc to get a set part of the band for my repeater. I was wondering what hardware do I need? I am planing to use the DMK URI for the radio interface. I would like to us a Motorola radio with a 16pin interface port so I can use a pre made cable from marshals. Can any of Motorola's radio's with the 16 pin be programed to the 220 ham band? What other hardware do I need ie Duplexer and how does the auto patch work? Can I use my VOIP phone line with a usb voice modem or do I have to get a VoIP service that offers sip trunking? I would also like to have my EcoIRLP node on my repeater. Is there a way of doing this and keeping both IRLP and ALL-STAR link happy. Thank you. -- 73, VE3ETG

1 0

Raspberry pi
by Leon D. Zetekoff 29 Dec '12

29 Dec '12

Hi folks. Happy holidays. Has anyone looked at implementing this on a raspberry pi? Pbx in a flash now has a distro for it. Thoughts? 73 Leon wa4zlw Sent from my iPhone

2 3

Fwd: Fwd: RE: Jim and Ramesh (chan_voter and RPi)
by Shane Morris 28 Dec '12

28 Dec '12

---------- Forwarded message ---------- From: Shane Morris <edgecomberts(a)gmail.com> Date: Fri, Dec 28, 2012 at 6:57 PM Subject: Re: [App_rpt-users] Fwd: RE: Jim and Ramesh (chan_voter and RPi) To: "S. Scott" <8f27e956(a)gmail.com> And I have said I'd like to use a Cubieboard and included a link. It is comparable to an xM, as well as being far, far cheaper. If chan_voter works on RPi, it'll certainly work on anything. The intent here is to get a voting server to work, not a direct peripheral on an RPi or a Cubie or even an xM. I have listed all these factors in my original email, and for good reason. Sorry, I'm not trying to be a smart alec but I did go over all this with he intent it wouldn't be vexed again. So I'm going to point at my original post, and say "Ignore the reference to RPi, and read again." :) On 28/12/2012 6:44 PM, "S. Scott" <8f27e956(a)gmail.com> wrote: > > While i understand the appeal of the rPi, the BeagleBone more likely has the needed horse power, and it can handle its USB and ethernet going at the same time. To modern O/S, the BEAGLE BONE "looks" like i real mobo, needing less custom shoehorning. > > 2¢ > > ————— > iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar errors • Thought of the Day – "With all this manure, there must be a pony in here somewhere.” > > On 2012-12-27, at 18:25, Shane Morris <edgecomberts(a)gmail.com> wrote: > > ---------- Forwarded message ---------- > From: "Shane Morris" <edgecomberts(a)gmail.com> > Date: 28/12/2012 10:25 AM > Subject: RE: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) > To: "Corey Dean" <n3fe(a)repeater.net> > > Yes, but that function is handled by the DSPiC in the RTCM as far as I understand. I'm suggesting the RPi be a SIP/ IAX server. And merely that. No real need for a DSP in the RPi. > > On 28/12/2012 10:22 AM, "Corey Dean" <n3fe(a)repeater.net> wrote: >> >> My thought on this would be if it couldn't handle the DSP and had to rely on simple USB then it wouldn't be able to work as a voter because it wouldn't be able to read the RSSI of the discriminator audio. I may be way off on my thought, but I know it needs DSP for the discriminator audio. >> >> Corey N3FE >> >> -----Original Message----- >> From: app_rpt-users-bounces(a)ohnosec.org [mailto:app_rpt-users-bounces@ohnosec.org] On Behalf Of Shane Morris >> Sent: Thursday, December 27, 2012 2:56 PM >> To: app_rpt mailing list >> Subject: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) >> >> Hi all, >> >> I was thinking, even though the RaspberryPi can't handle the audio stream from a URI due to the limitations of the USB bus, what is the ethernet performance like? I imagine it wouldn't be terribly good, due to the fact the ethernet swings off the USB, but hear me out... >> >> chan_voter is a module that communicates via ethernet, am I correct? >> It uses an RTCM connected over an ethernet bus to communicate the voice data around, and I can imagine, at a low codec rate like GSM or even Speex, throughput wouldn't be as excessive as raw sound data coming from a fob. >> >> So my proposal is, before Jim and Ramesh throw out the baby with the bathwater, and consign the RPi effort to the dust, why not take the work, which I believe involves getting Zaptel/ DAHDI to work with the RPi, and apply it to a purely chan_voter system? Yes, I know the chan_voter is dependant upon app_rpt, and in the future, someone, somewhere, is going to try to hook up a sound fob, and miserably complain it doesn't work, but we get the same questions about Asterisk >> 1.8 over and over too, right? >> >> The advantages here are manyfold - again, low power consumption comes into the game, everyone knows I personally need as low a power consumption as I can get. The fact the RTCM data (ie, VoIP over >> ethernet) is much more suited to the infrastructure on the RPi is a good thing here too. The fact that normal Asterisk just runs, and runs well, on RPi is another motivating factor - my friend Andrew is running his house PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. And yes, simply the cool factor - who else can say they run their voting repeater system off something the size of a credit card, with all the proprietary, messy, rack mounted stuff out there? >> >> If Jim and Ramesh are unwilling, or unable, to help, due to the fact that the RPi is a bit of a letdown (I heard about the USB performance issues - ouch!), I would like to take their work, and apply it to a platform I think may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 I/Os? For $49, gets you something good, look it up, www.cubieboard.org - I got one for Christmas, and I thought it would be good for this. Its a Chinese Allwinnner A10 device. >> >> Since I have gone beyond just simple URI systems since Jim introduced me to the RTCM, I would like to get this to work. I recognised the RTCM did something I was talking to Andrew about on the way home from Expedition in October of this year - "Wouldn't it be nice, Andrew, if we could have a voting system that allows us the flexibility to run an Expeditions communications in such a way that make it simply easy for us, and easy for the users?" Before, we've had users change channels in different places, this inevitably leads to confusion. With a chan_voter system, we can run the same UHF CB channel across the arena, and access it anywhere. >> >> Andrew had said to me "Shane, do you know how much such a system would cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for >> $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how much would a PROPRIETARY system cost us? >> >> Anyway, I hope I have Jim and Rameshes blessing on this one - they did some great work, and I know it must've been a letdown to find out the hardware simply wasn't up to the task. Believe me, this isn't the first story I've heard about the lacklustre I/O performance of the RPi, and it won't be the last. But by using their work on a much stronger (I hope!) platform that it still ARM Linux based, I hope to circumvent at least one problem with the RPi. And its only $11 more before shipping! >> >> Looks like I'm going to be reading the Allwinnner A10 device spec sheet now, huh? =) >> >> Thanks for putting up with my ramble everyone. >> >> Shane. >> _______________________________________________ >> App_rpt-users mailing list >> App_rpt-users(a)ohnosec.org >> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users >> >> -- >> This message was scanned and is believed to be clean. >> Click here to report this message as spam. >> http://simba.repeater.net/cgi-bin/learn-msg.cgi?id=E18C4221F.A9108 >> >> > _______________________________________________ > App_rpt-users mailing list > App_rpt-users(a)ohnosec.org > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

1 0

Fwd: RE: Jim and Ramesh (chan_voter and RPi)
by Shane Morris 28 Dec '12

28 Dec '12

---------- Forwarded message ---------- From: "Shane Morris" <edgecomberts(a)gmail.com> Date: 28/12/2012 10:25 AM Subject: RE: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) To: "Corey Dean" <n3fe(a)repeater.net> Yes, but that function is handled by the DSPiC in the RTCM as far as I understand. I'm suggesting the RPi be a SIP/ IAX server. And merely that. No real need for a DSP in the RPi. On 28/12/2012 10:22 AM, "Corey Dean" <n3fe(a)repeater.net> wrote: > My thought on this would be if it couldn't handle the DSP and had to rely > on simple USB then it wouldn't be able to work as a voter because it > wouldn't be able to read the RSSI of the discriminator audio. I may be > way off on my thought, but I know it needs DSP for the discriminator audio. > > Corey N3FE > > -----Original Message----- > From: app_rpt-users-bounces(a)ohnosec.org [mailto: > app_rpt-users-bounces(a)ohnosec.org] On Behalf Of Shane Morris > Sent: Thursday, December 27, 2012 2:56 PM > To: app_rpt mailing list > Subject: [App_rpt-users] Jim and Ramesh (chan_voter and RPi) > > Hi all, > > I was thinking, even though the RaspberryPi can't handle the audio stream > from a URI due to the limitations of the USB bus, what is the ethernet > performance like? I imagine it wouldn't be terribly good, due to the fact > the ethernet swings off the USB, but hear me out... > > chan_voter is a module that communicates via ethernet, am I correct? > It uses an RTCM connected over an ethernet bus to communicate the voice > data around, and I can imagine, at a low codec rate like GSM or even Speex, > throughput wouldn't be as excessive as raw sound data coming from a fob. > > So my proposal is, before Jim and Ramesh throw out the baby with the > bathwater, and consign the RPi effort to the dust, why not take the work, > which I believe involves getting Zaptel/ DAHDI to work with the RPi, and > apply it to a purely chan_voter system? Yes, I know the chan_voter is > dependant upon app_rpt, and in the future, someone, somewhere, is going to > try to hook up a sound fob, and miserably complain it doesn't work, but we > get the same questions about Asterisk > 1.8 over and over too, right? > > The advantages here are manyfold - again, low power consumption comes into > the game, everyone knows I personally need as low a power consumption as I > can get. The fact the RTCM data (ie, VoIP over > ethernet) is much more suited to the infrastructure on the RPi is a good > thing here too. The fact that normal Asterisk just runs, and runs well, on > RPi is another motivating factor - my friend Andrew is running his house > PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. > And yes, simply the cool factor - who else can say they run their voting > repeater system off something the size of a credit card, with all the > proprietary, messy, rack mounted stuff out there? > > If Jim and Ramesh are unwilling, or unable, to help, due to the fact that > the RPi is a bit of a letdown (I heard about the USB performance issues - > ouch!), I would like to take their work, and apply it to a platform I think > may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - > the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 > I/Os? For $49, gets you something good, look it up, www.cubieboard.org - > I got one for Christmas, and I thought it would be good for this. Its a > Chinese Allwinnner A10 device. > > Since I have gone beyond just simple URI systems since Jim introduced me > to the RTCM, I would like to get this to work. I recognised the RTCM did > something I was talking to Andrew about on the way home from Expedition in > October of this year - "Wouldn't it be nice, Andrew, if we could have a > voting system that allows us the flexibility to run an Expeditions > communications in such a way that make it simply easy for us, and easy for > the users?" Before, we've had users change channels in different places, > this inevitably leads to confusion. With a chan_voter system, we can run > the same UHF CB channel across the arena, and access it anywhere. > > Andrew had said to me "Shane, do you know how much such a system would > cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for > $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how > much would a PROPRIETARY system cost us? > > Anyway, I hope I have Jim and Rameshes blessing on this one - they did > some great work, and I know it must've been a letdown to find out the > hardware simply wasn't up to the task. Believe me, this isn't the first > story I've heard about the lacklustre I/O performance of the RPi, and it > won't be the last. But by using their work on a much stronger (I hope!) > platform that it still ARM Linux based, I hope to circumvent at least one > problem with the RPi. And its only $11 more before shipping! > > Looks like I'm going to be reading the Allwinnner A10 device spec sheet > now, huh? =) > > Thanks for putting up with my ramble everyone. > > Shane. > _______________________________________________ > App_rpt-users mailing list > App_rpt-users(a)ohnosec.org > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users > > -- > This message was scanned and is believed to be clean. > Click here to report this message as spam. > http://simba.repeater.net/cgi-bin/learn-msg.cgi?id=E18C4221F.A9108 > > >

2 1

Update on P55 mobo issue, ztdummy Zaptel driver now ported to Linux 3.X
by Anthony Percy 28 Dec '12

28 Dec '12

Hi all, Based on recent group emails, just thought I would let you all know, I now have an untested version of Allstar running on Arch Linux 3.X. I had to port the Zaptel ztdummy driver to Linux 3.X to try and get Allstar working on a ASUS H55 mobo that the club VK2CRZ owns... We have had allstar generating a test tone ( rpt fun 2393 *99) for a number of hours and the audio was fine with no dropouts etc. The real test will be hopefully tomorrow when I replace the current 2393 allstar repeater PC with the new Arch Linux version P55 PC Hopefully it will test out OK....:-) I haven't packaged the code as I need to test it further but if the testing is successfull have I will upload it somewhere.... If anyone needs it ASAP let me know. If testing is successfull, I will also try and port it to my Raspberry PI running Arch Linux 3.2.X as my CM108 audio seems fine when plugged into the PI with this version of Unix but I haven't ported Allstar yet as I need to create an ARM version of the Arch Linux alsa-oss library.... Regards Anthony, VK2ACP RE: What happened is this... 1. Our VK2CRZ allstar node 2393 has been working for a few years now but the PC is a bit old... So we bought a new Intel H55 chipset based i3 mobo a few months ago to replace it (Model no is ASUS P7H55D-M Pro mobo). 2. We loaded new ACID install, copied the existing /etc/asterisk files, unplugged the USB cable existing URI connected to the repeater and connected to the new Allstar PC.... 3. We found the COR and PTT worked fine but the audio was just hum.. :-( 4. Plugged the URI back into the existing repeater and it works fine!!! 5. Looks like an audio path problem.... but the URI green LED was flashing slower and after a few cold boots we noticed the new boot now had the URI green LED flashing faster and now the repeater audio worked fine!!! Did a warm reboot , URI green was flashing slower and repeater audio was now hum again....No matter what I did could I get the URI green LED flashing faster again on the ACID install.... ...maybe a probelm with the H55 USB bus...?

1 0

Jim and Ramesh (chan_voter and RPi)
by Shane Morris 27 Dec '12

27 Dec '12

Hi all, I was thinking, even though the RaspberryPi can't handle the audio stream from a URI due to the limitations of the USB bus, what is the ethernet performance like? I imagine it wouldn't be terribly good, due to the fact the ethernet swings off the USB, but hear me out... chan_voter is a module that communicates via ethernet, am I correct? It uses an RTCM connected over an ethernet bus to communicate the voice data around, and I can imagine, at a low codec rate like GSM or even Speex, throughput wouldn't be as excessive as raw sound data coming from a fob. So my proposal is, before Jim and Ramesh throw out the baby with the bathwater, and consign the RPi effort to the dust, why not take the work, which I believe involves getting Zaptel/ DAHDI to work with the RPi, and apply it to a purely chan_voter system? Yes, I know the chan_voter is dependant upon app_rpt, and in the future, someone, somewhere, is going to try to hook up a sound fob, and miserably complain it doesn't work, but we get the same questions about Asterisk 1.8 over and over too, right? The advantages here are manyfold - again, low power consumption comes into the game, everyone knows I personally need as low a power consumption as I can get. The fact the RTCM data (ie, VoIP over ethernet) is much more suited to the infrastructure on the RPi is a good thing here too. The fact that normal Asterisk just runs, and runs well, on RPi is another motivating factor - my friend Andrew is running his house PABX on an RPi running Asterisk 1.8 I believe, there is an image for this. And yes, simply the cool factor - who else can say they run their voting repeater system off something the size of a credit card, with all the proprietary, messy, rack mounted stuff out there? If Jim and Ramesh are unwilling, or unable, to help, due to the fact that the RPi is a bit of a letdown (I heard about the USB performance issues - ouch!), I would like to take their work, and apply it to a platform I think may have a bit better USB performance - its based on a Cortex-A8 (ARMv7) - the Cubieboard. For all you I/O junkies out there, what can YOU do with 96 I/Os? For $49, gets you something good, look it up, www.cubieboard.org - I got one for Christmas, and I thought it would be good for this. Its a Chinese Allwinnner A10 device. Since I have gone beyond just simple URI systems since Jim introduced me to the RTCM, I would like to get this to work. I recognised the RTCM did something I was talking to Andrew about on the way home from Expedition in October of this year - "Wouldn't it be nice, Andrew, if we could have a voting system that allows us the flexibility to run an Expeditions communications in such a way that make it simply easy for us, and easy for the users?" Before, we've had users change channels in different places, this inevitably leads to confusion. With a chan_voter system, we can run the same UHF CB channel across the arena, and access it anywhere. Andrew had said to me "Shane, do you know how much such a system would cost...?" Yes, Andrew, I had the Simoco, and I bought the RTCM for $250 second hand ^.^ Sorry for being a smart-alec, I know you meant how much would a PROPRIETARY system cost us? Anyway, I hope I have Jim and Rameshes blessing on this one - they did some great work, and I know it must've been a letdown to find out the hardware simply wasn't up to the task. Believe me, this isn't the first story I've heard about the lacklustre I/O performance of the RPi, and it won't be the last. But by using their work on a much stronger (I hope!) platform that it still ARM Linux based, I hope to circumvent at least one problem with the RPi. And its only $11 more before shipping! Looks like I'm going to be reading the Allwinnner A10 device spec sheet now, huh? =) Thanks for putting up with my ramble everyone. Shane.

2 2