One of my simpler projects, just three electronic components and 140 lines of code… an open squelch DCD (OSDCD) for Paccomm Tiny2 Mk2 .
The TNC normally derives Data Carrier Detect (DCD) from its TCM3105 modem chip (often a broadband energy detector is used in modem chips, and it is such in the TCM3105). DCD is used to enable decoding of incoming Receive Data (RD), and to block transmission whilst the channel is busy.
There are two problems that the OSDCD addresses:
- squelch may be slow to open on some receivers, preventing decoding of some packets with short preamble; and
- if squelch opens because of interference or non-packet signals, the transmitter is blocked.
Additionally, a receive with open squelch recognises another transmitter (and potential collision) faster, something of the order of 40-50ms and can therefore wait until the next slot to avoid the collision.
The OSDCD monitors the RD pin of the modem chip, and tries to recognise transitions characteristic of 1200Bd data transmission. The name derives from the fact that the receiver can be operated with squelch open as the OSDCD differentiates between 1200Bd data and other audio.
This OSDCD hardware implementation is specifically to suit the Paccomm Tiny2 Mk2 as it has a 7pin header (pins numbered 2-8) to receive a module for this purpose. This module uses only the high five pins:
OSDCD ATTiny25 pin | Tiny2 Mk2 DCD_OP pin | Description |
---|---|---|
1 | NC | /RESET |
2 | XTAL | XTAL |
3 | XTAL | XTAL |
4 | 7 | GND |
5 | NC | S1200 |
6 | 4 | RD |
7 | 5 | /DCD |
8 | 8 | Vcc |
The table above shows the connections.
To install it in the Tiny2 Mk2, JPD must have the link removed (place it over just one pin for storage), and the module fitted to the high pins of the DCD_OP header.
The firmware has been tested with Paccomm 5.0 firmware in normal mode and KISS mode, and with UIDIGI 1.9B3. In both cases, it shows DCD on signals that are not strong enough to decode the frames.
Above is a typical response comparing the OSCDC signal with that of the TCM3105 modem. The OSDCD naturally takes a little long to recognise signal as it must see two bytes to consider the clocking valid, and it stops as soon as data is removed, the modem responds to the squelch tail.
An interesting observation is that OSDCD can be kinder to grossly overdriven signals (and there are plenty) than the modem which is inclined to remove DCD during some of these packets, and so disabling decode. The standard Tiny2 Mk2 used hardly ever decodes VK2RHR-1 standard, but decodes it more than 80% of the time with OSDCD (with the radio squelched, so it is not a squelch delay problem).
A test was conducted with WA8LMF test CD track 4 with standard and with OSDCD. 90 packets were decoded standard, and 88 with OSDCD, the loss of 2% decodes for the benefit of clock derived DCD is small in most situations. By contrast, a MFJ-1270B decoded only 78 packets.