<div>One of the neat things I did with mic-e was to wire a 1k resistor in the COR line from the repeater receiver to the repeater controller. Then I could use the CD light on the TNC to pull the COR down (softly). Since most repeaters use a kerchunk filter, they won't come on air if they are hit with a COR burst less than 1/2 a second. The beauty of the pulling down the COR line was that the repeater controller believed it had been kerchunked and never came on air - it had just seen 10 to 12 ms of signal before the TNC CD LED came on, and yanked COR away. You could sent packet after packet over the input frequency of the repeater and no one would have been the wiser. Of course if the sending stations were configured correctly, they sensed the activity on the output of the repeater and would not key over the voice users who had caused the repeater to come on air. The use of the "soft" pulldown via a 1k resistor instead of a relay meant no chance for a failed relay to stick and render the repeater permanently deaf. On the cat1000 controllers, I used a rs232 breakout PCB from radio shack to "splice in" the 1k resistor. This was done in Jacksonville on the 146.76, in Roanoke VA (thanks ke4nyv) and in Sumter SC on the 145.43. </div>
<div> </div>
<div>Another perk to the pulling down COR method was that when you actually sent a mic-e burst at the end of your tx, the COR dropped out 300ms before you actually stopped transmitting. The result was again transparent to the end users. The courtesy beep still came out 1/2 a second after you stopped _talking_ (even though the packet silently took up 300ms of that 1/2 second.) </div>
<div> </div>
<div>Other methods I've seen used a relay in line with the COR or the RX audio. Other methods tried to blank or reduce the audio output of the repeater into the exciter. COR just seemed to be the best way. You typically hear as much of a packet brrrrrrap as you do with a DTMF before it is muted. Even better if you have one of those fancy audio delay boards - you won't hear a peep of packet on the repeater output using COR as a mute.</div>
<div> </div>
<div>Wes<br><br></div>
<div class="gmail_quote">On Mon, Jul 7, 2008 at 9:09 PM, Rich Garcia <<a href="mailto:k4gpsc@gmail.com">k4gpsc@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Yes.. good way of explaining it.<br><br>BUT as I learned early on when I first tried D-Star that every time your<br>
radio does key up to send the position report over the gateway other users<br>will know in a way. Their radio will act just as if someone has "kerchunked"<br>the repeater, you may not hear the "brapp" of a packet but you will know<br>
someone is out there. Yes you can set up the radio to only send out the GPS<br>data while you are speaking but how about the users that have little or no<br>activity on their one and only repeater? If no one is out there to talk to<br>
then you need to remember to key up for a few moments every time you want<br>the position report to go out.<br><br>The origninal "design" of Mic-E was actually a bit better. If built<br>correctly the MIC-E enabled repeater would re-transmit the packet onto the<br>
APRS channel or directly to the internet but voice users on the repeater<br>would be unaware/unbothered. Now the APRS user would also need to be sure<br>that their setup was properly configured to inhibit transmissions during a<br>
voice conversation but hey it was an idea that needed some technical work<br>just like every new idea that comes to our hobby. I think some regions of<br>the country did get some good working systems going but it never took off,<br>
so what there are a lot of places in the country that APRS has not taken off<br>either.<br><br>I tried DV for a little bit of time but decided to sell the radio, it was<br>not my cup of tea. It was a mix of this based on lack of activity, poor<br>
coverage if at all in my area, a single DV repeater but above all when I saw<br>the way APRS worked over DV and my primary interest is APRS, that was the<br>final deciding factor.<br>
<div>
<div></div>
<div class="Wj3C7c"><br><br><br>-----Original Message-----<br>From: <a href="mailto:aprssig-bounces@lists.tapr.org">aprssig-bounces@lists.tapr.org</a><br>[mailto:<a href="mailto:aprssig-bounces@lists.tapr.org">aprssig-bounces@lists.tapr.org</a>]On Behalf Of Pete Loveall AE5PL<br>
Lists<br>Sent: Monday, July 07, 2008 1:34 PM<br>To: TAPR APRS Mailing List<br>Subject: [aprssig] D-PRS> D-STAR and APRS Explained<br><br><br>Since there appears to be a prevelant misunderstanding of the D-STAR DV<br>(digital voice) protocol and how D-PRS works with it, I thought I would take<br>
a different approach and relate it to something that was originally designed<br>by Bob back in the '90s. That "something" is Mic-E. Not the APRS packet<br>format for Mic-E but how Mic-E was originally presented to work.<br>
<br>The basic concept of Mic-E was to have a single position packet appended to<br>the end of every voice transmission by use of a standard 1200 bps TNC (with<br>special circuitry, etc., of course). If the person was using a voice<br>
repeater with a TNC tied to the repeater receiver, the TNC would see the<br>position packet and retransmit it on a data frequency or, in later times,<br>gate it to APRS-IS. The repeater controller would block the tones from<br>
being retransmitted so other hams on the repeater frequency wouldn't hear<br>the blap of the AX.25 packet.<br><br>This is a one-way use of APRS where the mobile station is tracker, nothing<br>more. This is exactly how the Icom D-STAR radios in GPS or GPS-A mode make<br>
use of the digital voice transmission with one big enhancement: instead of<br>appending a single packet to the end of the voice transmission which is<br>subject to being dropped due to bit errors, the Icom radios continuously<br>
send the position information while the person is transmitting helping to<br>ensure at least one position will get through. This GPS information is<br>carried with the other control information sharing the voice transmission<br>
but separately encapsulated so the user never sees the other control<br>information. The other control information which is carried separately is<br>information like callsigns, preprogrammed message, etc.<br><br>Why wasn't it ever the intent to make Mic-E operation bidirectional (again,<br>
talking about Mic-E functional operation, not the Mic-E format APRS packet)?<br>Because it would interfere with voice communications on that frequency.<br>That is the same reason that the "extra bits" accompanying the D-STAR<br>
digital voice transmission do not transform it into a "data" or "APRS<br>information" channel. Could Mic-E be bidirectional? Yes, if the repeater<br>doesn't block the modem tones. Does it make sense to do? No, because<br>
everyone would leave that frequency for one that they can talk on. Same<br>goes for D-STAR digital voice repeaters and D-PRS.<br><br>Hopefully this will help those who are failing to comprehend the difference<br>between the serial data information exposed by the Icom D-STAR digital voice<br>
radios and data protocols like AX.25. And hopefully it will help those who<br>read the D-PRS information to understand some of the background information<br>contained in those documents.<br><br>73,<br><br>Pete Loveall AE5PL<br>
pete at ae5pl dot net<br><br><br><br><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
<br><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a><br><a href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Wes<br>---<br>Where there's silence, there is no Hope.