OctoBRI - Asterisk 1.4 Bristuff 040-test1 - LED's aus ...

[MicroPhone]

Hallo zusammen, nettes Informationsfleckchen hier !

...vor etwa 3 Wochen habe ich eine OctoBri der Firma Junghanns bekommen, konnte jedoch die Karte bis heute nicht dazu bringen mal ein Laempchen am Panel mit Strom zu versorgen. :noidea:

Ich habe bereits mit meinem Reseller wie auch Junghanns.net gesprochen, die mir jedoch bisher nur bestaetigen konnten, dass eigentlich alles gut ausschaut - den Fehler jedoch noch nicht erkennen koennen. Laut Anleitung sollte nach dem Befehl "ztcfg -vv" jedoch eine LED auf dem Panel leuchten, dies ist jedoch nicht der Fall.

Meine Hoffnung ist jetzt, dass einer von euch vielleicht die rettende Idee auf Lager hat.

Da wir die Karte jetzt bereits ausgetauscht haben, gehe ich davon aus, dass die Hardware i.O. ist.

folgende Config liegt vor:
8xTE-Mode (gejumpert), 5V PCI (Jumper gesetzt)
Stromversorgung aus, da kein NT-Mode. Derzeit kein PF-Modul.

Das System ist ein Debian Sarge
Linux asterisk 2.6.8-3-386 #1 Wed Dec 6 00:38:53 UTC 2006 i686 GNU/Linux

folgende Initialisierung nehme ich vor:

asterisk:/usr/src/bristuff-0.4.0-test1/qozap# modprobe zaptel

Zapata Telephony Interface Registered on major 196
Zaptel Version: 1.4.1
Zaptel Echo Canceller: MG2

asterisk:/usr/src/bristuff-0.4.0-test1/qozap# insmod qozap.ko ports=0

qozap: no version for "struct_module" found: kernel tainted.
ACPI: PCI interrupt 0000:02:09.0[A] -> GSI 17 (level, low) -> IRQ 209
qozap: Junghanns.NET octoBRI (Version 2.0) card configured at io port 0xa400 IRQ 209 HZ 1000
qozap: S/T ports: 8 [ TE TE TE TE TE TE TE TE ]
qozap: 1 multiBRI card(s) in this box, 8 BRI ports total, bloop 0, pcmslave 0.
Registered tone zone 29 (Germany)

asterisk:/usr/src/bristuff-0.4.0-test1/qozap# ztcfg -vv

Zaptel Version: 1.4.1
Echo Canceller: MG2
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 2: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 3: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 4: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 5: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 6: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 7: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 8: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Slaves: 01)
Channel 02: Clear channel (Default) (Slaves: 02)
Channel 03: D-channel (Default) (Slaves: 03)
Channel 04: Clear channel (Default) (Slaves: 04)
Channel 05: Clear channel (Default) (Slaves: 05)
Channel 06: D-channel (Default) (Slaves: 06)
Channel 07: Clear channel (Default) (Slaves: 07)
Channel 08: Clear channel (Default) (Slaves: 08)
Channel 09: D-channel (Default) (Slaves: 09)
Channel 10: Clear channel (Default) (Slaves: 10)
Channel 11: Clear channel (Default) (Slaves: 11)
Channel 12: D-channel (Default) (Slaves: 12)
Channel 13: Clear channel (Default) (Slaves: 13)
Channel 14: Clear channel (Default) (Slaves: 14)
Channel 15: D-channel (Default) (Slaves: 15)
Channel 16: Clear channel (Default) (Slaves: 16)
Channel 17: Clear channel (Default) (Slaves: 17)
Channel 18: D-channel (Default) (Slaves: 18)
Channel 19: Clear channel (Default) (Slaves: 19)
Channel 20: Clear channel (Default) (Slaves: 20)
Channel 21: D-channel (Default) (Slaves: 21)
Channel 22: Clear channel (Default) (Slaves: 22)
Channel 23: Clear channel (Default) (Slaves: 23)
Channel 24: D-channel (Default) (Slaves: 24)

24 channels configured.

Changing signalling on channel 1 from Unused to Clear channel
Changing signalling on channel 2 from Unused to Clear channel
Changing signalling on channel 3 from Unused to HDLC with FCS check
Changing signalling on channel 4 from Unused to Clear channel
Changing signalling on channel 5 from Unused to Clear channel
Changing signalling on channel 6 from Unused to HDLC with FCS check
Changing signalling on channel 7 from Unused to Clear channel
Changing signalling on channel 8 from Unused to Clear channel
Changing signalling on channel 9 from Unused to HDLC with FCS check
Changing signalling on channel 10 from Unused to Clear channel
Changing signalling on channel 11 from Unused to Clear channel
Changing signalling on channel 12 from Unused to HDLC with FCS check
Changing signalling on channel 13 from Unused to Clear channel
Changing signalling on channel 14 from Unused to Clear channel
Changing signalling on channel 15 from Unused to HDLC with FCS check
Changing signalling on channel 16 from Unused to Clear channel
Changing signalling on channel 17 from Unused to Clear channel
Changing signalling on channel 18 from Unused to HDLC with FCS check
Changing signalling on channel 19 from Unused to Clear channel
Changing signalling on channel 20 from Unused to Clear channel
Changing signalling on channel 21 from Unused to HDLC with FCS check
Changing signalling on channel 22 from Unused to Clear channel
Changing signalling on channel 23 from Unused to Clear channel
Changing signalling on channel 24 from Unused to HDLC with FCS check

... hoffe schwer dass jemand noch 'ne Idee hat, wo noch ein Fehlerchen versteckt sein koennte ...

besten Dank schon mal !

Gruss

change: eine falsche Codezeile entfernt

 

[MicroPhone]

Nachtrag

... mittlerweile habe ich entdeckt, dass ich unter Umstaenden zeitweise zu langsam war - die LED des ISDN-Ports, in dem derzeit ein Mehrgeraeteanschluss (aus unserer alten PBX) steckt, leuchtet kurz (ca. 30sec) nach Ausfuehrung von ztcfg -vvv auf, bevor sich das Ding dann wieder stillschweigend schlafen legt. In der Zeit ist auch /proc/zaptel/1 auf ACTIVE ... der Debug sagt mir nur

1 Sending TEI verify tei=127
1 Sending TEI Request ri=40560

in zyklischen Abstaenden ...

in der zaptel.conf is bereits signalling = bri_cpe_ptmp eingestellt.

hat jemand evtl. noch eine Checkliste auf Lager, wo ich mal schauen sollte ?

ich weiss net weiter ... :noidea:

Gruss

 

[MicroPhone]

Neuigkeiten

die Firma Junghanns hat sich des Problems nochmal angenommen und angemerkt, dass an den 0.4.0-test1 - Treiber noch etwas zu verbessern ist.

Waren jetzt zwar etwa ne Mann-Woche Arbeit und ich hab das Ding noch nicht am rennen - waere aber wahrscheinlich anders gewesen, wenn ich nicht einen Reseller dazwischen gehabt haette.

Der Support ist bisher jedenfalls zufriedenstellend.

Warten wir auf Neuerungen in den naechsten Tagen - da soll sich wohl was bei Junghanns im Download-Verzeichnis tun.

Gruss MP

 

[speedy1980]

Warum muss es eigenlich Bristuff 0.4.0 sein? Reicht Dir Asterisk 1.2 nicht (und damit Bristuff 0.3.0)? Bei meinen Installationen vermisse bisher nichts bei Asterisk 1.2.

 

[MicroPhone]

naja, es waere schoen.
Vielleicht hab ich da was uebersehen, aber soweit mir als Voip-neuling bekannt ist, gibt's das *-GUI nur beim 1.4, da der 1.2er noch keinen Webserver implementiert.
Zum anderen hatte ich die 030-PRE-1w bereits installiert und der Treiber sagte mir beim erkennen meiner Karte nur "wtf" (sry - is ein Zitat) ... daraufhin bekam ich von Junghanns den Tipp die letzte verfuegbare Version zu nehmen. Da war dann gerade die 040 aufgetaucht. Zu dem Zeitpunkt hatte ich aber noch keine Ahnung, dass es nicht an meinen moeglicherweise zu ungeschickten Fingern liegt, sondern tatsaechlich der Treiber noch einen so dicken Fehler hatte.
Aber vielleicht sollte ich einfach auf die GUI verzichten und eine der 030-y's versuchen - hoffe dass die Sangoma A400 da mitmacht, denn die hat sich schon mit dem 1.4er angefreundet und laeuft glaenzend ...

 

[Red1982]

Jetzt mal ne ganz dumme frage... hast du mal versucht weiter zu konfigurieren bzw. bist du sicher das deine Karte nicht läuft? Hab zwar nicht die octoBri aber ne andere Karte aus der Serie von Junghanns und bei mir haben die LED's auch nichts von sich gegeben.

War auch Anfangs skeptisch aber da ich sicher war das ich alles richtig gemacht habe und keine Fehler bei der installation aufgetaucht sind hab ich einfach mal weiter gemacht und die Karte läuft einwandfrei auch ohne blinken ;-)

 

[MicroPhone]

@RED1982:
nun, dafuer dass da bei mir aber was nicht richtig laeuft gibt es vier Indizien:

sowohl Doku als auch eine Anleitung per mail sagen uebereinstimmend aus, dass nach modprobe zaptel; insmod qozap.ko ports=XX; ztcfg; , spaetestens aber nach dem folgenden Start des Asterisk sollten die LED's der Ports leuchten, auf denen der LAYER 1 aktiv ist.
Da das bei mir beim letzten Versuch genau 30 sec der fall war - is da wohl wieder etwas zusammengeklappt. Also Blinken soll da wohl nix, aber wenigstens dauerhaft leuchten.

Das * hat mir enttaeuscht mitgeteilt, dass ihm beim Laden der zapata.conf Kanaele aufgefallen sind, die nicht existieren (weil wohl eben der Layer 1 net mehr funzt) und deshalb das laden des chan_zap abbricht.

das angeschlossene ISDN-Telefon (Karte auf dem Port in NT-Mode, Powerfeeding-Jumper gesetzt, qozap.ko ports=XX entsprechend gesetzt, onboard-pfm ist installiert) sagt keinen Mucks

und Junghanns hat scheinbar noch einen kleinen Fehler in ihrer 040-TEST1 ausgabe gefunden, der eben das wohl loesen soll - so die Aussage -.

- so spontane Funktion waere allerdings was feines gewesen

... ich denke Freitag/Samstag werde ich die letzte 030 mit dem 1.2 nochmal anvisieren, sollte bis dahin kein neuer 040 vorliegen ...

 

[MicroPhone]

030-PRE1-ye laeuft teilweise ...

FUNKTION! - partiell zumindest - ... habe soeben die 030-PRE1-ye installiert und ein Gespraech reinbekommen auf einem TE-Port ...
Endlich ! ... leider will das Powersupply bei den NT-Ports noch nicht ... Forschung laeuft ...

 

[MicroPhone]

... mir noch unerklaerliches Verhalten ...

Na ganz Klasse ! ...

... nachdem ich heute morgen speedy's Vorschlag angepackt habe, den 1.4er wieder deinstalliert hab und nochmal den 1.2er asterisk bzw. den bristuff-0.3.0-PRE-1y-e installiert hab konnte ich zumindest einen dauerhaft aktiven LAYER1 auf den TE-Ports vermelden.
Aber die scheinbare Loesung fuer den NT-Mode kam erst gerade ...

Anstatt des passiven T-Concept PA722 (schnurgebundenes ISDN-Waehlbrett) habe ich nun mal die Basisstation meines T-Sinus 62K (mit Netzteil) angeschlossen und man siehe und staune, der LAYER1 ging online.

=> Kann mir jemand hier erklaeren, warum das gute alte solide PA722 nicht funktioniert, die Basisstation hingegen doch? ... am NTBA funktionieren beide wunderpraechtig! )

Weil ich's wissen wollte hab ich beide Telefone per Y-Adapter an einen Port gehaengt, mit dem selben Ergebnis: PA722 sagt nix, 62K is supergluecklich und gratuliert mir beim Abheben zum erfolgreich installierten *.
Ein auf dem gleichen BUS haengender SiTi (ISDN-Tester) zeigt an, dass da kein Power auf dem Bus waer ( LED's aus ).

=> ... kann das PF-Modul nicht genug Power fuer passive ISDN-Geraete liefern ? :noidea:

... bei sowas sucht man sich ja nen Wolf ...

aber immerhin! die Karte zeigt Grundfunktionalitaet!

zur Config: OctoBri 2.0, Ports 1+8, 7+2 im TE-Mode, Ports 4+5, 3+6 im NT-Mode, Powerfeeding-Jumper bei 3,4,5,6 gesetzt, PF-Modul onboard installiert, qozap ports=60 => [TE TE NT NT NT NT TE TE], Molex-Stecker angeschlossen. wenn gewuenscht hab ich auch noch nen Photo von der konfigurierten Karte.

 

[MicroPhone]

also die Erklaerung des Phaenomens hab ich.

siehe http://www.netzmafia.de/skripten/telefon/isdn-a.html

die Basisstation braucht keine Speisespannung.

ABER was ist auf der Karte noch falsch ?

 

[TomS]

Welches PFM setzt Du ein?
Falls du ein externes PFM verwendest mußt Du die 4 Steckbrücken auf der Karte, die das interne PFM aufnehmen würden schließen. (Auf dem Jumpersheet wird die Stelle PFM-Connector genannt)

Ich hoffe das hilft Dir weiter.

Ciao,
Tom

 

[MicroPhone]

Danke Tom,

nee - dat ist es leider nicht - hab das kleine "onboard"-PFM.
12V vom Netzteil (Molex-Stecker) sind ebenfalls angeschlossen.

:noidea:

 

[MicroPhone]

Ersatzteil ...

... nachdem ich von Junghanns.NET nun die Nachricht bekam, dass sie herausgefunden haben, dass die OctoBri 2.0 nur mit einem externen PFM funktioniert, und sie mir dieses Bauteil zugeschickt haben, komme ich nochmal auf Dich zurueck Tom:

weiss jemand von euch, wie genau die Jumper nun gesetzt werden muessen ? welche Richtung ? oder hat vielleicht jemand nen Bildchen davon ?

Ziel: OctoBri 2.0 & externes PFM.

Gruesse MP

 

[MicroPhone]

ernuechterndes Ergebnis ...

Vielen Dank erstmal fuer eure Unterstuetzung bis hier her ...

Knapp sieben Wochen nach dem Kauf, hab ich die OctoBri 2.0 noch immer nicht vollstaendig am Laufen. Die Karte laeuft am Anlagenanschluss, und vertraegt sich auch mit der hinter ihr haengenden Fritzkarte. Saemtlichen passiven Geraete funktionieren jedoch nicht, da die OctoBri einfach keine Speisespannung rausgibt.
Nachdem man mir nun erklaert hat, dass das Onboard-PFM, welches mir mit der Karte verkauft wurde, auf der OctoBri nicht funktioniert, und mir deshalb ein von Junghanns ein externes geschickt wurde, das jedoch auch nicht funktioniert, bin ich mehr als nur enttaeuscht von der Karte. Zumal ich bis heute keine annaehernd vollstaendige Doku ueber die Karte gesehen hab, die Lieferungen kamen alle voellig nackt.
Die Jumpersettings passen, soweit ich das nach Anleitung und der Aussage von Herrn Junghanns verfolgen konnte. Ebenso liegen an der Karte (externes PFM) ca. 38V an, die Jumper fuern PFM-Connector sind geschlossen.

Hat irgendjemand hier schon eine OctoBri 2.0 mit Speisespannung erfolgreich laufen ? ... oder kann mir jemand eine erwiesenermassen funktionierende Alternative aufzeigen ?

Besten Dank nochmal!

Gruesse, Micro

/added:
P.S.: Ziel meiner Bemuehungen sind 4 TE PTP (Anlagenanschluss) und 4 NT PTMP mit Speisespannung fuer die internen ISDN-Telefone

 

[TomS]

Hi Micro,

diese Kombination habe ich leider nicht im Einsatz. Die einzige Octobri nutze ich ohne PFM (intern gibts nur ISDN-Karten oder ab-Wandler, also keine Speisung nötig). Ich hatte mal zum Spaß ein ext. PFM getestet, wußte aber damals nicht, dass ich das dann den internen PFM-Sockel kurzschließen muß, daher gings nicht.
Die Quadbri-Karten machen keine Probleme.

Gib das Problem doch mal an den Hersteller-Support weiter. Sollte doch im Interesse des Herstellers liegen, das sein Produkt wie geplant funktioniert (hartnäckig bleiben ;-) )

Ciao,
Tom

PS: dass das interne PFM bei Octobri nicht funktioniert ist schon der Hammer, das ist eine wichtige Info, danke!
PPS: beworben wird aber immer noch auch das interne PFM: "# optional external or onboard S0 bus power feeding module available for feeding up to 2 cards"

 

[MicroPhone]

Hey Tom, jepp, Du hast Recht, ist echt ein wenig unschoen ...
der aufmerksame Beobachter haette sich jedoch den Aerger erspart - ein Blick auf die Beronet-Seite bringt eine Karte BN8S0 zutage - die verblueffend aehnlich ausschaut (ich moechte den Entwickler kennenlernen, der eine solche "Kopie" anfertigen kann ) ... also mal angenommen, die Karte waere die "gleiche", dann staende auf der Beronet-Seite bereits seit einiger Zeit, dass auch die Junghanns-Karte OctoBri 2.0 nicht mit dem Onboard-Modul funktioniert.

Daher wundern mich jetzt auch ein wenig die Schwierigkeiten mit dem Externen.

... zum Hersteller-Support aeusser ich mich an dieser Stelle mal nicht weiter ...

Sagt mal, koennten zwei QuadBri mein Problem loesen ? ... gehen die tatsaechlich so viel besser (auch mit PFM) ?

Gruss Micro

 

[MicroPhone]

[solved] - hardwareprobs ueber hardwareprobs

hallo zusammen,

gute Neuigkeiten ! - naja wie man's auch sieht - sie laeuft...

aber wie es dazu kam hat mich nun doch sehr verwundert...

Ich habe noch einige Male herumtelefonieren muessen, bis ich schliesslich meinem Distributor mitgeteilt habe, dass ich die Karte zuruecksenden wolle und mich nach etwas anderem umschaue. Der hat mich dann wiederum gebeten doch mal bei beronet anzufragen, die haetten ein aehnliches Produkt (BN8S0) - ist klar.
Daraufhin hab ich dann sofort bei BeroNet angerufen und mich dort nach einem Produkt mit "besserem" Support erkundigt, woraufhin der Mitarbeiter der Firma BeroNet mich kurzerhand an meinen Asterisk gebeten hat und mit mir in einer knappen halben Stunde die Konfiguration der OctoBri (immernoch die von Junghanns !!!) durchgesprochen hat.
Dabei sind uns dann zwei Fehler aufgefallen: a) das Anschlusskabel des externen PFM musste noch gekreuzt werden und b) es werden NUR die OBEREN 4 PORTS der OctoBri mit Strom versorgt.
Nachdem ich mir dann die Kabel aufgepatcht und neu verdrahtet hatte, funzte alles auf Anhieb - es kann SO EINFACH sein, wenn man nur den richtigen Support bekommt! (Nen Hinweis in der Doku waere allerdings auch hilfreich gewesen!)

EIN HOCH AUF BERONET! An dieser Stelle nocheinmal besten Dank fuer die Unterstuetzung! (und das an einer Junghanns-Karte!) - Hut ab!

Also an dieser Stelle nochmal fuer alle - die aehnliches vorhaben :

a) die Junghanns OctoBri 2.0 funktioniert (entgegen der Werbung) NICHT MIT DEM ONBOARD-PFM

b) das Externe PFM benoetigt ein GEKREUZTES Anschlusskabel (40V auf dem inneren der beiden PFM-Anschluss Pins)

c) der Connector fuer das Onboard-PFM muss mit 4 Jumpern gebrueckt werden (Jumper senkrecht zum PCI-Slot)

d) die PFM-Jumper fuer die den mit strom zu versorgenden Port muessen geschlossen werden (Jumper parallel zum PCI-Slot)

e) ES KOENNEN NUR DIE PORTS 5-8 MIT GESPEIST WERDEN! Daher auch nur 4x2 PFM-Jumper. Das sind uebrigens die Ports, die man nur mit den Adaptern erreicht!

Allgemein bleibt mir nur zu sagen - von dem Hardware-Support der Firma Junghanns bin ich SEHR ENTTAEUSCHT! - Das BeroNet-Beispiel hat mir gezeigt, dass das Problem in 30min abgehandelt haette werden koennen. Insgesamt habe ich bei Junghanns+Distributor jetzt 8 Wochen gebraucht.
Und die Qualitaetssicherung im Hause Junghanns erscheint mir ein wenig fragwuerdig, angesichts dieser Pannenserie und der Tatsache, dass die von den Problemen an der Karte bis dato scheinbar nichts wussten.

MfG, das Micro