Hi @kjm, while I see that good timeout-functionality is very important to everyone out there (and probably for us as well), we haven't had the chance to care about these details yet. However, we will be happy to get any support for that ;]. With kind regards, Andreas.

@fernandes-son It uses self->frequency which is the same value as that returned by the lora.frequency method. self->frequency should be the same as lora_obj.frequency. Going very very quickly through the code it seems to be this would be more likely to be the frequency data was/is going to be sent on, but the lora_obj may be passed to other parts of the code. It should be easy to test, though, just call lora.frequency to see what it returns in various scenarios. Don't have a LoPy at hand to test this here at the moment.

That's interesting, I get that same cryptic error when I test directly over an SSL socket with a bogus certificate: >>> s = socket.socket() >>> ss = ssl.wrap_socket(s, cert_reqs=ssl.CERT_REQUIRED, ca_certs=bad_cert) >>> ss.connect(socket.getaddrinfo(host, 443)[0][-1]) Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: -9984 With other "wrong" certificates I've gotten OSError: [Errno -30592] MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE instead. Not sure why the difference. Anyway, I know this post is old, just putting this here in case it helps someone in the future. K

@guyc Yes, it is. In the repository there are tables which set the Gxx, GPIOxx and Pxx numbers side by side. For Lopy, it's here: https://github.com/pycom/pycom-micropython-sigfox/blob/Dev/esp32/boards/LOPY/pins.csv For the other boards the tables are in the respective paths.

Dear Dan, it is interesting that you are seeing these faults on some devices and not on others, this might indicate something like the PSRAM cache bug related to the ESP32 rev.1 and rev.2 chips [1]. Actually, I don't know if Pycom ships revised LoPy4 devices already including the ESP32 ECO V3 [2] where these silicon bugs have been mitigated - you might be able to investigate by reading out the chip information [3]. @d-alvrzx said in Random Core Panics only on some LoPy4 units: we have not been able to try your Dragonfly or Squirrel builds neither. You should really try [4]. While we can't promise anything, they are already helping others in similar scenarios when accessing the flash memory at runtime. With kind regards, Andreas. [1] https://community.hiveeyes.org/t/random-memory-corruption-faults-on-esp32-wrover-rev-1-and-rev-2-when-running-in-dual-core-mode/2515 [2] https://www.espressif.com/sites/default/files/documentation/ESP32_ECO_V3_User_Guide__EN.pdf [3] https://community.hiveeyes.org/t/read-information-about-the-chip-and-flash-on-pycom-devices-through-the-expansion-board/2699 [4] https://community.hiveeyes.org/t/squirrel-firmware-for-pycom-esp32/2960

@misterlisty Thanks - what PC / Operating system are you using ? Windows/Mac/Linux?

Thank you for the feedback on the ESP32 ADC challenges. It helps greatly. In dealing with the ADC Class function I have the following questions; I have 2 prototype designs, 1 based on LoPy and the other on Gpy. On the Gpy design I am trying to read the Battery Voltage (range between 5.5v and 3.3v) through a 1M ohm and 47K ohm resistor divider connected to ADC1_CH7 (GPIO35 ESP32 pin 11). Can I use the ADC Class Function to read that channel? My code would be; adc = machine.ADC() BatterySensorPin = adc.channel(pin='P11', attn=machine.ADC.ATTN_11DB) BatterySensorPinVoltage = BatterySensorPin.voltage() My concern is that when I read the ADC Class documentation it says valid pins are 13-20. Is that a documentation error? If that is correct how is the other available ADC pins read? As an example, in my case how would I read ADC1_CH7 (GPIO35 ESP32 pin 11)?

@jcaron I said a similar to lora-mac-nano-gateway example. If it was too different, I'd post the code. So I guess you don't need a crystal ball to see that this example here https://docs.pycom.io/tutorials/lora/lora-mac-nano-gateway/ is not working.

@jcaron Hi jcaron, I change the node to class C. I also tried class A mode with TTN, that works OK.

@andreas Nice, we have looked at this... so we think it is in the firmware as we don't have any issues with 1.18 r3 but only with 1.20.2 rc3 we got these Guru Meditation Error

Dear community, updating to the recent 1.20.2.rc3 release seems to help here, see also [1]. @ps47 said: I tried the new build LoPy4-1.20.2.rc3-0.8.0-vanilla-squirrel.tar.gz and not any “bad00bad bad00bad bad00bad” Core Panic happened till now. Thanks @husigeza and the whole Pycom team for mitigating this issue! With kind regards, Andreas. [1] https://community.hiveeyes.org/t/investigating-core-panics-on-the-lopy4/2878/29

@goldfishalpha said in Flashing v1.20.r1 bricks my LoPy4: @crumble where did you find this? I'm surprised this isn't in the documentation anywhere.. just follow the link. You have to read the firmware update posts for two reasons: pycom updates the documentation rarely pycom has no concept how to deal with version differences. So they do not document the API changes of the development branches until they move them into release. - if the remember the changes. MicroPython documentation is a little better. You can choose between the versions. But I prefer to see the supported versions in the doc. This is much more handy, if you have to program against multiple API versions.

Good news, I got this to work by commenting out the code in sqnsupgrade.py which I assume tries to retrieve the modem crashdump (the two occurrences in the __run method). I guess the crashes on my modem were longer than the 100 byte assumption in the code.

Dear Henro, you should really be using LittleFS these days. FatFS is known for regularly losing data. With kind regards, Andreas.