@DEFRAINE-JM Many thanks. I did find a stable combination after all, although not the latest version of the plugin or VSCODE, but I am happy that it works.

Pygate needs a lot of RAM. As suggested in the docs you can turn off LTE or Wifi (whichever you don't need) https://docs.pycom.io/tutorials/expansionboards/pygate/#setup

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!

@sarya said in PyGate with Gpy India Frequencies: m based out of India and was wondering which configuration to use to set up a gateway using this setup. If anyone can share a snippet it would be great as I don't want to brick the devices. Thanks Hi, I will have this information available in the documentation very soon. In the meantime, you can use this: You can find the config file for your region here Make a file called config.json in your project and paste the appropriate region settings to that file Add the following to the bottom of the config.json file:... } ], "gateway_ID": "XXXXXXXXXXXXXXXX", "keepalive_interval": 10, "stat_interval": 30, "push_timeout_ms": 100, "forward_crc_valid": true, "forward_crc_error": false, "forward_crc_disabled": false } } Edit the gateway_ID to reflect yours.

To your first question, both firmwares are fine. The second question applies to the modules shipped from December 2019 and after and is not related to the firmware version difference. The last question, it is fine to sign up with Pybytes. The Pybytes library is always in the firmware (even if you did not sign up), but once you disable the connection, it will not connect to the Pybytes servers.

See my Teensy 3.x/4.0 CoreMark, Temperature and Power Benchmark. With a simple black aluminium heatsink from Raspberry Pi the MCU temperturare of the Teensy 4.0 is up to 15 C lower. Other solution is to cover the case/box with reflective surface. I've had experienced 20-30 C lower temperature.

@crumble Thankyou very much

Dear @shanefowler25, @shanefowler25 said in Bluetooth GATTSCharacteristic GPy: I just wasn't able to do a GET request for my application. May I humbly ask whether you wanted to connect using SSL here? I'm just asking because we didn't test these details thoroughly with our custom builds yet. @shanefowler25 said in Bluetooth GATTSCharacteristic GPy: Hopefully sometime in the future, there will be another update to the firmware that allows users to use Wifi/Bluetooth or Cellular/Bluetooth, without the program crashing and resetting the board. Issues around this "coexist" thing have even bitten Espressif Systems for quite a while, as outlined above. In this manner, the Pycom firmware is pretty much innocent here as it depends very much on the details coming from the ESP-IDF in this regard. @shanefowler25 said in Bluetooth GATTSCharacteristic GPy: My program would still crash when I used to Bluetooth to break the while loop of my program. While we are avid WiFi users, some people from our community are also approaching BLE these days. @poesel reported his observations on [1] and [2] already, but unfortunately he is currently traveling without being able to confirm our latest build would work better for him. He is using a GPy as well. @shanefowler25 said in Bluetooth GATTSCharacteristic GPy: I figured out a workaround that works for the application that I'm trying to do. Good that you found something that works for you. As we are currently trying to collect experiences from people affected by this issue on [3], we still ask anyone who could test the latest dragonfly builds. So, if you might find some time for that beyond working on your program, we would be more than happy to hear about the outcome. Thanks already and happy hacking. With kind regards, Andreas. [1] https://forum.pycom.io/topic/5358/1-20-0rc13-guru-meditation [2] https://community.hiveeyes.org/t/investigating-core-panics-with-ble-on-pycom-devices/2715 [3] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746

@kjm To check whether the LTE sim card is deactivated or not you need to contact the service provider.

Hi @jcaron, Thank you for answering, so I reviewed that other forum as well before and I am still a bit confused. I understand creating a server side script in python, php, etc. to execute the SQL queries, however, I’m lost at how to return the results over HTTP. I see the other forum talks about sending data to a MQTT broker, is that something I would have to do? Send the query results from the database to the broker and then subscribe to the MQTT?

@kjm That value is #defined in esp32/lte/lteppp.h, and the constant is used e.g. in esp32/mods/modlte.c.

Dear @kjm, we also dedicated ourselves to that topic and followed the suggestions from the forum to shut down the LTE modem before deep sleep. We are actually shutting it down shortly after boot already. However, we have not conducted detailed measurements yet. As far as we can tell, the power consumption the FiPy draws still shows flaky behavior. a) Do you have any news about that topic? b) Maybe @robert-hh can also contribute something sensible? With kind regards, Andreas. [1] https://community.hiveeyes.org/t/deep-sleep-with-fipy-esp32-on-micropython/1792 [2] https://community.hiveeyes.org/t/lte-modem-des-pycom-fipy-komplett-stilllegen/2161

@kjm I never worked with Gpy, but with LoPys the speed of the firmware is nearly the same. What changed are the windows when the i2c module is ready to communicate. So you can start some i2c stuff before the whole system was completly initialized. But these windows/frames moved between firmware versions and became larger or smaler. So it was not reliable to use them. Maybe pycom moved some of their internal i2c stuff into more reliable regions. I do not recommend to stay on older firmware versions and optimise the timings for them. The ESP32 and the IDF cause too many problems. IMHO pycom is on the development branch too far behind the actual IDF version. If you have huge scripts, you can save some time by using precompiled or frozen modules. If you have some complicated stuff to do, you can do this before the Modem is ready. Yes, fast boot times will be fine, but I preferre signals, callback or variables which tell me, if the hardware is ready to use. I wasted too many time to find windows inbetween init states :)

I would try to monitor the length of the output queue. See _io_thread_func in MQTTMsgHandler.py - in there there's the transmit loop and you could add some signaling there to indicate the TX queue is empty. You'll probably need to modify the code and rename the function so you are not using the builtin frozen ones.