FT37-43 for a 49:1 EFHW transformer enquiry

A correspondent asked whether Sontheimer coupler – transformer issues – an alternative design – FT37-43 could be used to inform design of a 49:1 EFHW transformer based on the same core, but with a 2 or 3t primary.

In the case of the Sontheimer coupler the winding with the higher number of turns appears in shunt with the nominal 50Ω load, and its effect on InsertionVSWR and the core loss can be predicted reasonably well and confirmed by measurements as in the referenced article.

In that instance, a 7t winding in shunt with the nominal 50Ω load causes excessive core heating, a 3t winding will be worse, and 2t worse again.

The case of an EFHW transformer is somewhat similar, the difference is now that the winding with less turns in approximately in shunt with the nominal 50Ω primary referred load. The same Simsmith model can be used to predict likely InsertionVSWR due to primary magnetising admittance, and the core loss.

Let’s try the 3t case first, with the experience of the referenced article we can expect it will have insufficient turns for good performance.

Above is the Simsmith model of a Fair-rite 5943000201 core (equivalent dimensions to FT37-43) with a 3t winding. Note this does not apply to Amidon #43 as their material is significantly different in characteristic. Continue reading FT37-43 for a 49:1 EFHW transformer enquiry

(tr)uSDX firmware, bootloader, application – an explanation

Introduction

The term firmware means lots of things to lots of people, and you will see so many definitions that it becomes confusing.

It is apparent from postings by people about (tr)uSDX (trusdx) that the rubbery definition prevails in that environment also.

The term firmware came into being 50 odd years ago, about the time that microcomputers appeared. There was a need for a term to describe something that sat between traditional hardware and software, the programming that was ’embedded’ in the system.

ATmega328P memory

In the case of the ATmega328P (as used in the (tr)uSDX), it contains three main blocks of memory and some auxilliary non-volatile storage, the three main types are:

  • RAM (volatile scratch storage used for running programs);
  • FLASH (non-volatile memory used for user programs (instructions and constant data); and
  • EEPROM (non-volatile memory often used to save settings, calibration data etc).

Firmware

We might reasonably regard that all of the contents of FLASH is firmware.

Bootloader

(tr)uSDX uses a bootloader, user code that can be executed on startup to load user programs into FLASH. In the case of the ATmega328P, the bootloader resides in FLASH at the top of the address range. FUSE settings tell the system to start at the boot section on power on reset, and they can be used to protect the bootloader from corruption on reliable systems (this last feature is NOT used on (tr)uSDX).

Above is a map of FLASH memory for an ATmega328P for the configuration used by (tr)uSDX from the chip datasheet. Continue reading (tr)uSDX firmware, bootloader, application – an explanation

(tr)uSDX bootloader corruption – a smoking gun – an experiment

At (tr)uSDX bootloader corruption – a smoking gun I proposed that the (tr)uSDX (trusdx) is vulnerable to users attempting to program the initial bootloader file using the (tr)uSDX USB port and its bootloader interface because without protection, that will attempt to overlay the bootloader while it is being executed and that is likely to corrupt the bootloader.

The (tr)uSDX bootloader code is proprietary, ie secret.

This article documents an experiment that demonstrates the vulnerability, and the effect of bootloader section protection.

Below are a series of verbose AVRDUDE logs of the operations to discover / demonstrate the outcomes. Continue reading (tr)uSDX bootloader corruption – a smoking gun – an experiment

(tr)uSDX bootloader corruption – a smoking gun

A common topic of discussion on (tr)uSDX (trusdx) forum is problems in loading firmware (application or bootloader.

A user posting provides evidence for discussion of the problem in this case, probable cause, solution, and a better design to prevent the problem.

Analysis

The type of programmer (Arduino), connection (COM port) are the settings one would use to talk to a bootloader already installed on the mcu to write the application program to flash. They are not the settings one would use to install the bootloader, they are not suitable for talking to the ISP facility burned into silicon. Continue reading (tr)uSDX bootloader corruption – a smoking gun

ISP programming of the (tr)uSDX – more on SPI

ISP programming of the (tr)uSDX (trusdx) showed that filtering on the MOSI pin in that kit distorted the MOSI signal significantly and suggested a workaround (reducing SCK rate) for reliable programming.

Some correspondence prompts a little more information on the nature of the ATmega328P ISCP signals.

The line protocol used is actually SPI, quite a common protocol.

ISP uses SPI MODE 0 (CPOL=0, CPHA=0), shift out on the falling edge of SCK, and capture input on the rising edge.

Let’s look at a three channel capture of SCK, MOSI and MISO of a AVRDUDE / USBasp driving an Arduino Nano.

The capture shows SCK at around 750kHz rate, the default (-B1) rate for AVRDUDE in this setup. Continue reading ISP programming of the (tr)uSDX – more on SPI

(tr)uSDX – review of the directional coupler ADC design

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.

ATmega328P datasheet

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. Continue reading (tr)uSDX – review of the directional coupler ADC design

Sontheimer coupler – transformer issues – an alternative design – FT37-43

Sontheimer coupler – transformer issues discussed problems with the Sontheimer coupler in a recently published QRP transceiver ((tr)uSDX / trusdx), suggesting that the core loss in transformer T2 was excessive.

This article presents an alternative design for the transformer for a coupler for a 5W transmitter.

The above circuit is from (Grebenkemper 1987) and is an embodiment of (Sontheimer 1966). In their various forms, this family of couplers have one or sometimes two transformers with their primary in shunt with the through line. Let’s focus on transformer T2. It samples the though line RF voltage, and its magnetising impedance and transformed load appear in shunt with the through line. T2’s load is usually insignificant, but its magnetising impedance is significant and is often a cause of: Continue reading Sontheimer coupler – transformer issues – an alternative design – FT37-43

Sontheimer coupler – transformer issues – an alternative design – FT23-43

Sontheimer coupler – transformer issues discussed problems with the Sontheimer coupler in a recently published QRP transceiver ((tr)uSDX / trusdx), suggesting that the core loss in transformer T2 was excessive.

This article presents an alternative design for the transformer for a coupler for a 5W transmitter.

The above circuit is from (Grebenkemper 1987) and is an embodiment of (Sontheimer 1966). In their various forms, this family of couplers have one or sometimes two transformers with their primary in shunt with the through line. Let’s focus on transformer T2. It samples the though line RF voltage, and its magnetising impedance and transformed load appear in shunt with the through line. T2’s load is usually insignificant, but its magnetising impedance is significant and is often a cause of: Continue reading Sontheimer coupler – transformer issues – an alternative design – FT23-43

ISP programming of the (tr)uSDX

I noted some online discussions where some people had troubles using an ISP programmer to program the MCU.

I do not have a (tr)uSDX (trusdx), but inspection of the schematic does hint what those users are doing wrong.

Loading the SCK, MOSI and MISO lines risks problems with operation of the SPI protocol used, but the effect depends to some extent on the driver, length and type of interconnecting cable etc.

Here are some measurements of a USBasp driving an Arduino board with 5V Atmega328P 16MHz chip using about 200mm of ribbon cable… AND the MOSI line is loaded with a 0.01µF capacitor (as in the (tr)uSDX schematic).

As mentioned, ISCP uses an SPI protocol and the capture above uses blue for SCK and cyan for MOSI. Continue reading ISP programming of the (tr)uSDX

Sontheimer coupler – transformer issues

It is not uncommon that ham designs for Sontheimer coupers (aka Tandem coupler, Grebenkemper coupler) fall short in the design of the magnetic components resulting in one or both of:

  • high InsertionVSWR; and
  • high core loss.

The above circuit is from (Grebenkemper 1987) and is an embodiment of (Sontheimer 1966). In their various forms, this family of couplers have one or sometimes two transformers with their primary in shunt with the through line. Let’s focus on transformer T2. It samples the though line RF voltage, and its magnetising impedance and transformed load appear in shunt with the through line. T2’s load is usually insignificant, but its magnetising impedance is significant and is often a cause of: Continue reading Sontheimer coupler – transformer issues