G4WIM PA controller
An advanced PA controller design by Tim G4WIM and described in CQ-TV 265 - PCB's will be available from the BATC shop.
Introduction
This project came about as a result of needing to remote control and monitor a 2.4GHz power amplifier for the QO-100 satellite up link. In the case of G4WIM the amplifier is at the end of 75 metres of cable directly beneath the feed point of a 1.2 metre dish. So running from the shack to the PA was not an option!
It has evolved from a simple controller which relied on either 5 or 12 Volts being sent up the coax to set off, standby or transmit modes into a multi-purpose design.
Configurations
The resulting system can be configured in three ways:
- Full remote control of the PA and shack monitoring of vital signs – using radio link.
- When PA is in the shack, local control and monitoring - no radio link.
- Remote control of PA by means of DC down the coax – no radio link or remote monitoring
The most likely use cases are 1 and 2. In this article I refer to the PA with associated control and telemetry hardware as the MASTER and the remote display / control in the shack as the SLAVE. When used as #2 above there is no SLAVE and the MASTER serves as control and display.
Monitoring
In all cases it allows monitoring of the following analogue signals:
- Vdd, 100mV resolution
- Idd, 100mA resolution
- PA temperature, 0.3C resolution
- Bias voltage, 10mV resolution for LDMOS
- RF power (forward or reverse but not both – depends on HW implementation)
- Fan status on or off
- Standby status on or off
Amplifier choices
The design was initially conceived for a Pyro Jo PA which needs 24V DC bias to activate it, subsequently it was modified to provide a temperature compensated bias for LDMOS FET’s. Basically for the LDMOS FET use the temp compensated bias circuit and for the Pyro JO PA use the 24V DC device – one or the other NOT both.
See CQ-TV article and schematics for more detail.
Hardware
The design uses the same PCB in all cases but populated slightly differently for each of the three use cases above. The BoM and schematics indicate what needs to be fitted for each use case.
For each use case firmware works differently and is jumper selected as mentioned above.
Note, if RF power is not being monitored then the RF power sensor input on pin 1 of J3 must be connected to ground to disable the function. Normally RF power will only be shown when on transmit and above a certain threshold.
Documentation
Bill of material
File:G4WIM PA CONTROLLER V2-0 BOM.xlsx
Schematics
Microcontroller Firmware
Source code + pre-built hex files (in respective subdirectories): File:BATC_PA_Controller_Firmware_V2.zip
The controller logic is driven by a standalone ATmega328P, whereas the the radio link uses an nRF905 + Arduino Nano v3 (which has its own ATmega328P). The Arduino Nano code is based on this solution http://blog.zakkemble.net/nrf905-avrarduino-librarydriver/comment-page-1/
IMPORTANT - after building several of these links it became apparent that the timings required for the nRF905 are not the same for all modules. To fix this issue I've created a new improved version of Zak's C code for the Nano. The code for the standalone ATmega328P has also been changed to match.
Any chips supplied by the BATC shop will have the correct code installed for both the ATmega and the Nano.
Flashing
Any ordinary AVR programmer + appropriate software should work here. If you do not use a GUI for this, look into avrdude - it is Free Software, supports quite a wide range of programmers, and there are many tutorials and examples available on the Web should the bundled documentation prove insufficient.
In case there is any confusion here: BATC_Unified_PA_Controller.hex goes onto the standalone ATmega328p and avrwirelessuart.hex goes onto the Nano.
Variants of code
Let us re-emphasise that the improved radio-link code for the Arduino Nano is not compatible with the Arduino environment and boot loader! Both the standalone and the Nano-based ATmega should be programmed as a standalone device. In other words, we treat the Nano simply as a collection of parts conveniently already wired to the microcontroller rather than as an Arduino board.
Using Zak Kemble's original code in the Arduino environment might work - but it is better to use his C code version with my modifications as documented and provided in the above source code link.
You cannot mix and match Arduino and plain-ATmega code.
Fuses
Before programming the hex files make sure the "divide clock frequency by 8" fuse (low bit 7) is unchecked and that the fuses specifying the clock source (low bits 0-3) select an external 8-16 MHz crystal. All these fuses should already be set correctly on the Nano because it comes with its own 16-MHz crystal but will likely have to be adjusted on the standalone ATmega328P (the factory settings are different). It is highly recommended that you read the fuses settings out having programmed them to make sure they have been set correctly.
Values of all the other fuses (low bits 4-6 as well as all high and extended bits) are less important. If confused by the plethora of available settings, values used by the Arduino environment (these can be found in the file boards.txt; use 'Arduino Nano w/ ATmega328P' values for the Nano and 'Arduino Uno' ones for the standalone ATmega328P) are a safe choice.
Note that the extended fuses might in the end appear different from what they told them to be because different batches of ATmega328P react differently to the attempts of programming "reserved" fuses. As long as the difference does not cover the "brown-out detection" bits, this is completely harmless.
When in doubt regarding any of the values here, consult an AVR fuse calculator such as this one: https://www.engbedded.com/fusecalc/
Building
The code can be built using Atmel Studio, or if you have a standalone AVR toolchain installed you can simply use GNU make on the project. In either case, you will want to use the "Debug" target to build the hex files - the "Release" target has never been tested by G4WIM so it may or may not work (and in his own words, it shouldn't make any practical difference).
If building using Atmel Studio V7.0 set optimisation to -Os (optimise for size). This is a good idea in general unless you use a very old AVR compiler known to have problems with this optimisation mode.