April-28th-2020, 08:53 AM
Well Peter,
first of all the physics:
In the NPIX manual located here https://www.netiot.com/fileadmin/user_up..._07_EN.pdf in the chapter 4. NIOT-E-NPIX-RS485 you see the schematics of the RS485 module's circuit. There is not much in it other than the gavanic isolation chip named SI8642BC-B-IS1 and in #REV2 the bus driver MAX13488E with auto-direction control if you set BCM17 = TX_EN to high state. I think you agree that this physical setup is straight and just forwarding signals BCM14 and BCM15 from and to the CPU. So from this point of view I can exclude a hardware problem.
As next I am very interested in your overall RS485 setup, cause I think you know that RS485 needs end termination at each end of the line, else the bus level does not automatially falls back to idle and prevents reflection on the wire as described here https://e2e.ti.com/blogs_/b/analogwire/a...t-properly. 120 ohms is the recommended value. It might be that you USB stick has a terminator integrated.
What I also see is that in all case the temperature sensor tries to send back a response ... this means sending through NPIX-RS485 works always, right?
Then to the software:
I guess setting Node-RED to "rtu-buffered" in the Modbus RTU node means that all Rx data that is received is first of all put in a internal buffer directly in the interrrupt service routine the time it is received instead of sending each byte by byte to the application. But this is only a guess. Maybe your python driver does not work the same. I don't know.
There is another thing: In general, the socalled Mini-UART used for this communication path has one big pitfall. It doesn't have its own clock source, so the UART bitrate depends on the CPU clock. Which means you have to set a fixed CPU clock for reliable communication. With original netPI OS we use the force_turbo=1 parameter in the config.txt to prevent the CPU clock from throttling, but I don't know if balena OS is supporting it as well.
Thx
Armin
first of all the physics:
In the NPIX manual located here https://www.netiot.com/fileadmin/user_up..._07_EN.pdf in the chapter 4. NIOT-E-NPIX-RS485 you see the schematics of the RS485 module's circuit. There is not much in it other than the gavanic isolation chip named SI8642BC-B-IS1 and in #REV2 the bus driver MAX13488E with auto-direction control if you set BCM17 = TX_EN to high state. I think you agree that this physical setup is straight and just forwarding signals BCM14 and BCM15 from and to the CPU. So from this point of view I can exclude a hardware problem.
As next I am very interested in your overall RS485 setup, cause I think you know that RS485 needs end termination at each end of the line, else the bus level does not automatially falls back to idle and prevents reflection on the wire as described here https://e2e.ti.com/blogs_/b/analogwire/a...t-properly. 120 ohms is the recommended value. It might be that you USB stick has a terminator integrated.
What I also see is that in all case the temperature sensor tries to send back a response ... this means sending through NPIX-RS485 works always, right?
Then to the software:
I guess setting Node-RED to "rtu-buffered" in the Modbus RTU node means that all Rx data that is received is first of all put in a internal buffer directly in the interrrupt service routine the time it is received instead of sending each byte by byte to the application. But this is only a guess. Maybe your python driver does not work the same. I don't know.
There is another thing: In general, the socalled Mini-UART used for this communication path has one big pitfall. It doesn't have its own clock source, so the UART bitrate depends on the CPU clock. Which means you have to set a fixed CPU clock for reliable communication. With original netPI OS we use the force_turbo=1 parameter in the config.txt to prevent the CPU clock from throttling, but I don't know if balena OS is supporting it as well.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
