12 July 2021

Protecting the ham radio station against lightning and EMP

 Lightning is a natural event with a tremendous destructive power. You have the electric hit and the associated EMP hit; you have to match protection for both.

For many years, Polyphaser set the standard in industry.

Here are some documents to read about lighning and protection against it, those documents are in PDF format and the links are from Polyphaser website. Click on them, download and keep it stored!

-The Lighning Event;

-Significance of Surge Protection for Radios;

-EMP Mitigation - Protection Land Mobile Vehicles from HEMP

-Coaxial Cable Protection

-Equipment Rack Grounding

-Halo Grounds

-Ham Radio Station Protection

-Insulated Support Structures

-Lightning Protection Location

-Tower Mounted Electronics Protection

-Tower Strikes and Solutions

-EMP Mitigation

-Built-in protection... Can You Trust It?

06 July 2021

Xiegu G90 Block Diagram and Schematic

Based on work of Bob, W9RAN and some modest contribution from my side, here is the block diagram of the popular Xiegu G90 transceiver.


 

 

THIS PART IS NO LONGER ACTUAL BECAUSE THE FULL SCHEMATICS ARE AVAILABLE

 

And, based on reverse engineering of parts I am interested in, here is the schematic. Attention, it is work in progress!

Last version: September 15, 2021 - minor corrections



I received a very interesting e-mail from Nils, W8IJN. 
Many thanks Nils for the informations:

Adrian,

I've been following your adventures exploring the inner workings of the G90. I've downloaded all the schematic diagrams that you've put together about the radio.

Recently I blew up the two 100 Ohm resistors in the area around the key jack. I sent Radioddity a note and they responded with a schematic of that area. The drawing is included with this email to add to your collection.

The problem came from testing a EFHW antenna with the 49:1 balun sitting a meter from the radio and connected by what turned out to be a faulty cable. The radio wasn't grounded and the key line did not have any RF suppression/chokes on it. I figure the RF got past the RFC and the zener diodes shorted the RF through the 100 Ohm resistors to ground.

I repaired this with parts I had and added 1nf caps on the high/key jack side of the RFCs. We'll see how that works out. Oh, and I grounded the radio and put a clip-on ferrite on the key line.

Stay safe and well, Adrian. We will survive!




73

Nils R. B. Young
W8IJN

There is a small difference between the schematic received from Xiegu and what i found on my board. The supressing capacitors in my radio are between the resistors and inductors while in the picture sent by Xiegu are on the ESD suppressing diodes. This might be from a different revision or even a mistake in my drawing. I will check this soon.

04 June 2021

Split one COM port between two software programs

Many times I was facing a complicated problem: using two software programs that need to access the same serial port at the same time. This is the case when a CAT program like Ham Radio Deluxe want to access the radio but, in the same time, I want to use my favorite Log program! 

Usually, this is not possible because the intrinsec properties of a serial UART prevent it to be addressed by two different programs

Usually, commercial products are spicy and, if I can use the money on hardware, this is what I choose to do.

So, I search and search for a proper solution to use my SW without paying too much and I found that it is possible to have a really freeware solution.


And the solution came from ETERLOGIC  and it is named: VSPE - Virtual Serial Ports Emulation.

Unfortunately, this solution is no more freeware! 

Download it, install it.

Create a "New Device". It will made a new virtual serial port and will connect it to the hardware serial port.


Then, this new virtual serial port can be used into the software.

I used it with:

-HAM RADIO DELUXE

-N3FJP Amateur's log

-N3FJP CQ WW DX Contest log

All simultaneously!





23 May 2021

XIEGU G90 - ATU problems

Some considerations about Xiegu G90 internal ATU tuning problems.


1. The ATU is a "relay" based.

2. The ATU is driven by the Main Unit MCU STM32F429.

3. The mismatch (SWR ratio) is measured with a Bruener phase compensated bridge, like the one in this picture (too lazy to draw it myself): 



Here is a picture of the SWR bridge from the Xiegu G90:


The outputs of the bridge are fed into a dual OpAmp then sent to the MCU ADC where the values are used to calculate the SWR that is used to find the match solution and it is also sent via UART to the Front Panel MCU to be displayed on the LCD.

4. In some FW versions the ATU seems to do a better job in matching various non-resonant antennas. FW revisions that use high RF power gave more accurate matching solutions than those that uses low RF power.

5. How the tuning sequence is done (in a simplified and presumable description): 
    Frequency is stored in EEPROM;
    -LC relay configuration is stored in EEPROM;
    -SAMPLE(Direct and Reflected are sampled);
    -oldSWR is calculated; oldSWR is stored in EEPROM;
    -change is applied to LC relay configuration;
    -SAMPLE;
    -newSWR is calculated;newSWR is stored;
    -newSWR is compared with oldSWR; decision is made upon this (continue or stop finding a match solution).


In high quality "tuners", the RF is applied only during the SAMPLE and SAMPLE is made when the relays are settled, in a stable state.

In the G90 the RF is present always during the TUNE process.

Depending on the voltages applied function of time, the relays can be in 3 states: ON. OFF and UNSETTLE, the last being an uncertain position between the first two ones and this parameter is defined as “operating time” which, depending on manufacturer can or cannot include the bouncing time.The bouncing time is a time interval in which the contacts are closing and opening erratically for mechanical reasons.

If the SAMPLE is done during the bouncing or inside the operating time interval, the result can be massive altered. (bouncing during the RF presence can make the LC’s to “ring” on various harmonic frequencies also).

This is particulary valid on those relay ATU’s that are working very fast and the ATU in the Xiegu G90 IS A VERY FAST one!

Because all of this, a wrong LC configuration can be selected for that particular frequency thus allowing the radio to transmitt full power on a mismatched antenna system.

This can be a source for errors in ATU sequence and those can be identified very quick by activating the tune sequence several times on the same frequency and the same antenna system. 

Beware! The short press will recall a matching solution already stored in memory for that frequency therefore a long press is desirable, in order to erase that memory and start the matching process from the scrap. (Thanks Dave).

If the results are different, most probable is due to settle time. This time interval is in the 5-10msec range.

The problem can be mitigated by various means, all in the FW code; the most efficient one is to switch on RF after a 10msec timeguard from the LC solution is applied to the relays.

6. Errors in SWR value can came from the intrinsec construction of the SWR bridge. The major source of error are the diodes in the bridge. Injecting low RF (around 1W) into a Bruener bridge based on Si diodes (even Schottky) can be into the non-linear range of the transfer function which also is altered by variation in the ambient temperature. (https://www.analog.com/en/technical-articles/integrated-diode-based-rf-detectors.html#)

Another factor that alter the SWR ratio could be the loses on the Reflected path. On loosy antenna systems, the Reflected power is attenuated by some factors like the lenght in the coaxial cable. This leads to a lower voltage in the non-linear transfer function of the diode therefore reducing more and more the reflected detected voltage and finally affecting the SWR ratio to a point that the MCU "feel" a proper match is achieved even if a non-match solution is set in the LC relays.

Therefore, the SWR calculated value could reflect or not the true SWR. The result is a wrong tuning solution.

This problem can be mitigated by applying one of these solutions:

a.     Replacing the Direct and Reflected detection diodes with lower threshold ones. The actual diodes used in the Xiegu G90 has to be measured to find out if they are normal Si or Schottky.

b.     Biasing the actual diodes to the linear transfer range.

c.     Replacing the diodes with logarithmic amplifier like AD8307

Actually, the last method can be the most successfull one it is also the most complicated and require major modifications that might be not reproductible by most hams so the first and the second one could be further explored.

11 May 2021

XIEGU G90 - COMM LOST error

The Front panel and the Main unit of the popular Low power transceiver Xiegu G90 are connected through a DB9 cable.

The Main unit and the Front panel have, each other, separate firmware upgrade procedures meaning. This meaning the user has to acces the upgrading UART on each part of the radio.

Between the two parts, information is exchanged via UART also. The Main unit is sending information from the I/Q detector used to show the nice waterfall on the LCD and the Front panel is sending frequency and mode (and other various DSP settings) to the Main unit.

From practical observations, the protocol used between the Main unit and the Front panel is modified on the fly, with each "improved" version therefore, different versions of FW cannot be used (with one exception at this moment, DisplayUnit FW 1.76 and MainUnit FW 1.77. (download link).

Possible causes for this, as far as the time of this post;

1. Improper contact on the separation cable.

2.  a- Incompatible FW versions (see the above note about FW1.77).

     b- No FW in the Main unit. This will be detailed.

3. Physically broken UART either on Front panel or in Main unit.


Note about 2.b- The FW procedure means that you must connect the radio to the power supply with the serial programming cable (3.5mm stereo jack), start the PC software, power ON the radio and send "1" from a terminal window. What happen next is that the content of FLASH memory of the microcontroller is erased. So, no FW in the uC.

If the cable is left into the programming jack, at the power on, a stray "1" can be accidentally sent thus erasing the FW. The Front panel uC will wait for the right flag on UART and after a while it will signal that the serial communication is not possible. The solution is simple, you must reflash the Main unit (with the right version of FW, of course).

This apply also on 2.a.

Most viewed posts in last 30 days