X-Received: by 2002:a05:6214:20ac:: with SMTP id 12mr3806589qvd.12.1642251362836;
        Sat, 15 Jan 2022 04:56:02 -0800 (PST)
X-Received: by 2002:a9d:6452:: with SMTP id m18mr10071045otl.99.1642251362366;
 Sat, 15 Jan 2022 04:56:02 -0800 (PST)
Path: ...!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: fr.sci.electronique
Date: Sat, 15 Jan 2022 04:56:02 -0800 (PST)
In-Reply-To: <slrnsu53ar.bbo.JKB@hilbert.systella.fr>
Injection-Info: google-groups.googlegroups.com; posting-host=2a01:cb1c:f17:900:3521:61be:e750:b660;
 posting-account=q7TWSwoAAACOGlDiqgPG6hvLEUJmQy4p
NNTP-Posting-Host: 2a01:cb1c:f17:900:3521:61be:e750:b660
References: <slrnsu53ar.bbo.JKB@hilbert.systella.fr>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b4266b40-00e2-44ab-82f0-16d1788d8774n@googlegroups.com>
Subject: =?UTF-8?Q?Re=3A_Gestion_de_l=27=C3=A9nergie_sur_puve_GNSS_CAM=2DM8?=
From: ptilou <ptilou@gmail.com>
Injection-Date: Sat, 15 Jan 2022 12:56:02 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bytes: 5777
Lines: 117

je vois que t=E2=80=99ai toujours dans la litt=C3=A9rature =E2=80=A6
ben le sch=C3=A9ma !


Le samedi 15 janvier 2022 =C3=A0 10:01:16 UTC+1, JKB a =C3=A9crit=C2=A0:
> Bonjour =C3=A0 tous,=20
>=20
> Je suis en train de peaufiner la gestion de l'=C3=A9nergie sur un syst=C3=
=A8me=20
> embarqu=C3=A9 utilisant une puce GPS CAM-M8. J'observe des choses=20
> =C3=A9tranges et pour l'instant, le support du fondeur ne m'est d'aucun=
=20
> secours. Je ne sais pas si dans ce lieu quelqu'un a d=C3=A9j=C3=A0 =C3=A9=
t=C3=A9=20
> confront=C3=A9 au probl=C3=A8me, mais on ne sait jamais.=20
>=20
> La puce fonctionne parfaitement, je me suis tap=C3=A9 tout le protocole=
=20
> UBX, je n'ai aucun probl=C3=A8me de communication. Typiquement, j'utilise=
=20
> deux fonctions :=20
>=20
> void=20
> gnss_ubx_send_frame(uint8_t classe, uint8_t id,=20
> uint16_t longueur, void *charge)=20
> {=20
> }=20
>=20
> et=20
>=20
> uint8_t=20
> gnss_ubx_receive_frame(uint8_t *classe, uint8_t *id,=20
> uint16_t *longueur, void *charge, uint8_t timeout,=20
> uint8_t tentatives)=20
> {=20
> }=20
>=20
> qui empilent les commandes et les d=C3=A9pilent pour que les transactions=
=20
> soient coh=C3=A9rentes (la puce est capable d'entrelacer les r=C3=A9ponse=
s).=20
> C'est pour cela que la fonction de r=C3=A9ception poss=C3=A8de deux param=
=C3=A8tres=20
> timeout et tentatives. Si la trame correspond =C3=A0 classe et id, elle=
=20
> est retourn=C3=A9e, sinon, elle est empil=C3=A9e et retourn=C3=A9e =C3=A0=
 la prochaine=20
> requ=C3=AAte correspondant =C3=A0 classe/id (et naturellement retir=C3=A9=
e de la=20
> pile si le timeout est d=C3=A9pass=C3=A9).=20
>=20
> Ces deux fonctions sont parfaitement d=C3=A9bogu=C3=A9es.=20
>=20
> Sur le site du fabricant se trouve un fichier=20
> 'u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf' qui contient=20
> les protocoles utilis=C3=A9s pour parler au composant. J'utilise le=20
> protocole UBX sur bus SPI (1 MHz).=20
>=20
> Le syst=C3=A8me complet fonctionne soit sur une batterie de forte=20
> capacit=C3=A9 (typiquement une centaine d'Ah sous 12V), soit sur une=20
> alimentation de secours (1 Ah/7,2V). Je cherche donc =C3=A0 optimiser le=
=20
> fonctionnement sur l'alimentation de secours.=20
>=20
> Le syst=C3=A8me complet consomme actuellement 30 mA/12V au repos=20
> (typiquement, 8 mA pour les deux r=C3=A9gulateurs 5V et 3,3V, le reste=20
> pour le CPU et les composants autour. J'arrive =C3=A0 baisser cette=20
> consommation =C3=A0 12 mA en =C3=A9teignant le NFC). Mais _sans_ la puce =
GPS.=20
> Une fois cette puce active, je n'arrive pas =C3=A0 baisser la=20
> consommation en-dessous de 50 mA sur 12V, ce qui est =C3=A9norme. Et=20
> cette consommation minimale ne semble pas d=C3=A9pendre de l'=C3=A9tat du=
=20
> champ powerSetupValue de UBX-CFG-PMS (page 210 de la doc).=20
>=20
> Typiquement, lorsque je suis en veille sur la batterie principale,=20
> je mets le composant dans le mode "aggressive with 4Hz". Je lis donc=20
> l'=C3=A9tat du composant avec une trame de la classe 0x06 et l'id 0x86,=
=20
> je positionne dans la trame lu powerSetupValue =C3=A0 0x05, period et=20
> onTime =C3=A0 0 et je renvoie le tout =C3=A0 la puce qui me r=C3=A9pond O=
K. Sauf=20
> que je ne vois aucune diff=C3=A9rence avec la consommation 0x00 (Full=20
> Power). J'ai pouss=C3=A9 le vice =C3=A0 positionner powerSetupValue =C3=
=A0 0x02,=20
> period =C3=A0 600 et onTime =C3=A0 60, l=C3=A0 encore le composant me r=
=C3=A9pond OK,=20
> mais la consommation reste identique =C3=A0 celle qu'elle =C3=A9tait en "=
Full=20
> Power". Je suppose qu'il y a un truc qui m'a =C3=A9chapp=C3=A9, mais je n=
e=20
> vois vraiment pas quoi, d'autant que le composant r=C3=A9pond bien qu'il=
=20
> accepte la commande !=20
>=20
> J'ai sacrifi=C3=A9 un piste en collant un amp=C3=A9rem=C3=A8tre sur l'ali=
mentation=20
> de la puce GPS, c'est bien elle qui consomme et cette consommation=20
> ne varie pas.=20
>=20
> Dans le m=C3=AAme ordre d'id=C3=A9e, j'essaie aussi d'=C3=A9teindre la le=
d de=20
> synchronisation en utilisant la trame 0x0631 en modifiant la valeur=20
> pulseLenRatioLock qui ne semble pas avoir l'effet escompot=C3=A9. C'est=
=20
> assez =C3=A9trange parce que je n'ai aucun autre probl=C3=A8me avec ce=20
> composant...=20
>=20
> Si quelqu'un avait la moindre id=C3=A9e, je suis preneur.=20
>=20
> Bien cordialement,=20
>=20
> JKB=20
>=20
> --=20
> Si votre demande me parvient en code 29, je vous titiouillerai volontiers=
=20
> une r=C3=A9ponse.