[asterisk-dev] Change RX Signalling Bits in Dahdi drivers

[Optical Phoenix]

On Wed, Mar 6, 2013 at 2:57 PM, Optical Phoenix <opticalphoenix at gmail.com>wrote:

> Hello!
> Thanks very much for your input. I would very much like to create a new
> signalling type,I have been intimidated by the complexity of the driver.
> Would it be very difficult to create a new type?
>
> > case DAHDI_SIG_FXSLS:
> > if (!(~cursig & DAHDI_BBIT)) {      /*Dennis RINGING  */  /*<----- I
> think
>
> > this is checking if the state is different from a set value? needs
> > clarification*/
> >  /* Check for ringing first */
> > __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_RING);
> > break;
> >  }
> I added the tilde before cursig, It should now check if the signal is a
> "1" correct?
>
> and here, I have done a similar thing
> }
> if ((chan->sig != DAHDI_SIG_FXSLS) && (~cursig & DAHDI_BITS_ABCD)) {  /*
> added tilde  Should  be true if cursig is 0000, I think?*/
>     /* if went on hook */
> __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_ONHOOK);
>  } else {
> __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_OFFHOOK);
> }
>
> To give a little background, my goal is to create a PLAR signalling type.
> Since PLAR is very simple in comparison to FXO/S and is completely
> symmetrical(both sides signal the same way), It took me a while to figure
> out that there were tx and rx sections because I was only familiar with
> PLAR and E&M, and didn't expect there to be different cases.
> ON HOOK is all ones (1111)
> OFF HOOK is all zeros (0000)
>
> Thanks again,
> Dennis
>
> On Wed, Mar 6, 2013 at 1:21 PM, Shaun Ruffell <sruffell at digium.com> wrote:
>
>> Hi Dennis,
>>
>> On Wed, Mar 06, 2013 at 11:42:54AM -0500, Optical Phoenix wrote:
>> > Greeting,
>> > I am trying to setup PLAR signalling in asterisk. I have modified the
>> FXSLS
>> > TX bits in dahdi-base.c on line 2580, and I can make calls.
>>
>> After you get things woring, what about adding a new signalling type
>> instead of modifying loopstart?
>>
>> > .sig_type = DAHDI_SIG_FXSLS,
>> > .bits[DAHDI_TXSIG_ONHOOK]  = DAHDI_BITS_ABCD, /*changed by  for PLAR*/
>> >  .bits[DAHDI_TXSIG_OFFHOOK] = (0), /*changed by  for PLAR*/
>> > .bits[DAHDI_TXSIG_START]   = DAHDI_BITS_ABCD, /*changed by for PLAR*/
>> >
>> > When I go to change the rx, its a bit more complex. I have learned from
>> > this list that dahdi_rbsbits() handles the rx bits, but my changes seem
>> to
>> > have no effect. Does anyone have a good understanding of this function?
>> I
>> > would appreciate any help you can provide.
>> >
>> > case DAHDI_SIG_FXSLS:
>> > if (!(cursig & DAHDI_BBIT)) {      /*Dennis RINGING  */  /*<----- I
>> think
>> > this is checking if the state is different from a set value? needs
>> > clarification*/
>> >  /* Check for ringing first */
>> > __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_RING);
>> > break;
>> >  }
>>
>> This is just checking if new BBIT is 0, which would indicate a ring.
>> At the top of dahdi_rbsbits there was already a check to see if
>> cursig is different from the previously saved rxsig.
>>
>> > if ((chan->sig != DAHDI_SIG_FXSLS) && (cursig & DAHDI_ABIT)) {
>>  /*<------
>> > Why is it checking DAHDI_SIG_FXSLS? do I need to modify this to be 1111
>> > also?*/
>>
>> I'm not sure about this question. When using Loop start signalling,
>> the central office cannot indicate that the call was terminated to
>> the remote station.  Hence, that is why the only events sent to
>> __dahdi_hooksig_pvt are DAHDI_RXSIG_RING and DAHDI_RXSIG_OFFHOOK
>> when configured with FSX Loop Start signalling. So basically, that
>> check is to ensure that the ABIT is only looked at in FXSKS and
>> FXSGS signalling (which shares this code block with the FXSLS
>> signalling).
>>
>> >      /* if went on hook */
>> > __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_ONHOOK);  /*<----------I think
>> this
>> > is passing it to a function that reacts to the signal in this case the
>> > onhook signal?*/
>> >  } else {
>> > __dahdi_hooksig_pvt(chan, DAHDI_RXSIG_OFFHOOK);  /* <------ same here
>> but
>> > with the off hook? */
>> >  }
>>
>> Essentially, yes. dahdi_hooksig_pvt processes real state
>> transitions on the line and converts them into events for Asterisk.
>> For example, dahdi_rbsbits knows when a line goes offhook / onhook,
>> but that could result in a WINK, FLASH, OFFHOOK, ONHOOK event to
>> asterisk depending on the current state and timing of the actual
>> line transitions.
>>
>> Hope this helps.
>>
>> --
>> Shaun Ruffell
>> Digium, Inc. | Linux Kernel Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: www.digium.com & www.asterisk.org
>>
>> --
>> _____________________________________________________________________
>> -- 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
>>
>
> Hi Again,

Above Shaun was kind enough to point out that  "if (!(cursig &
DAHDI_BBIT))" was checking if the BBit is zero.  (thanks again!)  for what
values is this statement not true? it seems that no matter what I put in,
it comes out as true.

Thanks,
Dennis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130307/682c2b5f/attachment.htm>