Hey ich wollte mal fragen obs bei einer Kabellänge von ca. 70-80 cm zu
starken Fehlübertragungen kommt?
Ich weiß nur nich obs das ist, weil ich nur bei der Feuchtigkeit starke
Schwankungen bekomme... die Temperatur scheint richtig und stabil zu
bleiben.
Ist zu lang, 15 cm sollte das Kabelmaximum sein oder aber die
Übertragung muß extrem verlangsamt werden. Außerdem sollte direkt am SHT
ein 100nF-Keramikkondensator die Betriebsspannung abblocken und ein
4kOhm...10kOhm Pullup am Data-I/O-Pin angeschlossen werden.
Laut Datenblatt sollte das Kabel kürzer 10 cm sein, andernfalls ist eine
Schirmung zwischen SCK und DATA notwendig. Eine Reduktion der Datenrate
(SCK-Frequenz) kann die Übertragung stabiler machen.
Ich würde die Taktfrequenz testweise auf ca 100 Hz stellen und die
Fehlerrate prüfen. So dürften eigentlich keine Übertragungsfehler
auftreten.
Grüße,
Peter
Ein 2-Wire Interface sollte 70cm schaffen, aber natürlich nur wenn es
richtig gemacht wurde.
Was verwendest du als pull up, hast du einen Stützkondensator zwischen
GND und VCC, sind die Leitungen irgendwie ungeschickt (parallel zu
Leitungen mit hohem Strom).
Was passiert, wenn du 1/10 der Geschwindigkeit für SCK verwendest ?
Hm das mit der Frequenz werd ich mal versuchen...Also als Kabel hab ich
ein Flachbandkabel werd mal die Länge des Kabels verkürzen und dann mal
schauen obs besser wird.
Edit:
Aber wiesou funktioniert dann die Temperatur richtig?
Ich habe problemlos einen SHT11 mit 50cm Flachbandkabel an einem
Butterfly dran. Mit 100nF Kondensator für VCC/GND direkt am SHT11 und
nur dem internen Pullup-Widerstand vom Controller. Taktung ist fast
ungebremst das was der 2MHz Controller hergibt.
Hm...der Kondensator ist bei mir schon integriert auf dem Sensor.
Edit:
Hier mal den Quellcode, hab ihn von jemand anders im Internet bekommen
vielleicht ist da ein Hacken dran:
1
readsh11:
2
clr trt
3
4
clr rhrt
5
cbi SENSOR_PORT,PIN_CLK ;init clock line
6
sbi SENSOR_DDR,PIN_CLK
7
8
cbi SENSOR_PORT,PIN_DATA ;init data line
9
cbi SENSOR_DDR,PIN_DATA
10
11
rcall rdelay
12
13
14
ldi temp1 ,10 ;connection reset sequence
15
16
re1: rcall chigh
17
rcall clow
18
dec temp1
19
brne re1
20
21
22
rcall chigh ;transmission start
23
rcall dlow
24
rcall clow
25
rcall chigh
26
rcall dhigh
27
rcall clow
28
29
ldi temp1,0b00000101 ;send byte: command for 'check RH'
30
rcall sendbyte
31
;---------
32
;wait for sensor ready
33
re3: ldi temp1,2
34
rcall g_wms
35
sbis SENSOR_PIN,PIN_DATA
36
rjmp re2
37
inc rhrt
38
brne re3
39
40
re4: rjmp reto ;sensor timed out (512 ms)
41
42
re2: rcall readbyte ;read one byte
43
44
rcall dlow ;acknowlegde
45
rcall chigh
46
rcall clow
47
rcall dhigh
48
49
rcall readbyte ;readbyte
50
51
mov rhl,temp2
52
53
rcall chigh ;skip acknowlegde to end communication
54
rcall clow
55
56
57
;--------read temperature
58
59
60
rcall chigh ;transmission start
61
rcall dlow
62
rcall clow
63
rcall chigh
64
rcall dhigh
65
rcall clow
66
67
68
ldi temp1,0b00000011 ;send byte: command for 'check temp'
69
rcall sendbyte
70
71
;wait for sensor ready
72
rew3: ldi zl,2
73
rcall g_wms
74
sbis SENSOR_PIN,PIN_DATA
75
rjmp rew2
76
inc trt
77
brne rew3
78
79
rew4: rjmp reto ;sensor timed out (512 ms)
80
81
rew2: rcall readbyte ;read one byte
82
83
mov th,temp2
84
85
rcall dlow ;acknowlegde
86
rcall chigh
87
rcall clow
88
rcall dhigh
89
90
rcall readbyte ;readbyte
91
92
mov tl,temp2
93
94
rcall chigh ;skip acknowlegde to end communication
Also hab ich das richtig verstanden...1x 100nF so nah am Sensor wie
möglich zwischen GND und VCC und dann noch jeweils einen 100nF zwischen
GND und und SCK und eins zwischen GND und Data? am Sensor und am
Mikrocontroller
Philip Ockert schrieb:> und dann noch jeweils einen 100nF zwischen> GND und und SCK und eins zwischen GND und Data? am Sensor und am> Mikrocontroller
Nein, auf keinen Fall!
Nein, an die Datenleitungen dürfen keine so großen Kapazitäten
angeschlossen werden. Zum Vermeiden von zu hoher Flankensteilheit kann
man einige Pikofarad draufbauen, aber nur, wenn man weiß, was man da
macht. Normal bracht man das aber nicht. Der auf Vcc ist richtig und
auch wichtig.
Wieso wird im Programm für einfache Anweisungen, wie das Setzen von
Bits, rcall verwendet? Das geht mit Makros viel effizienter.
Grüße,
Peter
Aber der bei VCC und GND der ist doch da schon drauf auf dem Sensor?oder
ist das ein anderer???
Ok ich muss mir mal Macros anschauen^^...nur vom Quellcode her müssts
doch so komplett laufen oder?
>Aber der bei VCC und GND der ist doch da schon drauf auf dem Sensor?oder>ist das ein anderer???
Das weiß ich nicht, was da schon drauf ist. Das ist auch egal, wenn
mehrere 100nF parallel auf der Versorgung sind, schadet das auch nicht.
Den Quellcode sieht man ja nicht komplett, so kann ich dazu nicht sagen.
Grüße,
Peter
Philip Ockert schrieb:> Aber der bei VCC und GND der ist doch da schon drauf auf dem Sensor?
Laut Datasheet ja. Bei mir ist es kein SHT71 sondern ein SHT11, daher
separat nötig.
Dürfte ja beim Abruf der Feuchtigkeit ein Problem sein, wenn so ein
riesen Unterschied ist zwischen zwei Messungen.
Also hier mal der Code, der die Feuchtigkeit und Temperatur abruft:
1
.equ SENSOR_PORT = PORTC
2
.equ SENSOR_DDR = DDRC
3
.equ SENSOR_PIN = PINC
4
.equ PIN_DATA = 2
5
.equ PIN_CLK = 1
6
7
.equ Zahl = 4010 //d1 für Temperatur berechnen mit 10^3
8
.equ C1 = 2046 //Gerundet von 2.0468 auf 2.046*1000
9
.equ C21 = 36 //C2 aufgeteilt in vor dem Komma und nach dem Kommastellen 0.0367*10^3
10
.equ C22 = 7 //Nachkommastelle
11
.equ C23 = 10
12
.equ C31 = 1595 //C3 von 1.5955*10^-6 durch *10^3 auf 1.595 /1000 gerundet
13
.equ C32 = 1000
14
.equ C33 = 1000
15
16
.def rhl=r8
17
.def rhh=r9
18
19
.def tl=r10
20
.def th=r11
21
22
.def rel=r12
23
.def reh=r13
24
25
.def trt=r14
26
27
.def rhrt=r15
28
29
.ifndef XTAL
30
.equ XTAL = 4000000
31
.endif
32
33
34
35
;Kurze Pause
36
shortbreak: ; 50us Pause
37
ldi temp1, ( XTAL * 50 / 3 ) / 1000000
38
shortbreak_:
39
dec temp1
40
brne shortbreak_
41
ret ; wieder zurück
42
43
dlow: sbi SENSOR_DDR,PIN_DATA ;set data low
44
rjmp rdelay
45
46
dhigh: cbi SENSOR_DDR,PIN_DATA ;set data high
47
rjmp rdelay
48
49
50
clow: cbi SENSOR_PORT,PIN_CLk ;set clock low
51
rjmp rdelay
52
53
chigh: sbi SENSOR_PORT,PIN_CLK ;set clock high
54
55
rdelay: push temp1 ;1 msek delay to allow the lines to settle
Das ist doch nicht der Code, den du laufen lässt, der lässt sich nicht
assemblieren, temp1 undefined.
Und bitte den Code in den Anhang, direkt so als Datei, wie sie ist.
Grüße,
Peter
Jap sind die eingestellten 4MHz ich werd aber bald auf nen externen
Quarz umstellen...weil die Uhr bis jetzt noch relativ ungenau läuft weil
ich internen Takt verwende
Ja hab ich beobachtet manchmal...hat mich vorallem gewundert, dass ich
manchmal mehr als 12 Bits hatte (also die letzte eins war manchmal bei
13 oder 14) was ja bei Feuchtigkeit eigentlich nicht sein darf oder?ist
ja nur eine 12 Bit Messung. Aber ich werd nachher wenn meine
Terrariumsteuerung ausgeht also Licht etc mal abstöpseln und mir noch
mal die Bits ausgeben lassen.
Wo steht das?mit dem Software Kondensator?
Was macht denn das eigentlich:
.org OVF1addr
in save_sreg, SREG
Was soll das im Fall des Timerüberlaufs bewirken, außer, dass kein reti
ausgeführt wird, und das Programm beliebigen Unsinn macht?
Ach das hab ich noch beim Kopieren von der Entprellroutine dort hinein
gemacht...brauch ich wohl nicht...
Edit:
Was mir aufgefallen ist, meine Endzeit wird immer wieder zurück gesetzt
bzw. auf 2 Stunden. Und das liegt irgendwie an dem was mein
Mikrocontroller macht im Interrupt mit dem Feuchtigkeitscheck.
entprell_init:
push temp1 ; temp 1 sichern
in temp1,sreg ; SREG sichern
clr key_old
clr key_state
clr key_press
out sreg,temp1 ; sreg wieder herstellen
pop temp1
feuchte_check:
Wieso wird in der Initialisierung der Entprellung das Statusregister
gesichert? Es schadet ja nicht, aber es ist einfach überflüssig.
Was mich daran mehr stört, ist dass die entprell_init kein return hat,
also danach gleich mit feuchte_check weitermacht.
ahhh bingo^^ danke...ja das mit dem Stautsregister war so weil irgendwie
dort immer das Zero Bit sich danach nicht wieder zurück gesetzt hat.
Aber durch den Ret hat sich nichts geändert...bei mir ändert es jedesmal
meine Endzeit_stunde auf 2 wenn ich das mit dem Feucht_check durchführen
lasse.
Lass mal die Umrechnung der Rohdaten weg und schau die Rohdaten vom
Sensor als 16 bit Zahl direkt an, diese Umrechnerei durchblicke ich
nicht ganz.
calchumhum:
//u1 in (u11:u12):
ldi temp1, LOW(C1)
ldi temp2, HIGH(C1)
ldi temp3, 0
ldi temp4, 0
ldi temp5, LOW(C23)
ldi temp6, HIGH(C23)
rcall div32
Was soll denn die Rechnerei mit den Konstanten, das kann man doch alles
vorher ausrechnen, es kommt doch immer das gleiche dabei raus. Abgesehen
davon ist die Rechnung irgendwie unnötig kompliziert und der Kommentar
nicht besonders nachvollziehbar.
Ja stimmt da ists echt sinnlos...gut ich wollts etwas so gestallten dass
man bei kleineren Änderungen bei den Konstanten einfach oben das
Einträgt.Diese Warnungen machen doch nichts oder?das ist doch nur weil
die letzten Registern schon durch diese Z X Y definiert sind?
Also ich hab mal alles weggelassen und mach nur die
Feuchtigkeitsrechnung + Bit Ausgabe...und die schwankt wie vorher.
Edit:
Okay ich glaub ich weiß woran es liegt...werde das Kabel noch mal
auftrennen und die Lötstellen kontrollieren, weil ich dort den Fehler
sehe, wenn ich das Kabel liegen lasse kommen gerade nur relativ gleiche
Werte raus. Hebe ich das Kabel in die Luft und bleib aber so, dann
wackeln die Werte wieder.
So langsam geb ichs auf...wenn ich den Sensor raus mache und einfach
beobachte was passiert, dann kommen lauter komische Zahlen raus anstatt
dass der Kontroller einfach nur noch die selben Zahlen anzeigt.
Okay hat sich erledigt war ein Problem in der Routine für den Sensor da
ich dort einmal das rhh vergessen habe zu speichern...jetzt frag ich
mich bloß woran es liegt dass sich immer wieder meine Endzeit auf 02:00
stellt... liegt irgendwo in der Schleife in der ich den Sensor abrufe.
