<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Craig,<div class=""><br class=""></div><div class="">I can see some improvements:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">If we get a HW FIFO overflow in MUX mode, there is little point in continuing. Probably simplest to reset the modem at that point.<br class=""><br class=""></li><li class=""><font color="#000000" class="">At the moment, we pickup on various failures (like no MUX traffic, unable to make cellular connection, etc) and reset the modem. But I too have seen cases where the cellular connection can’t be made, that only a module reset seems to fix.<br class=""><br class="">Perhaps the problem is in the async driver? Better to reset that as well?<br class=""><br class=""></font></li><li class=""><font color="#000000" class="">Hardware flow control would be nice, but sadly we simply don’t have the GPIOs for it. We only have two free unused, and they are desperately needed for expansion modules. The MUX protocol does have a software flow control mechanism, but I am not sure if that would help.<br class=""><br class=""></font></li><li class=""><font color="#000000" class="">I wonder why you are getting HW FIFO overflows? I am not seeing these.</font></li></ol></div><div class=""><br class=""></div><div class="">Attached are draft 3.3 schematics. I have one change outstanding on these (I want to re-label CAN as CAN1..CAN3, rather than the existing CAN0..CAN2, to better match the firmware labelling), and then will publish.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class=""></div></body></html>