Hallo!
War letztens eine zufällige Entdeckung:
Beim vorletzen zerlegen des Repeaters zwecks Antennenkontrolle habe ich beim anschließenden Zusammenbau die Repearerplatine versehentlich versetzt auf die im Steckergehäuse eingeklebte Stiftleiste gedrückt.
Gute 2,5 Wochen war das Teilchen dann zwar häufig in der Steckdose, wurde aber dennoch nicht geladen.
Als mitte letzte Woche dann mein Terminal anfing tausende "RSSI-Timeouts" zu melden, entdeckte ich den Schlamassel.
Repeater war auf Dauersenden und an Vcc konnte ich knapp 1,6xV messen.
Dumm, somit hat die LiPo ihre erste fatale Tiefentladung wech, wovon sie sich aber augenscheinlich wieder erholt hat.
Generell ist es aber ein Problem bei Batteriebetriebenen Projekten. Beherrschbar wenn man diese Gefahr berücksichtigt und schaltungstechnisch sicherstellt das die RFM69 definitiv still bleibt wenn der µC nicht mehr funktioniert.
Habe ich auch schon dran gedacht, ist aber nicht so einfach.
Die Müll-Bytes am Anfang des FIFO's sind eher zufällig, warscheinlich durch Rauschen verursacht.
Die meißten Bytes in meinem Paket können auch eher zufällig sein, da es eben Rohdaten.
Ein wie auch immer definiertes Startbyte könnte also zigmal an beinahe beliebiger Stelle auftreten.
Aber wie dem auch sei:
Ob ich eine Korrektur versuche, oder einfach durch Nichtaussendung des nötigen Ack's das Paket nochmals senden lasse, weis ich noch nicht.
Das mache ich später Abhängig von der maximalen Rechenzeit im Vergleich zur nochmaligen Übertragung.
Ein weiteres Problem nervt mich gerade gewaltig, nämlich die Zuverläsigkeit meiner Referenzuhr.
Seit Samstag Abend steckt der Repeater in der vorgeplanten Steckdose.
Genau die Steckdose wo ich schon rumoptimiert habe, damit dort zumindestens halbwegs zuverlässig DCF77-Empfang möglich ist.
Was soll ich sagen:
Heute morgen dann auf das LCD des Terminals geschaut...Zeit stimmte. Beim exakteren vergleich maximal eine Abweichung von +0,2-0,3s zu meiner komerziellen Funkuhr am Monitor.
Im Echtzeitlog dann aber die ernüchterung.
Von Samstag Abend bis heute morgen schaffte der Repeater keine einzige DCF-Synchronisierung.
Byte 22 stand auf h1F entsprechend 31 Stunden ohne DCF77-Sync.
Der minütliche Zeitstempel kam dann am Terminal nicht so an wie gedacht:
08:10:00
08:11:00
08:12:00
sondern:
08:10:09
08:11:09
08:12:09
Wie ich vor einigen Tagen (Posting 74, letzter Absatz) ankündigte habe ich schon ein Experimentierentwurf um mich mal komplett und grundlegend neu damit auseinander zu setzen.
Das Teil hat auf jeden Fall schon mal drei Antennenschnittstellen wo ich zum Vergleich der üblichen Ferritkern-Antennen auch noch undefinierte Signaladern (im Stromnetz z.B. den PE oder sonstige Kabel) als Antenne testen will, sowie eine miniaturisierte Aktivantenne.
Statt dort einen DDS oder eine PLL drauf zu pappen habe ich mich für ein Direktmischer entschieden.
Mischfrequenz soll vom Timer kommen und das Signal auf wenige 100Hz herab mischen.
Und das wichtigste:
Alternative Zeitzeichensender!
Neben DCF77 auf 77,5kHz gibt es nämlich noch DCF49 (127,5kHz) und DCF39 (138,5kHz) die Zeitstempel aussenden welche mit DCF77 synchron laufen. Jedoch in mehrfacher Hinsicht Effektiver:
DCF49 und DCF39 haben grob die selbe Sendeleistung wie DCF77, jedoch durch die zwei unterschiedlichen Senderstandorte eine weitere Ausleuchtung:
DCF49 steht am gleichen Standort wie DCF77, in Mainflingen/Frankfurt, sowie DCF39 bei Burg/Magdeburg.
Und das Sendeformat ist deutlich günstiger:
Während bei DCF77 die 58 Bits mit 1Baud in 58 Sekunden empfangen werden müssen, wo schnell einzelne Impulse (Gewitter, lokale Funkenstörungen wie Lichtschalter u.v.m.) Fehlauswertungen verursachen, senden die DCF39/49 ein 200Bd FSK Signal wo alle 10 Sekunden ein DCF77-exakter Zeitstempel mit Uhrzeit, Zeitzone, Datum ausgestrahlt wird.
Sieht dann grob so aus wie der Screenshot im Anhang (aktueller Mitschnitt von DCF49).
Statt also mindestens 60 Sekunden (CHECK=0) oder sogar 180 Sekunden (CHECK=2) durchweg feherfreien Empfang wie man ihn für DCF77 brauchte, brauch mal bei DCF39/49 nur 10 Sekunden (ähnlich CHECK=0) bis 30 Sekunden (ähnlich CHECK=2).
Will da demnächst mal experimentell schauen was da effizienter geht und den dadurch gefundenen Alternativweg versuchen zu optimieren bezüglich Größe und Strombedarf.
Grüße
Jürgen
Mitch64 schrieb:
Im Datenblatt steht, dass der Betriebsspannungsbereich 1,8 bis 3,3 Volt sein soll.Wenn da dann nur 1,6V dran sind, darf das Modul auch "spinnen"!DG7GJ schrieb:
Und das auch nur in der Hoffnung das bei einer Restspannung von 1,6V (wo er noch sendet!) die Reset-Auswertung überhaupt noch funktioniert.
Aber wie tief fällt denn deine Spannung ab und warum?
War letztens eine zufällige Entdeckung:
Beim vorletzen zerlegen des Repeaters zwecks Antennenkontrolle habe ich beim anschließenden Zusammenbau die Repearerplatine versehentlich versetzt auf die im Steckergehäuse eingeklebte Stiftleiste gedrückt.
Gute 2,5 Wochen war das Teilchen dann zwar häufig in der Steckdose, wurde aber dennoch nicht geladen.
Als mitte letzte Woche dann mein Terminal anfing tausende "RSSI-Timeouts" zu melden, entdeckte ich den Schlamassel.
Repeater war auf Dauersenden und an Vcc konnte ich knapp 1,6xV messen.
Dumm, somit hat die LiPo ihre erste fatale Tiefentladung wech, wovon sie sich aber augenscheinlich wieder erholt hat.
Generell ist es aber ein Problem bei Batteriebetriebenen Projekten. Beherrschbar wenn man diese Gefahr berücksichtigt und schaltungstechnisch sicherstellt das die RFM69 definitiv still bleibt wenn der µC nicht mehr funktioniert.
Mitch64 schrieb:
Ich würde Pakete in einem Frame senden. Heißt da gibt es ein definiertes Startbyte und ein definiertes Schlussbyte. Checksumme (CRC) ist das
letzte Byte vor den Schlussbyte.
So könnte man, wenn man schon im Fifo suchen will, einfach nach dem Startbyte suchen. Ist das gefunden, zu prüfen, ob das Schlussbyte auch vorhanden ist (Offset 25). Dann die Daten nehmen und mit CRC verrechnen.
Diese Vorgehensweise würde vermutlich weniger Rechenleistung (Zeit) abverlangen, als zig mal eine CRC-Berechnung durchzuführen, bis die CRC-Summe stimmt.
Habe ich auch schon dran gedacht, ist aber nicht so einfach.
Die Müll-Bytes am Anfang des FIFO's sind eher zufällig, warscheinlich durch Rauschen verursacht.
Die meißten Bytes in meinem Paket können auch eher zufällig sein, da es eben Rohdaten.
Ein wie auch immer definiertes Startbyte könnte also zigmal an beinahe beliebiger Stelle auftreten.
Aber wie dem auch sei:
Ob ich eine Korrektur versuche, oder einfach durch Nichtaussendung des nötigen Ack's das Paket nochmals senden lasse, weis ich noch nicht.
Das mache ich später Abhängig von der maximalen Rechenzeit im Vergleich zur nochmaligen Übertragung.
Ein weiteres Problem nervt mich gerade gewaltig, nämlich die Zuverläsigkeit meiner Referenzuhr.
Seit Samstag Abend steckt der Repeater in der vorgeplanten Steckdose.
Genau die Steckdose wo ich schon rumoptimiert habe, damit dort zumindestens halbwegs zuverlässig DCF77-Empfang möglich ist.
Was soll ich sagen:
Heute morgen dann auf das LCD des Terminals geschaut...Zeit stimmte. Beim exakteren vergleich maximal eine Abweichung von +0,2-0,3s zu meiner komerziellen Funkuhr am Monitor.
Im Echtzeitlog dann aber die ernüchterung.
Von Samstag Abend bis heute morgen schaffte der Repeater keine einzige DCF-Synchronisierung.
Byte 22 stand auf h1F entsprechend 31 Stunden ohne DCF77-Sync.
Der minütliche Zeitstempel kam dann am Terminal nicht so an wie gedacht:
08:10:00
08:11:00
08:12:00
sondern:
08:10:09
08:11:09
08:12:09
Wie ich vor einigen Tagen (Posting 74, letzter Absatz) ankündigte habe ich schon ein Experimentierentwurf um mich mal komplett und grundlegend neu damit auseinander zu setzen.
Das Teil hat auf jeden Fall schon mal drei Antennenschnittstellen wo ich zum Vergleich der üblichen Ferritkern-Antennen auch noch undefinierte Signaladern (im Stromnetz z.B. den PE oder sonstige Kabel) als Antenne testen will, sowie eine miniaturisierte Aktivantenne.
Statt dort einen DDS oder eine PLL drauf zu pappen habe ich mich für ein Direktmischer entschieden.
Mischfrequenz soll vom Timer kommen und das Signal auf wenige 100Hz herab mischen.
Und das wichtigste:
Alternative Zeitzeichensender!
Neben DCF77 auf 77,5kHz gibt es nämlich noch DCF49 (127,5kHz) und DCF39 (138,5kHz) die Zeitstempel aussenden welche mit DCF77 synchron laufen. Jedoch in mehrfacher Hinsicht Effektiver:
DCF49 und DCF39 haben grob die selbe Sendeleistung wie DCF77, jedoch durch die zwei unterschiedlichen Senderstandorte eine weitere Ausleuchtung:
DCF49 steht am gleichen Standort wie DCF77, in Mainflingen/Frankfurt, sowie DCF39 bei Burg/Magdeburg.
Und das Sendeformat ist deutlich günstiger:
Während bei DCF77 die 58 Bits mit 1Baud in 58 Sekunden empfangen werden müssen, wo schnell einzelne Impulse (Gewitter, lokale Funkenstörungen wie Lichtschalter u.v.m.) Fehlauswertungen verursachen, senden die DCF39/49 ein 200Bd FSK Signal wo alle 10 Sekunden ein DCF77-exakter Zeitstempel mit Uhrzeit, Zeitzone, Datum ausgestrahlt wird.
Sieht dann grob so aus wie der Screenshot im Anhang (aktueller Mitschnitt von DCF49).
Statt also mindestens 60 Sekunden (CHECK=0) oder sogar 180 Sekunden (CHECK=2) durchweg feherfreien Empfang wie man ihn für DCF77 brauchte, brauch mal bei DCF39/49 nur 10 Sekunden (ähnlich CHECK=0) bis 30 Sekunden (ähnlich CHECK=2).
Will da demnächst mal experimentell schauen was da effizienter geht und den dadurch gefundenen Alternativweg versuchen zu optimieren bezüglich Größe und Strombedarf.
Grüße
Jürgen