Support for A226m board-ID

[rokafeller]

Hi, first of all thanks and congratulations for this amazing project. I successfully compiled and made your driver work on a Pirelli A226m router, which also features a Le88266 VoIP chip. Unfortunately in your src/board/board.c board-id check the A226m board-id is missing, thus leading natively to a non-working driver as the absence of a recognized board-id won't allow the driver to load.

I had to add this line at line 584 of src/board/board.c to make the driver work: || (0 == strcmp(board6358_desc.name, "DWV-S0"))

The inclusion of the A226m board-id DWV-S0 in the allowed boards check would make life easier for those compiling your driver.

thanks

[pgid69]

Hi

Thank you for your feedback. I saw that you mention the project on the OpenWrt wiki page on Pirelli A226m, which is great. I will add your modification to src/board/board.c quickly.

Thanks

[pgid69]

Ok i modified file board.c. But i don't follow exactly your suggestion because it would imply declaring that the router has a Le88266, that support Wideband codec. So i duplicate description of hw553 and I switch the order of the lines Can you confirm that it works (both phone lines) ?

Thank you.

[rokafeller]

A226M mounts Le88266 and not Le88221. Here my findings:

• Minor issue: with the current updated version of board.c both FXS ports are working but they are swapped (1 is 2 and 2 is 1). By telling the driver A226M behaves like HW553 in board.c - if (0 == strcmp(board6358_desc.name, "HW553") || 0 == strcmp(board6358_desc.name, "DWV-S0")) - the order was correct.
• Supported openwrt versions. I managed to have this driver working on Attitude Adjustment only. When compiled for Barrier Breaker or Chaos Chalmer there seem to be an incompatibility with bcm63xx-spi - see logs. I read this has been already reported as an issue, but in my case there are no instances of bcm63xx-spi driver explicitly installed nor loaded (see lsmod). Is this something you know how to deal with? AA is pretty old and would be great to have the driver working with recent openwrt versions as well.
• Issues with ringback tone. When placing a call to PSTN through SIP provider, during the ringback tone -which you can barely hear- the audio passed to the phone is terribly sloppy and disturbed (sounds like very strong electrical interference/malfunctioning on the circuit). Once the other side picks up, voice communication is perfect. During the sloppy ringback phase, the asterisk log is flooded with such messages [Apr 26 22:13:25] WARNING[1460]: <snip>/build_dir/target-mips_uClibc-0.9.33.2/asteris:3509 bcmph_chan_write: Only wrote 0 of 160 bytes of audio data to line 1. This happens if the call is originating from FXS ports only, soft phones not leveraging the driver and calling PSTN work perfectly in the same setup.

thanks again for your support! this is a great project!

[rokafeller]

updated info in previous post

[pgid69]

Thanks again for your feedback.

• I updated board.c, because A226M uses a Le88266, and switch the order of the lines. I hope it will be ok.
• I updated readme about problem you have with bcm63xx-spi with OpenWrt 14.07 and 15.05. If you apply the patch that i mention and recompile the kernel to remove bcm63xx-spi, the driver will work.
• I will investigate the problem of ringback tone because another user reported it. I hope i will reproduce it this time in order to fix it.

[rokafeller]

very much appreciated, thanks. I have an A226M unit for testing purposes, if you need me to help and perform any specific test/trace just let me know.

[pgid69]

Thank you for your proposal. Perhaps it could help me if you send me debug log of Asterisk.

You have to change file /etc/asterisk/logger.conf to request that asterisk write debug messages at least on the console (you should have a line like console => notice,warning,error,debug ). Then after reloading conf files or restarting asterisk, launch asterisk -rvvvvvvvvv to access the Asterisk console. And then try to reproduce the problem.I need debug messages from the moment you pick up the phone to make a call

Else the problem occurs when the call is originating from the FXS line. Ok. But whatever the destination you try to call ?

Thank you for your help.

[rokafeller]

• now board.c has the right port numbering
• the patches to disable bcm63xx-spi in 14.07 e 15.05 work pretty well
• find here the asterisk logs of an attempted call towards PSTN (phone# is 1234567890, a fake number instead of the real one I was dialing) starting from the key pressing. This ringback issue happens with FSX port calling a a PSTN number. Calling an internal SIP phone doesn't originate this.

thanks. should any other test be necessary let me know :+1: cheers)

[pgid69]

I'm sorry but i'm not able to extract the asterisk logs I run tar xzvf phonelog.tar.gz but i get a binary file whose size is only 45 bytes. phonelog.tar.gz is only 180 bytes long which seems very small.

[rokafeller]

try now, it should be working. logs thanks

[pgid69]

This time, that's ok. I already see strange messages before you get "bcmph_chan_write: Only wrote 0 of 160 bytes of audio data to line 1". I will try to investigate and i keep you informed. Thanks

[rokafeller]

was in a bit of a rush, here some additional details:

• the log traces an attempt to call a PSTN number (1234567890 in the log for the sake of privacy :) )
• the call is not answered, ie. there is only dialling+ringback tone+hook up phases
• an additional issues on top of the choppy audio during ringback is that after hooking up the phone, channel is not freed in asterisk straight away. You can see that from the moment I hook up around [May 1 22:43:55] DEBUG[2804]: <uClibc_path>/asterisk:2445 bcmph_do_monitor: Line 1, hookstate changes 1 times. Was 3 and is now 2 and the moment the call is eventually destroyed and the channel freed [May 1 22:44:28] DEBUG[2801]: rtp_engine.c:298 instance_destructor: Destroyed RTP instance '0xd82858' a lot of things happen and it takes around 30s.
• didn't think about it: do you need a log of an answered call, ie. when the called user picks up and audio starts to flow normally?

[pgid69]

Hi

Thank you for the log. But alas i don't understand what's happening : the line [May 1 22:43:51] DEBUG[2805]: <uClibc_path>/asterisk:3380 bcmph_chan_write: bcmph_chan_write() : changing codec and switching to mode off talking, before call is answered is normal but the lines [May 1 22:43:51] DEBUG[2805]: <uClibc_path>/asterisk:3393 bcmph_chan_write: bcmph_chan_write() : switching to mode off talking, before call is answered should not occur, because mode off talking has already been set. I finally succeed to reproduce the problem if i add playback(calling, noanswer) at the start of my dialplan. I'm still investigating.

For the issue of the delay between the moment you hook on the phone and the RTP instance is destroyed, i have no explaination. I think it's normal. What is important for me is that the call to bcmph_chan_hangup occurs at 22:43:56 only one second after hookstate change is detected.

Gilles

[rokafeller]

excellent, still if you need any testing on my side just let me know. I was also playing around with the code generating the off-hook / dial tone, since that doesn't look to be changing regardless the country setting in bcm3xx_phone.conf. But this is a another topic, we might discuss about it in another thread.

cheers

[pgid69]

Hi

I've just committed changes. Let me know if it fix the problem of messages bcmph_chan_write: Only wrote 0 of 160 bytes of audio data to line 1...

BR

[rokafeller]

Hi, very good job indeed, the modifications you applied to the code fixed the issue. Now the ringback tone from pstn is properly passed to the phone. excellent! It took me a while to test it because I concurrently hit another issue with wifi and had to take care of that before properly verifying this. I'm curious - was it a bug or anything not handled properly in the setup of the audio flow?

As I anticipated in a previous message, I have few questions about the off-hook tone. It's not a malfunctioning, more of an aesthetic improvement :) should I open another issue for that?

again, thanks a lot!!!

[pgid69]

Hi

Thank you for your feedback. Indeed the setup of audio flow was not properly handled so it was a bug. For the tones i prefer that you open another issue.

BR