Hello Community,

Let me introduce you my latest vacation project! It's a code porting and PCB creation of an

electronic project originally designed and presented by Bertrand, aka EB (Electro-

Bidouilleur).

In 3 YouTube videos (the links are in the source code), Bertrand created and described a

“delicate” short-circuit probe based on an operational amplifier and a Microchip PIC12F683

microcontroller. The probes approach the cause of the short-circuit acoustically (rather

than visually). Detection of the short-circuited component or track is very precise using

Bertrand's approach.

So it was this that I had to reproduce and develop a suitable printed circuit board for

surface-mounted components. I also use an identical Teko package for several of my

assemblies. Here too, I was going to make a front panel in 1.5mm thick GFK black epoxy,

engraved and cut by a CNC milling machine.

For many years, I had been using Eagle software to design my printed circuit boards. It

was time for me to learn a new tool, in this case KiCad, to design my future assemblies. I'd

started learning KiCad by converting one of my documentary projects, PWM2Laser. One

of the reasons I didn't want to leave Eagle was the CAM tool developed by John

T.Johnson, PCB-Gcode, an ULP addon to Eagle which I used to produce the gcode files

needed to isolate per CNC the circuit boards.

In fact, when I was developing circuits, I often first produced a PCB prototype with the

CNC milling machine, using isolation passes. As I hadn't yet found a new CAM (and post-

processor for Mach3) for KiCad, I was naturally dragging my feet about converting to

KiCad. In the meantime, I discovered the LineGrinder software developed by Nic. I'm still

getting the hang of it, but it will certainly enable me to switch from Eagle to KiCad for milled

circuit boards.

Using KiCad a little more now as for my PCB single-sided board (although LineGrinder

does contain a function for making double-sided boards), I now had to make the step up to

a double-sided board with plated-through holes, to be produced by a PCB factory. The

idea was born to give Bertrand's project a PCB, and at the same time to port EB's initial C-

language code to a language I know better, BASIC!

Getting back to the tools I use for my microcontroller-based creations, I had been using

MikroElektronica's MikroBasic environment for several years. Since then, I've discovered

GCBASIC (with a top-notch support team), an open source environment dedicated to PIC

and AVR (8-bit) microcontrollers.

Let's combine the 2, KiCad and GCBASIC. I took the opportunity to replace the original

microcontroller used by EB, a PIC12F683, with a PIC16F1825. Why a PIC16F1825?

Because I still have quite a few in my drawers and it's in production at Microchip, so it's not

difficult or expensive to obtain. It also contains enough programming memory to support

the functionality of the short-circuit detection probe.

So, in addition to the probe's audible indications, I've also added a visual indication in the

form of a bar graph with 6 different-colored LEDs. You'll also find in my approach an

electronic part to manage the electronic power supply, as well as a charging module for

the electric battery. The board contains several test points, designed to be used as a

prototype and development board. Several soldering bridges allow optional use of certain

components, such as the battery charger or voltage regulator. For more information, take a

look at the KiCad schematic provided in the project file. The project was named SCC-2024

for Sonde de Court-Circuit (vacations 2024)!

You will certainly recognize in the diagram modules and functions designed by other

people in the community, perhaps even one of you currently reading this presentation. I've

been able to note and name the people whose references I've been able to find, but

unfortunately for some parts, such as the electrical interruption management and its push-

button management, I haven't been able to find its origin. If you know its designer, please

let me know.

So there you have it, the result of my vacation work is now available and shared with the

whole community. If you have any ideas for improvements, particularly to the code - in fact,

there's a routine (the LED display) that could well be revised in a way that's probably more

elegant than the one I've come up with (I'm not the specialist in algorithms) - you can use

my e-mail address to contact me. I'd be delighted to talk to you.

Following updates during project must be considered:

Now that I had a second SCC-2024 module assembled, I had to review the ADC data

calibration values for the battery voltage control measurements. During these

measurement operations, I became aware of a problem with excessive current

consumption from time to time when the buzzer stopped sounding.

In fact, I've recently been using a new laboratory power supply with a much more

comprehensive display than the one used at the start of the project. This highlighted

abnormal current consumption in particular situations. When the buzzer made a random

sound, the electronics consumed more current than normal. What could be causing this?

Let's take a look at how the buzzer is activated to emit sounds. The buzzer is alternately

powered by the microcontroller's interrupt management, at particular frequencies, simply

by changing the buzzer's control state from 0 to 1, from Off to On, each time the routine is

run. This electrical level switch generates the buzzer sound signal.

By exiting the interrupt routine in the PIC program, the buzzer control can be set to 0 or 1,

Off or On. And if, from that moment on, the buzzer was no longer to emit any sound, but its

control state remained at 1, I'll leave you to imagine the rest. What may seem obvious, but

was not in my mind at the time of re-coding Bertrand's program, is that I should have paid

attention to the output state of the buzzer command at the end of sound frequency

generation.

This has now been done, and version V1.2 of the software contains these associated

commands. I don't have much experience of the long-term use of buzzers, but what can

happen if a current (which is quite high, given its specifications) flows permanently through

the buzzer? To avoid any problems, I recommend replacing the previous code (if you've

already programmed it in your PIC) with this new V1.2 version.

Version V1.2 also contains new values for the battery voltage detection thresholds, and a

slightly adapted parameter for a better sound experience (constant BuzzerReloadDelaySet).

The battery voltage display routine has also been corrected. The value displayed was

compared to the last average value stored in EEPROM, and could be erroneous if the

difference was too great. You can find out more in the source code comments.

Thanks to everyone for making this project possible, especially Bertrand EB for his initial

idea and sharing, the GCBASIC team, especially Evan and Angel, the KiCad team, John

and Nic, and I'm sure I'm forgetting too many. Thanks to all of you! Until next time…