Bits From My Basement
A Collection of Material by Bdale Garbee, KB0GIt seems like a long time since I was a member of the board of directors of TAPR, the Tucson Amateur Packet Radio association. At some point during my tenure on the board, I somehow got motivated to start writing a regular "packet radio gossip column" for the TAPR newsletter, PSR. It was called "Bits in the Basement", and I get comments from folks about it to this day...
After a bit of digging around, I've located files containing the text of some of the later columns. I'll keep my eyes out for the rest of them as I continue to shuffle things around "the Basement".Bdale Garbee, firstname.lastname@example.org
Bits in the Basement
- 1991: Third Quarterly Issue, and My Last Column
- 1991: Second Quarterly Issue
- 1991: First Quarterly Issue
Assorted descriptions of Hardware projects that I've undertaken over the years.
- Using a DE-1200 Modem in a Digital Repeater
- Motorola Mitrek Radios Information on modifying Motorola Mitrek radios (VHF and UHF) for both half and full duplex 9600 baud operation, including digital repeater service.
Bits in the Basement 1991 Q3by Bdale Garbee, N3EUA Welcome to the last installment of Bits in the Basement. This time, I'll talk a bit about the Packet Racket meeting in Grand Junction, CO, convey my impression of Dayton this year, talk a bit about the state and future of TAPR, and wrap up with some thoughts on what I'll be working on for a while.
Packet Racket 1991On Friday, March 29th, Karen and I travelled west to Grand Junction, CO, near the border with Utah, for the annual Packet Racket meeting organized by hams on the "western slope" of Colorado. It was an interesting trip for several reasons. It snowed on us on the drive out. The meeting itself was very well organized, and represented significantly more enthusiasm and activity than I'm aware of on the "eastern slope" of Colorado. And some interesting brain-storming occurred on the linked voice repeater system driving back towards home on Sunday.
The meeting itself was on Saturday, with presentations on a variety of subjects, from new user fundamentals, to NET/ROM node operation, to amateur satellites. I consumed a big chunk of the afternoon talking about packet "on the bleeding edge", and we had a live demo of several high speed link technologies, and the Gracilis PackeTen switch in operation.
I really enjoyed this meeting, and Karen and I may well try to drive out again next year if the folks in Grand Junction put the show on again! My thanks to everyone at the meeting for making us feel welcome, and particularly to Al WA4HND and Don N0LEU who talked me into being there despite other committments.
One of the questions I've pondered since the meeting, and which I don't yet have an answer for, is what was so different in Grand Junction from the Front Range in Colorado that caused folks to all seem to have so much more enthusiasm. Maybe the folks involved are newer to packet, and just fresher, and less burned-out? Maybe there's something about being not being able to talk to the next packeteer down the line without being active enough to climb and mountain or two and install the intervening nodes? Dunno...
Dayton 1991To start off with the summary, the Dayton Hamvention seemed sort of weird to me this year. Several factors probably contribute to this impression. For one, I spent almost the whole weekend in the booth run by Gracilis, Inc., formerly known as Grace Communications. These are the folks who build packet switches based on the Motorola 68302 processor that I've talked about in previous columns. I arrived with "one each" modem and radio combinations from 1200 baud, through 9600 baud, to 56kb. I also dragged along an HP 9000/400t workstation equipped with name server and callsign database server to use showing off my favorite model for providing packet radio applications. We put all of the gear on the air, and had a fairly interesting network running in the booth for the weekend, demonstrating everything from 56kb access to the Unix box, to a 1200 baud AX.25 station connecting to the "terminal server" built into a Gracilis switch, and from there to everything else on our "network".
Probably the most fun I had all weekend was making all the RF pieces work! No, really, it *was* fun! We put big Kenwood dummy loads on the two 430Mhz transverters hooked to the 56kb modem, with enough RG-58 between the transverters and dummy loads to get the two dummy loads next to each other. The silly dummy loads were tight enough (much better than the cruft I use at home!) that I ended up twisting the coax runs together 7.5 turns and taping them in place to inductively couple the two units. It worked great! We ran thousands of packets through the weekend, and dropped less than 10... This seems like a near-perfect way to survive the RF hell at Dayton, because the dummy loads meant we were neither contributing to, nor susceptible to, what must be one of the more intense electromagnetic field situations ham gear ever encounters. I offer this as my "free tip of the day" to folks trying to run demos of RF gear at Dayton...
A special thanks to my wife Karen N1FED, who located a 24-hour grocery store and made sure we didn't have to eat any "arena-food" all weekend...
A second contributor to the weekend was the rain on Friday morning. I understand there was a flood of sorts in the flea. Inside, the organizers came on the PA just before the interior exhibits opened at noon... saying that there were thousands of soaking wet people pushed up against the doors waiting for noon so they could come in out of the rain. Mixed with a metal-roofed building with the ventilation fans all turned off, and the humidity right after noon went asymptotically towards infinity. I was *not* a pretty sight, particularly since I live in and love the high country of Colorado where real humidity just doesn't exist. Ah well, reminds me of college in Pittsburgh...
I did leave the Gracilis booth on Saturday afternoon and again on Sunday morning for just long enough to hit the booths of all the other packet vendors and pick up some literature. It was disappointing that noone seemed to have anything new to offer the high-speed packet afficiando other than Gracilis... for the second year in a row.
Here's a quick rundown of what I found interesting at packet vendor booths: AEA had "released" the DSP-based PK-232 replacement, but according to a spokesperson at the booth, was "a month or two away from shipping". I'm not sure what that means exactly. Maybe by the time you read this the unit will be available, maybe not. I won't try to predict AEA's shipment plans, I've made that mistake before.
Kantronics was showing the DVR4 radio. This is a UHF, 10watt derivative of the DVR2-2 I've talked about before. It apparently fixes some of the complaints folks had about the DVR2-2, and obviously moves to a band more available to many packeteers for 9600 baud and faster operation. Kantronics supposedly has a DE-19200 modem that couples up painlessly with this radio.
Paccomm had nothing new from a technology standpoint at their booth this year that is available to hams. I've lost track of the number of TNC, G3RUH modem, and software variations that they're selling now. It makes for an impressive, if somewhat repititious, display. The most exciting thing at the Paccomm booth, quite frankly, was the prototype 900Mhz spread spectrum hardware they were showing that resulted from a commercial contract. See my column in the last issue of PSR in the section regarding part 15 operation for more thoughts on this subject.
The TAPR booth highlighted the METCON-1 telemetry and control system, built around 8051 microcontroller hardware. This is an interesting item for TAPR, being the first purely "application" product that I remember. There was also news of the packetRADIO and DSP projects (which I'll leave to other TAPR folks to report), and the usual brisk sale of DCD mods, TNC upgrades, and packet software on floppies.
I missed the GRAPES crowd's flea market space this year, but did manage to buy another 56kb modem kit thanks to their excellant "delivery service" to the booth... thanks guys! The Ottawa crowd was much in evidence, with bright blue "PI card" shirts (blue seemed to be the "in" shirt color this year!), and a backpack full of boards for sale. It was fun seeing everyone again...
But, overall, Dayton 1991 wasn't as exciting for me as some I remember.
Field Day 1991It has been a tradition for several years (but not last year, when Karen and I were on the way to Paris!) for a variety of folks from HP and other companies in Colorado Springs and Denver to arrive in the Bit Basement for a laid-back stab at Field Day, Bdale-style. This year was no exception!
John Conner, WD0FHG, once again volunteered his Honeywell motor-generator widget that takes nominal 12VDC in one side and puts out up to 500W of 120VAC on the other side. My wife Karen N1FED graciously loaned us the use of her 1980 VW Rabbit for the duration. We ran class "1E", for one simultaneous transmitter at a home station on emergency power. We just crank up the Rabbit, wire-tie the throttle cable to maintain 13.5V or better at full load, and let it run for 24 hours! With the hood up, and the garage door open, the radiator fan ran about 40% duty cycle this year, and we got almost the full 24 hours on one tank of fuel before we had to refill.
We ran about 50w from my TS-430S as NE0V. If you worked us while we were calling CQ on 20m SSB early Sunday morning, you talked to me without knowing it! If I allowed myself to get interested in HF, contesting would consume all my time. As it is, this was my first time on HF since Field Day two years ago!
A special thanks to Dave N0IPQ who stuck it out all night, catching a couple hours sleep on the futon in the guest room before morning, and hanging on until noon Sunday. And congrats to Bob Sterrett from HP, who made a few contacts on 80m SSB in the wee hours for us, and who just might get his license someday, if we keep needling him! (nudge, nudge... wink, wink...)
The down side of having Bob around, however, was that he started razzing me about not having a packet station on the air at all. I should never have given him a copy of the Field Day rules to read! The second time he said "of all people, Bdale, you ought to be able to get us the 100 bonus points for a packet contact!", I relented. The problem was, what to put on the air? I traded the PK-232 for 48 feet of freestanding Rohn tower. I sold my HD-4040 to some college kid in Maryland. The Kenwood 2600 I used to use with my Tasco pocket TNC (and for which I had a cable made up) now belongs to N0IPQ, and he didn't have it with him. I didn't have a cable for my one remaining KISS TNC-2 for any radio I still own... and noone else in town would be running Field Day on 430.15 at 56kb!
Fortunately, my digging around in the boxes from Field Day brought up a brand new Gracilis PackeTwin PC plug-in board. I'd brought one back from Dayton to play with "when I had time". It was still in the box, with a floppy and a manual. I found a cable I'd made up to hook my Kantronics DVR2-2 to a Kantronics 1200-baud modem board I plan to use on my Gracilis PackeTen switch fanout card... that had never been tested. To make a long story short, the docs were good enough for us to have the card in a PC in about 10 minutes, most of which was spent figuring out which interrupt to use and attaching the 1200 baud modem card to the PackeTwin with the two provided screws. The software installed in a subdirectory in no time flat, and there was an example config in the docs except for the interrupt vector we'd chosen for the card. Start to finish, in under an hour Bob (who had never seen a working packet station) and I had the PackeTwin on the air running the Gracilis windowed version of NOS, and had made our first contact with KE9S to get the 100 bonus points! We worked WA0VTU, the local club Field Day station, and tried to leave a message for our section manager to snag more bonus points, then called it a night.
As much as I heard Don N4PCR talk about providing a complete solution for packet at Dayton, and as often as I'd seen Dan or Don stuff a PackeTwin in a PC and make it work, this was my first experience with the card solo, and I really *was* impressed at just how easily it all went together. My past experiences with Paccomm PC-100 and DRSI PCPA PC plug-in cards, and all manner of regular TNC's, were a lot more frustrating...
Why This is My Last ColumnI'm sure you've been wondering since the first paragraph of this column why I say this will be the last... There are two main reasons.
I'm finding that I have less time to work on packet things now than I used to, mostly because of circumstances at work. That makes it hard for me to "do enough neat stuff" to write a column just about what is going on around here, and doubly hard to do a good job of keeping up with what other folks are working on well enough to talk about it without making a fool of myself. Frankly, I'd rather spend the few hours each week I've got for my hobbies these days hacking on hardware than writing...
The second reason is one that I hesitate to mention, but which I believe the TAPR membership is going to have to deal with at some point anyway. I now have a small financial interest in the future of Gracilis, and expect to work on a number of projects relating to enhancement of the PackeTen standalone switch product. I talked about a lot of my ideas to many of you at Dayton. What has changed since then is a building commitment on my part to do some of the things I want to do anyway as products for Gracilis, instead of on my own as a simple user. The win for you is that I won't be the only one to benefit from my efforts, since anyone will be able to buy the results off the shelf.
Overall, it no longer seems appropriate to me to try and be TAPR's "packet gossip columnist". I feel less strongly about the appropriateness or lack thereof of continuing to serve on TAPR's board, but my evolving work situation makes it unlikely that I'll run for re-election when my term expires this year... I just can't commit to another three years at this time, regardless of how I feel about the conflict of interest issue.
Take this as early encouragement to think about who you'd like to nominate and elect to the board next time! TAPR desperately needs new blood at all levels of the organization to survive.
The End...Writing "Bits in the Basement" has been, for the most part, a neat experience. I would especially like to thank those of you who have taken the time to write, or call, or even better... send me email! I apologize if I'm cutting this short before taking time to use all your suggestions for things to write about, but I suppose that's just how the world works.
I'm not going to disappear completely from the pages of PSR. I suspect that every couple issues I'll try to put in a short article about one or another project I'm working on. I had hoped to talk this time about a widget I've designed to provide power and an RS-422 interface for WA4DSY 56kb modems, but a corporate audit at work stole enough of my "spare time" that the prototype isn't finished yet. Maybe I'll try my hand at a real construction article for next time? Who knows...
I will continue to be reachable by all the usual means. I'm still email@example.com at work, firstname.lastname@example.org will reach me at home, and I still check Easyplex mail on Compuserve every week or so at 76430,3323.
73, and CUL!
Bits in the Basement 1991 Q2by Bdale Garbee, N3EUA Hi! This time around, I'm a bit rushed putting this column together. The good part is that I'm rushed because there's lots of interesting things going on... I'll start this time with my impressions from the TAPR annual meeting, and end with what I know about Dayton this year. In between, I'll try to hit a few highlights of activity in the Bit Basement since the last issue.
TAPR 1991Probably the first thing that comes to mind when I think back on the weekend spent in Tucson this March, is that the Board of Directors meeting on Friday was by far the most calm and straight forward of any that I have participated in or heard about to date. A couple of obvious factors contributed. We had zero difficulty electing a slate of officers, since Bob W6SWE had already expressed a willingness if elected to the BOD to serve as President this year. That's been the tough job to fill the last couple of years. We also didn't have any particularly controversial issues on the agenda this year. All in all, it was... shall I say... the "least unpleasant" board meeting I've been part of.
The one disappointment I might voice about the board meeting really wasn't part of the meeting at all, but a misperception voiced by a member on Sunday morning. With the exception of brief periods surrounding discussion of commercial licensing agreements and royalties where we have an obligation to the manufacturers to maintain the confidentiality of their sales, plans, and so forth, all TAPR board meetings are open to the public. You won't find us actively encouraging lots of folks to come sit in, because to be honest things tend to go more quickly when there's a smaller group present. But we have always welcomed questions and input from the membership, and continue to do so! It's also probably worth mentioning, in case it isn't general knowledge, that the TAPR board meets in "continuous session" on a private area of Compuserve year-round, so if you ever have an issue you'd like to bring to the board, a project proposal that you'd like to seek funding for, or anything else we ought to hear... then contact any one of the TAPR board members certainly including me, and ask us to convey a message to the board at large on CIS! It's easy, and we'd welcome the input.
The most wonderful and most painful part about an organization like TAPR is that it is no more and no less than the sum of those who are participating members. The next time you find yourself saying "TAPR" in a sentence and meaning someone else... go find a mirror and take a hard look at yourself. You *are* TAPR, and whether TAPR is working on what you think is important or not is largely a function of whether you are actively involved or not! I've commented in this column before about how amazed I am sometimes at the perception that TAPR is some mystical entity. It really isn't! It's just a bunch of folks like you and me trying to make a contribution to the hobby, and have some fun at the same time...
The general meeting this year included some interesting presentations. I hope someone else will publish a full report, because to be honest I was doing my usual thing, popping back and forth between conversations in the lobby and the presentations. There were two presentations that stick out in my mind, however... and they are related.
Jon Bloom, KE3Z, gave an update on what is happening at the ARRL. Part of his discussion focused on the recent incidents regarding improper content of traffic on the PBBS network. This is an issue that we should all keep our eyes on, because it has the unfortunate potential of doing great harm to the development of serious packet networking on amateur bands in the future.
At this point, I am very hopeful that the issue of responsibility for content of forwarded traffic will be resolved in a way that will not prevent future network development... but on that Saturday in Tucson, the whole discussion was a real downer. N4PCR said something as he started his talk on the Grace PackeTen system about the degree to which this sort of conflict can be a negative motivator to those of us trying to push the edge of technology. I have to admit that my presentation (which followed his) about what was happening with COPA and what we hope to build in Colorado wasn't up to my usual standards, because I too was, well, pretty bummed. My apologies to those present, you deserved a more coherent presentation than you got from me!
The other presentation worthy of note was made by Dewayne Hendricks, WA8DZP, who is one of the folks responsible for the Macintosh version of NET, and who has been working with Mike Cheponis K3MC on an investigation of RF hardware being produced under the Part 15 Spread Spectrum rules at 900Mhz and elsewhere. Mike wasn't able to be present because of the imminent birth of his first child... a daughter! Congrats Mike, we missed you, but this time your priorities were clearly in order!
The Part 15 devices are something we as packeteers should keep our eyes on.
The class of device being shown by Dewayne in Tucson is a spread spectrum digital radio, capable of data rates on the order of 100-250kbps. The power output and antenna restrictions imposed by Part 15 rules seem restrictive at first, but some back-of-the-envelope calculations by Phil Karn KA9Q that evening implied that these radios could easily be used for many of the local and intermediate range hops that comprise the functional part of our current network. And the exciting part is that there are *no* content restrictions associated with the use of Part 15 devices, at all!
For a variety of other good reasons, I very much want to see the Amateur Radio service survive. But as someone who is an RF Network person first, and a ham second, if the environment surrounding packet radio gets too restrictive, it's nice to know that there's somewhere else we can go! Even more important, perhaps, was the realization that if the ARRL is correct in its prediction that packet radio's success or failure is going to make or break the future of the service, and if a new generation of potential ham has the option of going in the direction of a license-free, content unrestricted service that for all intents and purposes gives them what packet radio can give them...
Think about it.
I may have more to say next time, and Dewayne hinted at a paper for the CNC this year in the San Jose area surveying the field. Keep your eyes open!
COPAThere's been one board meeting of COPA since the last issue of PSR. It was held in Denver, and two important things came out of it. First, N0LEU and I have been working on drafting bylaws for the organization. Hopefully, by the time you read this they will be complete and on the way to the rest of the board for review. All this administrative stuff is a real headache, but we've got to be legal, right?
The second thing is that we have officially recognized a technical standards committee, headed by yours truly, that is working on proposals for such things as consistent parameters for our NET/ROM sites, documentation and possible changes in our frequency usage, and plans for an East-West 10Ghz backbone across the state. I am particularly in need of information about frequency usage across the state for all forms of packet radio operation. If you're reading this and have something to add, *please* let me know! We can't do this all alone...
56kb ModemsI talked last time about the love/hate relationship I have with my 56kb modems lashed up to DRSI PCPA cards (more hate than love at this point!), and made the point that the world needs a better solution for high speed I/O on PC's. I was suitably chastised by VE3JF for not thinking about the PI card developed by the Ottawa packet working group. It is a two-channel HDLC card for the PC with one port configured for half-duplex DMA using the PC's internal DMA controller, which is easily capable of driving a 56kb modem. Somehow, between not making it to the ARRL CNC in Canada last year where they were introduced, and not having seen one in person, I just plain forgot about the card.
Barry has remedied that situation since the last issue. I have now purchased one of the PI cards to play with, and on first glance it looks like it will allow me to start collecting dust on my PCPA's. At this writing, I regret that I haven't had time to really put the card through its paces. I'll plan on reporting in more detail next issue.
I'm sure that the Ottawa crowd will be at Dayton this year, if you're planning to attend, put them on your list of places to stop!
I also saw Phil Karn KA9Q wandering around in Tucson with a card similar to the PI card from some folks in California. I don't have any more information about it right now, but some is on the way. It looked like a single-port card based on a Western Digital HDLC chip. I'll try to have more to say about it next time. Suffice to say there are some better cards available for lashing WA4DSY modems to PC's than dumb cards like the PCPA these days!
10Ghz HardwareThings have been crazy enough lately that I just hadn't found time to stuff parts into the first-cut PC boards that Jon KE3Z sent out for me to test from the board shop at the ARRL lab. Two weeks ago, Don N0LEU drove over to the Basement from his home in Steamboat Springs (out in the middle of Colorado, in ski country!) to pick up the bare boards and all the parts I had lying around. He has promised to stuff the boards and try turning them on for me.
This coming weekend Karen and I will be driving to the western edge of the state, to the Packet Racket meeting in Grand Junction, CO. Don should have the initial link assembled if not tested by then, and he's planning to drag it along for me to see, and show. Don, Al WA4HND, and I have committed to putting up at least 4 sites with Grace cards and 10Ghz link hardware to begin building a new backbone for Colorado this summer.
The impact this will have on the rest of the world is that we intend to modify the design for RS-422 I/O instead of the current differential ECL, and then cut PC boards. If we are successful in getting to the PCB stage, we'll try to figure out how to make the useful pieces available. Wander by at Dayton this year if this interests you, and I'll see about making up a mailing list or something.
And if you know of a cheap source of dishes and related hardware that have any chance of surviving winters at 14000 feet for 10Ghz... *please* tell me!
Dayton 1991We tend to measure the year at the Garbee household by what was the most recent amateur radio function we attended, and which one is coming next. As I write this, the next "biggie" that is a fixture on our calendar is the Dayton Hamvention. If you haven't been to Dayton, you ought to do it at least once in your lifetime... it is, if nothing else, an experience.
The packet forum will again be held on Friday afternoon this year. I am on the agenda with Don Lemley N4PCR to talk about what's happened in high speed packet in the last year. If nothing else, I'm hoping we can pass along a list of the folks you ought to stop by and visit the rest of the weekend, as most of the folks doing interesting high speed things should be around somewhere. If you're one of the folks doing something neat, and particularly if you're going to have a booth or flea market space at Dayton, please drop me a line so I can make sure to remember you for the presentation...
The big change this year is that I will not be working in the TAPR booth. I have been invited by the Grace Communications folks to participate in their booth, lashing up some of our high speed RF hardware to their packet switches (currently the only thing available that will drive some of my toys directly, and what we're planning to base the Colorado backbone on) for what we hope will be an interesting continuous demo. The Grace guys also have some new products they plan to introduce at Dayton this year, which I think will be worth a visit. We'll be in booth spaces 570 and 571, which is an aisle away from the TAPR booth.
I *strongly* encourage everyone to stop by both the TAPR and Grace booths. There should be lots of new things to see and buy, and I'm looking forward to the opportunity to chat at length about the construction of high speed packet networks with you!
Until Next TimeI appreciate the time some of you have taken to communicate with me about the column, TAPR, and high speed packet widgets. I have to admit, however, that I'm a bit disappointed none of you have responded to my query from the last issue asking "what does it really cost" to put up and support the packet radio shared facilities in your area. This is something I am really very interested in. If you meant to, but just haven't had time to reply, *please* do so.
And if you have any suggestions for things I can/should talk about in future columns, drop me a line! I still have a couple of good suggestions in the hopper for the hypothetical issue when I've got lots of time to prepare and am not writing after the deadline... but I need more! Keep those cards and letters coming!
I can be reached as email@example.com on the Internet, as 76430,3323 on CIS, on the PBBS network as N3EUA@W0LKD, or by paper mail at 4390 Darr Circle, Black Forest, CO, 80908, USA. 73!
Bits in the Basement 1991 Q1by Bdale Garbee, N3EUA Hello again! For the first time in many issues, I don't have a big trip to report on... We've managed to stay inside Colorado for some time now. My work at HP has kept me very busy, but enough time has been spent on radio projects recently that there are many things to talk about. I've also had some interesting mail which I will report on.
COPAParticularly for those former members of RMPRA who are now members of TAPR, let me update a bit what has happened with the effort to organize a new group called the Colorado Packet Association, or COPA for short. Things are starting to fall together, albeit slowly.
On 1 December, Ed Wright W0LJF called a meeting in Castle Rock, CO. Attendance was very good, and included many PBBS sysops, node operators, our state repeater coordinator, ARRL section manager and head of the the State Amateur Radio Emergency Service (SARES), a couple TCP/IP users, and me. I dragged along enough hardware to run a 56kb demo across the room, but other than that it was a purely business meeting.
A document was circulated and approved by vote organizing COPA as an autonomous division of SARES. This gives us an organizational framework with existing permanent 501(c)3 tax exemption, and yet allows us to maintain independent control of our actions and budget. It's a neat arrangement, and we thank the SARES folks for helping us out. We think it is obvious that an improved packet network in Colorado will benefit SARES, so the association is natural.
Elections were held, with the following results: W0LJF President, N0LEU Vice President, KA7EEJ Treasurer, and N1FED (my wife Karen) Secretary. In addition, we elected representatives from each geographic quadrant of Colorado and SARES, KB0CZV for NorthWest, AI0C for NorthEast, WM0Z for SouthWest, KQ0J for SARES, and yours truly, N3EUA for SouthEast.
Two technical issues were addressed. One was the adoption of geographic quadrants NECO, SECO, NWCO, and SWCO for PBBS heirarchical address designators, and a suggestion that the Colorado Front Range packet backbone on 446.8 move to a frequency inside the band plan published since the adoption of that frequency, taking into consideration the need to interface with the Western Slope backbone. I agreed to act as the first COPA Technical Standards Committee chair, and to look into the 70cm frequency issue before the next meeting.
My apologies to those of you from outside of Colorado for whom this is no big deal... I'm apt to continue to report on the highlights of COPA activity that may have general interest, but will refrain from spending too much time on the topic from now on.
56kb ModemsIn case you skipped over the last section, I actually demo'ed 56kb operation between two machines at a meeting on 1 December. It was a milestone for me, as K0YUM, WD0FHG and I have only had modems working reliably for a couple of months. As this event indicates, a lot of attention in the Bit Basement has been focussed on 56kb operation since the last issue of PSR.
We have two modems working absolutely reliably across my basement, using DRSI PCPA cards and the 'hs' driver in KA9Q's NOS software to run them. These are both the current revision of the WA4DSY design built from GRAPES kits by N6GN and then sold to me. We also have two units WD0FHG and I assembled from the beta-test PC boards, and one set of beta-test PC boards that are partially populated. Obviously, we'd like to have 5 working modems. The two current revision units have been mounted to rack panels with power supplies and cabling, and are very portable, as demonstrated by the trip to Castle Rock for the demo, where everything plugged in, turned on, and came up in about 10 minutes, including my AT and XT clones!
We've run into some problems with the beta RF boards that we're still working on. They function adequately, but the receiver first LO won't tune to the expected amplitude despite component value tweaking. The best we can get is about 3.2V. And the amplitude at the output of the 455khz IF filter is only about half the expected value. Part of this may be that we are apparently operating the modems near the limit of the receiver frequency range. The LO circuit is not very different on the current rev PC boards, so I'm apt to hack one to current rev and see if it tunes up better. Not sure what is wrong at the 455khz filter yet. Let me emphasize again, though, that the current rev kits are working great, the problems I'm having are strictly with the older alpha-revision PC boards.
The performance with the DRSI cards is sort of hard to talk about, because at the same time it is great and absolutely horrid. Let me try to explain. The configuration I ran for some time testing the first two units we put online was a 20Mhz 286-based AT clone at one end of my basement, using a PCPA card as the only interface, running NOS. At the other end of the 56kb RF hop was my 8Mhz V20-based XT clone, with two serial ports connected to TNCs using 16550 chips on the interfaces, a TRW PC-2000 ethernet card, and the PCPA card.
After tweaking things, and clipping out the PTT hang-time capacitors in the MMT 430Mhz transverters, I was able to FTP the NOS sources from the AT over the RF hop through the XT to my HP 9000/350 workstation at the other end of the room across ethernet with a transfer rate of 6.5kbytes per second. This was using 1k packets, and a window size that allowed 4 packets in flight over the course of the 470k or so file transfer. This means I was getting about 93% of the theoretical bandwidth of a 56kb channel, in data! Including the acks, headers, and so forth. This is, obviously, pretty great.
The down side is that the PCPA card and hs driver absolutely guarantee that the PC clone is "flat-lined" for the duration of a packet transmit or receive. Nothing else happens, at all. In particular, even the 16550's overflow on the 9600 baud links to my TNCs, and the XT is absolutely useless from the keyboard when the modem is in operation. The fact that the ethernet remains functional at all is a tribute to having an ethernet interface card in the XT with non-trivial amounts of buffer and a fast interface to the main bus.
This "war story" should make it absolutely clear, if it wasn't already, that the world needs better ways of interfacing to RF channels than dumb I/O hardware in an XT or AT clone! In fact, as soon as I can afford to do so, I intend to replace the DRSI PCPA cards with something better, and sell the boards. Yes, they work fine, but only if you can tolerate the utter blitz of the machine during transfers.
One of the guys at the demo in Castle Rock asked me about reliability of the modems. The pair that I demo'd, which were built from current rev kits, came up fine the first time, and have not been tweaked since. For several weeks, they were the only link between my 20Mhz AT software development system and the other machines in my basement... I did a lot of telnet and ftp traffic across them, with no glitches or gotchas. That's not quite the same as running one for a year on top of Pike's Peak, I admit, but it definitely says something... if only my XT were as reliable!
Power SuppliesI mentioned last time that I thought the world needed a good power supply to get from 12VDC nominal to +/-5VDC at an amp or so each. Why? Well, that is what a 56kb modem needs, among other things. I measured both of my current rev board sets, and the current drains were in the neighborhood of 250ma of 5V, and about 80ma of -5V for both boards in normal operation.
Fred Peachman, KB7YW, sent me a very simple little circuit that does the trick, using a 555 timer as an oscillator to switch a pair of power transistors to provide an inversion of the 12V input. He then uses a 7805 three-terminal 5V regulator to brute-force linearly regulate 12V to 5V, and a 7905 negative regulator to cut the negative voltage down to -5V. If you would like a copy of his design, Fred says he's reachable as KB7YW @ WB8LVP. If there's enough interest maybe he'll even write this up for PSR sometime.
I have to confess, though, that I haven't duplicated Fred's circuit. There are a couple of reasons. One is that K0YUM found some supplies at a surplus shop in Denver that generate +5 and +/-12 from 120VAC, for $15 each. For the short term, this has given us what we need to get the rest of the modems working for essentially no effort and very little money (at least compared to the rest of our investments, HI!).
The other is that I managed to get myself to Westminster, CO, for a day-long seminar by Linear Technologies, and it looks really easy to do a very efficient switching supply based on the LT1171 or LT1172 100khz switcher parts. This has been a fun linear design exercise for me, since it had been several years since I designed a non-trivial analog electronic circuit. I haven't had time to prototype my design, but the only nasty piece is a toroidial transformer that I'm going to fabricate from a toroidial inductor, adding secondaries myself. It seems the more I learn about how transformers work the less I think I know!
If I ever get around to finishing this, I'll write it up and publish it somewhere. But, as I mentioned, K0YUM has solved the power problem for the moment, so on to more important problems.
10Ghz StuffLast time I mentioned that WD0FHG had finished the PC board layouts for the N6GN 10Ghz 1Mbit/sec link. Jon Bloom, KE3Z, at the ARRL lab had agreed to cut a couple of sets of boards to test out the design. Turns out he had to make some layout changes to accomidate limitations in the ARRL's current board making facility, which all made good sense. A set of the boards are in my hands now, and I'm working on populating them. There are several problems with the current board layout, and not having plated through holes is a bit of a pain, but I expect to have the boards up soon. A board set also went to N6GN, so we should know a lot more about the design soon.
Once we get a chance to build up and test some of the boards, it seems likely that Glenn N6GN or someone will make PC boards available. When I have details I'll report them here. But, it's pretty obvious to me now that there are some things that I want to work on.
The current design is half duplex. Glenn and I talked once or twice about how it might be possible to mutate the system into running full duplex. I think this would be worth investigating further, particularly since the nature of these links will be point to point. It's not like we'll have a collision problem, but there are noticable differences in performance, particularly for interactive applications, when acks can flow in parallel with data. This is more of an issue at slower data rates than at ethernet speeds, but given the availability of switch hardware that can handle full duplex megabit data rates (the Grace PackeTen), I'm going to spend some time investigating this.
Also, the design of the current circuit includes a digital interface modelled on the AUI connector on an Ethernet card (the DB-15). The levels are differential ECL, and there are separate transmit and receive pairs... but it is assumed that the interface card will do clock recovery on receive, and is self-clocking on transmit. This does not describe the interface of switch and end-user cards intended for HDLC operation, where the WA4DSY 56kb modem is a better match... the modem provides transmit clock, and extracts clock from data on receive, plus generates a carrier detect signal and reacts to a request to send, or PTT signal.
For use with cards like the Grace PackeTen, including a little additional circuitry on the FSK receiver PC board to provide an HDLC-compatible interface makes a lot of sense. Once we're at 10Mbit/sec, the AUI is probably still the right model, but since we can't easily slow down ethernet cards, the current design won't quite do 10Mbit/sec, and the existing interfaces at lower data rates are all optimized for HDLC... I'm thinking about working up the changes to do direct HDLC interface at RS-422 levels. More next time.
NOSThe letters that have shown up in my mailboxes the last few months have included a fair number of requests for more information in the column on what "NOS" is, what it is good for, and how to get it. That's a subject that could become an article unto itself. I'll try to hit a few high points here, and if there's continuing interest, I'll work harder for next time. Let me know what you want to hear!
To start with, I think it makes sense to take a short walk through amateur TCP/IP history, particularly for those of you who have never heard Phil KA9Q talk at a TAPR or other packet meeting.
A long time ago in a galaxy far away, called Pennsylvania, I met Phil Karn at the first meeting of MAPRC, the Mid-Atlantic Packet Radio Council. During the meeting, it snowed, so the three of us from Pittsburgh (Mike, K3MC, Bob N3CVL, and I) split a pair of hotel rooms with Phil, and we sat up most of the night talking protocols and what we thought the amateur packet world needed. By morning, we had all agreed to work together to develop TCP/IP based software for packet radio. Phil already had the core routines up and running on a Xerox 820. Mike went off to investigate TFTP and FTP, I went off to investigate SMTP, and Bob planned to look at ports to other hardware including some PDP/11 systems he had access to. The key is that all of us were motivated by having experienced the Internet protocols at work or at school, we shared a common vision of what it might be like to have a flexible, dependable platform for application development, and all of us were committed to making otherwise outrageously expensive protocol functionality available to the amateur community for free.
We dragged a bunch of other folks into the project fairly quickly, and after a couple of false starts, got a "tcp-group" electronic mailing list going. A lot of hours and a lot of lines of code later, Andy Freeborn N0CCZ and I had the first TCP connect using KISS TNC's between our houses in Colorado Springs. Others had run TCP over packet radio before, but this was a milestone in that it was the first time of record that the KA9Q software was used with a KISS TNC successfully... still the most common mode of operation for TCP packet stations today.
At that time, the software included Telnet, FTP, and SMTP... and not much else. For a long time, functionality was added by a variety of folks to this original version of the "NET" software. Eventually, the limitations of the internal structure of NET became overwhelming. But by the time they did, a lot of neat stuff had been added. AX.25 connections, a mini-PBBS sort of mailbox, drivers for a variety of interface cards, and ports to a variety of computers and operating systems. The last big hurrah for the pre-NOS version of NET was the "Dayton release", 890421.1. Some have continued to build new functionality around this version, including most notably KD8WK and PE1CHL. But for many of us, "pre-NOS" as it has come to be called, is history.
NOS is a "New Operating System" version of NET, the result of a complete rewrite of the internals of the package by Phil, KA9Q. The rewrite placed a multi-tasking kernel at the core of the package, and restructured the interface between protocol and application code to use the Berkeley Sockets Interface, a defacto standard in the networking world. The primary goal was to make it easier for others to use NOS as the basis for new applications. In this regard, NOS has already been a great success!
Anders Klemets has rewritten the "mailbox" code to be an almost complete W0RLI-style PBBS, all as part of the NOS package. This code is interesting to me mostly because it is being perceived by many as an alternative to something like MSYS, except that this is a primarily TCP solution with AX.25 BBS, instead of a primarily AX.25 BBS with TCP. K3MC and I have wasted many a late-night ice-cream and coffee session talking about this, I'm glad Anders took the time to make it reality. I will confess, however, that I haven't waded through the setup information, and so am not taking advantage of this functionality yet in the Bit Basement.
Considerable work has been done on NNTP by several people. NNTP is the Network News Transport Protocol, and is the standard way Usenet hosts on the Internet exchange News articles, and the way many News readers access a News database. I've talked at length in prior columns about News and the potential it has as an application to get more folks actively involved in packet radio. NNTP is at the moment the preferred way to actually implement the transport layer, as differentiated from the technique used by the Terakoya system by JK1LOT and friends, which involves sending articles as mail messages. If nothing else, NNTP is a "pull" system, where the downstream receiver requests only what he wants, which potentially is more efficient than the upstream sender sending what is wanted and then some. As I write this, I've got NNTP up and running on winfree, and have a copy of NOS with NNTP support that I'm playing with at night. More next time.
Another area that has been receiving a lot of effort is the RSPF routing protocol I mentioned in the last issue of PSR. In a nutshell, my interpretation of the results of the effort to date is that any kind of automated routing protocol is a pain when it is used on 1200-baud, collision-prone channels. Progress is being made, and I'm a strong believer in the future of RSPF. I haven't played with the protocol yet, but am looking forward to doing so soon.
The biggest problems with NOS right now are that a) it is still in a state of constant and rapid flux, and b) documentation of the quality needed for new users (or even of the quality of my hack for the pre-NOS version) does not exist. Phil has written a command reference. NQ0I has worked on docs for the "mailbox". There has been a lot of talk on the mailing list about getting an organized effort going. But for now, caveat emptor!
If you want to try it out, many of the BBS systems that carried NET now have beta-release snapshots of NOS available. This includes the N8EMR and WB3FFV BBS systems, and probably others. The current bits are always available for anonymous FTP on the Internet from thumper.bellcore.com.
Winfree / Unix PacketI mentioned in the last issue that I had migrated my Unix machine 'winfree' from an HP 9000/550 to an HP 9000/330. Thanks to the generosity of a TAPR member and reader of this column, winfee is now a 9000/350. Unfortunately, other than the upgrade, and adding some more disk space, I've had precious little time to work on services for the local community. I've got news installed and stable, am almost ready to unveil NNTP service, am running a .ampr.org nameserver, and will soon have the latest callsign database snapshot online... but who knows when I'll get time to finish these, or do more.
The rumor mill reports that there may be a ham from the Denver area at Dayton this coming April selling off as many as several thousand ATT 3B Unix machines at a fraction of their original cost. These aren't the most wonderful machines in the world, but running KA9Q networking software, they have the potential to be neat service-providing platforms, particularly when coupled with a good switch board like the Grace PackeTen to "fan out" the internal serial port to one or more RF channels. You'll hear more as I know more.
NOSINABOXThings have been really weird on the NOSINABOX front since the last issue of PSR.
I've had a port of NOS running, but with lockup problems, on the Kantronics Data Engine since before Dayton this year. I've had a port of NOS in progress on the PS-186 since sometime in July. But, I haven't worked on either one very much since then. There are two interlocking reasons. One is that I have run into some annoying technical problems with the port, and two is that I've lacked the motivation to overcome the hurdles and finish the work.
In the fall, I contacted AEA and Kantronics by FAX, and asked both vendors for production hardware to complete the ports with. Kantronics responded immediately by sending me the requested hardware, and reiterating their willingness to help in any way possible. I can't say enough good things about how easy it has been for me to work with and on the Data Engine, mostly because of the support from Phil Anderson, Mike Huslig, and the rest of the gang in Lawrence.
Mike Lamb of AEA responded quickly also, with a FAX indicating that production hardware would be available soon. I haven't heard anything since. I know not what conclusions to draw.
The lack of outwardly visible activity on the PS-186 from AEA leaves me unwilling to further pursue code for that platform. I am not sure that the Data Engine makes much sense running NOS except in a limited number of applications because of the relatively few ports it provides, and the fact that for high speed modems, use as a TNC or "home switch" is not optimal because of the limited speed of the serial port to the computer. A port of the G8BPQ NET/ROM-compatible switch code for the Data Engine exists now and seems to work. Since NOS supports IP over NET/ROM, this is not an unreasonable approach to take if you want to run Data Engines on your network.
My interest has been shifting away from the grungy details of making code work on diverse hardware and towards things like routing, network management and security, and neat new link hardware.
What does all this mean? Well, for one thing, if you want a packet switch based on NOSINABOX, buy a PackeTen card from Grace. It's a neat board. Don Lemley, N4PCR, has done a great job independantly porting NOS to the standalone environment. As discussed in two papers in the ARRL conference proceedings this year, the PackeTen card is based on the Motorola 68302 communications processor... which turns out to have some hardware features that dovetail nicely into the requirments of NOS. And the cost is not unreasonable for the performance received and the development and support effort it represents. K0YUM, WD0FHG, and I are buying some of the standalone boards to use in our emerging network in Colorado.
What Does It Cost?There is a question I've been wrestling with for several months, as I try to understand what may be possible for COPA, and as I talk about fast packet switching hardware with other hams. What is the actual cost of installing and maintaining a packet facility?
If you have recently or are now in the process of installing a packet facility that will be shared by multiple users, in particular things like digipeaters, single or multi-port NET/ROM sites, a PBBS, a DX cluster, or whatever... I would like to ask you to take a few minutes to write down what it cost.
What would be ideal is an explaination of what kind of facility this is, how many people it serves, what it cost to install including a line-item breakdown of what the pieces cost to whatever level of detail you can do easily (include antennas, feedline, any site costs, digital hardware, RF hardware, software or firmware, etc), and what you know or estimate it is going to cost to maintain (repair from acts of nature, frequency of vandalism, rent for the site, electric or phone bills you have to pay, whatever comes to mind).
Send your responses to me via any of the methods detailed at the end of this column. If I get enough responses, I'll summarize the information next time in PSR, and comment on any particularly interesting tidbits. I went through this process a while back in the packet section of Compuserve, and it was kind of fun to see what other folks were working on.
CompuserveMentioning "Compuslave" reminds me that I wanted to mention that I've effectively left the HAMNET forum on CIS. The time required, and the cost involved in keeping up with the general content of the packet and satellite sections led me to stop participating. I am still involved in the TAPR board of director section of HAMNET, and am still checking in to read EASYPLEX once a week or so. Therefore, you can continue to use the CIS address to send mail to me, but do it with EASYPLEX or using the Internet gateway to get to my 'firstname.lastname@example.org' address instead of putting the message in S9 of HAMNET, since I just won't see it there.
Until Next TimeI hope you've enjoyed my ramblings this time around, and that you had a healthy and happy holiday season. I spent most of mine recovering from strep throat and a sinus infection, but my brother Cabell (who graduated as a Civil Engineer from NC State University in December, way to go bro!) came out on Christmas day and stayed through the first. We had a great time, and other than not feeling great at the end, 1990 was a good year here in the woods.
I look forward to seeing you at the TAPR meeting in early March, and at Dayton in April. In the meantime, keep those cards and letters coming!
I can be reached as email@example.com on the Internet, as 76430,3323 on CIS, or by paper mail at 4390 Darr Circle, Black Forest, CO, 80908, USA. 73!
Using the Kantronics DE-1200 for Full-Duplex Repeater Operationby Bdale Garbee, N3EUA Postcript Schematic of Additions to DE-1200 Several articles have appeared in the past on building full duplex, bit regenerative repeaters for packet radio use. Those that I have studied all involved modifications to TAPR standard TNC-2 designs. Because we intend to use a Gracilis PackeTen switch at our voice and data repeater site here in Colorado Springs, and because the Gracilis switch makes use of the Kantronics modem daughter cards, I was motivated to develop a suitable modification to the Kantronics 1200-baud modem, the DE-1200. This modification should work in either the Gracilis PackeTen switch, or in a Kantronics Data Engine.
There are pros and cons to performing the repeater function at the RF level, at the analog level, or at the digital level. For a variety of reasons, not the least of which being a desire to have the repeater be a source of "reference tones" and deviation for users to calibrate against, I chose to perform the repeater function at the digital level, which turns out to be easy to do on the DE-1200. I suggest you have a copy of the schematic for the DE-1200 in hand, along with the attached schematic of new circuitry when making the changes.
There's only one component needed for the modification, a 74HCT157 mux chip. This chip is basically a 4PDT switch with TTL inputs and outputs. I suspect that any variant of a 74157 would work fine here, I happened to have this CMOS variant in hand because it's used in the Gracilis processor board. Depending on the requirements of your transmitter's PTT circuit, you may also want a VN10KM or equivalent FET to replace the 2N2222 transistor used in the PTT circuit. I pulled one from a dead TNC-2 board.
I started by piggy-backing the 74HCT157 on the 74HC153 already on the board at U7. To do this, I bent all of the pins on the 74HCT157 except pins 8 and 6 180 degrees, so the pointed up in the air. I then tack soldered pins 8 and 16 to pins 8 and 16 of the 74HC153, to get power and ground connections. Next, I cut two traces on the bottom side of the modem board. One is the RTS line, the other is the transmit data line. The RTS line is easiest to cut adjacent to pin 4 of U2, which is a 74HC04. The transmit data line is easiest to cut between pin 3 of connector INT1 and one end of R5.
With the IC on the board, and the traces cut, there are 8 wires to add. I used 30-gauge wire-wrap wire, stripping a small bit of insulation on ends that I tack-soldered to existing holes in the board, and using a hand-held wire-wrap tool to wrap bare wire on the now-vertical pins of the 74HCT157. Since the pins of the IC are not guaranteed to make gas-tight connections with the wire-wrap wire, I soldered the pins after wrapping them.
The wires are all documented on the attached schematic. Pin 1 of the '157 goes to pin 7 of the connector INT1. Pin 2 of the '157 goes to pin 3 of the connector INT1. Pin 3 of the '157 goes to pin 4 of connector INT1. Pin 4 of the '157 goes to the end of R5 that was once hooked to pin 3 of connector INT1, and is still connected to pin 14 of U6 (the 3105 modem chip). Pin 5 of the '157 goes to pin 16 of the '157 (5V). Pin 6 of the '157 goes to U2 pin 5. Pin 7 of the '157 goes to the C33 side of the trace cut made next to U2 pin 4.
If the 2N2222 transistor used by Kantronics doesn't pull the PTT line to ground hard enough to key your repeater's transmitter (a common problem with older commercial rig-based repeaters), pull it out and stick in a VN10KM FET in the same holes. The transistor in question is Q3. And while you're at it, Q4 adds absolutely no value in repeater operation, so I pulled it out. It's a 2N7000 FET between the transmit audio line and ground, I suppose intended to squelch the transmit audio during receive.
If your repeater uses a relay to switch the transmitter on and off, I cannot suggest strongly enough that you replace it with a FET circuit. The Maggiore repeater I've been working with used a relay to switch 12VDC into one pin on the exciter. After about a day of pinging every 5 seconds, the relay welded itself in the "on" position. If it isn't obvious how to do this, find a friendly local "transistor jock" to give you a hand. It's well worth the effort. Relays are evil!
That's all there is to it. This circuit, as designed, gives precendece to the packet switch at the repeater site, by switching the mode of operation from repeater to transceiver using the RTS line from the switch. When the switch wants to transmit, it can. When the switch isn't transmitting, anything heard by the receiver will be sent out the transmitter as well. Since the switch has the port connected to the repeater configured for half duplex, it won't transmit when a valid packet is being received, so this works out great.
I hope this modification is useful to others, the Gracilis switch with Kantronics modems is an easy and powerful way to build a multi-port digital site. With this modification, attaching a digital repeater is easy. A similar modification can be made to the DE-9600 modem, I'll write that up too if there is sufficient interest.
Forward any comments or suggestions to me at firstname.lastname@example.org on the Internet, or look me up in a current callbook...
Motorola Mitrek Radio Modifications for 9600 Baud Serviceby Bdale Garbee, N3EUA The Motorola Mitrek radios are readily available through commercial radio surplus channels, and provide a very reasonable platform for building robust 9600 baud packet links.
Various groups have published modification instructions for the Mitrek series, however the modifications we found all involved sufficiently significant changes to the transceiver circuitry that the normal, analog tuneup procedures were invalidated. Since we are also using Mitrek radios for our VHF and UHF voice repeater RF decks, we were highly motivated to come up with a set of mods for 9600 baud packet that preserved a single tuneup procedure. We believe that the point of diminishing returns for tweaking the radio's IF path is low, therefore these mods are simple but effective.
These modifications were developed by Derek Toeppen, WA0ZTI, with inputs from Bdale Garbee N3EUA, and John Conner, WD0FHG. The work was done on behalf of the Pikes Peak FM Association.
The following instructions assume that you have a Mitrek in front of you, and that you have a Mitrek manual to refer to for component placement, etc. Our local Motorola field service office had no trouble obtaining reprints of the manual for us at a reasonable price. All mods have been thoroughly tested with UHF Mitrek radios of the 30W and 50W variety, they should work on VHF radios as well, but we haven't tried it.
Modifications for Simplex 9600 Baud OperationTo feed the modulation signal directly into the TX channel element, we chose a method that does not require any modification of the PCB traces.
- Remove R501.
- Remove C502, C503, and C504.
- Remove R513, and R515.
- Jumper MIC HI Audio to Channel element pin 4. This may easily be done by jumpering the through hole vacated by the end of R501 which formerly connected to C502, et al, to the through hole vacated by R515 which formerly connected to R513.
No receiver modifications are required. Just make sure the channel elements are enabled. For a single frequency radio, just add jumper JU611 to hard enable F1.
Receiver audio is taken from the DET pin on front panel connector pin 11.
We make no modifications to the RF input/output, just let the existing TX/RX relay do it's thing, and use the front-panel UHF connector for your antenna connection.
Modifications for Repeater OperationWe have built one digital repeater using a 30W UHF Mitrek chassis. We have built several audio repeaters with both VHF and UHF Mitrek chassis with both 30W and 50W chassis. The following mods are for repeater operation, and are based on the 1200 baud packet repeater we built. If you want a 9600 baud packet repeater, combine the above mods with the following mods. If you want either a 1200 baud packet repeater, or an audio repeater, the following will be sufficient.
On the TX side, we remove R501, which prevents 9.5 volts from appearing on the mic input. The modulation signal can then be fed in to the MIC HI pin (pin 1) of the front panel control head connector. Remember that the pre-emphasis and gain of the audio path depends on the source impedance of the circuit driving it. This impedance should be about 360 ohms.
On the RX side, the project is a bit more ambitious:
- Remove CR1. This keeps RX on when PTT is low (TX is on).
- Remove CR403. This prevents audio muting when the TX is on.
- Install JU611. This hard selects channel element #1 for both TX and RX.
- Remove CR604 and CR608. Install a jumper between node E (collector of Q406) and the cathode through hole of CR608. This makes a carrier detect signal available on the channel element #4 select line.
- Remove CR404. This prevents the muting of receiver audio when no carrier is present.
To complete the project, we need to modify the RF cabling. Note that the TX cable is short, don't waste any length when making these modifications!
- Cut the RX and TX coax as close to the TX/RX relay as possible.
- Remove the TX/RX relay.
- Add SMA connectors to the TX and RX coax.
The radio can be tuned using standard Mitrek procedures. Nothing in these modifications alters those procedures.