Project update 11 of 20
On Monday 1/7, we finally received completed panels from Colorado Tech Shop!
So we spent most of this week doing final assembly (installation of two through-hole electrolytic capacitors and the Ethernet jacks) and testing for all 245 boards in the first batch. I am quite pleased with the result, I hope you backers will be happy as well!
Some boards were used for internal testing, some had to be sent back to Colorado Tech Shop for rework after finding issues during test, but today we were able to ship the first 205 units to Crowd Supply for delivery to backers next week.
If you need to change or update your shipping address, please do so through your Crowd Supply account.
One of the boards was used for an experiment. I wanted to see if the board worked with the AI-Thinker ESP32-S module instead of the ESP32-WROOM-32:
I’m happy to report it seems to work just the same, so this module could be used to provide a future U.FL antenna connector option.
You may have noticed a warning at the bottom of the MongooseOS demo in the demo code repo, about accidentally blowing up the Ethernet Phy while playing with MongooseOS demo code.
I didn’t find any time to pursue this further, but I have to give the people at MongooseOS credit for getting to the bottom of this! I received this message from them:
We did some research, and found the problem with ethernet. It happened to be quite stupid: the default config for the built-in LED used pin 22, which conflicts with the ethernet TX.
So, this command should set the board correctly:
mos flash esp32
mos config-set eth.enable=true eth.mdc_gpio=16 eth.mdio_gpio=17 board.led1.pin=-1 board.btn1.pin=-1
This highlights an issue that can happen with other firmwares as well: misconfigured pins doing damage to the Phy. By default, the wESP32 ships with MicroPython installed and it is configured correctly out-of-the-box for the Ethernet Phy as it is configured on the wESP32. If you load different firmware though, it is your responsibility to ensure the ESP32 pins are configured correctly and will for instance not configure an ESP32 pin as an output that connects to a Phy output, and thus cause a short. Please refer to the schematic to make sure. The wESP32 website section on Software provides more information on wESP32 support in different environments.
I recommend you try your wESP32 with the default MicroPython firmware when you first receive it, to confirm the hardware is sound and it receives an IP address (check with
lan.ifconfig()) from DHCP over Ethernet, which only happens if the Phy is working. All units are tested to do this before they are shipped, but this way you can prove to yourself the hardware is OK and nothing bad happened during shipping. I will not replace defective units once they have been flashed with different firmware, as I cannot know what happened to them.