The Favero Full Arm scoring machines use serial data output that can be interpreted through an Arduino and then used to send data signals for ws2812b LED lights for strip repeater lights. This should work for the FA-01, FA-05, and FA-07. I tested this with a FA-07.
This uses one esp8266 Wemos D1 mini per fencing strip, and one LED object for each fencer (left and right). The hardware is assembled as shown in the basic diagram. This is a basic overview of how it works through a breadboard. I recommend using a protoboard/perfboard/pcb for real applications. Some people swear online to put a resistor between the data pin on the LED strip and the microcontroller, but I found my setup worked fine without it. The full setup includes this resistor, but it may not be required for you. The full setup also includes the power injection points I am using to ensure my LEDs are able to draw enough power.
- Two ws2812b RGB LED strips and knowing how many total LEDs in each strip to change line 10 in Wemos_Favero_Serial_Parser.ino.
- Power source for the RGB LED strips and microcontroller (not covered here)
- A 100 ohm resistor
- A favero full arm scoring machine with a rj-11 serial port on the back.
- A microcontroller: I am using a esp8266 Wemo D1 mini in this example (specifically ESP8266 ESP-12 ESP-12F NodeMcu Mini D1 Module WeMos Lua 4M Bytes WLAN WiFi Internet Development Board)
- An RJ11 cable to connect from your Favero scoring machine to your microcontroller. An easy option is to use a RJ11 breakout such as this.
The section in the diagram shows what is required from the microcontroller to the Favero scoring machine.
- Plug one end of an RJ-11 cable into the Favero Full-Arm scoring machine serial port on the back: FA-01, FA-05, or FA-07.
- Wemo 3.3V pin to Favero RJ-11 pin 3 (R).
- Wemo RX pin to Favero RJ-11 pin 4 (G).
- Wemo GND pin to Favero RJ-11 pin 5 (Y).
- There must be a 100 Ohm resistor in between the Favero scoring machine and GND (no other devices need the 100 ohm resistor).
- The GND pin on the Wemo will also need to be connected to your LED strips and their power source ground as well. A common ground between all the components is required.
- Connect the "left fencer" LED strip data to D2 (pin 4) (fencer on the left / FOTL) on the Wemo.
- Connect the "right fencer" LED strip data to D1 (pin 5) (fencer on the right / FOTR) on the Wemo.
- The GND pins will need to be connected on the same rail to your power source, LED strip, the scoring machine, and the Wemo's ground pin. A 100 ohm resistor is required from GND to the Favera FA scoring machine RJ-11 pin 3 (no other devices). A common ground between all the components is required.
- Connect your 5v/12v/24v or whatever power source you have to each LED strip for their power. If you need help figuring out how to power your LEDs, https://quinled.info/ is a fantastic resource.
- Edit line 10 of Wemos_Favero_Serial_Parser.ino to the total number of LEDs (applies to both fencers).
- Edit line 46 of Wemos_Favero_Serial_Parser.ino to the power draw you want. This will have FastLED tell the LED strips to only draw a maximum power draw to prevent your LEDs from going out, and set the amps to an appropriate amount.
FastLED.setMaxPowerInVoltsAndMilliamps(5, 2000)- Where5is 5 volts, and2000is 2000 milliamps (2 amps). This applies to the total output FastLED will allow to be output.
Credit for this chart goes to @Gioee: https://github.com/Gioee/fav3er0-master-emulator
| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|---|---|---|---|---|---|---|---|---|---|---|
| Example | 0xFF | 0x06 | 0x12 | 0x56 | 0x02 | 0x14 | 0x0A | 0x00 | 0x38 | 0xC5 |
| Explanation | This Byte identifies the beginning of the string, it has to be always 0xFF | Right score, in this case 6 | Left score, in this case 12 | Seconds, in this case 56 | Minutes, in this case 2 | State of the lamps, case 0b00000000 no lamp is activated, case 0b00111111 every lamp is activated | Number of matches and priorite signals | Always 0x00 | Red and yellow penalty cards | Checksum = Sum of previous Bytes % 256 |
- 6° byte: XXh = Define the state of the lamps (red, green, whites and yellows). Every bit defines the state of a lamp (zero=OFF, 1=ON). Following is the correspondence of the 8 bits:
- Bit D0 = Left white lamp
- Bit D1 = Right white lamp
- Bit D2 = RED lamp (left)
- Bit D3 = GREEN lamp (right)
- Bit D4 = Right yellow lamp
- Bit D5 = Left yellow lamp
- Bit D6 = 0 not used
- Bit D7 = 0 not used
- Example: if byte 6° = 14h , we have D2=1 (red light=on) and D4=1 (right yellow light=on)
- Credit to /u/Dalboz989 on Reddit: https://www.reddit.com/r/Fencing/comments/cufcku/do_anyone_know_where_to_find_those_lightings_and/ey15ezm/
- The code is set to only send signals for the appropriate color for left (red) and right (green) fencers and white for off-target. If the colors are mismatched such as green and red on the opposite sides, then move your led strip or swap the data pin connections. You can also ensure your LED strips are truly RGB, or GRB and edit that in line 44 and 45 in Wemos_Favero_Serial_Parser.ino. If you are getting some other color like a blue or a unexpected white, its most likely your LED configuration that is causing the issue. There is a lot of knowledge that you need to know that comes with LED strips (that I hadn't known before this project), such as the power injection or wire gauge for voltage drop off. The site https://quinled.info/ is a fantastic resource for determing your LED strip power usage, and how to get the best results out of your LEDs. Be sure to watch some of the videos on their website or Youtube channel.
- This is caused by noise somewhere. My tests were usually the LED data pin causing the noise. I couldn't figure out how to stop it so I added the checksum verification to the serial parser for the microcontroller. The microcontroller will only accept messages from the scoring machine if the checksum matches to prevent corrupted data. In my testing with the checksum verification, I have never seen corrupted data hit the LED strips and turn on a light when a light has not been turned on. Without the checksum verification, electrical noise will send junk data to the serial port and the microcontroller may read a bit as having a light turned on therefore causing the LED strip to turn on a light when the scoring machine does not have that light turned on.
There is a small delay in the lights when two fencers don't make a touch at the same exact time, but both lights come on.
- Your guess is as good as mine as to why this occurs. Could be noise causing the serial message to be thrown out so often it causes a delay. This delay DOES occurr on the official Favero repeater I tested with.
If you have any improvements, please open a pull request. I am definitely not doing some stuff the most optimal way and I would greatly appreciate any additions.
Credit for the serial parsing came from @BenKohn2004: https://github.com/BenKohn2004/Favero_Overlay
Credit for discovering the checksum verification that is used goes to @Gioee: https://github.com/Gioee/fav3er0-master-emulator