@robert-hh okay, makes sense regarding the documentation. thanks for the information

@Mr-Admin I did it, and it worked for me! Thank you so much for pointing that out!

Thanks for the info Elizar So since as you say RS-485 physical protocol allows for multi-master networks, am I right in thinking the software protocol itself still only allows for a single master architecture? I believe you are right when you say about requesting and listening (I think the master poll's a device's address to respond with the required data). I see the Modbus library also allows for TCP as opposed to 485. Can anyone suggest how I would physically connect the Wipy3.0 to a TCP network? This is something I pretty new to! Thanks :)

@edgar-bacaltos MicroPython is a little bit picky on SD cards. The SD card has to be FAT formatted with a single partition. Brand new SD cards have sometimes a second partition. And: not all SD cards work. I have good results with cards from sandisc, transcend or samsung, in sizes between 8 and 64 GB.

@serenabilly I mentioned to try Putty to sort our the reason for the problem. If there is a driver issue, that can be better analyzed without the overhead of an IDE, which adds it's own layer of complexity and errors. One the communication works with Putty or the like, you can go for debugging an dreconfiguring pymakr. The latter has to be done about every time, when a new version of VC or Atom is published. For tansfering files between a Pycom board and my PC I prefer ftp with FileZilla as client. PC file managers work as well, but FileZilla is more robust. There are also a command line tools like rshell or mpremote from the micropython.org project, or Thonny as IDE as an alternative to pymakr.

@Davide-Botturi I do not have a WiPy, so I hooked up a LoPy4. With nothing connected but GND and Vin, the deepsleep current is less than 20µA (I measured 15-16µA). A WiPy will not be worse. But anything connected to an output may draw additional current, if that output is not switched off. It is quite some work to identify all places which consume some power,

Hello @jmarcelino, do you know if this is already available in any Pycom's firmware?

@robert-hh thank you for the link, rob! I will look into it!

@Tobias-Eliasson I believe you need to enable Pymesh via Pybytes (and accept the associated license) before you can use it. See https://docs.pycom.io/pybytes/pymeshintegration/provisioning/ for info.

@NaveenKumarB The WiPy 3 is based on the ESP32 which has a built-in Ethernet MAC, so you could add an external Ethernet PHY. This uses the pins labeled 'EMAC' on the pinout (a total of 14 pins). Of course this could be a problem if you need any of those pins for other purposes. Not sure if there's any support for that in the firmware, though. An alternative is to use a fully external Ethernet interface (MAC+PHY), connected to the WiPy via SPI for instance, like the W5500 which is quite common in this scenario. Again, there's then the issue of firmware support. In the pure Pycom world, the Pygate has an optional Ethernet (with PoE) module (PyEthernet). I believe it uses the second option (external Ethernet chip), though it lacks details, but that means there is support for it in the Pygate version of the firmware, so it should be possible to build a non-Pygate version of the firmware with Ethernet support. There are quite a few boards out there with an ESP32 and Ethernet (some of them with PoE), depending on your actual use case it may be easier trying to use one of those.

@cbourne Well done!

Thanks - apologies for the duplicate. I’ve now managed to get this to work using uRequests.