Ping from pybytes

[almeos]

Hello,
I have connected some Fipy on Pybytes. It sometimes disconnect without any reason, nevertheless "lte.isconnected() = True" and "pybytes.isconnected() =True".
My question is: Is there a way to ask pybytes to send a response when fipy uses "pybytes.send_ping_message()" so that if there is no response the fipy should reboot.
Thanks
Denis

[Gijs]

The Pybytes library itself checks every 10 minutes for a PING message from the Pybytes server. The internal watchdog timer has a timeout of 20 minutes, and will reset the device if it has not received a PING response twice in a row. Though if you manually disabled the watchdog timer, this will not occur.

At the moment, I can not think of a way that makes detection faster without recompiling the firmware

[almeos]

Hello,
Thank you for your answer,

• First, my fipy, as usual, has been here disconnected from pybytes during hours, I finally made a Ctrl C and wrote this:

>>> alarmCase.pybytes.disconnect()
Watchdog timeout has been increased to 2147483647 ms

How can the watchod timer increase over 21min?

• Second point, I made a showphy:

>>> alarmCase.pretty('AT!="showphy"')
DL SYNCHRO STATISTICS
=====================
    Synchro state                         : DRX_SLEEP
    PPU SIB1 ACQ watchdog                 : 2
    Frequency Hypothesis RF  (Hz)         : 0
    RSRP (dBm)                            : -90.44
    RSRQ  (dB)                            : -8.46 

The synchro state is "DRX_SLEEP", I think this is the reason why it is disconnected from Pybytes.
How can I change DRX state to have "DRX_WAKE_UP"?

[Gijs]

How can the watchod timer increase over 21min?

Once you disconnect from Pybytes, we increase the WDT timeout to the maximum value. It might look like 21 minutes, but actually the timeout is almost 600 hours

Second point, I made a showphy:

Sorry, its not totally clear to me what you're getting at, could you perhaps elaborate on what you're trying to achieve here?

Let me know!

[almeos]

@Gijs Sorry for my poor english language, I will do my best to explain clearly.

• If the WDT is over 21 minutes, the fipy should try to reconnect to pybytes, shouldn't it?

• I am trying to find how to reconnect my fipy when it disconnects from pybytes.
  The commands "lte.isconnected()" and "pybytes.isconnected()" do not work: connected or not, it always displays "TRUE"!
  After many many tests, the only way that I found to see if the fipy is realy connected to pybytes (using Atom pymakr), is to type the commmand "lte.send_at_cmd('AT!="showphy"')"
  If the answer is Synchro state: "DRX_SLEEP" : the fipy is not connected to pybytes
  If the answer is Synchro state: "DRX_WAKE_UP_ : the fipy is connected to pybytes

The solution I finally found is to insert a callback in my code:

lte.lte_callback(LTE.EVENT_BREAK, lte_cb_handler)

If the callback has been triggered because of a disconnection, then the fipy tries to reconnect to pybytes using

pybytes.connect()

This the only efficient command that I found. It does work but this solution is not so good: there are too many callback occuring so that the fipy spends much time to reconnect to pybytes.

[Gijs]

No worries

If the WDT is over 21 minutes, the fipy should try to reconnect to pybytes, shouldn't it?

Yes, though it will take 21 minutes before the reset happens (it will trigger a full system reset, similar to machine.reset()). This is independent of lte.isconnected() or pybytes.isconnected(). As I mentioned before, it will send/receive a PING message from Pybytes every 10 minutes, and when there is no response, it will try again 10 minutes later. If there is still no response, it will trigger the system reset.

The solution I finally found is to insert a callback in my code:

lte.lte_callback(LTE.EVENT_BREAK, lte_cb_handler)
If the callback has been triggered because of a disconnection, then the fipy tries to reconnect to pybytes using

pybytes.connect()
This the only efficient command that I found. It does work but this solution is not so good: there are too many callback occuring so that the fipy spends much time to reconnect to pybytes.

When the callback triggers, you will need to check manually (by for example doing a socket.getaddrinfo() whether the BREAK was caused by a 'permanent' disconnect or something else. We also explain this in the documentation: https://docs.pycom.io/tutorials/networks/lte/#lte-connectivity-loss