Cc1101 von Ebay

[kimbolero]

Bestellt habe ich die hier: http://www.aliexpress.com/snapshot/6499458011.html
Dort sind auch die Daten von dir auf den Vorschaubildern zu sehen.
Bekommen habe ich die jedoch so wie im Anhang zu sehen (RF1101SE V3.1).

[locutus]

@Funsailor
es liegt am fehlenden CC1101. Du hast ein "Radio ohne Empfangsteil" gebaut!

[Funsailor]

@locutus
Hallo,
Danke für deine Antwort.
@alle
Habe nun nochmals die Firmware vom Gummibärchen (culfw-code-507-trunk) geladen.
Ich habe das Device "nanoCUL" ausgewählt, allerdings habe ich gerade den "Mini pro" mit meinem CC1101 aufgebaut.
Und da habe ich die selben Probleme. Keine Versions abfrage mit V möglich.
Und auch hier habe ich das Problem, das beim Schalter "HAS_16MHZ_CLOCK" nur alle 2 Sekunden die LED blinkt.
Da der Schalter HAS_16MHZ_CLOCK auch bei der Initialisierung der Baud Rate eine Rolle spielt

#ifdef HAS_16MHZ_CLOCK
  uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
#else
  uart_init( UART_BAUD_SELECT_DOUBLE_SPEED(UART_BAUD_RATE,F_CPU) );
#endif
habe ich nun verschieden Möglichkeiten getestet.
Jeweils F_CPU im "makefile" auf 8MHz und 16MHz gestellt
Mit jeder Auswahl von F_CPU mit und ohne HAS_16MHZ_CLOCK getestet
Und dann nochmals bei der Takteinstellung den Prescaler fest eingestellt: clock_prescale_set(clock_div_1); -> Den nur dann blinkt die LED im 1 Sekundentakt!
Um den Überblick nicht zu verlieren habe ich eine Liste abgearbeitet!

Nix geht, ich sehe zwar das beim Senden die Blinkfrequenz geändert wird, aber eine Antwort erhalte ich nicht.

Um die Baudrate zu testen würde ich nun gerne jede Sekunde mit dem blinken eine Message senden, how to do?
Da müsste ich mich ziemlich tief in die CUL Lib reinarbeiten, kann mir da jemand einen Tipp geben? 

Oder an welchem Pin des CC1101-Modul muss ich nach Reset was messen (Ich habe da sehr gute Möglichkeiten)

Kann ich den Mini nicht mit der nanocul laden?, so wie ich das bisher verstanden habe sind die beiden außer dem eingebautem USB/RS232 Konverter, der Taktfrequenz und der 3,3V Versorgungsspannung identisch.

[locutus]

Es leuchtet mir nicht ein, warum du ausgerechnet den Fehler im Source Code suchst. Sorge bitte erstmal dafür, dass die Hardware nach dieser Anleitung aufgebaut und mit der vorhandenen Firmware gefüttert wird: http://www.fhemwiki.de/wiki/Selbstbau_CUL
So wie ich das sehe, kommt keine serielle Kommunikation zustande. Es wäre sehr hilfreich, wenn du Angaben zur deiner CUL Definition machen könntest. Ein brauchbares Foto von deinem selbstbau CUL wäre auch nicht verkehrt.

[chris1284]

Habe nun nochmals die Firmware vom Gummibärchen (culfw-code-507-trunk) geladen.

zum einen ist die anleitung besser http://www.fhemwiki.de/wiki/Selbstbau_CUL und zum anderen hat das Gummibärchen keine eigene firmware 
ich würde dir raten, wie locutus schon schrieb, den aufbau zu prüfen. wenn du alles richtig verkablet hast , die richtige firmware nach anleitung geflashed hast dann hast du 0 probleme mit dem selbsbau cul und ein neuschreiben der firmware ist zu 101% nicht notwendig. wenn du björns alternative culfw nimmst hast du auch gleich für alle arten des cul's (nano/mini/433/868 usw) fertige hexfiles die du nur noch flashen musst http://forum.fhem.de/index.php/topic,35064.0.html ohn den quellcode auch nur anschauen zu müssen, für einsteiger der sicherste weg

[Bugs]

Guten Abend zusammen.

Ich hätte da mal eine kurze Frage:
Warum braucht dieses Modul extra noch einen uC? Im Falle eines Rpi ist doch die SPI Schnittstelle vorhanden und ein SPI-Treiber gibt's für das Modul wohl auch.

Mit freundlichen Grüßen
Bugs

[hexenmeister]

Warum braucht dieses Modul extra noch einen uC? Im Falle eines Rpi ist doch die SPI Schnittstelle vorhanden und ein SPI-Treiber gibt's für das Modul wohl auch.

Weil die existierende Firmware für AVR geschrieben ist.
Dank µC+USB ist das Ganze auch wesentlich universeller als direkt an RPI.

[Bugs]

Hmm, ok...
Ich frage eigentlich nur, weil ich vorgehabt hätte das ganze auf einem HLK-RM04 Modul mit OpenWRT zum laufen zu bringen.  FHEM läuft schon, leider belegt der dafür benötigte USB-Stick schon den USB-Port. Aber SPI wäre noch frei !
Diese Kombo ergäbe ein echt winziges, günstiges und stromsparendes Zuhause für FHEM incl. LAN und WLAN.

Bugs

[hexenmeister]

Du hast Doch zuerst von RPI gesprochen? HLK-RM04 ist vermutlich wieder etwas anders.
Wie auch immer, theoretisch ist das nicht unmöglich. Aber die entsprechende Software gibt es meines Wissens nicht. Ist auch vermutlich nicht ganz ohne, da (im Unterschied zu Atmel) RPI/HLK-RM04 & Co. mit Linux/OpenWrt nicht realtime fähig sind. Könnte ein Problem sein.

P.S. nimm doch einen kleinen USB-Hub. Es gibt ganz kleine dabei

[Bugs]

Da Openwrt auf dem aktuellen MainstreamKernel basiert sind Rpi(Raspbian) und HLK-RM04 das gleiche, Sorry.
An welcher Stelle ist denn RT-Fähigkeit gefordert?
Bei reiner Master/Slave Kommunikation ( Master fragt und Slave antwortet ) von FHEM zu Aktor/Sensor seh ich da kein Realtime-Problem.
Ein kleiner Hub könnte auch gehen, aber was wenn er unnötig wäre?!
Bitte nicht falsch verstehen, ich frage nur um zu lernen

Bugs

[hexenmeister]

Kernel ist nicht alles. Die Systeme haben nicht die gleiche Hardware und (in diesem Fall) auch nicht die gleiche Software. Da gibt es ein ganzer Berg kleiner Feinheiten. Daher würde ich die Aussage, dass bei den beiden Systemen um "das gleiche" handelt nicht unterschreiben.
Ich weiß nicht, wie wichtig RT-fähigkeit hier praktisch sein wird, aber Timing hat schon eine große Bedeutung. Auch bei reiner Master/Slave-Kommunikation. Falls ein anderer Prozess dazwischen kommt - kann (wird) es zu Verlüsten kommen (ggf. auf beiden Seiten). Das muss man schon berücksichtigen. Ich will damit sagen, dass eine 1zu1 Portierung nicht ohne weiteres möglich ist.

[Funsailor]

Vorab: Problem gelöst, CUL im Eigenbau brummt.

@locutus   
-> Die Versions Abfrage mit einem Terminal Programm geht auch ohne CC1101 Modul!  Dazu muss man nur die FW auf den Arduino bruzeln!

-> Ich habe keinen Fehler in der Firmware gesucht, sondern die Möglichkeit meinen Aufbau zu testen, den bei der visuellen Prüfung der Schaltung konnte ich keinen Fehler finden.
Scheinbar hatte ich eine Firmware erwischte (wenn ich Zeit habe suche ich die mal raus) bei der der die LED trotz richtiger Taktauswahl (16MHz) mit 0,5 Hz blinkte, da dachte ich an ein Frequenzproblem.  Da man die interne Taktfrequenz nicht einfach messen kann, wollte ich die Frequenz der seriellen Schnittstelle überprüfen. Einfach mal eine Message vom Arduino senden lassen und mit dem Oszi ausmessen.
Mit Hilfe von kahis (Nochmals vielen Dank für die Unterstützung) habe ich dann die relevanten Stellen in der LIB gefunden und beim Startup eine Versions abfrage gesendet. Klappte hervorragend (38400 war richtig).
Hätte ich mir aber auch sparen können, den beim lesen des Codes konnte ich sehen, das die CUL nicht nur ein 'V' erwartet sondern ein 'V CR' oder 'V LF'. Und das muss man beim HTerm einstellen.
@chris1248 Mir ist bewusst das Gummibärchen keine eigenen FW gemacht hat, hab mich da undeutlich ausgedrückt.

Ich habe mich nun mal an ein paar einfachen Intertechno - Steckdosen gemacht und die Intertechno - Fernbedienung eingelesen. Klappt bisher prima, ist aber noch keine wirkliche Aufgabenstellung!

[Garagenhaus]

Hat jemand schon mal eine kleine 2-lagige Adapterplatine ankonstruiert, die man als Verbindung zwischen Nano und CC1101 Modul nehmen könnte?
Kompliziert ist das Routing ja nun nicht und ohne Adapter sind die ganzen Kabel oder gar Breadboard ja nicht gerade schön.

Im Prinzip gibt es ja nur zwei Typen von Modulen: 2,5 mm Pins (die 433Mhz Module) entweder als 2x5 Pins (dann sind VCC und GND jeweils an 2 Pins) oder als 2x4 Pins, dann sind VCC und GND nebeneinander. Das könnte man auf ein Layout mit einer Lötbrücke passen. Dann gibt es die 2mm "Briefmarken" Versionen für 868Mhz mit 8 Halbpins in einer Reihe.

Ich stelle mir das so vor:

- Eine kleine Platine ungefähr im Formfaktor des Nano
- Auf der Oberseite wir das CC1101 Modul durchgesteckt und von unten fest gelötet. Ebenso wir die Kontroll-LED und Widerstand angelötet.
- Unterseite: Ein kleiner 4-Pin Level Shifter zum Auflöten (für Perfektionisten für die Output Pins des Nanos) wird angelötet, alle anderen schließen einfach drei Lötbrücken oder es werden Spannungsteiler/Widerstände angelötet (davon wird aber i.d.R. abgeraten und die LevelShifter kostet fertig nur 70Cent.
- Finaler Montageschritt: Der Nano wird von unten aufgesteckt und die Pins festgelötet
Den Nano gibt es als fertige Eagle Library, die 2x5 Pin Reihe bestimmt auch.

Damit hätte man von der Parts-List nur noch fertige Standard-Komponenten mit wenigen Lötstellen, die auch Anfänger zusammen löten können und alles wäre schön kompakt, auch ein versehentliches Falschlöten und Sticken reduziert sich drastisch auf eine Lötbrücke (10 oder 8 Pin Modul)

Gibt es jemanden der sowas in Eagle o.ä. konstruieren könnte?
Ich würde es ja gerne selber machen aber meine Eagle Kenntnisse sind leider sehr begrenzt.
Dafür könnte ich mich um eine erste Sammelbestellung und Verteilung kümmern.

[noice]

Ach dann ist doch das basteln nur noch halb so schön

[kadettilac89]

Hat jemand schon mal eine kleine 2-lagige Adapterplatine ankonstruiert, die man als Verbindung zwischen Nano und CC1101 Modul nehmen könnte?
Kompliziert ist das Routing ja nun nicht und ohne Adapter sind die ganzen Kabel oder gar Breadboard ja nicht gerade schön.

Ohne das schlechtreden zu wollen, mit dem CC1101-Modul mit 2,54mm Pins und einer Lochrasterplatine kann man sich das auch ohne großen Aufwand ansehnlich zusammenbauen. Mal die Levelshifter außer Acht gelassen, die würden noch einiges an Löten verursachen. Aber so viele Kabel sind es nun auch nicht dass man große Fehler zu erwarten hätte. Wenn solch ein Projekt, wäre es interesant wenn eine Steckbrücke für Arduino und das CC1101 schon vorhanden wäre, dann müsste nur noch gesteckt werden und alle die auf Löten verzichten wollen könnten es ganz einfach zusammenstecken. Vielleicht will sich ja jemand ein paar Euro damit verdienen.