Posts by nurazur

    Warum kann ich jetzt nicht mehr mittels FTDI USB Adapter die Sketche aufspielen?

    Kann ich nicht mit Sicherheit beantworten. Manchmal ist es allerdings so dass der RC Oszillator im Atmega328 zu sehr verstimmt ist. Das Datenblatt sagt +/-10%, in der Praxis messe ich selten mehr als 3% aber zum Flashen muss der Oszillator auf etwa 1% genau sein. Den Oszillator kann man abstimmen, aber das Register im Chip ist fest eingebrannt (Avr Designfehler!) so dass man den Kalibrierwert im Bootloader setzen muss. Ich loese das Problem mit speziell kompilierten Optiboot Bootloadern, da steht der Kalibrierwert im Flash.

    hama hat den Wunsch neben den Interrupts auch den Status von GPIO's zu übermitteln. Nach längerer Diskussion per PM kann ich folgenden Vorschlag machen:

    Im Funkprotokoll gibt es das "Flags" Byte, mit dem in bits 1-4 die Interrupts angezeigt werden. Bit 0 ist für den "Heartbeat" reserviert. Jetzt passiert es so gut wie nie dass ein Interrupt und ein Heartbeat gleichzeitig kommen. Das kann man ausnutzen und mit dem Heartbeat den Status der 4 die GPIO's abfragen und senden.

    Das bedeutet für mich: Im receiver.ino Sketch muss ich die Logik ändern und eine GPIO Abfrage einbauen - das sind nur ein paar Zeilen Code, bringt aber eine neue TiNo Version (2.2.0).

    Das bedeutet für den ioBroker Adapter: es kommt eine neue Variable ins Spiel, die ich aber nur über den seriellen Port schicke, wenn es sich um einen Heartbeat handelt, z.B. stat=13 - 0xD - beduetet PCI3, PCI2 und PCI0 sind HIGH, PCI1 ist LOW. Macht das Sinn? Die Interrupts sende ich natuerlich separat weiterhin.


    Was haltet ihr davon? Ich frage mal in die Runde weil ich keine Ahnung vom ioBroker habe, und ich persoenlich diese Funktion nicht brauche.

    Vieleicht wäre es mal eine Option in einer der nächten Versionen den Status auch zu übertragen 8) .

    Technisch kein Problem - aber es hat schon seinen Grund warum ich das nicht vorgesehen habe. Es kommt darauf an von was genau du den Status erfassen willst. Man muss den Stromverbrauch im Auge haben, 0.1mA Dauerstrom fuer einen LOW Status sind viel zu viel.

    nurazur : Hat sich hier etwas in der Firmware geändert?

    nein. 'intr' war noch in Version 2.0.0, die hab ich aber nicht dokumentiert. 'int' ist richtig ab Version 2.1.0. hama: wäre besser wenn du die Firmware auf Version 2.1.0 änderst.


    Einen Status kann ich so nicht übertragen bzw. ich kann den nicht erkennen.

    nein, übertragen kannst du den Status nicht, ausser du passt die Firmware an. Aber (Trick!) du kannst zwei Interrupts auf den selben Pin mappen, einmal auf FALLING und einmal als "RISING" triggern. Den Status kann man dann daran erkennen welche Flanke als letztes gesendet wurde.

    Habt ihr mal nen CCS881 genutzt?

    ich hab kurz mal damit gearbeitet. Nachdem ich aber gelesen habe dass das Teil erst mal 48 Stunden kontinuierlich laufen muss bevor man es ueberhaupt nutzen kann ("burn in"), und dass es dann nach jedem Einschalten mindestens 20 Minuten laufen muss bis die Werte stabil sind ("Run in"), hab ich für mich beschlossen dass das Teil für meine mobile Anwendungen (TiNo) wegen zu hohem Batterieverbrauchs nicht geeignet ist.

    Heisst nicht dass ich mir das nicht irgendwann mal genauer anschau.

    Wie man es kalibriert, und was man da kalibrieren kann, steht im Datenblatt, aber auch hier ist das Procedere nicht für mobile Anwendungen geeignet.

    In den log-Dateien von Muchul ist auch immer die Variable 'f' vorhanden. Wofür steht diese Variable? In der Protokoll-Beschreibung wird sie nicht erwähnt.

    das ist das rohe Flag-Register, eine Bitmaske mit 8 Bits:


    Bit 0: Heartbeat (der Sensor sendet etwas von sich aus, wenn z.B. ein Timer überläuft und meldet "ich bin noch da!". Das Bit ist immer gesetzt wenn ein Sensor eine geplante Messung abschickt.

    Bit 1: Pinchange Interrupt 0 (0= kein Interrupt, 1=Interrupt hat ausgeloest)

    Bit 2: Pinchange Interrupt 1

    Bit 3: Pinchange Interrupt 2

    Bit 4: Pinchange Interrupt 3

    Bit 5: zeigt ein spezielles HF-Protokoll an, ist aber nur für den Dekoder im TiNo selbst bestimmt, hier also nicht interessant

    Bit 6: Es handelt sich um die Antwort auf einen "ACK-request" - Anforderung einer Empfangsbestätigung (interessant für Aktoren, für Sensoren irrelevant)

    Bit 7: "Ack-request" an einen Zielnode (interessant für Aktoren, für Sensoren irrelevant)


    Bits 1 bis 4 werden für die Variable "int" ausgewertet.

    Ich weiss nicht inwieweit das für euch interessant ist - wenn ja, kann ich das gerne in die Spezifikation mit aufnehmen.

    Data received: 63 v=2697&c=101&t=2936&h=4650&f=2&int=0x1&sy=0&rssi=-1010&fo=-1281&be=1

    das sind die Rohdaten wie sie vom TiNo kommen. Was mir auffällt ist dass der RSSI sehr niedrig ist (-101 dBm) und du bekommst sogar schon Bitfehler (die der Algorithmus noch korrigieren konnte), aber es sieht so aus als sei dein Link Budget fast erschoepft. Auch hast du die Sendeleistung auf 12 dBm erhoeht.


    Das heisst du musst damit rechnen dass das eine oder andere Paket gar nicht ankommt.


    Wie sieht deine Funkstrecke aus? ist der Sender sehr weit vom Receiver entfernt? Was hast du mit den Antennendrähten gemacht?

    Wie viel Strom verbraucht denn LTE IOT?

    Das weiss ich nicht, drum wuerde ich es ja gerne testen. Aber mit Sicherheit wird es mehr sein als Sigfox und LoRaWAN.


    Aber vielleicht bieten deutsche Mobilfunkanbieter auch LoRaWAN an, wie bei uns in F? muesste man recherchieren. Ich denke, wo ein Mobilfunkmast, da auch ein potentielles LoRaWAN Gateway. Ist bei denen nur ein Software-Upgrade, die Infrastruktur ist ja vorhanden.

    Wozu brauchst du das?

    Es geht darum (sehr) kleine Datenmengen gelegentlich von A nach B ins Internet zu uebertragen (z.B. M2M Anwendungen). Die Anforderungen an Zuverlaessigkeit (QoS, quality of service) und Batterielebensdauer (5 Jahre, besser 10 Jahre) sind extrem. Meine Tino's sind nur eine Studie. Eigentlich hab ich was anderes vor gehabt.

    Bisher hat man in der Industrie dazu GSM mit SMS genommen. Wie wir alle wissen, wird GSM irgendwann abgeschaltet, deshalb muss man sich langsam aber sicher um Alternativen kuemmern. Ausserdem frisst eine GSM Verbindung eine Menge Strom.

    Es gibt aus meiner Sicht drei konkurrierende Technologien:

    1. LoRaWAN

    2. Nb IOT (Narrow-Band IoT, manche sagen auch G4.5)

    3. Sigfox.


    LoRaWAN ist toll, aber macht nur mit einem Netzwerk Sinn das aehnlich dicht ist wie das der Mobilfunkanbieter. TTN ist ein Netzwerk das auf einer Community basiert, fuer industrieanwendungen waere mir das im Moment zu riskant, obwohl ich glaube dass das die Zukunft ist. Da geht es um Investitionen fuer die naechsten 10++ Jahre.

    Sigfox ist ein Startup und niemand weiss wie die sich in diesem Markt gegen die Konkurrenz behaupten werden.

    Nb IoT kann auf die existierende LTE Infrastruktur zurueckgreifen und ist auch deshalb sehr interessant weil die grossen Mobilfunkanbieter entsprechenden QoS liefern koennen. Nachteil ist der enorme Software Overhead (ETSI Standard) mit SIM etc. (Kosten!) , bei LoRaWAN dagegen hab ich sogar einen Node gesehen der mit einem ATTiny85 (sic!) laeuft. Nachteil von Sigfox ist die proprietaere Hardware, d.h. man kann nicht wie bei LoRaWAN sein eigenes Netzwerk aufbauen, oder sich bei TTN anmelden, man ist auf das Sigfox Netzwerk festgenagelt.


    Wie du siehst hat alles seine Vor- und Nachteile. NbIoT wuerd ich daher ganz gerne testen ohne ein Vermoegen dafuer ausgeben zu muessen. Paradoxerweise betreiben 2 Mobilfunkanbieter (Orange und Bouyges) hier in Frankreich ein LoRaWAN Netzwerk, aber die wollen natuerlich Geld dafuer, und es ist auch professionellen Anwendern vorbehalten. Irgendwie scheinen die dem NbIoT nicht so ganz zu trauen...

    1. Bedeutet der Datenpunkt 'FEI' in Protokoll V1.1 und der Datenpunkt 'Frequency offset' in Protokoll V2.0 das selbe?

    nicht ganz. "FEI" bedeutet 'Frequency Error indicator' und ist eine Zahl ohne Einheit, die die Anzahl der Schritte angibt die der Empfänger-Oszillator gebraucht hat um sich auf die Senderfrequenz abzustimmen. (ähnlich wie bei einem UKW Radio wo man früher an der Kurbel gedreht hat bis man einen Kanal gefunden hat).

    Die Groesse der Schritte in Hz ist spezifisch für den verwendeten Typ Transceiver IC . Beim RFM69xxx sind das etwa 61Hz, beim CC1101, den ich in Zukunft auch unterstützen moechte, sind es etwa 397 Hz pro Schritt. Deshalb finde ich es besser wenn man den Versatz in Hz ausgibt.


    2. Wird die RFM69-Temperatur im Protokoll V2.0 nicht mehr übertragen?

    Nein. Da die Temperatur mit +/- 3K sowieso sehr ungenau ist und nur als Debug-Wert gedacht war, lasse ich das weg. Man kann trotzdem am Gateway einen richtigen Temperatursensor einsetzen, wenn man das will, aber ich weiss nicht ob das sinnvoll ist. Es ergibt - für mich - mehr Sinn, wenn man so einen Temperatursensor unabhängig vom TiNo am Raspberry Pi anschliesst, der kann per crontab die Messungen regelmäßsig durchführen.


    Der Grund warum ich den Wert überhaupt erfasst hatte war herauszufinden, ob es möglich ist die gemessene Temperatur zur Kompensation der Temperaturdrift des Quarzes zu verwenden.

    (ja, aber nur wenn der Sensor kalibriert ist, aber ich habe bisher keine gute Lösung wie man den kalibrieren könnte)

    3. Nochmal zu den Interrupts, aber diesmal im Protokoll V2.0. Dieser ist in deiner Protokollbeschreibung V2.0 (letzte Seite) noch als 8bit hex dargestellt und nicht weiter beschrieben. Wolltest du den nicht erweitern

    doch... kommt... du sagtest doch ich soll mir Zeit lassen. Entwurf als PN.

    Es gibt eine neue Firmware für das Tino Funksystem!


    Der TiNo Firmware Update 2.0.1 ist jetzt auf github. Die Version ging von 1.x auf 2.x weil es Inkompatibilitäten gibt, die aber NICHT das Funkinterface betreffen. Das heisst, alle TiNo's die mit Sketchen der Versionen 1.x geflasht wurden sind vom Funkprotokoll her voll kompatibel mit der neuen Version.


    Bei dem Update geht es vor allem um zwei Bereiche:

    1. Erweiterung der Funktionalität. TiNo Empfänger koennen jetzt als "Aktoren" dienen, also Licht ein/ausschalten, Thermostaten regeln etc, eigentlich genau wie ein Homematic System. Allerdings muss ich die entsprechende Dokumentation erst noch fertig stellen.


    2. Noch mehr Sensoren: neben den bekannten HTU21D, SHT2x und SHT3x werden jetzt DS18B20 und BME280 unterstützt. Da der Speicherplatz im Atmega328 aber zu klein für alle ist, muss der jeweilige Sensor vor dem Kompilieren mittels Kompiler-Switch ausgewählt werden.


    Wer bereits die "Tiny Nodes" im Board Manager der Arduino IDE installiert hat, kann nun einfach auf Version 2.0 erhoehen.


    Neu ist:

    1. Als Empfänger kann der TiNo Aktionen ausführen, die man frei definieren und im EEPROM ablegen kann. Man kann festlegen, auf welchen der 4 moeglichen Interrupts reagiert werden soll, wie reagiert werden soll, also welcher Port angesprochen werden soll und auf welchen Sender reagiert werden soll. Moegliche Kommandos sind "AN", "AUS" "Toggle" (ändere den Port-Zustand) und "Puls". Die Zeitdauer eines Pulses kann ebenfalls konfiguriert werden.
    2. das serielle Interface des Empfänger-Sketches. Dies ist von jetzt an dem ursprünglichen Protokoll des TinyRx4 sehr ähnlich, mit einer Reihe von Erweiterungen. Ausserdem werden die ankommenden Pakete besser auf Plausibilität geprüft.
    3. Die Prüfsumme des Eeproms ist jetzt CRC-16, das ist zuverlässiger als die 8-bit Prüfsumme bisher.
    4. Die Temperaturdrift des Quarzes auf dem RFM Modul kann kompensiert werden. Das ist eigentlich nicht notwendig, hat aber Vorteile wenn man den TiNo in extremen Umgebungen betreiben will. Im Moment ist die Funktion im Sketch auskommentiert.
    5. Die Batteriespannung wird jetzt während dem Sendepuls gemessen. Das erlaubt eine wesentlich bessere Abschätzung des Zustandes der Batterie. Mit zunehmender Entladung nimmt der Innenwiderstand der Batterie zu, gegen Ende der Lebensdauer wird das der bestimmende Faktor, während die Leerlaufspannung durchaus noch vernünftig ist. Das RFM69 Modul bricht bei etwa 1.7V Betriebsspannung zusammen.
    6. die Python Skripte zum Konfigurieren der TiNo's sind jetzt kompatibel mit Python Version 3. Achtung, diese Skripte sind nicht mit TiNo Version 1.1 kompatibel. wer also noch Sensoren im Netzwerk hat die mit TiNo Version 1.x konfiguriert werden, der sollte sich die alten Tools unbedingt aufheben.
    7. neue Bootloader und neue Fuses: Da der Flashspeicher langsam knapp wird, verwende ich optiboot Bootloader, die benoetigen gerade mal 512 Bytes im Flash.





    Ich meinte welches Format hat diese Zahl im jetzigen Protokoll V1.1?

    HEX

    ja das ist soweit richtig.

    Aber ich dachte wir hätten uns darauf geeinigt dass ich für die Version 2.0 das Interface dem TinyRX4 angleiche. dann kann man nämlich sowohl den TiNo als auch den TinyRX mit dem selben ioBroker Adapter betreiben. Ich bin gerade dabei die Version2.0 auf Github hochzuladen, mit dem TinyRX Interface.

    Eine Interface Spezifikation habe ich auch, die ist aber leider noch nicht 100%ig fertig.

    Für die Interrupts moechte ich deinen Vorschlag für jeden interrupt 2 bits zu verwenden umsetzen. Das Heartbeat Flag ist in diesem Zusammenhang eigentlich unwichtig, weil es in der jetzigen Form keine Aussagekraft hat:

    Ist das Interrupt Byte Null, dann handelt es sich um ein reguläres Paket, d.h. das Heartbeat Flag ist 1.

    Ist das Interrupt Byte ungleich Null, dann handelt es sich um ein nicht reguläres, von einem Interrupt ausgeloestes Paket.


    Anbei die 2.0 Spec in ihrer jetzigen Form, ich mach's fertig so schnell ich kann, kann aber morgen werden. Ist aber wirklich mitten in der Bearbeitung, koennen also Tippfehler drin sein etc.