Sensorwerte werden bei zeitdiskreter Abfrage nur unregelmäßig dargestellt

[R. W. (riwen)]

Hi Leute,

ich habe einen digitalen Sensor (HYT-221) für Relative Luftfeuchtigkeit 
und Temperatur an meinen Atmega32 angeschlossen und möchte die Werte in 
Labview darstellen.
Ich will die Werte folgendermaßen auslesen: Die Werte sollen nur dann an 
den Rechner übertragen werden, wenn Labview danach fragt. Somit schickt 
Labview in regelmäßigen Abständen einen kleinen String an den 
controller, welcher daraufhin die Werte auslesen und ausgeben soll.
Problem: Es werden nur jedes zweite Mal richtige Werte dargestellt. Die 
dazwischen sind negativ oder sehr gering. Ich weiß nicht, wo er die her 
hat. Außerdem reagiert der Sensor auf Änderungen nur sehr spät. Das ist 
innerhalb meiner Anwendung nicht besonders tragisch, ich würde aber 
einfach gerne wissen warum. Hat jemand von euch Ideen? Danke!!!

Mein Basic-Programm ist so aufgebaut:

Do

Input #1 , Eingabe

Wert = Left(eingabe , 1)

If Wert = "1" Then

   Sound Portd.7 , 400 , 450
   Measurement

End If

Loop



Sub Measurement()

I2cstart
   I2cwbyte Hyt221write
I2cstop

I2cstart
   I2cwbyte Hyt221read
   I2crbyte Humhigh , Ack                                   ' Auslesen der 4 Bytes
   I2crbyte Humlow , Ack
   I2crbyte Temphigh , Ack
   I2crbyte Templow , Nack
I2cstop


Humidity = Humhigh * 256                                    ' Umrechnen von Humhigh und Humlow in 16Bit-Wert
Humidity = Humidity + Humlow
Humidity = Humidity And &H3FFF                              ' Rauskürzen der Status-Bits

Temperature = Temphigh * 256                                ' Umrechnen in 16-Bit-Wert
Temperature = Temperature + Templow
Temperature = Temperature / 4                               ' Verschieben um 2 Bits nach Rechts


Print Humidity ; Temperature


End Sub

[R. W. (riwen)]

Ps.: Wenn ich die Werte kontinuierlich abfrage, funktioniert alles 
einwandfrei: Gute Werte, Schnelle Reaktion

[spess53 (Gast)]

Hi

>Die Werte sollen nur dann an
>den Rechner übertragen werden, wenn Labview danach fragt. Somit schickt
>Labview in regelmäßigen Abständen einen kleinen String an den
>controller,...

BASCOM verwendet Nullterminierte Strings. Wie sieht denn der von Labview 
gesendete String aus?

MfG Spess

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

R. W. schrieb:
> Mein Basic-Programm ist so aufgebaut:
Pack da doch in Zukunft die passenden Tokens drumrum:
https://www.mikrocontroller.net/articles/Formatierung_im_Forum
Wenn keiner passt, dann ist der [code] Token (und sein Partner) auch gut 
genug...

[Karl H. (kbuchegg)]

R. W. schrieb:
> Außerdem reagiert der Sensor auf Änderungen nur sehr spät. Das ist
> innerhalb meiner Anwendung nicht besonders tragisch, ich würde aber
> einfach gerne wissen warum. Hat jemand von euch Ideen? Danke!!!


Natürlich habe ich Ideen.
Was, zum Bleistift, macht der

   Sound Portd.7 , 400 , 450

da drinnen? Und du wunderst dich, dass das zäh geht?

[Karl H. (kbuchegg)]

> Ich weiß nicht, wo er die her hat.

Fehler suche so wie immer:

Schau nicht nur auf das Ergebnis, sondern auch auf die Ausgangswerte. In 
deinem Fall dann eben auf die Bytes, die du vom Sensor bekommst bzw. den 
String, den sich LabView von der SChnittstelle holt.

[R. W. (riwen)]

An Karl Heinz: Natürlich wundere ich mich. Ich habe den sound da nur für 
einen Test reingepackt, aber ohne ihm läuft das ganze auch nicht besser.

[R. W. (riwen)]

@ Lothar: danke! mach ich das nächste Mal.
@ Spess: Ich habe ein Wagenrücklaufsymbol an meinen eigentlichen String 
mit drangehängt. Das habe ich schon mit beachtet.

[spess53 (Gast)]

Hi

>@ Spess: Ich habe ein Wagenrücklaufsymbol an meinen eigentlichen String
>mit drangehängt. Das habe ich schon mit beachtet.

Genau das ist ja meine Befürchtung/Vermutung. Was ist, wenn INPUT auf 
ein NULL-Zeichen wartet, aber in deinem String keins enthalten ist?

MfG Spess

[R. W. (riwen)]

Ich weiß jetzt, woran es liegt. Er gibt mir bei jedem zweiten Mal den 
String "1" zurück - also quasi den String, der eigentlich nur an den 
Atmega gesendet werden soll. Habt Ihr eine Idee, weshalb er das macht?

[Karl H. (kbuchegg)]

spess53 schrieb:

> Genau das ist ja meine Befürchtung/Vermutung. Was ist, wenn INPUT auf
> ein NULL-Zeichen wartet, aber in deinem String keins enthalten ist?

Laut
http://halvar.at/elektronik/kleiner_bascom_avr_kurs/uart_rs232_vom_computer/

wartet INPUT auf einen CR. Das würde also stimmen.

Aber das ist interessant: INPUT macht ein Echo. Das würde ich gleich mal 
ausschalten. Das könnte auch der Grund sein, warum die Rückmeldung der 
Werte nicht richtig bzw nur jedes 2. mal funktioniert.

[R. W. (riwen)]

Spess, Du bist der Beste. Das mit dem lokalen Echo des Befehls Input ist 
das Problem. Ich verwende jetzt Inkey(). Läuft 1A. Sogar die Verzögerung 
ist weg. Ich werde das noch weiter testen.

[Karl H. (kbuchegg)]

R. W. schrieb:
> Spess, Du bist der Beste. Das mit dem lokalen Echo des Befehls Input ist
> das Problem. Ich verwende jetzt Inkey().

Kann man machen.
Man hätte aber auch einfach mit
  ECHO OFF
das Echo einfach abschalten können.


Manchmal frag ich mich ehrlich wozu ich mir eigentlich die Mühe mache, 
für andere die Tutorien im Web zu suchen, die zu lesen und dann auch 
noch die relevanten Links zu posten, wenn es eh kein Schwein 
interessiert.

[spess53 (Gast)]

Hi

>Spess, Du bist der Beste. Das mit dem lokalen Echo des Befehls Input ist
>das Problem. Ich verwende jetzt Inkey(). Läuft 1A. Sogar die Verzögerung
>ist weg.

Das war Karl-Heinz.

MfG Spess

[Falk B. (falk)]

@ Karl Heinz Buchegger (kbuchegg) (Moderator)

>Manchmal frag ich mich ehrlich wozu ich mir eigentlich die Mühe mache,
>für andere die Tutorien im Web zu suchen, die zu lesen und dann auch
>noch die relevanten Links zu posten, wenn es eh kein Schwein
>interessiert.

Helfersyndrom. Kein Witz.

[R. W. (riwen)]

Sorry, verlesen. Aber danke! mit Echo off habe ich immer noch da Problem 
der großen Verzögerung. Es hat mich interessiert- es war die Lösung^^