Application OSCILLOSCOPE avec WIN32 API

Bonjour,
Supposant un tableau de données receuilli d'un convertisseur A/N (CAN) d'une résolution de 12bits et avec Vref = 3.3V.

Code:

---

1 2	#define sample_count 1024 uint16_t data[sample_count];

---

J'arrive à tracer le graphe du signal en utilisant WIN32 API.
Je voudrais savoir, SVP, comment ajouter les options suivantes:
1- time/Div
2- Trigger avec choix de front mont/desc.
3- Volt/div
4- calcul de la fréquence et la valeur pic à pic.
Merci

Bonjour,

Où est le code ? Deux déclarations, c'est un peu court.

1. Time/div
C'est quoi le problème ? Tracer le graticule ? Il y a un CAN de 12 bits pour 3.3V. Ce CAN a également une fréquence d'échantillonnage, f_ech par exemple, et donc un temps entre 2 échantillons T_ech = 1 / f_ech. Une division correspond à n échantillons donc à n*T_ech. En général, on fixe n pour avoir un temps/division plus lisible par exemple de 0.5 ms/div, 1 ms/div etc.
2. Trigger
Comment est tracé le graphe ? Le premier élément est déterminé comment ? Si c'est un seul tracé, il n'y a pas de problème, mais si le signal est rafraichi régulièrement, il faut un point de déclanchement (au minimum seuil et sens de passage du seuil) pour que les divers tracés visuellement se superposent approximativement et restent ainsi lisibles. L'utilisation de sensiblement plus d'échantillons que ceux visualisés (par exemple le double) et/ou le bon usage d'un tampon circulaire, permettent de voir également les échantillons précédent le déclenchement.
3. Volt/div
Mêmes questions que pour Time/div. Chaque division représente un nombre v de niveaux et chaque niveau vaut 3.3V/2¹².
4. Calcul de la fréquence et la valeur pic à pic.
La fréquence fondamentale vaut 0 Hz (nous sommes avec des entiers non signés). La fondamentale superposée se trouve en retirant la valeur moyenne (ce qui implique de passer de non signé à signé) et en regardant les passages par 0 (simple pour les formes d'onde régulières. Le valeur pic à pic est simplement la différence entre le max et le min du signal.

Salutations

Merci Guesset pour tes éclaircissements.
Je simule les données de l'ADC par code:

Code:

---

1 2 3

for (int i= 0; i < data_length; i++) { data[i] = uint16_t((sin(2.0 * PI * i * (frequency / sample_rate)) + 1.0) * 2048); }

---

les échantillons sont centrés autour 2048.
Trcer le graticule c'est pas un problème. Pour tracer le graphe je commence par le 1er élement du tableau:

Code:

---

1 2 3 4

for (int i = 1; i < sample_count; i++) { MoveToEx(hdc, i-1, HEIGHT/2 + (MAX_AMPLITUDE/30 - (data[i-1]/15)), NULL); LineTo(hdc, i, HEIGHT/2 + (MAX_AMPLITUDE/30 - data[i]/15)); }

---

Où MAX_AMPLITUDE = 4095 et HEIGHT = 500 (hauteur de l'écran en pixels).
Oui le graphe doit être rafraichi régulierement en utilisant un timer.

Bonjour,

Pour que la simulation soit plus proche de la réalité (sans trig, la phase de tracé n'est pas a priori constante), il faudrait que chaque point (et non seulement la courbe) soit généré à l'intérieur d'une fonction appelée par un timer (esquisse) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#define sample_count 1024 // Utiliser 2^n pour un tampon circulaire uint16_t data[sample_count];   uint16_t i_smp = 0; // indice de l'échantillon courant uint16_t i_smp_max = sample_count - 1; // indice maximal déchantillon double A = 0.0; // Angle courant (évite une multiplication) double dA = 0.0; // Variation d'angle par période d'echantillonage ... void InitSignal(uint f, uint smppsec) { if(smppsec <= 0) dA = 0; else dA = 2.0 * PI * (f / smppsec); }   void OnTimerSignal(...) { A += dA; i_smp = (i_smp + 1) & i_smp_max; // Ne fonctionne que si sample_count == 2^n data[i] = uint16_t((sin(dA) + 1.0) * 2048); }

---

Remarque : les échantillons i après l'échantillon courant i_smp (i.e. i > i_smp) sont en fait dans le passé en i-1024. En tenir compte pour l'affichage.

Dans le cas d'une simulation, on pourra se contenter de simplement désactiver le timer durant l'affichage mais en cas réel il faudra quelque chose de plus sophistiqué (par exemple un tampon > 2 fois la largeur d'affichage).

Salutations

le graticule est de 10x8 divisions sur un rectangle de 500x400 pixels soit 50 pixels par division.
Comment tracer le graphe en fonction de la valeur time/div choisie?

Bonjour,

50 pixels / division.

Horizontal : 1 pixel = 1 échantillon. Mais sample_rate = nb_échantillon /sec => T_échantillon = 1 / sample_rate, donc 50 pixels / division <=> (50/sample_rate) sec/division.

Vertical : raisonnement similaire. 1 pixel <=> 3.3V*15 / 4096 (ou 4095) donc 50 pixels/division <=> 3.3V*15*50/4096 = 0.6 V/division.

Salutations

Merci Guesset, je vais essayer d'implémenter ça en code.
Salutations

Citation:

---

Dans le cas d'une simulation, on pourra se contenter de simplement désactiver le timer durant l'affichage mais en cas réel il faudra quelque chose de plus sophistiqué (par exemple un tampon > 2 fois la largeur d'affichage).

---

Ou bien utiliser un buffer circulaire qui introduira une désynchronisation mais l'affichage sera propre.

Bonjour henderson,

Citation:

---

Envoyé par henderson

Ou bien utiliser un buffer circulaire qui introduira une désynchronisation mais l'affichage sera propre.

---

Le tampon circulaire évite élégamment d'avoir deux tampons. J'y faisais implicitement référence en écrivant que "les échantillons i après l'échantillon courant i_smp (i.e. i > i_smp) sont en fait dans le passé en i-1024. En tenir compte pour l'affichage.". Une caractéristique des tampons circulaires est de préférer avoir une dimension en 2ⁿ pour faciliter le bouclage sans calcul (un simple masquage i = (i +1) & msk avec msk = (1 << n) -1;).

Ceci étant, la recherche de synchronisation, nécessaire pour avoir un signal lisible, fait perdre des positions, parfois beaucoup. Aussi que le tampon soit circulaire ou qu'il y ait deux tampons, il est nécessaire d'avoir plus d'espace que la largeur de l'écran surtout si on souhaite voir le signal juste avant le déclenchement. Les séquences de trig peuvent certes être très simples (sur 1 ou 2 échantillons) comme relativement longues et complexe (start d'un protocole par exemple).

Enfin panorama et zoom accroissent encore le besoin en mémoire.

Salut

Par ailleurs il faut simplifier la formule pour générer l'onde sinus.
- 2 * PI est un constante
- (frequency / sample_rate) est à calculer avant la boucle for.

Pour le dessin de point en point par segments, il faut un seul MoveToEx sur le premier point et un LineTo de points en points pour les points suivants.

Quelque part j'ose espérer que le hdc est celui d'un bitmap, que l'on recopie dans la zone client de la fenêtre lorsque les opérations graphiques sont terminées.
C'est une histoire de double buffering ... et j'avoue que ça peut paraître idiot à première vue ... !
Note qu'avec l'usage du timer :

Code:

---

1 2	SendMessage(hwnd, WM_PAINT,0,0);

---

est plus approprié qu'un :

Code:

---

1 2	PostMessage(hwnd, WM_PAINT, 0, 0);

---

Bonjour,

Pour le tracé d'un signal, il y a plusieurs techniques dont quelques unes ci-après (en espérant n'avoir pas fait trop d'erreurs :oops:) :

Pièce jointe 664909

Je n'ai pas mis les initialisations qui sont assez simples.

Les différences entre types de tracés se manifestent essentiellement dans les hautes fréquences (au sens visualisation).

Le premier est le plus simple mais présente le défaut que la valeur courante est souvent moins visible que les valeurs de transitions.
Le second, simple également, présente les valeurs courantes à des extremums mais propose un signale un peu empâté.
Une variante l'allège en évitant de repartir de la dernière valeur mais au-dessus ou en dessous.
Le dernier est aussi un tracé vertical comme les deux précédents, mais on ne trace que les parties de segment qui ne sont pas en recouvrement avec le précédent.

Je préfère le dernier car je le trouve plus lisible, mais les goûts et les couleurs...

Salutations