[pucpood]

Bonjour, c'est encore Pucpood et ses questions de vieux débutant !

Je développe un outil sur une base de PIC24FJ couplé à un Bluetooth RN4678.
J'utilise ce BT en mode classique SPP.
Je parviens à échanger des données proprement avec une appli mobile Android, mais le débit est très mauvais.

En moyenne, j'ai un débit d'environ 70 octets par seconde. Ça me semble très bas.
Côté PIC, mon UART est réglée sur 57600 bauds (au-delà, ça devient n'importe quoi à partir de 7 ou 8 octets reçus).
Côté Android : je n'ai pas la maîtrise. Mais même à 9600 bauds, ça ferait quand-même encore environ 1200 octets par secondes.

Je veux bien que les traitements entre chaque envoi (de 62 octets) prennent un peu de temps de part et d'autre, mais on parle de 1/100èmes de secondes.
Je veux bien aussi que la couche radio du BT ajoute quelques octets, mais de là à passer de 1200 BPS à 70 BPS ...

Serais-je passé à côté de quelque-chose de flagrant sur la config de ma plateforme PIC/RN ?

Au plaisir !

[pucpood]

Hello,

J'ai fait d'autres essais d'échanges Bluetooth, mais avec un PC. Le débit y est meilleur, même si modeste, tout n'est donc pas à mettre sur le dos de ma plateforme. J'ai pu constater en effet que sous Android, l'outil "socket" proposé par notre outil de dev est vraiment lent. Je vais essayer d'autres outils.

Néanmoins, je suis un peu contrarié par les dysfonctionnements qui apparaissent à partir de 115200 bauds alors que sur le papier on peut aller beaucoup plus vite, aussi bien côté PIC24FJ que du côté RN4678.

Je suis en contrôle de flux matériel, qui fonctionne parfaitement à 57600 bauds.
Les problèmes sont là aussi bien mode "transparent" qu'en mode "command" (CMD).

Qu'est-ce qui pourrait expliquer une dérive des communications via l'UART au-dessus de cette vitesse, dès le 7ème ou 8ème octet ?

Bonne journée !