(only have apple computers in the house if that is relevant)
Software -
Tried with multiple builds of latest firmware, both with and without power loss protection
Issue -
Plug in and configure via USB-C, everything works GREAT, logs to card properly and the Arduino IDE Serial monitor window spitting out data like a champ. Pressing reset causes a pause in data then everything reinitialises perfectly.
Plug in battery (without unplugging from USB-C). Yellow charge light comes on, everything continues to work perfectly (including pressing the reset button).
Unplug USB-C, yellow light turns off, data keeps logging. but if I try to plug the USB-C back in to make an adjustment in the menus, I cannot get the board to re-establish communications. The board does not show up in Arduino IDE. Pressing reset on the board puts the board through a reboot, it returns to logging, but NOTHING in the IDE serial monitor and the board does not show up in the ports or board list.
I feel like I am missing something VERY obvious.
I tried letting the board sit on charge for a while but the problem persists.
I have tried with and without the micro SD card installed
the only thing that fixes is is unplugging the battery and plugging back into the USB-C. This is really not good for how I was looking to use the product.
Have you tried closing the Arduino IDE between steps 2 and 3? I’m wondering if the link to the USB-C port is ‘broken’ when you disconnect and reconnect. I’ve seen similar behaviour on the old Arduino IDE v1.8.n on Windows. The solution there is to close and reopen the Serial Monitor each time.
I had already tried that but just tried it again to no avail. Here is another datapoint:
With the artemis running on the battery and Arduino IDE open and unable to connect via serial monitor I tried unplugging the battery without touching anything else. The board (within about 250ms) is automatically detected by the IDE, automatically connects and starts spitting out data.
Trying to simplify whats going on, I opened a terminal window and used the ls /dev/tty.* command
just the Artemis plugged in → the device (/dev/tty.usbserial-110) appears in the list
plug the battery in to the artemis and reissue the command → the device appears in the list
remove the USB-C cable and reissue the command → the device disappears as expected as it is not plugged in
reinsert the USB-C cable without unplugging the battery and reissue the command → device is still missing from the list.
reset the artemis with everything still attached and reissue the command → device is still missing from the list.
unplug the battery, do nothing else. ALL LEDs go off, the artemis appears to reboot, reissue the command → the device reappears in the list.
I am SOOOOO close to this all working. Plugging in the battery was supposed to be the easy part!!!
Other pieces of information that I do not think are relevant but could be (#3 is likely the most interesting):
I had been messing around with connecting and OLED to this setup. I had that up and running in a branch of code but then reverted to back to a sparkfun compiled binary to make sure it wasnt my code.
I struggled getting this macbook to play nice with the artemis. it will not let me upload to the board in arduino IDE, BUT it will let me push a locally compiled binary successfully to the OLA via the Artemis Uploader App.
I believe I have the ch340 driver properly intalled, but devices show up in the list as /dev/tty.usbserial-110 rather than tty.wchusbserialx
I think this could be a driver issue, but I’m really not sure. I’ve never seen similar behaviour on Windows. And there’s nothing on the schematic to explain what you’re seeing.
Is there any way you could borrow a Windows machine, just for testing?
I’ll include a couple of links below to the official Mac drivers at WCH-IC, just in case they help.
For some reason those links wont work, but I now believe I DO have the drivers installed correctly and showing up as such in Arudino IDE. Behaviour remains the same. I will try to get the files you linked to download and make sure there isnt someother oddity about the files I found.
I will try to find someone with a windows machine locally and I know of one other person in the area using the some of these sensors and accessories.
if you have any ideas OR if someone else out there with a mac an OLA and a battery could give this a try. . . please let me know!
I just had an idea how I think I can show that this is something independent of the driver tomorrow. . . but need to discharge the battery first. Do you agree that this is a valid test:
Run down the battery to some threshold where charging SHOULD start when plugged into USB (can you tell me when this should trigger?
with the OLA still running on the battery, Plug in a power only USB-C cable to the OLA (known good USB-C cable, plugged into a wall charger).
Expected outcome: we would expect that the USB-C power enables the charger to start charging and the amber charge light turns on.
its interesting that my board is experiencing the exact same symptoms as this other thread on an ESP32.
One of their observations gives me a work around that is good enough for now. If I use a USB-A to USB-C cable instead of a USB-C to USB-C cable . . .IT WORKS even though I have to use a USB hub between as my macbook does not have a USB-A port on it.
Peculiar, but ill let it go as I have a solution that works good enough for me
