ESP8266-DevKitC RX Pullup problem?

ESPHome
1

I have a cute SP8266-DevKitC-02D-F module that I want to use for my heating regulation with this Project.

It seems that I have troubles getting good signal on the RX pin of the module. Without connecting the RX line, the Phototransistor gives good signal. But as soon as I wire this up to the RX-Pin of the module, the PT is unable to draw the line to a reasonable LOW signal. It just drops from 3.3V to 3.1V.

This looks like a rather low value internal pull up resistor that the PT can’t satisfy.

Unfortunately there is no ready “board” specification for this board, so I might just have picked a wrong template (esp_wroom_02) even this seems to be just a little older version with small hardware changes in the WIFI part but otherwise the same.

Does anyone know whether this module can get convinced to read the signal on the RX pin? Maybe with some kind of “power up” on the sensor side, adding a transistor that can drive the needed current?

  • Can the UART0 RX input configured on another pin without such an internal pull-up?

  • As far as I’ve seen, the OptoLink component does NEED to use the UART0 because of timing restrictions.

  • Did I buy the wrong module?

The example implementation uses a similar board with an identical(?) ESP8266 WROOM-02D modul, just as mine, so I would expect they behave similary. I even bought the same external components, that have been “verified working”.

2

The internal pull up resistors are approximately 56K Ohm for all ESP chips.

3

This might well be, but that does not mean that the “DevKitC” board that utilizes the module cannot interfer.

I bet it might be a conflict of the serial/usb controller that uses the same UART0.

I have seen there could be a possibility to use UART0_SWAP to map the signals to other pins, but I have just seen this for logging.

The Viessman Optolink component seems to insist using UART0 for the communication. Other than with the ESP32, the ESP8266 does not support the rx_pin: GPIO15 syntax.

I’m quite new to this topic - is it possible to configure UART0_SWAP by default and have all component communication on pins GPIO13 and 15?

I would think, that once this swap is defined, every command that utilizes UART0 will automatically use the new pins.

The logger however should stay put to not interfere with the module communication.

How would I configure that?

would

logger:
  hardware_uart: UART0_SWAP
  baud_rate: 0

force the component to happily use GPIO13 and 15 instead of rx and tx (3 and 1) and at the same time silence the serial logger?

4

I have the exact same problem with an ESP32-C3 and a photo-diode not able to drive the internal pullup on the rx-pin…at least in ESPHome!
When doing it in platform.io, I can disable the pullup after the uart.begin, and everything works as expected.
Conclusion: for whatever reason, enabling the uart, also enables the rx-pullup, which should at least be documented somewhere! as it is “not normal”.

Question is: how to disable the pullup in ESPHome? I tried the pin-schema with pullup: false, but without success.

Another: as another workaround, I connected the PD to a normal input (with external pullup) which I wanted to just mirror to a GPIO next to the uart-rx_pin, and just short them with a jumper. Again: works nicely in bare platform.io, but seems unfeasable in ESPHome. The binary sensor → GPIO Output loop seems way to “slow” to mirror even a slow 4800baud serial.

Any suggestions?

5

I meanwhile exchanged the circuit against a plain vanilla ESP32 board. This allows setting the UART to any free GPIO and thus frees me from the necessity to share the function with the on board serial chip. Should be possible with the 8266 too, but the OptoLink Software for ESPHome does not seem to successfully swap the pins when configured.

Once this was done, signal levels were good. The remaining problems turned out to be signal shape being bad and so was the timing.

I did the sensor part of my OptoLink interface like shown here: https://github.com/openv/openv/wiki/ESPHome-Optolink

I had to chose different components and settled with

Phototransistor: SFH 309 FA
IR-LED: OP265FAB (850nm)
LED resistor:150R
PT-Pullup: 5.5k

Since it’s 3.3V the 150R does not overload the LED.

You mentioned using a Photodiode, so your circuit certainly looks different than mine and you are certainly driving a switching transistor before the RX, as the current provided by the PD usually is quite low and has to be amplified to give a good digital signal.

Do you mind sharing your design?

I found, that I had to LOWER the pull up resistor for the PT quite a bit. With this value the PT still draws the signal to a good “low”. The problem was not the falling edge when the PT was switching. It was the rising edge, when the current trickled through the pull-up resistor to restore the high-state. Since there was no active driver setting the signal level with low impedance, the pull-up resistor is the only source of current.

The rising edge is still a bit rounded due to the minimalistic design but overall signal is fine - as is the decoding.

If possible, investigate the signal with a Scope. It might be a different problem than you think. Even a cheap ($100 USB/PC) scope might be of great help in all kind of electronic work.

Before (RX interfering with on board serial on reply to the init sequence):

Signal loss
Signal loss1024×600 44.6 KB

After (pins swapped, rising edge enhanced):

Signal OK
Signal OK1024×600 34.5 KB