I have the same opinion as @jcaron . MTU size is something that has to be configurable. We should be able to set MTU size of Pycom. Changing is not going to break anything in case of good implementation (I've already tried it with Pycom). @Emmanuel-Florent the reason I've started this topic is that I've experience with ESP32-DevKitC and BLE MTU size changing, on that size everything worked fine, so I'm just requesting the same functionality on Pycom if possible.

a web service protocol stack is a protocol stack that is used to define,locate implement, and make web services interact with each other .

Heya, Take a look at our own pybytes: http://pybytes.pycom.io/

@jcaron Yes, and it works! Now I am trying to figure out where to put my module. In the ESP8266 version there is a file called ESP8266.ld which contains the list of C files. Where is the equivalent for ESP32? If there is no equivalent, what shall I look for?

@geoff-white : guess we'll find out.

@peterson79 MicroPython.org does not support @micropython.native in the ESP32 port. It is supported for ESP8266 and STM32.

in this section, there was only : #terminal { background: #000; padding-left: 2px; } I have added the line : font-size: 16px; and that is better to read , thanks !

@calvinblock44 Sigfox enforces that the devices that consume their service need to be registered manufacturers, the Pycom's Sigfox native library contains sensitive information and code that need to be packed and secured (As more as possible). From there you have two options, construct your wifi sniffing functionality over the official firmware or select a more appropriate hardware that fit your needs. Be aware also that if you are planning to create a final product using certified boards your are not allowed to modify the RF code because is highly possible to void the certification if the code modify the way of signal emission.

Dear @tanmay07 and @Martinnn, if you feel lucky, you might want to try our custom build just released on [1]. More background about this is available through [2]. Please be aware that when upgrading from a lower firmware version to this custom build based on 1.20.1.r1, you will have to erase your device completely before flashing in order to keep things straight. You will find respective references to this on the forum. Hint: Use pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [3]. With kind regards, Andreas. [1a] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [1b] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480 [3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688

@seb Yes I meant copying single files. I installed mpfshell and this can do the job for me. I did use an FTP toool for this, bud when using the WiFi radio in my app I constntly had to switch between IP addresses. Thanks again.

@robert-hh Thanks! I tried this and it works great! I tried also the new update with the freezing the _main.py which also solves the problem.

This is the correct procedure. It works 100%. I really appreciate your quick and accurate response. THANKS !!!

Reading this up and down a couple of times. But still cannot figure out if V_BCKP is connected to the L76 GPS or not? Trying to use go_to_sleep(gps=True) but it still takes 30+ seconds to get a GPS fix after waking up. Straight up, do I need to solder a bridge on the unpopulated component or not?