"My SD card is not detected by the Marauder"

 When using Marauder, an SD card it's a must.

Unfortunately, the smallest SDcards i have are no less than 64GB so, according to the author, it will not work.

 

Not so fast, mate!

See? 

 

Where there is a will, there is a way! After all, I am a "brave ham"!

Here is how was done. Attention, instruction follows, mind the gap....

|   |  

Open CMD in Administrator Mode. (Windows key and type CMD then select in the right side of the  folding whatever-is-that-called "Run in Administrator").  This was in Red and Bold because I consider it very important. Also because those below will not work otherwise.

Then, following commands:

        diskpart

        list disk 

Search for your 64 GB (or 128 GB) SD card "disk".  An SD card of  64GB will be shown as "Disk 2 58 GB".

 Note the number of the disk; be aware, usually the Disk 0 has your precious Windows!

       select disk # ( where # is your number).

Now, you will have "Disk # selected" and write:

        clean

        create partition primary

 You can then try 

        format fs=fat32 quick

        assign

        exit

but most probably, you will get an error after "create partition primary", something like "virtual disk service error: the volume size is too big".

Don't worry! 

If so, go download an old piece of software from Ridgecrop,  called fat32format.exe.

Yeah, it's a ugly scary EXE!

Extract it and save it in a well lit place easy to reach it. I save it on C to look like this:

     C:\ fat32format.exe

Good.

 

At this point, the SD card should be listed, but inacessible in Explorer.

Note down the letter under the SD card is hiding.

Open (again), the CMD, also in Adminstrator mode.

Write this:

     C:\fat32format.exe E:

(where E: is how my SD card was listed in Explorer).

After some babble on the screen, the SD card will be as new as a newborn, in FAT32, ready to be thrown in Marauder.

 

That's all folks! 

 

 

A GNSS Disciplined CTCSS, DCS and DTMF generator based on ESP32

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!

Industry standard in CTCSS require precision of less than 1% (typically 0.5%), so I needed a laboratory instrument to validate the decoder results.

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!

Most receivers provide a pulse-type signal with a duration of about 100 msec, every second, with the precision imposed by the GNSS signal, which in turn is provided by atomic clock sources.

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: 

 

 

 SINE 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

Debugging ESP32 Timer Interrupts: A Tale of API Compatibility

 

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:

1. A web interface for controlling tone parameters (frequency, level, on/off)

2. WebSockets for real-time communication

3. A timer interrupt running at 10 kHz to drive the DAC output

4. 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!