J'ai vu des modules 4G se bloquer sur le terrain. La caméra reste allumée, mais le réseau est mort. Personne ne peut l'atteindre. Vous conduisez des heures jusqu'au site juste pour débrancher un câble et le rebrancher.
Oui, la carte mère peut forcer un redémarrage d'un module 4G planté — mais seulement si la conception matérielle inclut un circuit de commutation d'alimentation dédié et un MCU de surveillance indépendant1. Sans ces deux fonctionnalités, un module 4G bloqué restera bloqué jusqu'à ce que quelqu'un coupe physiquement l'alimentation.

La plupart des cartes PTZ à bas prix n'ont pas cette capacité. Elles traitent le module 4G comme un simple périphérique. Lorsque le module se bloque, le processeur principal n'a aucun moyen de couper son alimentation. L'ensemble du système doit redémarrer — ou pire, quelqu'un doit se rendre sur le site. Dans cet article, je vais expliquer exactement comment une carte mère correctement conçue détecte un modem bloqué, coupe son alimentation et le ramène à la vie — le tout sans intervention humaine.
Table des matières
Comment le “ circuit intégré de gestion de l'alimentation ” (PMIC) détecte-t-il un modem bloqué qui consomme toujours du courant ?
Un module 4G bloqué est délicat. Il tire toujours du courant du rail d'alimentation. Les LED peuvent encore s'allumer. De l'extérieur, il semble vivant. Mais il ne répond à rien.
La carte mère ne se fie pas uniquement à la détection de courant. Au lieu de cela, un MCU basse consommation envoie périodiquement des commandes AT2 au module 4G via UART3. Si le module ne répond pas après plusieurs tentatives consécutives, le MCU le déclare “ mort ” et déclenche la séquence de coupure d'alimentation.

Pourquoi la surveillance du courant seule ne suffit pas
Vous pourriez penser : “ Si le module plante, sa consommation de courant changera. ” Parfois, c'est le cas. Mais dans de nombreux scénarios de plantage, le module continue de consommer 200–400 mA — un courant de veille parfaitement normal. Le PMIC ne voit rien de mal. Le rail de tension reste stable. Le courant semble correct. Mais le firmware du module est bloqué dans une boucle infinie ou un blocage de pile de protocoles.
C'est pourquoi les bonnes conceptions utilisent un détection basée sur les battements cardiaques4 méthode au lieu de — ou en plus de — la surveillance actuelle.
Comment fonctionne le système de battements cardiaques
Voici le flux de détection typique :
| Étape | Action | Délai d'attente |
|---|---|---|
| 1 | Le MCU envoie AT une commande via UART | Attendre 3 secondes pour une réponse |
| 2 | Aucune réponse → Le MCU réessaie | Réessayer jusqu'à 5 fois (15 secondes au total) |
| 3 | Tous les essais échouent → Le MCU envoie AT+CFUN=1,1 (redémarrage logiciel) | Attendre 60 secondes pour que le module se réenregistre |
| 4 | Toujours aucune réponse → Le MCU déclenche un cycle d'alimentation forcé | Couper le VCC pendant 2 à 5 secondes, puis rétablir |
Le MCU fonctionne sur sa propre horloge. Il ne dépend pas du processeur Linux principal. Même si le processeur principal se bloque également, le MCU de surveillance continue de fonctionner. C'est un circuit complètement indépendant — souvent une petite puce comme une STM8 ou une LPC810 qui coûte moins de 0,50 $.
Le rôle du PMIC dans ce processus
Le PMIC lui-même ne “décide” pas de couper l'alimentation. Il fournit simplement les rails de tension. Le décideur est le MCU de surveillance. Le MCU contrôle un interrupteur de charge MOSFET5 situé entre la sortie du PMIC et l'entrée VCC du module 4G. Lorsque le MCU met la grille du MOSFET à l'état haut, l'interrupteur s'ouvre. L'alimentation du module tombe à zéro. Après un délai chronométré (généralement 2 à 5 secondes), le MCU relâche la grille. L'alimentation revient. Le module démarre à froid à partir de zéro.
Pourquoi le délai est important
Vous ne pouvez pas simplement couper et rétablir l'alimentation instantanément. Le module 4G possède des condensateurs internes. Si vous rétablissez l'alimentation trop rapidement, ces condensateurs retiennent encore une charge résiduelle. L'état interne du module ne s'efface pas complètement. Il pourrait redémarrer dans le même état de plantage. Un délai de 2 à 5 secondes garantit que chaque condensateur se décharge complètement. Le module revient à un véritable état de “mise sous tension d'usine”. C'est la différence entre un vrai cycle d'alimentation et un faux.
Dans nos conceptions chez Loyalty-Secu, nous avons défini ce délai à 3 secondes par défaut. Nous avons testé des délais plus courts et avons constaté que certains modules — en particulier par temps froid — ont besoin des 3 secondes complètes pour se décharger correctement.
Existe-t-il une “ broche de réinitialisation ” dédiée connectée entre le CPU et le matériel du module 4G ?
Je pensais auparavant que la broche RESET suffisait. La mettre à l'état bas, attendre un moment, la relâcher, et le module redémarre. Cela fonctionne — la plupart du temps. Mais “la plupart du temps” n'est pas suffisant pour une caméra installée sur un poteau au milieu d'un désert.
Oui, la plupart des modules 4G ont une broche matérielle RESET6, et une carte mère bien conçue la connectera à un GPIO du processeur principal ou à un MCU de surveillance. Mais la broche RESET n'est que la première ligne de défense. Elle ne peut pas résoudre tous les plantages. Une coupure d'alimentation VCC complète est la solution de secours ultime.

Ce que fait réellement la broche RESET
La broche RESET déclenche un redémarrage interne du processeur du module. C'est similaire à appuyer sur le bouton de redémarrage de votre ordinateur. Le firmware du module se recharge depuis la mémoire flash. Le processeur de bande de base se réinitialise. L'enregistrement réseau recommence.
Pour la plupart des plantages au niveau logiciel — comme un processus de connexion bloqué ou un délai d'attente de résolution DNS — cela fonctionne bien. Le module revient en ligne en 20 à 40 secondes.
Quand la broche RESET échoue
Mais il existe des situations où la broche RESET ne peut pas aider :
| Type de défaillance | Ce qui se passe | La broche RESET peut-elle résoudre le problème ? |
|---|---|---|
| Verrouillage (Latch-up) | Une décharge statique ou une surtension provoque un effet SCR parasite à l'intérieur du module. Le courant circule par des chemins non intentionnels. | ❌ Non. Le circuit interne est électriquement verrouillé. Seule une coupure d'alimentation complète peut briser le verrouillage. |
| Verrouillage par sous-tension (brownout lock) | Le module a tenté de transmettre à haute puissance, le courant a augmenté, la tension est tombée en dessous du minimum, et le module est entré dans un état indéfini. | ❌ Non. Le module est bloqué entre “marche” et “arrêt”. La logique de RESET elle-même peut ne pas fonctionner à cette tension. |
| Corruption de la mémoire flash | Une fluctuation de courant lors de l'écriture du firmware a corrompu le secteur de démarrage. Le module ne peut pas du tout charger son firmware. | ❌ Non. Le module boucle indéfiniment au stade du chargeur de démarrage. RESET redémarre simplement la même boucle défectueuse. |
Dans les trois cas, la seule solution est de couper complètement l'alimentation du module. C'est pourquoi un commutateur de charge MOSFET sur la ligne VCC n'est pas facultatif — il est essentiel.
La stratégie de récupération en trois étapes
Une carte mère correctement conçue utilise une escalade en trois étapes:
- Étape 1 — Réinitialisation logicielle : Envoyer
AT+CFUN=1,1ouAT+QPOWD=0via UART. Cela demande au module de redémarrer poliment. Attendre 60 secondes. - Étape 2 — Réinitialisation par broche : Mettre la broche RESET ou PWRKEY à l'état bas pendant 1 seconde, puis relâcher. Cela force un redémarrage au niveau matériel sans couper l'alimentation. Attendre 60 secondes.
- Étape 3 — Cycle d'alimentation forcé : Couper VCC via le commutateur MOSFET. Maintenir pendant 3 secondes. Rétablir l'alimentation. Attendre 90 secondes pour le démarrage complet et l'enregistrement réseau.
Si l'étape 3 échoue également après 3 tentatives consécutives en moins de 10 minutes, le système doit cesser d'essayer et enregistrer un défaut matériel critique. Cela évite une boucle de redémarrage infinie qui pourrait endommager le module ou vider une batterie solaire.
Chez Loyalty-Secu, nous câblons à la fois la broche RESET et la broche PWRKEY7 1. pour séparer les GPIO sur le MCU du chien de garde. Cela nous donne un contrôle indépendant sur chaque signal. Nous ne les acheminons pas via le processeur Linux principal, car si Linux lui-même plante, nous avons toujours besoin que le chien de garde agisse.
Cette fonctionnalité empêchera-t-elle les “ appareils zombies ” qui restent alimentés mais sont inaccessibles ?
“2. ” Périphériques zombies » — c'est exactement ce que mes clients appellent. Le panneau solaire continue de charger. Le boîtier de la caméra reste chaud. La LED d'état clignote en vert. Mais la liaison 4G est morte. Le périphérique est un fantôme sur le réseau. Vous ne pouvez pas le voir. Vous ne pouvez pas le contrôler. Il est juste là, consommant de l'énergie et ne faisant rien.
3. Oui, une carte mère avec un chien de garde indépendant et un circuit d'alimentation 4G éliminera les périphériques zombies. Le chien de garde détecte la défaillance de communication en 90 secondes et force un cycle d'alimentation complet. Dans la plupart des cas, le module 4G récupère et se réenregistre sur le réseau en 3 minutes — sans aucune intervention humaine.

5. Pourquoi les périphériques zombies sont si chers
6. Le périphérique lui-même peut coûter 300 à 500 $. Mais le coût d'un périphérique zombie est bien plus élevé. Considérez ce scénario : vous déployez 50 caméras PTZ solaires le long d'un pipeline de 200 kilomètres dans l'ouest du Texas. Trois mois plus tard, 4 d'entre elles tombent en panne. Votre centre de surveillance ne voit rien de ces 4 sites. Vous envoyez un technicien. Le trajet prend 6 heures aller-retour. Le technicien arrive, débranche le câble d'alimentation, attend 10 secondes, le rebranche. La caméra se remet en ligne. Coût total de cette visite “ débrancher et rebrancher ” : 800 à 1 200 $ en main-d'œuvre, carburant et perte de productivité.
7. Multipliez maintenant cela par 4 caméras. Et cela se reproduit le mois suivant. Et le mois d'après.
8. Comment fonctionne la boucle de récupération automatique
9. Une carte mère avec une conception de chien de garde appropriée exécute une boucle de surveillance continue :
- 10. Toutes les 10 secondes, le MCU du chien de garde vérifie si le module 4G répond à une commande de base.
AT11. Toutes les 30 secondes, il vérifie si le module a une adresse IP valide et peut atteindre le serveur cloud (via un ping léger ou un keepalive MQTT). - 12. Si les deux vérifications échouent pendant 90 secondes consécutives, la séquence de récupération commence.
- 13. Ce qui se passe pendant la récupération.
14. Le système suit l'escalade en trois étapes que j'ai décrite précédemment. Mais il y a un ajout important pour la prévention des zombies :
15. le chien de garde surveille également la récupération elle-même. 16. Si le module revient en ligne mais se déconnecte à nouveau dans les 5 minutes, le chien de garde compte cela comme une « récupération instable ». Après 3 récupérations instables, le système passe à un.
17. . Il éteint complètement le module 4G et attend 30 minutes avant de réessayer. Cela évite la décharge de la batterie sur les systèmes alimentés par énergie solaire. mode veille basse consommation. 18. Impact réel sur les coûts de maintenance.
19. Sans cycle d'alimentation automatique
| Scénario | Sans cycle d'alimentation automatique | Avec cycle d'alimentation automatique |
|---|---|---|
| Visites annuelles du site par 50 caméras | 30 à 50 visites | 2 à 5 visites (uniquement pour les pannes matérielles réelles) |
| Coût moyen par visite | 800 $ – 1 200 $ | 800 $ – 1 200 $ |
| Coût de maintenance annuel | 24 000 $ – 60 000 $ | 1 600 $ – 6 000 $ |
| Disponibilité de l'appareil | 85–92 % | 98–99,5 % |
Ces chiffres proviennent des retours réels que nous recevons des intégrateurs déployant nos systèmes PTZ solaires dans des zones reculées du Moyen-Orient et de l'Amérique du Nord. La fonction de cycle d'alimentation automatique seule peut réduire les coûts de maintenance sur le terrain de 80 % ou plus.
La promesse “ maintenance zéro ”
Pour les déploiements hors réseau — caméras solaires sur les fermes, les chantiers de construction, les champs pétrolifères ou les falaises côtières — cette fonction est ce qui rend la “ maintenance zéro ” possible. La caméra s'occupe d'elle-même. Elle détecte sa propre panne 4G. Elle se répare. Elle enregistre l'événement. Et elle reprend le travail. Pas d'appel téléphonique. Pas de déplacement. Pas d'interruption de service.
La carte mère enregistre-t-elle ces événements de “ crash et récupération ” pour mon audit technique ?
Lorsque je parle aux intégrateurs de systèmes, ils posent toujours la même question après que j'ai expliqué la fonction de récupération automatique : “ Cela semble formidable, mais puis-je voir ce qui s'est passé ? ” Ils ont besoin de preuves. Ils ont besoin de journaux. Leurs clients finaux — agences gouvernementales, compagnies d'électricité, entreprises de construction — exigent des pistes d'audit.
Oui, une carte mère bien conçue enregistre chaque événement de crash et de récupération avec un horodatage, le type de panne, l'étape de récupération qui a réussi, et la force du signal du module avant et après l'événement. Ces journaux sont stockés localement et peuvent être envoyés à un serveur cloud via MQTT ou HTTP.

Ce qui est enregistré
Le MCU watchdog et le processeur principal travaillent ensemble pour enregistrer des données d'événements détaillées. Une entrée de journal typique comprend :
- Horodatage : Date et heure de la défaillance détectée (synchronisé via NTP ou GPS).
- Type de défaillance : Timeout AT, perte de battement de cœur, erreur UART ou IP inaccessible.
- Stade de récupération : Quel stade a résolu le problème — réinitialisation logicielle, réinitialisation par broche ou cycle d'alimentation complet.
- Durée : Combien de temps le module a été hors ligne avant la fin de la récupération.
- Qualité du signal : Valeurs RSSI et SINR avant le crash et après la récupération.
- Compteur cumulé : Nombre total de cycles d'alimentation depuis le dernier démarrage du système.
Ces journaux sont stockés localement et peuvent être envoyés à un serveur cloud via MQTT8 ou HTTP.
Pourquoi les journaux sont importants pour votre entreprise
Si vous êtes un intégrateur système vendant un contrat de maintenance de 3 ans, vous devez prouver que votre système est fiable. Lorsque votre client demande : “ Pourquoi la caméra 17 était-elle hors ligne pendant 4 minutes mardi dernier à 3 heures du matin ? ” — vous devez avoir une réponse. Sans journaux, vous n'avez rien. Avec des journaux, vous pouvez leur montrer : “ Le module 4G a perdu son enregistrement réseau en raison d'un transfert de station de base. Le chien de garde a détecté la défaillance en 90 secondes. Une réinitialisation logicielle l'a résolu. Temps d'arrêt total : 3 minutes 42 secondes. Aucune donnée n'a été perdue car la caméra a mis en cache 4 minutes de vidéo localement et l'a téléchargée après la récupération. ”
Ce niveau de transparence renforce la confiance. Il transforme une plainte potentielle en une preuve de qualité.
Comment accéder aux journaux
La plupart des systèmes offrent plusieurs méthodes d'accès :
- Interface Web : Connectez-vous à l'interface utilisateur Web locale de la caméra et téléchargez le journal des événements sous forme de fichier CSV.
- Notification push cloud : La caméra envoie chaque événement à votre plateforme cloud via MQTT ou HTTP POST en temps réel.
- Événements ONVIF : Certains firmwares avancés mappent ces événements de récupération à ONVIF9 des notifications d'événements, afin que votre VMS (comme Milestone ou Blue Iris) puisse les afficher directement.
- Stockage local : Les journaux sont également écrits sur l'eMMC ou la carte SD intégrée, de sorte que même si la liaison 4G est interrompue, les données sont conservées.
Ce qu'il faut demander à votre fournisseur
Lorsque vous évaluez une caméra PTZ pour un déploiement à distance, posez ces questions spécifiques :
- “ Votre carte mère dispose-t-elle d'un MCU watchdog indépendant qui surveille le module 4G ? ”
- “ Le watchdog peut-il physiquement couper l'alimentation du module 4G — pas seulement envoyer un signal de réinitialisation ? ”
- “ Où sont stockés les journaux de crash et de récupération, et comment puis-je y accéder à distance ? ”
- “ Quel est le nombre maximum de cycles d'alimentation automatiques avant que le système ne s'arrête et ne signale un défaut matériel ? ”
Si le fournisseur ne peut pas répondre clairement à ces questions, sa carte n'a probablement pas cette fonctionnalité. Et cela signifie que chaque module 4G bloqué nécessitera une intervention sur site.
Chez Loyalty-Secu, nous intégrons ces capacités dans notre conception de carte mère dès le départ. Notre MCU watchdog, notre commutateur d'alimentation MOSFET et notre logique de récupération à trois étages sont standard sur toutes nos plateformes PTZ solaires 4G. Nous fournissons également des journaux d'événements complets accessibles via notre API cloud ou l'interface Web locale de la caméra. Parce que nous contrôlons l'ensemble de la chaîne d'approvisionnement verticale — de la conception du PCB à l'assemblage final — nous pouvons personnaliser le délai d'attente du watchdog, les délais de récupération et les formats de journaux pour répondre aux exigences de votre projet.
Conclusion
Une carte mère peut forcer un cycle d'alimentation sur un module 4G bloqué — mais seulement si elle dispose d'un MCU watchdog indépendant et d'un interrupteur d'alimentation matériel. Exigez les deux dans les spécifications de votre prochain projet.
1. Un microcontrôleur dédié qui surveille l'état du système et peut forcer une réinitialisation matérielle ou un cycle d'alimentation. ︎↩︎ 2. Commandes standardisées utilisées pour contrôler les modems, y compris les modules cellulaires, via une interface série. ︎↩︎ 3. Une interface de communication série couramment utilisée pour connecter des microcontrôleurs à des modems. ︎↩︎ 4. Une technique de surveillance qui utilise des signaux périodiques pour vérifier qu'un système ou un composant répond. ︎↩︎ 5. Un circuit basé sur MOSFET qui peut allumer ou éteindre l'alimentation d'un appareil sous contrôle logique. ︎↩︎ 6. Une broche matérielle sur un microcontrôleur ou un module qui déclenche un redémarrage de sa logique interne. ︎↩︎ 7. Une broche de contrôle sur les modules cellulaires qui est mise à l'état bas pour initier une séquence de mise sous tension ; souvent utilisée pour réinitialiser le module. ︎↩︎ 8. Un protocole de messagerie léger de type publication-abonnement conçu pour les appareils IoT et les réseaux à faible bande passante. ︎↩︎ 9. Une norme ouverte pour les produits de sécurité basés sur IP, permettant l'interopérabilité entre les caméras et les systèmes de gestion vidéo. ︎↩︎