Tag: trusdx

(tr)uSDX IMD performance

(tr)uSDX uses less common techniques for generation of an SSB telephony signal at modest power (a few watts).

There are aspects of the techniques that might raise questions as to how well they work, questions that do not seem to be addressed by the developers.

Wide signal / distortion reports

Whilst there are lots of videos where users demonstrate making QSOs with the (tr)uSDX, credible evaluation of common reports of wide transmit bandwidth is scarce, though spectrum displays of excessively wide (tr)uSDX signals on air are not so rare.

One simple objective measure of IMD is that of a two tone test with spectrum analysis.

Two tone test with spectrum analysis

A two tone test calls for combining two equal amplitude non-harmonically related pure sine waves and feeding that to the transmitter input, and observing the spectral distribution on a Spectrum Analyser.

Ideally, the output should be just the two input components frequency shifted by the virtual carrier frequency (in the case of USB). Practical transmitters are not perfect, so there will also distortion products, and a common measure is that of the 3rd order mix at  If F1 and F2 are the frequencies of the two tones (at RF), the third-order distortion products occur on both sides of these tones at 2F2 – F1 and 2F1 – F2.

Above is a figure from an Anritsu application note showing a wider scope of IMD. Distortion products are measured wrt to each of the desired signals or ‘carriers’, and this value is often given relative to those signals as dBc. (The ARRL uses a different method, referenced to two tone PEP.) Continue reading (tr)uSDX IMD performance

Last update: 28th February, 2023, 6:22 AM

(tr)uSDX BS170 woes

(tr)uSDX users seem beset by a number of common problems, and one of them is failure of the BS170 PA FETs.

Further, lots of users have bought replacements that appear as a dead short circuit when wired into the board. This seems to be that pins 1 and 3 are transposed on some product bought online.

These FETs have an integral body diode, and if Source and Drain are swapped, the body diode will conduct, appearing to be a near short circuit on the supply rail in the (tr)uSDX. Continue reading (tr)uSDX BS170 woes

Last update: 7th January, 2023, 6:34 AM

(tr)uSDX unauthorised product and countermeasures

It has been interesting to observe takeup of the (tr)uSDX project.

The project is released under a quite restrictive licence.

Whilst the developers do not make or sell hardware, they exercise control over the hardware and offer hardware manufacturers an opportunity to have their implementation “approved” or “authorised”.

It is not surprising that a number of implementations have appeared that the IP owner regards as infringing his licence, inevitable really as Chinese copyists have little regard for intellectual property.

Who’da thought that “unauthorised” products would appear?

One of the developers posted those rigs will be banned from Firmware updates, so don’t buy that.

My correspondent asked how can he do that? Continue reading (tr)uSDX unauthorised product and countermeasures

Last update: 27th December, 2022, 8:21 PM

(tr)uSDX bootloader woes

A reader of my article WriteOptiBoot.bat asked about application to the (tr)uSDX project.

The first point to note is that the (tr)uSDX project uses its own bootloader, and it would appear it is proprietary code (ie secret), and one is entirely dependent on their published information.

A common user problem reported on the the (tr)uSDX project forum is inability to either:

  1. program the bootloader; and / or
  2. program the application code.

Continue reading (tr)uSDX bootloader woes

Last update: 26th June, 2024, 8:09 PM

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

Last update: 14th April, 2024, 1:34 PM

(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

Last update: 25th July, 2022, 1:19 PM

(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

Last update: 25th July, 2022, 1:19 PM

(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

Last update: 27th July, 2022, 6:50 AM

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

Last update: 24th August, 2022, 8:33 AM

(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

Last update: 30th October, 2022, 11:12 PM