Perhaps a bad decision!

[pickles-n-beany]

Hiya!

I've started noting down the parts for this and starting to build it myself. I've contacted Vyruz, but just incase you see a copy of what you are doing appear, its only that I may need to fork it.

I also am still trying to work out how to do this! I've only done little arduinos before but I am part of a little Scottish flyball team and have told them Im going to do my best to replicate this ETS!

So hello!

[simonttp78]

Hi,
I recently moved this project to "maintenance" mode due to low (almost no) community contribution. However, I’m still happy to help with replicating the solution.

My fork has evolved quite a lot from what Alex originally created, but the core principles remain very similar. The housing can be adjusted to your needs (e.g., depending on the number of sensors).

In my version, I added a serial shift register to free up some ESP32 pins (just to clarify: the Arduino Mini was only used in a prototype— the final solution uses an ESP32 LoLin32). I also connected an SD card using a simple 1:1 pin mapping in MMC mode.

You can use either NPN or PNP sensors (I’m currently using PNP), but be careful with the LCD. There are Type A and Type B displays (with different data line pinouts), and this is not always clearly indicated.

Let me know if you need any further support!

[Gruni22]

Hi,
I also built a Flyball-ETS several years ago.
Because of some troubles I decided to get rid of the remote control and switched to the ESP32 using WIFI only.

I have the issue, that the light barriers do not indicate clear crossings.
Do you have any idea? Did you change something on the circuit?

I wired them like sketched in the Flyball-ETS/Hardware.

I could also provide some logs if necessary.

The lights are also still the old version using a shift register.

[simonttp78]

es, the remote is not working in a very reliable way, however, there are still situations where it’s useful.
To release the pins for the SD card, I’m using a 74HC166 shift register. It seems that while cleaning up the code before switching to 'maintenance' mode, I accidentally removed all the comments. I’ll restore them, focusing on the pin descriptions in main.cpp and the .h file.

I designed the hardware from scratch. Let me check Alex’s v4.0 hardware (found it in the feature/ESP32 branch)...
It seems Alex switched to PNP sensors. My design is flexible and ready for both NPN and PNP, although I’m also using PNP.

For the red LEDs indicating beam break, I calculated 1kΩ resistors for the PNP configuration, not 500Ω like in version 4.
As a voltage level shifter for the sensor signal (~12V while the ESP32 needs 3.3V), version 4 uses a resistor-based voltage divider: 1kΩ to 330Ω.

For PNP sensors, I'm using a voltage level shifter based on a 2N7000 MOSFET:

For NPN sensors, the signaling LEDs use 330Ω resistors, and the voltage level shifter is based on a BC557 transistor:

I also recall that in version 4, there was a mistake related to the GPS module connection:
GPS RX → GPIO36 / VP
GPS TX → GPIO39 / VN
The issue is that these pins are input-only, and configuring GPIO39 as an output will cause crashes with the newer espressif32 versions.
This is why I'm using GPIO39 for the GPS module's PPS line (input), and GPSTX is now connected to GPIO22.

I believe these are essential changes (not to mention SD card support) in terms of overall sketch compilation and handling sensor signal lines.

In my sketch, I have completely removed the legacy light system that relied on a shift register, so you would need to re-implement it if you wish to use my code.

Regarding the main race processing algorithm, the situation is much more complex. At a high level, I reused Alex’s concept of reacting to beam interruptions and the A/B/a/b string approach. However, the entire algorithm has been redesigned from scratch.
So, if the source of your issue lies in the race logic, I’m afraid I won’t be able to help directly. I would recommend forking my fork 🙂, updating the pin mapping where necessary, and reintroducing the shift register-based lights. That shouldn’t be too difficult.

By using my algorithm, you’ll benefit not only from additional noise filtering functions but also from the ability to configure the number of racing dogs (not limited to 4), and whether or not re-runs are required.

For “unmeasurable” passes/crossings, my code uses 4 indicators:
ok – still not great
OK – good, clean crossing
Ok – very good (e.g., “invisible dog” scenario)
Perfect – extremely tight passing (<5ms)

My sketch also uses multithreading, so the delay between the start of race timing and light activation has been minimized.

UPDATE:
It may be worth mentioning that I'm using an external LDO to generate the 3.3V line from 5V, rather than relying on the onboard LDO of the ESP32 (LoLin32) board.
The LCD control signals are connected directly to the ESP32, even though the LCD is powered by a 5V supply. The 3.3V control signals from the ESP32 work perfectly fine with the LCD, even if it's not the most ideal solution.

For the Remote, which is powered from the 5V line, I’m using resistor-based voltage dividers (1kΩ / 1.8kΩ) to convert the 5V signals from the Remote receiver to 3.3V inputs for the 74HC166. This would be also relevant for direct remote receiver connection the ESP32.