José Miguel Parrella Romero

In the past, I’ve used PCI cards providing telephony TDM for my Asterisk-based projects. I’ve only worked with Digium’s FXO/FXS and T1/E1 cards, both in PCI and PCI-x formats, until a client asked for a gateway solution with FXO, FXS and E1, where using the PCI cards in a 1U IPBX was simply out of the question.

Using Ethernet gateways has always been a problem in those cases, since entry-to-medium level solutions lack the processing power for massive call handling, and signalling is poor, making the architecture unfit for reporting purposes and specialized apps such as call centers. But hey, that’s my experience with gateways.

Therefore, I looked into Xorcom’s Astribank. They pack FXO, FXS and PRI/BRI ports inside a convenient 19″ 1U case, which can connect to an Asterisk-based IPBX server via USB and gets recognized as an integral DAHDI device in modern setups.

So I ordered a composite 8xFXO, 8xFXS and 1xE1 PRI from Astribank, labelled XR0072. Getting the equipment from Arizona to Florida was easy, and since I worked with DHL, getting it to Guayaquil in Ecuador was a breeze (next-day delivery) but passing customs is, as always in Latin America, a time-consuming operation. After paying 12.5% taxes and then some for DHL operations, and 15 days waiting, I got the equipment in Quito.

To my surprise, the Astribank was extremely light and small, slightly near 3 Kg in 1U form factor and under 1/4 depth in the rack. While it had a rack-mounting kit, which I used, it could also rest securely over my IPBX without rack screws.

My Astribank uses a single USB cable to connect to the “master” PBX — it could also be connected to a secondary PBX and provide a fault tolerant setup. It also depends on a DC supply, which they included. Since I was using a modern Debian, with a modern Asterisk with already-compiled modern DAHDI (formerly called Zapata/Zaptel) drivers, I just connected the equipment via USB to the IPBX, issued an invoke-rc.d dahdi restart and we were good to go.

Note: you do need the fxload package in Debian for firmware loading to the Astribank. And for “good to go” I mean you can check the registered spans with dahdi_registration and, as soon as you connect the E1 cable that comes from the CPE to the CPE port (which in my XR0072 is the first on the lower row for PRI) you get an OK status with dahdi_tool. Also note that I use an E1/CPE port, which is the default for the Astribank, otherwise I’d have to set the XPP_PRI_SETUP variable as indicated on the User Manual.

DAHDI insists on configuring a crc4 parameter for the detected spans, which I needed to remove and restart DAHDI so the equipment could ‘sync’ with the CPE (that is, the box that the telco provided, with the balun and the crossover RJ45 cable) and avoid some nasty noise issues on the line, that also occur with Digium’s Wildcard for PRI.

usb:008/005          xpp_usb+     e4e4:1162 Astribank-modular FPGA-firmware
 LABEL=[usb:...]       CONNECTOR=@usb-0000:00:1d.7-1
	XBUS-00/XPD-00: E1       (31)  Span 1  DAHDI-SYNC
	XBUS-00/XPD-10: FXS      (8)   Span 2
	XBUS-00/XPD-20: FXO      (8)   Span 3

Using DAHDI’s dahdi_genconf command writes an /etc/asterisk/dahdi-channels.conf file with the group and channel configuration as detected by DAHDI. It should be included by the chan_dahdi.conf file, which, in my case, is not necessary since I only wanted to enable one DAHDI group (DAHDI/g0) with my 31 E1 channels (1-15,17-31)

group=0
context=from-pstn
channel => 1-15,17-31

That means that when I want to use the FXO/FXS ports, it’d probably be easier to include the dahdi-channels.conf (FXS ports, for example, belong to a different context, from-internal) so I don’t have to type more than my laziness permits.

I also found that, in my setup, some Asterisk parameters were superfluous, such as the switchtype (either national or euroisdn work, and the former is the default) or the echo-cancelling stuff, so I assume Astribank’s doing a great job in negotiating that with the CPE. Do take note, however, that in my case the CPE needed to be cold-restarted so I could get an ‘Up’ status in Asterisk (pri show spans) and that my only non-default, channel related configuration in chan_dahdi.conf is signalling=pri_cpe.

So far, so good. I’m really happy with the Astribank and I can fully understand how useful it is in terms of price (quite competitive in comparison with traditional cards, specially when bought from resellers -like me-), size/weight and functionality/ease of setup and administration. Kudos!

Update: Using Debian Sid, the video acceleration is not working correctly. glxgears shows a black screen with a glimpse of the gears when I move the window, but GLX-enabled applications aren’t showing up even correctly. Changing the AccelMethod doesn’t improve the situation. One of the readers asked how did I calibrate the screen. I added the information below.

Last year I got my hands on an Acer Aspire 1420P. It’s now running Debian GNU/Linux unstable, and I’m transitioning from my older Thinkpad T400. Of course, it won’t install and work flawlessly out of the box, so here are my notes.

Ethernet

Use a recent kernel, say, 2.6.32 (2.6.32-3-686 in Debian, for example), since the Atheros GigaEthernet card won’t work in older kernels without patching (e.g., you get a link but can’t actually send packets). My lspci reports the Ethernet controller as Attansic Technology Corp. Device 1063 (1969:1063) which uses the atl1c kernel driver.

Wi-Fi

The Wi-Fi card, an Intel WiFi Link 100, which my pci-utils report as 8086:0083, needs a recent firmware-iwlwifi (or a recent firmware for that card, if you don’t use the package) which I also took from sid.

Tablet touchscreen

It works with the evtouch driver, but you’ll need to apply a patch to xf86-input-evtouch (0.8.8 is both in sid and lucid) and calibrate the tablet. It seems like the screen rotation does not generate an ACPI event, but if you attach a button with the xrandr rotation, you don’t need nothing else for evtouch to catch up. Screen’s multitouch, but software doesn’t support it yet.

Calibration: the xf86-input-evtouch package includes a calibration utility which presents users with crosshairs which you have to click in order. This program should output the minimum and maximum parameters for the evtouch driver in xorg.conf (actually in an out.txt which you should manually merge), but in my case, it didn’t. On the code for ev_calibrate, it should output the information to /etc/evtouch/config, but not in a xorg.conf compatible file.

So, just copy the values for min[x,y] and max[x,y] in a correspondent InputDevice section on xorg.conf as follows:

Section "InputDevice"
  Identifier "Touchscreen"
  Driver "evtouch"
  Option "Device" "/dev/input/event1"
  Option "MinX" "0"
  Option "MinY" "0"
  Option "MaxX" "3825"
  Option "MaxY" "3825"
  Option "ReportingMode" "Raw"
  Option "SendCoreEvents" "On"
  ...
EndSection

Things that work

Integrated Intel Mobile graphics chipset, Huawei integrated HSDPA modem (shows up as ttyUSBn), audio, wireless provided you have firmware, webcam, ACPI events for almost everything (lid rotation doesn’t seem to work), function keys… it’s all working nicely. This model has a Core 2 Duo U2300 processor and 2 GB. RAM.