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

I think I might have a flash memory problem, something that has haunted me with GPYs from the getgo. If I upload then remove then upload boot.py & main.py several times I seem to get a more stable system. It's like the first write of new software is not enough.

@Bettina, @administrators Must be a deep one, I still waiting for a solution or at least and acknowledgment of my comunications

@robert-hh Unfortunately I don't have an sd card to try updating it that way. Here's my output when I run the update with debug set to True. >>> sqnsupgrade.run('/dev/ttyUSB0', 'NB1-41019.dup', debug=True) <<< Welcome to the SQN3330 firmware updater [1.2.5] >>> File NB1-41019.dup has size 5835531 mirror? False recover? False resume? False direct? False atneg_only? False bootrom? False load_fff? True baudrate: 921600 target_baudrate: 921600 Setting port /dev/ttyUSB0 Setting baudrate to 921600 Initial prepartion complete... Loading NB1-41019.dup Firmware file is too big to load via FFF method. Using ON_THE_FLY Attempting AT wakeup... [921600] b'\r\nOK\r\n' AT+BIND=AT returned b'\r\nOK\r\n' ATE0 returned b'\r\nOK\r\n' Entering upgrade mode... Sending AT+SMLOG? AT+SMLOG? returned b'\r\n+SMLOG: LOG_INHERIT\r\nOK\r\n' AT+SMOD? returned 2 Sending AT+FSRDFILE="/fs/crashdump" AT+FSRDFILE="/fs/crashdump" returned b'\r\n\x00\x00/V\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x0055.1.1.0 [33080] by robot-soft at 2017-10-27 07:49:11\x00\x00\x00\x00\x04\x00\x00\x03\xa8Assertion fai' AT+SQNSUPGRADENTF="started" returned b"ed\nFile: l1DspReset.c@96\n'LPU RIP: 00000000 00000003 00000000 (s->state ==ZSP_STATE_RUN || s->state "

@kjm The Pycom devices need between 1-2 seconds to start up. There is some analysis of that in the forum, based on the supply current analysis. LTE devices are slower than e.g. the WiPy. I do not know what's in your main.py script. But that one may take some time. LTE.attach() from power on for instance takes at my place 15 seconds and more. P.S.: Your formula above looks a little bit strange, because in the statement: sleep=600-diff you mix physical units. The unit of 600 is implicitly s (seconds), the unit of diff is ms (milliseconds).

@jcaron No the rtc.ntp_sync fails to connect to time.google.com a lot on wifi & the default 1970 timestamp is what the rtc defaults to when it's not synced. I have to resync the rtc after each wakeup on the gpy because it doesn't keep time during deepsleep.