<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>From: Mark Phillips <<a href="mailto:g7ltt@g7ltt.com">g7ltt@g7ltt.com</a>><br>To: Discussion of D-RATS <<a href="mailto:drats_users@intrepid.danplanet.com">drats_users@intrepid.danplanet.com</a>><br>
Date: Tue, 01 Mar 2011 15:57:41 -0500<br>Subject: Re: [drats_users] D-RATS support in the ircDDB Gateway<br>IMHO, those asking for D-RATS "support" in pcrepeatercontroller demonstrate a clear misunderstanding of how it works - both D-STAR and D-RATS.<br>
<br>
D-RATS with DVAR requires only that (usually) local user pass his DRATS data to the slow data socket in DVAR. DVAR then forces that data out over it's radio port. Network connections were not allowed by KB9KHM for whatever his reasons were. I do however see a requirement for slow data via D-RATS to be forwarded to whatever stations are connected to the repeater but that would happen via the RF inputs and so should have the relevant D-STAR addressing already.<br>
<br></blockquote><div><br></div><div>I agree. I believe KB9KHM's "no over the network" specifically to reflectors is good design and policy. When you automatically relay the traffic to a reflector you are sending traffic to untold numbers of gateways and stations, many of whom may not desire "non-audio" traffic, especially with a lot of end of transmission "beeps" ... One could take the approach of having designated reflectors for such traffic, which would be pretty acceptable I think. However, we have the Ratflector system and if the gateway can identify D-RATS traffic it could route it both to RF (with the proper UR addressing) and to Ratflectors. Generally relaying everything that's on the Ratflector to RF might be a bit much, but the gateway operator should have that option.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Jonathan; take a read of this <a href="http://www.d-rats.com/documentation/4-howtos/32-using-your-hotspot-for-d-rats/" target="_blank">http://www.d-rats.com/documentation/4-howtos/32-using-your-hotspot-for-d-rats/</a> (written by some English bloke who thinks his $h1t doesn't stink) to get an idea of the current RF functionality.<br>
<br>
Dan & Jonathan; can we come up with some way of dumping the voice content and filling it with data? Surely this is just payload? Agreed, a listener will not be able to decode the data without your combined softwares but at least we'll be able to get out of the not quite 1200bd packet arena.<br>
<br></blockquote><div><br></div><div>Well, I don't think you can get the Icom radios into this mode. However, if some bloke would make a GMSK modem and the gateway software was adapted to recognize DD packets at 4800 bps (hint it's a single bit flag in the header) then you could use native D-STAR encapsulated ethernet packets within D-RATS. :) :) :) And be compatible with the 128 Kbps DD and other data rates as well. (Fred says that the Icom radios in DV mode don't seem to mind "other" DD traffic on the channel.)</div>
<div><br></div><div>D-RATS for DD would be a nice addition with data rates from 4.8 - 128 Kbps (and beyond).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Keep it up fellas!!<br>
<br>
Mark<br></blockquote><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div><font face="'arial black', sans-serif" size="4">John D. Hays</font></div><div style="text-align: right; ">
<a href="http://k7ve.org/blog" target="_blank">K7VE Blog</a> / SIP: <a>john@hays.org</a><br></div><div style="text-align: right; ">PO Box 1223, Edmonds, WA 98020-1223</div><div><br></div>