Digitalsysteme .... eine Gegenüberstellung

Modellbahn Digitalsysteme ... eine Gegenüberstellung; aber keine Vergleiche und Bewertungen

Digitalsysteme ... eine Gegenüberstellung

>>>>> !!! im Aufbau begriffen; Zwischenspeicherung !!! <<<<<<<<<<

Vorwort

Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad & Co, Freiwald Software (Egmating) habe ich entnommen, daß viele Modellbahner, die neu in das digitale Zeitalter eintreten oder eine Umstellung / Erweiterung vor haben, unsicher sind, welches digitale System und welche Komponenten denn nun "die richtigen" seien.

Ferner habe ich den Eindruck gewonnen, daß bei bestimmten Betriebssituationen Probleme auftauchen, die sinnvoll nur unter Berücksichtigung der Kenntnisse der / des digitalen Systems(e) gelöst werden können.

Bei all dem wurde und werde ich an meine eigene Zeit erinnert, als ich vom analogen System auf das digitale umgestiegen bin.

Diese Gegenüberstellung soll die reinen technischen Daten und Fakten, wie sie von den Herstellern in ihren Datenblättern bzw. in den Normen definiert sind ergänzen.

Ich betone ausdrücklich, daß dieser Beitrag kein Vergleich über "für und wider" darstellen und auch kein System bewerten soll.

Der Leser soll diese Informationen mit aufnehmen und hoffentlich erfolgreich in seine Lösungsfindung einbeziehen.

Betrachtete Digitalsysteme

Am Markt werden eine Reihe von digitalen Systemen angeboten. Ich will hier nur die betrachten, die am häufigsten im oben erwähnten Forum vertreten sind; hierzu zählen ...

• DCC
• Märklin mit seinen Varianten
• Selectrix (SX)

In dieser Abhandlung wird der Stand der Systeme betrachtet, wie er im August 2011 vorlag. Spätere Entwicklungen müssen jeweils nachgetragen werden.

Digitalsystem - Architekturen

Historie

• allgemeine Betrachtung

Meines Wissens und meiner Erinnerung nach brachte die Fa. Märklin als erstes ein "komplettes" Digitalsystem auf den Markt, welches als "Motorola I" bekannt wurde. Es folgten über die Jahre die Nachfolger "Motorola II" und "mfx".

Märklin führte sein digitales System unter dem Marketingaspekt ein: Zwei Drähte genügen zum Betreiben der Anlage. Kein "Drahtverhau" mehr, wie bei analogen Anlagen. Als Drähte fungierten weitestgehends die Schienen als Verbindung zwischen Zentrale und jeweiligen Dekodern. Für die Rückmeldung (Besetztmeldung) wurde eine separate Kommunikationsstrecke eingeführt, der "s88 - Bus".

Die technischen Details des Märklinsystems wurden ofiziell nie offengelegt. Technisch interessierte Nutzer ermittelten "rückwärts" (re-engineering) die Protokolle für "Motorola I / II" und konnten somit Selbsbauprodukte aufbauen. Für "mfx" liegen, auch aus Patentschutzgründen keine Detail-Informationen offen vor. -- Die Fa. ESU, Ulm welche wohl maßgeblich an mfx mitgewirkt hat, vertreibt mit dem Produkt ECOS ein Produkt, welches auch das Protokoll mfx ausführen kann; dort wird dieses aber aus Schutzgünden M4 Protokoll genannt --

Man kann unter diesen Randbedingungen die Märklinsysteme als "geschlossene Systeme" einstufen.

Aufgrund dieser "Abschottung" entwickelte die Zubehörindustrie, wohl im Zusammenwirken mit anderen Modellbahnherstellern", das digitale System "DCC", welches genormt wurde und bei dem alle technischen Daten "offen liegen" und kostenlos einzusehen sind.

Die Fa. Trix, seinerzeit noch juristisch eigenständig, entwickelte zusammen mit industrieller Unterstützung das digitale System "Selectrix". Dieses System ist ebenfalls genormt und alle Informationen / Daten liegen offen vor.

• spezifische Entwicklungshintergründe

Märklin mit seinen Systemen als auch DCC wurden auf dem Hintergrund der "Spielzeugindustrie" entwickelt. Dies bedeutet, alle bisherigen Tasten, Schalter, Trafo - Funktionen sollten in eine Zentrale integriert werden. Die Peripherie, d.h. die Dekoder sollten so einfach und damit so preiswert als irgend möglich sein.

Die Anbindung an einen PC kam eigentlich erst später hinzu und stand nicht im Fokus der ersten Entwicklungen.

Somit lassen sich diese beiden Systeme als "zentralistische Systeme" definieren.

Bei der Entwicklung von Selectrix wurde, wohl durch die industriellen Erfahrungen mit verteilten Systemen, ein gänzlich anderer Ansatz gewählt. Im Selectrix-Verbund sollten auch die peripheren Komponenten soviel "Intelligenz" als irgend möglich besitzen, um ein "verteiltes System" aufbauen zu können. Dieser Ansatz erforderte auch ein komplett anderes Kommunikationssystem (Bussystem). Bei Selectrix kann jeder Busteilnehmer mit jedem anderen Daten / Informationen austauschen.

Dies ist bei den beiden vorgenannten Systemen nicht möglich, dort gibt es nur eine Richtung von der Zentrale zu den Dekodern (Peripherie);(ausgenommen das im Moment auf den Markt kommende RailCom Verfahren bei DCC > siehe weiter unten; als auch mfx hier gibt es eine Gegenrichtung Lokdekoder -> Zentrale).

Selectrix fällt damit in die Kategorie: "dezentrale oder verteilte Systeme" .

• ... und ihre Auswirkungen

Letztendlich ist es unter Berücksichtigung des vorgenannten nicht verwunderlich, daß sich ganz unterschiedliche Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-Seite als auch auf der Software-Seite in Form der Protokolle.

Während Selectrix mit einem Bussystem und einem Protokolltyp für Fahren, Schalten und Melden auskommt, werden bei DCC und Märklin jeweils 2 Bussysteme und Protokolltypen benötigt; eines für Fahren und Schalten und eines für Melden.

Werden bzw. sollen noch Handregler zur Steuerung der Anlage mit eingebunden werden, dann benötigt man bei Märklin bzw. DCC in aller Regel ein drittes Bus- und Protokoll- System; Selectrix hingegen benötigt kein weiteres Bussystem. Hinweis: ein Selectrix-Handregler kann immer nur zu einem Zeitpunkt auf einen der SX-Busse der Anlage zugreifen. Sollen andere SX Busse bedient werden, dann muß der Handregler umgesteckt oder mittels eines elektronischen Schalters umgeschaltet werden

• ... und die unterschiedliche, offen gelegten Bus-Systeme / Protokolle

--DCC

 Diese Protokoll (ohne RailCom) ist so gestaltet, daß man von einem "Standard-Anteil" und
 einem "offenen Anteil (Erweiterungen)" sprechen kann.
 Durch diesen gewählten Aufbau lassen von den einzelnen Herstellern relativ einfach spezifische
 Produktergänzungen in das System einfügen.
 Im Ergebnis ergibt dies unterschiedlich lange Protokolle und damit unterschiedlich lange
 Übertragungszeiten.

--Selectrix

 Das Selectrix Protokoll hat einen starren, festen Rahmen.
 Aus diesem Grunde ist auch jede Übertragunszeit gleich lang und es läßt sich daraus ableiten wie
 oft innerhalb eines Busses jeder Busteilnehmer innerhalb einer definierten Zeitperiode
 angesprochen wird.
 Die Flexibilität bei diesem Bussystem liegt darin, daß das Busprotokoll (einzelne Bit) selbst
 keiner Dekoder-Funktion zugeordnet ist.
 Die Funktion des einzelnen Bits ergibt sich aus dessen logischer Zuordnung zu der / Dekoder
 Funktion / Funktionen.
 So kann das gleiche Bit bei einem Dekoder als Ausgang "S" schalten interpretiert werden und beim
 anderen als Meldereingang "M" gesetzt werden > die Zentrale wertet dies dann aus.
 Wiederum kann das gleiche Bit ein Teil einer Bitkombination sein, die eine bestimmte Meldung
 übermittelt; z.B. Fahrstufe; etc.

System- und Kommunikations- Strukturen

zentralistische Systeme

• Fahren
• Schalten

Bei diesen (hier betrachteten) Systemen sind sowohl die Lok-Dekoder als auch alle anderen Dekoder zum Schalten (Anzeigen) über eine 2 adrige Verbindung -- z.B. Schiene / Gleis -- mit der Zentrale verbunden.

Von der Zentrale werden alle Einstellbefehle codiert über diesen Bus übermittelt.

Die jeweilge Spannung und ihre digitale Codierung ist zwischen den beiden Systemen DCC und Märklin sehr unterschiedlich. Nähere techn. Informationen über die Busse und ihre Protokolle können über die Links (unten) abgerufen werden.

Da die mir am Markt bekannten Dekoder zum Schalten / Anzeigen relativ einfach aufgebaut sind muß zum Schalten eines Ausgangs ein Befehl ausgegeben werden > Ausgang "ein" und nach einer Zeit t der Befehl > Ausgang "aus". Die Zeit t wird in der Zentrale verwaltet. Daraus folgt, jedes Schalten eines Magnetartikels erforddert 2 Busübertragungen Plus einer Zeitverarbeitung in der Zentrale.

• Melden

Diese Funktion wurde erst mit der Erweiterung der "PC-Steuerung" notwendig. Sie ist quasi das "Auge des Modellbahn-Steuerungsprogramms, hier von TrainController (TC).

Das Prinzip des Meldens ist die Erkennung eines Stromflusses, ausgelöst durch ein Fahrzeug, welches sich in einem Überwachungsbereich (Gleisabschnitt) befindet.

-- DCC

  Die Besetztmeldung / Erkennung basiert bei DCC auf der sog. "Strommessung".
  Hier wird der gesamte Strom eines Abschnittes über einen Besetztmelder (Dekoder) geführt.
  Fließt ein Strom weil sich ein Verbraucher (Lok oder Wagen mit Beleuchtung oder
  "Widerstandsachsen") auf dem Gleisabschnitt befindet, dann wird dies erkannt und über einen
  eigenen Meldebus mit eigenem Protokoll an die Zentrale gemeldet.

-- Märklin

  Die Besetztmeldung / Erkennung basiert bei Märklin aus der "Masse-Kontaktgabe". Diese historische
  Bezeichnung ist geblieben, obwohl man bei einem digitalen System nicht mehr von "Masse" sprechen
  kann.
  Der Mittelleiter ist an einen Ausgang von Zentrale bzw. Booster angeschlossen, der andere an
  einem der beiden Außengleise (Schienen).
  Steht ein Märklin (oder 3 Leiter-Fahrzeug) auf dem Gleis, dann verbinden die elektr. leitenden
  leitenden Achsen das an der Zentrale / Booster angeschlossene Gleis (Schiene) mit dem anderen
  Melde - Gleis (Schiene). Diese ist an einem Melde-Dekoder-Eingang angeschlossen.
  Somit liegt am Meldereingang das gleiche Potential wie bei der Zentrale / Booster.
  Über einen im Meldedekoder hochohmigen Widerstand kommt jetzt ein kleiner Stromfluß (mA)
  zustande, denn der Meldedekoder muß einen Anschluß besitzen auf dem sich das Mittelleiter- 
  Potential des Gleisabschnitts befindet; also es muß eine Verbindung zur Zentrale oder Booster
  bestehen.
  Letztendlich wird auch hier ein Stromfluß ausgewertet; im Gegensatz zu DCC ist dieser allerdings
  kleiner.  

Die beiden unterschiedlichen Ansätze brachten am Markt auch unterschiedliche Dekodertypen hervor. Diese sind jeweils über unterschiedliche Bussysteme mit der Zentrale verbunden.

Während bei Märklin der "S88" Bus sein muß, hängt es bei DCC davon ab, was die jeweilige Zentrale für einen Melde-Bus zur Verfügung stellt.

• Identifikation von Lok-/Fahrzeug- Adressen

--DCC

 Mit dem genormten Systemteil RailCom bringt die DCC Gemeinde derzeit ein Rückmeldesystem auf dem
 Markt, was nicht nur die Lok-Dekoder-Adresse melden soll, sondern noch umfangreichere sonstige
 Informationen.
 Unter OpenDCC findet der Leser hierzu eine umfangreiche Abhandlung.
 Im Prinzip basiert die Lösung auf folgendem Verfahren:
 Die Gleisspannung wird derzeit in regelmäßigen, sehr kurzen Abständen umgeschaltet, so daß
 die "Rechteckspannung" entsteht. In diesen Umschaltmomnet wird eine kurze Verzögerung eingefügt,
 damit ist das Gleis für eine Kurze Zeit von der Zentrale / Booster abgeschaltet > Spannungslos.
 Innerhalb dieser Zeitspanne kann jetzt ein Lokdekoder eine Meldung über die Gleise schicken,
 die dann von der Zentrale aufgenommen und ausgewertet werden muß.
 Der Lokdekoder muß zur Spannungspeicherung einen größeren Kondensator besitzen, der in dieser
 Zeitspanne das Senden ermöglicht.

 Es bleibt abzuwarten, wie sich dieses Verfahren und die damit verbundenen Komponenten im
 Modellbahn-Alltag bei Mittelgroßen Anlagen bewähren.

--Märklin

 Mit mfx (M4) hat Märklin ein Meldesystem eingeführt. Dieses hat allerdings eine ganz andere
 Funktion als das unter DCC vorgestellt und das noch unter Selectrix vorzustellende Verfahren.
 Bei Märklin melden sich die Loks mit ihrer Lokdekoder-Adresse beim Aufsetzen automatisch bei 
 der Zentrale an. Die Zentrale ordnet dieser Lokdekoder-Adresse eine "Modellbahn-Lok-Adresse" zu.
 Es findet also keine Identifikation über den Standort des Fahrzeuges (Lok) auf der Anlage statt.

dezentrale Systeme

In diesem Beitrag wird in diesem Abschnitt nur das Selectrix-System betrachtet.

Grundsätzlich wird das Gleis über zwei Leitungen an die Zentrale oder einen Booster angeschlossen. Über diese Leitungen erfolgt, wie bei den beiden anderen Systemen auch, die elektrische Versorgung des Lokdekoders und des Lok-Motors als auch die Busübermittlung. Wie bei DCC wird auch hier die Polarität in sehr kurzen Zeitspannen zur Erzeugung einer "Rechteckspannung" umgeschaltet. Das Protokoll ist allerdings unterschiedlich zu DCC, als auch Märklin. Booster werden über den sog. MX-Bus mit der Zentrale verbunden.

• Fahren
• Schalten
• Melden

Aus Sicht der Zentrale ist das Gleis ein Teil des SX 0 - Busses. Und nur an einem SX 0 Bus kann ein Lok-Dekoder (Fahren) angeschaltet werden !!

Alle anderen SX - Dekoder (Schalten, Melden) können wahlfrei über einen der beiden SX 0 oder SX 1 Bus mit der Zentrale verbunden sein. Beide Busse sind vollkommen identisch aufgebaut.

Über diese Busse werden auch die logischen Schaltkreise der Dekoder versorgt !!, während Spannungen zum Schalten, etc. separat dem Dekoder zuzuführen sind.

Beim Schalten zeigt sich -- im Gegensatz zu DCC und Märklin -- ein großer Unterschied. Soll bei SX z.B. eine Weiche geschaltet werden, dann setzt die Zentrale an den Dekoder nur eine Meldung ab mit dem Inhalt > Weiche schalten und die Weichenstellung. Der Dekoder übernimmt das einschalten des Magnetartikels (Spule) und beachtet die Einschaltdauer (Stromflußdauer) und schaltet dann den Magnetartikel wieder aus. Aus Sicht der Zentrale ist dies pro Schaltvorgang eine 50% Busentlastung und eine starke Entlastung bei der Zeitverfolgung (Einschaltdauer des Magnetartikels).

Das Prinzip des Meldens ist das gleiche wie bei DCC. Wobei der Meldedekoder hier an einen der SX-Busse angeschlossen und mit der Zentrale verbunden ist.

Wollen Märklinisten allerdings -- wie ich selbst SX verwenden --, dann steht ihnen aufgrund des 3 Leitergleises auch die "Märklin-Variante" zusätzlich zur Verfügung. Wie unter Märklin dargestellt, kann vom "Melde-Gleis (Schiene)" eine Verbindung zum SX-Melder-Eingang geführt werden. In diese Verbindung muß der Nutzer allerdings selbst einen z.B. 10 k Ohm Widerstand einfügen. Damit funktioniert eine "Masse-Kontakt" Meldung wie zuvor beschrieben.

• Identifikation von Lok-/Fahrzeug- Adressen

Diese Identifikations-Methode ist etwas "tricki".

Wie bei DCC wechselt auch bei SX das Gleispotential an den Schienen. Hierbei entsteht eine kleine Spannungslücke -- während diese bei DCC sehr viel größer sein muß !!

In dieser kurzen Phase entlädt sich ein kleiner Kondensator, der sich auf dem Lok-Dekoder befindet über die Schienen und den an der Schiene angeschlossenen Meldereingang und von dort zum Booster / Zentrale und wieder zurück zum Gleis / Schiene > Lok.

Der hierbei entstehende kleine Stromfluß (bei SX I ca. 1-2 mA; bei SX II ca. 5 mA) wird vom Melder erkannt und ausgewertet.

Wie erfolgt nun die Zuordnung zur Lok-Dekoder-Adresse ??

Da bei SX alle am Bus angeschlossenen Adressen regelmäßig angesprochen werden UND alle Dekoder "mithören" können, registriert (merkt sich) der "intelligente" SX-Melder die jeweils gesendete Lok-Adresse. Folgt jetzt unmittelbar in seinem Beobachtungs (Melde-) Abschnitt eine Kondensatorentladung, dann kann er die Lokadresse diesem Abschnitt zuordnen, was z.B. bei TC (TrainController) einem Block entspricht.

Hinweis: Soll die SX-Identifikation eingesetzt werden, dann müssen nach SX-Angabe alle in Lok und Wagen vorhandenen Birnchen / LEDs auf einer Seite über eine schnell schaltende Diode verbunden werden. Diese Diode verhindert "Querströme" die bei der Kondensatorentladung auftreten würden und dann könnte keine saubere Erkennung erfolgen. Wenn Märklinisten SX und seine Melder einsetzen (s. oben), dann muß aus solchen Gründen auch eine Diode in Serie zum Widerstand gechaltet werden.

Im Vergleich zu Märklin wird beim Aufgleisen auch die Lok erkannt UND der Standort. Beim Vergleich zu DCC fällt auf, daß das DCC Meldesystem sehr viel weiter ausgebaut ist als das von SX.

DCC als "zentrales System" im Verbund mit dem DCC-Meldeverfahren RailCom könnte dazu neigen, daß auf mittelgroßen Anlagen die zeitliche Auslastung für die Steuerung mittels PC-Modellbahn-Steuerungsprogrammen zu Problemen führt.

Auf der anderen Seite, die heutigen, modernen PC-Modellbahn-Steueruungsprogramme, wie TC, benötigen keine solche Identifikation für den laufenden Betrieb der Anlage.

Multiprotokoll-Zentrale und Dekoder

Auf dem Markt werden zunehmend mehr Multiprotokoll Dekoder und Zentralen angeboten. Dies ist wohl primär als Marketing Instrument der Hersteller zu sehen, als auch ein Instrument beim "Verteilungskampf" von Marktanteilen.

In den wenigsten Fällen werden private Modellbahner (außer Clubs) eine Vielzahl und Vielfallt von Modellbahnen (Loks) besitzen. Auch wenn dies hier und da der Fall sein sollte, dann wäre ein Dekoder-Umbau auch eine gute Alternative zu einer "Multiprotokoll-Anlage".

Einsatz auf Modellbahn-Anlagen

Labor v.s. Anlage

Es wird keinen Zweifel geben, daß diese Multiprotokoll-Systeme in den Labors der einzelnen Hersteller einwandfrei arbeiten.

Auf den unterschiedlichen Anlagen, insbesondere auf mittelgroßen und dies im Zusammenwirken mit PC-Anlagen-Steuerungsprogrammen, wie TC, kann es zu zeitlichen Problemen bei der Abarbeitung der Steuerbefehle / Melderabfragen kommen.

Dies insbesondere dann, wenn zentralistische Systeme wie DCC und Märklin mit komplett unterschiedlichen Gleis-Signalen / Busprotokollen zusammen als Multiprotokoll - System betrieben werden.

Beispiel >> Schalten

• Aufgabe

Schalten einer Weiche von TC heraus.

• Lösung: Märklin / DCC

TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.

Die Zentrale muß diese Meldung aufnehmen und in drei Aktionen zerlegen ..

1) Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) einzuschalten (Stromfluß > Magnetartikel Spule) 2) Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist 3) Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auszuschalten (kein Stromfluß > Magnetartikel Spule)

TC sollte in dieser Zeitspanne KEINE weiteren z.B. Weichenbefehle an die Zentrale senden. D.h. in TC ist eine entsprechende "Wartezeit" einzutragen, diese sollte größer sein als die unter 2) eingestellte Zeitdauer plus Reserve.

Diese Reserve wird in der Praxis benötigt, da nicht davon auszugehen ist, daß eine Busübertragung nicht mal wegen Störungen wiederholt werden muß.

Es können auch sonstige Aktivitäten "dazwischen kommen".

• Lösung: Selectrix

TC sendet über den Bus PC <> Zentrale eine Meldung zum Schalten der Weiche x in Stellung r.

Die Zentrale muß diese Meldung aufnehmen und in eine Aktionen zerlegen .. 1) Meldung an zugehörigen Weichendekoder senden mit dem Inhalt Ausgang (= Weiche x) auf Stellung r zu schalten.

Der SX-Weichendekoder nimmt diese Meldung auf und zerlegt diese in die Aktionen ....

1) Ausgang (= Weiche x) einschalten (Stromfluß > Magnetartikel Spule) 2) Zeit für Dauer der Einschaltung der Spule setzen und abfragen, wann diese abgelaufen ist 3) Ausgang (= Weiche x) ausschalten (kein Stromfluß > Magnetartikel Spule)

TC sollte in der Zeit, in der die Zentrale beschäftigt ist, keine weiteren Weichenbefehle senden. Im Vergleich zum vorrangegangenen Systemansatz ist diese Belegung aber wesentlich kürzer.

Somit steht in TC auch nur eine sehr kurze "Wartezeit". TC kann also in einer wesentlicher höheren Sequenz Aktionen (z.B. Weichen schalten) ausführen, da sowohl die Auslastung der Zentrale als auch der Anlagenbusse pro Aktion sehr viel geringer ist.

Beispiel >> Fahren / Multiprotokolle

Wird mit unterschiedlichen Protokollen gefahren, das geschieht bei Märklin bereits, wenn Motorola I / II und mfx (M4) eingesetzt wird, dann muß die Zentrale jeweils komplett die Gleistakte ändern als auch das Protokoll. Das alle kostet Zeit. Bei manuellem Betrieb von zwei Loks sicher kein Problem, jedoch mit z.B. TC und 15 Loks kann es zu welchen kommen (wobei die Zahlen nur die Unterschiede verdeutlichen sollen und keine absoluten Werte darstellen).

Entsprechendes gilt, wenn der Lok-Dekoder mit mehreren Protokollen betrieben werden kann. Dann muß der die entsprechende "Vorauswahl" treffen. Auch das kostet Zeit.

In all diesen Fällen, kann es -- wie die vielen Anfragen im TC-Forum zeigen -- unter den unterschiedlichsten Randbedingungen zu Problemen kommen.

Ich halte diese Multiprotokoll-Systeme für nicht sonderlich gut geeignet für PC gesteuerte Modellbahnanlagen.

Zusammenwirken mit dem Software Programm TrainController (TC)

TC kann, so zeigt es auch die weltweite Verbreitung mit sehr vielen Zentralen zusammenarbeiten. Mittels der Vielfalt der Einstellungsmöglichkeiten können auch einige zeitliche Probleme "umgangen" werden.

Sollten Funktionen nicht so ablaufen wie erwartet, so zeigt sich aufgrund des TC Forums, daß in aller Regel der Engpaß in der Hardware und bei den System- Lieferanten zu suchen ist.

Produktanbieter / Quellen

--Jens Mohr; 82275 Emmering (bei München); www.jens-mohr.com 09:40, 17. Jul. 2011 (UTC)