Have you resolved this problem?

@Adnan-Sabovic I have never observed current consumption of my LoPy4 devices with such detail, but the values you are getting seem in line with typical consumption for these boards. I would also say the peaks are normal for board initialization and transmission. Note that the highest peak of 0.57 A lasts maybe 1 ms from what I can see in your image, so it won't affect your current consumption drastically. [image: 1638903733277-ba8db431-788c-4744-8377-04c44de98999-image.png] From the FiPy datasheet, average current consumption for the board with no radios is 62.6 mA @ 5V. You are averaging 100 mA (although I do not know what voltage you are using), so maybe your WLAN module is on. Make sure to turn it off by setting the pycom.wifi_on_boot() flag to False or by manually disabling it via WLAN().deinit(). Since this is a FiPy, make sure the LTE modem is powered off, as well as Bluetooth and Sigfox (although these are usually off by default).

@vinay-singh yes, however I meant the firmware running on the FiPy board, for example the latest firmware from pycom is 1.20.2.r6. You should check this. On the other hand, sometimes guru meditation errors can happen when the firmware is not loaded correctly, so try erasing the board with pycom-fwtool (more information here https://docs.pycom.io/updatefirmware/device/) and re-uploading the latest firmware.

Hey @frederik-Leys, the LoPy does not have an LTE Modem so lte = LTE() should be have no effect on LoPy but und FiPy it should start the modem. Change your code to: import pycom import machine import time from network import LTE from network import WLAN wlan = WLAN() lte = LTE() time.sleep(5) lte.init() wlan.deinit() pycom.heartbeat(False) print(pycom.heartbeat_on_boot()) print(pycom.lte_modem_en_on_boot()) print(pycom.pybytes_on_boot()) print(pycom.smart_config_on_boot()) print(pycom.wdt_on_boot()) print(pycom.wifi_on_boot()) #colors in hexadecimal (0xRRGGBB) pycom.rgbled(0x00FF00) # Red time.sleep(1) lte.deinit() machine.deepsleep(40*1000) To get in uA range. Or let it run in powersave mode like: import pycom import machine import time from network import LTE from network import WLAN wlan = WLAN() lte = LTE(psm_period_value=1, psm_period_unit=LTE.PSM_PERIOD_1H, psm_active_value=5, psm_active_unit=LTE.PSM_ACTIVE_2S ) print(lte.psm()) time.sleep(5) lte.init() wlan.deinit() pycom.heartbeat(False) print(pycom.heartbeat_on_boot()) print(pycom.lte_modem_en_on_boot()) print(pycom.pybytes_on_boot()) print(pycom.smart_config_on_boot()) print(pycom.wdt_on_boot()) print(pycom.wifi_on_boot()) #colors in hexadecimal (0xRRGGBB) pycom.rgbled(0x00FF00) # Red time.sleep(1) lte.deinit(detach=False, reset=False) machine.deepsleep(40*1000) which brought me to 300uA.

UPDATE : IT IS SOLVED! Unfortunately I'm not allowed to edit my original post, so I put this here... It turned out the the SIM card that I used from T-Mobile had an 'old profile'. So they provided me with a new batch, and enabled the registration on their dashboard. After registering one of the new cards, the FiPy connected within 30 seconds: SYSTEM FSM ========== +--------------------------+--------------------+ | FSM | STATE | +--------------------------+--------------------+ | RRC TOP FSM |CONNECTED | | RRC SEARCH FSM |CAMPED | | RRC ACTIVE FSM |CONNECTED | | PMM PLMN FSM |NORM_CAMPED | | EMM MAIN FSM |REGISTERED | | EMM AUTH FSM |KASME_DEFINED | | EMM CONN FSM |EMM_CONNECTED | | EMM TAU FSM |NULL | | EMM TEST FSM |NULL | | ESM BEARER FSM |BEARER_ACTIVE | | SMS MT FSM |IDLE | | SMS MO FSM |IDLE | | LPP FSM |IDLE | | HP MAIN FSM |IDLE | | HP USIM FSM |READY | | HP SMS MO FSM |IDLE | | HP SMS MT FSM |IDLE | | HP CAT FSM |IDLE | +--------------------------+--------------------+

@Gijs I have exactly the same problem as described above (T-Mobile SIM etc.). Aparently you have assisted Lars outside this thread, but I'm curious if you found the solution.

@jcaron yes, the device is declared to be a class C device via device profile in chirpstack. Here are more details on the setup: Device is a LoPy 4. Every 3 hours it receives data via LoRa and displays it on e-paper. Data comes from a sensor device (Tekelek TEK 766). Communication from sensor to display via Chirpstack, LoRa all the way (Logs show downlink to LoPy 4). No deepsleep nor sleep. Every 5 minutes it updates the information on the display with latest timestamp to see if the device itself is still working. After a power reset it seems to be working as expected. Only after some time the problems occur. I need to do some further testing because over the last weekend the device has stopped working.

We have some Fipy's labelled 'v1.0' going around that are mislabelled, and actually are the v1.2. The picture on the webshop is indeed old, but other than the silkscreen, the physical appearance has not changed. Coming back to your question about RSSI, I'm not completely sure whether the recalibration would be detectable in that way, but it would be a good experiment to try!

@Chandan-Verma can you clarify which example you are using, which region you are in, and where exactly the error happens (the full log/trace would be useful)?

@Konstantinos-Gkekas when you say localisation, I suppose you mean finding the position of the device (geolocation)? In LoRaWAN, this is a feature of the network, not the device, though I’m not sure this is actually implemented in any network. Of course it would require a pretty dense network so that at any point there are at least 3 gateways “hearing” any uplink by the device, along with precise geolocation of the gateways. What exactly are you trying to achieve? It’s probably more likely you will be able to achieve your goal if the device has a GPS receiver, though of course the power constraints are very different.

I'm aware there is a learning curve for the LTE modem, please let me know how we can make it easier for beginners. Could you elaborate what is happening here? the lte.isattache is half finished, making me think the error comes from somewhere else. Does the error just appear, does it always appear? Are you running any code on micropython _thread lte.isattached() cannot return that error, it only returns True or False. Are you perhaps using the mesh (that is the only place I could refernence the ENXIO error to) ?

There's a lot of resources out there to get this up and running. Perhaps have a look at this page: https://docs.pycom.io/tutorials/networkprotocols/mqtt/#app

Please check the page here: https://docs.pycom.io/tutorials/networks/lte/#lte-troubleshooting-guide. Can you confirm the simcards are specifically for NB-IoT and/or CAT-M1 LTE networks, and not the regular 4G mobile phone simcards? also confirm with the carrier whether the there is coverage in your region