FHEM Forum

Ihr Lieben,
durch diesen Post https://forum.fhem.de/index.php/topic,68971.0.html, bin ich auf die Betty aufmerksam geworden.
Leider sind Wiki u. Repository zur Betty scheinbar Tod. Das Forum existiert aber noch und da findet man dann interessante Ansätze, wie man die FB mit seiner schicken Ausstattung(433MHz über CC1100, IR) nutzen könnte. Auch haben wohl einige das Ding in der Schublade und bei Pollin gibt es sie wohl auch noch für 4 EUR.

Im Forum hab ich nur diese Posts gefunden, wo scheinbar Boris Versuche gemacht hatte, aber mangels Interesse von anderen nicht mehr weiterverfolgt hat.
https://forum.fhem.de/index.php/topic,5505.msg20495.html#msg20495
https://forum.fhem.de/index.php/topic,11457.msg70817.html#msg70817

und ich hab, wohl kein Zufall, festgestellt, dass sowohl das Betty-Forum, als auch unseres, einen User Telekatz haben, der bei uns ja die culf@ARM betreut. https://forum.fhem.de/index.php/topic,38404.msg327424.html#msg327424

Von ARM-Entwicklung hab ich null Plan und bin gerade erst in die Atmel/Arduino-Welt eingestiegen.  :'(

Diesen Thread möchte ich daher nutzen, um die Erfahrungen zur Betty und FHEM zu sammeln, mir dann ggfs. Betty's zulegen und in die Entwicklung einsteigen.

Ich könnte mir die Betty als einfachen 433/IR-Hub vorstellen, was vermutlich machbar ist. Vielleicht auch als schicke FB in eine IT-(Derivate)-FB umzuwandeln und das allergrößte wäre es, wenn ich, evtl. durch Harwareumbau(IR-Baustein), einen 433-B&O-Hub hinbekäme, nach dem ich mich schon lange sehne.

Ich freu mich über Eure Beiträge.

Grüße Markus

-----------------------------------------------------------------------------------------------------------------------------------------------------------
Was ist die Betty ?
Die Betty ist die Hardware eines um die Jahrtausendwende entwickelten Systems, welches aus einem TAE-Adapter, einem SCART-Adapter und einer Universal-Fernbedienung mit Ladeschale besteht, das für eine Form "interaktiven Fernsehens" entwickelt wurde. Die 3 Geräte kommunizierten über Funk miteinander.
Die Idee wurde dann durch das Internet überholt, das Projekt vom Hersteller eingestellt.

Die Hardware der Betty etwas ausführlicher
Die Fernbedienung verfügt über interessante Features. Neben dem 433MHz-CC1100-Funkchip, der in einer ähnlichen Variante auch im CUL oder S'duino seinen Dienst verrichtet, verfügt die Betty über ein hintergrundbeleuchtetes Display, Tonausgabe, eine Tastatur ähnlich Universal-Fernbedienungen und einer leicht zugänglichen Programmierschnittstelle.

Was ist Boop ?
Eine kleine Gemeinde entdeckte die nun eigentlich nutzlose Hardware für sich und entwickelte die Programmierschnittstelle und eine neue Firmware, programmiert in C. Es entstand ein Forum und ein Wiki. Vermutlich durch Hackerangriffe wurden die Inhalte zerstört, was dann scheinbar auch der Grund dafür war, dass dieses Projekt sein Ende fand.

Das Vermächtnis von Boop
Zum Glück wurde aber ein Backup des Wikis gerettet und ist auch heute noch z.B. über diesen Link (https://web.archive.org/web/20140108154117/http://bettyhacks.com/wiki/index.php/Main_Page) zugänglich.

- Das Forum (http://bettyhacks.com/forum/) zu Betty.
- Den letzten Stand des Sourcecodes findet man hier (https://sourceforge.net/p/boopfirmware/code/HEAD/tree/):
- Toolchain für das compilieren des Sourcecodes hier (https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q3-update/+download/gcc-arm-none-eabi-4_8-2014q3-20140805-win32.exe)(bitte keine neuere Version als die im Link genannte wählen, da das zu Problemen führen kann).
(wer vorher noch keine andere Entwicklung betrieben hat, benötigt wahrscheinlich noch ein build tool wie dieses (https://github.com/gnu-mcu-eclipse/windows-build-tools/releases/download/v2.8/gnuarmeclipse-build-tools-win32-2.8-201611221915-setup.exe) von Eclipse)
- Das Windows-Programm Betty-Heaven zum Flashen der firmware auf die Betty gibt es hier (http://colibri.bplaced.net/Betty.htm).
  Neben Betty-Heaven wird ein preiswerter USB-TTL-Adapter für die physische Verbindung der Programmierschnittstelle der Betty mit einem Windows-Rechner benötigt. Alternativen wie Eigenbau, Nutzung alter Handykabel etc. sind im Betty-Wiki beschrieben.

Weiterentwicklung von Boop in FHEM
In 2017 wurde die umfangreiche Hardwareausstattung der Betty für FHEM wiederentdeckt und Boop weiterentwickelt. Dank des Users Telekatz, wurde die firmware auch für ungewöhnliche und hohe Trägerfrequenzen wie z.B. 455kHz für das Bang&Olufsen-Infrarotprotokoll erweitert. Der Sourcecode und flashfähige binaries fanden ein neues Zuhause (https://github.com/Telekatz/boop): 

Funktionalität der binaries
Auch ohne Programmierung und Installation der Toolchain lassen sich die binaries nutzen. Dazu braucht es dann nur o.g. USB-Adapter und das Windows-Flash-Programm Betty-Heaven.
Mit dem binary steht einem eine nette IR-Universalfernbedienung für 4 Geräte zur Verfügung, die bereits einen riesen Umfang an Geräten abbildet. Noch nicht implementierte Protokolle, die aber im LIRC-Projekt implementiert sind, lassen sich leicht programmieren. Auch lassen sich IR-Codes anlernen.

Ausblick zur Integration in FHEM
Derzeit ist bereits das Senden von SlowRF-Protokollen(getestet: IT-V1, IT-V3, FS20(sehr begrenzte Reichweite)) per Tastatur möglich und getestet. Die Software soll weiter ausgebaut werden, so dass Interaktionen wie Alarmierungen per Ton u. LCD aus FHEM heraus möglich werden.

Das Wiki ist noch über die WaybackMachine abrufbar: Stand 27.12.2012 (http://web.archive.org/web/20121227093254/http://www.bettyhacks.com/wiki/index.php/Main_Page)

Interesse hätte ich auf jeden Fall auch an einer Einbindung in FHEM. Ich muß das Teil mal in meinen Kisten suchen.

Hurra, neues Leben in alter Hardware. Ich habe 3 Bettys im Keller liegen. Bei einer hatte ich vor Jahren auch schon die Boop-Firmware draufgebügelt. Die Teile sind echte Klopper. Nicht vom Specs, von den Abmessungen ;-)

Programmieradapter müsste ich auch noch haben.

Ich bin damals an der Lowlevel-Programmierung des CC1101 gescheitert. Meine letzte Idee war - soweit ich mich erinnere - die CUR-Firmware auf Betty zu portieren.

Mein Anwendungsfall: die Klopper liegen im Haus herum und werden zum Schalten benutzt (für FS20 und auch als Fernbedienungen i.V.m. sequence). Haben die nicht 868 MHz?

Viele Grüße
Boris

Also, ich habe in meinem Hardware-Fundus auch noch ein paar Bettys in Orginaler Schachtel liegen.

Im Softwarefundus habe ich hier:

• boop-room.bin
• McBetty-0.7.tar.bz2
• Betty-Heaven
• Betty-UniFB

Boris, schön, dass Du Dich gemeldet hast. Auf Dich hatte ich soooo gebaut. Die beiden Threads von damals, die ich gepostet hatte, stammen ja aus Deiner Feder. Aber ist ja schon lange her....

ZitatHaben die nicht 868 MHz?

Wenn ich es richtig quergelesen hab, habt Ihr damals versucht die 433MHz auf 868 umzustricken, um FS20 bedienen zu können. Sicherlich mit den auch beim CUL bekannten Reichweitennachteilen.....

Wenn Du die Klopper(sind die so groß oder schwer ?) aus dem Keller geholt hast, kommt vielleicht auch die Erinnerung wieder....  ;)

Und wie ich gerade sehe, hat auch noch jemand die damaligen Firmwares. Prima  :)

Ja, von den Bettys hab ich auch noch ein paar Kisten voll rumstehen. Die Hardware war ja einigermaßen brauchbar. Nachteilig war nur die geringe Akkulaufzeit. Vergleichbar mit heutigen Smartphones. Nach zwei Tagen leer.

Mit Boop hat culfw@ARM übrigens nichts zu tun. Außer dem Makefile gibts da keine Gemeinsamkeiten.

@Telekatz
schön dass Du Dich gemeldet hast. War meine Spekulation denn richtig, dass der User Telekatz im Betty-Forum und Du identisch sind ?
Wenn ja, warst Du ja äußerst aktiv dort und hast sehr fleißig an Boop mitgewirkt. Du wärst dann sicherlich eine riesen Hilfe für die Einbindung an FHEM.

Ich hab mich gestern ein wenig durch das Betty-Forum gewühlt. Mal ein paar (für mich) neue Erkenntnisse:
Hardwarebeschreibung: http://www.hackdaworld.org/cgi-bin/awki.cgi/BettyTV
Der Prozessor ist ein LP2220 von npx(früher Philips). Datenblatt: http://www.nxp.com/documents/data_sheet/LPC2210_2220.pdf
Es scheint 2 verschiedene Hardwareversionen zu geben. Häufig ist die Rede von der deutschen und der swisscom-Version die Rede. Bei Pollin soll es wohl die swisscom-Variante geben. Manchmal auch als Version HW02 bezeichnet.

Zum Flashen benötigt es ein serielles Interface. Hier https://www.mikrocontroller.net/topic/355651 findet sich über die verschiedenen Posts eine Beschreibung, wie auch im Betty-Forum. Leider nirgends der konkrete Schaltplan, der wohl im nicht mehr vorhandenen Wiki steht. Oft ist auch von einem Siemens-Ladekabel die Rede. Müsst ich noch irgendwo haben  :-\

Die nächste Hürde ist wohl eine funktionierende Toolchain hinzubekommen. Auch dazu gibt es diverse Posts, die immer wieder auf Probleme hinweisen. Da die meisten von uns einen RPi besetzen, sollte es vielleicht das Ziel sein, eine funktionsfähige Toolchain hinzubekommen. Wer kennt sich da aus ?

Den Boop-Sourcecode gibt es hier https://sourceforge.net/projects/boopfirmware/. Ich hab mal den Sourcecode quer gelesen. Wenn ich es richtig verstanden habe, ist es recht simpel Sendecodes für 433MHz einzubinden. Es ist bereits dieser IT-ähnliche Code 0000 00FF FF (0F/F0)und 2 weitere fest verdrahtet. Auch zu FS20 fand ich etwas. Hab ich aber noch weniger verstanden  :-[

Und immer wieder das leidige Thema der Akkus. Aber je nach Einsatzzweck baut man direkt ein Netzteil dran oder nutzt die Ladeschale oder in einem Endstadium widmet man sich den Stromsparmodi....

Zitat von: Telekatz am 16 März 2017, 22:05:50
Ja, von den Bettys hab ich auch noch ein paar Kisten voll rumstehen. Die Hardware war ja einigermaßen brauchbar. Nachteilig war nur die geringe Akkulaufzeit. Vergleichbar mit heutigen Smartphones. Nach zwei Tagen leer.

Deswegen ist ja auch eine Ladestation dabei :-)

Interessant ist der Rückkanal und das Display.

Zitat von: KölnSolar am 17 März 2017, 08:32:26

Zum Flashen benötigt es ein serielles Interface. Hier https://www.mikrocontroller.net/topic/355651 findet sich über die verschiedenen Posts eine Beschreibung, wie auch im Betty-Forum. Leider nirgends der konkrete Schaltplan, der wohl im nicht mehr vorhandenen Wiki steht. Oft ist auch von einem Siemens-Ladekabel die Rede. Müsst ich noch irgendwo haben  :-\

Dieses Siemens oder auch Nokia-Kabel wurde damals (tm) verwendet als serielle Schnittstelle. Heutzutage macht man das wohl einfach über einen CH340-USB-RX-TX usw.
Wozu war eigentlich der Scart-Connector da? Im Zeitalter von HDMI ist das Ding natürlich etwas aus der Zeit gefallen, aber vielleicht ist interessante Elektronik drin.

Zitat von: KölnSolar am 17 März 2017, 08:32:26
Zum Flashen benötigt es ein serielles Interface. Hier https://www.mikrocontroller.net/topic/355651 findet sich über die verschiedenen Posts eine Beschreibung, wie auch im Betty-Forum. Leider nirgends der konkrete Schaltplan, der wohl im nicht mehr vorhandenen Wiki steht. Oft ist auch von einem Siemens-Ladekabel die Rede. Müsst ich noch irgendwo haben  :-\

Wie gesagt, das Wiki ist in der WaybackMachine konserviert. Die Anschlußbelegung an der Betty steht hier (http://web.archive.org/web/20121212070403/http://www.bettyhacks.com/wiki/index.php/Betty_Hardware#Anschlussbelegung).

Zitat von: Bapt. Reverend Magersuppe am 17 März 2017, 08:55:06Wozu war eigentlich der Scart-Connector da? Im Zeitalter von HDMI ist das Ding natürlich etwas aus der Zeit gefallen, aber vielleicht ist interessante Elektronik drin.

Der Scart Adapter hat aus dem Videosignal den Videotext decodiert und per Funk an Betty gesendet. Und nachts wurden dann mit dem TAE-Adapter Daten mit den Betty-Servern ausgetauscht. Alternativ gab's dazu einen IP-Adapter.

Ich weiß gar nicht, ob ich die Adapter noch habe. Ich hatte meine Betty damals noch ein zeitlang als Universalfernbedienung genutzt und nach dem letzten Umzug ist sie in der Kiste gebieben.

ZitatWie gesagt

Hatte ich in Deinem ersten Post glatt übersehen  :-[

Zitatdas Wiki ist in der WaybackMachine konserviert.

Das ist ja genial  :-* :-* :-*

Also mit der Bezugsquelle Pollin war es wohl nix. Aber amazon und eBay. Bevor ich jetzt dort 3-4 Stck. bestelle und der ein oder andere hier aus dem Forum den Keller entrümpeln möchte.....  ;)

Wegen der Toolchain: Was macht da Sinn auf dem Rpi zu installieren:
so wie im Wiki beschrieben: http://web.archive.org/web/20120929025327/http://www.bettyhacks.com/wiki/index.php/Entwicklungsumgebungen#Linux
oder ist das eine alte Version und man nimmt etwas aus dieser Übersicht: http://download.ronetix.info/toolchains/arm/
oder gar was ganz anderes, weil viel moderner(aus unserem culf@arm-Thread): https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update
Hat da jemand der Linux-C-Entwickler einen guten Rat ?

Zitat von: KölnSolar am 17 März 2017, 08:32:26
@Telekatz
schön dass Du Dich gemeldet hast. War meine Spekulation denn richtig, dass der User Telekatz im Betty-Forum und Du identisch sind ?
Wenn ja, warst Du ja äußerst aktiv dort und hast sehr fleißig an Boop mitgewirkt. Du wärst dann sicherlich eine riesen Hilfe für die Einbindung an FHEM.

Ja, das war ich.

Zitat von: KölnSolar am 17 März 2017, 11:10:30
Also mit der Bezugsquelle Pollin war es wohl nix. Aber amazon und eBay. Bevor ich jetzt dort 3-4 Stck. bestelle und der ein oder andere hier aus dem Forum den Keller entrümpeln möchte.....  ;)

Wegen der Toolchain: Was macht da Sinn auf dem Rpi zu installieren:
so wie im Wiki beschrieben: http://web.archive.org/web/20120929025327/http://www.bettyhacks.com/wiki/index.php/Entwicklungsumgebungen#Linux
oder ist das eine alte Version und man nimmt etwas aus dieser Übersicht: http://download.ronetix.info/toolchains/arm/
oder gar was ganz anderes, weil viel moderner(aus unserem culf@arm-Thread): https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update
Hat da jemand der Linux-C-Entwickler einen guten Rat ?

Wieso überhaupt der Versuch, einen Rpi dafür zu nehmen? Aus Gründen der Einfachheit würde ich die selbe Toolchain nehmen wie für culfw@ARM. Muss mal schauen, ob ich Boop damit übersetzt bekomme.

Zitat von: Bapt. Reverend Magersuppe am 17 März 2017, 08:55:06
Wozu war eigentlich der Scart-Connector da? Im Zeitalter von HDMI ist das Ding natürlich etwas aus der Zeit gefallen, aber vielleicht ist interessante Elektronik drin.

Für die Decodierung des Videotextes ist ein CPLD enthalten, der µC ist ein relativ kleiner MSC-51 Controller. Für eine Minimalstversion eines CULs mit nur dem RFnative Protokoll zur Kommunikation mit der Betty reicht der Platz vielleicht noch aus.

Hi,
Also das hört sich lustig an! Ich will auch mitesten. Hat jemand zwei über? Bitte eine PM an mich ;-)
Gruß Arnd

Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...

ZitatWieso überhaupt der Versuch, einen Rpi dafür zu nehmen?

Nur weil ich dachte, dass die meisten "Bastler" einen Rpi besitzen, dann also möglichst viele von einer einheitlichen und funktionsfähigen Lösung profitieren würden.
Unter welchem Betriebssystem entwickelst Du ?

Hey, ich hab auch noch eine irgendwo. Bin dabei [emoji111]

Gesendet mit Tapatalk

Zitat von: KölnSolar am 17 März 2017, 13:39:08
Nur weil ich dachte, dass die meisten "Bastler" einen Rpi besitzen, dann also möglichst viele von einer einheitlichen und funktionsfähigen Lösung profitieren würden.
Unter welchem Betriebssystem entwickelst Du ?

Ich verwende Windows. Und ich denke auch die meisten "Bastler" haben einen Windows und/oder Linux PC. Dafür gibt es die fertigen Toolchain auf Launchpad. Mit ein paar Änderungen im Makefile kompiliert auch Boop damit.

Ok, dann probier ich es mal damit. Verräts Du noch die notwendigen Änderungen am Makefile.

Dann macht es sicherlich auch Sinn betty-heaven zum flashen zu nehmen, oder ? Verfügbar hier http://colibri.bplaced.net/Betty.htm

Zwischenzeitlich hab ich meinen USB-TTL-Konverter als Flashinterface hervorgekramt. Der sollte funktionieren. :)

Immer noch keiner, er ein paar Bettys loswerden möchte ?

Folgende Änderung habe ich vorgenommen:

Index: boop/trunk/Makefile
===================================================================
--- boop/trunk/Makefile (revision 60)
+++ boop/trunk/Makefile (working copy)
@@ -18,14 +18,15 @@
#####
###############################################################

-ARMBASE = /opt/toolchains/gcc-arm-none-eabi-4_9-2014q4
-INCLUDEPATH = $(ARMBASE)/include
-#LIBGCCPATH = $(ARMBASE)/lib/gcc/arm-none-eabi/4.7.3/thumb/arm7tdmi-s
-#LIBCPATH = $(ARMBASE)/arm-none-eabi/lib/thumb/arm7tdmi-s
+
+ARMBASE = F:/Tools/GNU_Tools_ARM_Embedded/5.4
+INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
+LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-
LPCTOOL = lpctool
-OPENOCD = openocd -f betty.cfg -f interface/parport.cfg
+OPENOCDPATH = F:\Tools\OpenOCD-20160901
+OPENOCD = $(OPENOCDPATH)\bin\openocd.exe -f $(OPENOCDPATH)\share\openocd\scripts\interface\jlink.cfg -f betty.cfg

###############################################################
#####
@@ -34,17 +35,17 @@
###############################################################

CC = $(ARMPATH)/$(TOOLPREFIX)gcc
-AS = $(ARMPATH)/$(TOOLPREFIX)as
-#LD = $(ARMPATH)/$(TOOLPREFIX)ld
+AS = $(ARMPATH)/$(TOOLPREFIX)gcc
LD = $(ARMPATH)/$(TOOLPREFIX)gcc
OC = $(ARMPATH)/$(TOOLPREFIX)objcopy
OD = $(ARMPATH)/$(TOOLPREFIX)objdump
+SIZE = $(ARMPATH)/$(TOOLPREFIX)size

CPUFLAGS = -mcpu=arm7tdmi-s
OPTFLAGS = -Os
-CFLAGS = -Wall -mthumb-interwork -msoft-float
+CFLAGS = -Wall -mthumb-interwork
INC = -I$(INCLUDEPATH) -I. -Iinterrupt -Idisplay -Ikeyboard -Iaudio -Iinfrared -Iserial -Iflash -Icc1100 -Igui -Itimer -Igames -Iadc -Irtc  -Itools
-ASFLAGS = -D --gstabs -mthumb-interwork -mfpu=softfpa
+ASFLAGS = -g -I. -mthumb-interwork
#LDFLAGS = -Tlpc2220_rom.ld -Map boop.map
#LIBS = -lc -lgcc
LDFLAGS = -mthumb-interwork -nostartfiles -Xlinker -Map -Xlinker boop.map -Tlpc2220_rom.ld
@@ -122,7 +123,7 @@
$(LD) $(LDFLAGS) -L$(LIBGCCPATH) -L$(LIBCPATH) -o $@ $^ $(LIBS)

%.o: %.s
- $(AS) $(CPUFLAGS) $(ASFLAGS) -o $@ $<
+ $(CC) $(ASFLAGS) -c -o $@ $<

%.o: %.c
$(COMPILE) $(OPTFLAGS) -c -MMD -MF $(dir $<).deps/$(notdir $@) -o $@ $<
Index: boop/trunk/keyboard/keyboard.c
===================================================================
--- boop/trunk/keyboard/keyboard.c (revision 60)
+++ boop/trunk/keyboard/keyboard.c (working copy)
@@ -52,7 +52,7 @@
setBacklight(BL_AUTO); // pwm value
}

-inline char isKeyPressed (void)
+char isKeyPressed (void)
{
    return ((keys[0] != 0) || (keys[1] != 0));
}
Index: boop/trunk/keyboard/keyboard.h
===================================================================
--- boop/trunk/keyboard/keyboard.h (revision 60)
+++ boop/trunk/keyboard/keyboard.h (working copy)
@@ -188,7 +188,7 @@
void waitKeyUp(void);
void waitKeyDown(void);
/// Return 1 if any key is pressed.
-inline char isKeyPressed (void);
+char isKeyPressed (void);
signed char getNumKeyValue(void);
unsigned char getKeynum(void);



Danke für die Anpassungen am makefile. Wenngleich die Form als diff mir insofern Problemchen bereitete, dass ich die Zeilen einzeln per cut&paste ändern musste. Ich hoffe, ich hab da jetzt keine Fehler eingebaut  :-[ Als Dateianhang wäre das für mich und andere Amateure sicherlich einfacher zu handeln. Aber der Reihe nach ...

Erster Schritt war die Installation der Toolchain. Eigentlich ja recht einfach. Da ich bisher außer mit Arduino-IDE nicht unter Windows entwickelt habe, habe ich dann aber gleich 2mal installiert. Denn irgendwann fiel mir auf und ein, dass Win zwar Verzeichnisse vorschlägt, leider aber mit Leerzeichen, die ich dann später nicht zu maskieren wusste  :-[ Also für Nachahmer: lasst einfach die Leerzeichen weg und wählt kurze Verzeichnisnamen, denn mit dem Tablet auf der Couch wird die Tipperei in einer Konsole recht unamüsant :(

Nun noch die Boop-Sourcen auf WinDoof gebracht, makefile angepasst  und los geht's. Denkste ! Ein make kennt mein WinDoof (noch) nicht  :( Spätestens zu diesem Zeitpunkt kommt mir mein Bauchgefühl, besser auf dem Rpi zu entwickeln, wieder in den Sinn  :-\ Aber die Entscheidung ist ja gefallen. Also im Inet nach einer Lösung gesucht. Ich bin dann auf Eclipse gestoßen. Ebenfalls installiert und... Voila, ich kann ein make aufrufen, das sich aber mit Händen und Füßen gegen mich wehrt  :( Das im makefile von boops verborgene "svnversion" kennt WinDoof nun auch nicht. Außerdem fällt mir ein "include makefile.local" im makefile ins Auge, welches ich gar nicht hab.  :o Bei einem Blick ins Betty-Wiki ist mir dann aufgefallen, dass dort beschrieben ist, man solle dafür die "Musterdatei" makefile.local.WinArm kopieren. Ja, aber was steht denn da drin ? Definitionen, die ich bereits im makefile stehen hab, außer, dass dort noch auf Verzeichnisse von WinArm verwiesen wird, was ich ja bewusst nicht als Toolchain installiert habe. :o

Mit diesem Konflikt hab ich dann die Arbeiten eingestellt und mir vorgenommen Euch heute Morgen ein paar Zeilen und Fragen zu schreiben.

1. Braucht es dieses makefile.local/include überhaupt und wenn ja, was schreibe ich da für die gewählte Toolchain rein. Oder muss ich zusätzlich WinArm installieren ?
2. Woher kriege ich dieses svnversion ? Muss ich evtl. so etwas wie TortoiseSVN installieren ?

Ich bin da immer etwas vorsichtig alles Mögliche zu installieren, was sich vielleicht später rächen, weil beissen könnte  :-[

Danke&einen schönen Sonntag
Markus

Moin,
Erstmal ne kurze Möglichkeit Lange Verzeichnisse zu kürzen:

subst z: "c:\langer Ordnername\sogar mit Leerzeichen"

Und schon gibt es z:\ ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Das Leben kann manchmal so einfach sein, wenn man sich auskennt  :-[

1. makefile.lokal braucht man nicht unbedingt. Ist dafür gedacht, dass man lokal bestimmte Dinge wie z.B. den Pfad zur Toolchain anpassen kann, ohne das Makefile aus dem SVN Repo anpassen zu müssen.

2. Nimm das angehängte makefile und version.h, dann funktioniert es auch ohne SVN.

Danke, wir nähern uns nun fast dem Ziel Aber nur fast  :(
mkdir -p $@
macht 2 Probleme. Irgendwie scheint $(1) wohl mit einem whitespace befüllt zu werden, was das make mit mkdir -p adc/ .deps abbrechen lässt. Hab da leider keinen Plan zu  :-[
Das 2. Prob. ist weniger wild aber um so überraschender. Parameter -p macht nicht, was er soll, sondern es wird ein Verzeichnis -p angelegt  :o Sowohl auf dem Laufwerk, als auch in der Registry nach dem "falschen" mkdir gesucht: negativ Rufe ich das EINZIGE mkdir aus dem eclipse-verzeichnis auf, funktioniert es richtig. Wo hat sich da welcher Geist versteckt ?

Ach so, und beim anpassen der Pfade kam mir in den Sinn nach openocd zu suchen. Ergebnis: ich musste es erst noch installieren.

Mach mal mit cmd eine Eingabeaufforderung auf und suche mit "where mkdir", ob nicht vieleicht doch irgendwo ein zweites mkdir in PATH versteckt ist.

Openocd brauchst du nur, wenn du ein JTAG zum Flashen verwendest.

Hihi,
auf ner Windose where? Evtl. unter cygwin, oder geht das echt?

Test:
Spannend wieder was gelernt:

C:\Windows\system32>where mkdir
C:\Program Files\WinAVR\utils\bin\mkdir.exe

C:\Windows\system32>where MKDIR
C:\Program Files\WinAVR\utils\bin\mkdir.exe

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Zitat von: Bapt. Reverend Magersuppe am 17 März 2017, 08:55:06
Dieses Siemens oder auch Nokia-Kabel wurde damals (tm) verwendet als serielle Schnittstelle. Heutzutage macht man das wohl einfach über einen CH340-USB-RX-TX usw.
Wozu war eigentlich der Scart-Connector da? Im Zeitalter von HDMI ist das Ding natürlich etwas aus der Zeit gefallen, aber vielleicht ist interessante Elektronik drin.

Ganz genau das war damals meine Motivation den Text über das Siemens-Datenkabel ins Betty-wiki zu hacken.
Funktional entspricht dieses Kabel mit abgeschnittenem Stecker genau dem was man heute mit einem USB-RS232-TTL-Wandler aus Übersee bekommt, nur dass damals die echten Comports noch verbreiteter, die Handykabel öfter herumliegend und die USB-Seriell-Wandler noch etwas problematischer in der Anwendung gewesen sind.
Dazu habe ich eine kleine Platine gehäkelt, welche die Reset- und BLEN-Leitungen auf jeweils einem Dip-Schalter mit Masse brückbar macht.

P.S.: Hier der Wayback-Link zum Interface-Artikel, 10 Jahre ist es her..

http://web.archive.org/web/20121212070403/http://www.bettyhacks.com/wiki/index.php/Interfaces_PC_zu_Betty

es konnten keine Dateien mit dem angegebenen muster gefunden werden  :o

also hab ich den eclipse-pfad in die path-variable eingetragen. where antwortet nun richtig, und mkdir funktioniert jetzt auch richtig :o  ;D warum auch immer.

Und make ? Nach ein paar kleineren Problemchen, die selbst durch mich behebbar waren.... läuft durch  ;D ;D ;D

Entwicklungsumgebung steht also erst einmal, Betty kann kommen  ;D

DANKE Telekatz  :-* :-* :-*

Hi,
also heute war Weihnachten für KölnSolar und mich ;-) Soll heißen Bapt. Reverend Magersuppe hat uns aus seinem Fundus Betty FB überlassen! Vielen Dank dafür in Deine Richtung!!! Die Postfrau war übrigens super nett ;-)

Da die Entwicklungsumgebung bei KölnSolar schön eingerichtet ist, gilt es nun die richtige Flashtechnik zu entwickeln...
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Hurra, Betty mit Boop ist da  ;D  ;D ;D

Aber von Anfang an. Vielen lieben Dank an Bapt. Reverend Magersuppe , der mir 2 OVP Bettys spendiert hat. Und vielen Dank an Arnd, der mir dann die Bettys ohne Boop gebracht hat.  :-* :-* :-* Möglich, weil wir 3 in der selben Region leben.

Die Betty sieht erst mal ganz hübsch aus. Zugegeben, durch das Display etwas lang, aber wir wollen ja auch viel  ;)

Ohne Boop(wer hat nur diesen Namen erfunden  8)) kann die Betty gar nix. Man müsste erst das Scart-Funkteil mit Netzstecker anschließen. Und dann das Modem mit Funk, welches dann nach Hause telefonieren würde. Mangels eigener Stromversorgung und, dass es das zu Hause ja nicht mehr gibt, die Idee verworfen, erst einmal die Betty im Standard auszuprobieren.

Also meinen USB-TTL-Adapter an den PC gestöpselt und, man will ja nix kaputt machen, mit Betty-Heaven die Flashs als Backup auslesen. Nach kleineren Schwierigkeiten hat es dann geklappt: Schnittstelle am PC auf 9600,8,N,1 Rx an Tx, Tx an Rx, GND an GND und ein Steckkabel an Reset und eins an EINT1. Eint1 auf GND, Reset auf GND, nun geht Bettys Display aus, Reset weg von GND, EINT1 weg von GND, Backup in Betty-Heaven gewählt und schon befindet sich Bettys Original-Firmware auf dem PC.

Das gleiche nochmal und für Flash1 die bereits erstellte Boop-Firmware ausgewählt im Restore-Modus. Restore-Button und die Verlaufsanzeige von Betty-Heaven läuft. Schnell ist der Flashvorgang fertig. Batterie raus und wieder rein und schon strahlt einen Betty, nun mit Boop, an.  ;D

Schnell versteht man das Menu von Betty. Auf Kanal A ist DBOX2 voreingestellt. Nix wie ab ins Schlafzimmer und meine Alte Box eingeschaltet. Priiiima, funktioniert. Nun für den freien Kanal C den Code über lirc von Samsung für meinen TV ausgewählt. Geht auch.

In nullkommanix hab ich also schon einmal eine nette Uni-IR-FB.

Nun die nächste Stufe. Anlernen von IR-Codes. Vom TV(38kHz) völlig problemlos, ja fast idiotensicher. Jetzt wird es spannend. Wird Betty auch meine B&O(exotische 455kHz) verstehen ???? Neeeeiiiin. Fehler. Zu kurz gedrückt, zu lang gedrückt, nicht erkannt. Nur gut, dass Betty, im Gegensatz zu Alexa, (noch) nicht reden kann  :D

Bis hierhin aber trotzdem schon mal eine nette Uni-IR-Fb.

Aber das Ziel ist ja meine B&O. Ich werde mich mal mit der Frequenz bzw. lirc auseinandersetzen, um mein Ziel zu erreichen. Hoffentlich ohne einlöten neuer IR-Dioden.

Fazit: Ziel die B&O einzubinden vorerst verfehlt und mit FHEM hat das bisherige nu auch nicht wirklich etwas zu tun.

Deshalb habe ich da einen Wunsch, und bevor ich den äußere, nochmal eine Aufzählung, was Betty an Hardware mit sich bringt: IR-Sende-/Empfang-Diode, 433MHz-CC1100, s/w-Display mit Hintergrundbeleuchtung, Lautsprecher, serielles Interface, JTAG-interface, 2*NiMh-1,2V-1.000mAh Akkus und natürlich eine Tastatur.

Nun der Wunsch: wenn sich je Hardwarebaustein mindestens einer von Euch detailllierter mit dem Hardwarebaustein und Boob auseinandersetzt, hätten wir ein Entwicklungsteam, welches relativ schnell noch einiges mehr aus Betty herausholen kann, als es jetzt schon vorhanden ist:

Alarmierung/Info per 433MHz aus FHEM an Betty: blinkend, anzeigend, tönend

Steuerung von 433MHz-devices per Tastatur über FHEM

Sicherung von Datum/Uhrzeit bei Batterie leer/stromparender Betrieb/leistungsfähigere Hardware
(Betty hat die negative Angewohnheit, Datum und Uhrzeit bei Batteriewechsel zu vergessen)

Anbindung von was auch immer über die beiden einfach zugänglichen Interfaces seriell und JTAG

Und die ganz große Vision: dem CC1100 ein quasi CUL-Verhalten einzuhauchen, so dass Betty auch noch als repeater nutzbar ist

Ich beginne mit der 455kHz Funktionalität für IR und Anbindung von IT-devices, wer mag sich eines anderen Themas annehmen ?

Grüße Markus

PS: Wäre sicherlich auch nicht schlecht, wenn sich jemand in der rechtlichen Ecke umschauen würde. Wie weit dürfen wir gehen ? Code von Boop öffentlich zugänglich machen, etc...

Es heißt Boop, nicht Boob.

Zitat von: KölnSolar am 21 März 2017, 17:01:42
Steuerung von 433MHz-devices per Tastatur über FHEM

In lirc ist eine HX2262 Remote vorhanden, mit der so etwas schon möglich ist.

Zitat von: KölnSolar am 21 März 2017, 17:01:42
Sicherung von Datum/Uhrzeit bei Batterie leer/stromparender Betrieb/leistungsfähigere Hardware
(Betty hat die negative Angewohnheit, Datum und Uhrzeit bei Batteriewechsel zu vergessen)

Wenn beim Batterie einlegen eine zweite Betty mit eingestellter Uhr in der Nähe ist, wird die Uhrzeit über Funk automatisch übertragen.
Stomsparender wird es nur, wenn man das Display bei nichtbenutzung ausschaltet. Power Down Modus beim µC und WOR beim CC1100 ist schon vorhanden.

Zitat von: KölnSolar am 21 März 2017, 17:01:42
PS: Wäre sicherlich auch nicht schlecht, wenn sich jemand in der rechtlichen Ecke umschauen würde. Wie weit dürfen wir gehen ? Code von Boop öffentlich zugänglich machen, etc...

Ist doch schon öffentlich:
https://sourceforge.net/projects/boopfirmware/ (https://sourceforge.net/projects/boopfirmware/)

Zitat von: KölnSolar am 21 März 2017, 17:01:42

PS: Wäre sicherlich auch nicht schlecht, wenn sich jemand in der rechtlichen Ecke umschauen würde. Wie weit dürfen wir gehen ? Code von Boop öffentlich zugänglich machen, etc...

Gern geschehen :-)

Hast Du nur die Boop.bin? Laut dem alten Archive (http://web.archive.org/web/20080118235152/http://www.bettyhacks.com/wiki/index.php/Boop) ist Boop GPL3 und war soweit ich mich erinnere auch eher als Beispiel gedacht was alles für Funktionen in der Betty sind. Leider habe ich das Sourcepaket auch nicht mehr. Tzefix.
Aber das Netz vergisst angeblich nichts (es verlegt es nur oftmals irgendwo):https://sourceforge.net/projects/boopfirmware/?source=directory (https://sourceforge.net/projects/boopfirmware/?source=directory).

Jetzt habe ich noch ein Paket McBetty, da sind auch einige Sourcen drin. Das hänge ich hier mal dran. Auch GPL.

ZitatLeider habe ich das Sourcepaket auch nicht mehr

Hat Telekatz doch auch einen Post früher nochmal verlinkt. Die hab ich dann mit der hier im Thread beschriebenen Toolchain in "meine" .bin umgewandelt und geflashed.

ZitatPaket McBetty

..ist glaub ich irgendwas mit Musik oder so.

ZitatIn lirc ist eine HX2262 Remote vorhanden, mit der so etwas schon möglich ist.

Jo, die hatte ich schon gesehen  ;) Stammt ja wohl aus Deiner Feder. Die Idee, das über eine "lirc"-Schnittstelle zu handeln find ich auch recht pfiffig. Hatte dann erst gedacht, dass es daher ganz simpel ist IT V1 umzusetzen. Der HX2262 ist ja vergleichbar den ITs. Pulsweiten, Tristate etc. sind auch klar, aber die vielen anderen Parameter, für die lirc-Schnittstelle... :-[ Ich hab dann versucht die Codes auf IT anzupassen. Bin da aber nicht mit klar gekommen. Die Beschreibung predata 0x00000000 und (bits 0-4) und für Taste 1 dann 0x00551 (bits 5-11) haben mich etwas verwirrt. Für predata also 4bytes hex, um 5bits abzubilden und bei der Taste dann 5 nibbles für 7 bits(0FFFF0F), Gesamtlänge dann 13 nibbles 0x0000000000551 um 12 bit abzubilden  :-\ Hab da keine Systematik erkennen können und meinen 433CUL leider nicht da, der mich sicherlich erhellen würde. Ach ja und bei bits steht dann noch die 14  :-\

Es ist aber nur das Senden implementiert oder ?

ZitatWenn beim Batterie einlegen eine zweite Betty mit eingestellter Uhr in der Nähe ist, wird die Uhrzeit über Funk automatisch übertragen.

gut zu wissen.

Versuche jetzt noch weitr zu verstehen, wie der Programmablauf ist...

Zitat von: KölnSolar am 21 März 2017, 22:14:15
Jo, die hatte ich schon gesehen  ;) Stammt ja wohl aus Deiner Feder. Die Idee, das über eine "lirc"-Schnittstelle zu handeln find ich auch recht pfiffig. Hatte dann erst gedacht, dass es daher ganz simpel ist IT V1 umzusetzen. Der HX2262 ist ja vergleichbar den ITs. Pulsweiten, Tristate etc. sind auch klar, aber die vielen anderen Parameter, für die lirc-Schnittstelle... :-[ Ich hab dann versucht die Codes auf IT anzupassen. Bin da aber nicht mit klar gekommen. Die Beschreibung predata 0x00000000 und (bits 0-4) und für Taste 1 dann 0x00551 (bits 5-11) haben mich etwas verwirrt. Für predata also 4bytes hex, um 5bits abzubilden und bei der Taste dann 5 nibbles für 7 bits(0FFFF0F), Gesamtlänge dann 13 nibbles 0x0000000000551 um 12 bit abzubilden  :-\ Hab da keine Systematik erkennen können und meinen 433CUL leider nicht da, der mich sicherlich erhellen würde. Ach ja und bei bits steht dann noch die 14  :-\

Es ist aber nur das Senden implementiert oder ?

Predata ist 4 Bytes groß, weil es ja auch groß genug für andere Protokolle sein muss. Diese Größe ist auch bei LIRC dafür vorgesehen. Gesendet davon werden nur die ersten 10 Bit (/*pre_data_bits*/). Jedes der 5 tristate Bits (Bit 0-4) wird in jeweils zwei Bits übersetzt. Dasselbe gilt für die 7 folgenden tristate Bits. Diese werden in 14 Bits übersetzt (/*bits*/).
Und es ist nur Senden implementiert.

Anbei noch ein Diagramm mit der zeitlichen Abfolge der einzelnen LIRC Phasen.

ganz schön kompliziert  :o aber wohl notwendig wg. der LIRC-Kompatibilität. Dazu scheint mir dann noch die alte Inline-Doku falsch, so dass das Muster nicht erkennbar wird  :(

Aber ich hab jetzt die IT-Funktionalität für Protokoll V1 umgesetzt. Inline-Doku ist entsprechend verändert, so dass es jetzt einfacher möglich sein sollte, die Datei auf die individuellen Bedürfnisse anzupassen. Damit die alte Funktionalität nicht verloren geht, werde ich im nächsten Schritt die übergeordneten Files so verändern, dass die hx2262-Funktionalität erhalten bleibt und zusätzlich Intertechno mit einem separaten LIRC-file auswählbar wird. Für hx2262 werde ich dann die inline-Doku korrigieren(Taste 1-3 = on-Befehle, Taste 4-6 = off-Befehle).

Edit: Danke für die Grafik, macht die Parameter klarer  ;)
        Damit Ihr nicht lange suchen müsst: Die angehängte Datei müsst Ihr nach infared/ir_codes/lirc kopieren.
        Ach, auch noch wichtig: aufgrund der Konstruktion über LIRC lassen sich nur 8 IT-Codes nutzen. Die ersten 5 Stellen sind fix, also der
        Buchtstabe+das_erste_Bit_IT_Code der Dezimalzahl(bedeutet dann gerade oder ungerade) also z.B. nur C1, C3, C5, C7.....

Du kannst auch mehr als 8 IT-Codes benutzen, wenn die die ersten 5 Stellen von pre_data nach data verschiebst. Pre_data wird dann gar nicht benutzt. In data passen bis zu 32 Bits rein.

Ahh, danke. Das macht die Sache natürlich schöner und viiiiiel einfacher  ;) Anbei die Dateien, um nun IT mit allen 256 Codes u. HX2262 zu nutzen. Auswahl des Sets erfolgt über das Menü - Settings - RC Keys - gew. ABCD-Taste - remotes in LIRC - IT V1.
Datei codes.c muss in den Pfad infrared kopiert werden.

Kannst Du was zu B&O sagen ? LIRC-File gibt es ja mit raw_codes. Nur kann man die einbinden und wenn ja, wie ? In der ir_lirc.h hast Du Dich wohl schon mal versucht und im Bettyforum hast Du mal die Aussage getroffen, dass es gar nicht ginge  :-\ In IRMP scheint mir die Implementierung des Protokolls einfacher(zumindest übersichtlicher). Ob man das anders als die jetzige Implementierung in LIRC "übersetzt" bekommt ?

Meine Aussage bezog sich darauf, das mit der aktuellen IR Implementierung keine 455kHz Modulation der IR Diode erreicht werden kann. Die Modulation ist als Software PWM mit dem Timer1 implementiert. Für 455KHz ist das zu langsam.
Hardware PWM ist zwar möglich, die IR Diode hängt an PWM5. Dafür sind jedoch einige Änderungen am IR Code nötig.

Danke, dann kann ich mir erst einmal die Mühe sparen. Ich guck mir das mal an, um überhaupt mal den Unterschied zwischen software-PWM und Hardware-PWM zu verstehen  ;)

Hi Telekatz,
ich wollte mich jetzt mal zum Funk-Empfang vortasten. Unter Tools gibt es ja den FS20 Decoder. Der macht aber rein gar keinen Mux  :'( Ist die Funktionalität gar nicht gegeben ? Weißt Du ggfs. wo ich dran drehen müsste, um überhaupt etwas zu sehen ? Mir geht es da erst einmal gar nicht um die vollständige und richtige Protokollentschlüsselung, sondern nur ein wenig dem Programmablauf und den settings des CC1100 näher zu kommen.

Sowohl für den CC1101 im CUL, als auch dem CC1100 der Betty wird nach meinem Verständnis über SPI kommuniziert. Da müsste es doch "relativ" einfach sein, sich an den culfw-Sourcen zu "bedienen" oder bin ich da total auf dem Holzweg  :-\

Als µC-Developer-Dummy: Gibt es irgendein sinnvolles Tool, zum Debugging ? Zumindest so etwas, wo ich die einzelnen Funktionsaufrufe in Ihrer Sequenz verfolgen kann ?

@all: 1 download für die IT-Funktionalität ist arg wenig  :'( Mag denn neben der Unterstützung von telekatz niemand mitmachen ?

Zitat von: KölnSolar am 24 März 2017, 09:24:54
Hi Telekatz,
ich wollte mich jetzt mal zum Funk-Empfang vortasten. Unter Tools gibt es ja den FS20 Decoder. Der macht aber rein gar keinen Mux  :'( Ist die Funktionalität gar nicht gegeben ? Weißt Du ggfs. wo ich dran drehen müsste, um überhaupt etwas zu sehen ? Mir geht es da erst einmal gar nicht um die vollständige und richtige Protokollentschlüsselung, sondern nur ein wenig dem Programmablauf und den settings des CC1100 näher zu kommen.

Funktionieren sollte der schon. Aufgrund der Fehlanpassung der Antenne ist die Reichweite aber nicht groß.

Zitat von: KölnSolar am 24 März 2017, 09:24:54
Sowohl für den CC1101 im CUL, als auch dem CC1100 der Betty wird nach meinem Verständnis über SPI kommuniziert. Da müsste es doch "relativ" einfach sein, sich an den culfw-Sourcen zu "bedienen" oder bin ich da total auf dem Holzweg  :-\

Die Ansteuerung des CC1100 ist im Grunde gleich. Allerdings kann man die Registerwerte nicht 1:1 übernehmen, da die im CUL verwendeten CC1101 Module mit 26MHz Quarz bestückt sind, bei der Betty jedoch ein 27MHz Quarz verwendet wird. Das hat dann Auswirkungen auf alle frequenzabhängigen Register.

Zitat von: KölnSolar am 24 März 2017, 09:24:54
Als µC-Developer-Dummy: Gibt es irgendein sinnvolles Tool, zum Debugging ? Zumindest so etwas, wo ich die einzelnen Funktionsaufrufe in Ihrer Sequenz verfolgen kann ?

Zum Debuggen habe ich Eclipse und openOCD in Verbindung mit einem FTDI2232 basierten JTAG Interface genommen. Ich habe es jetzt auch mal mit einem J-Link versucht. Da funktioniert aber irgendwie die Programmierung des externen Flashs über CFI nicht.

Zitat von: KölnSolar am 24 März 2017, 09:24:54
@all: 1 download für die IT-Funktionalität ist arg wenig  :'( Mag denn neben der Unterstützung von telekatz niemand mitmachen ?

Das mangelnde Interesse war für mich dann auch irgendwann der Grund, die Entwicklung von Boop einzustellen.

Zitat von: KölnSolar am 21 März 2017, 17:01:42
....
Ohne Boop(wer hat nur diesen Namen erfunden  8))
....

Hier https://de.wikipedia.org/wiki/Betty_Boop die Erlaeuterung des Namens, aber die solltest Du doch eigentlich kennen!?

Interesse habe ich schon, insbesondere, da es ja sehr geringer finanzieller Aufwand ist! Aber helfen kann ich nur beim Testen, und eventuell was Schreiben! Momentan sehe ich allerdings noch nicht so ganz das Ziel, ich schlafe mal des WE drueber!

Gruss Christoph

ZitatFunktionieren sollte der schon. Aufgrund der Fehlanpassung der Antenne ist die Reichweite aber nicht groß.

Schon klar. Aber weder 3m, noch 50cm Abstand zum 868CUL bringen das Display in Bewegung, wenn ich einen FS20-Befehl aus FHEM absetze  >:( Ich sehe FS20 auch nur als Testcase.

ZitatDie Ansteuerung des CC1100 ist im Grunde gleich. Allerdings kann man die Registerwerte nicht 1:1 übernehmen, da die im CUL verwendeten CC1101 Module mit 26MHz Quarz bestückt sind, bei der Betty jedoch ein 27MHz Quarz verwendet wird. Das hat dann Auswirkungen auf alle frequenzabhängigen Register.

SUPER Info. Wenn ich etwas implementiert und getestet hätte, wäre ich im Leben nicht drauf gekommen, dass die Frequenzparameter anzupassen sind. Hatte beim vergleichenden Lesen schon Fehler in der FS20.c vermutet :-[

@Christoph: Danke für den Hinweis, den Wiki-Eintrag hatte ich tatsächlich noch nicht gesehen.
Ziel ? Uni-FB für TVs, Receiver UND IT-V1 habe ich ja nun schon. Die bei weitem nicht vollständigen Ideen hab ich ja hier https://forum.fhem.de/index.php/topic,69112.msg609209.html#msg609209 gepostet.

Moin KölnSolar,
Super Du gibst richtig Gas cool! Naja diese Woche war ja erstmal Cebit gelle, aber nächstes Jahr hat man ja 3 Monate mehr Zeit bis zu der ;-) Aber ich schaue mir die Hardware am WE mal an...
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

Ich habe in den Tiefen meiner Platte noch ein Paket namens Lernbetty gefunden. Das gibts auch noch online: https://www.mikrocontroller.net/topic/277603 (https://www.mikrocontroller.net/topic/277603). Da sind einige interessante Beispiele drin.

Hi Telekatz,
hab jetzt auch mal die 2. FB in Betrieb genommen. Das Synchronisieren der Zeit hat gut geklappt.
Leider tut sich auch dort nichts beim FS20-Empfang. Hatte gehofft, dass das evtl. an der FB liegt  :(

Da ich dort nicht weiterkam, hab ich mich dann doch wider dem B&O-Protokoll gewidmet. Ich hab ein LIRC-File erstellt, welches passen sollte. Wie Du schon sagtest: klappt nicht. Man kriegt wohl scheinbar max. ca. 100kHz hin. Warum ist mir leider immer noch nicht klar. Ich hab zwar einiges investiert, um den Programmablauf zu verstehen, insbesondere die Timersteuerung und die Interrupts, aber das ist echt müüüühselig. Irgendwie fehlt mir da noch der Zusammenhang zwischen key_press, lirc_send, RunIR, welches den timer1 startet und dann ? Wird dann die FIQ_Routine getriggered, die dann den infraredirq aufruft, die wiederum die LIRC_Encode aufruft ?

Im Augenblick hänge ich an hi_ u. lo_border, die ja durch den Parameter duty_cycle im LIRC-file gesetzt werden. Daran hängt ja wiederum der Wert für das match register T1MR0. Kannst Du mir vielleicht in wenigen Worten beschreiben, was die 3 Parameter bedeuten/bewirken ?
Außerdem hab ich noch nicht so ganz verstanden, warum der Timer1 nicht in der VIC eingetragen wird. Heißt das nicht, dass die VICs alle eine höhere Priorität haben ? Hintergrund der Frage ist, dass ich auch ohne Umbau auf PWM gerne testen würde, ob das senden grundsätzlich funktioniert, also erst einmal alles entfernen würde, was Zeit kostet bzw. behindert oder vorhandenes beschleunigen würde. Dann hätte ich auch den kompletten Ablauf verstanden. Danach würd ich mich dann an den Umbau auf PWM geben. Ist dieser Gedanke machbar oder einfach nur Blödsinn eines µC-Dummies ?
Grüße Markus

Die IR Encoder sind alle so aufgebaut, dass sie folgende Funktionen bereitstellen:
xx_Encode
xx_Init
xx_Send
xx_Repeate
xx_Stop

xx_Init wird aufgerufen, wenn der Fernbedienungscode gewechselt wird und initialisiert den Encoder
xx_Send wird aufgerufen, nachdem eine Taste gedrückt wird und läd dann z.B. den Encoder mit dem entsprechenden Code für diese Taste.
xx_Repeate wird periodisch aufgerufen, solange die Taste gedrückt wird.
xx_Stop wird aufgerufen, wenn die Taste losgelassen wird.

In xx_Send oder xx_Repeat wir mit runIR der Timer1 Interrupt aktiviert.

T1MR0 ist das Timer Counter 1 Match Register. Erreicht Timer1 diesen Wert, wird der Interrupt ausgelöst. Bei jedem Interrupt wird die Variable c_cnt hochgezählt. Solange c_cnt kleiner hi_boarder ist, bleibt die IR Diode eingeschaltet falls ein Träger erzeugt werden soll. Danach bleibt die IR Diode ausgeschaltet bis c_cnt gleich lo_border ist. Dann ist eine Periode vorbei und c_cnt wird wieder auf 0 gesetzt.

Die Frequenz des Trägers kann man ausrechnen mit: f_Träger =  PCLK / (tval * lo_border)
Am Beispiel von RC5: f_Träger = 15MHz / (139 * 3) = 35,97kHz

Für die duty_cycle gilt: duty_cycle = hi_border / lo_border
Am Beispiel von RC5: duty_cycle = 1 / 3 = 33,3%

Die Anzahl der Perioden wird in b_len gezählt. Über die Variable cycles wird vorgegeben, wieviele Perioden und damit wie lange ein Signal gesendet werden soll. Ist die gewünschte Anzahl an Perioden erreicht, wird in xx_Encode die Anzahl der Perioden für das nächste Signal und ob der Träger gesendet werden soll ermittelt.

Für das Verständnis der IR Funktion würde ich empfehlen, mit einem einfacheren Encoder wie RC5 anzufangen. Der Ablauf ist bei allen IR Encodern gleich.

Der Timer1 Interrupt steht nicht im VIC, weil er im FIQ behandelt wird. Der hat schon die höchste Priorität.

Danke für Deine Mühe. Jetzt fehlt mir nur noch die Stelle, wo die FIQ_Adresse gesetzt wird. spielt aber keine Rolle, wird schon irgendwo gesetzt werden  :)
Mit Deiner Formel müsste ich bei lo_border = 3 tval = 11 setzen und hätte 454545 Hz. Das ist doch bestimmt zu einfach gedacht, oder ?
Duty cycle ist ja eigentlich das Verhältnis des Pulses zum Space. Der liegt bei einem 0-bit bei ca. 2% und beim pre-bit sogar bei nur 1,3%. Also eher tval =1 und lo_border =33, also duty cycle 3% ?
Ich probiers mal aus...

Zitat von: KölnSolar am 29 März 2017, 22:08:07
Duty cycle ist ja eigentlich das Verhältnis des Pulses zum Space. Der liegt bei einem 0-bit bei ca. 2% und beim pre-bit sogar bei nur 1,3%. Also eher tval =1 und lo_border =33, also duty cycle 3% ?

Nein, duty_cycle hat nichts mit dem Verhältnis Pulse zu Space zu tun. Duty_cycle betrifft den Träger während des Pulses.

Hmm, Träger während des Pulses  :-\ bitte für dummies...

Beide Tests fehlgeschlagen  :'( Hab auch mal probiert die Taktrate auf 60/30 höher zu setzen. War aber auch nix  :'(  Betty starb  :'(

Ich häng mal das LIRC-file dran. Passend hab ich die code.c erweitert, eine Anpassung in der LIRC_Init für hi_ u. lo_border, sowie in der LIRC_Encode bei LIRC_DATA_S eine Anpassung, weil nicht einfach 0 u. 1 gesendet wird, sondern, wenn sich der bit-wert gegenüber dem vorhergehenden nicht ändert, eine besondere Space-Pulsweite zu berücksichtigen ist.

Any ideas ? Was hab ich überfordert, dass die Betty den Geist aufgibt ?
Edit: Einen Fehler in meinem zusätzlichen Code oder des LIRC-Files kann ich insofern ausschließen, dass ich die Betty am Leben erhalte, wenn ich die Frequenz im LIRC-File deutlich absenke(um die 100kHz). Es ist also irgendein "Timing"-Problem.
Zum Aufbau des IR-Protokolls: Die B&O hat immer einen Sendepuls von 200, der Spacepuls variiert. Es werden 4 unterschiedliche Startbits gesendet. Die hab ich im header(1.), pre_data(2.), pre(3.) u. das letzte neben den Daten in bits. Nach den 17 Datenbits(16 + 4. start bit) kommt dann noch ein post_bit und ein abschließender Puls als ptrail.

Zitat von: KölnSolar am 29 März 2017, 23:37:06
Hmm, Träger während des Pulses  :-\ bitte für dummies...

Du sendest einen Puls mit 200 µs Länge gefolgt von einem Space variabler Länge. Während des Pulses ist die IR Diode jedoch nicht ständig an sondern wird mit 455kHz moduliert (der Trägerfrequenz). Der 200 µs Puls besteht nicht aus einem langen Puls, sondern aus 91 kurzen Pulsen. Und das Verhältnis aus IR Dioden an und aus während dieser 200 µs ist die duty_cycle.

Zitat von: KölnSolar am 29 März 2017, 23:37:06
Edit: Einen Fehler in meinem zusätzlichen Code oder des LIRC-Files kann ich insofern ausschließen, dass ich die Betty am Leben erhalte, wenn ich die Frequenz im LIRC-File deutlich absenke(um die 100kHz). Es ist also irgendein "Timing"-Problem.

Du kannst jetzt noch im lirc File duty cycle auf 50 stellen, dann könntest du um die 150kHz schaffen. Mehr geht nicht mit Software PWM so wie es jetzt im Timer1 Interrupt implementiert ist.

ich beginne mehr zu verstehen ...
Ist es nur eine Schätzung aufgrund von Erfahrungswerten, dass nicht mehr als 150kHz drin sind oder lässt sich das irgendwie (einfach)berechnen/abschätzen ?

Hab mich jetzt mit PWM weiter auseinandergesetzt und könnte mich an den Einbau wagen. Sieht ja erstmal gar nicht so schlimm aus  :D Als Basis nähme ich den PWM aus der Soundsteuerung, natürlich angepasst für channel 5. Da es ja nur einen Counter für alle PWM channels gibt: siehst Du später ein Problem darin, dass sound und IR PWM-gesteuert werden ? Auch, wenn ich jetzt den Anwendungsfall nicht sehe, die könnten sich ja in die Quere kommen ? Fängt ja schon mit dem prescaler an, der für sound auf 7 gesetzt wurde. Grund ? Gibt es Performance- oder sonstige Gründe den Prescaler zu setzen oder aber eher nicht setzen ? Was würdest Du mit Deiner Erfahrung mit dem Prescaler für IR und speziell dem B&O-Protokoll treiben ? Auf die minimalste Pulslänge setzen ?

Des weiteren dachte ich mir, ich beschreibe das PWMMR5 immer mit der nächsten Pulslänge oder wäre hier ähnlich wie beim timer ein "Basis-puls" besser und die Programmlogik kümmert sich um die Pulslängen ?

Muss ich mich mit double-edge auseinandersetzen oder kann ich mir das sparen ?

Und schließlich verwirrt mich die Doku(ich nutze UM10114) etwas. Es wird eingangs zum PWM beschrieben, man könne high, low, oder toggle beim match setzen. Nur: Ich finde kein(e) Register, wo ich genau diesen Willen kundtun könnte  :o Muss man also für jede P/S-Kombination PWMMMR0 auf P+S setzen und PWMMR5 auf S ?

Freu mich wie immer über Deine Hilfe...

Zitat von: KölnSolar am 31 März 2017, 08:21:38
ich beginne mehr zu verstehen ...
Ist es nur eine Schätzung aufgrund von Erfahrungswerten, dass nicht mehr als 150kHz drin sind oder lässt sich das irgendwie (einfach)berechnen/abschätzen ?

Das ist eine Schätzung aufgrund deiner LIRC Konfiguration, bei der 100kHz als maximale Frequenz ermittelt hattest.

Zitat von: KölnSolar am 31 März 2017, 08:21:38
Hab mich jetzt mit PWM weiter auseinandergesetzt und könnte mich an den Einbau wagen. Sieht ja erstmal gar nicht so schlimm aus  :D Als Basis nähme ich den PWM aus der Soundsteuerung, natürlich angepasst für channel 5. Da es ja nur einen Counter für alle PWM channels gibt: siehst Du später ein Problem darin, dass sound und IR PWM-gesteuert werden ? Auch, wenn ich jetzt den Anwendungsfall nicht sehe, die könnten sich ja in die Quere kommen ? Fängt ja schon mit dem prescaler an, der für sound auf 7 gesetzt wurde. Grund ? Gibt es Performance- oder sonstige Gründe den Prescaler zu setzen oder aber eher nicht setzen ? Was würdest Du mit Deiner Erfahrung mit dem Prescaler für IR und speziell dem B&O-Protokoll treiben ? Auf die minimalste Pulslänge setzen ?

Sound und IR wird nicht gleichzeitig funktionieren.
PWMR0 muss passend zur PWM Auflösung gewählt werden. Zusammen mit Prescaler muss das dann die gewünschte Frequenz ergeben. Beim Sound PWM sind das dann etwa 4,4kHz.
Für IR wirst du keinen Prescaler benötigen um auf 455kHZ zu kommen. Eingestellt werden die 455kHz über PWMR0 (müsste dann 33 sein)

Zitat von: KölnSolar am 31 März 2017, 08:21:38
Des weiteren dachte ich mir, ich beschreibe das PWMMR5 immer mit der nächsten Pulslänge oder wäre hier ähnlich wie beim timer ein "Basis-puls" besser und die Programmlogik kümmert sich um die Pulslängen ?

Muss ich mich mit double-edge auseinandersetzen oder kann ich mir das sparen ?

Und schließlich verwirrt mich die Doku(ich nutze UM10114) etwas. Es wird eingangs zum PWM beschrieben, man könne high, low, oder toggle beim match setzen. Nur: Ich finde kein(e) Register, wo ich genau diesen Willen kundtun könnte  :o Muss man also für jede P/S-Kombination PWMMMR0 auf P+S setzen und PWMMR5 auf S ?

Über PWMMR5 wird die duty cycle der Trägerfrequenz eingestellt. Für die Puls und Pausenlängen des IR Signals ist ist weiterhin Timer1 zuständig. Nur muss hier der Timer1 Interrupt nicht mehr so oft aufgerufen werden. PWM kümmert sich nur um die Trägerfrequenz und benötigt dazu auch keinen Interrupt.

jaja, die Trägerfrequenz. Die hatte ich in meinem Post völlig vergessen, was mir dann bei der Umsetzung klar geworden war.  :o

ZitatÜber PWMMR5 wird die duty cycle der Trägerfrequenz eingestellt.

ist mir also soweit klar. Aber warum brauche ich noch den timer 1? Bei den Spaces muss ich doch sowieso den pin abschalten und beim nächsten pulse die Trägerfrequenz wieder auf die LED schalten, oder nicht ?

Die richtigen Probleme, die ich hab, sind aber andere  :'( Der ersten Betty hab ich wohl die Diode zerstört  :'( :'(  Damit nicht genug. Bis ich mal auf die Idee kam, dass PINSEL1 gesetzt werden muss  ::) Danach blinkte die Diode, aber irgendwie ist alles durcheinander. Sie blinkt rythmisch endlos weiter, trotz coding für stopIR  :o Fehlt der Aufruf ? Aber das ist nicht alles  >:( Die Hintergrundbeleuchtung spinnt auch. Die wird aber doch über timer0 gesteuert oder etwa nicht ? Wieso funktioniert der nicht mehr richtig, obwohl die Register zwischen timer und PWM doch unterschiedlich sind ?

Testen tu ich über das LIRC-Samsung-Protokoll, was mit timer1 ja einwandfrei funktioniert. Erst, wenn das über PWM funktioniert, versuche ch mich an den 455kHz.

Jetzt nehm ich mal den  sound raus und gucke, ob die Geister sich beruhigen....

Edit: der Sound war es nicht. Ich hatte nach dem Senden den PWMTCR nicht richtig zurückgesetzt  :-[ Backlight bleibt aber immer noch aus  :-\
Und jetzt kann ich das erste mal das Senden beobachten. Gefühlt bleibt die Diode viel zu lange an  >:(

So, neue Diode angelötet. Geht selbst für mich Löt-Dummy relativ problemlos. Die 2. Betty ist also wieder geheilt.

Um die Probleme mit der Hintergrundbeleuchtung und dem Sound abzustellen, habe ich das Ganze etwas entgegen der üblichen Ablaufstruktur nun direkt in den LIRC_Send bzw. LIRC_Stop eingebaut. irIRQ und FIQ_Routine passend umgebaut, den timer1 nicht gestartet(kein runIR())

Der Output der Diode sieht "richtiger" aus, schaltet aber leider nicht auf 38kHz  :'(

Bei 433kHz scheint ebenfalls der Erfolg auszubleiben. Die Diode kommt nicht zur Ruhe  :o

So sieht der Code in LIRC_Send aus: PWMTCR = 0x00;
PINSEL1 |=  (1 << (2 * (IR_PWM - 16))); // Pin function PWM5
PWMPCR  |=  (1 << 13); // enable output f. pwm5
PWMTC  = 0;
PWMPC  = 0;
PWMPR  = 0; //precale register initialize
PWMMCR = 0x03; //match MR0: reset counter and interrupt; no further action
PWMMR2 = 0;
PWMMR0 = T1MR0;
PWMMR5 = PWMMR0 / lo_border * hi_border; // high cycles for carrier frequence
PWMLER = 0x25;
PWMTCR = 0x0b;
PWMTCR &= (0<<1);


das on-off-keying passiert dann am Ende der LIRC_Encode mit
if(mod_enable) PWMPCR |= (1<<13);
else  PWMPCR &= ~(1<<13);


Da ich ja auch C-Amateur bin verstehe ich auch nicht warum PWMTCR = 0x09;
nach   PWMTCR = 0x0b; funktioniert,    PWMTCR   &= (0<<1);  aber nicht  :-\ Mache ich da generell beim setzen u. löschen von Bits etwas falsch ?

Zitat von: KölnSolar am 24 März 2017, 09:24:54@all: 1 download für die IT-Funktionalität ist arg wenig  :'( Mag denn neben der Unterstützung von telekatz niemand mitmachen ?

Meinerseits gibt es dafür zwei Gründe:
1. habe ich den Thread erst heute gefunden
2. wäre ich euch keine Hilfe
Aber ich habe den Thread aboniert und bin schonmal extrem gespannt!

Du brauchst weiterhin den Timer1, um die Puls und Pausen Zeiten auszugeben. LIRC_Encode wird sonst nicht aufgerufen. T1MR0 wird dann auf die entsprechenden Zeiten geladen.

PWMMR0 = T1MR0;
PWMMR0 muss auf die Trägerfrequenz eingestellt werden. T1MR0 ist dabei nicht der korrekte Wert. Der korrekte Wert ergibt sich aus 15MHz/Trägerfrequenz.

Zitat von: KölnSolar am 06 April 2017, 09:32:34
Da ich ja auch C-Amateur bin verstehe ich auch nicht warum PWMTCR = 0x09;
nach   PWMTCR = 0x0b; funktioniert,    PWMTCR   &= (0<<1);  aber nicht  :-\ Mache ich da generell beim setzen u. löschen von Bits etwas falsch ?

Eine 0 zu shiften bringt nicht, das Ergebnis ist immer 0. Und ein AND mit 0 ist auch immer 0.

Korrekterweise schiebt man eine 1 an die richtige Stelle, invertiert alle Bits und verknüpft dann mit AND:
PWMTCR &= ~(1<<1)

   

ZitatUnd ein AND mit 0 ist auch immer 0.

Das war ja auch beabsichtigt. Funktioniert aber nicht, während die von Dir gepostete Syntax bestens funktioniert.  ;)
Durch Deine Beharrlichkeit mit timer1 hab ich dann noch einen Fehler gefunden. Ich hatte beim Umbau nach LIRC_Send einen Fehler gemacht. Es muss natürlich heißen
PWMMR0 = T1MR0 * lo_border;
PWMMR5 = T1MR0 * hi_border;
Und dann funktioniert das Samsung-Protokoll  :-* Bis hierhin viel gelernt über Boop, Betty, C....aber das war ja nicht das Ziel. Nur leider funktioniert so das B&O immer noch nicht. 155kHz laufen durch, 205kHz aber schon nicht mehr  :'(

Und bevor ich das poste und mir den Rüffel einhandele, dass ich ja den IRQ beim PWM rausnehmen und den timer1 wieder benutzen soll, habe ich dies gemacht. Im "Standard" keine Veränderung  :( Aber Ziel ist ja auch den IRQ seltener auslösen zu lassen. Das hat mir aber mal wieder enorme Schwierigkeiten bereitet  :'( Ich hatte timer1 auf 20 Zyklen gesetzt, was in keiner Konstellation funktionierte  :'( Bis ich auf den Gedanken kam es einfach mal nur mit 2 Zyklen zu probieren. Kein Fehler ! Weiter getestet mit 5, dann mit 10. Ab 10 ging wieder nichts mehr. Gibt's eine Erklärung dafür, dass man den timer nicht höher setzen kann ?
Mittlerweile hab ich mir dann die genauen Zeitenberechnungen angesehen und bestmöglich auf das B&O-Protokoll eingestellt: Frequenz im Lirc-File auf 450000, damit auch 33 Zyklen errechnet werden. Den timer1 auf den Faktor 4(Interrupt nach 132 Zyklen) eingestellt, so dass eine Abweichung der Pulsdauern von ca. 1% entsteht. Samsung funktioniert so einwandfrei. Aber leider geht bei der B&O nix. Mir gehen jetzt die Ideen aus, was ich noch verändern könnte  :'( Ob es an der Diode liegt ? zu schwach, falsche Wellenlänge, doch noch Fehler im Protokoll ......

Da ich da nicht weiterkomme hab ich mir mal Gedanken über die weiteren Teile gemacht, also Scart- u. TAE-Adapter.  Den Scart müsste man doch fast als Betty-CUL mit eingeschränkter Funktionalität(nur 8kB flash) umbauen können... Im ersten Schritt scheitert es natürlich mal wieder an der Toolchain  :(  wird ich wohl mal den SDCC installieren...

Möchte auch nur kurz Interesse bekunden, auch wenn ich inhaltlich eher Bahnhof und Abfahrt verstehe, aber ich habe wieder Hoffnung, meine in einem Moment des Enthusiasmus gekauften Bettys doch noch in Verbindung mit FHEM nutzen zu können  8)

Wenn's da was brauchbares gibt, wäre ich über einen Wiki-Eintrag sehr dankbar, bin kein Programmierer  :D

Na wenigstens mal wieder einer, der die verstaubten Bettys nutzen möchte.  ;)

Wiki ? Die Zeit hab ich nicht auch noch  :( Hier im Thread steckt ja schon ne Menge Info drin: Link aufs Betty-Wiki, Nutzung als Uni-FB für IT-Schalter, womit wir natürlich bei der derzeit funktionierenden Nutzung wären: Uni-FB für IR und IT. Funktioniert bei mir prima !

Ziel sind für mich die Einbindung meiner B&O(IR-Frequenz 455kHz und aktuell auf Eis, weil ich nicht weiterkam) und die Anbindung an FHEM über die aculfw.

Letzteres ist dann meine laufende Arbeit. Ich versuche, vergleichbar der aculfw@ARM, die aculfw(erster Schritt IT senden) zu integrieren. Aufgrund der deutlich geringeren Peripherie dachte ich erst ich versuchs mit dem Scart-Adapter. Das hab ich aber schnell aufgegeben, weil ich keine Debuggingmöglichkeit habe und auch der Flashprozess umständlicher ist. Für die Betty ist es auch recht zäh, weil ich zig neue Themen auf einmal habe: Toolchain(make/makefile/includes), AVR-/ATMega-Prozessoren, aculfw/culfw, CC1100/CC1101, Betty....

Ich hab dabei verschiedene Ansätze verfolgt und immer wieder erfolglos verworfen  >:(

Anders als Telekatz für die aculfw@ARM möchte ich dabei in geringerem Umfang in die Sourcen der aculfw eingreifen. Ich habe die Hoffnung, dass ich das Ganze über Pointer auf die AVR-Register gestalten kann :-\

Im Augenblick scheitere ich aber immer noch an einem fehlerfreien Compile  :'(

Zitat von: szoller am 27 April 2017, 11:44:44
Wenn's da was brauchbares gibt, wäre ich über einen Wiki-Eintrag sehr dankbar, bin kein Programmierer  :D

Moin
Einen Wiki-Eintrag kann man auch als Nichtprogrammierer schreiben.
Ich habe mich auch schon mal fuer eine Modulbeschreibung geopfert, hat gar nicht weh getan! Und hilft auch immens beim Verstaendnis!
Gruss Christoph

Ja, ist mir schon klar, allerdings sollte man dazu die Thematik selbst auch verstehen.

Mein konkretes Problem ist die Flut an Informationen in diesem Thema, weiß gar nicht wo ich anfangen soll  ;D

Brauch ich jetzt zB. Boop oder muss ich doch was anderes flashen... da fängts bei mir schon an ;-)

ZitatBrauch ich jetzt zB. Boop oder muss ich doch was anderes flashen...

Na das ist (fast) einfach  ;D
BBoooopppp

In den ersten Posts sind beschrieben: Flashhardware, Betty-Heaven(flashsoftware unter Win), Lokation des Boop-Sourcecodes, Toolchain f. Compile.

und zu meinen Problemen: versteht jemand, warum der Precompiler die simplen Makros nicht mag error: expected expression before ')' token
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))

Verwendung:    SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   
sollte eigentlich dann das:   CC1100_CS_DDR |= (1<<CC1100_CS_PIN)
ergeben.

Mit avr-gcc und makefiles der aculfw klappt das problemlos. Irgendeine Option ins makefile ? Nur welche ?

Versuche ich mich im Vergleich dem Problem anzunähern, scheitere ich beim make einer CUL_433 bereits daran, dass die option -mmcu=... abgewiesen wird. Geht arm-none-eabi-gcc also eben nur für arm-Prozessoren und nicht avr, oder ?

Zitat von: KölnSolar am 28 April 2017, 10:53:44
Versuche ich mich im Vergleich dem Problem anzunähern, scheitere ich beim make einer CUL_433 bereits daran, dass die option -mmcu=... abgewiesen wird. Geht arm-none-eabi-gcc also eben nur für arm-Prozessoren und nicht avr, oder ?

Das sagt doch der Name arm-none-eabi-gcc schon aus, dass das für ARM ist. AVR ist nicht ARM.

Die Antwort hatte ich ja fast erwartet  ;) Hätte ja sein können, dass die Toolchain beide kann, schade  :(

Auch noch ne Idee zu den Makros ? Wird das generell im arm-none-eabi-gcc nicht unterstützt ? Bliebe ja noch die Möglichkeit eine Funktion für zu bauen.

Poste mal etwas mehr vom Code. Das was davor und danach kommt. Und auch etwas mehr von der Compilerausgabe beim Fehler.

mehr ist es leider nicht  :( das define des makros und dann die Fehlermeldung des Precompilers. Davor und danach ist unerheblich. Hab die Makros schon an x verschiedenen Stellen eingebaut.
Ok, hab gerade noch gesehen, dass beim cut&paste der Unterstrich nicht transportiert wurde, welche ")" der Precompiler meint. Es ist die hinter dem ersten PORT.
Der Meldung folgend hab ich dann mal getan, was der Precompiler will und einfach PORT+1 in die Klammer geschrieben, Dann lautet die Meldung:
error: lvalue required as left operand of assignment. Markiert ist dann nicht die Klammer sondern das "|" vom "|=". Deshalb gehe ich ja davon aus, dass der Compiler entweder ein generelles Problem mit solchen Makros hat oder er aber (hoffentlich) mit einer option zu überlisten ist. Nur wo könnte man das nachlesen  :-[

Der Compiler hat kein Problem mit solchen Makros. Das Problem sitzt so gut wie immer vor der Tastatur und tippt darauf herum.
Ist CC1100_CS_DDR und CC1100_CS_PIN überhaupt definiert?

wie gerne würde ich Dir zustimmen, aber
#define CC1100_CS_port      1
#define CC1100_CS_PIN 2
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_port, CC1100_CS_PIN ); 
  CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
} // main
sollte dann funktionieren und nicht
main.c: In function 'main':
main.c:3:39: error: lvalue required as left operand of assignment
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
                                       ^
main.c:8:3: note: in expansion of macro 'SET_BIT'
   SET_BIT( CC1100_CS_port, CC1100_CS_PIN );
   ^~~~~~~
main.c:4:41: error: lvalue required as left operand of assignment
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
                                         ^
main.c:9:3: note: in expansion of macro 'CLEAR_BIT'
   CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
   ^~~~~~~~~
Makefile:129: recipe for target 'main.o' failed
make: *** [main.o] Error 1

ergeben, oder ?
edit: und so
#include <avr/iom32u4.h>

#define CC1100_CS_DDR DDRB
#define CC1100_CS_PIN PB3

#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN ); 
  CLEAR_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
} // main
kommt dann wieder
In file included from main.c:1:0:
./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."
    ^~~~~
main.c: In function 'main':
main.c:6:37: error: expected expression before ')' token
#define SET_BIT(PORT, BITNUM) ((PORT) |= (1<<(BITNUM)))
                                     ^
main.c:11:3: note: in expansion of macro 'SET_BIT'
   SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   ^~~~~~~
main.c:7:39: error: expected expression before ')' token
#define CLEAR_BIT(PORT, BITNUM) ((PORT) &= ~(1<<(BITNUM)))
                                       ^
main.c:12:3: note: in expansion of macro 'CLEAR_BIT'
   CLEAR_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
   ^~~~~~~~~
Makefile:129: recipe for target 'main.o' failed
make: *** [main.o] Error 1
:'(

Das liegt daran, das CC1100_CS_port eine Konstante ist und dieser kann der Compiler keinen Wert zuweisen. Du musst im Macro auf eine Adresse casten.


#define CC1100_CS_port      1
#define CC1100_CS_PIN 2

#define SET_BIT(PORT, BITNUM) (*(char*)(PORT) |= (1<<(BITNUM)))
#define CLEAR_BIT(PORT, BITNUM) (*(char*)(PORT) &= ~(1<<(BITNUM)))

int main(void)
{
  SET_BIT( CC1100_CS_port, CC1100_CS_PIN );
  CLEAR_BIT( CC1100_CS_port, CC1100_CS_PIN );
  return 0;
}


So geht es zum Beispiel. Du musst char* entsprechend der Addressbreite noch austauschen.

Besser wäre es bereits mit dem define für CC1100_CS_port einen Pointer zu definieren.

Und mach erst mal das, was der Compiler sagt:
./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."

@papa: ok, glaube ich Dir jetzt mal so. Entscheidend ist aber der 2. Test.
edit: neugierig hab ich es ausprobiert. Stimmt. Aber leider ist das 2. Bsp. das Entscheidende  :( :(

@telekatz: ist ja einfach nur ein Extrakt aus der culfw. avr-gcc kanns, arm-none-eabi-gcc nicht. Und ich will ja gerade nichts an der culfw ändern, sonst hätt ich mir schon längst anders beholfen. Nicht vielleicht doch ne einfache option ?
edit:

ZitatUnd mach erst mal das, was der Compiler sagt:
Code: [Auswählen]
./avr/iom32u4.h:39:4: error: #error "Include <avr/io.h> instead of this file."
#  error "Include <avr/io.h> instead of this file."

Prinzipiell schon klar hat aber mit dem Beispiel nix zu tun(und arm-none-eabi-gcc  kann ja kein -mmcu=atmega32u4, was der Grund für die Fehlermeldung istweshalb ein include io.h nicht funktioniert)

DDRB ist in iom32u4.h so definiert:

#define DDRB _SFR_IO8(0x04)

Da macht der Präprozessor dann daraus:

int main(void)
{
  ((_SFR_IO8(0x04)) |= (1<<(2)));
  ((_SFR_IO8(0x04)) &= ~(1<<(2)));
  return 0;
}


Da du das File, in dem das AVR Makro _SFR_IO8 definiert ist nicht inkludierst, wird es nicht aufgelöst und der Compiler sagt dir, dass in der linken Klammer Unsinn steht.

Und deshalb sitzt das Problem vor der Tastatur.

DAS klingt schlüssig. Muss ich suchen, ob das noch in der culfw steckt....

es war es (fast). Fast deshalb, weil ich es sogar aus meiner iom32u4.h rausgenommen hatte, als ich noch kein Verständnis für Makros hatte  :-[

Danke, da wär ich im Leben nicht drauf gekommen. Die Fehlermeldung ist auch nicht wirklich umfangreich...

Nun muss ich die geglaubt behoben zu habenden Fehler wieder suchen...

fast bin ich durch. Der Linker meckert
../../clib/ttydata.o: In function `callfn':
ttydata.c:(.text+0x74): undefined reference to `fntab'
code(aculfw)
typedef struct _fntab {
  unsigned char name;
  void (* const fn)(char *);
} t_fntab;

#define __LPM(addr)         *(addr)
#define __LPM_word(addr)    *(addr)

extern const PROGMEM t_fntab fntab[];
uint8_t
callfn(char *buf)
{
  for(uint8_t idx = 0; ; idx++) {
    uint8_t n = __LPM(&fntab[idx].name);
    void (*fn)(char *) = (void (*)(char *))__LPM_word(&fntab[idx].fn);


fntab ist aber doch gar keine function und definiert sollte doch auch alles sein. Ich seh nur Sterne...
Liegts am avr PROGMEM ?

Du hast fntab mit dem Schlüsselwort extern hier nur deklariert. Dadurch weiß der Compiler, dass es diese Variable irgendwo geben wird und meckert nicht.
Wenn fntab aber nirgendwo im Code definiert wird, meckert der Linker, weil er die Variable nicht findet. 

Danke, da hätt ich aber mal selber drauf kommen können  :-[

Ich muss hier doch mal ne Anfängerfrage stellen...  :(

Ich flashe nun zum ersten Mal etwas über ein serielles Interface, habe mir da auch schon die Beschaltungen rausgesucht (Servicestecker) und habe insgesamt vier Adern miteinander verbunden

Adapter - Betty
TX - TX
RX - RX
GND - GND
VCC - 3V

Betty-Heaven meldet immer RX Timeout, Synchronisation gescheitert...
Die andren Bezeichnungen am Adapter (hat 6 Pole) kann ich denen der Betty nicht zuordnen (DTR und CTS)

Ich glaube, den Bootloader hab ich aktiviert eINT mit GND gebrückt, dann dazu noch Reset, die Betty startet neu und Display ist zumindest aus.

Habe nun in einem andren Artikel gelesen, dass TX - RX und RX - TX zugeordnet werden müsse, dann sagt Betty Heaven "Starte Backup" und nix passiert mehr...

Was mach ich falsch?


Und achja... hat jemand noch die kompilierte Firmware?

Du musst Rx und Tx kreuzen.

ZitatIch glaube, den Bootloader hab ich aktiviert eINT mit GND gebrückt, dann dazu noch Reset, die Betty startet neu und Display ist zumindest aus.

so soll es sein. Reset dann wieder lösen(ich löse danach auch eINT u. nach dem flashen eine kurze Verbindung Reset-GND z. Restart)

ZitatUnd achja... hat jemand noch die kompilierte Firmware?

Liegt im Trunk. ich hab sie aber mal angehangen

Danke! Was muss ich außer RX und TX denn noch zwingend anschließen?

wie Du schriebst: GND U. VCC.

Ich danke dir, werds erneut probieren  :)

Ich glaub ich bin zu doof dafür... habs via Restore geflasht, nun reagiert die Betty nicht mehr auf Tasten (auch Menu nicht), einzige Reaktion ist, dass die Displaybeleuchtung angeht, wenn ich sie bewege...

Das Betty-Bild mit der Angabe 0.91 sehe ich, da hörts aber auch auf  ::)

Nachtrag:
Die Beleuchtung scheint doch von einem Tastendruck abhängig zu sein, ist aber scheinbar total zufällig, manchmal gehts Licht an, wenn ich die 5 drücke, manchmal reagierts nicht, dafür bei der 8, 1 oder AV-Taste...

Ich hab die vorkompilierte Version ja nie geflasht. Bei der selbst kompilierten Version geht die Beleuchtung nur im Betty-Menü oder bei Auswahl eines IR-Encoders mittels der A-B-C-D-Tasten.
Was das Reaktionsvermögen anbelangt: Dass die Betty läuft, siehst Du an der Uhrzeit rechts unten und der Tastendruck äußert sich durch ein kurzes Anzeigen eines kleinen IR-Symbols links neben der Batterieanzeige  ;)

Telekatz, ich bräuchte mal wieder Deine Hilfe. Mittlerweile habe ich den compile mit viel Gewürge mit der culfw hinbekommen. Beim Test bin ich dann aber erst einmal wieder bei meinem alten B&O-Problem angelangt.

Ich habe etwas aufgeräumt und in der Variante mit PWM für die Trägerfrequenz und dem timer1 fürs Protokoll ist mir aufgefallen, dass das auch nur bis ca. 350 kHz funktioniert. Höhere Frequenzen lassen die Betty sterben. Ich hab dann einfach den timer1 verdoppelt und beim IRQ entsprechend. Dann wird zwar das Protokoll etwas ungenauer, aber mit Samsung funktioniert es. B&O funktioniert mit duty cycles 25,33,50 leider nicht, also es läuft durch, aber die B&O reagiert nicht. Dabei ist mir dann die Frage gekommen, dass PWM und timer1 ja eigentlich auseinanderlaufen, also synchronisiert werden müssten. Wie könnte man das machen oder ist meine Variante ohne timer1, aber mit Interrupt für PWMMR0 nicht doch geeigneter ? Oder liegt es vielleicht doch nur an der Diode ?

Ich stürze mich jetzt mal wieder in die culfw....

Das heißt, das Ding btw. die Firmware kann eigentlich nix?

Uhrzeit läuft, aber beim Batteriesymbol wird nix angezeigt bei Tastendruck...

Schade, dachte Betty Boob hätte es zu nem brauchbaren Stadium geschafft :(

das musst Du aber sofort streichen  >:(
Betty mit Boop kann quasi alles das, was eine Universal-IRfernbedienung kann. Alles weitere ist tatsächlich eher im Versuchsstadium, sprich es geht eine Menge, aber derzeit noch ohne sinnvollen Einsatz. Mit meiner kleinen Anpassung(so ungefähr Post #20) lassen sich IT V1-Codes in die firmware einbinden und senden.(Geht super und ich hab nur noch eine FB ;D) Und meine zwei Projekte sind die Einbindung der ungewöhnlichen 455kHz-IR-Frequenz und der culfw. Sollte ich das schaffen :-\ ist die Betty ein CUL mit IR und Bild-, Sound- u. Sprachausgabe......Edit:(natürlich dann noch ohne "wired" Anbindung an FHEM)
Edit:

Zitatbeim Batteriesymbol wird nix angezeigt bei Tastendruck...

Vielleicht hast Du diese Schweizer Variante ? Kommst Du über die Betty-Taste ins Betty-Menü und dann ins Untermenü "Info" ? Dort sähest Du ein paar Angaben über die Hardware.

Was davon soll ich streichen?  8)

na wenn die Funktion der Universalfernbedienung schon gegeben ist, wär ich ja schon froh, dann kann Boop ja schon fast mehr als das was bei mir im Lieferzustand drauf war  ;D

Könnte mir dann jemand eine "richtige" Binary bzw. kompilierte Version zur Verfügung stellen?

Nein, Menu klappt nicht, Tastendrücke ändern maximal die Beleuchtung vom Display, mehr geht nicht.

Und ja, es ist die Schweizer-Variante, zumindest steht Swisscom drauf  ::)

Hoffe doch, dass ich dafür auch eine Bin finde...

Zitat von: KölnSolar am 08 Mai 2017, 22:42:42
Ich habe etwas aufgeräumt und in der Variante mit PWM für die Trägerfrequenz und dem timer1 fürs Protokoll ist mir aufgefallen, dass das auch nur bis ca. 350 kHz funktioniert. Höhere Frequenzen lassen die Betty sterben. Ich hab dann einfach den timer1 verdoppelt und beim IRQ entsprechend. Dann wird zwar das Protokoll etwas ungenauer, aber mit Samsung funktioniert es. B&O funktioniert mit duty cycles 25,33,50 leider nicht, also es läuft durch, aber die B&O reagiert nicht. Dabei ist mir dann die Frage gekommen, dass PWM und timer1 ja eigentlich auseinanderlaufen, also synchronisiert werden müssten. Wie könnte man das machen oder ist meine Variante ohne timer1, aber mit Interrupt für PWMMR0 nicht doch geeigneter ? Oder liegt es vielleicht doch nur an der Diode ?

Kannst du deine Änderungen mal mal veröffentlichen, dann schau ich mir das mal an.

szoller, probier mal die Version. Sollte für die swisscom passen.

@telekatz: ja danke. schicke es per PN, da nicht veröffentlichungswürdig  :-[

Hi Telekatz,

an ne PN kann ich gar nix anhängen  :o, daher also doch hier die relevanten Dateien mit meinen Änderungen. Das ist jetzt die version mit t1mr0 = 2* 15000000/freq, also nur ein interrupt nach 2 Zyklen.
Den "PWM-init" hab ich bewusst in lirc_send eingebaut, um Wechselwirkungen möglichst auszuschließen.
Danke&Grüße Markus

Du rufst den irIRQ viel zu oft auf. Der Sinn darin Hardware PWM zu verwenden ist ja der, nur noch zu den Zeitpunkten einen Interrupt zu benötigen, an denen die Modulation ein oder ausgeschaltet wird (da wo das IR Signal zwischen Pulse und Space wechselt).

Du zählst immernoch b_len im Interrupt hoch bis der Wert von cycles erreicht wird und rufst dann irEncoder auf, um den nächsten cycles Wert zu berechnen. Du solltest allerdings den nächsten Reloadwert vom Timer immer so berechnen, dass der Interrupt erst dann wieder aufgerufen wird, wenn der aktuelle IR Pulse bzw. Space vorbei ist und der nächste Aufruf von irEncode notwendig ist.

Ahhh, verstehe. Guck ich mal wie ich das umsetze. Aber für die Funktion des B&O wird das doch keinen Einfluss haben, oder ? Was denkst Du, wo da mein Problem liegen könnte ? Zu hohe Frequenz für Diode, Duty Cycle....

Danke, mit der Schweizer-Firmware klappts!

Mal schauen, wie ich das Ding zunächst für meine Geräte angelernt bekomme, bevor ich weitere Spielchen versuche  8)

Nochmals danke!

Was mich reizen würde, wäre die Möglichkeit, mit der Betty über Funk Befehle an FHEM zu senden, wenn möglich auch mit Bestätigung á la ACK von FHEM,
eventuell auch die Anzeige von Werten von FHEM wie zB. ne Temperatur, wenn das überhaupt möglich ist.

Beispiel wäre ja ein Menüpunkt zur Heizungssteuerung meiner Max-Thermostate  ;D Oder Ausgabe von Alarmmeldungen von FHEM mit akustischem Signal....

Vielleicht böte sich ja dann auch ein FHEM-Modul als Gegenstück an.

Ich meine, die Betty ist ja zB. bei Amazon immer noch für 10€ inkl. Versand verfügbar  ;D

Aber ich wart mal ab, was ihr so hinbekommt, ich versteh von Programmierung eher wenig...

Zitat von: KölnSolar am 09 Mai 2017, 21:46:27
Ahhh, verstehe. Guck ich mal wie ich das umsetze. Aber für die Funktion des B&O wird das doch keinen Einfluss haben, oder ? Was denkst Du, wo da mein Problem liegen könnte ? Zu hohe Frequenz für Diode, Duty Cycle....

Doch das hat Einfluss auf B&O da aufgrund der hohen Trägerfrequenz auch der Interrupt zu oft aufgerufen wird.

Das war ja mal einfach  ;D im irEncode jeweils den timer auf PWMMR0 * cycles setzen und neu starten und beim IRQ den irEncoder aufrufen. DEUTLICHE Qualitätsverbesserung beim Samsung-Protokoll(vorher hatte ich immer wieder kein IR-SIgnal, was ich auf die Diodenreparatur schob). B&O leider negativ  :'( Frequenz mit 454.545 sollte passen, Protokoll hab ich zig mal verifiziert, duty cycle?, Diode?, Genauigkeit der Pulse(werden ja immer etwas länger durch die Abarbeitung des irEncoder bis der nächste timer gesetzt bzw. der Output(Pulse/Space) verändert wird). Wenn ich doch nur messen könnte, was die Betty und die Original-FB da rausfeuern....

so, endlich wieder Neuigkeiten: Ich habe die aculfw mehr schlecht als recht in Boop integriert und habe heute das erste mal IT-V1 mit gering modifizierter aculfw zum schalten gebracht  ;D
Größte und noch immer nicht begriffene Hürde: Im Gegensatz zur aculfw, wo High=High und Low=Low ist, musste ich für die Betty ein Low auf den Sendepin legen, um einen Highpuls zu erzeugen  :o Irre. Wenn da mal jemand eine Erklärung für mich hat....

Nun geht es an die Empfangsroutine...

@Telekatz: Gibt es einen Grund, dass für Boop die SSP-Anbindung und nicht das einfachere(zur culfw harmonischere) SPI gewählt wurde ? Sonst würd ich, um Modifikationen an der CC1100.h der culfw zu sparen, evtl. auf SPI umbauen.

Keine Ideen zu meinem B&O-Thema ?

Schöne Pfingsten
Markus

Da wohl keiner mit mir reden mag, führe ich mal Selbstgespräche.

ZitatIm Gegensatz zur aculfw, wo High=High und Low=Low ist, musste ich für die Betty ein Low auf den Sendepin legen, um einen Highpuls zu erzeugen  :o Irre. Wenn da mal jemand eine Erklärung für mich hat....

Betty ist unschuldig. Boop war der "Bösewicht. Die PAtable wurde falsch befüllt. Ich hab das jetzt korrigiert. Sämtliche "alten" RF-Funktionalitäten scheinen auch zu funktionieren.

Nun sollte das Senden für alle 433MHz OOK-Protokolle  funktionieren. Hier und da vielleicht noch ein Stellschräubchen drehen. Möglicherweise auch 868er wie FS20 ...... Ich bau jetzt mal ein pendant zur ir_lirc, wo man dann dem Tastencode eine aculfwsendefunktion mit rawCode zuweisen kann....

Zitat von: KölnSolar am 06 Juni 2017, 01:41:03Da wohl keiner mit mir reden mag, führe ich mal Selbstgespräche.

Nennen wir es Monolog, weil lesen tu ich ja. Ich kann dir halt nur nicht helfen. Höchstens motivieren ;).

Gibt es eigentlich einen Trick, die FB "enblock" anzulernen (tausende billige UniversalFB können das auch) oder muss ich wirklich jede (!) Taste einzeln anlernen?

MOTIVIERT  ;D

ZitatGibt es eigentlich einen Trick, die FB "enblock" anzulernen (tausende billige UniversalFB können das auch)

Leider nein

Zitatoder muss ich wirklich jede (!) Taste einzeln anlernen?

leider ja.

Aber möglicherweise  ist Dein Gerät ja bereits im Standard implementiert ? Musst Du mal nach Deinem Gerät googeln und versuchen rauszufinden, welches Protokoll zu senden ist.

Und außerdem ist es ja ein Bastelprojekt. Also nicht zu vergleichen mit einer Uni-FB für 9,99  ;D

Wenn Du ein wenig computern kannst/möchtest, könntest Du Dir auch das passende Protokoll und die Codes aus LIRC heraussuchen. Bei 38kHz sollte eine Implementierung dann einfach sein. Ich unterstütze gerne. Ggfs. könnte ich dann auch einen compile für Dich machen....

bräuchte dann mal kurze C-Hilfe  :-[
Das Problem war keins, sondern an einer anderen Stelle, die ich nun korrigiert habe
Und nun kann man simpel über ein Include seine RF-Tastenbelegung mit den raw codes definieren  ;D IT V1/V3 funktionieren getested. HE und irgendwelche Derivate, selbst mit Quad-Code, sollten problemlos funktionieren  ;D
Nun geht es aber wirklich an den Empfang....

JAAAAAA, Betty hat soeben das erste mal meine B&O geschaltet  ;D also IR mit 455kHz geht  ;D

Nach allen möglichen Gedanken, googeln etc. hab ich dann einfach mal einen Sendebefehl kodiert mit Nutzung der bereits beschriebenen PWM-Funktionalität. Die Pulse u. Spaces habe ich aber nicht über die Programmlogik des LIRC-Moduls gesteuert, sondern deren Abfolge hart kodiert.

Jetzt muss ich also den Fehler im Encoder suchen, aber wenn man einen Anhaltspunkt hat....

Grüße Markus

Fehler gefunden - B&O voll in Betty implementiert  ;D  ;D  ;D  Endlich nur noch eine FB für alles. So soll es sein  ;D

Problem war die Programmierung des LIRC-Encoders in Boop. Es ließ nur Zyklen(Pulslänge) bis 255(0,5ms) zu während das B&O-Protokoll bis zu 8.181(18ms) benötigt. Wer denkt schon an so was  ::)

Leider ist auch die Diode der 2. Betty bei den Tests abgeraucht :'(, so dass ich nun kein "Original" mehr habe. Wenn noch jemand das 16er-Pack im Keller verstauben lässt: Ich bin dankbarer Abnehmer  einer Teilmenge ;)

Hallo Markus
Glueckwunsch zur Vollendung! Das mit den Dioden ist doof! Kann man die nicht ersetzen?
Betty's gibt es noch bei Amazon https://www.amazon.de/gp/offer-listing/B000MIO6L4/ref=dp_olp_0?ie=UTF8&condition=all .
Gruss Christoph

Hallo Christoph,
danke  ;D
Ich hab sie ja mit jeweils einer Sendediode ersetzt. Nur der IR-Empfang geht jetzt nicht mehr. Nicht sooo dramatisch, da ich jetzt ja alle meine IR-Geräte u. Intertechno laufen hab.  :)
Vollendet ? Nicht ganz. Nur ein Etappensieg. Jetzt geht's weiter mit culfw FS20-Senden und Empfang....
Grüße Markus

so, nun funktioniert auch das OOK-Senden mit 868 MHz. Exemplarisch für FS20 eingebaut und erfolgreich getestet. Die letzte Hürde wurde hier (https://forum.fhem.de/index.php/topic,73853.0.html) gemeistert.

Die Sendeleistung ist erwartungsgemäß sehr mäßig. Möglicherweise durch Anpassungen an der PA table aber noch verbesserbar.

Sendetechnisch können wir nun also das, was eine Kombi-Multi-FB können sollte: OOK-Funk mit 433 u. 868MHz, IR für ALLE(denke ich) Frequenzen und Protokolle.

Jetzt aber ran an den Empfang.....
Grüße Markus

Yippih  ;D ;D ;D
Die Betty empfängt SlowRF-Protokolle. MEINE gibt jetzt Töne von sich, wenn es an der Haustür klingelt, jemand durch den Garten läuft......

Die Basis ist somit geschaffen neben den bisherigen FB-Funktionalitäten(IR u. SlowRF) eine "echte" FHEM-Anbindung zu schaffen. Mitstreiter und Ideen willkommen  ;D

Neben fest codierten Aktionen(also "starre" und fest verdrahtete Aktionen aufgrund von z.B. "normalem" on-/off-IT-code)  könnte man u.U. ein FHEM Modul entwerfen, mit welchem man Parameter der Aktion flexibel parametrieren kann(z.B. Frequenzen v. Alarmtönen, Tonpausen, Wiederholungen, LCD-Nachrichten....) Dabei könnte man das FHEM-Modul einfach nur als "Codiertool" "missbrauchen" und die Kodierung dann im Flash speichern oder jede Message individuell senden.  :-\ Jemand ne Meinung, Lust ?

@Telekatz: Ich bräuchte aber wieder mal Deine Hilfestellung. Ich habe den Empfang unschön über GDO0 als GPIO umgesetzt. Müsste also das Ganze über die Main-Loop laufen lassen. Leider bekomme ich den EINT0 partout nicht zum rennen, um das zu vermeiden.  :'( Beim CUL wird ja der EINT auf rising&falling edges eingestellt. Beim LPC2220 geht das aber nicht. Folglich habe ich ihn auf edge sensitive eingestellt und versuche bei jedem Interrupt von rising auf falling edge  und umgekehrt zu wechseln. Es wird aber never ever die interrupt routine aufgerufen  :o Die CC1100-Mimik funktioniert, sonst bekäm ich ja keine Daten bei Nutzung des Pins als GPIO. Ich füge mal die entscheidenden Codepassagen ein, vielleicht siehst Du oder jemand anders meinen Fehler  :-\


startRFIRQ(false);


void startRFIRQ(unsigned char mode) {

stopRFIRQ();

EXTINT |= (1<<0);

PINSEL1 |= (1<<0); //GDO0 as EINT0
EXTMODE |= (1<<0); //edge sensitive
EXTWAKE |= (1<<0);


if(sync) {
EXTPOLAR &= ~(1<<0); //falling edge
VICVectAddr2 = (unsigned long)&(cc1100IRQ);
}
else {
EXTPOLAR |=(1<<0); //rising  edge sensitive
VICVectAddr2 = (unsigned long)&(RFasyncmode_ISR);
}

VICVectCntl2 = VIC_SLOT_EN | INT_SRC_EINT0;
VICIntEnable = INT_EINT0;
}

void RFasyncmode_ISR(void) {

stopRFIRQ();
VICSoftIntClr = INT_EINT0; //notwendig ?

rf_receive_IN_PIN(); // entspricht culfw ISR(CC1100_INTVECT)
draw_string(5, 60, "eint0", LCD_COLOR_B, DRAW_PUT);

EXTINT |= (1<<0);
if (!(EXTPOLAR & 0x01)) EXTPOLAR |= (1<<0); //rising  edge sensitive
else EXTPOLAR &= ~(1<<0); //falling edge sensitive

VICIntEnable = INT_EINT0;
}



Jetzt muss ich ans Tuning, um die Erkennungsrate(Reichweite) noch zu verbessern....

PS: Dank eines edlen Spenders hab ich nun auch wieder 2 "Original-Bettys"  :)

Anhand der Codepassage konnte ich jetzt keinen Fehler finden. Kannst du mal deinen kompletten Änderungen am Sourcecode veröffentlichen.

Au Mann  :o
Wie ich alle Änderungen einstellen soll hat mich überfordert  :-\ Also hab ich versucht so weit wie möglich zu reduzieren u. hab neue Debugmeldungen eingebaut. Und dann fiel es mir wie Schuppen von den Augen: die startRFIRQ(unsigned char mode) rufe ich mit false auf. ABER: anstatt auch mode für die beiden Zweige abzufragen, habe ich sync(eine Konstate) auf wahr geprüft u. folglich hab ich immer den Vector auf die cc1100IRQ gesetzt  :-[

Danke für den Denkanstoß. Mal schauen, ob das nun mit dem switch der r-/f-edges klappt....

Zitat von: KölnSolar am 15 Juli 2017, 18:47:07
Wie ich alle Änderungen einstellen soll hat mich überfordert

Pack den Ordner boop/trunk in ein Archiv und lade es hoch.

Hi Telekatz,
schon klar. Will aber das Forum nicht zumüllen mit Entwicklungen im Entwicklungsstadium. Jetzt muss ich erst einmal konzeptionelle Entscheidungen treffen. Bisher wird ja im Hintergrund sporadisch synchron empfangen. Wenn ich es richtig sehe, nur für die Zeit-Datumseinstellung, sofern an einer anderen Betty gerade geändert oder Testfunktionen. Mit voller CUL-Funktion geht das nicht mehr. Beraubt Boop aber auch nicht einer wesentlichen Funktion. Ich plane daher synchron so lange zu erhalten, bis die neue IR_CUL aufgerufen wird. Synchron wird dann nur noch im settings-clock-menu u. Testmenü unterstützt. Ob ich mir mit der Verwendung des timer1 f. den CUL ein Ei ins Nest gelegt habe, wage ich auch noch nicht zu beurteilen. Strom sparen u. Reichweite muss auch noch verbessert werden. :-\ Noch viel Arbeit vor einer Veröffentlichung.

Ich wollte mich danach in das github der aculfw integrieren. Dazu werde ich Kontakt zu Björn aufnehmen.

PS: Eint0 u. polarity-change funktioniert prinzipiell. Irgendwas schaltet aber noch periodisch u. temporär den Empfang ab. nNur was u. wo  :-\

Ich denke nicht, dass man aus der Betty ein CUL Gerät machen sollte. Deshalb denke ich auch nicht, dass es sinnvoll ist, den Code in die aculfw zu integrieren. Die gemeinsame Codebasis ist dafür zu gering. Die Betty Firmware sollte in einem separaten Repository bleiben.

Ich hab jetzt auch mal etwas an der Boop Firmware gearbeitet. Die IR Encoder sind jetzt alle auf Hardware PWM umgebaut worden. Auch das B&O Protokoll sah am Oszi brauchbar aus.

Die RF Parameter habe ich für die Kommunikation mit einem CUL etwas angepasst. Für die entsprechenden Modifikationen zum Empfang der Betty mit der a-culfw haben ich einen neuen Branch (https://github.com/heliflieger/a-culfw/tree/Betty) erstellt.
Aktiviert und getestet habe ich das neue Protokoll mit dem MapleCUN und dem CUBe. Beim nanoCUL habe ich das Betty Protokoll auch eingebaut, aber mangels Hardware nicht getestet. Wer es ausprobieren möchte, muss sich die Firmware selber compilieren.

Für die Kommunikation mit FHEM habe ich eine angepasste Version von 00_CUL.pm und einneues Modul 10_Betty.pm erstellt. Damit funktioniert aktuell das Senden der Uhrzeit an die Betty und der Empfang der beiden RF IR Encoder.

Für Boop habe ich auf Github ein neues Repository erstellt: https://github.com/Telekatz/boop (https://github.com/Telekatz/boop)
Dort sind auch die beiden FHEM Module enthalten.

Hmmm, jetzt haben wir 2 verschiedene Ansätze. Ich wollte ja mehr die aculfw-Funktionalität in Boop integrieren. Kommunikation mit FHEM als RFR_CUL. Also quasi ein CUL ohne USB mit FB-Funktionalität von boop.

Du hast jetzt ein "neues" Protokoll und einen neuen rfmode für den CUL geschaffen, was doch wiederum bedeutet, dass ein separater CUL benötigt wird, keine aculfw-Sende-/Empfangsmöglichkeiten, kein RFR,....vorhanden sind. Jedes neu zu implementierende Funkprotokoll muss neu entwickelt u. implementiert werden. Einzigen Vorteil den ich sehe, dass die ursprüngliche Struktur(RF synchron/asynchron) erhalten bleibt. Da die aber mit wenig Funktionalität daherkommt......

Vielleicht sehe ich gerade aber nur nicht den wahren Sinn  :-[

B&O geht mit der .bin nicht. Vielleicht nur eine "veraltete" beo4 von mir ? Hast Du auch die Besonderheit des Protokolls berücksichtigt, dass es das sogenannte repeat-bit gibt ? Wird immer dann f. das Folgebit genutzt, wenn das Folgebit gleich dem vorherigen ist. Spacepulslänge ist die doppelte Spacepulslänge des Nullbits.

Muss jetzt erst mal gucken, wie ich die neue Source kompiliert bekomme, den Betty-Branch einrichten, die Anpassungen für den CUL machen und schließlich die aculfw-branch-betty kompilieren u. flashen. Toolchain f. den CUL ist auf nem verliehenen Rpi  :'(

Edit: Mit meiner beo4 geht es auch nicht und den repeat-bit part von mir hast Du ja auch drin. Ich kann mich schwach daran erinnern, dass mir irgendwelche Berechnungen der cycles oder etwas anderes , wo eine Mehrfachoperation stattfand, Probleme bereitet hat. Ich hänge mal meine ir_lirc, die beo4 u. auch die dbox2 u. die samsung_ue46b6000, wo ich jeweils geringfügig Tastencommands korrigiert hatte, an.
Und irgendwie macht die Tastatur seltsame Dinge  :-\ Muss die keyboard.h wieder geändert werden ?

Eine Anbindung an FHEM mit dem RFR Protokoll halte ich einfach für nicht praktikabel. Um das Ping, das über SlowRF vom CUL gesendet wird zu empfangen, muss der CC1100 ständig auf Empfang geschaltet sein und der µC würde auch ständig laufen, um das empfangene Signal zu decodieren. Die Batterielaufzeit der Betty ist so schon nicht berauschend und würde dadurch noch geringer. Und deshalb ist meiner Meinung nach die Betty als CUL artiger Empfänger ungeeignet.

Mit meiner Implementierung läuft der CC1100 im WOR Modus und ist nur während kurzer Intervalle im Empfangsmodus. Den Rest der Zeit legt er sich schlafen. Und erst, wenn der CC1100 ein gültiges Paket empfangen hat, wird der µC zur weiteren Bearbeitung aufgeweckt. Damit ist eine bidirektionale Kommunikation zwischen FHEM und Betty möglich und einer Implementierung der Sendemöglichkeiten aus der aculfw wird dadurch auch nicht behindert.

Für B&O habe ich die Informationen als Basis gehabt, die du hier vor längerer Zeit gepostet hattest. An das Repeat Bit habe ich auch gedacht, siehe Bild im Anhang. Ich hätte es ja gerne mit deiner aktuellen Implementierung verglichen, aber dafür fehlten mir die Sourcen.

Zum kompilieren der Betty Sourcen solltest du maximal die Version 4.8 der Launchpad (https://launchpad.net/gcc-arm-embedded/+milestone/4.8-2015-q3-update) Toolchain verwenden. 

Mein Edit im vorherigen Post hattest Du gesehen ?

Ja stimmt. Und nicht nur für den Ping, sondern auch für empfangene u. an den "stationären" CUL weiterzuleitende Pakete. Und ja, die Bat.Laufzeit geht rapide nach unten. Da die aber eh nicht berauschend ist, ist es egal, ob die Dame 2mal am Tag oder alle 2 Tage in die Station muss. Um an anderer Stelle etwas zu sparen, hab ich unbenötigte Peripherie abgeschaltet. Neue und stärkere Akkus würden sicherlich zu 24h Laufzeit führen.
Aber ein weiteres Manko des RFR ist, dass nicht alle Protokolle funktionieren  :'( z.B IT  :'( :'( Aber da baue ich noch auf eine Änderung.
Ich find halt die Idee der Reichweitenverlängerung schön  :D
Und die bisherigen Entwicklungen(Lernen ;)) möchte ich ja für den Scart-Adapter übernehmen. Aber hey, wie wäre es mit der Kombi ? Scart-Adapter als RFR für den der es mag und der gibt Empfangenes an die Betty in bekannter Weise weiter. Apropos bekannte Weise: das rf send über FHEM ist dann ja logischerweise zeitverzögert, oder ?

Aber seis drum, den RFR-mode könnte ich ja nur für mich separat entwickeln, wenn wir die aculfw wenigstens zum senden integrieren. Ich schick Dir mal ne PN damit ich Dir meinen Entwicklungsstand bzgl. aculfw-slowrf schicken und Du Dir z.B die ir_cul angucken kannst. 

Wie sieht denn ein raw Befehl mit 10_Betty aus ?

ZitatZum kompilieren der Betty Sourcen solltest du maximal die Version 4.8 der Launchpad Toolchain verwenden. 

Hab das installiert, was Du damals empfohlen hattest. (was auch immer das war, aber es funktioniert ja)

Für die Reichweitenverlängerung ohne Kabel gibt es bessere Lösungen, z.B ein ESP8266.

In der Richtung FHEM zu Betty gibt es eine Verzögerung von etwa 0,5 Sekunden, da erst mal ein WOR Paket zum wecken der Betty gesendet werden muss.

Der raw Befehl für 10_Betty sieht eigentlich fast genauso aus wie einer für 00_CUL, mit der Ausnahme, dass das "y" Prefix für das Betty Protokoll automatisch vorangestellt wird.

WOR Packet:
w00

Zeit Setzen:

s0a01000322060717081000


Zum Aufbau der Daten solltest du mal in cc1100/rf.h und cc1100/rf.c schauen.

Ich verstehe zwar nur etwa 10 % von dem, was ihr euch hier an Stichworten zuruft (z.B. "Betty" :D), aber ich bin ganz zuversichtlich, dass ihr der alten Dame ein ganz neues Leben verpasst!

Ja, sorry. Von grober Funktionsdiskussion rutscht man bei der Entwicklung schnell in die nicht mehr allgemein verständlichen Tiefen der Details ab.

Aber mach doch schon mal einen Anfang, leg Dir einen Adapter zum flashen zu. Dann kannst Du die ersten Lebenszeichen schon ausprobieren  ;D

Welche neuen Organe würden Dir denn Freude bereiten ?

ZitatFür die Reichweitenverlängerung ohne Kabel gibt es bessere Lösungen, z.B ein ESP8266.

Bestimmt. aber ich hab mich doch so in die Betty verguckt  :-* Hab mir gerade nochmal die Speichermöglichkeiten angesehen. 64k beim SCART-Interface. Übel. Also wenn überhaupt max. ein Protokoll  :( Aber wegschmeißen ? Niemals !

Um es Euch etwas leichter zu machen, habe ich mal ein paar Dinge zur Betty im Eingangspost übersichtlich zusammengefasst.

Ob sich jemand findet, der das ins Wiki übernimmt  ::)

Grüße Markus

Ihr habt wohl geglaubt ich hätte aufgegeben. Nix da. Ich hatte lediglich etwas weniger Zeit und fehlende Hardware.
Auch, wenn ich nun tw. angedachte Funktionalitäten(Sprachausgabe von Warnungen etc.) mit FS20-SIG-2 und nun sogar Alexa umgesetzt habe, bleibt Betty die MOBILE Wunderwaffe. Denn die SIG-2 braucht ne Steckdose und Alexa einen USB-Anschluss.  ;D

Heute möchte ich Euch erst einmal die Version, die Telekatz erstellt hat, etwas näher bringen.

Er hat ja eine modifizierte aculfw erstellt, die 00_CUL angepasst und 10_Betty erstellt, die uns ein eigenes Betty-Device in FHEM mit batteriesparender Kommunikation ermöglicht.

Wichtig zu wissen: über 00_CUL muss ein neuer rfmode=Betty eingestellt werden, weshalb, abgesehen von Testzwecken, ein separater 433-CUL notwendig wird. Hintergrund ist das verwendete Funkprotokoll, welches eben nicht dem "üblichen" 433MHz- ASK/OOK-Protokoll entspricht.

Eine weitere Bedingung ist, dass die Betty zwingend auf den channel 0 eingestellt werden muss. Auch das hat funktechnische Gründe.

Belegt man nun eine der 4 Geräte-Tasten A-D noch mit dem RF0-Protokoll, so lässt sich mit der Betty in Richtung FHEM kommunizieren. Betätigt man nämlich nun eine Taste, wird per autocreate ein device gem. dem an der Betty eingestellten address-Parameter angelegt.(dadurch wäre also die Unterscheidung von physischen Bettys möglich, sofern gewünscht) Von nun an empfängt das FHEM-Betty-device jeden Tastendruck, so dass man per notify/DOIF etc. darauf reagieren kann. Neben IR auf allen Frequenzen, lässt sich nun also auch FHEM individuell steuern. Der Phantasie sind keine Grenzen gesetzt.  ;)

In der Gegenrichtung gibt es bisher nur das set time command. Es lassen sich Datum u. Uhrzeit mit dem FHEM-Server synchronisieren.

Zukünftig könnte man sich vorstellen:
- Ausbau der Betty zum FHEM-IR-Transmitter: FHEM per Funk an Betty, die relativ fix vor der IR-Gerätschaft liegt, um aus der Ferne ein IR-
  Kommando abzusetzen(heutige Lösungen wie z.B. IRTRANS sind mit irgendwelchen Kabeln verbunden, die unschön schwebend irgendwo lang-
  baumeln)
- Ausbau der Betty zum FHEM-Funk-Transceiver(Reichweitenverlängerer): FHEM per Funk an Betty, Befehl in anderes 433-Funk-Protokoll
  umsetzen(Beispielszenario: schlecht erreichbarer Funkaktor im Schlafzimmer wird nicht direkt über FHEM eingebunden, sondern indirekt über
  die Betty, die eh im Schlafzimmer steht, aber günstiger positioniert ist (oder bessere Empfangsqualität hat ?)
- Sound-/Sprachausgabe
- Displaynachrichten
- Blinkmodus zur Signalisierung
- ......

Habt Ihr Wünsche oder andere Ideen ?

Schönes WE
Markus

Zitat von: KölnSolar am 07 Oktober 2017, 13:00:56Habt Ihr Wünsche oder andere Ideen ?

Zur Reichweitenverlängerung eine Idee (Wunsch?):
Mein Receiver steht in einem anderen Zimmer (leider), in beiden ist eine Betty aktiv (leider noch nicht), wenn ich auf einer Betty den Kanal umschalte, meldet die das (über Fhem) der anderen, die gibt das IR-Signal ab.
Tippe ich direkt an Betty 2 das den Knopf, meldet sie das zwar auch Fhem (wg. dem Status), gib aber das IR-Signal auch ab (am besten direkt, wg. der Verzögerung -> WAF).

Hallo Per,
wenn ich es richtig verstehe, möchtest Du den von mir skizzierten FHEM-IR-Transmitter um eine Komponente erweitern: den IR-FHEM-IR-Transmitter, wobei FHEM natürlich auch durch die direkte Kommunikation zwischen 2 Bettys ersetzt werden könnte.

Suggeriert mir, dass Ihr nicht ständig das Smartphone bis zum letzten Wimpernschlag in den Fingern habt.  ;D ;D ;D Das ist zumindest einer meiner Beweggründe, warum ich die Betty so mag. Bei mir wird z.B. von 23:00-6:00 das WLAN per FHEM abgeschaltet.  ;)

Zurück zu Deinem case:
- fangen wir beim WAF an: Für Betty2(local) würde ich die "normale" IR-Funktion vorschlagen. Dazu ist es natürlich erforderlich zu prüfen, ob es das IR-Protokoll bereits in Boop für Deinen Receiver gibt. Ggfs. über den Anlernmodus der Betty die IR-Codes anlernen. Im Hintergrund könnte dann immer der IR-Tastendruck an FHEM gefunkt werden(an sowas hatte ich noch gar nicht gedacht).
- Mit Betty1(remote) könnte man über die jetzt schon vorhandene Funktionalität die "Taste"(den Tastencode) an FHEM funken. Über notify/DOIF dann den Tastendruck an die Betty2 senden(neu zu implementierendes command in FHEM). Die Betty2 sendet nach Empfang vom Funksignal das entsprechende IR-Signal unabhängig des eingestellten Gerätekanals(A-D) aus(in der Betty zu implementieren).

Klingt gar nicht so aufwändig.

Für meine Priorisierung: Hast Du Bettys und würdest sie vom Staub befreien, wenn es die Funktionalität gäbe  oder überlegst Du Dir erst die "Neuanschaffung" ?
Grüße Markus

Kurz: ich habe bereits zwei Bettys, scheue aber das komplette Anlernen, weil ja im GGsatz zu den "normalen" Universal-FB keine Code-Tabellen integriert sind, die man nur freischalten muss.

Versteh ich, aber vielleicht ist es schon vorhanden. Was ist es denn für ein Receiver ?

Zitat von: KölnSolar am 09 Oktober 2017, 17:35:40Was ist es denn für ein Receiver ?

Irgendwas von Unitymedia  :-[. K.A., was da dahinter steckt.

Der TV ist ein Panasonic, der sollte machbar sein.

Guck mal hier (http://lirc-remotes.sourceforge.net/remotes-table.html). Wenn Du die FB für den Panasonic dort findest, ist die Einbindung ein Klacks. Bei der Unitymedia-Box müsstest Du den Hersteller/Typ ausfindig machen.
Oft stehen solche Dinge im Batteriefach der FB. Oder wie bei Samsung direkt auf der FB, was man aber nie bemerkt  :D

Ich habe mir jetzt auch eine Betty für 1€ bei eBay besorgt, da konnte ich nicht widerstehen.

Ich nutze allerdings ausschließlich Linux, die Einleitung am Beginn dieses Threads bezieht sich aber auf Windows.
Benutzt jemand Linux und kann mit sagen mit welcher Toolchain und welchem Flashtool?

Priiimaa.

Guck mal hier (https://web.archive.org/web/20120929025327/http://www.bettyhacks.com:80/wiki/index.php/Entwicklungsumgebungen#Linux)

und hier (https://web.archive.org/web/20101210073403/http://bettyhacks.com:80/wiki/index.php/LPCTool)

Hallo,

bin absoluter Anfänger in fhem und lese mich erst so langsam ein, mit der Betty hab ich aber doch schon einige Erfahrungen gemacht. :-)
Ach jetzt hab ich es kapiert, der CUL braucht die angepasste aculfw, richtig?

Wie binde ich denn die Betty in fhem ein? Und was kann man damit machen? Kann ich Nachrichten aus fhem an die Betty schicken, zum Beispiel lese ich den aktuell gespielen Film/Serie was auch immer aus Kodi aus und schicke dies aufs Display der Betty?

Danke im Voraus,
eazee

Hallo eazee,
schön, dass Dich Dein 1. Post in FHEM direkt zur Betty gebracht hat  ;D Willkommen im Forum.

Zitatder CUL braucht die angepasste aculfw, richtig?

Lies mal hier (https://forum.fhem.de/index.php/topic,69112.msg663143.html#msg663143) und hier (https://forum.fhem.de/index.php/topic,69112.msg695936.html#msg695936). Telekatz hat die aculfw für die Betty erweitert. Im Augenblick ist das übertragen von Datum/Zeit die einzige "sinnvolle" Funktion. Ansonsten ist es quasi die "technische Infrastruktur", um mit der Betty so etwas

ZitatUnd was kann man damit machen? Kann ich Nachrichten aus fhem an die Betty schicken, zum Beispiel lese ich den aktuell gespielen Film/Serie was auch immer aus Kodi aus und schicke dies aufs Display der Betty?

zu realisieren. Auch, wenn ich nicht genau verstanden hab, was Dir vorschwebt  :-[

Ich wiederum hab einen etwas anderen Ansatz gewählt. Ich habe die aculfw in die Betty integriert, so dass sich (sämtliche ?) slowRf(IT, FS20 getestet) Protokolle leicht nutzen lassen. Außerdem der Empfang solcher Signale und nachfolgende Aktion. Großer Nachteil: Die Betty ist dauernd auf Empfang u. muss daher häufig ins Bettchen(=Ladestation).

Zu meiner Version gibt es keine Veröffentlichung. Nachdem ich die Funktionalität quick&dirty implementiert hatte, bin ich jetzt dabei das Ganze veröffentlichbar aufzuhübschen. Leider gerade aus verschiedenen Gründen recht zäh :-[

Zitatmit der Betty hab ich aber doch schon einige Erfahrungen gemacht. :-)

Dann solltest Du ja Toolchain, Betty Heaven... schon eingerichtet haben. :)

Grüße Markus

Hallo,

danke für die Antwort(en)!

Ja, hab mich ein bisschen unverständlich ausgedrückt. Was ich mir zum Beispiel vorstelle ist folgendes: ich habe mein Kodi in fhem kofiguriert, somit kann ich ja auch den aktuellen Titel des gerade gespielten Films oder Serie oder was auch immer auslesen. Diesen als String oder sowas über Funk an die Betty zu senden, um dieses im Display anzuzeigen, wäre zum Beispiel mein erster Gedanke und Ansporn zu realisieren.

Wenn die Uhrzeit/Datum schon übertragen werden kann, sollte das ja grundsätzlich funktionieren, oder?

Ja, habe die Betty schon seit ein paar Jahren, jetzt beim Umzug wieder rausgekramt und neue Funktionen hinzugefügt/angepasst bzw. aus persönlichen Gegebenheiten geändert.  ;)

Weitere Frage wäre (mein 433MHz CUL kommt hoffentlich bald), wie ich die Betty in der fhem config eintrage. Von welcher Adresse ist denn hier die Rede?

Vielen Dank schon mal im Voraus!

eazee

Zitatwäre zum Beispiel mein erster Gedanke und Ansporn zu realisieren.

You're welcome  ;D
Ich könnte mir so etwas vorstellen: Ein reading "message" im Betty device, welches vom User individuell befüllt und an die Betty gesendet wird. Auf Seite der Betty: Standard oder flexibel(font,size, Positionierung, backlight.....)

ZitatWenn die Uhrzeit/Datum schon übertragen werden kann, sollte das ja grundsätzlich funktionieren, oder?

Ja geht.

Zitatwie ich die Betty in der fhem config eintrage

Am besten gar nicht. Alles über das Webinterface zu definieren. Kommt CUL kommt Hilfe  ;)

ZitatVon welcher Adresse ist denn hier die Rede?

Steht doch im verlinkten Post. Address der Betty. settings-menü -> RF

Zitatneue Funktionen hinzugefügt/angepasst bzw. aus persönlichen Gegebenheiten geändert.

Wäre das etwas f. die community ? Sonst müsstest Du es ja auch immer wieder neu einpflegen. Unsere Basis ist ja die letzte boop-version.

Sehr schön die Betty wird wiederbelebt  8)

Ich hätte da auch noch welche in OVP wer Interesse hat, einfach melden... bevorzugt an Entwickler  ;D

Benachrichtigungen an die Betty auf FHEM wäre schon interessant...

Wie wäre es mit einem Betty Mesh Netz ;D ;D ;D

Hi Smarti,

Zitatbevorzugt an Entwickler

Da kann ich Dir nur beipflichten. Denn ein wenig mehr Unterstützung könnten wir gebrauchen....

ZitatBenachrichtigungen an die Betty auf FHEM wäre schon interessant...

Telekatz hat ja den Weg technisch geebnet. Also zwischen FHEM u. Betty  ein "Protokoll" funktechnisch erschaffen. Nun müsste man halt definieren,  wie eine "Benachrichtigung" optisch/akustisch auf der Betty aussehen soll und wie variabel

ZitatAuf Seite der Betty: Standard oder flexibel(font,size, Positionierung, backlight.....)

wir die Möglichkeiten in FHEM gestalten wollen. Danach könnte man dann die Entwicklungsaufgaben auf mehrere Schultern(bisher sind es irgendwie nur meine beiden u. Telekatz kann nur unterstützend eingreifen) verteilen.

Ich selber hatte ja mein Hauptziele(IR-Protokoll m. Freq. > 38 kHz), Integration von slowRF-Protokollen(=ASK/OOK) über die aculfw u. Signalisierung auf der Betty nach Empfang solcher Protokolle  bereits erreicht. Nun bin ich dabei, die quick&dirty-Implementierung zu standardisieren, so dass auch eine Veröffentlichung möglich ist. Aber wie das halt so ist. Bei mir funktioniert es ja u. dann kommen spannende Projekte wie Feinstaubsensor, Alexa spricht/singt/alarmiert per FHEM-Kommando....dazwischen u. die Betty muss hinten anstehen  :(
Grüße Markus

So, auch mal wieder melden, ist ja lange genug her.  :-[

Ich hab jetzt auch mal meinen nanoCUL433 mit der von Telekatz angepassten aculfw geflasht, die 00_CUL und die 10_Betty ins FHEM gepackt usw. usf.
rfmode Betty wurde auch eingestellt.
Jetzt natürlich gleich eine Frage: Ich habe gelesen in einem Beitrag von Markus, dass das Betty Device per autocreate selbst angelegt wird, sobald man im/mit RF0 der Betty ein bisschen was rausfunkt.
Ist leider bei mir nicht der Fall. ABER: Ich habe rein interessehalber mal meine Funksteckdosen mit dem umgeflashten CUL angesteuert, plötzlich werden mit massenhaft Betty Devices angelegt.
Von Betty_00 bis Betty_FF in allen möglichen hex Kombinationen.  ::)

Was hab ich falsch gemacht?

Habe gesehen dass der Boop Code selbst im Funkprotokoll optimiert wurde, ich habe aber noch den alten Code (wollte meine Betty vorsichtshalber erst mal nicht umflashen)
Liegt es vielleicht daran?

Vielen Dank schon mal für eure Hilfe,
eazee

ZitatABER: Ich habe rein interessehalber mal meine Funksteckdosen mit dem umgeflashten CUL angesteuert, plötzlich werden mit massenhaft Betty Devices angelegt.
Von Betty_00 bis Betty_FF in allen möglichen hex Kombinationen.  ::)

Oha  ;D
Solche Versuche hab ich gar nicht gemacht. Ich hatte ja irgendwo schon einmal erwähnt, dass die "Telekatz-Lösung" den Haken hat, dass man den CUL exclusiv für die Betty per rfmode=Betty nutzen muss(oder sofern man nur an die Betty senden möchte den rfmode temporär umschalten muss)

ZitatHabe gesehen dass der Boop Code selbst im Funkprotokoll optimiert wurde, ich habe aber noch den alten Code (wollte meine Betty vorsichtshalber erst mal nicht umflashen)

Damit Du die "Telekatz-Lösung" testen kannst, solltest Du die Betty schon neu flashen. Ist aber eigentlich recht easy und es geht Dir keine gewohnte Funktionalität verloren....
Grüße Markus

Hey!

Danke für die Antwort!
Ich habe mal die wichtigsten von Telekatz geänderten Files in meine Version gepackt und kompiliert.
Siehe da, die Betty wird soweit erkannt (auch nur einmal als Betty_01 01 ;) ) und bsp. Uhrzeit kann ich auch setzen.

Allerdings kann ich jetzt wenn auf RF0 umgeschaltet wurde nur einmal was senden, dann hängt sich die Betty auf.

Also die kompletten Sources von Telekatz aus dem git geholt und versucht zu kompilieren, krieg ich aber nicht durch. Bin leider grad auf Arbeit und kann die genaue Fehlermeldung nicht schreiben, werde ich aber nachreichen.

Hier die Fehlermeldung:
infrared/infraredirq.c:41: relocation truncated to fit: R_ARM_PC24 against symbol `PWM_set_IR_duty_cycle' defined in .text section in infrared/pwm.o

Denke es hat was mit dem Switch zu PWM zu tun, da stand irgendwas drin. Mit den makefiles hab ich lange rumprobiert (hab auch -Og durch -ggdb ersetzt, da es sonst nicht lief), leider ohne Erfolg.

Könnt ihr problemlos die Sourcen kompilieren und wenn ja, welche Toolchain/Compiler nutzt ihr?

UPDATE: So, oben genannter Fehler ist weg, habe mit der Option -mlong-calls kompiliert, damit ist dieser "Fehler" schon mal nicht mehr im Weg. Jetzt taucht aber folgender auf, den ich bis jetzt noch nicht geschafft habe zu beseitigen:
arm-elf/lib/interwork\libc.a(siprintf.o) uses software FP, whereas boop_rom.elf uses hardware FP

Grüße,
eazee

Toolchain wie im ersten Post angegeben. Wichtig !!! die Versionsinfo beachten, sonst kann es Probleme geben.

Tausend Dank!

Das hatte ich ja komplett überlesen, mea culpa.  :-X

Hab jetzt das "aktuelle" kompilieren können, absolut problemlos. Ist aber - und ich traue mich das fast gar nicht zu schreiben - für mich leider unbenutzbar. Die Tasten werden werden kaum erkannt, DOWN, Exit etc. funktionieren gar nicht. Die keyboard files sind soweit ich gesehen habe aber gleich geblieben, seeeeehr merkwürdig.
Fast genauso verhält es sich beim Senden von Lirc Codes, manche werden auf den Weg gebracht, andere überhaupt nicht. Weiß nicht ob das mit der Umstellung auf PWM zu zun hat.

Was muss ich denn ändern, wenn ich nur das angepasste und verbesserte Funk haben will? cc1100 warscheinlich und was noch? "Change RF settings" Änderungen im git reichen?

Sorry für die vielen Fragen,
eazee

Zitat von: eazee am 08 Dezember 2017, 20:47:35
Hab jetzt das "aktuelle" kompilieren können, absolut problemlos. Ist aber - und ich traue mich das fast gar nicht zu schreiben - für mich leider unbenutzbar. Die Tasten werden werden kaum erkannt, DOWN, Exit etc. funktionieren gar nicht. Die keyboard files sind soweit ich gesehen habe aber gleich geblieben, seeeeehr merkwürdig.

Kontrolliere nochmal, ob es wirklich die Version 4.8 der Toolchain ist, die du benutzt. Und mach vor dem build ein clean.

eazee, oder hast Du vielleicht die Swisscom-Hardware  :-\

@Telekatz: Ja, ist die 4.8er. Ich mach grundsätzlich ein clean vor jedem build, hab ich mir schon vor ein paar Jahren angewöhnt.

@KölnSolar: Ist eine "richtige", definitiv. Die Swisscom hab ich ins Schlafzimmer verbannt, die muss nicht so viel leisten.  ;)

Ja, ist irgendwie merkwürdig, ich kann ja auch meine ursprüglich funktionierenden keyboard files in die Sourcen packen, aber das Ergebnis mit nicht funktionierenden Tasten bleibt das Gleiche.

Ich probier da noch ein bisschen rum...

Aloha an alle Betty-Bastler,

ich bin der Mensch, der den Grundstein für Boop gelegt hat. Hier ein paar, hoffentlich nützliche, Hinweise.

Das ganze war, aus meiner Sicht, nur ein "kann man es programmieren?" Dingens. Ich hätte nie damit gerechnet das so viele Leute daran Interesse haben. Nachdem die eigene Basis-Firmware dann fertig war, ging Betty pleite. Aber es waren gute Leute, denn sie haben uns Palettenweise die Betties geliefert! Kostenlos! Anfangs haben sie ja ein wenig Blödsinn versucht ("1024 bit encryption").

Wie dem auch sei. Ich bin mehr als erfreut zu sehen das Jahre danach noch Leute an dem ganzen Kram interessiert waren. Gut, OK, ist jetzt auch wieder ein paar Jahre her, aber immerhin.

Ich hatte das ganze damals als quick&dirty implementiert. Es war also weit weg von gut. Das sieht man eben auch in dem IR Encoder. Man hat halt die Wahl: Etwas spezielles sehr gut, oder einen breiten Bereich ausreichend. B&O ist halt der Outsider hier. aufgrund der Träger-Frequenz. Mein Ziel war es den Encoder halbwegs "offen" zu gestalten, so das er mit dem meisten Kram funktioniert.

Das war aber auch viele Jahre. Heute würde ich einiges anders machen. Wie dem auch sei, schön zu sehen das selbst Jahre später noch einige Leute Spaß daran haben.

Hätte auch noch ein paar Betties abzugeben....

Bzgl. dem Namen... Wurde ja schon angedeutet. "Betty" war der Name der FB. "Betty Boop" war der Name einer sehr bekannten "Comic"Figur. Und der Start-Song in der originalen Boop Firmware war "Black Betty" von  Ram Jam.

Grüße,

Chris

Hallo Chris,
schön, dass Du Dich hier eingefunden hast, zumal Du vermutlich keinen Bezug zu FHEM hast.  :'(

ZitatIch hätte nie damit gerechnet das so viele Leute daran Interesse haben.

Leider (nicht mehr) so viele.

ZitatGut, OK, ist jetzt auch wieder ein paar Jahre her, aber immerhin.

Aber ich hab sie täglich im Einsatz.  :)

ZitatIch hatte das ganze damals als quick&dirty implementiert. Es war also weit weg von gut.

Ich bin da ähnlich gestrickt.  ::) Funktioniert u. dann bleibt es wie es ist. ???
Die toolchain u. das Hardware-setup sind halt lästig(von der Halbwertszeit des Gedächtnisses ganz zu schweigen), um die Entwicklung wieder aufzunehmen. Kommt bei mir aber irgendwann wieder u. dann greife ich den Ansatz von Telekatz noch einmal auf. Vielleicht in Verbindung mit mqtt.
Grüße Markus
PS: Ich schick Dir mal ne PN mit meiner email zum möglichen anderweitigen Austausch.

Moin KölnSolar,

hehe, jo. Das war damals für mich mehr eine Fleißübung, und nicht wirklich um etwas "fertiges" abzuliefern. Hauptsache was neues lernen. Genauso wie beim ESP8266 vor ein paar Jahren. Da habe ich auch ganz am Anfang mitgemacht und einige Tools (esptool, z.b.) für geschrieben, mit dem Hersteller geredet, etc. Deshalb gibt es jetzt so viel OpenSource Zeug für den Chip :)

Telekatz war bei der Betty auch sehr aktiv und hat sehr viel daran gearbeitet. War ja, wie gesagt, auch mein eigentliches Ziel. Einen Grundstein lege, und dann andere weitermachen lassen.

Wir wurden ja damals dann von denen kontaktiert. Die haben uns dann Palettenweise die restlichen Betties gratis geschickt. Sehr nett von denen, muss man auch mal sagen. Müsste oben im Speicher noch 2 Kartons voll rumstehen haben, denke ich.

Grüße,

Chris

Also - so rein aus Neugier - würde ich mir auch gern mal so ein Teil ansehen. Allerdings eher in Richtung Anbindung Homematic. Auf dem Wohnzimmertisch liegen einfach zu viele Fernbedienungen rum :-(
Also wenn der Platz auf dem Speicher gebraucht wird, würde ich mich auf jeden Fall für ein oder zwei Betty interessieren.

Zitat von: mamalala am 23 Februar 2020, 09:30:47Müsste oben im Speicher noch 2 Kartons voll rumstehen haben, denke ich.

Schade, ich habe selbst noch zwei, mangels Zeit bin ich noch nicht zum Einbinden gekommen. Einfach zu viele offene Projekte...

Moin papa,

hmm, das ist jetz aber doof. Hatte am WE Besuch (Geburtstag und so), und dem habe ich die restlichen Betties mitgegeben. Waren auch "nur" noch 1 1/2 Kartons.

Ich kann mal nen Kumpel fragen, der hatte auch einige Kisten voll. Aber keine Ahnung ob der noch welche hat.

Grüße,

Chris

Hallo Chris,

kein Problem. Ich weiss ja auch noch gar nicht, ob ich überhaupt zeitlich dazu komme. Aber bevor jemand welche wegwirft, würde ich mir einfach eine weg legen.

Achja,

habe grad wieder das alte Verzeichnis von meinem lokalen Betty-Kram wiedergefunden. Hätte da ein archiv anzubieten mit den originalen Quellcodes der Betty und der Adapter. Hatten wir ja damals vom Hersteller bekommen als es dann EOL war. Ein paar Datenblätter sind auch dabei.

Bei Bedarf bitte eine PN an mich.

Grüße,

Chris

Hallo Chris,
gerne.  ;) :-*
Oder ob es i.O.(rechtlich) ist, ein Zip im 1. Post anzuhängen ? :-\ Würd ich dann machen(nur ich kann meinen Post ja ändern)
Grüße Markus

Hi Telekatz,
hi Chris,
hi all,

meine Betty ist nach wie vor zufriedenstellend mit FHEM im Einsatz.  ;)

Da sich meine Systemlandschaft mittlerweile um Zigbee-Komponenten erweitert hat, stoße ich mit meinem alten Ansatz(Integration der aculfw) an meine Grenzen. Außerdem hab ich ein neues Projekt eines TFT-Projektors begonnen.

Nach der langen Zeit des einfach nur Benutzens, krame ich so peu à peu mein Betty-Wissen aus, baue mir meine Toolchain wieder auf und beginne wieder mit einer Weiterentwicklung.

Die bisher nicht von mir genutzte Telekatz-Adaption an FHEM per aculfw scheint mir, wo ich nun andere als nur 433/868- ASK/OOK Komponenten im Einsatz habe, der bessere Weg, um individuell FHEM per Betty zu steuern. Ich guck mal, ob ich die Telekatz-Betty-aculfw für einen busware-V3-Cul hinbekomme, um das weiter auszutesten.

Beim TFT-Projekt (https://forum.fhem.de/index.php/topic,114080.0.html) könnte ich mir den Einsatz des Scart- (https://forum.fhem.de/index.php/topic,70407.msg618955.html#msg618955) oder TAE-Adapters vorstellen. Die Mini-TFTs haben wohl eine proprietäre SPI-Schnittstelle. Müsste man doch an die Betty-Komponenten anschließen können.  :-\ Beim Scart-Adapter hätte man direkt eine 230V-Spanungsversorgung. Etwas problematisch sehe ich den knappen Speicherplatz.
Was denkt Ihr über diese Idee ?

Grüße Markus

Der Scart Adapter könnte dafür taugen. Wenn die Daten nur vom CC1100 zur SPI-Schnittstelle durchgereicht werden müssen sollte der Speicherplatz reichen. Für diesen Zweck kann man die Firmware auch noch etwas ausmisten um Platz zu schaffen.

Vom TAE-Adapter rate ich ab. Die Hardware ist zu exotisch. Da ist zwar ein ARM drauf, aber eine Dokumentation zu diesem Typ gibt es frei zugänglich keine.

Danke Dir für Deine Einschätzung. Ich guck mir dann mal den Scart-Adapter bzw. die betty_scart näher an. Damals hatte ich nur das flashen über die Betty ausprobiert. Ich mache dann in diesem alten Post (https://forum.fhem.de/index.php/topic,70407.msg618955.html#msg618955) dazu weiter.

2 generelle Fragen:
- ich fand damals Deinen FHEM-Ansatz ja u.a. nicht so gut, weil dem FHEM-System ein separater CUL spendiert werden muss.Ich hab mir mal die "Modulationsparameter" von boop angesehen. synchrones GSK..... Sollten wir nicht das Modulationsverfahren komplett auf eher übliches asynchrones OOK umstellen oder was spricht dagegen ?
- daraus resultiert dann auch die 2. Frage: Hast Du für den CUL das selbe Modulationsverfahren implementiert, wie es bereits zwischen boop u. betty_scart existierte ?(dann muss ich nicht mühsam die Register abglichen  ;))

Grüße Markus

Beim CUL habe ich die Einstellungen auf die der Betty angepasst. Zusätzlich habe ich dann noch die Frequenzeinstellungen von CUL und Betty wegen der unterschiedlichen Quarzfrequenzen etwas angepasst. Am Scart Adapter habe ich nichts angepasst. Da müssen noch die Einstellungen von der Betty Übernommen werden.

Zitat von: KölnSolar am 11 Oktober 2020, 10:40:57
Sollten wir nicht das Modulationsverfahren komplett auf eher übliches asynchrones OOK umstellen oder was spricht dagegen ?

Gegenfrage, was spricht dafür? OOK ist bei 433 MHz wohl deshalb weit verbreitet, weil man dann einfache und günstige RF Sender verwenden kann. Üblich sind dann aber auch weit geringere Datenübertragunsraten.

ZitatGegenfrage, was spricht dafür?

Zitatweil dem FHEM-System kein separater CUL spendiert werden muss

, wenn man, u. das haben sicherlich viele FHEMler, bereits 433-OOK, also slowRF, einsetzt.

ZitatÜblich sind dann aber auch weit geringere Datenübertragunsraten.

Klar, aber den ursprünglichen Zweck der Betty ne Menge Daten zwischen Scart/TAE/FB zu übertragen gibt es doch eigentlich bei keiner Anwendung.

Es reicht aber nicht aus, nur auf OOK umzustellen. Du brauchst dann auch einen neuen Encoder/Decoder im SlowRF Teil der aculfw.

ja, richtig, hatte ich nicht bedacht. Sollte aber kein Problem sein.

Toolchain auf dem neuen Rechner steht. Habe board.h u. CUL.c sowie das makefile für den busware_CUL angepasst. Kompiliert u. geflashed. Boop kompiliert u. geflashed. Betty-device wurde über autocreate angelegt. Die Tastendrücke kommen in FHEM an u. das settime funktioniert auch.

Dann werd ich nun  betty_scart an die geänderte Frequenz anpassen.

Oh, da passieren gerade fürchterliche Dinge. Massenhaft Betty-devices in FHEM, gefluteter event-monitor......tbc

....Erst dachte ich meine verschiedenen Bettys würden sich immer wieder ein "Echo" zuschmeißen. Nachdem ich wieder restarted hab, ist mir aber im Log aufgefallen, dass es alles scheinbar begann, als ich mit einem diesem CUL zugeordneten IT-device gesendet habe. Ich spekuliere, dass das mit der immer wieder von mir kritisch beäugten Funktionalität zu tun hat, dass das IT-Modul an den CUL-Einstellungen Veränderungen vornimmt u. wieder zurücksetzt. Ich vermute mal, dass aber nicht alle Parameter zurückgedreht werden und der CUL dann in einen völlig undefinierten Zustand gerät. :'(
2020.10.11 19:19:55 2: autocreate: define Betty_01 Betty 01
2020.10.11 19:41:39 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:40 2: autocreate: define Betty_00 Betty 00
2020.10.11 19:41:40 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:41 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:41 2: autocreate: define Betty_81 Betty 81
2020.10.11 19:41:42 2: autocreate: define Betty_04 Betty 04
2020.10.11 19:41:43 2: autocreate: define Betty_41 Betty 41
2020.10.11 19:41:44 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:45 2: IT IODev device didn't answer is command correctly:   raw => y0142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B200010400000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B20001
2020.10.11 19:41:45 3: CUL433: Unknown code 04000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B20001040001, help me!
2020.10.11 19:41:45 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:45 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:45 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:46 2: IT IODev device didn't answer is command correctly:   raw => y0142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B200010400000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B20001
2020.10.11 19:41:46 3: CUL433: Unknown code B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B200000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143, help me!
2020.10.11 19:41:46 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:46 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:46 3: CUL433 IT_set: Deckenlampe on


Da denke ich seit Jahr u. Tag, dass Betty2 irgendein Akkuproblem hat und musste nun feststellen, dass es die Ladeschale ist, die scheinbar einen "Schaden" hat. Anstatt ca. 4,5V wie Ladeschale1 werden nur 0,4V geliefert.  >:(

Zum Glück gibt es ja noch Ladeschale3.  ;D Muss ich beizeiten mal gucken, was das defekt sein kann.  :(

Grüße Markus

Hi Telekatz,
kann es sein, dass durch Deine damalige Änderung "Change all IR protocols to hardware PWM" b&o u hx2262 kaputt gegangen sind ? Lirc mit Samsung läuft.
Ich bin jetzt wieder soweit, dass ich Deine Version laufen hab u. b&o sowie itv1(neu) teste.
Kann aber auch sein, dass meine Test-Betties spinnen. Bei der einen geht die Exit-Taste nicht, so dass ich keine RC-keys einstellen kann. >:( Dann hab ich immer wieder das Problem, dass nicht nachstellbar manchmal bei Tastendruck in ein anderes Menü(A/B/C/D) gesprungen wird. Bei manchen Encodern auch immer  :'( Selbst bei meiner Produktivbetty. Kann das an schlechten Akkus liegen ? :-\ Wo das fast nie auftritt, ist bei meiner aculfw-Implementierung von damals, um it-v1/-v3 zu senden. Das läuft immer noch sehr gut u. nutze ich am meisten.
Grüße Markus

Den Fehler bei hx2262 habe ich gefunden und behoben. Für b&o habe ich noch einen alten Branch gefunden, bei dem ich da Änderungen gemacht habe. Ich habe beides auf GitHub veröffentlicht. Teste mal, ob es bei dir funktioniert.

Hi Telekatz,
das war es. Danke. B&O u. HX2262 funktionieren nun wieder.

Magst Du die attachten Dateien bei Dir einchecken ?    code.c - new lirc-encoder for Intertechno V1 added
   itv1   - new sample file for Intertechno V1 encoder
   beo4 - all RC-keys added
   samsung_ue46b6000 - change of codes for RC-keys: 0x08F7, // Prog-, 0x34cb, // VTX2


Dann mach ich mal mit dem scart-Adapter weiter....

Grüße Markus

weil ich ja kein serielles Interface am betty_scart hab, hab ich mir gedacht, dass die ping-Funktion zum einfachen Funktionstest brauchbar ist.

Um auch aus FHEM heraus testen zu können, habe ich dem Modul den set ping x Befehl(x=Adresse von 1-9) spendiert.
Beim Empfang dann das reading ping mit adress_ack, wenn ein acknowledge des ping gesendet wurde und ein adress_send, wenn nur der ping-Befehl gesendet wurde(in der Regel das Indiz, dass die "Adresse" den ping-Befehl nicht erwidert hat. Sendet die Betty ein ping an sich selbst(eigentlich ja widersinnig) antwortet FHEM mit einem acknowledge.

Zitat von: KölnSolar am 04 November 2020, 13:32:55
Magst Du die attachten Dateien bei Dir einchecken ?

Code Auswählen Erweitern

   code.c - new lirc-encoder for Intertechno V1 added
   itv1   - new sample file for Intertechno V1 encoder
   beo4 - all RC-keys added
   samsung_ue46b6000 - change of codes for RC-keys: 0x08F7, // Prog-, 0x34cb, // VTX2


Ist eingecheckt.

Hi Telekatz,
lange nichts mehr passiert hier. Klar, läuft ja auch.  8)

Nun bin ich über die Zeit auf ein Problem gestoßen, das bei schlechter Akkuladung auftritt. Erst dachte ich, es läge an einer bestimmten Betty oder gar an einer Modifikation meinerseits und schließlich an Deiner PWM-Modifikation. Aber weder noch. Heute habe ich eine alte boop-Version geflashed, die dieselben Symptome hat.

Das Problem scheint im Lirc-Encoder zu liegen.
- leere Akkus(Akkuanzeige voll  ??? ): Tastendruck bei eingestelltem Lirc-Encoder löst einen reboot aus; bei anderen Encoder, z.B. RC6, nicht
- etwas vollerer Akku: Lirc-Encoder funktioniert; aber die Akkuanzeige springt auf "teilweise" leer bei einem Tastendruck, zeigt später aber wieder voll an

Ich vermute daher, dass da irgendwas kurzzeitig einen hohen Strom zieht. Ne Idee ?

Lässt sich die Akkuanzeige etwas "sensibler" gestalten ? Jetzt ist es bei mir so, dass nach Anzeige "voll" mit wenigen Tastendrücken die Akkus leer sind, weil sie nicht mehr wirklich voll waren. Ich guck mal in adc.c....

Grüße Markus

Edit:
Ich hab mich mal in den Sourcen umgeschaut. Ich seh da nichts, was wirklich speziell bei LIRC anders sein sollte. Ich hab jetzt auch noch weitere Tests gemacht:
Batterieanzeige gut halb(2,56V) bis fast voll(2,64V):
- Display aus: LIRC funktioniert für Samsung, B&O, IT
- Display beleuchtet: IT, Samsung funktionieren; B&O mit Reboot

Scheint mir mittlerweile eher ein durch die Akkus verursachtes "Symptom" zu sein, welchem es sich nicht lohnt näher auf die Spur zu kommen.  ;)

Hi Telekatz,
ich denke, wir haben noch ein Problem mit bestimmten Tasten. Zumindest beim Lirc-Encoder, den ich ausschließlich benutze.

Die Tasten Down, ProgUp, VT2 u. VT3 funktionieren nur ganz selten. Und das bei den verschiedenen Lirc-Encodern(Samsung,Beo4,ITV1) und bei unterschiedlichen Bettys.

Ich hab nun versucht das näher zu analysieren. Überraschenderweise sind alle 4 Tasten über P2.22 verbunden. 4 weitere Tasten mit P2.22 Verbindung sind unproblematisch. Diese sind alle über Port 3 verbunden, während die 4 nicht funktionierenden Tasten über Port 0 verbunden sind. Interessant ist dann, dass die 4 Pins der nicht funktionierenden Tasten auch eine Funktion für timer0 u. timer1 haben: Capture Input bzw. Match Output.

Ist da etwas einfach über PINSELx korrigierbar ?

Zur Symptomatik: In der Regel wird auch kein IR-Symbol beim Tastendruck im Betty-Display angezeigt, wenn die Taste nicht funktioniert. Am besten funktioniert noch die VTX3-Taste. Dort sieht man dann auch im Display, dass das IR-Symbol angezeigt wird. Aber "anders"(kürzer,schwächer) als bei funktionierenden Tasten. Manchmal(wohl bei nicht vollem Akku) führt ein Tastendruck zum Reboot, manchmal auch zum Encoder-Wechsel(A/B/C/D).
Ob das schon immer so war oder möglicherweise erst durch Deine Umstellung auf PWM, kann ich nicht sagen. Muss ich mal nach einer alten .bin suchen und testen.

Ich probier auch mal, wie die Tastendrücke mit RFx in FHEM ankommen..... Edit: Das selbe Problem.

Grüße Markus

Hallo Markus,

kann dir da gerade leider nicht weiterhelfen. Mir fehlt momentan die Zeit, mich wieder in die Betty einzuarbeiten. Ich mache mit der eigentlich gar nichts mehr.

Hi Telekatz,
vielleicht hast Du aber eine Idee/Fingerzeig, wo ich mal näher hingucken kann, um der Symptomatik auf die Spur zu kommen.
Grüße Markus

Also ich habe vor kurzem zwei Bettys erstanden, beide mit defekten Ladeschalen. Nach einem gründlichen Durchmessen hat mir der Wink aus einem DUAL-Forum dann weitergeholfen:
https://www.dual-board.de/index.php?thread/74589-betty-fernbedienung-defekte-ladestation/
Ein semiprofessionelles reines Kapazitätsmessgerät (edit: korrigiert) bescheinigte allen Kondis nur um ca 20% reduzierte Werte. Der Haken ist aber der Serienwiderstand (wie übrigens auch oft beim berühmten "C26"-Problem bei Homematic): Erreicht die Spannung über dem ersten Kondensator einen bestimmten Schwellenwert, wird über einen Optokoppler der Wandler gestoppt - durch den hohen Serienwiderstand sind die Kondensatoren dann aber gar nicht richtig aufgeladen, bei mir lagen die Spannungen bei 2,2 und 1,8 Volt, viel zu wenig für die in Serie geschalteten Akkus.
Mit einem richtigen Bauteiletester nachgemessen habe ich Serienwiderstände von 3-6 Ohm gemessen. Dann die Kondensatoren durch welche aus der Bastelkiste oder frisch aus Schlachteplatinen ausgelötet mit ~0,4 Ohm ersetzt (also nicht mal besonders gute) und die Ladeschaltungen arbeiten wieder einwandfrei.
Es sind übrigens keine Elkos mit mehr als 10 Volt nötig, es geht um Spannungen von maximal 4,5 Volt an der Stelle. low ESR wären von Vorteil.

Meine beiden Bettys haben HW02, eine davon Boop 0.9.1. (in der Kombi also mit den leidigen Steuerproblem am Cursorkreuz) und eine mit der letzten originalen Fernbedienungs-Firmware zum Anlernen von 4 Geräten (was übrigens wirklich beeindruckend gut funktioniert). Aber ich habe genug lernfähige IR im Haus und auch die FS20-Funktionen der Boop-Version sind für mich lediglich experimentell. Ich habe beschlossen, da keine weitere Zeit mehr zu investieren. Bevor ich es im Markt einstelle: Möchte jemand von Euch Aktiven hier die Teile haben, dann macht mir einen Preisvorschlag von mindestens 5 Euro (Versandkosten). Zu beiden Bettys gibt es jeweills nur die (von mir reparierte) Ladeschale. Natürlich auch keine Akkus...

Interessant. Vor allen Dingen, dass der Beitrag im DUAL-Forum noch so jung ist. Gibt ja doch noch Enthusiasten wie mich.

Schade, dass Du die Bettys nicht nutzen möchtest. Auch nicht als Fb für Deine 433er devices ?

Grüße Markus

Zitat von: KölnSolar am 10 Oktober 2021, 19:21:08
Interessant. Vor allen Dingen, dass der Beitrag im DUAL-Forum noch so jung ist. Gibt ja doch noch Enthusiasten wie mich.

Oh ja, und dort hat sie eben noch ganz andere Anwendungsfälle.

Ich wollte das hier auch platzieren, weil ja vielleicht der eine oder andere Bettybesitzer hier auch mit seinen Ladeschalen hadert, Du ja auch vor Jahresfrist, aber ich denke, das hat sich längst erledigt.

ZitatSchade, dass Du die Bettys nicht nutzen möchtest. Auch nicht als Fb für Deine 433er devices ?

Ich habe zwar gerade im gleichen Zuge ein Rudel IT-Steckdosen aufm Tisch gehabt, aber auch die performen eher suboptimal, ich werde ein paar behalten und den Rest wieder abstoßen - und CULs für 433 werde ich auch demnächst zwei im Einsatz haben.

Ich finde die Betty-Idee nach wie vor total reizvoll, aber es darf nicht das 25. halb angefangene und nie zu Ende gebrachte Projekt werden. Der aktuellen Schere im Kopf fällt nicht nur dieses Projekt zum Opfer.

Also wie gesagt: Die Teile sind zu haben, demnächst auch im Markt.