@robert-hh Thank you

Just to give feedback, I've had the Pytrack + Gpy powered via the VUSB_AUX for a few hours and all is working fine. Thank you for all the help!

@jcaron Perfect thanks

Same topic: https://forum.pycom.io/topic/2469/easy-way-to-tell-what-expansion-board-is-in-use Here's a method to create a generic exp. board object: from pycoproc import Pycoproc from pysense import Pysense from pytrack import Pytrack # create exp board object using unknown board type pyexp = Pycoproc(1) if pyexp.read_product_id() == 61458: print("Using Pysense") pyexp = Pysense() if pyexp.read_product_id() == 61459: print("Using Pytrack") pyexp = Pytrack() Later on use eg: if pyexp.board_type == pyexp.PYSENSE: si7006 = SI7006A20() Perhaps someone can tell us the id for the Pyscan board.

@robert-hh ah ok, thank you for explaining. so I set it to 3.28 V and I am on the safe side ;) thanks

Thanks. I assume that I run into one of the ESP32 bugs related to memory problems with multicore or reading multiple times the same address. But therefore it is strange that the returning value is always 6. As long as it fails mainly on initilazing pytrack and WDT helps, I am fine. I will be happy. if the *Py can be configured so that ctrl-c stops the watchdog or sets wait time to max.

@combaindeft Did you find any solution? We have ended up with the EXACT same problem. Poor antenna. I mean, good relative to the size – but our application is not size constrained. I actually consider abandonning the pytrack alltogether and get a seperate gps module, accellerometer etc.

@paul-thornton Thanks to both, the upgrade went flawless, and it seems to be much easier doing it from within linux. It gave me a scare though, in that not only I could not make my (VC) pymakr to connect to it, but it crashed the computer a few times. That, until I deleted the directory .vscode from the working folder. Next I have to look into the Lopy4 upgrade (current code 1.18.2 r1)

Seems like this is related to WIFI in some way. When turning off WIFI (pycom.wifi_on_boot(False)) problem goes away. I am not using WIFI in any way, but maybe powerlines or WIFI accesspoint makes my W01 panic? This is the application I have been running during the test: from machine import Pin import utime LED.append(Pin('P3', mode=Pin.OUT)) while True: LED.value(1) utime.sleep_ms(100) LED.value(0) utime.sleep_ms(100) I havent been able to decode the core dumps, can I send them to someone for investigation? This forum didn´t allow me to post it here.

@pyshi were you able to connect the adafruit gps to lopy4 ?

@fedonman Depends on the sensors really. What bus (i2C, SPI, etc) or other port you need. Other factors are the power supply required and any other such factors. My practice is to extend the bus/es from the sockets Expansion/Pytrack board to a protoboard, so I am able to connect more than one device, power supply, level shifters, pull up/down resistors, capacitors etc if required. Makes it easier to work on and follows on with making a custom PCB later on..

Ideally the external headers if the pins match your usecase.

@glagnar Hey, Pretty sure I just responded to your rma a short while ago you can go ahead and ignore my request to confirm its running the latest firmware in that now I realise its linked to this thread :). Ill update the RMA shortly :) Paul

I actually gave up on the FiPy for not getting this sorted out. The problem is not in the use of a GPIO to wake the board. The problem is in entering or exiting the deepsleep mode. Now reading some more in the forum I found one reference to sometinh that might be related to the issue that I experienced: @crumble said in Deep Sleep Not Waking Up: @jcaron said in Deep Sleep Not Waking Up: Also, remember that machine.deepsleep never returns. Depends :) If it behaves like the pytrack, it may never go to sleep and never increase the program counter. I assume a catched i2c issue in combination with the pytrack. If the OP has a USB volt meter, he can simply verify this. If it still draws a lot of power, it does not sleep and can therefore never wake up. The software watchdog is able to get it out of this state. On my system it is not easy to reproduce. It may need a few hundred deepsleeps before this error occurs.

Found a start of an answer here: https://forum.pycom.io/topic/3624/machine-pin_deepsleep_wakeup-function-is-not-working-in-lopy4-firmware-version-1-19-0-b2 Link to developemtn documentation on github: https://github.com/pycom/pycom-documentation/tree/development_release/firmwareapi/pycom/machine The method is renamed to pin_sleep_wakeup()

Going back to the 1.18.0.r1 and reseting the GPS did not help. The firmware updater (1.15.2.b1) installs the 1.18.1.r10 version of the firmware and I'm unable to find the 1.20.rc4 version of the firmware.