AlarmReceiver on E1

Asterisk Asterisk Support
1

I have ‘successfully’ got the AlarmReceiver module to work on our E1 line. The E1 line uses aLaw and the AlarmReceiver uses uLaw. I have set up a panel that on power up sends 12 contact ID strings (of 16 dtmf chars). The panel transmits Contact ID at a cadence of 5ms on and 5ms off. I have hacked app_alarmreceiver.c to spit out the string after it receives being careful not to add cpu load on the app. It consistently receives the first 7 chars correctly. From the 8th char onwards we get a missing char and we mostly only receive 14 of the 16 chars.

This seems to me to be a buffer problem because the 1st 7 chars are always correct. I have tried recompiling app_alarmreceiver.c to use ALAW but things got worse. Has anyone got a clue on this problem and if it is a buffer problem whether the buffer can be increased?

This is what should be received from the 12 contact id strings of 16 chars:
8255181305000809
8255181143000039
8255181143000066
8255181143000075
8255181143000084
8255181143000093
825518114300010*
8255181143000115
8255181143000124
8255181143000133
825518130500002C
825518130500005#
This is a sample of what is received of the 12 contact id strings:
82551815000809
82551811000039
82551811000066
82551811000075
82551811430084
8255181430093
8255181100010*
8255181430005
8255181430004
82551811400133
8255181300002C
8255181500005#
where dropouts occur from the 8th digit onwards.
I have used both Asterisk 11.4.0 and 11.5.0.

Any help/feedback would be very much appreciated.

Lee

2

I don’t think that DTMF was ever intended to be transmitted at 100 baud, so I’m not too surprised if you have having troubles decoding it. Given that this information may be safetly critical I would want to go for reliability, not speed.

Mu-Law/A-Law transcodes should not compromise DTMF with standard timing.

Are you certain that the DTMF is being transmitted in band?

The normal frame period in Asterisk is 20ms, so I would suggest that trying to signal faster than that, especially if it turns out that the DTMF decode is happening early, faster than that is likely to cause problems.

3

Hi David,

Thanks for the feedback. Yes, I do agree that dtmf should not be transmitted that fast. Here in Australia we have most panels that transmit in that speed when communicating with receivers.

I don’t think that speed per se is a problem though as the dsp seems to be able to recognise and distinguish each char. I think it is some buffers on the card or the driver that is the problem… that does not hold enough before the next interrupt request is serviced…or something like that. As I said from the 8th char onwards we start losing chars…so it seems that 70 to 80ms later…which is a long time in the cpu world …the drivers have not been reactivated to perhaps start reading from the dsp.

I am hoping that someone who knows the hardware TE133F or someone who knows about the dahdi drivers can share some thoughts here and hopefully provide a solution.

Cheers.

4

You need to enable dtmf debugging to see whats actually being received.

5

Googling “dtmf timing” suggests that you sending 8 or more times faster than a DTMF decoder could reasonably be expected to cope with.

My guess, though, in this case is that the decoding is being done in hardware and events can only be read out every 10 or 20 ms, maybe only one event per poll.

6

In looking at this problem deeper:

  1. the dsp is able to process the dtmfs accurately even if it is with a cadence of 5ms on 5ms off
  2. chan_dahdi.c dahdi_read() reads 20ms frames from the E1 channel at a time. 20ms is equivalent to 2 dtmf chars.
  3. I have traced that dahdi_read() reads four 20ms frames correctly. It then misses 1 frame for some reason or other…losing 2 dtmf chars. It then continues to read the other chars.
    the dtmf string is 8 2 5 5 1 8 1 3 (0 5) 0 0 0 8 0 9
    where the 2 chars (05) is lost.
    I have repeated this same string a dozen times with exactly the same results.
  4. Why is dahdi_read() reading 4 frames (80ms=8 dtmf chars) and decoding the dtmf correctly then miss 1 frame (20ms = 2 dtmf chars)? Is it making way for the checking of voice or something else.

I am hoping that someone can shed some light into this problem. It looks like this problem is with the dahdi libraries or the configuration settings. Any experts on dahdi?

Any help/feedback will be appreciated.

7

Internally, Asterisk used separate DTMF start and stop events, so 20ms may well be 4 frames from the hardware.