- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
New Products release / BOX-ESP32-P4-PC
Last post by olimex - Today at 01:56:12 PMWe are pleased to announce that our popular ESP32-P4-PC board now has its own dedicated 3D printed enclosure! The new BOX-ESP32-P4-PC is specially designed for the board and provides openings for all interfaces
https://olimex.wordpress.com/2026/05/27/esp32-p4-pc-now-have-plastic-box/
#esp32 #iot #oshw #esp32 #esp32p4 #espressif
https://olimex.wordpress.com/2026/05/27/esp32-p4-pc-now-have-plastic-box/
#esp32 #iot #oshw #esp32 #esp32p4 #espressif
#2
New Products release / TuxCon2026 is over
Last post by olimex - May 26, 2026, 09:31:09 AMTuxCon 2026 is over, and once again it was an amazing weekend full of talks, friends, hardware, open source, and the traditional soldering workshop at Olimex.
Huge thanks to the volunteer organizers and to everyone who joined us — from the youngest 4.5-year-old participant to the experienced makers and hackers who keep the community growing every year.
See you all at TuxCon 2027!
https://olimex.wordpress.com/2026/05/26/tuxcon-2026-has-come-to-an-end/
#tuxcon #foss #oshw #linux #soldering #workshop
Huge thanks to the volunteer organizers and to everyone who joined us — from the youngest 4.5-year-old participant to the experienced makers and hackers who keep the community growing every year.
See you all at TuxCon 2027!
https://olimex.wordpress.com/2026/05/26/tuxcon-2026-has-come-to-an-end/
#tuxcon #foss #oshw #linux #soldering #workshop
#3
New Products release / Six new models of OV5647 5-Meg...
Last post by olimex - May 25, 2026, 10:36:20 AMSix new models of OV5647 5-Megapixel cameras with adjustable lenses for ESP32-P4-DevKit and ESP32-P4-PC are in stock. NV suffix version is with IR cut-off filter removed for night vision apps. https://olimex.wordpress.com/2026/05/25/six-new-models-of-ov5647-5-megapixel-cameras-with-adjustable-lenses-for-esp32-p4-devkit-and-esp32-p4-pc-are-in-stock/ #esp32p4 #ov5647 #computervision #iot #mipi #csi #raspberrypi
#4
ESP32 / Re: Olimex ESP32 POE
Last post by LubOlimex - May 25, 2026, 08:10:33 AMEach ESP32-POE is tested empirically after manufacturing. The test includes programming at least two times.
Double check cabling, port selection, programming settings and configuration. Try with another software tool.
Try reinstalling the CH340 driver.
My advice is to also first try with the tools supported by the chip manufacturer Espressif - like esptool, ESP-IDF, ESP32 package for Arduino IDE.
Double check cabling, port selection, programming settings and configuration. Try with another software tool.
Try reinstalling the CH340 driver.
My advice is to also first try with the tools supported by the chip manufacturer Espressif - like esptool, ESP-IDF, ESP32 package for Arduino IDE.
#5
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 24, 2026, 10:54:51 AMThen why does the MOD-RS485-ISO have a half-duplex mode which according to the manual is the default mode? It wasn't actually default by the way (neither was passthrough mode which required a factory reset), there was only one jumper on the board and it wasn't used for half-duplex mode.
Since it seems the MOD-RS485-ISO does not actually support half-duplex mode, why is this even in the manual and why are there jumpers for this?
Finally found the AMS1117's so that I could test the 3.3V FTDI-cable (with 5V VCC) directly on the MOD-RS485-ISO, without having the ESP32-PoE-ISO involved.
When connecting it to my laptop and testing with ModBus Poll (which I confirmed working with a RS485 USB stick) I got "insufficient bytes received" and when I checked the communication traffic the data looked the same as when I connected Rx and Tx together: what is received is the same as what was send. Is this to be expected?
Currently waiting for "dumb" RS485-UART adapters that are 3.3V compatible.
Since it seems the MOD-RS485-ISO does not actually support half-duplex mode, why is this even in the manual and why are there jumpers for this?
Finally found the AMS1117's so that I could test the 3.3V FTDI-cable (with 5V VCC) directly on the MOD-RS485-ISO, without having the ESP32-PoE-ISO involved.
When connecting it to my laptop and testing with ModBus Poll (which I confirmed working with a RS485 USB stick) I got "insufficient bytes received" and when I checked the communication traffic the data looked the same as when I connected Rx and Tx together: what is received is the same as what was send. Is this to be expected?
Currently waiting for "dumb" RS485-UART adapters that are 3.3V compatible.
#6
ESP32 / Olimex ESP32 POE
Last post by bend - May 23, 2026, 06:24:52 PMhi,
I bought 2 olimex Esp32 POE
i try to flash wled on it
it failed on both devices with running message : preparing
Any Tips to flash these devices?
regards
I bought 2 olimex Esp32 POE
i try to flash wled on it
it failed on both devices with running message : preparing
Any Tips to flash these devices?
regards
#7
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - May 22, 2026, 08:49:47 AMNowhere did we mention that we used or tested ModBus. Never have I or any colleague explored empirically that compatibility until now.
The one thing I can try to do is to give the firmware source to AI and ask it to the change default mode of operation from full-duplex to half-duplex and make it compatible by default with Modbus and ESPEasy. I would test it a bit. If this succeeds I can send you the hex and you can change the firmware via PIC16-compatible programmer (attached over the ICSP connector) and test again.
The one thing I can try to do is to give the firmware source to AI and ask it to the change default mode of operation from full-duplex to half-duplex and make it compatible by default with Modbus and ESPEasy. I would test it a bit. If this succeeds I can send you the hex and you can change the firmware via PIC16-compatible programmer (attached over the ICSP connector) and test again.
#8
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 21, 2026, 06:42:47 PM"Well, read again slowly your last reply. Voila. That is how Schottky diodes work - it blocks current from travelling in reverse direction and also why the Schottky is fine on GPI36 (it has only one direction)."
Yes, but that does not explain why I am not getting a beep with the continuity measurement between UEXT-GPI(O)36 and the one on the side of the board. Correct me if I'm wrong, but shouldn't that, just like directly over the diode, also give a result/beep in just one direction? I'm getting nothing, in either direction. Only when measuring directly over the diode I get a result.
"and there is also pull-up resistor on the wire...."
Which is not active when the circuit is unpowered, so I am still wondering why directly over the diode there's a result, but not between the two GPI(O)36 pins. If the circuit where active and with that the pullup, then yes, but during the continuity test the circuit and with that the pullup was not active.
Plus when I Googled I came across that other topic (where my startpost was split from) so I thought something might've been wrong with UART1.
"- Connect RX to TX via jumper wire like this:"
That was on my to do list, but due to a move, everything is somewhere else and partly still in boxes. Have been having problems finding stuff, like the jumper wires. Just found one, hooked it up, connected ModBus Pull (which also failed to make contact to the meters) to the serial server in ESP Easy and after checking the communication window in ModBus Pull I see Rx data that matches the Tx data and when disconnecting the jumper wire, no Rx data. So it seems the UART does work.
"it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use."
Including ModBus Pull on Windows which I tested through the serial server plugin on ESPEasy. Once I've found the AMS1117's (got a 3.3V FTDI-cable with a design flaw) I'm planning on testing that directly on the MOD-RS485-ISO module, see if I can rule the combination ESPEasy and MOD-RS485-ISO out.
"There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying"
Well, something like that could've been mentioned in the FAQ on the product page
, if I had known this, I would've bought something else. Though those dumb boards (MAX485 ?) aren't isolated as far as I know. Thought getting an isolated board was a good idea.
"Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO"
Do you have any insight on where ESPEasy's SDM*** library might be failing with this? I assumed ModBus was as simple as: Master (ESPEasy plugin) sends command with request for data from a certain register, MOD-RS485-ISO passes it along over RS485, ModBus-meter responds and sends the requested data back, MOD-RS485-ISO passes it along over UART to the ESP32.
Yes, but that does not explain why I am not getting a beep with the continuity measurement between UEXT-GPI(O)36 and the one on the side of the board. Correct me if I'm wrong, but shouldn't that, just like directly over the diode, also give a result/beep in just one direction? I'm getting nothing, in either direction. Only when measuring directly over the diode I get a result.
"and there is also pull-up resistor on the wire...."
Which is not active when the circuit is unpowered, so I am still wondering why directly over the diode there's a result, but not between the two GPI(O)36 pins. If the circuit where active and with that the pullup, then yes, but during the continuity test the circuit and with that the pullup was not active.
Plus when I Googled I came across that other topic (where my startpost was split from) so I thought something might've been wrong with UART1.
"- Connect RX to TX via jumper wire like this:"
That was on my to do list, but due to a move, everything is somewhere else and partly still in boxes. Have been having problems finding stuff, like the jumper wires. Just found one, hooked it up, connected ModBus Pull (which also failed to make contact to the meters) to the serial server in ESP Easy and after checking the communication window in ModBus Pull I see Rx data that matches the Tx data and when disconnecting the jumper wire, no Rx data. So it seems the UART does work.
"it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use."
Including ModBus Pull on Windows which I tested through the serial server plugin on ESPEasy. Once I've found the AMS1117's (got a 3.3V FTDI-cable with a design flaw) I'm planning on testing that directly on the MOD-RS485-ISO module, see if I can rule the combination ESPEasy and MOD-RS485-ISO out.
"There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying"
Well, something like that could've been mentioned in the FAQ on the product page
, if I had known this, I would've bought something else. Though those dumb boards (MAX485 ?) aren't isolated as far as I know. Thought getting an isolated board was a good idea."Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO"
Do you have any insight on where ESPEasy's SDM*** library might be failing with this? I assumed ModBus was as simple as: Master (ESPEasy plugin) sends command with request for data from a certain register, MOD-RS485-ISO passes it along over RS485, ModBus-meter responds and sends the requested data back, MOD-RS485-ISO passes it along over UART to the ESP32.
#9
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - May 21, 2026, 01:53:27 PMWell, read again slowly your last reply. Voila. That is how Schottky diodes work - it blocks current from travelling in reverse direction and also why the Schottky is fine on GPI36 (it has only one direction).
Just take my word for it - there is a hardware connection between ESP32 module pin #4 and UEXT pin #4 and it is visible in both the schematic and the PCB. It is not a straight wire, it has a diode on its way, and there is also pull-up resistor on the wire....
Listen, just do the following test, it is the easiest test, which people that test UART do first:
- Connect RX to TX via jumper wire like this:
- Open Arduino IDE, install the ESP32 support for Arduino and use this code:
- Download it to the board, refer to my settings (you'd have different COM port):
- Open serial monitor - you'd see pX every half a second; remove one side of the wire, message will change to BREAK, connect it back pX will resume again. Like here:
Now when it is clear that issue is not with the UART. You'd realize the problem is elsewhere, it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use.
Honestly, after analyzing and working on this for a few hours I don't think the default firmware of MOD-RS485-ISO would work with ESPEasy or Modbus - the main problem is that the board is designed for full duplex and ESPEasy and Modbus are made for half duplex; standard libraries like Modbus, ESPEasy, etc. expect either a dumb transceiver with controllable DE/RE or an auto-direction adapter. The firmware gives them neither in default pass mode. Also the firmware of MOD-RS485-ISO is like an alternative of ESPEasy and Modbus, it was made for people that want to use simple commands. There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying, since MOD-RS485-ISO has more hardware than required, and it is more expensive than a dumb transceiver. Like all possible ways forward are:
- Get another simpler RS485 transceiver and leave MOD-RS485-ISO for another task that doesn't require ESPEasy or Modbus;
- Use MOD-RS485-ISO without ESPEasy with its own commands, implement similar behavior to what ESPEasy does;
- Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO;
- Re-write the MOD-RS485-ISO firmware.
The software effort to modify ESPEasy or the firmware would be huge and would require a lot of knowledge.
That being written, take into account that the software of MOD-RS485-ISO is open source and sources are available to improve and study and modify.
Just take my word for it - there is a hardware connection between ESP32 module pin #4 and UEXT pin #4 and it is visible in both the schematic and the PCB. It is not a straight wire, it has a diode on its way, and there is also pull-up resistor on the wire....
Listen, just do the following test, it is the easiest test, which people that test UART do first:
- Connect RX to TX via jumper wire like this:
- Open Arduino IDE, install the ESP32 support for Arduino and use this code:
Code Select
uint32_t c = 0;
void setup() {
Serial.begin(115200);
Serial2.begin(115200, SERIAL_8N1, 36, 4);
}
void loop() {
Serial2.printf("P%lu\n", c++);
delay(500);
if (Serial2.available()) {
Serial.println(Serial2.readString());
} else {
Serial.println("BREAK");
}
}- Download it to the board, refer to my settings (you'd have different COM port):
- Open serial monitor - you'd see pX every half a second; remove one side of the wire, message will change to BREAK, connect it back pX will resume again. Like here:
Now when it is clear that issue is not with the UART. You'd realize the problem is elsewhere, it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use.
Honestly, after analyzing and working on this for a few hours I don't think the default firmware of MOD-RS485-ISO would work with ESPEasy or Modbus - the main problem is that the board is designed for full duplex and ESPEasy and Modbus are made for half duplex; standard libraries like Modbus, ESPEasy, etc. expect either a dumb transceiver with controllable DE/RE or an auto-direction adapter. The firmware gives them neither in default pass mode. Also the firmware of MOD-RS485-ISO is like an alternative of ESPEasy and Modbus, it was made for people that want to use simple commands. There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying, since MOD-RS485-ISO has more hardware than required, and it is more expensive than a dumb transceiver. Like all possible ways forward are:
- Get another simpler RS485 transceiver and leave MOD-RS485-ISO for another task that doesn't require ESPEasy or Modbus;
- Use MOD-RS485-ISO without ESPEasy with its own commands, implement similar behavior to what ESPEasy does;
- Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO;
- Re-write the MOD-RS485-ISO firmware.
The software effort to modify ESPEasy or the firmware would be huge and would require a lot of knowledge.
That being written, take into account that the software of MOD-RS485-ISO is open source and sources are available to improve and study and modify.
#10
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 21, 2026, 12:18:34 PMAs for the schottky diode, I did a continuitytest over the diode, beep in one direction, no beep other way round. No beep between UEXT pin 4 and GPI(O)36 pin on the side of the board, in either direction.