custom tx power control (for BPF and PA)

[chrthr]

Hi,

first of all, thanks for this nice firmware!

I have a 2m bandpass filter (max input 3W) and a 2m PA (max input 4W).

Right now I can only use them with MID power level (2W).

It would be great if there would be an option to attenuate the HIGH power level by a custom percentage, so I could decrease it to 3 or 4 Watt. This would give much better control over the output power of the PA.

73, Christian
DO1ZL

[armel]

Hello Christian,

Thank you for your message.

Regarding power settings, unfortunately it's a bit too complex. Since the BK4819's power adjustment is not linear, I chose to offer six pre-calibrated levels instead (which is already much more than what most transceivers of this type provide): from Low1 (<20 mW) to Low5 (~1 W), then Mid (~2 W), and finally High (~5 W).

Adding a percentage-based setting would also introduce issues, especially with storage, as in my firmware, power is defined individually for each memory channel, not globally.

I completely understand your need, but I don't plan to change this logic. That said, the firmware is open, so feel free to adapt it to suit your own requirements.

73'

Armel, F4HWN

[chrthr]

Hello,
thanks for pointing out this line, seems like a good place to do the modification! Will do some tests with this number

I still have some problems with the docker build (compile-with-docker.bat). The default make file has fm radio disabled:

ENABLE_FMRADIO ?= 0

When I change this to 1, it will not compile anymore:

driver/bk1080.d:1: *** multiple target patterns. Stop.

Content of the file:

driver/bk1080.o: driver/bk1080.c \
 C:/dev/git/uv-k5-firmware-custom/bsp/dp32g030/gpio.h driver/bk1080.h \
 C:/dev/git/uv-k5-firmware-custom/driver/bk1080-regs.h \
 C:/dev/git/uv-k5-firmware-custom/driver/gpio.h \
 C:/dev/git/uv-k5-firmware-custom/driver/i2c.h \
 C:/dev/git/uv-k5-firmware-custom/driver/system.h \
 C:/dev/git/uv-k5-firmware-custom/misc.h

Also when I enable aircopy I get:
app/aircopy.d:1: *** multiple target patterns. Stop.

Any idea whats going on here? Maybe related to linefeed windows vs linux?

73

[armel]

Hello,

Sorry, I don't have a Windows PC and I'm not familiar with that operating system.
Maybe another Windows user here could help you out.

73'

Armel, F4HWN

[chrthr]

No Problem, I just found the issue. There were some *.d files left over from my first attempt to compile on windows directly.

After deleting these files now everything works! (I was expecting that "make clean" would remove all created files)

Just as a note, the direct windows compile seems not to work. As a first attempt I followed the instructions in win_make.bat and installed the software mentioned there.
However it already fails with CFLAGS += -Oz in a way that this optimization switch is not supported.

I guess the Arm compiler version 10 2021.10 is not sufficient anymore to compile the firmware?

When changing the optimization switch it will continue but you get more errors, like app/flashlight.c will need an #include <stdbool.h>

I am fine with docker build, just mentioning it in case someone else has this problem.

Thanks!

[chrthr]

Hello Armel,

finally I was able to do the modification and it works quite well.

Sharing my approach here in case someone has a similar requirement. It is just a hack and repurposes the existing menu setting "24 ScnRev". I never use the scan feature so this is fine for me.

In the code I replaced the line you suggested with these two lines

            uint8_t attenuate = gEeprom.SCAN_RESUME_MODE > 20 ? 20 : gEeprom.SCAN_RESUME_MODE;
            Txp[p] += (30 - attenuate * 5);

The attenuate value is limited to 20 to prevent any subtraction underflow on the result, however this could still be problematic if the value in the calibration table is smaller than 0x46. A proper implementation should check for this.

With this code change you can now attenuate the HIGH tx power by changing SCRev entry in "Carrier Mode" between Stop and 05s:000ms. You have to up/down channel in order to re-initialize vfo power level after the change.

I tested some output levels with a wattmeter at 145.9 Mhz:
STOP (attenuate==0) -> 5.1 W, 01s:000ms (attenuate==4) -> 4.6 W, 02s:000ms -> 3.8 W, 02s:500ms: 3.4 W, 03s:000ms: 3.0 W, 04s:00ms 2.2 W

(Of course these values will depend on the device specific calibration data of the EEPROM)

I can now drive the PA with the BPF at a defined level which is really nice!

73, Christian

[armel]

Hello Christian,

Perfect. Good job. I’m glad to hear you’re now able to use your PA the way you intended 👍🏼

73'

Armel, F4HWN.