www.mikrocontroller.net

Forum: Projekte & Code ISDN am AVR (Mega8)


Autor: hunz (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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!

: Verschoben durch User
Autor: snowfly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: BillX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rekpekt! Allergrößten ..... respekt.... ich bin gespannt wies weitergeht 
;)

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe S. (de0508)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

.

Autor: Benedikt H. (hunz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beeindruckend und anregend.
Ich möchte Dir meine Anerkennung für dieses Projekt aussprechen.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sam (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke das ISDN noch eine Zeit überleben wird, trotz IP-Telefonie.

Ich will mein Telefon nicht abhängig vom Internet machen.

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S2M wäre mal cool!

Autor: s2m-fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Helmert schrieb:
> S2M wäre mal cool!

Brauchst die Schaltung von hunz nur 32x aufbauen ;)

Autor: xurpcha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Wie schwierig wäre es dann ISDN signal slebst zu generieren?

Autor: Benedikt H. (hunz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Benedikt H. (hunz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hatte auch schon 1M als Feedback drin.
Hmm. Das wären 10mV. OK. Danke.

Autor: Bal Tic (baltic)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Bal Tic (baltic)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe S. (de0508)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

.

Autor: isdn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: BRI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-...

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

Autor: Bal Tic (baltic)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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=e...) 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

Autor: Harald P. (haraldp)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bal Tic (baltic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bal Tic (baltic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: armnix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harald P. (haraldp)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Bal Tic (baltic)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: D. K. (lemur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D. K. (lemur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: schraubär (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oskar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Luci (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
^^ Das gibts auch schon fertig, guckst Du hier:

http://www.alarm.de/telefonueberwachung/isdn/uk0-m...

Luci

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.