Reaching Out to the Seller
Naturally one of the first things to try when dealing with these sorts of problems is to try asking the seller about it. In this case, the seller did not reply for over a month, and I had already figured the problems out for myself. Some of the items that I complained about in my initial review of the product were addressed, such as missing documentation on the product page.
CAN Bus
The example code for the CAN bus was very promising, and in fact there was nothing explicitly wrong with it. But I couldn't get any data to transmit or receive on the CAN bus. I could see that the data was present on the I/O pins for the ESP32 and that they were connected to the right pins on the transceiver. What didn't match the example was that this development board had the enable for the CAN transceiver connected to a pin on the ESP32 instead of wired to be permanently on (this was not mentioned anywhere on the product page at the time).
Micro SD Card Logging
One of the more simple tasks, this was impeded by two things. First, there was no documentation for which IO pin was used for the CS pin on the SD card (while this was not difficult to determine by using my multimeter to find which pin has continuity to the SD card, it did add 20-30 minutes of time spent searching around for the information and probing everything). The bigger issue that I discovered was that there were no pins on the ESP32 connected to the "card present" pin on the SD card holder. This isn't unfixable, but it's definitely something that I shouldn't have to do myself.
Incorrect Voltage at the 5v pin when powered from 12V
There were two issues that came up when powering the device from the 12v input. The first was that the voltage of the pin labeled "5v" was actually around 7v when the device was powered from 12v. This was quite alarming, as I was concerned that this might damage the USB-UART chip.
This turned out to be caused by too much leakage through the OR-ing diodes used to allow the board to run off of 12v or USB power.
WiFi
Disclaimer: this problem was most likely caused by the diodes that I used to replace the original OR'ing diodes (mentioned above) and may not have happened with the original design. The diodes that were used as replacements were ones that were on-hand and aren't ideal. Since I have a work-around for this problem I may just opt to leave it as-is for now and do my own PCB with a better solution.
I started out trying a simple WiFi client example from Sparkfun, and found that when the board was powered only by USB that the microcontroller would brown out when attempting to use the WiFi:
Because the power inputs are diode OR'd between the USB and the 12v input, I was able to rule out my USB port as the source of the problem by using my lab power supply set to 5v. In both cases there was a large voltage drop on the output when the WiFi was used that would cause the microcontroller to reset:
The voltage regulator used has a dropout voltage between 1-1.3v according to the datasheet. The combination of insufficient capacitance near the regulator and the voltage drop across the OR-ing diodes causes the momentary dip in the output. Adjusting the voltage of the bench power supply to account for the additional drop gets rid of the problem:
Overheating Voltage Regulator
Because the WiFi would not work with USB power (see above), I was powering the board from 12v to test some code and noticed that the LDO voltage regulator was getting really hot. Using a thermal camera showed that the component temperature was exceeding 100 degrees Celcius(!) in room temperature ambient conditions. This is a classic case of a poor usage of an LDO regulator, not only because they generate a lot more heat than a switching regulator but because there was no copper plane for the part to use as a heat sink. The video below shows the vast difference between temperatures when the device is powered from USB and with 12v:
Conclusion
Tindie promotes itself as a marketplace for makers, which makes a lot of interesting and unique things available that wouldn't otherwise be for sale. However, there is a difference between a "maker" and an engineer, and some degree of caution must be taken when deciding if a product created by a "maker" actually does what they say it can do. I spent a lot of time at the beginning looking for problems in my code when things weren't working because I assumed that the hardware had already been validated. This highlights the importance of doing your own testing and characterization of components and parts when you are going to use them in a design, even when it is just for a personal project.
