Recently in Phones Category

Droid Ringtones

| No TrackBacks

On your storage card, or the device itself (the X2 shows up as a USB drive under Mac OSX, making this a drag-drop no-software install job):

mkdir /ringtones

mkdir /audio
cd audio
mkdir notifications
mkdir ringtones
mkdir alarms

Place your mp3s, wavs into the appropriate directories. If you have really short wav files, add some silence to the beginning of the wav to pad it out where the audio system is on line. I had to do this because I use a few short wavs for notification. The "Nextel Chirp", actually a Motorola "Talk Permit" tone -- an old hold-over from Motorola Trunking Radio -- is only 90 ms long. However, it seems that the Droid X2's audio system isn't on line in 90 ms. Adding about 600 ms of silence allows the wav to be played fully.

I didn't bother getting scientific with this one, I've got better things to do. ;)

SDSL Pipelines

| No TrackBacks
Or what I know about them now that you don't.

Years and years ago, I got introduced to the Pipeline series of routers by a friend and employer. As a way to save money, he had obtained an Ascend Pipeline P130 and used it to replace a Cisco 3640, saving some $500 a month in router rental. The catch was that I had to figure out how to make it talk to the provider's circuit. This was easier than realized, once I had them on the phone and they told me they could switch the DS1 over to PPP instead of Cisco HDLC. When they did, the circuit came up. A few months later I attempted to the same trick with a new provider network and a different version Lucent Pipeline P130, and had absolutely no success for several days. Finally, I noticed the "Nailed Group" number on the new router was set to "1" and the old, working router was set to "3". I changed the Group over to "3" and got lock on the WAN light.

After much consternation with discovery of more sub-variants of Pipeline Routers than there are species of cacti, I finally succeeded in obtaining two SDSL Pipelines which were close enough in feature set so as to support communication with each other. These routers turned out to be Lucent Cellpipes, specifically the DSL-CELL-50S.

Of course, they proved again to be a source of MUCH consternation, as no setting seemed to convince them to talk to each other. Having worked in a xDSL test lab some years ago for a major chipset manufacturer, I knew these could talk to each other, as I had seen one used as a CO device, and read the specs myself and knew that any device that could provide the head-end side of the circuit. Knowing that ATM was intimately involved in the lower DSL levels, I opted to configure the modems in ATM-VC mode, and configured them to bridge.

Bridging on the Pipeline is a very dodgy proposition. Most of the providers used bridging, which lead to the Pipeline getting a bad reputation. At only 25MHz or so of CPU, the processor would attempt to bridge the entire traffic of the 10Mbit ethernet segment onto the WAN circuit, while copying the incoming WAN circuit data out the ethernet port. The end result was that the CPU was constantly overwhelming, servicing interrupts continuously and trying to IO itself to death. On the other hand, if you forced it to do only IP routing, the little bastards flew, happily updating the interactive terminal interface while responding to SNMP. I once schemed to build a BGP router out of a FreeBSD PC using a pair of Pipeline P130s bridging ethernet to DS1s and terminating the PPP session on the PC using PPPoE. Unfortunately, our network never got large enough for that. Such were the days of the DotComs and the fickle ways of the investor.

Back to configuration of the Pipelines,  I set the DSL layer to communicate using ATM VCs over VPI 8 and VCI 35. In the lab we expressed this as "8.35", or "0.35" depending on what port we were using. On the outside, the inner workings of ATM were too complicated for most people to understand, so the VPI.VCI just became another meaningless setting that HAD to be input exactly for the system to work. After the ATM was configured, I rolled back a step and set the modems to communicate at a single DSL speed ("mode=singlerate") of around 2.3Mbit/s. Now the modems started attempting to lock to each other, but kept dropping the call. I set one to COE, and the other to CPE, then configured the COE unit to only answer the call, and the CPE unit to only call, never to answer. Now the calls were being initiated, but data was not flowing. "What the hell could the problem be?" I asked myself.

Fortunately, the several modems I had gather had documentation. One of them actually had the xDSL specific menu addendum, but all of them explained in a physical layer independent method how Ascend Bridging worked, and how the PPP system was used. "Knowing" how PPP worked and that the circuit was largely free of eavesdropping, I configured the units to use PPP over ATM (PPPoATM) to pass traffic to each other. The PPP system was setup to use PAP, and an arbitrary password was selected and configured into both modems as the recieved (expected) and the sent password. Likewise, I named both of the DSL modem's names (or names under Connections) to "DSLPipe". This way, both modems would ask each other for the same bits of information, allowing either modem to assume the role of COE or CPE depending on how I got them configured.

At this point, I have two modems configured to only use 2.3Mbit/s as a rate, ATM-VC 8.35, PPPoATM, and Ascend Bridging over the PPPoATM. As soon as the call went up, traffic started flowing! Now to start tinkering...

First change was to turn of VJ compression and header compression. This brought throughput up to 2.0Mbit/s instead of 1.024Mbit/s. I left bridging on, as I didn't want to explore networks at this time, since most of my home network was a single LAN anyway, and I lacked other devices I could plug in and test connectivity with. Finally, I set both modems to autobaud, with the baserate set to 2.3Mbit/s and the SDSL data rate set to 2.3Mbit/s. They auto-negotiated as expected, and dealt with the interruptions as expected. Finally, I set the circuit type to Nailed on both sides, so that if either end went down, an attempt would be made to restart the connection.

And the data kept flowing. Not entirely bad for only about four hours of work. And the two modems were connected over an eight foot piece of RJ-11 patch cable.

So now you know what it takes to make those bloody modems work. Next project is to attempt the same with the V.35 Pipelines, which are basically a retarded version of the modem I already described.

Originally, I got these modems to attempt a bidirectional data link over 900MHz. By cutting away the resistive Wheatstone bridge-hybrid in the front end of the modem, it is possible to separate out the receive side from the transmit side. By piping these signals to separate block frequency converters (heterodyning transverters), it is possible to put them on the 900MHz amateur band. The benefit to using DSL modems for this purpose is that they already possess adaptive electronics in programming, which allows them to redistribute the bits as the channel capacity allows. If, for instance, a carrier appears and stays in a given place, the modems may alter speeds or re-profile the channel. This allows me to focus on getting the bits where I want them to go, and fiddling with RF, leaving the DATA layer delegated to prior art.  Thank you for reading what may be my longest post ever.

Also, this information is copyright 2010 by Kris Kirby, and all rights are reserved. You may not use any of this information in support of an eBay auction.

It is important to remember that ATM is involved here, so there is a percentage of that which cannot

About this Archive

This page is an archive of recent entries in the Phones category.

Networking is the previous category.

Power is the next category.

Find recent content on the main index or look in the archives to find all content.