I noted some online discussions where some people had troubles with the displayed forward and reverse RF power values, and the calculated SWR.
Some of the reports indicate non-zero RF power values displayed when the transmitter is off, symptoms which direct diagnosis in the first instance to review of the ADC input circuit.
This article reviews the hardware design based on documents as published at the date of this article.
Let’s start by reviewing some relevant parts of the ATmega328P datasheet.
Above is a simplified schematic of the ADC pin input circuit. Note the current sources IIH and IIL.
The above extract gives maximum or worst case figures for IIH and IIL. A reasonable interpolation is that at pin voltages between 0 and 5V, an ADC pin may source or sink up to 1µA.
So what happens if you read an ADC pin with nothing connected to it, ie open circuit?
In practice, the results is usually not zero, it can be anything up to the full scale value, ie 0-1023 (in 10 bit mode), and it is usually noisy, ie it jumps around.
If you connect a capacitor from the ADC pin to ground, any current sourced from the pin will tend to charge the capacitor and the capacitor will tend to smooth the jitter. The reading is not predictable, it depends on the pin leakage current characteristic, which varies with time, temperature, and from chip to chip, as well as the capacitor leakage characteristic which also varies with time, temperature, and from capacitor to capacitor.
So, how do you use a pin with this characteristic?
The circuit you attach to the pin must tolerate any current into or out of the chip pin, and the specification tells us to tolerate ±1µA.
Now lets look at the relevant part of the (tr)uSDX (trusdx) schematic for the forward detector.
Above is an extract of the schematic, the FWD node connects to ADC6 on the main board and there is C39, a 10nF capacitor to ground from that terminal.
So, taking the simple case where there is no RF power into the detector, the desired condition is that the voltage on FWD is zero.
Now trace out on the schematic where 1µA sourced from ADC6 will flow (ie out of pin ADC6). Some of it flows to ground through C39 adjacent to the ATmega328P, the balance flows in on FWD from the right in the above schematic, and there are several paths to ground, via C7, via C5, via reverse biased leakage of D1. Note that C39, C7 and C5 have capacitance and shunt leakage, so any current sourced from ADC6 tends to charge C39, C7 and C5, which all leak some current to ground and the final voltage on ADC6 depends on the ADC6 pin current pin characteristic of that instance of the ATmega328P, and the leakage characteristic of the three capacitors and reverse leakage characteristic of D1. Note that the leakage current to ground with good capacitors and diodes is much less than the worst case current from ADC6.
ALL of these are imperfections of the various components, and so, under zero RF drive, the value read from ADC6 is a result of various device imperfections, which vary from instance to instance, temperature etc.
The circuit design is likely to not work properly on ALL manufactured systems.
The RVS detector circuit is the same, and is likely to have the same problem but not that the residual voltage with zero RF input may be different as it depends on component imperfections.
Displayed SWR depends on both FWD and RVS detectors, and if one or both of them are in error, then the displayed SWR is a case of GIGO (garbage in, garbage out).
The effects of current sourced from the ADC pin is likely to be greatest at low RF power in the FWD detector, and of course the RVS detector would usually be operated at low RF power if close to matched.
Clone or substandard chips
None of this discussion is about chips that do not meet the datasheet specification. That is another matter, the discussion here offers one explanation of why the circuit as implemented might exhibit the symptoms observed by some users.
It seems that the solution favored by online experts is to swap the ATmega328P until one is found with acceptably low leakage. It is the last thing I would do!
I am experienced in replacing such chips, above is a Nano with damaged chip removed (a casualty of experimentation) and prepared for a replacement, awaiting cheaper chips one day.
It is my view that to offer a solution to this problem is sufficient to create a derivative work which is not permitted under the CC BY-ND licence under which (tr)uSDX is distributed.
It is also probably impractical as to solve the hardware issue discussed here will require recalibration of the firmware, source for which is proprietary (ie secret).