Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    LoRa NVRAM clear on restore issues

    Scheduled Pinned Locked Moved Discussion
    lorawanloradeep sleepbattery powerednvram
    4 Posts 3 Posters 1.4k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J Offline
      jcaron
      last edited by

      I had a couple of LoPys on which I had to change batteries today (batteries fully exhausted).

      The initial idea was to replace the battery and have the LoPys start again as if they had woken up from sleep. However that did not work, and I ended up having to re-join.

      My guess (don't have detailed logs for that though) is that there could be an issue with the recent logic on lora.nvram_restore which clears the NVRAM after the restore. This probably leads to situations that go like this:

      • battery is close to exhausted
      • LoPy still able to wake up
      • starts, nvram_restores, attempts to send
      • fully exhausts battery and stops before (or during) nvram_restore

      The result is that when a new battery is inserted, it won't be able to nvram_restore.

      I'm not sure what the consequences would be if we just kept the previous state and sent a new frame with the same counter (would just the "duplicate" packet be ignored, or would that trigger other issues?).

      The alternative (which I'm going to implement for now) will be to re-join automatically if needed (join was done manually when setting up the device only until now), but that seems a bit overkill.

      For reference, this is running 1.16.0.b1.

      Thoughts?

      1 Reply Last reply Reply Quote 0
      • H Offline
        han
        last edited by

        @jcaron how did you program the nvram_restore()? and where did you placed the rule in your code?

        I have some trouble with the first time when the Lopy is starting up and connecting.
        If the module is starting up with nvram_restore active, is not joining. But when I make the nvram_restore function inactive it joins directly when the module is starting up.

        Kind regards,

        J 1 Reply Last reply Reply Quote 0
        • J Offline
          jcaron @han
          last edited by

          @han I usually do the initial join process manually moving to the load/work/send/save/sleep cycle.

          But if you do a nvram_restore and there's nothing to restore, has_joined will return false and you can do your join as usual.

          You logic should be something along the lines of:

          • create lora object
          • nvram_restore
          • if has_joined is false, join, and wait for has_joined to become true
          • do the work, send the data
          • nvram_save
          • deep sleep
          1 Reply Last reply Reply Quote 0
          • G Offline
            goldfishalpha
            last edited by

            @jcaron Thanks.
            Just to note this method works also for both a software reset AND powercycle.

            1 Reply Last reply Reply Quote 0

            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

            With your input, this post could be even better 💗

            Register Login
            • 1 / 1
            • First post
              Last post

            Pycom on Twitter

            Pycom