Baofeng DM-32 desktop "charger" isn't a proper charger but a desktop stand with a charging indicator.
The charging circuit is built into the battery and powered by a 5V/1A power supply.
Inside the desktop stand is a detection circuit that change the colour of a dual-colour LED based on a LM358 dual op-amp configured as a comparator.
Here is the schematic:
Let me present a project to both show off and because it might be useful to others, a GNSS disciplined CTCSSDCS and DTMF generator.
Why? How?
This is the "bottom of the well" (from "out of the frying pan into the fire") because I initially started with a repeater controller (also ESP32 based), to which I wanted to add CTCSS/DCS/DTMF detection and generation (DSP based over ESP32 - still work in progress).
After creating the detector (based on DSP on the ESP32 dual-core platform), I found that I had no means at hand to verify the accuracy of the detection!
So, after a brainstorming session with myself, the solution emerged from smoke and beer - a GPS-disciplined oscillator. Twenty years ago, this would have been difficult to implement, requiring far too much effort on the hardware side and at a prohibitive cost.
Hey, but now we have very capable development boards, with the very board I was developing the repeater on sitting on my desk. The same one I was developing the decoder on...
Well, I thought, why not a signal generator disciplined with a GNSS PPS signal?
Signal generation, sinusoidal (well, approximately), would fall to one of the two DACs available on the ESP32 platform.
I consulted with ChatGPT to check if the ESP32
performance allows implementing such a generator and if it's possible to use a
WEB interface for control (GUI) to get rid of HW accessories like encoders,
buttons, display, etc...
The "debates" were interesting and helped me crystallize the development direction of the project. It's really good to have "matches" with this artificial intelligence, it can help you put your thoughts in order when you go off track!
Getting to Work!
However, I shifted the difficulties from hardware to software. During development, I encountered a phenomenon similar to the wave-particle duality, namely, "observing" the ESP32 software oscillator introduced completely random and impossible-to-compensate errors.
The most sensitive processing is made in ISR functions and observing what was happening inside them was sometimes pretty delicate. In other points, introducing Serial Debugging lines delayed the execution of some other delicate functions.
Signal generation is a time-based thing and calculations of the time in the ISR was simply impossible, delaying the execution and producing malformed wave-forms. Calculations made outside were simply, lacked on precision even using dinamically calculated correction factor.
For those understanding this aspect, the solution was seemingly simple but drained my energy for about two days (summer days, until evening).
Instead of time-difference-based measurements, the timers were based on cycle counting and these were used as references. For an engineer probably this was the right choise from the beginning but for me, as a full-time lawyer, this was a real milestone.
I'll close this overly-extended technical parenthesis.
Similarly, I won't go into boring details about disciplining the software DDS
based on the pulse received from the GPS receiver, but I'll present a few
aspects, as I'm proud of them!
The "disciplining" algorithm works like this: the timer that forms the basis of signal generation provides one pulse per cycle; at each pulse received from the GNSS receiver, the theoretically calculated value is compared with the practical value. From the difference, a correction factor is calculated which is then applied.
It seems simple, but in this algorithm, there are a series of self-adaptive functions that ensure that changes are progressive, applied at zero crossings, and other such interesting tricks, discovered through repeated wall-hitting during the project...
The Nail in the Shoe
I spent a healthy number of hours on a series of problems whose cause I couldn't identify and which kept the process stalled.
The paradox: compilation ran without any problem, but the functionality of the code was non-existent in certain absolutely necessary processes!
An INTerrupt refused to trigger... Just like that, as stubborn spoiled kid! I spent two days trying to understand what was happening and was even thinking I was approaching the third day (when if the problem doesn't solve itself, projects must be abandoned)!
I already write about this stupid moment in my life...After reverting to an "outdated" version, I overcame the first major hurdle.
Verification
It wasn't as simple as it seems, but at some point, the signals started to be visible on the oscilloscope, and another question emerged from the fog and beer: How the heck do I objectively verify what comes out of the DACs?
The solution, again elegant (I think), was comparing a derived reference (brutally square) from the GPS signal but with high frequency (5KHz) with the signals generated by the DAC and with the signal from the GPS using a multichannel oscilloscope.
And the result... mmmm, the result was exceptional and encouraging, with deviations beyond the observation limit, within the signal noise limits!
The heat kept me away from the journey to the laboratory where I have more sophisticated equipment, but for something done "on the table," I'm more than satisfied.
DCS Signal:
Web Interface
The eye must also be satisfied somehow, and here I heavily involved Artificial Intelligence because, on one hand, I don't master the domain, and on the other hand, the complexity of the graphical interface (GUI) and the Front-end (the code executed in the browser, which communicates with the Back-end - the actual program in the ESP32) requires coordinated interventions in many parts of code. Exactly what AI is good for! Except that sometimes it hallucinates!
Seriously, AI, I discovered, hallucinates, which is why it often ruined what I had laboriously built. An opportunity for it to learn some genuine Romanian curses, the kind Păcală would say to make the Devil's eyes pop out of his head!
In the end, from the confrontation, I emerged a little more knowledgeable in these aspects and at least can give the LLM (Large Language Model - AI that is) very precise instructions, which keep it awake and from which I can get what I want!
I tried to make the interface as simple to use as possible, like a laboratory device - which is what this project actually is - but also easy to use for anyone who wants to transform an ESP32 into a CTCSS/DCS/DTMF signal source for various projects.
The usage is intuitive, and there may still be some bugs; "the master's eye fattens the calf," so it's hard for me to discover them myself, it remains for users to shout out what's not OK here and there.
In principle, the user interface reflects the internal architecture:
It's divided into logically organized sections that provide control and feedback... what more can I tell you?
It also has an interface for uploading files necessary for the graphical interface; anyone who wants can make their own interface!
You have no idea how much I struggled to make batch file uploading work! It was murder to keep uploading them one by one!
A Few Words About Performance:
- Accuracy in generating CTCSS and DCS signals, better than 1% (I'd say better than 0.5%) but I don't want to boast too much!
- I also attached a tone generator with frequency between 40 Hz and 1.2 KHz, but above 900 Hz the signal begins to degrade due to digital-to-analog converter limitations.
- DAC1 and DAC2 signal level:
* max 2.35 Vpp.
* med: 1.6 Vpp.
* min: 850 mVpp.
- 0-3V logic signal outputs for various signals, also disciplined with GNSS.
Laboratory Integration
For the project to become a laboratory equipment, it's useful to connect a GNSS module that has visibility to the sky. The code doesn't use any other information transmitted by this module except PPS, so a connector with 3 wires can do the job just fine.
Even in the absence of the GNSS receiver, the precision is quite high, demonstrated by observing the correction factor applied following the 1PPS signal; this was a surprise because I expected larger errors but it seems that the architecture and non-blocking code it helps a lot.
Regarding the signal in the analog domain, i.e., the outputs, minimal filtering on each of the two outputs could improve signal quality by reducing possible artifacts produced by digital generation. Although there is a digital "volume" on each of the two DACs, it would be useful to have potentiometers for fine adjustment of the level to the DUT (the equipment benefiting from the signal).
A low-pass filter for frequencies below 1 KHz for DAC 1 and one with a limit at 2 KHz for DAC 2 would be welcome; in their absence, at least a network of 1 Kohm and a capacitor of about 1 nF to ground could reduce artifacts at the cost of some loss from the useful signal.
The generator can be integrated into the existing WiFi network or can generate its own Access Point.
See? Have you forgotten what it started from?
Yes, I forgot too; I needed something that would very precisely generate a CTCSS tone...
I'll leave you a link to the GitHub page of theproject where you can find it already compiled, so you don't have to bother with the necessary libraries:
OK, so the project was completed at the cost of a few sleepless nights.
While searching for a board to mount the potentiometers to unify the two audio channels, I found at the bottom of one of the many boxes that accumulate with "you might need it someday" a board with an FX365 circuit, CTCSS Decoder/Encoder. Life has mysterious ways of pulling the rug out from under you!
Oh, well... Sometimes life sucks!
Anyway, for me was a real technical journey into some unknown territories and I am really happy I could see it working at the end. After all, we are hams for this kind of exploration into "hic sunt leones", uncharted areas of technology...
Feel free to test and drop a comment if you liked or not and if you have suggestions but keep in mind this is a tool for a small lab with the main scope of generating a precise frequency to help the tests of a CTCSS/DCS/DTMF decoder for a ham radio repeater... :-)
73 from Adrian, YO3HJV
The Silent Signal Generator
Have you ever spent hours debugging code that should work but doesn't? Recently, I faced this exact challenge with an ESP32-based signal generator project. The symptoms were perplexing: all configuration parameters were correctly set, the web interface was working flawlessly, but the CTCSS tone output was completely silent. The culprit?
A timer interrupt that refused to fire...
The Setup
The project uses an ESP32 to generate precise CTCSS (Continuous Tone-Coded Squelch System) tones for radio applications with a GPS to "discipline" the time for 0.5% or less accuracy.
Yeah! Overkill, I know, but the architecture is straightforward:
A web interface for controlling tone parameters (frequency, level, on/off)
WebSockets for real-time communication
A timer interrupt running at 10 kHz to drive the DAC output
Direct Digital Synthesis (DDS) with a sine lookup table for waveform generation
Everything seemed perfect in theory, but in practice, the DAC remained stubbornly silent.
The Investigation: Hours of Head-Scratching
What followed were countless hours of frustrating debugging and head-scratching. I tried everything: different timer configurations, checking hardware connections, simplifying the code, even rewriting the interrupt handler from scratch. I attempted various approaches: minimizing critical sections to reduce conflicts with WebSockets, trying different timer frequencies, toggling GPIO pins to verify hardware functionality, and even considering direct register access to bypass the Arduino API entirely. Nothing worked. The timer stubbornly refused to fire its interrupt, and the oscilloscope showed a flat line where a beautiful sine wave should have been.
The extensive debug logged every aspect of the system and for no reason, the interrupt was silent.
At one point, my frustration reached such heights that I was ready to abandon the Arduino framework entirely and start learning Assembler or Machine Code just to manipulate the ESP32's DAC at the lowest possible level.
Anything to get that stubborn signal flowing! A pattern finally emerged: the timer was being initialized correctly (the code was compiling and running without errors), but the interrupt service routine (ISR) counter remained at zero. This meant the timer was configured but never actually firing its interrupt.
[DIRECT
DEBUG] Timer status check:
ISR counter value: 0
CTCSS
enabled: YES
CTCSS frequency: 100.00
Timer initialized: YES
The code was using the ESP32 Arduino Core 3.2.1, and the timer setup looked correct:
timer
= timerBegin(timerFreq);
timerAttachInterrupt(timer,
&onTimer);
timerAlarm(timer, alarmValue, autoReload,
reloadCount);
timerStart(timer);
The Breakthrough: API Version Matters
After multiple failed attempts to fix the issue within the 3.2.1 framework, I discovered something crucial: ESP32 Arduino Core versions have significantly different timer APIs.
The newer 3.2.1 version had simplified the API, removing critical parameters like timer number selection and edge-triggered interrupt options. These simplifications made the API easier to use but less powerful for specialized applications like precise signal generation.
The Solution: Strategic Downgrade
The solution was to downgrade to ESP32 Arduino Core 2.0.9, which offers a more comprehensive timer API. This allowed explicit control over:
1. Timer selection - Using Timer 1 to avoid conflicts with system functions
2. Edge-triggered interrupts - For more responsive and reliable timing
3. Precise prescaler settings - For accurate frequency generation
The updated code looked like this:
//
ESP32 Arduino Core 2.0.9 API with explicit timer number
int
timerNumber = 1; // Using timer 1 to avoid conflicts
uint16_t
prescaler = 80; // 80MHz / 80 = 1MHz timer frequency
timer =
timerBegin(timerNumber, prescaler, true); // true = count
up
timerAttachInterrupt(timer, &onTimer, true); // true = edge
triggered
uint32_t alarmValue = 1000000 / DDS_SAMPLE_RATE; //
100 ticks for 10kHz
timerAlarmWrite(timer, alarmValue, true); //
true = auto reload
timerAlarmEnable(timer);
The Results
The results were immediate and impressive:
[DIRECT
DEBUG] Timer status check:
ISR counter value: 2232839
CTCSS
enabled: YES
CTCSS frequency: 254.00
Timer initialized:
YES
[INFO] ISR count: 2240000, Time since last report: 1003
ms
[INFO] Actual interrupt frequency: 9970.09 Hz (expected: 10000
Hz)
[INFO] DAC output active: yes, CTCSS enabled: yes
The timer was now firing at approximately 9970-9980 Hz (within 0.3% of the target 10 kHz), and the oscilloscope confirmed a clean CTCSS signal output from the DAC.
Key Takeaways
1. API Compatibility Matters: Always check API compatibility when upgrading frameworks or libraries. What works in one version may not work in another, even if the code compiles without errors.
2. Explicit is Better than Implicit: When working with hardware-level features like timers, explicit control often yields better results than simplified APIs.
3. Effective Debugging: Implement counters and detailed logging to make invisible problems visible. The ISR counter was crucial in diagnosing this issue.
4. Sometimes Downgrading is Upgrading: Don't be afraid to use an older version if it offers functionality that better suits your specific needs.
Conclusion: From Frustration to Triumph
After hours of pulling my hair out (not quite) and questioning my sanity (and programming abilities - truly!), the solution turned out to be something I never would have guessed initially.
Those moments when you stare at perfectly valid code that simply won't work are some of the most frustrating in an amateur developer's life. Yet they're also the moments that teach us the most.
This experience reinforced an important lesson in embedded systems development: understanding the underlying hardware and API capabilities is just as important as writing correct code. Sometimes the most elegant solution isn't using the latest version, but rather the version that gives you the control you need.
The relief when seeing that ISR counter finally incrementing was indescribable. The ESP32 Signal Generator now produces perfect CTCSS tones with rock-solid timing, proving that with the right approach, even the most stubborn bugs can be conquered. The countless hours of head-scratching were ultimately worth it, not just for the working project, but for the deeper understanding gained along the way.
Have you encountered similar API compatibility issues in your projects? Share your experiences in the comments below!
Michael Rainey, cunoscut sub indicativul AA1TJ, este un cunoscut operator radioamator american, inginer și pasionat de homebrew minimalist.
Este celebru în comunitatea radioamatorilor pentru simplitatea și creativitatea sa radicală în proiectarea emițătoarelor - adesea construiește echipamente funcționale din cele mai puține piese posibile, folosind chiar circuite alimentate cu voce umană în unele proiecte.
Transmițătorul „El Silbo”, pe care l-a numit după limba fluierată Silbo Gomero din Insulele Canare, reflectă filozofia sa: comunicarea lipsit de complexitate - doar ingeniozitate.
Inspirat de ideea de simplitate și eficiență, acest transmițător utilizează un design minimalist pentru a transmite semnale de voce în bandă laterală dublă (DSB) pe frecvențe HF (în special, 80 de metri).
Michael a descris acest proiect într-un mod captivant, aproape poetic, descriind modul în care circuitul „șoptește prin eter” - la fel ca limba Silbo Gomero însăși...
Transmițătorul "El Silbo DSB" nu este doar o construcție tehnică — este un omagiu adus artei designului minimalist în radioamatorism.
Este un exemplu funcțional al modului în care un transmițător care utilizează doar câteva tranzistoare și componente pasive poate comunica în continuare semnale vocale în mod eficient, oferind:
El Silbo este un transmițător DSB (bandă laterală dublă) care funcționează pe banda de radioamatori de 80 de metri (~3,58 MHz).
Acesta utilizează:
Ce nu utilizează:
Puterea de ieșire tipică este de aproximativ 1,5 până la 2 miliwați, iar semnalul este compatibil cu receptoarele SSB standard, ceea ce îl face ideal pentru comunicații vocale ocazionale sau teste QRP.
Iată și detaliile - evident, Germanium:
A request from a fellow ham made me revisit an old project, and Arduino based repeater controller.
This lead to an iterative process to upgrade it from a simple Carrier Detect repeater to a more versatile one, that can use RSSI signal to activate the repeater. That's because the OM didn't have a Carrier Detect output on the radio that was available for his repeater.
In this version, the Mode can be selected by connecting a pin to the Ground) before the repeater is powered on.
Anti-kerchung was implemented for both Carrier detect and RSSI modes and in the later one, a hysteresis was defined.
Check it on Github for further explanations.
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 (108G), 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".
In ceea ce priveste G90 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 ma 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 (aparent) 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.
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:
