Re: [tracker2] Software DCD
- Well, if you don't include a AC coupled CD line, I'll (ie the end user) will have to make an AC coupled rectifier... seems like a simple cap in series with a diode so that the diode charges a .01uF of there abouts would do the trick... esp if you turned the volume all the way up. Something like that could be built into the speaker line from the radio.... speaker audio in at one end, and logic signal out the other end. The only real trick is making sure the charged cap bleeds down fast enough when the audio stops.Wes----- Original Message -----Sent: Thursday, March 30, 2006 2:24 PMSubject: RE: [tracker2] Software DCDDidn't someone already built a '2211-based DCD board? I think Bob was complaining about it. As for the AC-coupled CD input, I just want to avoid adding another pot if I can avoid it...
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Wes Johnston
Sent: Thursday, March 30, 2006 11:19 AM
Subject: Re: [tracker2] Software DCDThe best way _would_ be if it could discern packet tones on the 144.39 radio at the reapter site. But an AC coupled CD input like on the tiny tracks would be fine... I'ts not likely that the 144.39 2m only el-cheap-o transceiver I put at my repeater site will have a COR output... but it is very likely that it will have a speaker jack.So in a nutshell... at a repeater site, we need a tnc that can discern packet tones and provide us a mute function... do call substitution and digipeat out on a 2nd radio on 144.39. It needs to be able to either use speaker audio or a logic level COR signal to CSMA on 144.39.Scott, have you thought about making a stripped down simple carrier dector board? Just looks for the transistions at the right time and provides ONLY a mute (ie DCD) indicator?Wes----- Original Message -----Sent: Thursday, March 30, 2006 11:14 AMSubject: RE: [tracker2] Software DCDMy thoughts exactly. It probably needs a 'dumb' CD input anyway, so you can connect it to a radio with a COR output. I don't think it needs an AC-coupled input like the OT1, though - or at least, I can't think of any reason for one. In the default mode, it operates from the carrier detect of the '2211, which seems to do a good job of detecting any audio.Bob was just complaining about the lack of suitable DCD's for Mic-E digipeating - I wonder how this compares.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Wes johnston
Sent: Thursday, March 30, 2006 4:18 AM
Subject: Re: [tracker2] Software DCDnatrually, the next step would be to ask that the power pin become a MUTE function. I'd use the LED, but it just blinks, right? This way the T2 could be used for mic-e digipeating at a voice repeater site.In our local repeater, I inserted a 100ohm resistor in series with the COR between the repeater receiver and the controller. I just shunt the controller side of that resistor to ground when a packet is present, which in turn causes the repeater to think that the carrier dropped, and it will do the audio muting for me. This also pays off by allowing me to send packets on the repeater input when it is dormant... because the repeater controller only sees like 10mS of an active COR before the TNC shunts it to ground, the controller simply thinks it got kerchunked and does not come on air.Oh, now we just need an XCD pin to know the status of the aprs channel before allowing T2 to transmit... could we use one of the extra a/d pins?Wes----- Original Message -----Sent: Thursday, March 30, 2006 1:07 AMSubject: [tracker2] Software DCDNew firmware and config program have been uploaded. This version adds a
software data carrier detect function, so the unit can be run open-squelch.
The checkbox is in the digi menu, which will probably turn into a generic T2
extended function menu.
In software DCD mode, the DPLL has to receive 20 consecutive symbol
transitions inside the expected window to consider the channel busy. The
exact number might be a configuration option later, if necessary.
Digis should normally be run with the radio's squelch open, to allow faster
lock on incoming packets. This option lets you do that. You don't want to
use it on a shared data/voice channel, though, because it won't recognize
anything but data.