Port série

[Ollivier]

Salut MetalOS,

tu obtiens quelle version avec <GETVER>> ?

Si c'est un 500, voici une doc plus récente : (+ : thermomètre, gyroscope, etc...)

Bon et case se plante (désolé case de te rayer le disque, vu le temps d'aide que tu y consacres aussi) : PeekW ne te donnera pas la bonne valeur pour 2 raisons
1) PeekW est signé (signe mathématique, pas "signature) alors que ton périph retourne du non signé
2) PeekU est certes non signé mais opère comme suit : Partie faible du nombre ("LSB") puis partie forte du nombre ("MSB"). Or ton périphérique fait le contraire : partie forte puis partie faible.

Conclusion : Pour un résultat de 16 bits de ton périphérique :

Code : Tout sélectionner

Valeur.I = PeekA(*Address) << 8 + PeekA(*Address + 1)

Il restera à trouver la structure "CONFIGURATION DATA" et tu auras fait un bon bout de chemin (notamment pour choisir la fréquence du streaming, le mode d'acquisition, mais aussi pour savoir la taille de la mémoire flash embarquée.

Code : Tout sélectionner

***************************************************
GQ-RFC1201

GQ Geiger Counter Communication Protocol
***************************************************
Ver 1.40    Jan-2015


Status of this Memo

   This document specifies a GQ GMC Geiger Counter Communication Protocol for the
   communication between GQ GMC Geiger Counter and a computer host via serial port, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) GQ Electronics LLC (2012).  All Rights Reserved.

Abstract

   This document defines a GQ GMC Geiger Counter Communication Protocol
   to support communication between GMC Geiger Counter and a computer host via serial port.  The protocol allows to send data request command from a computer host to a GQ GMC geiger counter. 


**************************
Serial Port configuration
**************************

For the GMC-300 V3.xx and earlier version, the serial port communication is based on a fixed baud rate.

Baud: 57600
Data bit: 8
Parity: None
Stop bit: 1
Control: None

For the GMC-300 Plus V4.xx and later version firmware,  115200 BPS is used.

For GMC-320, the serial port communication baud rate is variable. It should be one of the followings:

1200,2400,4800,9600,14400,19200,28800,38400,57600,115200 BPS.  The factory default is 115200 BPS.


**************************
Command format
**************************

A valid command start with ASCII '<'  and ended with ASCII '>>'. Both command and parameters are in between '<' and '>>'.

Command is a ASCII string. All parameters of command are true value in hexadecimal. 


Direction: All commands are initiated from computer(HOST).


**************************
Commands
**************************

1. Get hardware model and version

Command:  <GETVER>>


Return:   total 14 bytes ASCII chars from GQ GMC unit. It includes 7 bytes hardware model and 7 bytes firmware version.

	  e.g.:  GMC-300Re 2.10   

Firmware supported:  GMC-280, GMC-300 Re.2.0x, Re.2.10 or later


2. Get current CPM value


Command:  <GETCPM>>

Return:   A 16 bit unsigned integer is returned. In total 2 bytes data return from GQ GMC unit. The first byte is MSB byte data and second byte is LSB byte data.

	  e.g.: 00 1C     the returned CPM is 28.

Firmware supported:  GMC-280, GMC-300 Re.2.0x, Re.2.10 or later



3. Turn on the GQ GMC heartbeat

Note:     This command enable the GQ GMC unit to send count per second data to host every second automatically. 

Command:  <HEARTBEAT1>>

Return:   A 16 bit unsigned integer is returned every second automatically. Each data package consist of 2 bytes data from GQ GMC unit. The first byte is MSB byte data and second byte is LSB byte data.


	 e.g.: 10 1C     the returned 1 second count is 28.   Only lowest 14 bits are used for the valid data bit.  The highest bit 15 and bit 14 are reserved data bits.



Firmware supported:  GMC-280, GMC-300  Re.2.10 or later


4. Turn off the GQ GMC heartbeat


Command:  <HEARTBEAT0>>

Return:   None

Firmware supported:  Re.2.10 or later


5. Get battery voltage status


Command:  <GETVOLT>>

Return:   one byte voltage value of battery (X 10V)

          e.g.: return 62(hex) is 9.8V

Firmware supported:  GMC-280, GMC-300 Re.2.0x, Re.2.10 or later


6. Request history data from internal flash memory

Command:  <SPIR[A2][A1][A0][L1][L0]>>

	A2,A1,A0 are three bytes address data, from MSB to LSB.  The L1,L0 are the data length requested.  L1 is high byte of 16 bit integer and L0 is low byte.
	
	The length normally not exceed 4096 bytes in each request.
 
Return: The history data in raw byte array.

Comment: The minimum address is 0, and maximum address value is the size of the flash memory of the GQ GMC Geiger count. Check the user manual for particular model flash size.

Firmware supported:  GMC-300 Re.2.0x, Re.2.10 or later

 
7. Get configuration data

Command:  <GETCFG>>

Return: The configuration data.  Total 256 bytes will be returned.


Firmware supported:  GMC-280, GMC-300 Re.2.10 or later



8. Erase all configuration data 

Command:  <ECFG>>

Return: 0xAA 

Firmware supported: GMC-280, GMC-300 Re.2.10 or later


9. Write configuration data

Command:  <WCFG[A0][D0]>>
	
	A0 is the address and the D0 is the data byte(hex).  

Return: 0xAA 

Firmware supported: GMC-280, GMC-300 Re.2.10 or later



10. send a key

Command:  <key[D0]>>
	
	D0 is the key value from 0 to 3. It represents software key S1~S4.  
Return: none 

Firmware supported:  GMC-280, GMC-300 Re.2.0x, Re.2.10 or later

Note: for Re.2.11 or later, each key can be a ASCII string: <KEY0>>,<KEY1>>,<KEY2>>,<KEY3>>   


  
11. get serial number

Command: <GETSERIAL>>

Return: serial number in 7 bytes. 

Firmware supported: GMC-280, GMC-300 Re.2.11 or later



12. Power OFF

Command: <POWEROFF>>

Return: none

Firmware supported: GMC-280, GMC-300 Re.2.11 or later


13. Reload/Update/Refresh Configuration


Command: <CFGUPDATE>>

Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.20 or later


14. Set realtime clock year

command: <SETDATEYY[D0]>>

	D0 is the year value in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later


15. Set realtime clock month

command: <SETDATEMM[D0]>>

	D0 is the month value in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later


16. Set realtime clock day

command: <SETDATEDD[D0]>>

	D0 is the day of the month value in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later

17. Set realtime clock hour

command: <SETTIMEHH[D0]>>

	D0 is the hourvalue in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later

18. Set realtime clock minute

command: <SETTIMEMM[D0]>>

	D0 is the minute value in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later



19. Set realtime clock second

command: <SETTIMESS[D0]>>

	D0 is the second value in hexdecimal
	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.2.23 or later


20. Reset unit to factory default

command: <FACTORYRESET>>

	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.3.00 or later


21. Reboot unit

command: <REBOOT>>

	
Return: None

Firmware supported: GMC-280, GMC-300 Re.3.00 or later


22. Set year date and time

command: <SETDATETIME[YYMMDDHHMMSS]>>

	
Return: 0xAA

Firmware supported: GMC-280, GMC-300 Re.3.00 or later



23. Get year date and time

command: <GETDATETIME>>

	
Return: Seven bytes data: YY MM DD HH MM SS 0xAA

Firmware supported: GMC-280, GMC-300 Re.3.00 or later



24. Get temperature

command: <GETTEMP>>

Return: Four bytes celsius degree data in hexdecimal: BYTE1,BYTE2,BYTE3,BYTE4
	Here: BYTE1 is the integer part of the temperature.
	      BYTE2 is the decimal part of the temperature.
	      BYTE3 is the negative signe if it is not 0.  If this byte is 0, the then current temperture is greater than 0, otherwise the temperature is below 0.
`	      BYTE4 always 0xAA

Firmware supported: GMC-320 Re.3.01 or later


25. Get gyroscope data

command: <GETGYRO>>

Return: Seven bytes gyroscope data in hexdecimal: BYTE1,BYTE2,BYTE3,BYTE4,BYTE5,BYTE6,BYTE7
	Here: BYTE1,BYTE2 are the X position data in 16 bits value. The first byte is MSB byte data and second byte is LSB byte data.
	      BYTE3,BYTE4 are the Y position data in 16 bits value. The first byte is MSB byte data and second byte is LSB byte data.
	      BYTE5,BYTE6 are the Z position data in 16 bits value. The first byte is MSB byte data and second byte is LSB byte data.
	      BYTE7 always 0xAA

Firmware supported: GMC-320 Re.3.01 or later


26. Power ON

Command: <POWERON>>

Return: none

Firmware supported: GMC-280, GMC-300, GMC-320 Re.3.10 or later

[Ollivier]

code de 2017 (Attention : je n'ai rien vérifié pour la viralité des ZIPs proposés)

[MetalOS]

J'ai laissé tourner mon soft 30 minutes environs et les données ont toujours été juste avec mon code.

[Ollivier]

D'accord, alors je t'explique. Excepté la coquille de case avec son PeekW (ou PeekU) que tu dois remplacer par les 2 PeekA comme écrit plus haut ou ici:

Code : Tout sélectionner

Valeur.I = PeekA(*Address) << 8 + PeekA(*Address + 1)

, si tu ne suis pas la recommandation de case, tu ne récupères que le restant de la division par 256 de la valeur réelle.

Traduction : que tu sois chez toi ou à Tchernobyl, tu vas avoir quasiment les mêmes extrema (entre 0 et 255).

Comme dit case, ton ReadDataPorc() il doit lire DEUX octets, et non pas seulement "un" octet.

Ensuite, tu dois avoir PLUSIEURS procédures de lecture :
- une pour récupérer la string de 14 octets
- une pour récupérer les valeurs (les 2 octets ou 16 bits)
- une autre pour lire la "Configuration data"
- une autre pour lire l'historique embarqué (par paquets de 4096 octets)

Mais là ton

Code : Tout sélectionner

ReadDataPorc(bla, blibla, 1 seul octet)
youp = Str(unQuad)
yeah = Val(youp)

C'est fait pour aller pique-niquer éclairé par un daemon core.

[case]

@ollivier d'apres la doc

> Types non-signés (.a, .u et .c):
Purebasic offre des types non-signés pour les variables de type 'byte' et 'word' au travers des types 'ascii' (.a) et 'unicode' (.u).
Le type 'character'(.c) est 'word' non-signé en mode unicode.

un peekw dans une variable en .u renvoi biens la bonne valeur

Code : Tout sélectionner

*memory=AllocateMemory(2)
For a= 1 To 1000
  topoke=Random(65535,0) ; valeur sur 16bits
  PokeW(*memory,topoke) ; ecrit une valeur sur 2 octets
  peeked.u=PeekW(*memory) ; la variable est non signée je lis un word peekw
  Debug ""+topoke+"-->"+peeked
  
Next
freememory(*memory)

par contre l'ordre renvoyé par le compteur est peut etre inversé (endian, big endian) ou j'ai peux me fourvoyer en effet ^^

[Ollivier]

Salut case,

tout est exact à l'exception de cette petite phrase suivie du code qui ne démontre pas le signe d'un type Word en PB :

un peekw dans une variable en .u renvoi biens la bonne valeur

Code : Tout sélectionner

*memory=AllocateMemory(2)
For a= 1 To 1000
  topoke=Random(65535,0) ; valeur sur 16bits
  PokeW(*memory,topoke) ; ecrit une valeur sur 2 octets
  peeked.u=PeekW(*memory) ; la variable est non signée je lis un word peekw
  Debug ""+topoke+"-->"+peeked
  
Next
freememory(*memory)

Ta boucle For i arrête la démonstration à 1000, donc bien avant de tester le domaine négatif d'une valeur de 16 bits.

de 0 à 32767 => domaine positif
de 32768 à 65535 => domaine négatif
(virtuellement de -32768 à -1)

Code : Tout sélectionner

Define x.i
PokeU(@x, $ACDC) ; ACDC = Vieux gratteurs connus
Debug PeekU(@x) ; res. $ACDC = 54052
Debug PeekW(@x) ; res. -2CDC = - 11484 (si j'ai bien fait...)
Debug Hex(PeekW(@x) ) ; res. ACDC
Debug Hex(PeekA(@x + 0) ) ; res. DC partie traitée par MetalOS
Debug Hex(PeekA(@x + 1) ) ; res. AC partie négligée par MetalOS

Autrement dit, la suggestion de code pour récupérer 16 bits depuis son "Little endianness Geiger device" est :

Code : Tout sélectionner

ReadDataPort(#comPort, *buffer, 1+1)
value = PeekA(*buffer) << 8 + PeekA(*buffer + 1)

[MetalOS]

@Olivier

Le <GETVER>> chez moi retourne GMC-320 4.06. Le 500 et un boitier plus récent mais la majorité des commandes et identique à la plupart des models sauf pour certains qui ne sont pas équipé de wifi.

Après je comprend vos arguments que je ne conteste pas du tous, je dit juste que si je modifie mon code avec vos recommandations même avec PeekA je n'obtient pas les même valeur que mon boitier. Si mon boitier affiche 12 CPM avec vos recommandation j’obtiens 3250 CPM.

Que si j'utilise mon code le boitier Affiche 12 CPM et le logiciel affiche 12 CPM aussi.

Sinon oui je compte utiliser une procédure par donnée demandé (température, configuration data...)

[Ollivier]

1ère hypothèse : les docs sont fausses et le "Geiger device" te retourne un format string ou "fixed string"

2nde hypothèse : peut-être que c'est vraiment un rapport d'échelle avec 3250 / 256 qui donne 12. Le cas échéant, ton retour de données est réglé pour être 256 fois plus précis que l'afficheur.

Merci pour la version de l'appareil : ça permet de se focaliser en cas de nouvelle doc.

Est-ce que tu peux récupérer quelques valeurs hexa d'état de buffer sur 8 octets (un quad) ?

Ça permettra d'enlever quelques doutes.

[Ollivier]

Et une doc en français pour le GMC 320+ !!

edit : ahm...rde, c'est juste la doc de l'utilisation de l'appareil. Bon ben je repars la quenouille perdue dans le tas de lin...

[MetalOS]

J'attends une réponse du constructeur pour avoir la dernière version du protocole de communication, mais pas de nouvelles pour le moment. Je vais essayer d'envoyer un message sur le forum du support technique. Je te retiens au courant.

[Ollivier]

Ben pour toutes les commandes qui renvoient une chaîne ou des valeurs, ça semble facilement normalisable avec une étude hexa de ce qui est retourné.

Mais c'est la "configuration data" de 256 octets qui n'est pas documentée (structure). Ainsi que la structure des paquets de 4096 octets pour lire l'historique depuis la mémoire flash. Acquérir ces paquets, c'est ok, mais savoir exactement ce qu'ils contiennent, c'est autre chose, et c'est sûrement documenté avec la "configuration data".

[Ollivier]

Ah... Beh... Comme qui dirait l'expression << J'aurai voulu, que j'aurai pas pu >>, (hehe!) voici la structure de la "configuration data" de ton compteur Geiger !

Et merci qui ? Merci Jacky et Google !

Source

Code : Tout sélectionner

typedef enum {
CFG_PowerOnOff,
CFG_AlarmOnOff, //1
CFG_SpeakerOnOff,
CFG_IdleDisplayMode,
CFG_BackLightTimeoutSeconds,
CFG_IdleTitleDisplayMode,
CFG_AlarmCPMValueHiByte, //6
CFG_AlarmCPMValueLoByte,
CFG_CalibrationCPMHiByte_0,
CFG_CalibrationCPMLoByte_0,
CFG_CalibrationuSvUcByte3_0,
CFG_CalibrationuSvUcByte2_0, //11
CFG_CalibrationuSvUcByte1_0,
CFG_CalibrationuSvUcByte0_0,
CFG_CalibrationCPMHiByte_1,
CFG_CalibrationCPMLoByte_1, //15
CFG_CalibrationuSvUcByte3_1,
CFG_CalibrationuSvUcByte2_1,
CFG_CalibrationuSvUcByte1_1,
CFG_CalibrationuSvUcByte0_1,
CFG_CalibrationCPMHiByte_2, //20
CFG_CalibrationCPMLoByte_2,
CFG_CalibrationuSvUcByte3_2,
CFG_CalibrationuSvUcByte2_2,
CFG_CalibrationuSvUcByte1_2,
CFG_CalibrationuSvUcByte0_2, //25
CFG_IdleTextState,
CFG_AlarmValueuSvByte3,
CFG_AlarmValueuSvByte2,
CFG_AlarmValueuSvByte1,
CFG_AlarmValueuSvByte0, //30
CFG_AlarmType,
CFG_SaveDataType,
CFG_SwivelDisplay,
CFG_ZoomByte3,
CFG_ZoomByte2, //35
CFG_ZoomByte1,
CFG_ZoomByte0,
CFG_SPI_DataSaveAddress2,
CFG_SPI_DataSaveAddress1,
CFG_SPI_DataSaveAddress0, //40
CFG_SPI_DataReadAddress2,
CFG_SPI_DataReadAddress1,
CFG_SPI_DataReadAddress0,
CFG_nPowerSavingMode,
Reserved_1, //45
Reserved_2,
Reserved_3,
CFG_nDisplayContrast,
CFG_MAX_CPM_HIBYTE,
CFG_MAX_CPM_LOBYTE, //50
Reserved_4,
CFG_nLargeFontMode,
CFG_nLCDBackLightLevel,
CFG_nReverseDisplayMode,
CFG_nMotionDetect, //55
CFG_bBatteryType,
CFG_nBaudRate,
Reserved_5,
CFG_nGraphicDrawingMode,
CFG_nLEDOnOff, //60
Reserved_6,
CFG_nSaveThresholdValueuSv_m_nCPM_HIBYTE,
CFG_nSaveThresholdValueuSv_m_nCPM_LOBYTE,
CFG_nSaveThresholdMode,
CFG_nSaveThresholdValue3, //65
CFG_nSaveThresholdValue2,
CFG_nSaveThresholdValue1,
CFG_nSaveThresholdValue0,

CFG_SSID_0,
//...
CFG_SSID_31 = CFG_SSID_0 + 31, //68 + 31

CFG_Password_0, //100
//...
CFG_Password_31 = CFG_Password_0 + 31, //100 + 31

CFG_Website_0, //132
//....
CFG_Website_31 = CFG_Website_0 + 31, //132 + 31

CFG_URL_0, //163
//....
CFG_URL_31 = CFG_URL_0 + 31, //163 + 31

CFG_UserID_0, //195
//...........
CFG_UserID_31 = CFG_UserID_0 + 31, //195+31

CFG_CounterID_0, //227
//....
CFG_CounterID_31 = CFG_CounterID_0 + 31, //227 + 31

CFG_Period, //259
CFG_WIFIONOFF, //260
CFG_TEXT_STATUS_MODE,


/
CFG_Save_DateTimeStamp, //this one uses 6 byte space

CFG_MaximumCFGBytes,

}EEPROMDATAT;

Petit extra sur la page en question concernant l'historique (historic data) :

For GMC-500, GMC-600 history data C code structure:
(this should be same as GMC-300, no change)
In history data, it start with 0x55AA00 prefixed for timestamp and followed by the date time data. and then always followed by 0x55AA and one of the bellow data length byte.

typedef enum
{
YYMMDDHHMMSS, // Time Stamp
DOUBLEBYTE_DATA, //the data are double bytes
THREEBYTE_DATA, //the data are three bytes
FOURBYTE_DATA, //the data are four bytes
LOCATION_DATA, //the data is a text string,the first byte data is the length of the text, followed by the text

TOTAL_EEPROM_SAVE_TYPE

}HistoryDataFormatMarkingT;


Also, the 0x55AA also can follow a one of following history data type:
typedef enum
{
SAVEOFF,
SECONDLY,
MINUTETLY,
HOURLY,
SaveByThresholdSecond, //only save the data if exceed the preset threshold value
SaveByThresholdMinute, //only save the data if exceed the preset threshold value

TotalSavedType

}SaveDataTypeT;

[MetalOS]

Salut Olivier,

Sympa la trouvaille mais ça parle de choses que je ne maîtrise pas malheureusement. L'hexadecimal je n'y comprends rien

[case]

Salut Olivier,

Sympa la trouvaille mais ça parle de choses que je ne maîtrise pas malheureusement. L'hexadecimal je n'y comprends rien

c'est pas très grave de pas tout comprendre en hexadécimal mais dis toi simplement que cela permet de représenter un nombre de 0 a 255 (le contenu d'un octet ) avec 2 caractères

au lieu de compter jusqu'a 9 en decimal ( base 10) tu compte jusqu'a 15 en hexadecimal (base 16)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 1 2 3 4 5 6 7 8 9 a b c d e f

ce qui permet de 'facilement' convertir un octet depuis le binaire

par exemple un octet 00111111 ( decimal 63 )
tu peux le couper en 2x4 bits

0011 (3 en decimal ) 1111 (15 en decimal )
3=3(hexadecimal) 15=F(hexadecimal)

3F ce qui est plus lisible que du binaire.

pour convertir en décimal ensuite une multiplication et une addition suffisent

3*16 + 15 = 63

au final c'est juste une representation de la même chose.



00111111
63
3F
c'est la même chose mais ton ordi lui il comprend que le binaire.

[Ollivier]

Conversions décimal <-> hexa :

Code : Tout sélectionner

x = 65535
Debug Hex(x) ; conversion décimal -> hexa
a$ = "FF"
Debug Val("$" + a$) ; conversion hexa -> décimal