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.

@dexter12 Our application is remote pump management in Australia. Currently using raspberry PIs with usb cell modems. The PI has full python & is a nice platform but usb modem choices are limited. The built in modem on the gpy is a nice idea but the limited repertoire of micropython makes code porting a pain but worth it to have another string to the bow.

@hayesey import network, machine wdt=machine.WDT(timeout 60000) #allow 60s per deepsleep cycle if 'lte' not in globals(): lte=network.lte() #new modem instance if previous is gone cause=machine.reset_cause() #check if previous cycle ended via watchdog if cause==2: lte.send_at_cmd('AT^RESET') #reset the modem if it did

@kjm I've just tested it through the REPL (PuTTY on COM with W10) on my LoPy and everything is OK: >>> os.uname() (sysname='LoPy', nodename='LoPy', release='1.20.0.rc11', version='v1.9.4-0a38f88 on 2019-05-14', machine='LoPy with ESP32', lorawan='1.0.2') >>> >>> v=input('Enter value -=> ') Enter value -=> test msg >>> >>> print(v) test msg >>>

@kjm For people using Atom the this is a possible approach. But not all people do, and this approach makes quite a few assumptions, like that the image fits into flash. And there a lot if threads about problems with Atom and syncing. Your approach is an alternative, but people will too have issues with it.

@rskoniec Yeah, got there eventually https://forum.pycom.io/topic/4999/gpy-modem-upgrade-alternative