@storm-1050 you mean the server is running on the module (WiPy, GPy…) on the Pygate? Or is it running on your computer? If the latter you’ll need them to speak to each other, so you’ll need WiFi or Ethernet. Not sure if you would actually need Internet in this scenario. Have you tried it? What was the result?

Hello Jcaron, I don't think that anything in terms of extra hardware added should have any effect on the UART speed. I have seen this the first time and this comes on irrespective of the firmware revision which makes me wonder. If no one has ever faced this problem then it has to be something on my HW design. Kind Regards Subham Joshi

Yes, I was able to get it to work over MQTT. But my task is mainly to use UDP or TCP. So I am looking for some solution with respect to that.

Yes you can freeze the code https://docs.pycom.io/advance/frozen/ -we are doing it but be aware that it is rather tricky, and my experience from the GPy is that all devices does not really like it. If you are prepared for the work, then this is your best option.

Same problem happened to me. @ahmedkalnaggar solution solved, memory is not being freed properly.

Could this be caused by having 2x 10k resistors connected to 3v3?

@Yuzhe-pei where do you get msg from? My guess is that it isn’t a byte array.

Update: eventually using globals as jcaron suggested was the solution (by-passing the need for argument passing).

How do I change the register code to extend the time for each measurement and also use the lux calibration before each measurement? I guess I could specify the gain manually but also get it for each specific measurement but I still don't know how. Datasheet

@Anders-H according to https://forum.pycom.io/topic/3351/new-development-firmware-release-v1-19-0-b1/18 it should be around 3.5 mA. So one order of magnitude lower than staying on, but two orders of magnitude higher than deep sleep. There are few applications which have a use case for light sleep, but there are probably some (mostly if you need faster wake up than deep sleep but don’t have battery life requirements measured in months or years).

@Teus-Hagen Playing with some basic code with LoRa nvram restore/save and deepsleep we could not reproduce the problem. Ie that part is working. For now let us close this issue. So now we have to dig into what LoRa nvram restore and save actually is doing with the state. Eg after a LoRa nvram restore() is there an argument to follow that imediately with a save? As well to make sure that a power cycle differs from a deepsleep for this: a power cycle should cause a join.

@gxshen You can use the usual socket communication, e.g. with UDP. The Internet is full of examples, e.g. here: https://stackoverflow.com/questions/27893804/udp-client-server-socket-in-python