Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.net!npeer.as286.net!npeer-ng0.as286.net!proxad.net!feeder1-1.proxad.net!cleanfeed3-b.proxad.net!nnrp4-2.free.fr!not-for-mail
Newsgroups: fr.sci.electronique
From: JKB <JKB@hilbert.invalid>
Subject: Gestion de =?UTF-8?Q?l=27=C3=A9nergie?= sur puve GNSS CAM-M8
Reply-To: <jkb@invalid>
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit
Message-ID: <slrnsu53ar.bbo.JKB@hilbert.systella.fr>
Date: 15 Jan 2022 09:01:15 GMT
Lines: 88
Organization: Guest of ProXad - France
NNTP-Posting-Date: 15 Jan 2022 10:01:15 CET
NNTP-Posting-Host: 62.212.98.88
X-Trace: 1642237275 news-3.free.fr 6448 62.212.98.88:47388
X-Complaints-To: abuse@proxad.net
Bytes: 4580

	Bonjour à tous,

	Je suis en train de peaufiner la gestion de l'énergie sur un système
	embarqué utilisant une puce GPS CAM-M8. J'observe des choses
	étranges et pour l'instant, le support du fondeur ne m'est d'aucun
	secours. Je ne sais pas si dans ce lieu quelqu'un a déjà été
	confronté au problème, mais on ne sait jamais.

	La puce fonctionne parfaitement, je me suis tapé tout le protocole
	UBX, je n'ai aucun problème de communication. Typiquement, j'utilise
	deux fonctions :

void
gnss_ubx_send_frame(uint8_t classe, uint8_t id,
		uint16_t longueur, void *charge)
{
}

	et

uint8_t
gnss_ubx_receive_frame(uint8_t *classe, uint8_t *id,
        uint16_t *longueur, void *charge, uint8_t timeout,
        uint8_t tentatives)
{
}

	qui empilent les commandes et les dépilent pour que les transactions
	soient cohérentes (la puce est capable d'entrelacer les réponses).
	C'est pour cela que la fonction de réception possède deux paramètres
	timeout et tentatives. Si la trame correspond à classe et id, elle
	est retournée, sinon, elle est empilée et retournée à la prochaine
	requête correspondant à classe/id (et naturellement retirée de la
	pile si le timeout est dépassé).

	Ces deux fonctions sont parfaitement déboguées.

	Sur le site du fabricant se trouve un fichier
	'u-blox8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf' qui contient
	les protocoles utilisés pour parler au composant. J'utilise le
	protocole UBX sur bus SPI (1 MHz).

	Le système complet fonctionne soit sur une batterie de forte
	capacité (typiquement une centaine d'Ah sous 12V), soit sur une
	alimentation de secours (1 Ah/7,2V). Je cherche donc à optimiser le
	fonctionnement sur l'alimentation de secours.

	Le système complet consomme actuellement 30 mA/12V au repos
	(typiquement, 8 mA pour les deux régulateurs 5V et 3,3V, le reste
	pour le CPU et les composants autour. J'arrive à baisser cette
	consommation à 12 mA en éteignant le NFC). Mais _sans_ la puce GPS.
	Une fois cette puce active, je n'arrive pas à baisser la
	consommation en-dessous de 50 mA sur 12V, ce qui est énorme. Et
	cette consommation minimale ne semble pas dépendre de l'état du
	champ powerSetupValue de UBX-CFG-PMS (page 210 de la doc).

	Typiquement, lorsque je suis en veille sur la batterie principale,
	je mets le composant dans le mode "aggressive with 4Hz". Je lis donc
	l'état du composant avec une trame de la classe 0x06 et l'id 0x86,
	je positionne dans la trame lu powerSetupValue à 0x05, period et
	onTime à 0 et je renvoie le tout à la puce qui me répond OK. Sauf
	que je ne vois aucune différence avec la consommation 0x00 (Full
	Power). J'ai poussé le vice à positionner powerSetupValue à 0x02,
	period à 600 et onTime à 60, là encore le composant me répond OK,
	mais la consommation reste identique à celle qu'elle était en "Full
	Power". Je suppose qu'il y a un truc qui m'a échappé, mais je ne
	vois vraiment pas quoi, d'autant que le composant répond bien qu'il
	accepte la commande !

	J'ai sacrifié un piste en collant un ampéremètre sur l'alimentation
	de la puce GPS, c'est bien elle qui consomme et cette consommation
	ne varie pas.

	Dans le même ordre d'idée, j'essaie aussi d'éteindre la led de
	synchronisation en utilisant la trame 0x0631 en modifiant la valeur
	pulseLenRatioLock qui ne semble pas avoir l'effet escompoté. C'est
	assez étrange parce que je n'ai aucun autre problème avec ce
	composant...

	Si quelqu'un avait la moindre idée, je suis preneur.

	Bien cordialement,

	JKB

-- 
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.