[asterisk-dev] Zaptel Programming

[Doug Ehlers]

William,

The other device is another companies communication equipment.  I have it
set for matching T1 parameters, but that is about it.  I know it is defined
to have the first DS0 as a full bandwidth data pipe and the balance are
audio.  Not much help I'm afraid.

I've started messing with some of the settings in zconfig.h and getting
debug output turned on.

I can't help but feel that something is getting translated slightly between
the HW interface and my applications read of the channel.  Especially when
with random (human) timing, I can get the right message exactly 1 out of
every 8 times.

The funny thing with the 1 in 8 times thing is that there are several
messages that get replied (once I found the right setting on the other
equipment) and the responses are identical in the round robin of 8 times.
The first replied message will be correct 1 of 8 times, the other messages
that are replied as the same kind of thing, 1 of 8 times each message is
correct.  Never all messages at once.

Doug

-----Original Message-----
From: William Moore [mailto:nyphbl8d at gmail.com] 
Sent: Thursday, October 04, 2007 9:29 AM
To: dehlers at css-design.us; Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Zaptel Programming

Doug,
You said one machine had the zaptel config that you specified.  What
is the config on the other end of the link?

William

On 10/3/07, Doug Ehlers <dehlers at css-design.us> wrote:
>
>
>
>
> My zaptel.conf is like this:
>
>
>
> span=1,0,0,esf,b8zs
>
> bchan=1-24
>
>
>
> span=2,0,0,esf,b8zs
>
> bchan=25-48
>
>
>
> Is there something better to use?
>
>
>
> If I read this right that should turn off the robbed bit signaling.  I
> believe this matches the opposite equipment.  You are correct, in D4 the
6th
> and 12th frames rob for the A and B bit, in ESF the 6th, 12th, 18th, and
> 24th rob for the A, B, C, and D bits.
>
>
>
> I have been working further since my previous message.  Another clue might
> be this:  The message I send is 10 bytes long, the response is 10 bytes
and
> then some additional data of 10-20 bytes for each message.  Exactly every
> eighth time I send the my message, the reply message comes back correctly.
> I have a sniffer that says the opposite end is sending the correct string
> everytime.  I am running this as a little command prompt program at the
> moment and each time I run it, it sends the message once, so there is no
> particular timing involved.  Also, if I loop back from port 1 of the
Digium
> 405 card to port 2 of it with a crossover cable, I get perfect TX/RX
between
> the same app running in two different windows.  One app operates on chan 1
> the other on chan 25.
>
>
>
> Thanks all,
>
> Doug
>
>
>
>  ________________________________
>
>
> From: Wai Wu [mailto:wkwu at calltrol.com]
>  Sent: Wednesday, October 03, 2007 9:24 PM
>  To: dehlers at css-design.us; Asterisk Developers Mailing List
>  Subject: RE: [asterisk-dev] Zaptel Programming
>
>
>
>
> Did you configure the span as PRI or RobBit? If your span is PRI, is your
> channel 0 the D-Channel? If RobBit, (anyone correct me it I am wrong) the
> zaptel driver inserts controlling bits into the data frames. If I am not
> mistaken, the 6th and 12th frame. That means, you might have a hard time
> send and receiving pure data across those channels.
>
>
>  ________________________________
>
>
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
> Doug Ehlers
>  Sent: Wednesday, October 03, 2007 8:26 PM
>  To: asterisk-dev at lists.digium.com
>  Subject: [asterisk-dev] Zaptel Programming
>
> Hello all,
>
>
>
> I hope this is the right place to post this message, I didn't see just a
> list for Zaptel programming.
>
>
>
> I am working on a project using a Digium 405 T1 card.  I am trying to
write
> an application to talk via the T1 interface to another piece of equipment.
>
>
>
> Very simply, I have set the line configs in zaptel.conf and then run ztcfg
> to activate them.
>
>
>
> In my C++ program, I open the data channel ->
fd=open("/dev/zap/1",O_RDWR).
> This application is very similar to a PRI line in that one DS0 functions
as
> a control channel with a pseudo HDLC communications type link and the
other
> 23 channels get dynamically assigned usage based on incoming and outgoing
> calls.  Each DS0 is setup to be CLEAR mode, no signaling.
>
>
>
> After opening the device, I check the buffers and change them to some
> smaller sizes, make them act immediate, etc.
>
>
>
> I am able to write my message and see the opposite system get it and
> acknowledge it with a message back -> write(fd, buffer, length)
>
>
>
> The problem is in getting the data back.  I have just a simple read loop
> setup to read the data from the buffers that I believe were setup after
the
> device was opened.  This is being done with a simple read(fd, buffer,
> length) kind of command.  I assume with enough buffers, I should be able
to
> read the data rapidly enough to not lose anything.  I always get something
> back buy 1 in 5 times its actually correct (when no traffic is present,
the
> opposite side is sending 0xFF always so its pretty easy to know when there
> is data coming).  Most of the time the received data bares a resemblance
to
> the message that was sent, but certainly isn't it.  Occasionally the reply
> message is exactly correct and all is well.  Its almost like the bit
> alignment is off or something.
>
>
>
> Is there something I should be doing differently to reliably read data
back
> from a channel like this?  My next step will be to deal with the audio
> channels and the mechanism will be similar.  I have looked at a number of
> example applications such as fxotune.c and spent some time in chan_zap.c
> trying to discern the correct way to read data, but haven't yet turned
> anything up.  There are quite a few options to the zaptel API and I
haven't
> yet located a good document explaining how to work with it at the level I
> need.
>
>
>
> Can anybody give me some pointers or point me toward other information and
> resources?
>
>
>
> Many thanks,
>
> Doug
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>