Software
Wrong UDP port / bug in EspDrv.cpp
splitFlapMaster: loop(): Udp.port(): The UDP port is not correct for the first UDP packet. The first digit of the port is lost. This is a known bug in EspDrv.cpp. Just deactivate line 685 with two comment dashes
UTF fuckup
splitFlapMaster/splitFlapUnit: String() class is not really working with UTF. String().length() will amount of bytes and not the string length! Also String().substring() will give you back only bytes and not whole UTF characters. To overcome this issue, I converted all UTF strings to bytes, process them (e.g. transfer via I2C) and parse them to UTF strings on the other side.
Overheating of stepper
One critical thing is, that the stepper may overheat if it is rotating too long. To avoid overheating, I first implemented some code to avoid continous rotating. However, this thing is so critical, that I decided to solve this conceptional. A thermistor is mounted directly on the top side of the stepper to recognize overheating. In the case of a too high temperature, the stepper is shut down.
Electronics
ESP8266/01 Baudrate
In my setup I had many transmissions errors in the serial connection between ESP and Arduino with the default baudrate of 115k. So I changed the default baudrate to 9600:
- Connect your ESP to your power source and your Arduino: (VCC and CH_PD to 3.3V and GND to GND, TX, RX)
- Connect VIN of your Arduino to 5V GND to GND and the RST pin also to GND. This will set your Arduino to the USB-Serial-Bridge mode
- Open a Serial monitor, select the corresponding USB port. Set your baudrate to 115k. Set mode to NL (new line) and CR (carrier return). Type “AT” and press return. If you get an “OK”, the connection is fine
- Set the default baudrate to 9600 by the following command: “AT+UART_DEF=9600,8,1,0,0”
- Change the baudrate of your serial monitor to 9600 an type in again “AT”. If you get an “OK” the baudrate of your ESP is succesfully set to 9600.
I2C interference
After the first long term tests (several hours & days), I observed that the Arduino froze after some time (sometimes after minutes, sometime after hours; with increasing amount of units decreasing time to freeze). After hours of debugging I came to the conclusion that it has something to do with the I2C communication. One of the slaves seemed to pull down SDA infinitely. However I had no oszilloscope to analyze the signal. A good reasion to buy one ;-.). That’s what I saw:

The heavy intereference came from my fine chinese power supply. To get rid of that interference, I applied a 100nF capacity between V+ (12V) and GND.

Much better but still some intereference (which seems to come from the DC-DC of the master). So I put another 100 nF between V+ (5V) and GND.

Nice! But what’s not so nice is the time constant of the SDA & SCL signal. It seemed that the capacity of my 20 units display is a bit too high for the 4.7k pull-up resistor, so I installed a 2k.

Fine! That’s how it should look like.