ASLCorporate:History - Revision history

Kg7qin at 06:23, 6 September 2021

2021-09-06T06:23:07Z

Kg7qin: Kg7qin moved page History to ASLCorporate:History: Moved into protected namespace

2019-12-24T08:14:03Z

Kg7qin moved page History to ASLCorporate:History: Moved into protected namespace

Bryan: minor spelling edits

2018-03-15T01:27:06Z

minor spelling edits

Wd6awp at 22:48, 13 November 2017

2017-11-13T22:48:50Z

Wd6awp at 22:45, 13 November 2017

2017-11-13T22:45:37Z

Wd6awp at 22:38, 13 November 2017

2017-11-13T22:38:41Z

Wd6awp at 22:35, 13 November 2017

2017-11-13T22:35:48Z

Wd6awp at 22:33, 13 November 2017

2017-11-13T22:33:31Z

Wd6awp at 22:27, 13 November 2017

2017-11-13T22:27:12Z

Show changes

Wd6awp at 22:17, 13 November 2017

2017-11-13T22:17:25Z

← Older revision		Revision as of 06:23, 6 September 2021
Line 1:		Line 1:
		+	[[Category:ASL Corporate]]
	==The History of App_Rpt==		==The History of App_Rpt==
	By Jim Dixon WB6NIL<br />		By Jim Dixon WB6NIL<br />

@@ Line 1: / Line 1: @@
 ==The History of App_Rpt==
-By Jim Dixon WB6NIL<br/>
+By Jim Dixon WB6NIL<br />
 <p>Once upon a time, there was [http://www.asterisk.org Asterisk PBX]. I was heavily involved in its initial practical implementation <font size="-1">if interested, see below <i>(Zapata Telephony Project as it relates to the Asterisk PBX</i></font>).</p>
 <p>From its very onset, I saw that Asterisk was not only a good telephony switch, but also makes a good application implementation platform for virtually any telecommunication application that requires use of many of the things that Asterisk provides.</p>
-<p>App_Rpt was started, not only to demonsrtate this feature of Asterisk, but to essentially provide an outlet of nearly 30 years of experience and frustration with repeater and remote base systems, in the form of designing a system essentially "the way I think a system should be."</p>
+<p>App_Rpt was started, not only to demonstrate this feature of Asterisk, but to essentially provide an outlet of nearly 30 years of experience and frustration with repeater and remote base systems, in the form of designing a system essentially "the way I think a system should be."</p>
 <p>I learned from and was inspired by some of the best ideas and implementations and also from some of the worst, and tried to create a workable and desirable system that met as many needs as possible.</p>
-<p>My first big hurdle was to design a radio interface that cound interconnect with a PC internally and the typical interface signals of a two-way radio. In the interest of keeping the technology simple and inexpensive, I designed a board (the ARIB board) which interfaced 2 analog FXS ports (either on a multiport analog card, like the [http://www.digiumcards.com/tdm400p.html Digium TDM400P], or a channel bank connected to the PC through a T1 card, that is already part of an existing phone switch) to the Radio signals (and provide buffering, level control, etc).</p>
+<p>My first big hurdle was to design a radio interface that could interconnect with a PC internally and the typical interface signals of a two-way radio. In the interest of keeping the technology simple and inexpensive, I designed a board (the ARIB board) which interfaced 2 analog FXS ports (either on a multiport analog card, like the [http://www.digiumcards.com/tdm400p.html Digium TDM400P], or a channel bank connected to the PC through a T1 card, that is already part of an existing phone switch) to the Radio signals (and provide buffering, level control, etc).</p>
 ===Analog Radio Interface===
 [[File:AnalogRadioInterface.jpg|left|thumb|Rev. C. Analog Radio Interface Board]]
-<br clear=all>
+<br clear="all">
-<p>This interface <i>did</i> work well to allow me to do the initial development of the software, and first half a dozen deployments, since most of us that had it first already had Asterisk phone switches already in opertion, with spare ports on our channel banks.</p>
+<p>This interface <i>did</i> work well to allow me to do the initial development of the software, and first half a dozen deployments, since most of us that had it first already had Asterisk phone switches already in operation, with spare ports on our channel banks.</p>
 <p>The systems were originally deployed in Northern California ([http://www.city-data.com/city/Oakhurst-California.html Oakhurst] area) at a couple of locations, and in San Diego by Steve, WA6ZFT.</p>
 <p>With Steve's greatly appreciated help, we were able to debug the thing and add many new and interesting features.</p>
@@ Line 16: / Line 16: @@
 ===PCI Radio Card===
 [[File:PCIradiocard.jpg|left|thumb|Quad PCI Radio Card]]
-<br clear=all>
+<br clear="all">
 <p>After a few months of the system running stably (despite new additions all the time), we decided that better system integration was appropriate, so we (along with help from David Kramer) designed and produced the Quad PCI Radio Interface card. This allows interface between the PC and 4 separate radio systems simultaneously, via 8 pin modular connectors.</p>
@@ Line 27: / Line 27: @@
 ===USB===
 [[File:Urirearview.jpg|thumb|left|DMK Engineering URI]]
-<br clear=all>
+<br clear="all">
 <p>After looking at many possibilities, including usage of a PC's internal audio subsystem (yuch! yuch! yuch!), it sure seemed that the only realistic chance we had was to get something reliably working with a USB interface.</p>
@@ Line 157: / Line 157: @@
 it to show me how to format (well at least to be functional)
 a minimal Linux driver. So, I ported the BSD driver over to
-Linux (actually wasnt '''that''' difficult, since most of the
+Linux (actually wasn't '''that''' difficult, since most of the
 general concepts are roughly the same). It didnt have
 support for loadable kernel modules (heck what was that? in
@@ Line 178: / Line 178: @@
 <p>At the time, Asterisk was a functional concept, but had no
 real way of becoming a practical useful thing, since it
-didnt, at that time, have a concept of being able to talk
+didn't, at that time, have a concept of being able to talk
 directly (or very well indirectly for that matter, being that
-there wasnt much, if any, in the way of practical VOIP
+there wasn't much, if any, in the way of practical VOIP
 hardware available) to any Telecom hardware (phones, lines,
 etc). Its marriage with the Zapata Telephony system concept

@@ Line 1: / Line 1: @@
 ==The History of App_Rpt==
 By Jim Dixon WB6NIL<br/>
-<p>Once upon a time, there was [http://www.asterisk.org Asterisk PBX]. I was heavily involved in its initial practical implementation (<font size="-1">if interested, see link below <i>(The History of the Zapata Telephony Project as it relates to the Asterisk PBX</i></font>).</p>
+<p>Once upon a time, there was [http://www.asterisk.org Asterisk PBX]. I was heavily involved in its initial practical implementation <font size="-1">if interested, see below <i>(Zapata Telephony Project as it relates to the Asterisk PBX</i></font>).</p>
 <p>From its very onset, I saw that Asterisk was not only a good telephony switch, but also makes a good application implementation platform for virtually any telecommunication application that requires use of many of the things that Asterisk provides.</p>
 <p>App_Rpt was started, not only to demonsrtate this feature of Asterisk, but to essentially provide an outlet of nearly 30 years of experience and frustration with repeater and remote base systems, in the form of designing a system essentially "the way I think a system should be."</p>
@@ Line 236: / Line 236: @@
 <p>
-''Editors note: Jim became a SK in December of 2016. My best guess it these articles were written around 2006.'' </p>
+''Editors note: Jim became a SK in December of 2016. My best guess it these articles were written around 2006. I've applied minor formatting changes for readability.'' </p>

← Older revision		Revision as of 22:45, 13 November 2017
Line 234:		Line 234:
	help with this project. Thank you for demonstrating that you		help with this project. Thank you for demonstrating that you
	believe in it, and that you believe in us.</p>		believe in it, and that you believe in us.</p>
		+
		+	<p>
		+	''Editors note: Jim became a SK in December of 2016. My best guess it these articles were written around 2006.'' </p>

@@ Line 107: / Line 107: @@
 <p>But to my dismay, no one had done anything about this. What I hadn't
 realized was that my vision was 100% right on, I just didnt know
-that *I* was going to be one that implemented it.</p>
+that '''I''' was going to be one that implemented it.</p>
 <p>In order to prove my initial concept I dug out an old Mitel
 MB89000C "ISDN Express Development" card (an ISA card that
@@ Line 157: / Line 157: @@
 it to show me how to format (well at least to be functional)
 a minimal Linux driver. So, I ported the BSD driver over to
-Linux (actually wasnt *that* difficult, since most of the
+Linux (actually wasnt '''that''' difficult, since most of the
 general concepts are roughly the same). It didnt have
 support for loadable kernel modules (heck what was that? in
@@ Line 165: / Line 165: @@
 kernel with it included). Since my whole entire experience
 with Linux consisted of installation and writing a kernel
-module, I *knew* that it *had* to be just wrong, wrong,
+module, I '''knew''' that it '''had''' to be just wrong, wrong,
 wrong, full of bad, obnoxious, things, faux pauses, and
 things that would curl even a happy Penguin's nose hairs.</p>
@@ Line 215: / Line 215: @@
 doing this project? Have you ever thought of how incredibly
 many things that he has to concern himself with, and that it
-just *NEVER ENDS*! At this point, I believe that I have
+just '''NEVER ENDS'''! At this point, I believe that I have
 worked with him on this project longer that just about
 anyone, including some of his employees, and believe me, I
 have a good vantage point to see at least some of the stuff
 that he has to go through to accomplish this.</p>
-<p>Personally, I would have *NEVER* taken on such a task, being
+<p>Personally, I would have '''NEVER''' taken on such a task, being
 that I am and was quite aware of the level of responsibility required
 to do so.</p>

@@ Line 54: / Line 54: @@
 today's standards (not to mention the horrendously pessimal
 environment in which they had to run), and still cost upwards
-of $1000 each. Most of these cards ended up being really bad
+of $1,000 each. Most of these cards ended up being really bad
 sounding and flaky personal answering machines.</p>
 <p>In 1985 or so, a couple of companies came out with
-pretty-much decent 4 port cards, that cost about $1000 each
+pretty-much decent 4 port cards, that cost about $1,000 each
 (wow, brought the cost down to $250 per port!). They worked
 MUCH more reliably then their single port predecessors, and

@@ Line 1: / Line 1: @@
 ==The History of App_Rpt==
-'''By Jim Dixon WB6NIL'''<br/>
+By Jim Dixon WB6NIL<br/>
 <p>Once upon a time, there was [http://www.asterisk.org Asterisk PBX]. I was heavily involved in its initial practical implementation (<font size="-1">if interested, see link below <i>(The History of the Zapata Telephony Project as it relates to the Asterisk PBX</i></font>).</p>
 <p>From its very onset, I saw that Asterisk was not only a good telephony switch, but also makes a good application implementation platform for virtually any telecommunication application that requires use of many of the things that Asterisk provides.</p>
@@ Line 74: / Line 74: @@
 spend over $1M/year alone, not to mention several others that
 came close) on high density Computer Telecom hardware.</p>
-<p>It really tore me apart to see these people spending $5000 or
+<p>It really tore me apart to see these people spending $5,000 or
-$10000 for a board that cost some manufacturer a few hundred
+$10,000 for a board that cost some manufacturer a few hundred
 dollars to make. And furthermore, the software and drivers
 would never work 100% properly. I think one of the many
@@ Line 101: / Line 101: @@
 be soon, so I kept a much more watchful eye out.</p>
 <p>I figured that if I was looking for this out there, there
-*must* be others thinking the same thing, and doing something
+'''must''' be others thinking the same thing, and doing something
 about it. I looked, and searched and waited, and along about
 the time of the PentiumIII-1000 (100 MHz Bus) I finally said,
@@ Line 140: / Line 140: @@
 Zapata. I decided to call the card the "tormenta" which, in Spanish,
 means "storm", but contextually is usually used to imply a
-"*BIG* storm", like a hurricane or such.</p>
+" '''BIG''' storm", like a hurricane or such.</p>
 <p>That's how Zapata Telephony started.</p>
 <p>I wrote a complete driver for the Tormenta ISA card for *BSD,
@@ Line 210: / Line 210: @@
 software, the technologies have come a long, long way, and
 continue to grow and improve every day.</p>
-<p>Footnote:</p>
+<p>''Footnote:''</p>
 <p>Has anyone ever taken a moment to sit back and consider the
 ENORMOUS responsibility that Mark has taken upon himself by

@@ Line 8: / Line 8: @@
 ===Analog Radio Interface===
-[[File:AnalogRadioInterface.jpg|left|Rev. C. Analog Radio Interface Board]]
+[[File:AnalogRadioInterface.jpg|left|thumb|Rev. C. Analog Radio Interface Board]]
 <br clear=all>
 <p>This interface <i>did</i> work well to allow me to do the initial development of the software, and first half a dozen deployments, since most of us that had it first already had Asterisk phone switches already in opertion, with spare ports on our channel banks.</p>
@@ Line 15: / Line 15: @@
 ===PCI Radio Card===
-[[File:PCIradiocard.jpg|left|Quad PCI Radio Card]]
+[[File:PCIradiocard.jpg|left|thumb|Quad PCI Radio Card]]
 <br clear=all>
 <p>After a few months of the system running stably (despite new additions all the time), we decided that better system integration was appropriate, so we (along with help from David Kramer) designed and produced the Quad PCI Radio Interface card. This allows interface between the PC and 4 separate radio systems simultaneously, via 8 pin modular connectors.</p>
@@ Line 25: / Line 25: @@
 <p>For the next 2 years, we kept adding features, and refining the ones we had, and discovering that even though MANY people were QUITE interested in the technology, the price for entry was a bit high (for those who had no experience and wanted to just evaluate it). It became painfully obvious that something had to be done, somehow, to allow the hardware interface price to be lowered considerably without sacrifice in the quality of the technology.</p>
 <p>After looking at many possibilities, including usage of a PC's internal audio subsystem (yuch! yuch! yuch!), it sure seemed that the only realistic chance we had was to get something reliably working with a USB interface.</p>
 <p>Experiments with USB several years previously show it to be utterly flaky and useless on Linux, and not much better even on Windows. But, since that's about all that's available any more (other then maybe Firewire, which is more or less the same thing) I figured we should re-visit the possibility of stable USB, and did so and found success. Its good that things change.</p>
-<p>After some looking around, I found the <a href="http://www.cmedia.com.tw/?q=en/USB/CM108"> C-Media CM-108</a> USB Sound IC. It is VERY simple, VERY high quality, VERY reliable and VERY inexpensive. Even already make USB sound cards (well, sound devices, they're awfully small to call a card) that could easily be modified for development and testing purposes.</p>
+<p>After some looking around, I found the [http://www.cmedia.com.tw/?q=en/USB/CM108 C-Media CM-108] USB Sound IC. It is VERY simple, VERY high quality, VERY reliable and VERY inexpensive. Even already make USB sound cards (well, sound devices, they're awfully small to call a card) that could easily be modified for development and testing purposes.</p>
 <p>So after some testing and verification of the USB hardware, I went to my friend Steve Henke, W9SH (who had already done some major work on the IAXRPT project for us), and asked him to use his amazing DSP skills to write code to do two-way audio processing right in the PC (going along with the Zapata Telephony motto of <i>"We don't need no stinkin' DSP!"</i>), which, happily he did.</p>
-<p>We now have functional DSP code and channel interface code to allow USB devices to interface with <a href="http://app-rpt-svn.ohnosec.org/viewvc/projects/allstar/?root=svn">App_Rpt</a> and <a href="http://www.asterisk.org">Asterisk</a>, allowing high-quality, yet inexpensive interconnection with radio devices.</p>
-<p>Currently, A URI (USB Radio Interface) is being sold specifically for this purpose (see <a href="http://www.dmkeng.com">DMK Engineering URI Site</a>)
+<p>We now have functional DSP code and channel interface code to allow USB devices to interface with App_Rpt and Asterisk, allowing high-quality, yet inexpensive interconnection with radio devices.</p>