[chirp_users] Tone Settings TX, RX (TSQL & DCL) discussion

Tue Jul 22 13:47:46 PDT 2014

Whit,
This is explained in the Guide mentioned previously under Tone Mode.
http://kc9hi.dyndns.org/uv5r/programming/CHIRP%20Guide.pdf
A description of each field and its options can be found there.

An entry in the ToneSql field is not required.
If the Tone Mode selection is (none), the Tone and ToneSql fields are ignored.
The 88.5 is a filler default.

I hope this helps . . .

John K3NXU
http://www.miklor.com

-----Original Message-----
From: chirp_users-bounces at intrepid.danplanet.com [mailto:chirp_users-bounces at intrepid.danplanet.com] On Behalf Of Dr. Whit Woodard
Sent: Tuesday, July 22, 2014 1:48 PM
To: Discussion of CHIRP
Subject: Re: [chirp_users] Tone Settings TX, RX (TSQL & DCL) discussion

Bill,
Thanks, that is very helpful.  The question that comes to my mind is why then does chirp require us to put some value in the ToneSql
column on every memory channel?  I 
have just put in the lowest tone, because the software does not allow me to leave it blank.  It would be very helpful if we had the
option of leaving unnecessary columns 
blank.  We can only do that with a couple of the entries.  I would just amend the template to eliminate those columns, but I do not
know which are necessary and which are not.  I hope in time I will gain a better understanding of the template which apparently is
restricted by both the hardware and the chirp software.  Your arrangement for communication just with your family is a great idea.
I would like to do something very similar.  Do you employ that on a repeater so that you can obtain better coverage? or must you
just set it up on simplex?

73
Whit
k3wb

On Jul 22, 2014, at 10:29 AM, Bill Kasper <williamkasper at frontiernet.net> wrote:

> Hi Forrest et al,
> 
> The TX tone (CTCSS DCL and other names) may be required for the ham 
> repeaters that use it. Modern radios' menus may set the tone 
> independently for each channel or for the entire rig. This tells the 
> repeater that "I really want to talk thru you" and I'm not some 
> skip-signal coming from a different part of the country.
> 
> Historically (a hundred years ago?) commercial repeaters had several 
> to many business users on them, as they were expensive and each 
> business that used, ie. paid for the repeater service, had a different 
> tone to open only that businesses own radios: a taxi had one tone, the 
> road-repair company another tone, and the delivery company another 
> tone and so on. They had to share the resource (the repeater) and not 
> interfere with each other any more than necessary. CTCSS is the modern 
> technical name of that tone process that used to be called PL - 
> Private Line (Motorola), CG - Channel Guard, General Electric, and 
> privacy codes for various FRS radios, plus other names.
> 
> It is the tone ENGAGED on the RECEIVER end that can be
> problematic: the exact tone MUST be present on the transmitted signal 
> for the receiver squelch (TSQL) to open so you can hear the other 
> station on that frequency; which may or may not be what you want.
> 
> As an example, I setup a simplex ham voice channel for myself and XYL 
> to use as a 'Private Line'
> (Motorola trademark) only for us: car-house, car-car etc. This is fine 
> for us, and I have TSQL set on both radios for this channel. On this 
> 'unused' simplex channel she can only hear me and I can only hear her.
> If someone else hears us, which they could, and then tries to answer 
> me, I would not hear them unless they figured out and then transmitted 
> our 'PL' tone.
> 
> As an aside, this feature, as implemented on the FRS private channel 
> radios, means that you can only hear people transmitting your private 
> code on your channel; people with no (RX) tone set can hear you too, 
> so not really very private, but helps reduce chatter from other users 
> when listening on a shared resource/channel.
> The implication is that, if you use your FRS channel 1, by convention, 
> as an emergency receiver, make sure the privacy codes are turned off, 
> so you will be able to hear everyone on channel 1, even if they have a 
> privacy tone enabled.
> 
> other comments?
> 
> 73 de Bill WB2SXY
> 
> --
> 
> On 7/22/2014 12:26 PM, Forrest wrote:
>> Curious why you say that using tone squelch on both TX and RX is not recommended???
>> 
>> THX.
>> Forrest
>> 
>> On Jul 21, 2014, at 6:51 PM, John LaMartina<JohnLa at usa.net>  wrote:
>> 
>>> Yes, TSQL sets the CTCSS or DCS tone on both TX and RX. (Not Recommended).
>>> Tone sets CTCSS or DCS on TX only.
>>> This explains in a bit more detail. 
>>> http://www.miklor.com/COM/UV_CTCSS.php
>>> I hope this helps...
>>> 
>>> John K3NXU
>>> http://www.miklor.com
>>> 
>>> 
>>> -----Original Message-----
>>> From: chirp_users-bounces at intrepid.danplanet.com 
>>> [mailto:chirp_users-bounces at intrepid.danplanet.com] On Behalf Of 
>>> Dave Nathanson
>>> Sent: Monday, July 21, 2014 7:22 PM
>>> To: Discussion of CHIRP
>>> Subject: Re: [chirp_users] Settings
>>> 
>>> Someone else will hopefully correct me if I'm wrong, (and I didn't 
>>> look this up) but I believe that in this usage, "Tone" applies when transmitting only.
>>> TSQL, or Tone Squelch applies to both transmitting&  receiving.
>>> 
>>> "Tone" is more common.
>>> If you use TSQL when you should have used Tone, others will be able 
>>> to hear you, but you will only be able to hear them if they also use the same tone.
>>> To complicate things slightly, many repeaters require a tone to 
>>> activate them, but many repeaters strip out the tone as the re-transmit.
>>> It is often a good idea to start with "tone" and only use TSQL if needed.
>>> 
>>> Best,
>>> Dave Nathanson
>>> KG6ZJO
>>> 
> 
> _______________________________________________
> chirp_users mailing list
> chirp_users at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_users

_______________________________________________
chirp_users mailing list
chirp_users at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_users

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7900 - Release Date: 07/22/14