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.
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.
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.
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
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.
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.
Bill of material
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. Using Zak Kemble's 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.
When programming the hex files make sure the "divide clock frequency by 8" fuse is unchecked and that the fuses specifying the clock source 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). When in doubt consult an AVR fuse calculator such as this one: https://www.engbedded.com/fusecalc/
If building your own code from source using Atmel Studio V7.0 set optimisation to -OS (optimise for size).
Any chips supplied by the BATC shop will have the correct code installed for both the ATmega and the Nano - you cannot mix and match Arduino code with the ATmega C code.