> That's almost as evil as removing serial and parallel ports from
>> the later laptops (and desktops). A working rotary dial phone
>> greatly amuses the grandkids.
>
>When did they remove them from desktops? I'm just not finding your
>mutant mobos yet.
Search for "legacy-free" motherboards and you'll find quite a few PC-type motherboards without the traditional PC ports on 'em. Interestingly, the ones I found just now were almost all fairly old --- sub-GHz PIII motherboards. More recent motherboards seem to have the usual serial and parallel and even PS/2 ports. I bet that the incremental cost of those is pretty tiny (and mostly due to the physical connectors, not the silicon). WRT Ma Bell, though, the cost of continuing to support pulse dialing has got to be nearly zero, so why eliminate it?
On the other hand, on a laptop (like the one I'm using) there might not be
*room* for the physical connectors, which I assume is why they've gotten pretty rare on laptops. (Also, this laptop is a Mac... but whatever.)
--
Wim Lewis , Seattle, WA, USA. PGP keyID 27F772C1
Support for pulse dialling adds a third to the price of an ATA (analogoue telephone adapter). It requires some costly electronics to decode those sort circuits reliably.
I still don't get this "every cable has to connect to my desktop machine" mentality. This is what we have networks for. I have set up a cheap Mini-ITX box with serial and parallel ports for this old-printer access; and access it over the network. Wireless, even.
Bullshit, bullshit and again I say bullshit. I've implemented dozens of telephone interfaces over the years (the most recent one two summers ago for a 32-port ATA for a VoIP switch).
The total hardware cost to support pulse dialing was zero. Zip. Zilch. Nada. The exact same status bit for loop current that gives hookswitch status, and is polled for flash is used for dial pulse detection.
In most of my designs (including this most recent one) when you pull a path to the DTMF receiver, a task is hung in the fast loop to monitor the flash bit -- if I see any dialpulse activity, I mark that call record as a DP call, and release the DTMF receiver (even a virtual digit receiver is a valuable resource - DSP time is tight).
I'm taking a look at my timesheets for tasks that can be charged against DP support ...
There were about 26 hours at the front, implementing dialpulse support, but it was pretty tightly coupled with flash detection (they both use the same software filter code). There are two bugs in the database about dialpulse which added another smidge to the cost of the design.
11/08/2004 - Bug 351 - FEATURE_REQUEST - Add 20pps support; closed 16/08 SLS - 2.8 hrs
17/08/2004 - Bug 377 - DEFECT - Mixed Dialing Does Not Work closed 17/08 SLS - 1.3 hrs notabug (OK by JJW)
This second bug was interesting -- someone wrote a test case that had someone dial half of the digits with DP and then try finishing with DTMF. I went up two chains of management to get that signed off as "Don't do that."
The entire software budget for the card was roughly $178,000, including management support and overhead. The software for dial pulse support represents about (run off to do some wc -l's) 0.77% of the code by lines-of-code-written. So, about $1400 dollars. Divide that into the first production run (2500 units) and it comprised 54 cents.
I can't disclose the precise unit-cost (NDA, you know), but I will say that to an order of magnitude the cost of supporting dial pulse is between 0.01% and 0.1% and going nowhere but down.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Lawrence Statton - snipped-for-privacy@abaluon.abaom s/aba/c/g Computer software consists of only two components: ones and zeros, in roughly equal proportions. All that is required is to sort them into the correct order.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.