Hallo. Ich bin dabei einen Temperatursensor mit Zacwire Protokoll auszulesen und komme nicht weiter. Es klappt bei Raumtemperatur super. Er liest schön in 0.1° Schritten aus. Aber wenn ich die Temperatur senke (unter 14°) fängt die anzeige auf einmal an zu ruckeln. Zwischen 14° und -12° bleibt der angezeigte Wert auf 1.2° stehen und erst unter -12° hört er auf zu ruckeln. Hat jemand ne Idee woran es liegen könnte? der Sensor ist es nicht, hab ihn mit Oszilloskop angesehen und er sendet ohne Probleme. Der Sensor hängt am Interupt0 Pin und wird dort ausgelesen. Es kann ja auch nicht am Timing liegen, denn bei Werten |value| > 14° geht es ja, d.h. die Bitwechsel werden gelesen. Selbst wenn das Auslesen der Ganzzahlen nicht richtig klappen würde, müsste sich ja zumindest der Nachkommawert ändern. Könnte der Atmega8 Probleme mit der niedrigen Temperaturen haben?
Hi >Könnte der Atmega8 Probleme mit der niedrigen Temperaturen haben? Der ATMega8 ist bis -55°C spezifiziert. Also unwahrscheinlich. Als Test könntest du die Leitung länger machen und nur den Sensor kühlen. > Zwischen 14° und -12° bleibt der angezeigte >Wert auf 1.2° stehen und erst unter -12° hört er auf zu ruckeln. Möglicherweise stimmt deine Einlese- oder Berechnungsroutine doch nicht so ganz nicht. Du könntest zum einen, dir einfach mal die vom TSIC gelesenen Werte ohne Temperaturberechnung ausgeben lassen. Die Temperaturberechnung kann man auch im Simulator mit vorgegebenen Werten Testen. MfG Spess
So. Ich bin jetzt einen Schritt weiter. Anscheinend ändert der Temperatursensor in Abhängigkeit zur Temperatur die Zeit zwischen den einzelnen Bits. Je höher die Temperatur, desto länger die Zeit dazwischen, je kälter desto kürzer. Ich kann also nicht mit einer festen Zeit arbeiten, die ich verstreichen lasse, sondern muss diese erst anhand des Startbits bestimmen. Es ist also eine neue Problemstellung (Soll ich dafür einen neuen Thread erstellen): Das Signal ist normal auf 1, wenn es los geht kommt zuerst das Startbit mit einer fallenden, einer steigenden und wieder einer fallenden Flanke. D.h. ich muss jetzt bei der fallenden Flanke, die zeit zur nächsten steigenden messen. Wie stelle ich das am besten an? Auf Seite 3 ist es gezeigt: http://www.zmd.biz/pdf/IST_TSic_ZACwire_V2.3%20Digital%20Output_17-Oct-06.pdf T_Strobe ist die Zeit die ich brauche. Das beste wäre wohl, wenn ich einen Counter starte bei der ersten fallenden Flanke, und bei der nächsten steigenden Stoppe. Anschließend kann ich ja auf dem Counter den gezählten Wert laden. Bloß wie generiere ich einen Wartezyklus mit der Länge des Werts vom Counter? Oder hat jemand eine einfachere Idee zur Realisierung?
>Je höher die Temperatur, desto länger die Zeit dazwischen, je kälter >desto kürzer. Du meinst das Bit ist nicht mehr 125µs lang, sondern wesentlich kürzer oder länger?
@Jörg S.: Ja genau. So kann ich nicht eine Warteschleife die konstant 120us wartet benutzen.
Hi >Anschließend kann ich ja auf dem Counter den gezählten Wert laden. Bloß wie >generiere ich einen Wartezyklus mit der Länge des Werts vom Counter? >Oder hat jemand eine einfachere Idee zur Realisierung? Entweder komplett mit Timer realisieren, oder die Messung mit einer Zählschleife realisieren, die die gleiche Taktzahl benötigt wie die Warteschleife. Dann kann der Wert direkt übernommen werden. MfG Spess
Benedikt W. schrieb: > @Jörg S.: Ja genau. So kann ich nicht eine Warteschleife die konstant > 120us wartet benutzen. Synconisierst du dich denn nicht auf die Flanken? Ich mach die Auswertung so: - Auf fallende Flanke warten - Delay 62,5µs (Mitte des Bit treffen) - Schauen welcher Pegel da ist und 1 oder 0 merken - Wieder auf fallende Flanke warten Wenn jetzt das Timing nicht so aus dem Ruder läuft das bei 62,5µs die logisch 1 nocht nicht da ist, oder bei logisch 0 schon vorbei ist, klappt das. Daher würde es mich auch mal interessieren wie weit sich die Bits denn jetzt von den Nominal 125µs entfernt haben.
Jörg S. schrieb: > Wenn jetzt das Timing nicht so aus dem Ruder läuft das bei 62,5µs die > logisch 1 nocht nicht da ist, oder bei logisch 0 schon vorbei ist, > klappt das. > Daher würde es mich auch mal interessieren wie weit sich die Bits denn > jetzt von den Nominal 125µs entfernt haben. Das kann ich dir leider "noch" nicht sagen, weil ich zu faul war um das Oszilloskop zur Gefriertruhe zu tragen und dort zu testen. Ich habs auch nicht abgelesen als ich es von Raumtemperatur bis ca 50° getestet habe. Aber ich habe jetzt hier eine Macro gefunden, mit dem man eine bestimmte Anzahl an Zyklen warten kann. Und dem habe ich jetzt einfach die gemessene Anzahl an Zyklen gegeben. Das klappt ziemlich gut. Beitrag "Re: AVR: Delay 7 ... 65542 Zyklen"
Hi, ich hatte auch festgestellt das sich das TStrobe des TSIC's stark ändert und die 60µS Pausen nit funzen. Im Anhang habe ich mal meinen Code angehangen(ist für Atmega8, also eventuell Register Anpassung erforderlich). Nicht der schönste, aber funzt. Hoffentlich sind keine Fehler drin, da aus mehreren Dteien zusammen kopiert. Habe ausserdem ne kleine main zum benutzen mit reingehangen. Ich benutze den Timer1 dafür(kann auch jeder andere benutzt werden natürlich). Am Anfang messe ich den TStrobe mittels Timer1 im Normal Mode. Anschliessend setze ich den CTC Mode ein um die Flanken richtig zu erwischen. Achso PD3 ist der Pin des Tsic-Signals und PD5 der Power Pin. Gruß
Hallo, ich habe nun schon seit mehreren Wochen ein scheinbar ähnliches Problem. Ich benutze ein embedded System von Bolymin mit einem Atmega 644p. An den 2 freien Ports des Boards lese ich zwei TSic´s ein. Dabei synchronisiere ich mich auf fallende Flanke mittels Pinchange Interrupt und benutze den 16bit Timer um die 62µs "abzuwarten". Nach dieser Zeit übernehme ich den Pinstatus. Beim nächsten Bit das gleiche: fallende Flanke(Interrupt)--> 62µs--> Pinstatus übernehmen. Bis ich alles aufgesammelt hab. Mein Problem ist jetzt, dass von Zeit zu Zeit der Temperaturwert "ruckelt". Ich gebe die Temperatur auf dem Display aus, z.B.: 20°C, 21°C, -15°C, 20°C. Ich weiß nicht, warum manch ein Wert komplett aus der Reihe fällt (-15°C). Ich habe auch schon das TSic Signal an den Oszi gehängt, dabei ist mir auch aufgefallen, dass die Bits mit steigender Temperatur länger werden, aber da ich mich ja immer per Interrupt an die fallende Flanke hänge, kann das mein Problem nicht erklären. Hat jemand eine Idee warum die Werte wackeln? Kann es sein, dass das Bolyminboard nicht stabil ist, hat schonmal jemand mit Hardware dieser Firma gearbeitet? Bolymin liefert auch Treiber die mittels PWM das HIntergrundlicht des LCD steuern, diesen Treiber konnt ich nicht verwenden, da das PWM Signal in die Ports gestreut hat, mit denen ich die Sensoren auslese, daher ist meine Hintergrundbeleuchtung "dauerhaft an". Deutet das auf "schlechte" Hardware von Bolymin hin? Vielen Dank für Ihre Hilfe! Gruß Martin
Wenn ein Wert völlig aus der Reihe fällt, fehlt da meist ein Bit. Die TSICs haben eine variable Bitlänge, die teperaturabhängig ist. Da das Startbit einen DC von 50% hat, die Datenbits aber von 25% bzw. 75% MUSST Du erst mal die Länge des halben Bits anhand des Starbits bestimmen und genau diese Zeit nach der Flanke warten und dann danach bestimmen, welchen Wert das Datenbit hat. Eine feste Warteseit von 62µsec funktioniert nur bei Temperaturen um 20°C
Hallo bingo, danke für die schnelle Antwort, ich hab das Signal auf dem Oszi von 20°C bis 120°C beobachtet und klar sieht man deutlich eine Verlängerung der 2 Bytes, aber laut Datenblatt ist die logische "1" und die logische "0" ja von jeweils 25% bis 75% eines Bits vorhanden also für die Zeit von ca 62,5µs und da messe ich ja für jedes Bit neu genau in der Mitte. Und das Signal müsste dann mehr als 31,25µs aus dem Ruder laufen pro Bit damit ich voll daneben haue, oder?. Auf dem Oszi hab ich Abweichungen von um die 7µs beobachtet. Ich hatte auch bereits mit dem Gedanken gespielt die Messung so umzustellen, das werde ich nun auch tun um zu sehen ob das hilft. Ich werde berichten, ob das geholfen hat. Vielen Dank mfg Martin
Hallo, wir haben die Software so umgestellt, dass jeweils das T Strobe gemessen wird und dann als compare Zeit genutzt wird mit dem Ergebnis, dass die Fehleranfälligkeit noch größer geworden ist. Das lässt uns vermuten, dass ein Timerproblem vorliegt, hat jemand dahingehend Erfahrungen. Atmega 644p Timer1 im CTC mode, dass der vllt. nicht ganz "rund" läuft, oder sowas? Danke Martin
Ich arbeite öfters mit TSICs, allerdings benutze ich PICs, ein gut kommentierter ASM-Code steht unter Beitrag "Re: digitaler Thermosensor", der funktioniert wunderbar
Hallo, nach weiteren Forschungen ist jetzt klar, dass Sörungen, die nur von anderen IC´s auf dem Bolymin Board stammen können -daher nicht eliminierbar sind- den Pinchange Interrupt stören, bzw. zum falschen Zeitpunkt auslösen. Also werden wir die TSic´s per Polling auslesen müssen. Danke für den Link zu dem Quelltext, den werde ich mir durchlesen und vielen Dank für die schnellen Hilfestellungen! liebe Grüße Martin
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.