Als kleines Spaßprojekt hab ich mal probiert, ob man ISDN ohne irgendwelche Spezial-ICs an nen AVR hängen kann und mir nen kleinen ISDN-Sniffer gebaut, der das Audiosignal vom B-Kanal 1 via PWM ausgibt. Man braucht eigtl. nur zwei 0815-Komparatoren aus der Bastelkiste. Ein kleines Demo-Video gibts hier: http://verbosemo.de/~hunz/avr_isdn/avr_isdn.m4v Sourcecode (Mega8, 16MHz, asm) gibts hier: https://github.com/znuh/unsorted/tree/master/isdn Die Anbindung an den S0-Bus ist als png angehängt. Das ganze ist nur als proof of concept / Spielerei gedacht, daher: - ist Senden nicht implementiert - gibts keinen richtigen Protokollstack, es werden immer Datenframes angenommen und die beiden B1-Kanal Bytes (2 pro frame) aufs PWM gegeben - nur NT->TE Richtung ist angebunden, TE->NT Richtung müsste man extra anschliessen und auswerten, die hört man also nicht Zur Funktionsweise: R1-R4 bilden einen Spannungsteiler, der 5V Vcc in Vref=2.5V, Vref_hi= Vref+0.44 und Vref_lo=Vref-0.44V teilt. Das differntielle S0-Signal wird kapazitiv eingekoppelt (Polarität hier egal) - ein Ende über 100nF auf GND, das andere Ende über 100nF und 1k nach Vref. C6 dient zur Stabilisierung von Vref. Zwischen C2 und R5 bekommt man dann als Signal Vref +-x (x ca. 0.8V). Das wird auf 2 Komparatoren gegeben und mit Vref_hi/lo verglichen. D1 schützt die Komparatoreingänge falls es mal unter GND geht. Komparator A ist invertiert beschaltet, der zweite nicht-invertiert. Resultat ist, dass AVR_INTA oder AVR_INTB low wird wenn die Spannungsdifferenz zwischen den S0-Leitungen über Referenzwert+Hysterese liegt. Je nach Polarität schaltet einer der beiden Ausgänge durch und triggert den Interrupt im AVR. Die Komparatorausgänge kann man nicht einfach als OR zusammenschalten, wegen der Framesynchronisation über Coderegelverletzungen. Die Software muss das erkennen wenn hintereinander 2x derselbe Komparator durchschaltet. Die Daten liegen am S0-Bus mit der inversen AMI-Codierung vor, d.h. Spannungsdifferenz -> logische '0', keine Spannungsdifferenz -> logische '1'. Um Gleichspannungsfreiheit zu garantieren wechselt die Polarität der Differenz für logischen '0' ständig. Logische '0' ohne Polaritätswechsel ist die bereits erwähnte Coderegelverletzung. Der Code im AVR ist relativ simpel - er wartet einfach auf zweimal '0' mit gleicher Polarität (L vom letzten + F vom neuen Frame). Direkt danach muss wieder ne '0' mit inverser Polarität kommen (L). Näher ist das z.B. hier http://www.virtualuniversity.ch/telekom/telefon/7.html oder hier http://wwwlehre.dhbw-stuttgart.de/~schulte/digiisdn.htm beschrieben. Danach kommt beim ersten '0'-Datenbit nochmal ne Coderegelverletzung die man ignorieren muss. '0'-Datenbits werden über die INT0/1 Interrupts erkannt. Da bei mehreren '1'-Bits keine Flanken von den Komparatoren kommen, lassen sich die nicht mit INT0/1 erkennen. Dafür wird mithilfe des T0-Überlaufs abgetastet. Wenn eine Flanke kommt, wird T0 für das nächste Bit scharf gemacht. Wenn vor dem Überlauf eine Flanke kommt, wird die von INT0/1 erkannt und als '0'-Datenbit erkannt, ansonsten läuft T0 über und ne '1' wird ins Schieberegister geworfen. Die Datenbytes vom B-Kanal 1 sind jeweils an Position 3-10 und 27-34 (siehe hier: http://www.rhyshaden.com/isdn.htm). Im AVR-Code läuft daher ein Bitcounter mit. Wenn der 10 oder 34 anzeigt liegt ein neues PCM-Byte von B1 vor. Zwischen 2 solchen vergehen genau 125µs, was genau der 8kHz Samplerate von ISDN entspricht. Da die Daten a-law codiert sind, werden die vorher über ne LUT umgewandelt und dann an den 9-Bit PWM verfüttert. An den PWM-Ausgang hab ich noch den Chebychev-lowpass aus der AVR-appnote AVR335 (http://www.atmel.com/atmel/acrobat/doc1456.pdf) gehängt. Der ASM-Code kann die Daten auch via UART an PC senden. Da sollte man dann aber nen 14.47MHz Quarz nehmen damit man 115.2kBaud sauber schafft. Die Daten kann man dann auch mit sox am PC (in besserer Qualität) abspielen. Bei Fragen einfach antworten!
Angehängte Dateien:
-
avr_isdn.png
6,7 KB
:
Verschoben durch User
Super Projekt! Da steckt ne ganze Menge KowHow drin. Respekt. Leider ist ja ISDN eher am aussterben daher stellt sich wohl die Sinnfrage. Wie lange hast du daran gebastelt?
Hat so ca. vier Tage gedauert. Ausgangsgedanke war, wenn low-speed USB geht muss ISDN auch gehen. Komparatorteil ging recht schnell, ASM-code hat so 2-3 Tage gedauert bis der tat was er sollte.
Respekt. Ja so einfach ist das eigentlich alles...nur muss man erstmal drauf kommen. Die Sinnfrage stellt sich mir hier gar nicht, einfach deswegen weil es eine attraktive Umsetzung wegen der Einfachheit ist. Einfache Lösungen sind immer die Schönsten.
Hallo, ich bin auch sehr von dem Video angetan und bitte weiter machen ! Evtl. können auch teile des Protokollstacks in "C" geschrieben werden ? Ist auch ein auslesen des D-Kanals denkbar ? .
Timmo H. schrieb: > Die Sinnfrage stellt sich mir hier gar nicht, einfach deswegen weil es > eine attraktive Umsetzung wegen der Einfachheit ist. Einfache Lösungen > sind immer die Schönsten. Danke! :-) Einfache Lösungen mag ich auch der Schönheit wegen, daher war das war auch meine Intention. Uwe S. schrieb: > ich bin auch sehr von dem Video angetan und bitte weiter machen ! Leider werde ich das nicht weitermachen. (zu viel andere Projekte, das übliche...) Es sind zwar einige Anwendungsszenrien denkbar, aber ich hab keines, das ich gerne realisieren würde. War eben in erster Linie als kleiner Versuch gedacht. Eine brauchbare Implementierung mit mehr Funktionen braucht sicher ein wenig Zeit+Geduld. Würde mich aber natürlich sehr freuen wenn jemand hier Lust hat damit weiterzubasteln, deswegen wollte ich das auch hier dokumentieren. > Evtl. können auch teile des Protokollstacks in "C" geschrieben werden ? Das geht sicherlich. Viel Zeit hat man zwischen 2 Bits allerdings nicht - 83 Takte bei 16MHz, wobei der aktuelle Code schon recht viel davon in den ISRs verbrät. Müsste man also auf jeden Fall im non-ISR-Kontext realisieren, oder einen Tiny fürs lowlevel und einen größeren via SPI/UART dranflanschen für die hilevel-Sachen, oder oder oder ;) > Ist auch ein auslesen des D-Kanals denkbar ? Ja, das geht sogar recht einfach. In jedem frame gibts 4 D-Kanal-Bits, die Positionen findet man z.B. hier: http://www.rhyshaden.com/isdn.htm Müsste man also so ändern, dass die D-Kanal-Bits statt den B-Kanal ausgewertet werden.
Beeindruckend und anregend. Ich möchte Dir meine Anerkennung für dieses Projekt aussprechen.
Beeindruckend. Das Teil kann man ja jetzt schon einsetzen als Mithörverstärker. Wenn jetzt noch Senden und Anrufe gehen, (Ja der Protokollstapel bei ISDN ist nicht so einfach) dann würde das neue Anwendungsgebiete eröffnen. Man könnte dann einfach einen Mikrocontroller an eine normale Telefonleitung hängen und damit kommunizieren.
Da ich mich vor einiger Zeit mal mit ISDN intensiv beschäftigt habe, kann ich nur den Hut ziehen. Bei mir hatte damals ein Chipsatz von Siemens HSCX (B-Kanal) und ISAC (D-Kanal/Sync) die meiste Arbeit übernommen. Damals ist aber eine Interessante Idee entstanden: Mit dem damals neuen Euro-ISDN (1TR6 kennt heut eh keiner mehr) war es möglich bei jeder Anruf-Iniziierung ein paar zusätzliche Bytes (ich glaube es waren so um 33 Bytes) zu Übertragen. Diese "SUB-Information" (Eigentlich SUB-Addressing) wurde dann zum Chatten benutzt. Einen lustigen Namen hatten wir auch dafür: SUB-Raum-Nachrichten (Subspace-Message) frei nach Star-Trek ;-) Ich weiß, bei 33 Bytes gähnt jetzt so mancher, aber damals zur Post-Monopol-Zeit kostet ein Ferngespräch noch rchtig Geld. Für eine Kommunikation zwischen zwei uCs übers ISDN könnte es aber durchaus heute noch interessant sein. Sam
ich denke das ISDN noch eine Zeit überleben wird, trotz IP-Telefonie. Ich will mein Telefon nicht abhängig vom Internet machen.
Hi! xurpcha schrieb: > Hallo! > > Wie schwierig wäre es dann ISDN signal slebst zu generieren? Ja das ist ne gute Frage. Auf jeden Fall nicht so einfach wie Empfangen. Zum Einen weil man sich vorher überlegen muss, was man eigtl. senden will - womit wir wieder beim Protokollstack wären. Zum Andern, weil das timing kritischer ist - beim Abtasten hat man einige Toleranz, die ist beim Senden einiges geringer. Müsste man sich überlegen, wie man das realisiert. Vielleicht über ne compare unit. Evtl. auch das Empfangstiming verbessern, indem man die Zeitpunkte der Flanken via ICP misst. Wenn die Referenz nicht genau genug ist, bringt hardware compare auch nicht mehr so viel. Wenn ich das richtig verstehe, kommt das timing von NT->TE und TE->NT erfolgt darauf synchronisiert mit 2 Bit Versatz (http://www.virtualuniversity.ch/telekom/telefon/7.html) - wieviel Toleranz man da hat steht sicher in irgendeiner Norm. Ein weiteres Problem ist, dass bei 16MHz/192kHz der AVR langsam wegdriftet. Wirkt sich beim Empfangen nicht so aus (weniger als 1/5tel Bit am Frameende) - zumal der Code an jeder Flanke nachsynchronisiert, beim Senden will man das aber vielleicht genauer. Kann man aber vmutl. auch beim Senden kompensieren oder halt nen passenderen Quarz nehmen. Die ersten Schritte wären vielleicht, erstmal sowohl NT->TE und TE->NT mitzuschneiden, einen eingehenden Anruf zu tätigen, den entgegenzunehmen und dann die Daten analysieren um zu verstehen was da alles passiert. (Ist so zumindest interessanter, als die passende Norm zu lesen ;)) Und dann versuchen als ersten Schritt mal ein TE zu bauen, das einfach nur den Anruf annehmen kann oderso. Also Senden wäre schon cool, ich würde da auch mitbasteln. Nur alleine hab ich nicht genug Zeit+Motivation. Ich werde aber mal NT->TE und TE->NT während eines eingehenden Anrufs mitschneiden um mal zu sehen, wie das timing von nem realen TE aussieht. Wenn Interesse besteht, könnte ich beide Richtungen auch mal während Klingeln/Setup mitschneiden, dass man mal am Beispiel nachvollziehen kann, was da alles passiert.
@Hunz Wie kritisch wird wohl die Hysterese sein? Ich rechne etwa 100mV aus. Ist das so über den Daumen gepeilt und hat auf Anhieb funktioniert oder hat ein geringerer Wert erstmal nicht funktioniert?
Huch schrieb: > @Hunz > > Wie kritisch wird wohl die Hysterese sein? Ich rechne etwa 100mV aus. > Ist das so über den Daumen gepeilt und hat auf Anhieb funktioniert oder > hat ein geringerer Wert erstmal nicht funktioniert? pi*Daumen "berechnet" ;-) Ist nicht so kritisch denke ich, sollte sowohl nach oben, als auch unten Luft sein. Hatte auch schon 1M als Feedback drin.
Angehängte Dateien:
-
S0_interface.png
3,1 KB -
S0_interface.jpg
64 KB -
S0-Frame1.jpg
33 KB -
S0-Frame2.jpg
39 KB
Hallo Benedikt, hallo Community, nachdem ich mich nun fast 19 Jahre mit ISDN-Protokollen und den dazugehörigen elektrischen Schnittstellen beschäftige, muss ich positiv überrascht sagen, dass mir bislang keine so krasse Anschaltung an einen S0-Bus bekannt war. Bei meinen beiden privaten ISDN-Projekten habe ich immer mit ISAC-S PEB2085/2086 bzw. ISAC-S/TE PSB2186 gearbeitet. In der Idee einer direkten Anschaltung an den AVR liegt Potential, welches ich gerne ein Stück weit mit entwickeln möchte. Heute habe ich mich mit der Hardware (S0 <--> AVR) ein wenig näher beschäftigt. Herausgekommen ist eine sehr einfache, aber komplett andere Lösung. Der Software-Teil steht erst in den kommenden Tagen auf meiner Agenda. Deshalb kann ich leider noch nicht sagen, ob dieses Interface überhaupt bzw. mit der Software von Benedikt funktioniert. Die Oszillogramme sehen aber recht brauchbar aus. Den Hauptvorteil dieser Lösung sehe ich in der sicheren galvanischen Trennung zum Telekommunikationsnetz. Gerade bei der direkten Anschaltung an das NTBA bzw. an TK-Anlagen mit gespeisten S0-Bussen lässt sich kein sicherer Bezug zum Erdpotential (PC & STK500) definieren bzw. herstellen. Bei einer ähnlichen Aktion hätte ich fast mal ein STK500 in den Himmel befördert. Neben diesem Sicherheitsaspekt könnten Masseschleifen zum Brummen führen, was sich nicht unerheblich auf die Signalqualität auswirken würde. Deshalb kam für mich nur eine Trennung mit einem Übertrager in Frage. Die Beschaffung war recht einfach - im Schrott liegt jetzt ein NTBA weniger. Passende Übertrager (z.B. L4097-X029) von VAC (Vacuumschmelze) werden millionenfach in NTBA's verbaut. Je NTBA sind 2 einzelne (z.B. L4097-X029) oder ein doppelter Übertrager (z.B. L5054-X005) enthalten. Prinzipiell funktioniert die Schaltung mit jedem Übertrager der auf der S/T-Controllerseite eine Mittelanzapfung (L4097-X029) oder zwei einzelne Wicklungen (L5054-X005) hat. Ein L5051-X005 von einer alten ISDN-Karte kann deshalb leider nicht verwendet werden. Der Rest der Schaltung braucht wohl nicht weiter erläutert zu werden. Im Endeffekt steht nun das ternäre Signal vom S0-Bus auf 2 Pins zur binären Verarbeitung im AVR zur Verfügung. Als Beweis noch zwei Fotos von meinem Oszilloskop und ein Bild vom Versuchsaufbau. Die Amplitudenverläufe in den Oszillogrammen sind nicht maßstabgerecht. Durch das Übertragungsverhältnis von 2:1 im TR1 liegen an R1 und R2 bei einem aktiven Pulse mehr als 1V an. T1 und T2 haben damit genug Reserve um sicher durchzuschalten. Soviel zunächst zum Thema alternative Hardware. In den kommenden Tagen werde ich mal schauen welche Ideen mir bei der Software so in den Kopf kommen. Gruß Jens
Angehängte Dateien:
-
S0-Rahmenstruktur.png
26 KB -
STLS2.jpg
11 KB
Nochmal hallo, vielleicht ist dies ein guter Zeitpunkt, die Realisierbarkeit von einigen Ideen in diesem Beitrag zu betrachten. Es geht also um die Anschaltung von eigenen Mikrocontroller-Projekten (AVR) an die ISDN-Welt. Nun ja, da würde ich (nachrichtentechnisch korrekt) wie folgt unterscheiden: 1.1 Monitoring B-Kanal Das Empfangen von Informationen (B1-Kanal, NT-->TE) mit einfachen Mitteln wurde hier bereits eindrucksvoll dargestellt. Für das 'Belauschen' des Nutzkanals der Gegenrichtung (TE-->NT) ist noch etwas zusätzlicher Aufwand erforderlich. Neben der zusätzlichen Eingangsschaltung müssten am AVR zwei weitere Signale ausgewertet werden. Der Takt für Abtastung steht bereits durch die Rückgewinnung aus der Richtung (NT-->TE) zur Verfügung. Weitere Interrupts für die Synchronisation sind also nicht erforderlich. Der Offset innerhalb des Frames von 2 Bit ist zu beachten. Das Signal könnte über einen 2. PWM-Channel oder durch Mischung mit der Richtung NT-->TE (ggf. Anpassung LUT) nach draußen gelangen. 1.2 Monitoring D-Kanal Die eingesetzte Minimalhardware hat hier gegenüber Lösungen mit ISAC-S(/TE) sogar einen gewaltigen Vorteil. Um beide Richtungen des D-Kanals zu erfassen genügt das Aufzeichnen der Daten aus der Richtung NT-->TE. Die D-Kanal-Daten der Richtung TE-->NT werden als E-Bits im Frame NT-->TE gespiegelt eingesetzt. Zusätzliche Hardware ist für das Monitoring beider D-Kanal-Richtungen also nicht erforderlich. Mit einem ISAC-S(/TE) kommt man nicht an die E-Bits ran und würde zum Monitoren immer einen 2. Controller für die Gegenrichtung benötigen. Mit den D-Kanal-Daten verfügt man über alle verbindungsbezogenen Informationen. Für einen Call-Monitor stehen beispielsweise im Layer3-SETUP die called party number (CDPN, angerufene MSN bzw. DDI) und die calling party number (CGPN, Nr. des Anrufers) zur Verfügung. Bei abgehenden Verbindungen wird im Layer3-CONNECT in der Regel Datum und Zeit zur TE (leider nur minutengenau) übertragen. Dies kann z.B. gut man zur Zeitsynchronisation des Mikrocontrollers verwenden. Der D-Kanal bietet damit genug Informationen für die ganz private Vorratsdatenspeicherung. 2. Simulation TE (Endgerät) Autsch! Schwierig ... persönlich halte ich dies mit einem aktellen AVR-Controller für nicht realisierbar. Ich lasse mich aber gerne für neue Ideen begeistern! ISDN (S0-Bus) nutzt in Layer1 ein vollsynchrones Übertragungsmodell, es arbeitet vollduplex und ist als Point-to-Multipoint designed. USB (low speed) ist zwar schneller, arbeitet aber halbduplex, Point-to-Point und nur innerhalb der übertragenen Nachricht bitsynchron. 3. Simulation NT (Network) Autsch! Auch das bitsynchrone Senden von dieser Seite halte ich mit einem AVR-Controller für nicht machbar. Für Punkt 2 und 3 stellt sich spätestens an dieser Stelle die Frage nach dem Sinn. Selbst wenn man Layer1 bitsynchron hinbekommt, muss man sich der 'Herausforderungen' in Layer2 und Layer3 (D-Kanal) noch stellen. Sollte man wirklich soweit kommen, einen protokollkonformen(!) Verbindungsauf- und abbau zu realisieren, ist immer noch nicht ein Bit an Nutzdaten (B-Kanal) geflossen. Hier wäre entweder noch ein Codec (z.B. G.711 A-Law) über LUT zu implementieren oder ein weiterer Protokollstack (z.B. X.75, PPP, ...) zu bauen. Möglicherweise kann man auch alles (incl. des AVR-Core) via VHDL in einen FPGA kippen. Freiwillige vor! Dies dann hätte allerdings nichts mehr mit einer genial einfachen Lösung zu tun. Wer sich unbedingt mit der Simulation von TE oder NT beschäftigen will, dem empfehle ich das Reengineering einer S0-Interface-Karte aus einer alten TK-Anlage. Alle notwendigen Komponenten (Übertrager, ISAC-S, Takterzeugung, ...) sind hier bereits vorhanden. Der ISAC-S erledigt das komplette Layer1-Handling, sowie einen Teil von Layer2 (auto mode). Ab Layer3 muss man sich dann selbst um die Nachrichten im D-Kanal kümmern. In der Bucht kann man so etwas ab ca. 20 EUR 'angeln'. Als Beispiel seien hier die S0-Interface-Karten STLS2 bzw. STLS4 der Fa. SIEMENS genannt. Na dann bin ich mal gespannt wie das hier weitergeht! Gruß Jens
Hallo Jens und Mitleser, ich bin auch an mehr und ausführlichen Informationen zu ISDN interessiert, leider arbeite ich nicht in der TK Branche und kann auf ISDN Ebene (Protokoll) nicht helfen. Hardware Design, HF-Design und Programmierung, sowie Mathematik/ Informatik und Algorithmen liegen mir da schon eher. .
Wenn man keine Lust zum "frickeln" hat, kann man den Teles LCR (Bild 1) neu programmierien. Alles auf der Platine. Jedoch kein AVR, sondern der gute alte 8051. Wer doch löten will, kann sich mit alten ISDN-Karten das Basteln etwas einfacher machen. Habe mal 2 Beispiele (Bild 2 und 3) angehängt.
@baltic: Wo hast Du denn das Datenblatt für den Übertrager her? Ich habe mich gerade nach dem Datenblatt des L4096-X022 blutig gegoogled - nichts gefunden... Der scheint allerdings ähnlich zu sein. Mit einem 18.432MHz Quarz stehen einem 96 Takte pro Bit zur Verfügung. Das ist sportlich, halte ich aber in ASM nicht für unlösbar. Die Syncronisierung und der Bitaustausch, Prüfsummen und die beiden B-Kanäle machen mir dabei eigentlich keine Sorgen. Meine größte Sorge ist der D-Kanal. Was mir vor allem fehlt sind die Beschreibungen der D-Kanal-Protokolle. Hast Du Infos darüber, wie die Daten darin verpackt werden? Gruß Jobst
Für ISDN findest du diverse Informationen in Netz, vor allem bei der ETSI und ITU. Hier mal ein Link auf die I.430 welche den Basic Rate Layer 1 beschreibt: http://www.itu.int/rec/T-REC-I.430-199511-I/en Für ISDN Chips würde ich Cologne Chip gegenüber den "Siemens" ISACs usw. vorziehen. http://www.colognechip.com/isdn/controllers/frame-datasheets.htm In den Datasheets von Cologne Chip findest du auch einieges an Informationen zu den Protokollen, Trafos, usw. Schön ist auch die Receive Schaltung von Cologne Chip. Die habe da eine relativ Einfache Lösung gefunden um das in "Digitale Chips" zu implementieren. Am ADJ_X Ausgang können Sie durhc ein PWM Signal die Levels der Empfänger beeinflussen. Der einfachste Baustein ist wohl der HFC-S mini, der XHFC-1SU ist etwas ausführlicher dokumentiert. Gruss
Angehängte Dateien:
-
Clock_S0_Layer1-INFO0.jpg
24 KB -
Clock_S0_Layer1-INFO4.jpg
24 KB
Hallo, das Datenblatt für den L4097-X029 habe ich schon ein paar Jahre. Bei VAC lassen sich scheinbar nur aktuelle Produkte als Datenblatt downloaden. Neben VAC (z.B. http://www.vacuumschmelze.de/index.php?id=992) sind mir noch EPCOS (z.B. http://www.epcos.com/inf/30/db/ind_2008/s0_p6622.pdf) und Vogt/Sumida (z.B. http://www.sumida-eu.com/de/produkte/2/21/13.html) bekannt. Sicher gibt es haufenweise mehr. Alternativ zu den von mir favorisieren L4097-X029 habe ich in etwas neueren NTBA (Bj. ca. 2004, größeres weißes Gehäuse, nur eine LED) Übertrager vom Typ VAC 22100 bzw. EPCOS 21700 gefunden. Sie sehen dem L4097-X29 verdammt ähnlich und müssten auf Grund der im NTBA verbauten Chipsätze (Infineon PEB2080/PEB2090x, Infineon PEF80902, ALCATEL/Mietec MTC20277), alle mit 2:2:1:1 Übertragern, auch funktionieren. Auf dem Breadboard kann ich sie jedenfalls problemlos gegen den L4097-X029 austauschen. Informationen zum Aufbau von ISDN-Protokollen findet man bei der ITU-T (http://www.itu.int/publications/sector.aspx?lang=en§or=2) bzw. bei der ETSI (http://www.etsi.org/WebSite/Standards/Standard.aspx). Hier ein paar ausgewählte Links: D-Kanal Layer 1 (BRI/S0) http://www.itu.int/rec/T-REC-I.430/en D-Kanal Layer 2 http://www.itu.int/rec/T-REC-Q.921/en D-Kanal Layer 3 (basic call control) http://www.itu.int/rec/T-REC-Q.931/en B-Kanal Voice Codec (G.711) http://www.itu.int/rec/T-REC-G.711-198811-I/en Ich habe gerade begonnen, mir über die Software ein paar Gedanken zu machen. Bei der Taktfrequenz für den AVR habe ich mich ebenfalls für 18,432 MHz entschieden. Die sportliche Herausforderung von 96 Takten zwischen den Bits habe ich auch schon erkannt. Da wird wohl etwas Inline-ASM erforderlich werden. Bis jetzt läuft bei mir nur die Synchronisation auf den Bittakt des S0-Busses. Im Anhang zwei Bilder vom Frequenzzähler, einmal mit deaktivierten S0-Interface (Layer1-INFO0) und einmal im aktivierten Zustand (Layer1-INFO4). Gruß Jens
Die Idee und Ausführung der SW-Dekodierung des S0-Kanals ist super. Ich habe die Idee der Dekodierungs des D-Kanals mal aufgegriffen und implementiert. Mein Beispielprogramm liest die D-Bits ein, wartet auf das Startkennzeichen (0x7E) und sammelt dann alle Bytes ein bis wieder das Kennzeichen 0x7E kommt. Dabei wird das Bitstopfen berücksichtigt. Da (zumindest bei uns) auch ab und zu Ruhe-D-Kanalnachrichten kommen, auch wenn nicht telefoniert wird, werden die D-Kanalnachrichten nur seriell ausgegeben, wenn sie mehr als 10Byte (kann natürlich geändert werden) lang ist. Die getraceten Nachrichten sehen so aus, wie bei meinem D-Kanal Dekoder (http://www.shamrock.de/tools.htm). Für Richtigkeit kann ich totzdem nicht garantieren. Hier noch einige Angaben zur HW: - verwendet habe ich den ATMEGA88P - Quarz 22.1184MHz (AVR übertaktet, geht aber trotzdem) - ISDN-Trafo UT28624 aus einer alten Medion ISDN-Karte - 2 Transistorschaltung wie bei Jens Die Ursprungs-SW ist folgendermaßen angepaßt: - Bitdekodierung nach Benedikt H. - PWM entfernt - Ser.-/Par.-Wandlung angepaßt, da erstes Bit = LSB - Zwischenspeicherung der Bytes im SRAM - Umwandlung in ASCII - Anfangs- und Endekennzeichen werden mit ausgegeben Vielleicht wollen einige hier auf das Programm aufsetzen, es fehlt ja noch einiges, wie z.B. die CRC-Auswertung. Testen werde ich demnächst die E-Kanalauswertung, da über den D-Kanal nicht immer die gewählte Rufnummer zu sehen ist. Für alle Leser alles Gute zum neuen Jahr! Harald
Gesundes und erfolgreiches neues Jahr an alle! @Harald: Den D-Kanal hatte ich vor zwei Tagen auch schon auf dem Terminal. Allerdings hatte ich mich da noch gefragt, warum ich gelegentlich fehlerhafte Frames auf dem Schirm habe. Die Erklärung habe ich in Deinem Sourcecode gefunden - die Sache mit dem Bit stuffing. Ein Blick in die ITU-T Q.921 (2.6 Transparency) lieferte endgültige Gewissheit: "A transmitting data link layer entity shall examine the frame content between the opening and closing flag sequences, (address, control, information and FCS fields) and shall insert a 0 bit after all sequences of five contiguous 1 bits (including the last five bits of the FCS) to ensure that a flag or an abort sequence is not simulated within the frame. A receiving data link layer entity shall examine the frame contents between the opening and closing flag sequences and shall discard any 0 bit which directly follows five contiguous 1 bits." Nachdem ich nun die Nullen gezielt vernichte, bekomme ich auch plausible Layer2/3 Nachrichten. Falls es jemanden interessiert: Die kurzen Datenpakete bei scheinbar ungenutzter Leitung sind Layer2-RR (RECEIVE READY) Nachrichten. Jede Layer3 Nachricht wird in der Regel von der Gegenseite mit einem Layer2-RR bestätigt. Werden für ca. 10 Sekunden keine Layer3 Nachrichten verschickt, z.B. in Ruhe bzw. auch bei fertig aufgebauter Verbindung, wird ein Layer2-RR mit gesetzten Poll-Bit benutzt um die weitere Verfügbarkeit des Layer2 zu prüfen (keep alive). Die Gegenstelle beantwortet eine solche Anfrage ebenfalls mit einem Layer2-RR, allerdings mit einem gesetzten Final-Bit. Reine Layer2 Nachrichten ohne Layer3 Informationen (RR, SABME, UA, ...) sind für die Realisierung eines Call-Monitors völlig überflüssig und brauchen nicht ausgewertet zu werden. Bei einer D-Kanal-Protokoll-Analyse liefern sie aber oft brauchbare Hinweise bei der Störungseingrenzung. Gruß Jens
Hallo, in Fortführung der Grundidee möchte ich hiermit als nächstes Etappenziel die Realisierung eines Low-Cost S0-PC-Interface zur D-Kanal-Protokollanalyse vorschlagen: - S0-Bus mit Übertrager am AVR (galvanische Trennung) - 1. AVR-Controller zum 'zerkleinern' der S0-Frames d.h. Filtern der D/E-Bits, Behandlung HDLC-LAPD für beide Richtungen (Flags, Bit stuffing) - 2. AVR-Controller mit Low-Speed Software-USB (V-USB) - Auswertung der Events (Layer1) und Nachrichten (Layer2/3) in der PC-Applikation - evtl. LED zur Anzeige ob Layer1 auf dem S0-Bus aktiv ist (Layer1-INFO4) Das Ganze müsste sich meiner Meinung nach einfach auf einem Streifen Lochraster realisieren lassen und könnte incl. RJ45-Buchse in einem kleinem Gehäuse verschwinden. Mit USB hätte sich auch das Thema Stromversorgung erledigt. Falls 20,000 MHz an Stelle von 18,432 bzw. 22,1184 MHz auch funktionieren, würde ich beide Controller mit dem gleichen Takt versorgen. Was haltet Ihr davon? Gruß Jens
Hallo Kollegen, die D-Kanal Protokollierung als Anrufmonitor fände ich auch höchst interessant. Die Frage ist nur, ob z. B. nicht EIN Arm-Controller dazu besser geeignet wäre. Ich habe mal Breakout Board für den LPC2148 und LPC2368 gemacht. Der LPC2368 hätte z. B. ein MAC-Interface (Ethernet) und ein SD-Karteninterface mit drin. Mit 60 MHz und exzellenter Hardware wäre der sicher gut als "one chip Lösung" geeignet. Alternativ der LPC1768. Gruß, armnix
Für AVR-Freunde geht D-Kanal Protokollierung auch mit Tiny25 und nachgeschaltetem Mega8/88 o.ä. Diese 2 Bausteine sind wahrscheinlich zusammen billiger als ein ARM-Prozessor. Ideen wie man es machen kann, kann man sich aus der zip-Datei holen. Neben einer kurzen Beschreibung finden sich auch ein paar Codeschnipsel für die Auswertung. Harald
Für alle die, die den VAC L4096-X022 benutzen: Dieser Übertrager liefert an den Ausgängen nur 500mVs. Wenn man ihn trotzdem verwenden möchte, so ist folgende Modifikation an dieser Schaltung vorzunehmen: http://www.mikrocontroller.net/attachment/96245/S0_interface.png Pin2 vom Trafo TR1 mit einem Spannungsteiler versehen. 8k2 gegen Vcc (bei 5V) und 1K gegen Masse. Die direkte Masseverbindung ist natürlich zu entfernen. Gruß Jobst
Servus Leute! Versteh ich das richtig, dass vom AVR sowohl das was in den Hörer gesprochen wird, als auch das, was der gegenüber sagt ausgegeben wird oder nur das von der Gegenseite? Schöne Grüße,
Stefan schrieb: > Servus Leute! > > Versteh ich das richtig, dass vom AVR sowohl das was in den Hörer > gesprochen wird, als auch das, was der gegenüber sagt ausgegeben wird > oder nur das von der Gegenseite? > > Schöne Grüße, Hallo Stefan, die ursprüngliche Lösung von Benedikt H. (hunz) erlaubt das einseitige 'Belauschen' eines Nutzkanals. Aus welcher Richtung die Daten kommen wird durch die Anschaltung am S0-Bus bestimmt. Aus Sicht des NTBA sind es folgende zwei Möglichkeiten: S0-Tx (NTBA) RJ45 Pin 4/5 NT --> TE (Daten von der Gegenseite) S0-Rx (NTBA) RJ45 Pin 3/6 TE --> NT (Daten vom eigenen Endgerät) Die gleichzeitige Erfassung beider Richtungen müsste theoretisch auch machbar sein. Im Beitrag "Re: ISDN am AVR (Mega8)" habe ich diese Möglichkeit bereits einmal betrachtet. Gruß Jens
Servus ! Heißt das man kann die Schaltung auch doppelt aufbauen und die eine an den inneren und die andre äußeren beiden Adern anschließen? Oder gibt es da Probleme bei der "Bitposition"? Außerdem kann man dann überhaupt die Schaltung von hunz nur mitt 100nF ohne Übertrager dann noch verwenden? Weil sonst müsste man ja eine Ader(Pi 3 od. 6) auf Masse legen, was nicht so gut sein wird ;) Leider hab ich nicht so gute Kenntnisse, um den Code für den AVR entsprechend zu ändern, dass der die beiden Kanäle mischt... Schöne Grüße, Stefan
Stefan schrieb: > Außerdem kann man dann überhaupt die Schaltung von hunz nur mitt 100nF > ohne Übertrager dann noch verwenden? Weil sonst müsste man ja eine > Ader(Pi 3 od. 6) auf Masse legen, was nicht so gut sein wird ;) Zwischen den beiden Aderpaaren (4-5 und 3-6) liegt Spannung, die zum Betrieb der Endgeräte benötigt wird. Die zusammen zu schalten wird Probleme geben. Gruß Jobst
Bzgl. der D-Kanaldekodiereung, wie ist das bei den "Standart"-ISDN Anschlüssen eigendlich?, wird da bei einem Anruf mit unterdrückter Rufnummer diese garnicht übertragen, oder liegt die vielleicht doch irgendwo bei Anrufsignalisierung auf dem D-Kanal und hat nur ein "nicht anzeigen" Bit gesetzt? Hat das schonmal jemand beim experementieren rausfinden können?
Im ISDN werden unterdrückte Rufnummer gar nicht übertragen. Falls es ein "böswilliger" Anruf war, kann man das den Ruf "fangen", d.h. es wird der Vermittlungstelle ein enstprechender "fangen" Request übermittelt, worauf diese die Nummer zur Auswertung speichert. Allerdings muß dieses Leostungsmerkmal in der Vermittlung freigeschaltet sein. (Diese Information kann veraltet sein, da ich seit 15 Jahren nichts mehr mit ISDN zu tun habe...)
Eigentlich schade, dass ISDN so am Aussterben ist und Analogtelefone wieder aktuell geworden sind. Auch wenn diese heute immer häufiger mit VOIP benutzt werden.
Danke für die Antwort Bernhard, allerdings bin ich da erst drauf gekommen, da ich an einem anderen Standort noch eine 0180er Nummer geschaltet habe. Auf dieser Nummer sehe ich jeden Anrufer, auch die Unterdrückten, (wohl zu Abrechnungszwecken). Jetzt hab ich einfach mal alle unterdrückten Anrufe von meinem ISDN via Vermittlungsstelle auf die 0180er umgeleitet und diese dann auf einer anderen MSN wieder zu mir zurück. D.h. der Anrufer zahlt die Verbindung zu meiner FN MSN, ich zahle die Verbindung FN -> 0180 und 0180 -> FN. Das Ergebnis ist nun, dass ich auf der 0180er alle Nummern sehen kann, also auch jene die bei mir Unterdrückt ankamen und durch mich weitergeleitet wurden... Sicher, dass da nix (versteckt) mitübertragen wird? Wäre schon interessant, zumindest würde es mir die doppelten Rufumleitunskosten ersparen, die aber immernoch bedeutend günstiger sind, als eine Fangschaltung beim Provider.
Normalerweise wird die Rufnummer bis zur letzten Vermittlungsstelle mit übertragen. Dort wird dann entschieden, ob sie zum Endteilnehmer übermittelt wird. Wird dagegen entschieden, kommen auch keine Daten an. Gruß Jobst
Angehängte Dateien:
-
ISDN_Monitor.jpg
170 KB -
ISDN_Monitor_Aufbau.jpg
320 KB -
ISDN_Trafo_Anschaltung.jpg
340 KB -
ISDN_PCM_Filter.jpg
210 KB
Hallo miteinander, vielen Dank an Hunz für sein Projekt. Damit konnte ich mir endlich mal eine sinnvolle Anschaltung für mein Telefon ans Mischpult bauen, wenn wieder Aufzeichnungen für Podcasts laufen. Da man sich ja selbst über ein anderes Mikrofon aufnimmt, den Gesprächspartner alleine auf einer Tonspur haben möchte, habe ich mir diesen ISDN Monitor in ein altes NTBA Gehäuse eingebaut. Die Mischung erfolgt außerhalb, deshalb wurde die Schaltung zwei mal aufgebaut. Die ISDN Anschaltung habe ich nach dem Schaltungsentwurf von Baltic umgesetzt. Da es andere Trafos sind, die Signalverhältnisse nicht gestimmt haben, mußten beide Basen der Transistoren mit einem 4k7 Widerstand zusammen geschaltet werden. Die Signalsymmetrie wurde deutlich besser. Die beiden Basen mußten auch nach dem Schaltungsvorschlag von jobstens-de vorgespannt werden, sonst ging da nix. Die Spannungsversorgung kommt vom NTBA und hat bereits eine 5V Versorgung samt Resetkomparator. Jeweils an PC0 wurde noch eine LED angebracht. Eine VOX Steuerung wäre damit denkbar. Der Quarz versorgt beide AVR. Da mit den vorhandenen 5V einige OPVs nicht richtig gut funktionieren, die 40V des NTBA echt oversized sind, habe ich mich für eine passive PCM Filterung 4. Ordnung entschieden. Auf zwei RCA Buchsen kommt der entsprechende Line Pegel raus. Für diese einfache Schaltung funktioniert das Ganze wirklich gut! Danke Lg, Schraubär
Diese Schaltung greift ja nach der NTBA die einseitigen Nutzdaten, eines B-Kanals ab... Wenn ich jetzt aber alles Brauche, also B1,B2,D und das in beiden Richtungen, könnte ich dann nicht einfach vor die NTBA, direkt an die 2-Draht-Leitung gehen? Also nach modifikation der Schaltung, schon klar - die Frage geht ehr in die Richtung, wäre das mit einer anderen Programmierung und ggf. größerem µC eine realistische Vorstellung?
Oskar schrieb: > Diese Schaltung greift ja nach der NTBA die einseitigen Nutzdaten, eines > B-Kanals ab... > > Wenn ich jetzt aber alles Brauche, also B1,B2,D und das in beiden > Richtungen, könnte ich dann nicht einfach vor die NTBA, direkt an die > 2-Draht-Leitung gehen? > > Also nach modifikation der Schaltung, schon klar - die Frage geht ehr in > die Richtung, wäre das mit einer anderen Programmierung und ggf. > größerem µC eine realistische Vorstellung? Das wäre dann Uk0. Wenn Du kein weiteres Gerät an die Leitung hängst und einen halben NTBA nachbilden möchtest ... Unmöglich ist das bestimmt nicht ... Gruß Jobst
^^ Das gibts auch schon fertig, guckst Du hier: http://www.alarm.de/telefonueberwachung/isdn/uk0-mitschnittsystem.html Luci
Guten Tag, ich bin durch Zufall auf diesen sehr alten Thread gestoßen und begeistert, dass es wohl doch ein paar Leute gibt, die sich von der "Bastelseite" dem Thema ISDN genähert haben. Ich hoffe mal, das vielleicht der ein oder andere hier noch mitliest und vielleicht noch an dem Thema interessiert ist oder Gleichgesinnte kennt. Ich hätte für ein "ISDN aus dem Mikrocontroller" tatsächlich auch eine Anwendung, wobei mir dabei nicht wäre dass es aus einem Mikrocontroller kommt. Es geht hierum: Aktuell und in den kommenden Jahren fliegen aufgrund der AllIP-Umstellung kistenweise Up0-basierende Systemtelefone auf den Schrott. Sie an den alten Anlagen weiter zu betrieben ergibt keinen Sinn, eben weil diese Anlagen nicht SIP-fähig sind, es gibt nur noch wenig Techniker die sich damit auskennen, die Konfigurationssoftware läuft nur auf immer älter werdenden Windows-Systemen oder man braucht zwingend RS232 am Rechner, etc.pp. Aber: ein Telefon ist ein Telefon, und die Telefone haben Displays und tlw. auch viele Funktionstasten, woraus man noch richtig viel machen könnte. Und: die Geräte brauchen sicherlich weniger Energie als IP-Telefone und begnügen sich mit zwei simplen Drähtchen. Auf der anderen Seite gibts ja diverse TK-Anlagen als Opensource (Asterisk, FreeSWITCH,...), die man solchen Geräten vorsetzen könnte. Insofern suche ich nach Interessierten, mit denen man so etwas mal durchspinnen könnte.
@sunnyman Exakt das gleiche habe ich mir heute auch gedacht und bin so auf diesen Thread gestoßen :-)
ME schrieb: > @sunnyman Exakt das gleiche habe ich mir heute auch gedacht und bin so > auf diesen Thread gestoßen :-) ISDN Telefone an einen Asterisk macht keinen Sinn. ISDN Merkmale und Sonderfunktionen werden nicht unterstützt. Ausserdem sind Mehrport ISDN Karten zu teuer. An einen Asterisk machen nur SIP Telefone Sinn. Alles andere ist Murks. Grüße
@wpfundstein So wie ich sunnyman verstanden habe, geht es vielmehr darum Up0-basierende Systemtelefone IP-fähig zu machen anstatt TK-Anlagen wie den Asterisk mit ISDN Karten auszustatten. Ich schätze auch, dass man nicht alle Funktionen wird umsetzen können. Schließlich unterscheiden sich viele Systemtelefone schon allein hinsichtlich Ihrer Nutzung von Up0 durch proprietäre Zusätze am Protokoll soweit ich das bisher verstanden habe. Dennoch nehme ich an, dass man die Grundfunktionen des Anrufens umsetzen könnte. Auch wäre es ein Mittel gegen die künstliche Obsoleszenz, die von den rosafarbenen vorangetrieben wird, denn die Geräte sind noch einwandfrei nutzbar und kommen spätestens Ende des Jahres mit der Zwangsabschaffung des Anlagenanschlusses auf den Müll.
Werner P. schrieb: > ME schrieb: >> @sunnyman Exakt das gleiche habe ich mir heute auch gedacht und bin so >> auf diesen Thread gestoßen :-) > > ISDN Telefone an einen Asterisk macht keinen Sinn. ISDN Merkmale und > Sonderfunktionen werden nicht unterstützt. Merke: Up0-Systemtelefon != ISDN-Standardtelefon. Und was unterstützt wird regelt der channel driver. Ich betreibe an mehreren Systemen ISDN-Karten in Asterisk-Systemen, alle gängigen supplementary Services sowie Leistungsmerkmale und Protokolle werden unterstützt (Q.SIG, AOC, 3PTY, CCBS, Call Reroute, Call Deflect, ...) > Ausserdem sind Mehrport ISDN Karten zu teuer. Eine ISDN-Karte mit PRI gibts mittlerweile für unter 100 € neu. 4 BRI-Karten für unter 50 €. Aber, wie gesagt, das ist nicht die Frage. Die Vision hinter so etwas wäre auch keine Lösung für eine PCI-Karte sondern eher ein Gerät ähnlich wie es jetzt ja auch schon SIP-Analog-Gateways gibt oder die herstellerspezifische, industrielle Variante namens "Siemens HiPath Access SLO" mit 24 UP0/E Ports. Aber das ist ungefähr der 200ste Schritt :)
ME schrieb: > Schließlich unterscheiden sich viele Systemtelefone schon allein > hinsichtlich Ihrer Nutzung von Up0 durch proprietäre Zusätze am > Protokoll Zwar habe ich auch noch kein Systemtelefonprotokoll auseinandergedröselt aber erfahrunsgemäß bestehen die neben dem Sprachkanal nur aus Display und Tastatur. Die Entscheidung was geschieht passiert in der TK Analage. Das würde es vereinfachen die Dinger anzusteuern aber es gibt so viele verschiedene und manche wollen auch noch Firmware haben.
Korrekt. Also die typischen Siemens-Geräte kommen bereits mit Firmware (die bei Bedarf natürlich überschrieben werden kann). Ein erster Schritt wäre dann natürlich, so etwas wie einen "Sniffer" zu bauen. Witzigerweise gibt es eine tschechische TK-Anlage namens 2N Netstar, die schon immer Siemens Up0-Geräte als Endgeräte unterstützt. Entweder haben die es geschafft, das Protokoll zu reverse engineeren oder Siemens mal dazu überreden können, ihnen selbiges zugänglich zu machen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.