16 ianuarie 2025

Xiegu G90 - O defectiune tipica

 Micul transceiver Xiegu G90 este unul foarte indragit de radioamatorii carora le place sa iasa in natura. 

Forma sa compacta, cei 20 de W in toate benzile HF, antena-tunerul incorporat si plaja de tensiuni de alimentare pentru care a fost proiectat (10-17V) il fac un fel de "Swiss Army Knife" al SOTA/POTA/WFF ori pur si simplu, al /P.

Daca luam in considerare si ca este un transceiver SDR pur-sange cu un receptor cu performante exceptionale si pretul ce il face accesibil, intelegem de ce este atat de raspandit in lumea radioamatorilor.

Am fost ceea ce se cheama un "early adopter", unul dintre primii care s-au aruncat pe noua jucarie; imi aduc aminte ca, la acel moment, pe "lista de cumparaturi" erau KX2 si KX3, Xiegu G90 fiind adaugat cumva intr-o doara, cu usoara neincredere...

Am avut anterior ceva experiente cu un transceiver din seria "G" de la Xiegu, in sensul ca am avut la reparat (HI) si nu pot spune ca am fost impresionat. Era ceva intre "Casa Pionierilor" si "Cooperativa Radio Progres" insa cele cateva review-uri "de bine" si pretul scazut m-au facut sa ma decid in favoarea lui.

Dupa primirea pachetului, a fost "dragoste la prima vedere" pana cand, la a doua, la aproape doua saptamani de la "intalnire", microcontrolerul panoului frontal a decis sa ne paraseasca ceea ce a dat nastere unui intreg proces de reverse-engineering. 

In pofida experientei mele destul de neplacute, convins de calitatile acestui transceiver, m-am implicat apoi in comunitatea on-line a utilizatorilor de Xiegu G90; am avut astfel ocazia sa intru in contact cu alti posesori sau utilizatori. In general, in astfel de comunitati discutiile sunt orientate in jurul problemelor intampinate iar radioamatorismul are si importanta componenta de laborator si atelier asa ca am incercat aici, pe blog, sa sintetizez tipologiile de probleme cu care fanii Xiegu G90 se confrunta.

Iar una din problemele cel mai des intalnite, este distrugerea etajului de intrare ca urmare a descarcarilor electrice.

Prin eforturi "specifice", am reusit sa intru in posesia unei scheme a producatorului, astfel ca m-am oprit din ridicarea schemei de pe exemplarul pe care il detin. Totusi, ce am primit este schema unei versiuni pe care nu am vazut-o niciodata in "liberate", cel mai probabil este a unui prototip folosit de producator in evaluarea preliminara. 

Cu toate acestea, diferentele nu sunt intr-atat de mari ca sa justifice ignorarea ei.


De regula, descarcarile electrice afecteaza sectiunea intre conectorul de intrare P1 si C33.

Zilele trecute, un amic radioamator m-a rugat sa ma ocup de trx-ul sau ce a trecut printr-un astfel de eveniment, astfel ca pot ilustra cu imagini cum arata efectele unei descarcari electrice asupra transceiverului lasat conectat la un sistem de antene neprotejat.

La prima vedere, elementele de protectie au decis ca sunt depasite de eveniment...

Aparent, cineva a incercat sa intervina pentru remedierea efectelor, fiind vizibile urme de ceea ce pare a fi flux insa, la incercarea de curatare cu alcool izopropilic, componentele, pur si simplu, s-au dezintegrat! De fapt, acela era "fumul magic" condensat pe PCB.

Schema prevede un circuit filtru de banda format de L12, L13 si condensatoarele aferente, ce nu este insa prezent pe echiparea de PCB din versiunea aflata pe masa.

Dupa curatarea PCB-ului si eliminarea componentelor distruse fizic (GDT, Q13, D4, D40, U31), a fost posibila verificarea celorlaltor componente, rezultand ca si R18 si U32 sunt neconforme.

Pentru remediere au fost comandate componentele necesare; D4, D40 - CDSOD323-T03C (original: GBLC03I) , Q13 - DTC114A, GDT- LittleFuse SG75, U31 si U32 - AS179-92LF (original in circuit).

Cu privire la acest circuit de comutare, el este destinat utilizarii de la 20 MHz la 4 GHz; am incercat inlocuirea cu unul destinat frecventelor mai scazute, cu aceeasi topologie si compatibil ca amprenta (SKYA21001) insa  mi s-a parut ca aduce in receptor unele componente de intermodulatie! Ciudat si contraintuitiv dar ramane ca fenomenul sa fie explorat suplimentar cu alta ocazie.

Pentru GDT a fost nevoie de refacerea unui "pat" corespunzator sustinerii de curenti mari intrucat acesta este primul element de protectie, ce descarca curenti mari fiind importanta rezistenta circuitului in special pe traseul de GND.

Un pic de rasina cu intarire la UV a fost de folos aici:

Masurarea celor doua condensatoare, C28 si C174 a aratat ca sunt decalibrate, avand in jur de 2 nF!

Circuitul Q13-C174 este un circuit care pune la masa tensiunea reziduala de RF la emisie, blocand trecerea semnalului de nivel mare catre etajul de intrare.

Datorita vaporizarii traseului, am refacut circuitul "Manhattan style" cu imobilizarea mecanicacu ajutorul unei picaturi de epoxy sub condensatorul C174.

Dupa remedierea si refacerea circuitului, la testare a reiesit ca pinul central din conectorul UFL mama instalat pe sectiunea de coaxial care vine de la releul comutator Rx/Tx realizeaza contact imperfect pe conectorul notat pe PCB cu "Rx". Datorita deselor manipulari, in cele din urma a cedat si conectorul de pe PCB astfel ca am ales sa il conectez direct, fara conector UFL.

Am verificat si functionarea filtrelor trece-banda din etajul de receptie si acestea functioneaza corect.

Reparatia a fost un succes si un QSO m-a convins de asta.

Pe langa aceste probleme am descoperit ca mufa RJ45 de la microfon sufera de binecunoscuta problema a ruperii din PCB astfel ca, daca tot era pe aici statia, am zis sa rezolv si problema asta. Din pacate, microscopul abia a sosit de dimineata si am gresit undeva astfel ca nu a capturat imaginile cu acea parte. Nu a fost simplu, reparatia a fost facuta "in situ", fara a scoate PCB-ul din sasiul panoului frontal intrucat mastile butoanelor sunt lipite cu superglue, din fabrica, de axele encoderelor! Nu e prima statie la reparat care are aceasta caracteristica si solutia este taierea mastilor pentru inlocuirea encoderelor. Nu merita aplicata solutia in acest caz asa ca repararea mufei a fost destul de complicata dar a reusit pana la urma!

Termistorul etajului final era, de asemeni problema cunoscuta,  la distanta de tranzistorul final; si aceasta problema a fost rezolvata, preventiv.








28 noiembrie 2024

433 MHz LoRa SAW Bandpass Filter

 The LoRa network that a team of radio amateurs in Bucharest is testing is - for various reasons - deployed in the 433 MHz ISM band.
A check of the radio spectrum showed that in this band there is a rather high level of noise generated by the multitude of competing networks in the 380 - 500 MHz band, most of them transmitting with high power.
These contribute to an increased noise level which in turn affects the signal to noise ratio of the receiver (usually SX1273).

 According to the SX127x datasheet:

"SX1272/73 Is a half-duplex, low-IF transceiver. Here the received RF signal is first amplified by the LNA. The LNA input is single ended to minimize the external BoM and for ease of design. Following the LNA output, the conversion to differential is made to improve the second order linearity and harmonic rejection. The signal is then down-converted to in-phase and quadrature (I&Q) components at the intermediate frequency (IF) by the mixer stage. A pair of sigma delta ADCs then perform data conversion, with all subsequent signal processing and demodulation performed in the digital domain. The digital state machine also controls the automatic frequency correction (AFC), received signal strength indicator (RSSI) and automatic gain control (AGC). It also features the higher-level packet and protocol level functionality of the top level sequencer (TLS)".

Although the circuit has been designed with interference rejection (IMD) in mind and the modulation itself is designed to ensure communication in environments with radio-frequency pollution and high signal-to-noise ratios, any noise reduction before being processed in the input stages is beneficial.

Filtering signals outside the operating frequency range is, however, a costly process in which a number of compromises have to be adopted.

Although the circuit has been designed with interference rejection (IMD) in mind and the modulation itself is designed to ensure communication in environments with radio-frequency pollution and high signal-to-noise ratios, any noise reduction before being processed in the input stages is beneficial.

Filtering signals outside the operating frequency range is, however, a costly process in which a number of compromises have to be adopted.
Their advantage is the narrow passband and the disadvantage is the insertion attenuation.
There are a number of such filters available for purchase from manufacturers in China but the overwhelming majority of them are realized with 40 MHz bandwidth (@-3db) filters, which allow signals in the 436-440 frequency range, where the output signals of amateur radio repeaters are found, to pass at increased levels.
At least in Bucharest, one of them is in DMR system and emits with increased power of several tens of W, which has the ability to contribute significantly to S/N degradation.

 

 

Another issue noticed was a poor PCB design on which these SAW filters are installed to become a usable product in the shack.



These filters must also ensure a considerable rejection of the transmitting stations of mobile phone network transmitters in the 800 MHz - 1 GHz band.
A look at the way the wiring on which the SAW filter is placed suggests a number of design problems that degrade its performance.
Because I'm a speedy ham, I thought I'd make my own filter, with much better performance than those available at online stores.

So, I started reviewing the range of SAW filters available from reputable manufacturers and settled on Qualcomm.

And after a "painful" and lengthy selection process I settled on a number of three filters that could be a much better solution than the existing ones, for the purpose I proposed.

One of them is  B39431B3735H110.

Now, on the PCB, the manufacturer is giving us some hints about how the PCB must be designed to get the most of what the manufacturer's specs:

"Minimising the crosstalk
For a good ultimate rejection a low crosstalk is necessary. Low crosstalk can be realised with a good
RF layout. The major crosstalk mechanism is caused by the “ground-loop” problem.
Grounding loops are created if input-and output transducer GND are connected on the top-side of
the PCB and fed to the system grounding plane by a common via hole. To avoid the common
ground path, the ground pin of the input- and output transducer are fed to the system ground plane
(bottom PCB plane) by their own via hole. The transducers’ grounding pins should be isolated from
the upper grounding plane.
A common GND inductivity of 0.5 nH degrades the ultimate rejection (crosstalk) by 20 dB.
The optimised PCB layout, including matching network for transformation to 50 Ohm, is shown
here. In this PCB layout the grounding loops are minimised to realise good ultimate rejection".

 


Just compare this with the footprint of the cheap Chinese filters shown above...


And here they are, assembled:





And here are the masurements, taken with SatSaGen with Adalm Pluto as VNA with tracking generator:

 







18 octombrie 2024

LoRa APRS with Meshtastic DevBoard

After I played a little with my Meshtastic Development Board I previously made (and write about) I decided it will be nice to give it a try into LoRa APRS.

This raise some issues about how different modules are connected to the GPIO's of the ESP32 in my configuration.

I was directed by some early adopters in Romania to the CA2RXU web flasher where I found that the Tracker FW can be loaded into a pretty good selection of boards.


But, what board from those would be compatible with my one? Hmmm.... this would require some research!

First, I had to go to CA2RXU's excellent repository and find some clues about pin mapping; how the LoRa transceiver is connected to the ESP32 on various boards in order to choose the proper version of the already compiled FW from the web flasher tool...

Yes, I could compiled it myself but, apart from being a brave ham, I like to cut corners because I'm a lazy one!

Using the already compiled FW will be a good "investment" because I can keep up with the future versions without going to the compiling process everytime a newer version is released.

Flashing the LoRa APRS I-Gate was easy and I already had one working on my bench but the tracker is a different animal because it needs the GPS input to really be usefull as a "tracker"!

So, I land onto the GitHub page of the project and searched for anything that could hint to my problem. Soon I found boards_pinout.h where various ready-made boards are described.

LoRa module is tied to the ESP32 using this diagram:

MISO > D19

MOSI > D27

NSS/CS > D18

SCK > D5

RST > D23

DIO0 > D26

so I searched for this particular definition.

I found two of them that could suit my needs.

First was the TTGO T-Beam family that catched my eye. Almost all of them have the LoRa transcever connected as I needed.

The main problem with the newer versions of the BOARD (!!!) have the battery management circuit APX192 and this is used for informations about the battery voltage.

 


Well, my board is reading the voltage with ESP32's ADC so, using the firmware could cause some problems. Or not. I don't want (yet) to explore the full code to see how APX192 is integrated into the workflow therefore I choose an early version, of T-Beam FW, the 0.7.

 
I connected the GPS Tx to GPIO 12 as defined into the code but, to my surprise, a message on the small LCD told me that there is no GPS data incoming.
Scratched my head a few hours... Everything was right on the HW side but no GPS valid frames and a suggestion to reset it. Well, that was not an option because I was sure my GPS junk was OK because I previously tested on Meshtastic and it performed like expected!

Left the things like that at around 2AM and next morning I was eager to see the schematic of the TTGO TBeam 0.7... Where the heck that GPS Tx was tied to ESP32?
The schematic is hard to find but a picture of the board told the whole story!
The GPS Tx was connected to GPIO 34!!!

Well well, you little TBeam prick, gotcha! I connected the GPS Tx to GPIO 34 and, voila! that message dissapeared and soon a fix was achieved!

Looking into the code I saw that another board had the same pinout definitions on LoRa TRX with some minor variations.

OK, so, what else do I need to look for? 
The Battery ADC..
 
Most of them are at GPIO 35 which is the same as my dev board so, "cheked".
 
Button? 
Well, I might be a nice feature but I think I can use the tracker without it after I tested the programming interface (web based) -most of them are on GPIO's that are not available on my board...

So? I think we are good with GPS and LoRa Trx working properly!

The next step was to play a little bit with the firmware for other boards and found one that fits well:
TTGO_T_LORA32 V2.1
 
 
 
The blue LED connected to GPIO 15 is there to show me when the tracker is transmitting because I intend to use it without the OLED display; that was just to see how the things works..
 
The battery voltage is not correct, it should indicate 4.2V but this is due to the voltage divider that have different resistors than the TBeam original board for which the FW was written. Yeah, Yeah, I know, I can change the ratio by replacing one resistor... I will think about it, I promise!
 

 
73!
 


Most viewed posts in last 30 days