Platine für Selbstbau NanoCUL

Begonnen von prodigy7, 26 Juni 2015, 21:17:48

Vorheriges Thema - Nächstes Thema

Omega-5

Zitat von: Spezialtrick am 03 Dezember 2015, 12:23:37
Aber ist das so tatsächlich allgemein für jede Bestückungsoption richtig bei der v3.1?

Die Pins A0, A1, A2, A3 sind bei meinem NanoCul 868 nämlich verbunden und der Stick funktioniert einwandfrei. Kann es sein, dass dies nur für die MySensors Bestückung gilt?
Das wird auch von der eingesetzten Software abhängen. Wenn die Pins Ax als nicht benutzte Eingänge (hochohmig) gesetzt sind, stören sie die Funktion nicht.
Ich meine die Bezeichnung Ax deutete ursprüngliche bei den Arduinos auf die Funktion als analoge Eingänge hin.

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

Spezialtrick

Könnte das auch der Grund sein, weshalb die Culfw ohne Probleme funktioniert und die A-Culfw nicht?
FHEM - Debmatic - Zigbee2MQTT - Homekit

Tom71

Bei mir funktioniert die Version 1.1 nur mit der a-culw., oder meint ihr die PCB 3.1? Vielleicht hängt es vom Modul ab. Ich benutze bei meiner Steckbrett-Version auch die a-culfw in Benutzung. Da habe ich ein RF 1101-SE ohne Vorwiderstände.


Gesendet mobil
Homematic | RaspberryMatic

Tom71

Für Arduino Nanos mit original FTDI Chip hab ich einen Lieferanten in Berlin gefunden: http://www.avc-shop.de/epages/64272905.mobile/de_DE/?ObjectPath=/Shops/64272905/Products/FT-ANANO
Hab ihn aber noch nicht ausprobiert, könnte ihm aber mal besuchen, wenn es kein Original Chip ist. Ich hab gestern bei einem Clone den Chip ersetzt. Hat geklappt. Aber der FTDI kostet schon allein 3,50€.


Gesendet mobil
Homematic | RaspberryMatic

Garagenhaus

Zitat von: Tom71 am 03 Dezember 2015, 00:20:42
Ist es richtig, das ein CC1101 868 Stamp Modul nur zum Senden auf 433Mhz geswitcht wird und ich damit nicht wirklich ständig 433Mhz empfangen kann?
Hi Thomas,
nein, du kannst ,.E. beides machen. Temporär switchen oder dauerhaft umstellen. Der Chip ist bei beiden Modulen genau der selbe, nur der Antennen Schwingkreis sind auf die jeweilige Frequenz optimiert, d.h. du hast immer auf der anderen Frequenz eine schlechtere Sende-und Empfangsleistung bzw. Reichweite.

Hauswart

1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

chris1284

#531
Zitat von: Spezialtrick am 03 Dezember 2015, 15:26:31
Könnte das auch der Grund sein, weshalb die Culfw ohne Probleme funktioniert und die A-Culfw nicht?

benutze ausschließlich die a-culf. daran liegts nicht. habe die pins auch verbunden und keine probleme.

auch das bedienen meiner 433 it dosen mit der aculf und dem 868 modul auf dem 3.1 funktioniert sauber

was ich jedoch beobachte das mit der 3.1er auf dem nano die rote led dauerhaft leuchtet (nicht die auf dem 3.1, die blinkt sauber). was bedeutet diese?

Omega-5

#532
Zitat von: Hauswart am 03 Dezember 2015, 17:16:24
Post ist da :)  8)
Meine auch. :)  8)

Zwei mal V3.1, wollte ich mit Arduino Pro Micro und CC1101 bzw. RFM12 bestücken. Und da gibt es bereits ein Problemchen.
Die Pro Micros haben die USB-Anschlüsse auf der Seite wo auch die SMA-Buchse sitzt.   >:(
Mal sehen was man da machen kann. Drahtantenne wird wohl eine Alternative sein.

@Tom71
ZitatBei mir funktioniert die Version 1.1 nur mit der a-culw., oder meint ihr die PCB 3.1?

Ich ging von der 3.1 aus. Bei der V1.1 ist ja nur der Arduino Nano vorgesehen.

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

Spezialtrick

#533
Zitat von: Omega-5 am 03 Dezember 2015, 15:02:33
Das wird auch von der eingesetzten Software abhängen. Wenn die Pins Ax als nicht benutzte Eingänge (hochohmig) gesetzt sind, stören sie die Funktion nicht.
Ich meine die Bezeichnung Ax deutete ursprüngliche bei den Arduinos auf die Funktion als analoge Eingänge hin.

Gruß Friedrich

Das könnte als bedeuten, dass die A-Culfw die Pins A0, A1, A2, A3 nicht "hochohmig" setzt?

Edit: Die Ohren sind raus. ;D
FHEM - Debmatic - Zigbee2MQTT - Homekit

PeMue

Zitat von: Spezialtrick am 03 Dezember 2015, 20:45:25
Das könnte als bedeuten, dass die A-Culfw die Pins A0, A1, A2, A3 nicht "hochohrig" setzt?
;D ;D ;D ich bin immer wieder erstaunt ??? über die Leistungsfähigkeit der Autokorrektur  ;D ;D ;D
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Spezialtrick

#535
;D ;D ;D
FHEM - Debmatic - Zigbee2MQTT - Homekit

Omega-5

Also Leute, ich habe jetzt mal eine V3.1 mit Arduino Pro Micro und CC1101 868MHz bestückt. Das CC1101 war schon mal per Kabel in Gebrauch. Sicherheitshalber habe ich es mit Steckern versehen und Buchsenteile auf die LP gelötet. Wie schon mal oben erwähnt ist die V3.1 nicht optimal für den Pro Micro, da die USB-Buchse auf der gleichen Seite wie die Antenne ist. Leider muß auch die Firmware angepasst werden, da bei der Standart CUL_V3 die Signale GDO0 und GDO2 auf anderen Ports liegen. Änderungen in der boerd.h sind nötig.

#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_SS PB6 //D10 CSN, war PB0
#define SPI_MISO PB3
#define SPI_MOSI PB2
#define SPI_SCLK PB1

#  define CC1100_CS_DDR       SPI_DDR
#  define CC1100_CS_PORT     SPI_PORT
#  define CC1100_CS_PIN        SPI_SS
#  define CC1100_OUT_DDR     DDRD
#  define CC1100_OUT_PORT   PORTD
#  define CC1100_OUT_PIN      PD0 // GDO0, war PD3 D1 TxD
#  define CC1100_OUT_IN        PIND
#  define CC1100_IN_DDR        DDRD
#  define CC1100_IN_PORT      PIND
#  define CC1100_IN_PIN         PD1 // GDO2, war PD2 D0 RxD
#  define CC1100_IN_IN           PIND
#  define CC1100_INT              INT1 // war INT2
#  define CC1100_INTVECT      INT1_vect // war INT2_vect
#  define CC1100_ISC              ISC10 // ISC20
#  define CC1100_EICR            EICRA
#  define LED_DDR                   DDRD // DDRE
#  define LED_PORT                 PORTD // PORTE
#  define LED_PIN                    PD5 // LED_ERR, war 6

#  define CUL_HW_REVISION "CUL_promicro"


Im Anhang drei Fotos.

Da meine RFM12 auf dem Versandweg verloren gegangen sind, dauert es wohl bis ins neue Jahr bis ich Ersatz bekomme. Ich würde deshalb meine zweite V3.1 inclusive Bauteile weitergeben (kostenlos).
Wer wäre denn der nächste auf der Liste.

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

PeMue

Ich denke, in der Bestückückungsliste ist noch ein Fehler:
- die v3.1 geht nur mit 3.3 V Ardunino pro micro bzw. pro-mini
- hierfür sind nur R15 (Vorwiderstand für LED) und LED11 bzw. R16 (pullup für CSN notwendig) (Friedrich ist sogar noch sparsamer als die Schwaben, er kommt sogar ohne LED aus  ;))
- die LED11 ist doppelt, ich würde das zweite Vorkommen löschen
Ich schaue es mir noch mal an und lade die Liste dann noch mal hoch.
Mal schauen, ob ich die vermeintlich defekte Platine nicht doch noch retten kann: nanoCUL 868 MHz mit pro-micro. Allerdings sind diese noch irgendwo im Flieger/Schiff(?)

@Friedrich: Könntest Du Deine compilierte Firmware hochladen? Da die Firmware ja von der Platinenversion nichts weiß, wäre mein Vorschlag für die Nomenklatur folgende:
culfw_vx.y_(8|16)_(433|868)_(nano|promicro).hex, wobei:
- x.y Versionsnummer der Firmware
- 8 oder 16 die Frequenz des Arduinos in MHz (eigentlich ist das das Resultat aus der Spannung  ;))
- 433 oder 868 MHz die Frequenz des Moduls (wenn es da einen Unterschied der eingebundenen Protokolle geben sollte)
- der Rest sollte selbsterklärend sein
Ich denke, die Firmware für Arduino nano bzw. Arduino pro-mini sollten gleich sein, da beim letzteren nur der USB<->seriell Wandler fehlt.

Wir sollten uns auch mal überlegen, ob wir das Ganze nicht auch in den offiziellen Teil der culfw einbauen könnten, was meint ihr?

Danke + Gruß

PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

PeMue

[offtopic]
Und hier noch was zum neidisch machen, heute sind meine Gehäuse für meine USB-Bluetooth bzw. RS485-Bluetooth Platinen gekommen:
(http://forum.fhem.de/index.php?action=dlattach;topic=38561.0;attach=41521;image)
[/offtopic]
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Omega-5

#539
Zitat von: PeMue am 05 Dezember 2015, 20:35:40
@Friedrich: Könntest Du Deine compilierte Firmware hochladen? Da die Firmware ja von der Platinenversion nichts weiß, wäre mein Vorschlag für die Nomenklatur folgende:
culfw_vx.y_(8|16)_(433|868)_(nano|promicro).hex

Ich hänge mal die Quelle für ein neues Device und das Hexfile an. Erst mal nur Q&D. Also noch nichts Endgültiges.

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),