[App_rpt] USB interface reliability
Hello all, I am building up a repeater to put on the air in Seattle as our first All Star node. I have the single-radio analog board which connects to my existing FXS card already but I don't want to put that up on top of a building in the long run. I'm curious if the cheap USB audio adapters (such as the one that computergeeks sells for something like $8) are a good long-term, reliable solution. I'm interested to hear from others running repeaters in good repeater sites that are using the USB ports, particularly those with repeaters in commercial or high-density sites where strong RF fields from other transmitters are common. The 4-port PCI card is certainly an option but given the price difference I would really like to make an attempt at the USB interface first but would like some advice of others on the stability/reliability of it. It won't be suitable for me if it's at all problematic as visiting this repeater site is not something I can do regularly. Thanks Mark Hagler
Well, to be completely honest USB has come a long long way from where it was 2 or 3 years ago (completely useless), but I would not put a USB device in a location that is difficult to get to such as a mountain top. So far, in our testing, we really have not seen any reliability problems stemming from USB, however, the USB just wasnt really designed to be an "unattended solution". Im sure that no matter how many times we recommend to stay away from USB in a critical situation, that there will be some that just insist on doing it anyway, and we'll just see what kind of reliability they are able to attain. Go with the Quad PCI and a fan-less disk-less embedded PC on the mountain tops. You cant go wrong. Jim Dixon, WB6NIL
Date: Sat, 19 Jan 2008 21:17:17 -0800 From: markhagler@gmail.com To: app_rpt@lists.illiana.net Subject: [App_rpt] USB interface reliability
Hello all,
I am building up a repeater to put on the air in Seattle as our first All Star node. I have the single-radio analog board which connects to my existing FXS card already but I don't want to put that up on top of a building in the long run.
I'm curious if the cheap USB audio adapters (such as the one that computergeeks sells for something like $8) are a good long-term, reliable solution. I'm interested to hear from others running repeaters in good repeater sites that are using the USB ports, particularly those with repeaters in commercial or high-density sites where strong RF fields from other transmitters are common.
The 4-port PCI card is certainly an option but given the price difference I would really like to make an attempt at the USB interface first but would like some advice of others on the stability/reliability of it. It won't be suitable for me if it's at all problematic as visiting this repeater site is not something I can do regularly.
Thanks
Mark Hagler _______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt
node 2091 has up and operating for 15 days. So far, so good. Its in a pretty heavy UHF RF environment at a tower site in the middle of a corn field. I will let you know when a year has gone by.. LOL But overall it is working and sounding great. Don W9DRR
Date: Sat, 19 Jan 2008 21:17:17 -0800 From: markhagler@gmail.com To: app_rpt@lists.illiana.net Subject: [App_rpt] USB interface reliability
Hello all,
I am building up a repeater to put on the air in Seattle as our first All Star node. I have the single-radio analog board which connects to my existing FXS card already but I don't want to put that up on top of a building in the long run.
I'm curious if the cheap USB audio adapters (such as the one that computergeeks sells for something like $8) are a good long-term, reliable solution. I'm interested to hear from others running repeaters in good repeater sites that are using the USB ports, particularly those with repeaters in commercial or high-density sites where strong RF fields from other transmitters are common.
The 4-port PCI card is certainly an option but given the price difference I would really like to make an attempt at the USB interface first but would like some advice of others on the stability/reliability of it. It won't be suitable for me if it's at all problematic as visiting this repeater site is not something I can do regularly.
Thanks
Mark Hagler _______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt
_________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx
Gents: I wonder if anyone can give me pointers on the following problem areas encountered as I come up to speed. Current installation (all compiled from source onto Debian Etch): Asterisk SVN-branch-1.4-r93420M app_rpt.c v. 0.86 12/05/07 chan_usbradio.c as at 20070918 xpmr.c as at 20070914 ******************************* 1. I regularly experience either one-way or no audio in connections to/from the radio interface. This is true with iax-rpt or IAX soft clients, both originating and terminating within my LAN or through a router from external IPs. The transmitter keying always works. I often see one-way audio when making Asterisk IAX calls that do not involve app-rpt. I am aware of the SIP/RTP/NAT issues but I am referring only to the IAX protocol. Any involved routers have 4569 forwarded correctly. There are some comments on Asterisk sites that refer to this problem, possibly limited to v. 1.4.x, but nothing definitive. 2. There was a posting on this list that mentioned that both rpt.conf and usbradio.conf should have the same 'duplex' parameter set (0 in my case). I do not see 'duplex' in the example usbradio.conf file. Should 'duplex=0' be set under [general] or [usb] in that file? 3. The autopatch 'on' code (*6) produces the following when dialed: NOTICE[27546]: chan_usbradio.c:1774 usbradio_read: Got DTMF char * NOTICE[27546]: chan_usbradio.c:1774 usbradio_read: Got DTMF char 6 ioctl(ZT_LOADZONE) failed: Inappropriate ioctl for device WARNING[27900]: app_rpt.c:4452 rpt_call: Unable to set tone zone us Hungup 'Zap/pseudo-1547130459' Hungup 'Zap/pseudo-721434464' Is the ioctl error an issue with the CM108 interface? I have 'tonezone=us' set in rpt.conf under my node stanza. I did not see this parameter shown in the distribution example rpt.conf file. Should the tonezone be set elsewhere? I have read through all archived postings, svn repos, and related websites but cannot find answers to the above. Any guidance would be truly appreciated. Allstar Link node number assignment is on request. Finally, I notice that with discriminator audio fed to the CM108, (and the radio tune parm's set) the DSP squelch is always very loose. DTMF is decoded properly but CTCSS decoding does not work at all. I have reverted to the hardware COS option. 73, Dave VE7MQ.
Dave, There have been lots of changes to chan_usbradio since September 2007 I would suggest you do the following updates then report back on any issues you still have: 1. Update asterisk and libpri zaptel to the latest stable "tarball" releases mentioned on asterisk.org. 2. Grab the latest SVN of chan_usbradio.c and all the files in the xpmr directory at: https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/channels 3. Grab the latest SVN of app_rpt.c at: https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/apps/ 4. Download the initial asterisk configuration files from; http://limeylinux.org/downloads/configs.tar.gz There are 4 directories underneath the main directory inside this tarball. There is one directory for each of the hardware platforms supported. Use only the files in the usbradio directory and the top level directory. Put all files in /etc/asterisk. Request for node number assignment: You have been assigned node allstar node 2140. Steve WA6ZFT David Powell-Williams wrote:
Gents:
I wonder if anyone can give me pointers on the following problem areas encountered as I come up to speed.
Current installation (all compiled from source onto Debian Etch):
Asterisk SVN-branch-1.4-r93420M
app_rpt.c v. 0.86 12/05/07
chan_usbradio.c as at 20070918
xpmr.c as at 20070914
*******************************
1. I regularly experience either one-way or no audio in connections to/from the radio interface. This is true with iax-rpt or IAX soft clients, both originating and terminating within my LAN or through a router from external IPs. The transmitter keying always works.
I often see one-way audio when making Asterisk IAX calls that do not involve app-rpt. I am aware of the SIP/RTP/NAT issues but I am referring only to the IAX protocol. Any involved routers have 4569 forwarded correctly. There are some comments on Asterisk sites that refer to this problem, possibly limited to v. 1.4.x, but nothing definitive.
2. There was a posting on this list that mentioned that both rpt.conf and usbradio.conf should have the same 'duplex' parameter set (0 in my case). I do not see 'duplex' in the example usbradio.conf file. Should 'duplex=0' be set under [general] or [usb] in that file?
3. The autopatch 'on' code (*6) produces the following when dialed:
NOTICE[27546]: chan_usbradio.c:1774 usbradio_read: Got DTMF char * NOTICE[27546]: chan_usbradio.c:1774 usbradio_read: Got DTMF char 6 ioctl(ZT_LOADZONE) failed: Inappropriate ioctl for device WARNING[27900]: app_rpt.c:4452 rpt_call: Unable to set tone zone us Hungup 'Zap/pseudo-1547130459' Hungup 'Zap/pseudo-721434464'
Is the ioctl error an issue with the CM108 interface?
I have 'tonezone=us' set in rpt.conf under my node stanza. I did not see this parameter shown in the distribution example rpt.conf file. Should the tonezone be set elsewhere?
I have read through all archived postings, svn repos, and related websites but cannot find answers to the above. Any guidance would be truly appreciated.
Allstar Link node number assignment is on request.
Finally, I notice that with discriminator audio fed to the CM108, (and the radio tune parm's set) the DSP squelch is always very loose. DTMF is decoded properly but CTCSS decoding does not work at all. I have reverted to the hardware COS option.
73,
Dave VE7MQ.
_______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt
Steve: Thanks very much. I will do as you suggest and report back early next week. Appreciate the assistance and the node assignment. Cheers, Dave VE7MQ.
Dave, There have been lots of changes to chan_usbradio since September 2007 I would suggest you do the following updates then report back on any issues you still have: 1. Update asterisk and libpri zaptel to the latest stable "tarball" releases mentioned on asterisk.org. 2. Grab the latest SVN of chan_usbradio.c and all the files in the xpmr directory at: https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/channels 3. Grab the latest SVN of app_rpt.c at: https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/apps/ 4. Download the initial asterisk configuration files from; http://limeylinux.org/downloads/configs.tar.gz There are 4 directories underneath the main directory inside this tarball. There is one directory for each of the hardware platforms supported. Use only the files in the usbradio directory and the top level directory. Put all files in /etc/asterisk. Steve WA6ZFT ********************************************* Steve: I followed your suggestions and recompiled with: Asterisk 1.4.18 Zaptel 1.4.8 Libpri 1.4.3 Chan_usbradio SVN rev 391 App_rpt SVN rev 416 Things are much improved, as you predicted. The one-way audio seems cured. I note that the audio levels through the USB FOB interface came up by about 20 dB in each direction, requiring a recalibration with radio tune. I also noticed that if Linux is rebooted with the FOB installed, the 2.6.22 kernel grabs the FOB as its primary audio device in preference to the normal sound card. As we all know, Linux reboots are a rarity but, unless one wants to play moh over the radio, it seems best to plug the FOB in after Linux is up and before Asterisk is started. If anyone else is recompiling Asterisk with chan_usbradio and app_rpt, I have made up a cheat sheet that may be useful. It can be obtained for the price of an email. Thanks very much for the pointers. I'll get my assigned node number plugged in and look forwards to hearing you and the other Allstar Link members. 73, Dave VE7MQ.
Dave, If the Linux distro you are using uses udev for devices you should be able to write some udev rules to force the load order for the sound card and the usb fob, provided you don't have two devices of the same type. Where udev breaks down is when you have multiple USB or Zaptel devices of the same type. The load order in these cases can be unpredictable. David Powell-Williams wrote:
Dave,
There have been lots of changes to chan_usbradio since September 2007 I would suggest you do the following updates then report back on any issues you still have:
1. Update asterisk and libpri zaptel to the latest stable "tarball" releases mentioned on asterisk.org.
2. Grab the latest SVN of chan_usbradio.c and all the files in the xpmr directory at:
https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/channels
3. Grab the latest SVN of app_rpt.c at:
https://www.xelatec.com/viewvc/app_rpt/asterisk/trunk/apps/
4. Download the initial asterisk configuration files from;
http://limeylinux.org/downloads/configs.tar.gz
There are 4 directories underneath the main directory inside this tarball. There is one directory for each of the hardware platforms supported. Use only the files in the usbradio directory and the top level directory. Put all files in /etc/asterisk.
Steve WA6ZFT ********************************************* Steve:
I followed your suggestions and recompiled with: Asterisk 1.4.18 Zaptel 1.4.8 Libpri 1.4.3
Chan_usbradio SVN rev 391 App_rpt SVN rev 416
Things are much improved, as you predicted.
The one-way audio seems cured. I note that the audio levels through the USB FOB interface came up by about 20 dB in each direction, requiring a recalibration with radio tune. I also noticed that if Linux is rebooted with the FOB installed, the 2.6.22 kernel grabs the FOB as its primary audio device in preference to the normal sound card. As we all know, Linux reboots are a rarity but, unless one wants to play moh over the radio, it seems best to plug the FOB in after Linux is up and before Asterisk is started.
If anyone else is recompiling Asterisk with chan_usbradio and app_rpt, I have made up a cheat sheet that may be useful. It can be obtained for the price of an email.
Thanks very much for the pointers. I'll get my assigned node number plugged in and look forwards to hearing you and the other Allstar Link members.
73, Dave VE7MQ.
_______________________________________________ App_rpt mailing list App_rpt@lists.illiana.net http://lists.illiana.net/mailman/listinfo/app_rpt
Steve: Thanks. Great idea. I'll do some digging with udevinfo and then see if I can put together a .rules file to force the load order. Might as well give the FOB a cute name while I'm at it. 73 Dave VE7MQ *************** Dave, If the Linux distro you are using uses udev for devices you should be able to write some udev rules to force the load order for the sound card and the usb fob, provided you don't have two devices of the same type. Where udev breaks down is when you have multiple USB or Zaptel devices of the same type. The load order in these cases can be unpredictable.
participants (5)
-
David Powell-Williams -
Don Russell -
Jim Duuuude -
Mark Hagler -
Stephen Rodgers