Discussion :

[giloutho]

Bonjour à tous,

Grâce à vos contributions j'ai développé un petit soft qui lit les données d'un GPS via le port série. J'ai déjà évoqué dans ces colonnes des problèmes de dysfonctionnement sur certains PC où l'on est obligé d'utiliser un émulateur série USB.

Le problème n'est pas reconnaitre le port série, TcomPort le fait très bien... Mais sur certains appareils je ne ramène aucune info. Le problème est à mon niveau car il existe un shareware (GPSDump) qui fonctionne parfaitement bien sur ces appareils.

J'ai donc décidé de creuser un peu plus le problème.

Le protocole est simple, j'envoie sur le port :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ComPort.WriteStr('$PBRSNP,*21'+#13#10);

et le GPS doit me répondre une phrase ($PBRSNP,5030, not set ,05132,1.11*36#0A) comprenant son numéro de série et autres infos

Ma form contient un TComPort et un TComDataPacket configuré avec un startstring à $ et un stopstring à *. Dans 90% des cas aucun problème cela marche nickel.

Pour essayer d'analyser mon problème j'ai décidé de me passer du TComDataPacket et là surprise je n'arrive pas à ramener quoique ce soit ( sur une prise qui marche évidemment !!! ). J'ai pris à la lettre le code du tuto... nada....

Je fais l'envoi de la phrase citée plus haut et j'éxecute le code du bouton btnRecevoirSync du tuto

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
begin
// MAJ composants
  btnRecevoirSync.Enabled := False;
  Memo1.Lines.Add('Début envoi synchrone');
  // Mise à jour du time out demandé     ( valeur en sec ici 3 que x 1000 )
  Comport.Timeouts.ReadTotalConstant := 3 * 1000;
  // Supression de ce qui traine dans le buffer d'entrée
  Comport.ClearBuffer(True,False);
  // Lecture bloquante de la longueur demandée ( ici 256 )
  Long:=Comport.ReadStr(Chaine,5);
  // MAJ composants
  Memo1.Lines.Add('Fin envoi synchrone '+IntToStr(Long)+' caractère(s) reçu(s):'+Chaine);
  btnRecevoirSync.Enabled := True;
end;

zéro caractères reçus... Etrange non ? J'ai en parallèle un espion de mon port série, et je voie bien que le GPS ne répond pas.

Quelqu'un a une idée ?

[Philippe Gormand]

Bonjour.

J'ai déja eu ce genre de problème avec TComPort.

Il faut paramétrer la propriété "SyncMethod" à la valeur "smNone". Problème
de synchronisation ?

[giloutho]

Merci philippe, mais cela ne marchait pas. J'ai mal interprété le tuto de Nono40 ( faut vraiment être c... car il est super bien fait ) et je me laissais abuser par mon spy du port série.

Résumons car cela servira peut être à d'autres ( je suis peut être pas le seul à être mauvais )

En envoyant une demande d'identification au GPS, je pensais que je verrais AUTOMATIQUEMENT sortir la réponse du GPS sur le monitoring de mon spy. Erreur c'est la façon dont on exploite ComPort qui déclenche la réponse.

1. J'envoie la phrase d'identification et je ne fais rien, on voit passer la demande sur le spy mais il n'y aura pas de réponse.

2. J'envoie la phrase d'identification et je place un TComdataPacket, cela configure le port en lui disant envoie ton schni, j'me débrouille avec ce qui arrive... même si je ne fais rien au niveau programme pour exploiter la trame reçue, je vois bien le GPS répondre sur le spy du port série

3. J'envoie la phrase d'identification et je place une procédure d'extraction dans l'évènement onRxChar, cela configure le port en lui disant envoie des caractères je vais m'en occuper. Idem, même si je ne fais rien au niveau programme pour exploiter correctement les caractères, le fait d'avoir placé dans cet évènement un ComPort.ReadStr déclenche une réponse du GPS vue sur le spy du port série.

Amitiés

[Philippe Gormand]

Salut.
Si tu as résolu ton problème, n'oublis pas de mettre la balise [Resolu]

Mais j'avais mal analysé ton problème.