LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[Schotty]

So, ich habe jetzt mal den "schlechten" Clone mit dem "AA" Oszillator in SMD-Keramik-Bauweise und den Wemos Mega mit dem 16 MHz Oszillator in HC49-SMD-Bauweise verglichen. Jedoch ist das einzige, was mir aufgefallen ist, dass der "schlechte" Oszillator eine Tendenz hat, im Schnitt in der Region 15.87 MHz zu schwingen (auch mal über die 16 MHz, aber auch mal runter bis 15.70 MHz); der Wemos Mega Oszillator dagegen so um die 15.97 MHz (gefühlt mit einer etwas geringeren Bandbreite).

Deshalb hatte ich den Link bzgl Quarz vs Resonator auf der vorherigen gepostet, dort kann man das anhand der Kurven schön sehen: Bei dem "AA" Keramik-Bauteil könnte/wird es sich um einen ungenaueren Resonator handeln, und eben nicht um einen Quarz.

[stan23]

Wo könnte ich denn sonst noch (besser) messen?

Ich glaube da kannst du gar nix besser machen, die Kapazität des Tastkopfes ist nun mal vorhanden.

Aber Kapitel 10.10 gibt einen guten Tipp:

http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf
10.10  Clock Output Buffer
The device can output the system clock on the CLKO pin. To enable the output, the CKOUT Fuse has to be pro-
grammed. This mode is suitable when the chip clock is used to drive other circuits on the system. The clock also
will be output during reset, and the normal operation of I/O pin will be overridden when the fuse is programmed.
Any clock source, including the internal RC Oscillator, can be selected when the clock is output on CLKO. If the
System Clock Prescaler is used, it is the divided system clock that is output.

Dort kannst du ohne Beeinflussung messen, der Pin ist stark genug um den Clock zu treiben, ohne dass der Tastkopf was ändert.

[Schotty]

Wenn ich den endlich dazu komme werde ich meine Brötje ebenfalls anschließen. Danke bei der Gelegenheit für Euren Einsatz!

Das sind nur zwei Kabel Gerd, die sind doch schnell angeschlossen!

[freetz]

@Maista: Danke für den Hinweis, aber so tief reichen meine Kenntnisse dann leider doch nicht, als dass ich daraus etwas ableiten könnte ...

@stan23: Danke, das werde ich mal probieren, weißt Du oder jemand anderesb aus dem Kopf, wie ich die mit avrdude richtig setze?

@Schotty: Dass es da einen Unterschied gibt, ist mir schon klar, nur woran erkenne ich das bei dem Bauteilen?

[Schotty]

So wie ich es bisher immer gelesen habe, ist es wohl so: Keramik = Resonator, silbern-oval-metallisch (wie von dir oben beschrieben HC49-SMD) = Quarz

[Airwave]

Das ist ja seltsam, neue Parameter sollten da eigentlich nicht auftauchen, aber ich trage den dann nachher mal nach...

Dankeschön. Parameter /Q wirft jetzt nichts mehr aus.

Gruß

[Maista]

Moin Schotty

Das sind nur zwei Kabel Gerd, die sind doch schnell angeschlossen!

Ich will den Arduino noch in ein Gehäuse packen und Buchse zu meiner Box für die DS18B20 vorsehen.
Die hängen noch am Firmata dran.

Nicht immer klappt es mit Motivation/HiGru 

[Maista]

So wie ich es bisher immer gelesen habe, ist es wohl so: Keramik = Resonator, silbern-oval-metallisch (wie von dir oben beschrieben HC49-SMD) = Quarz

Die obere Bauteile im Bild (Resonator_Quarz.jpg) dürften alles Resonatoren sein.

Im Blechkleid Quarze.

Auf meinem Arduino von Eckstein (Oszillatoren_Arduino_Mega.jpg) ist ein großer mit 16MHz drauf.
In der "nähe" der Mega-CPU etwas kleiner in SMD mit einem 1MOhm aber keine Kondensatoren.

Keine Ahnung ob das für das Projekt hier zutrifft, aber zumindest der Compiler scheint ein Problem zu haben.
https://hackaday.com/2014/11/22/solving-arduinos-stk500_getsync-error/

oder, mit einem Test
http://redhotengineer.blogspot.com/2014/11/my-fight-with-avrdude-stk500getsync-not.html

Nachtrag: Wenn ich bei https://store.arduino.cc/arduino-mega-2560-rev3 das Bild und den Stromlaufplan anschaue sieht das so für
mich aus als wenn das gleich bestückt ist wie bei meinem Board.
Die Kondensatoren sind in dem SMD-Resonator (Bild XTAL_SCH_Mega.png) verbaut.
https://de.farnell.com/murata/cstce16m0v53-r0/keramik-resonator-16mhz-smd/dp/2443265RL?CMP=KNC-GDE-GEN-KWL-MURATA&mckv=_dc|pcrid|237515106428|&gclid=EAIaIQobChMI39nKorG93wIVT-R3Ch3cyAHAEAAYASAAEgIzWfD_BwE

[stan23]

In der "nähe" der Mega-CPU etwas ganz kleiner in SMD mit einem 1MOhm aber keine Kondensatoren.
Das dürfte dann vermutlich kein Quarz sein!? Oder die haben die Kondensatoren vergessen 

Das ist ein Resonator. Habe ich selber schon verbaut, ist billiger als ein Quarz und genau genug für meinen Einsatzzweck.

Vermutlich braucht man das Timing bei USB zwingend einen Quarz.
Dem großen ATmega reicht der Resonator, damit kann man die serielle Schnittstelle ganz gut fahren.

weißt Du oder jemand anderesb aus dem Kopf, wie ich die mit avrdude richtig setze?

Ich mache das immer mit Atmel Studio, da gehe ich davon aus dass es die Fuses richtig rechnet 

[freetz]

@Maista: den habe ich auch, der ist aber für den USB-seriell-Wandler.

@Schotty & stan23: dann habe ich zwei Resonatoren und einen Quarz, allerdings auch einen Resonator an dem "guten" Clone...
Auf den ersten Blick sind bei den Resonatoren nur je ein 1M Widerstände, aber keine Kondensatoren.

[Maista]

Hallo zusammen,

hat schon mal jemand die Schaltung auf dem Tisch in betrieb genommen? Ohne BSB 
Ich habe hier nur 4N37 zur Verfügung und wollte die Funktion erst einmal auf dem Tisch testen bevor ich in den Keller gehe.
Aber mir erschließt sich noch nicht wie ich das elektrisch umsetzen soll.

Ist das eine 20mA-Stromschnittstelle?

Alle Versuche blieben erfolglos das ich auf dem 'CL-'-Ausgang irgend ein Pegelwechsel sehe wenn der Arduino sendet.

Und das tut er auch erst wenn der RXD auf Null liegt.
Das Webinterface zeigt zwar an das er abfragen schickt, aber diese werden erst ausgesendet wenn der RXD ziemlich gut Null ist.

Danke
Gruss Gerd

[freetz]

@maista: Nein, hab' ich zumindest nicht - ob die OKs den gleichen Dienst verrichten, wird Dir ein Blick ins Datenblatt vermutlich besser beantworten können als ich ...

Ansonsten: Dank' stan23s Tipp habe ich nun sowohl auf dem "schlechten" Clone mit dem "AA"-Resonator und auf dem Wemos Mega mit dem Oszillator mittels

Code Auswählen Erweitern

avrdude ... -U lfuse:w:0xBF:m die CKOUT Fuse setzen können, das mir dann auf beiden Boards auf CLKO (Pin 9 des AtMegas - nicht der Pinleiste wohlgemerkt!) die Taktfrequenz ausgibt. Hier ist das zuvor beobachtete noch mal deutlicher geworden: Bei dem "schlechten" Clone sind es 15,8855 MHz, bei dem dem Wemos Mega 16,000 MHz (je auf vier Nachkommastellen gerundet). Das entspricht etwa einem Prozent Abweichung - vermutlich genug, um manche Gegenstellen auf der Heizung zu verwirren, aber noch gering genug, damit nachsichtigere Geräte trotzdem noch kommunizieren.

Bisher verwendet BSB-LAN ja immer noch die von Gero vor fast vier Jahren angepasste SoftwareSerial Library. Die hatte damals feste Taktzyklen basierend auf festen Taktfrequenzen festgelegt. Diese konnte man dann begrenzt über die Variable XMIT_START_ADJUSTMENT anpassen, aber auch nur bei der Länge des Start-Bits.
Neue Versionen von SoftwareSerial berechnen die Länge aus der über die Systemvariable F_CPU übermittelten Taktfrequenz. Es wäre hier also möglich, wenn man die eigene Frequenz weiß, diese beim Kompilieren mit anzugeben und somit dann zuverlässigere Übertragungen hinzubekommen. Dazu müsste ich jetzt mal nachverfolgen, was für Änderungen Gero damals eingebaut hat, ich vermute/hoffe, dass es letztlich nur das Senden bzw. Abfangen des Parity-Bits war, weil wir hier ja mit 8E1 kommunizieren. Vielleicht schaffe ich das die Tage ja mal...

[freetz]

Kann mir jemand der C-Kundigen einmal diese Vermutung bestätigen:

In ./src/BSB/bsb.cpp steht als Kommentar in der Funktion BSB::_send Folgendes:

Jedes gesendete Bit wird ( wegen Bus ) ja sofort auf der Empfangsleitung wieder ankommen. Man schaut nach, ob das gesendete Bit mit dem empfangenen Bit übereinstimmt. Wenn ich eine "0" sende - also den Bus auf High lasse, dann will ich sehen, dass der Bus weiterhin auf High ist. Sollte ein anderer Teilnehmer in dieser Zeit eine "1" senden - also den Bus herunterziehen, dann höre ich sofort auf mit dem Senden und fange oben wieder an. Danach folgen nach gleichem Muster die folgenden Bits, Bit 7..0, Parity und Stop Bit.

Damit soll die Kollisionsprüfung, die vorher schon vor dem Beginn des Sendens prüft, ob der Bus frei ist, vermutlich auch während des Sendens stattfinden. BSB-LAN soll also der rücksichtsvollste Teilnehmer auf dem Bus sein, indem selbst ein begonnener Sendeprozess abgebrochen wird, falls ein anderer Teilnehmer dazwischenfunkt.

In meinen Augen wird dies aber mit dem dann nachfolgenden Code gar nicht umgesetzt, denn:
1. Es wird hier nicht bitweise gesendet, sondern ein ganzes Byte an BSBSoftwareSerial::write übergeben. Dort wird dann unabhängig davon, ob der Bus frei ist oder nicht, dieses komplette Byte inkl. Start-, Stop- und Parity- Bytes gesendet.
2. BSBSoftwareSerial::write gibt immer 1 zurück, außer wenn _tx_delay == 0 ist. Diese Variable wird aber nur einmalig bei Aufruf von BSBSoftwareSerial::begin gesetzt und wäre nur in seltenen Ausnahmefällen == 0.

So wie es jetzt scheint, findet die Kollisionsprüfung beim Senden also nicht statt. Dann könnte man den Code auch rausnehmen, wenn es seit Jahren diesbezüglich kein Problem gegeben hat und durch die Brute-Force Abfragen von Schotty und mir das auch bei mehreren Anfragen pro Sekunde nicht der Fall war.

Ich wüsste auch ehrlich gesagt gar nicht, wie man bei der auf jeden Taktzyklus abgestimmten SoftwareSerial::write Funktion (auf der BSBSoftwareSerial::write ja basiert) zwischen den Bits noch den Bus lesen und auswerten sollte, ohne diese genauen Abstimmungen zu stören.
Meine Vermutung ist, dass die anderen Busteilnehmer auch vor dem Senden schauen, ob der Bus frei ist, so wie das vorher in der Funktion bei BSB::_send auch der Fall ist. Wenn dem so ist, sendet auch nur ein Teilnehmer zur Zeit, und ein weiteres Prüfen während des Sendens wäre von daher auch gar nicht nötig.

Falls ich da nicht etwas Wichtiges übersehen haben sollte, würde ich diesen Code-Teil bei der Adaptierung der neuen SoftwareSerial Library entfernen, um den Code etwas aufzuräumen.

[stan23]

Ansonsten: Dank' stan23s Tipp habe ich nun sowohl auf dem "schlechten" Clone mit dem "AA"-Resonator und auf dem Wemos Mega mit dem Oszillator mittels

Code Auswählen Erweitern

avrdude ... -U lfuse:w:0xBF:m die CKOUT Fuse setzen können, das mir dann auf beiden Boards auf CLKO (Pin 9 des AtMegas - nicht der Pinleiste wohlgemerkt!) die Taktfrequenz ausgibt. Hier ist das zuvor beobachtete noch mal deutlicher geworden: Bei dem "schlechten" Clone sind es 15,8855 MHz, bei dem dem Wemos Mega 16,000 MHz (je auf vier Nachkommastellen gerundet). Das entspricht etwa einem Prozent Abweichung - vermutlich genug, um manche Gegenstellen auf der Heizung zu verwirren, aber noch gering genug, damit nachsichtigere Geräte trotzdem noch kommunizieren.

0,7% sind nicht so schlecht, ob das wirklich schon manche Heizungen verwirrt?
Der BSB ist doch für ewig lange Leitungen spezifiziert, da könnte sich das Signal doch auch stark verschleifen.

[freetz]

Sollte man meinen, aber es würde erklären, warum ein und dieselbe Konfiguration aus Arduino, Shield und Platine an einem Bus ohne Probleme läuft und an einem anderen nicht. Und es würde auch erklären, warum der Empfang der Broadcasts in allen Fällen kein Problem war.
Hinzu kommt, dass die sich die Abweichungen ja pro übertragenem Bit multiplizieren, d.h., beim vorletzten Bit, das ja für die Parity-Prüfung genutzt wird, hätten wir dann ggf. schon eine Abweichung von 8*0,7=5,6%.

Außer es gäbe eine Erklärung, dass die Bauteile auf der Platine selber (noch zusätzliche) Übertragungsgeschwindigkeitsabweichungen produzieren. Da waren wir ja vor einiger Zeit schon mal bei dem Thema, aber sind da zu keiner zufriedenstellenden Erklärung gekommen, wenn ich mich recht erinnere...

Ich bin mit der Übernahme der neuen Library aber schon recht weit gekommen, nur leider will jetzt mein "schlechter" Arduino nicht mehr über USB angesprochen werden, so dass ich im Moment keinen Vergleich mehr habe ...