[chirp_users] Thoughts after looking at the most recent build
Dan,
I'm testing Chirp with UV-3R files.
1. Why did you delete the Name field? I would find this very helpful for organizing and editing the data in my .CVS file. From our previous email conversation, I understood you were going to retain it in the CSV file and only drop it when writing data to the dual_band.dat file for uploading into the radio?
2. Vero/Baofeng uses one "menu" for manually setting the Tx-Code (transmitted CTSS or DTCCS code) and a second "menu" for manually setting the Rx-Code (received or SQL tone code, either CTSS or DTCCS).
Chirp has separate fields for the CTSS (Tone) and the DTCCS (DTCS Code) (defaulting to the lowest code value for whichever code type is not used). In addition, Chirp has a field Tone Mode with values of None, Tone (CTSS Tx only), ToneSql (CTSS Ts & Rx?), and DTCS.
The "inputs" suggest that a repeater using CTSS will always have to hear a user's Tx-Code and it may or may not send back using a CTSS code. On the other hand, if the repeater is using DTCCS, then, it will require that code (my Tx-code) and it will always broadcast using that same DTCCS code (my Rx-code).
Some questions to help increase my knowledge of current practices:
1. Is the above analysis correct? 2. Is this juxtaposition of data and information types done as a convenience in light of the requirements of earlier radios that Chirp was programmed for? Or, it it something that can be altered? 2. Is a repeater operator precluded from selecting different CTSS or DTCCS codes for Rx and Tx?** 3. Is a repeater operator precluded from selecting CTSS for the user's Tx Code and DTCCS for the user's Rx Code (or vice versa)?** 3. Can an operator set a repeater up to use DTCCS on what it receives (the user's Tx Code) and transmit without a code?** ** (Assuming the operator's choices do not conflict with any other repeaters sharing the frequency pair within a reasonable distance of the subject repeater.)
I don't see where the UV-3R uses the DTCS Polarity information at all; it does not appear to be an option as I read my .dat file.
Thanks & 73 de KK4DBR, Ron EL98fk Orange Cty Windermere, FL
- Why did you delete the Name field? I would find this very helpful for
organizing and editing the data in my .CVS file. From our previous email conversation, I understood you were going to retain it in the CSV file and only drop it when writing data to the dual_band.dat file for uploading into the radio?
The UV-3R doesn't support names, so that column shouldn't be displayed when editing such a file. It's still supported in CSV, of course.
- Vero/Baofeng uses one "menu" for manually setting the Tx-Code
(transmitted CTSS or DTCCS code) and a second "menu" for manually setting the Rx-Code (received or SQL tone code, either CTSS or DTCCS).
Yes, but almost all ham radios only support one code (for TX and RX) at a time. CHIRP was designed with this in mind and thus adding support for a split code is non-trivial.
- Is a repeater operator precluded from selecting different CTSS or
DTCCS codes for Rx and Tx?
Yes, at the moment.
- Is a repeater operator precluded from selecting CTSS for the user's
Tx Code and DTCCS for the user's Rx Code (or vice versa)?
At the moment, yes. Some of the Ham radios support a "cross mode" that lets them use CT and DT for RX and TX (or vice versa). I can see about enabling the UV-3R driver for that if it's important to you.
- Can an operator set a repeater up to use DTCCS on what it receives
(the user's Tx Code) and transmit without a code?
No.
I don't see where the UV-3R uses the DTCS Polarity information at all; it does not appear to be an option as I read my .dat file.
Yes, it can. When you're entering a DTCS code on the front panel, press the menu button and it will change from N (normal) to I (inverted).
On 8/9/2011 9:45 AM, Dan Smith wrote:
On 8/9/2011 12:49 AM, Ron McKenzie wrote:
[...] Some questions to help increase my knowledge of current practices: [...] 2. Is a repeater operator precluded from selecting different CTSS or DTCCS codes for Rx and Tx?
Yes, at the moment.
Err, perhaps repeater operator is a bit ambiguous here?
The repeater owner/administrator, who configures the repeater can can set up a repeater with different tone or digital squelcn settings for transmit / receive. The occurrences of this are pretty rare, and a number of popular radios do not support the setting of different squelch encoding / decoding on the same memory channel. However, I've seen a couple of popular linked repeater systems in the NYC area move to this configuration to avoid interference.
Also, I'm going to take the risk of being a bit pedantic here since I've seen a lot of misunderstanding on different mailing lists.
CTCSS, Aka Tone Squelch, or PL (Private Line) is a method for including an analog tone in a transmitted signal in order to allow the receiver to operated in a mode where it will only open the squelch if the tone is present. This prevents noise or even other undesired signals from being heard.
DCS, Digital Coded Squelch, uses a digital code embedded in the transmitted signal that provides for more possible squelch codes and greater reduction in an unwanted signal opening the receiver's squelch.
The typical repeater setup (especially in the US) is that the repeater's receiver has a tone squelch setup to prevent the repeater from keying up on unwanted noise or signals. This means that in order to use the repeater, your radio must *encode* the squelch tone in your transmission.
The repeater when retransmitting a signal may encode a squelch tone or digital code. This is a feature for the convenience of the people who listen to repeater to provided added protection against hearing unwanted noise or signals. None of the receive squelch settings on your end are required to use the repeater and if set incorrectly can prevent you from hearing the repeater. Given that it is often best to make sure you've got the settings for the repeater working correctly before you enable any receive squelch settings for that memory. If you don't live in a noisy area you could skip that step entirely.
About half of the repeaters that I've come across do transmit tone squelch which makes monitoring and scanning that much more pleasant. I've only come across three repeaters in my area so far that use DCS.
The most of the non-typical setups I've seen are from linked repeater systems in areas that are densely packed with radios.
Hope This Helps, --Rob
About half of the repeaters that I've come across do transmit tone squelch which makes monitoring and scanning that much more pleasant.
Amen.
I've only come across three repeaters in my area so far that use DCS.
I (co-)run one that uses DCS. It's the only one I know of :)
I don't know any of the current "ham" radios that support different DCS codes on the input and output (the same goes for tones), nor do I know of any of them that allow you to send DCS without requiring it on receive. In other words, you can transmit a tone without needing it on receive, but you cannot only transmit a DCS code.
I recognize that this limits chirp's applicability to a very few niche ham repeaters and/or potentially some commercial repeaters. I'm certainly not saying that CHIRP *shouldn't* support such operation, but I don't think the audience is wide enough to justify me spending time on it instead of something else. If I'm wrong here, please speak up.
Bob,
Thanks for the education. For a short time, back about 1978 to 1981, I converted a Motoroal base station into the first 147.61 repeater for Vail, CO. I seem to recall that PL was just beginning to be used by some PDs in Denver but none of the ones in my area of the Western Slope. From 1981 until recently, I've been away from ham radio and not following current developments and the evolution of practices.
So, some more questions. Use of CTCSS or DCS is a "local option" and the decision to use it on a repeater's retransmission is a separate local decision. Using the same PL tone (or DCS code) on the repeater's input and output has evolved into a "usual and customary practice" and is not a requirement. Further, it is used in an attempt to restrict a repeater to only retransmitting signals that are really intended for it and its users. Adding that tone or code to the repeater's output merely adds value for the user since spurious signals on the repeaters output freq are "hidden".
Further, many of the UHF/VHF ham radio manufacturers have built the usual and customary practices re: CTCSS tone/DCS code use into their radios to simplify circuit design and complexity. The consequence is that it reinforces the usual and customary practices. An unintended consequence is that users assume that the usual and customary is an absolute, immutable rule. It alsomakes life substantially more difficult for the admin/operator who needs to use different CTSS tones or DCS codes on a repeater's input and output frequencies. I know of a system (Colorado Connection) where there are a few VHF-VHF links in a larger system.
Have I captured the gist of the matter, Bob?
Again, thanks for the explanation. After I sort out a few more "things" I'm going to become more active around here and try to meet some of the folks who maintain local repeaters. As an aside, one thing that puzzle2 s me is the general lack of traffic that I hear. One of those "things" is building or buying better antennas for my QTH (covenant-restricted subdivison) and my van.
73 de KK4DBR, Ron EL98fk Windermere, Orange Cty, Florida living in the massive shadow of a wee rodent
On 8/9/2011 11:19 AM, Robert Terzi wrote:
On 8/9/2011 9:45 AM, Dan Smith wrote:
On 8/9/2011 12:49 AM, Ron McKenzie wrote:
[...] Some questions to help increase my knowledge of current practices: [...] 2. Is a repeater operator precluded from selecting different CTSS or DTCCS codes for Rx and Tx?
Yes, at the moment.
Err, perhaps repeater operator is a bit ambiguous here?
The repeater owner/administrator, who configures the repeater can can set up a repeater with different tone or digital squelcn settings for transmit / receive. The occurrences of this are pretty rare, and a number of popular radios do not support the setting of different squelch encoding / decoding on the same memory channel. However, I've seen a couple of popular linked repeater systems in the NYC area move to this configuration to avoid interference.
Also, I'm going to take the risk of being a bit pedantic here since I've seen a lot of misunderstanding on different mailing lists.
CTCSS, Aka Tone Squelch, or PL (Private Line) is a method for including an analog tone in a transmitted signal in order to allow the receiver to operated in a mode where it will only open the squelch if the tone is present. This prevents noise or even other undesired signals from being heard.
DCS, Digital Coded Squelch, uses a digital code embedded in the transmitted signal that provides for more possible squelch codes and greater reduction in an unwanted signal opening the receiver's squelch.
The typical repeater setup (especially in the US) is that the repeater's receiver has a tone squelch setup to prevent the repeater from keying up on unwanted noise or signals. This means that in order to use the repeater, your radio must *encode* the squelch tone in your transmission.
The repeater when retransmitting a signal may encode a squelch tone or digital code. This is a feature for the convenience of the people who listen to repeater to provided added protection against hearing unwanted noise or signals. None of the receive squelch settings on your end are required to use the repeater and if set incorrectly can prevent you from hearing the repeater. Given that it is often best to make sure you've got the settings for the repeater working correctly before you enable any receive squelch settings for that memory. If you don't live in a noisy area you could skip that step entirely.
About half of the repeaters that I've come across do transmit tone squelch which makes monitoring and scanning that much more pleasant. I've only come across three repeaters in my area so far that use DCS.
The most of the non-typical setups I've seen are from linked repeater systems in areas that are densely packed with radios.
Hope This Helps, --Rob
chirp_users mailing list chirp_users@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_users
On 8/9/2011 9:45 AM, Dan Smith wrote:
- Why did you delete the Name field?
The UV-3R doesn't support names, so that column shouldn't be displayed when editing such a file. It's still supported in CSV, of course.
DOH, you're right, I was looking at chirp's display of the image (hex) file and mistook it for the CSV file; once I opened that, the Name field was there, waving it's little paw at me.
<smip> > I don't see where the UV-3R uses the DTCS Polarity information at all; > it does not appear to be an option as I read my .dat file. Yes, it can. When you're entering a DTCS code on the front panel, press the menu button and it will change from N (normal) to I (inverted).
Where in UV-3R's file is this stored? And, similarly, where do they store the BCLO (xmt lock-out while channel in use) flag by channel?
It appears to me that Baofeng/Vero is using offsets (bytes) 04 and 09 in each 16-byte frequency (or channel structure) word to designate the CTCSS tone or DCS code. From what I see, there are 50 CTCSS tone codes and 104 DCS codes. Do I double that last number to account for the 2 polarities? If so, that means I'm trying to store 258 distinct bit codes in a max 16-bit hex byte (00-FF)..
In the words of the MC at the melodrama, we have 6 beautiful girls and 4 lovely costumes.
Is what you classify as DTCS "R" polarity what the Baofeng folks designate as "I"?
Thanks and 73 de KK4DBR Ron
It appears to me that Baofeng/Vero is using offsets (bytes) 04 and 09 in each 16-byte frequency (or channel structure) word to designate the CTCSS tone or DCS code. From what I see, there are 50 CTCSS tone codes and 104 DCS codes. Do I double that last number to account for the 2 polarities? If so, that means I'm trying to store 258 distinct bit codes in a max 16-bit hex byte (00-FF)..
The tone fields are two bytes wide. I would point you at the code if you're interested in the details, and also point you to the chirp_devel list if you want to talk bits and bytes. That's beyond the scope of what most people subscribed here want to see.
http://d-rats.com/hg/hgwebdir.cgi/chirp.hg/file/43efd847a8fe/chirp/wouxun.py...
Is what you classify as DTCS "R" polarity what the Baofeng folks designate as "I"?
Yes. Icom calls it "reverse" and many commercial rigs call it "inverted". I expect the UV3-R refers to it as "inverted," since Baofeng stole (allegedly, of course) from a commercial rig.
The tone fields are two bytes wide.
Whoops, I was looking at and thinking of the wouxun (which is in the same file I linked to).
On the UV3R, the tone value is one byte wide, storing 50 tones and 104 DCS codes. There are two other flag bits used to indicate inversion of the transmit and receive codes, as you can see in the source link I provided.
participants (3)
-
Dan Smith -
Robert Terzi -
Ron McKenzie