Palmmicro

For many years AR1688 and PA1688 based IP phones do not have speaker phone function. This is a major reason that we are considered as a low-end VoIP device designer. Finally in this month, we will release the first version of AEC running on AR1688 with 0.44 software. With this version, users will be able to use speaker phone with G.711. Although this first version can not work as good as those from GIPS yet, we have confidence to improve it in later software versions.

The new AEC can work with all current AR1688 based device. However the quality will vary a lot with different products. The major reason is that most of our old speaker phone hardware is not well designed to ensure the linear gain requirement of current AEC algorithm when output becomes louder. Users need to test and set the speaker output to a proper value in order to make sure the AEC algorithm will work in the way it is designed.

We have also added a new "Ring Volume" option to help to use the speaker phone function more easily. "Ring Volume" can be set at higher value like 31 to ensure the incoming ring is loud enough. While the original "Speaker Output" can be set at a lower level like around 20 to make sure the AEC algorithm can work in good linear status.

 

The concept of VAD is widely accepted after ITU G.729B and G.723.1 included it as part of the voice encode and decode algorithm. Cisco had used the idea a little earlier before the G.729B standard. In Cisco systems, voice is first sent to a pre-process VAD system before passing to standard voice codec like G.711 and G.729. The open source Speex works in the Cisco way, its VAD part is actually independent of Speex codec itself.

Now it is more than 13 years after the publish of G.729B and G.723.1. We gradually find that VAD is less and less useful in today's IP phone. We do not need it to save bandwidth any more. And we care much less of the power consumption it can possibly save too. Instead, none-codec related VAD algorithm can always have bad effect on voice quality and network jitter buffer handling. There is no reason to keep a VAD option in the phone if G.723.1 and G.729B is not used.

Actually we are not alone. GIPS has not included a VAD part in its open source iLBC internet voice codec. And VAD is also not a part in GIPS' VoiceEngine product neither. What important today is AGC, AEC and PLC with dynamic jitter buffer handling.

 

 

Once a year, the open source SDCC development team will update a major version. On March 22 they released 2.9.0.
The Windows SDCC binary files still use MSVC 6.0 to compile. But the 10 years old MSVC 6.0 can not run with Windows Vista any more. As I was out most of the time in last week with my Windows Vista laptop, I was not able to try it until this weekend.

The only thing related with our AR1688 Z80 in the 2.9.0 release note is "many optimizations to reduce code size and increase speed in the Z80 backend". This statement is true compared with 2.8.0 release on May 2008. But actually the code size is larger than 2.8.3 test version which we started to use on Nov 2008 (with AR1688 0.40 software release). But anyway, I believe in release versions, so we will release AR1688 0.44 software based on SDCC 2.9.0.

As usual, the SDCC compiler is located in our software API SDCC\bin. It is smaller than those binary files directly downloaded from SourceForge because we only have Z80 and MCS8051 compiled in.

We need open source MCS8051 compiler too because our AR168M VoIP demo application was built on a 8051 controller.

To keep up with my 64 bits Windows Vista, I will not learn any other 8 bits CPU besides Z80 (in AR1688) and 8051 (in PA1688) any more. Palmmicro is also moving into 64 bits in 2009.

 

深夜的凤凰卫视中文台总在广告时间放一首《功夫》的歌。有句歌词一开始总听成“人生在世肯定输”，听了几遍觉得不对，看屏幕才知道是“人生在世看定数”。不得不再次感慨心理阴暗。贴张一周前爬怀柔小山时冒似不阴暗的相片。

 

Early IP phone and ATA users were "forced" to use '#' key to call out. Unlike PSTN, the devices usually didn't know when was the end of dialing. In old H.323 days lots of IP to IP calls were made, especially when testing with NetMeeting which came free with Windows system. Since '*' key was used in internet address as '.', the only choice was to use '#' as key to call out.

PSTN service providers did not like H.323 at all. But when their backbone network were changing into IP, they guess they need something at the terminal side too. MGCP protocol was the answer, but it is really a bad one. The only good thing for MGCP is that it has "digit maps", so devices know when the numbers are completed.  

SIP and IAX2 protocol did not consider the dialing difficulty at first. But later they added things like "Overlapped Sending" and "Server's Dial Plan" to solve this problem.

Inspired by MGCP "digit maps", AR1688 and PA1688 devices can set private "digit maps" to enable call out without special call key or '#', it is described here.

PSTN service providers actually used a lot of '#' in special services. So when we were testing PA1688 devices with Huawei and UTStarcom systems, we added special "service type" as "huawei" and "utstarcom" to disable '#' key to call out.

When we started AR1688 software, we decided to discard '#' key as call key from the beginning. However, many old customers still like to use '#' key, we had to add an option 'Use "#" To Call' later.

In United States, people call '#' as pound key. For a long time I had been wondering: what is the relationship between '#' and a pond?

 

当一个人回顾过去的时候，就说明他老了。

我坐在他面前，并没有发现这些年他有什么变化，还是很瘦很精神的样子。我第一次见到他差不多是十二年前，这些年彼此来往极少。他还在按照他印象中的我跟别人介绍“这个人说他什么都能做”，却不知道近几年我最常说的是“这个东西我不会”。

一九九九年，当王老板招我们这些刚毕业的硕士开Palmmicro公司的时候，曾经想请他来管理我们。当时开过几次会，比较有印象的是他一直积极要求我们找市场上现有的同类产品来定义我们要做的东西。后来他并没有跟随王老板，而是作为难得的海归人才进了一家民营家电企业。

三年合同期满，海龟游回美国，在一家公司打工半年。在二零零三年间见了一次面，我给他家里装了一个刚刚开始成型的PA1688网络电话。后来听说他很快又回国了，跟我们都认识的一些人在上海做。

二零零六年，我在深圳意外碰到一个以前上海Centrality的熟人，得知他在深圳做GPS产品，请这个人在帮他做软件。随后要了他的联系方式，跟他通了电话。

昨天见到他，知道了更多的情况。他在三个月前刚刚结束了跟一家上市公司另外一个三年的合同，现在在自己开公司做产品设计。当年的GPS产品因为技不如人没有做成功。很多年没有再回美国，他的绿卡早已经被移民局收走。他说“一旦回来后就再也不可能回去了”。

我没有问他这十年的感受，不过我想体会大体是差不多的。虽然这十年我们做得不算成功，但是并不后悔每一步的选择。

某客户问我们是否能在接下来十年中保证现在AR1688的供货。这当然是不可能的，十年对一个芯片的生命周期来说实在是太长了。要做一个计划用十年的产品，只能在芯片停产前的“最后购买”中买下够接下来十年用的货。

说实话十年对一个人来说也是很长的时间。回想自己的经历，十年前我只会编Windows和Dos下的程序。当时我被招进王老板开的老Palmmicro公司，开始做嵌入式系统的软件。从1999年到现在，Palmmicro改名Centrality，Centrality被Sirf收购，Sirf又被CSR收购，城头变换大王旗，我居然变成了一家英国公司的股东。

从英文版本中的两张照片可以对比一个人十年的变化，大的是２００８年照的，小的是在１９９７年。

 

A customer asked if we can keep shipping current AR1688 for the next ten years. The answer is definitely "no". Ten years is too long for a chip's life circle. The only way to do a ten year product is to take the "last order" chance and place enough orders for the next ten years plan.

Actually ten years is also very long for a man's life. Looking back myself, ten years ago I only knew how to program under Windows and Dos. I joined the original Palmmicro founded by Dr Wang ten years ago in 1999 and began to do embedded software since then. During those years, Palmmicro became Centrality, Centrality merged into Sirf, and then Sirf merged into CSR, surprisingly, I am an UK company's share holder now.

Check how ten years can change a man, the larger picture was taken in 2008, and smaller in 1997:

某国内运营商要采购价格低于120人民币的网络电话。我问某客户是否能做。答复是，如果AR1688免费的话大概勉强可以。我就想啊，一个低成本的普通电话到底要多少钱呢？今天到电子市场转了几个小时，发现20块钱可以买一个不带显示的，25块可以买个带显示的。

照了一个20块的电话相片，在前面英文版本中。

 

A China service provider is looking for IP phone under 120 RMB. I asked one of our customers if they can handle the business. The answer was, the target price could almost be true if AR1688 is free. Then I began to think how much a low cost PSTN phone is. Here is the answer after a few hours in the market today: 20 RMB can buy a phone without LCD and 25 can buy a phone with LCD.

Here is the 20 RMB phone photo:

 

Finally, we can now test VLAN function support, more than 4 years after Nic Bellamy wrote 802.1Q VLAN support for the RTL8019AS on PA1688 IP phones.

 

Even with Z80 running at 24Mhz, AR1688 IP phones can handle nearly 1Mbps UDP data. It is ten times more than normal VoIP streams. So Z80 performance actually does not matter with network.

When it comes to the voice jitter problem caused by periodic re-register messages (Rtp First), Z80 speed matters, as we use it for MD5 calculation. When doing single loop less than 56 bytes encryption, it takes 4.7 milliseconds on 48Mhz, 3.7ms on 60Mhz, and 3.0ms on 72Mhz.

Due to software interface difference, the "Rtp First" method described on the above link only works with RTL8019AS, we can not do the same to KSZ8842 nor DM9003EP, so we need to push MD5 calculation as fast as possible. Besides running Z80 on higher speed, we also plan to do more assembly optimization for MD5.

Z80 performance also matters with "real" DSP MIPS. We will put DSP in loop only allow interrupt handling when Z80 exchanges data with DSP. The faster Z80 can read and write DSP data, the more actual DSP MIPS can be used.

Why I am always talking about performance and optimization? Maybe because it is the only thing I know how to do it right.

 

10 months after writing Z80 Speed, we now have much more knowledge about the AR1688 Z80 performance and IP phone system limitations.

 

After 24 hours, let us see the AR168P network performance difference before and after software optimization:

1. Ping 2952 bytes, 19 milliseconds, slightly faster than RTL8019AS based GP2266.

2. Upgrade software, 16 seconds, same as GP2266.

3. TFTP only test, 208kbytes/second, or 1.66Mpbs, 11% better than GP2266.

So glad to see everything with KSZ8842 is better than RTL8019AS. Actually I was thinking KSZ8842 might be a little slow because its read and write procedures are more complicated. Obviously faster bus operation helps.

 

 

 

I know it sounds strange when I boasting our 8 bit controller network performance in a world 32 bit ARM or MIPS is widely available. But I just can not help it.

The network performance of initial KSZ8842 software is poor, because it is not assembly optimized, and unlike DM9000, KSZ8842 itself does not have hardware check sum generation. I am recording 3 major performance data here, so we can come back and compare the results after software optimization.

AR168P, or DigitMat GP2268, is our new hardware reference design based on KSZ8842.

DigitMat GP2266 is based on RTL8019AS + RTL8305SC design, it is still not in production because first they are waiting for AR168O/DM9003 design and now they are waiting for AR168P/KSZ8842 design.

1. Ping 2952 bytes, GP2266 takes 21 milliseconds, AR168P takes 35ms.

2. Upgrade software, GP2266 takes 16 seconds, about 41kbytes/second, AR168P 19 seconds, 34kB/s

3. TFTP only test, GP2266 reaches 187kbytes/second (1.50Mbps), AR168P 127kB/s (1.01Mbps)

 

Besides RTL8019AS and DM9003EP source code, users can also find part of developing Micrel KSZ8842 source code in the upcoming 0.40 API, under GPL license too. But it is not finished yet. We hope this chip can replace RTL8019AS + RTL8305SC in our reference design in the near future. Test boards are promising so far, especially that the chip is even cooler than RTL8305SC, not to mention the huge temperature difference compared with DM9003EP.

Kendin was the most VoIP-active switch company, its KS8993 was the first 3-port switch for VoIP applications (We still have a few of its sample chips got from their Santa Clara office many years ago). However, saving chip cost is not the only way to win, 5-port switch chip RTL8305SC wins the market with huge quantity outside of VoIP world. Kendin merged into Micrel during our period of focus on Taiwan made cheaper switch chips. We eyed on Kendin/Micrel again after DM9003 became a dead horse. Then we found KSZ8842, 2 port switch with 8 bit CPU bus, specially designed for voice and video over IP applications. Actually it was the first of those VoIP-aware chip again, much earlier in market before DM9003.

And it is really cool! I guess it is made of .13 process, while others like DM9003 are still .18.

 

 

RTL8019AS driver source code had been in PA1688 software API for many years, but it is only available in AR1688 software API until recently. This is because of our low level driver policy changed significantly from PA1688 to AR1688. However, we are gradually opening the source code of low level drivers upon those requests from costumers, starting from GPIO and SLIC.

The DM9003 driver source code request is coming from Davicom distributor who hope to help us to solve the software receiving data problem. The support people told me that they had helped many other DM9000 related customers in their designs just for this special problem! It sounds actually like a bad news for me, because I understand it as a common problem among all DM9000 users. Anyway, what can you do with a dead horse?

We are planning to release AR1688 software 0.40 next week. In this version, both RTL8019AS and DM9003 driver source code are included under GPL license, same as other part of the software API.

 

A Davicom distributor agent was asking me what was the production status of AR1688+DM9003. He seemed to be shocked when I told him it was not ready yet. He even showed me the article I wrote 5 months ago to express his doubt.

I was busy at that time and did not answer him in detail. During the past weekend, I was thinking that I always put good news on my MSN BLOG, maybe it is a time for change too, to keep up with the rest of the world.

DM9003 is hot. I mean, it is really too hot in temperature, should be careful with your finger when you touch it . This chip will make the whole IP phone board in a warm state. Among the 3 of our customers who made the sample phone board, none of them is thinking it is acceptable.

Another hardware problem with DM9003 is that it will generate extra noise to our voice communication. Although the noise is not as widely complained as the hot problem among our customers, our hardware engineering think it is not acceptable for our goal of low cost and high quality IP phones.

Also we still have a software problem, the receiving software will sometimes stop to work, personally I guess it is because of receive buffer overflow, but I can not find a good way to solve it yet.

All the above problems do not exist in our RTL8019AS design, so it is still too early to say farewell to RTL8019AS.

 

 

 

Time passes by quickly, it has been more than five years since we moved into current office.

Picture from outside:

inside:

We are providing more source code example on GPIO control along with current 0.39&0.40 software development. In SDCC\src directory, isr_gpio.c is added for 5x6 and 7x8 keypad designs, and slic.c is added for AM79R70 SLIC control.

5x6 keypad is used in AR168K and AR168KD IP phone reference designs, both designs are at sampling stage by different manufacturers.

7x8 keypad is used in AR168J.

AM79R70 is used in AR168L and AR168LS 1-port FXS gateway reference designs, which are not ready with software yet.

More information about GPIO control is here.

 

On Sep 10, old aredfox.com registeration expired and at once it was registered by "ENOM CORPORATE INC" located in "PMB 368, 14150 NE 20th St - F1/Bellevue, WA 98007/US".

When I visited www*aredfox*com link today to see what is the new owner is doing with it, I am surprised with the information provided by Kaspersky Anti-Virus: "The requested URL http://www*aredfox*com/ is infected with Trojan-Downloader.JS.Agent.cme virus".

As the original owner of the domain name, I can only express my angry feeling here and warn all of you do not visit the domain again!

To avoid miss-click on the Trojan link, I have changes all '.' to '*' on above texts.

 

In standard AR1688 IP phone hardware reference design, all GPIO are used as key and LED. We only provided high level key and LED control functions in API before software version 0.37.

To our surprise, a new manufacturer does not need those GPIO output LEDs but needs to use several GPIO as input. To make API simple and reduce code size, we decided to put GPIO control as source code with the release of 0.38 software.

In current API, sdcc\inc\gpio_sfr.h is added, and control example code can be found in sdcc\src\led.c, function.c.

 

Continue from yesterday, after 23 hours, still nobody online except those added woody@palmmicro.com as a new ID. It is a very effective way to know who are watching you closely.

36 hours after the change, everything back to normal, many people do not aware of the change at all.

Although the chat history of mine is ok. Others are watching the chat history with me "missing". Actually it is not really missing, the xml file is still there, just that MSN will save the chat with woody@palmmicro.com into a new xml file. So far, this is the only problem I found during those 2 days' experience of changing Windows Live ID.

I will go to change my printed name card tomorrow.

 

We stopped aredfox.com service a few months ago. Since that time, Li Jing and me were worrying about our MSN accounts, because both of us use aredfox.com email address to log on MSN. At that time, Microsoft only provided service to change Windows Live ID into a Microsoft owned service like hotmail.com or live.com.

Last night I found that I can change Windows Live ID into non-Microsoft owned service now. At once I changed woody@aredfox.com into woody@palmmicro.com. Things went on well at first, after email confirm, I can log in using new ID, and can access old chat history. The stupid Tencent destroyed all my QQ chat history during a forced "automatically" upgrade, it was a disaster. Because it was early in the morning, I was not very surprised to see nobody online. Besides, Microsoft website says that it will take some time to update database of my recent changes.

However, nobody is online today neither. I guess that something must be wrong. Several people in Palmmicro managed to see me online by adding woody@palmmicro.com as a new MSN contact, and I can see them as online 1 or 2 hours later. It gives me some comfort that they did not need to delete old woody@aredfox.com, seems that MSN knows to convert it automatically.

So now, 16 hours after I changed my Windows Live ID, I still have almost nobody online yet. And I am sure that I appear to be offline to those contacts too. I do not know if things will change after a few days. If anybody likes to contact me by MSN now, please add woody@palmmicro.com as a new contact!

 

For quite some time, this is the topic I am avoiding. Because I am afraid that my English is not good enough to explain bank switching in our AR1688 Z80 controller. But recently I am finding that some customers are doing much more than we expected based on our software API, it is time to say something any way.

To use RFC 3164 syslog to replace PalmTool UDP debug, syslog functions must be removed from original bank2 to common bank, so functions in all banks can use it for debug any time. If syslog is kept in bank2, but adding an TaskSyslog() function in main.c to do manual bank switching, this function can be used in all banks too, but problem will occur with const string passed in function parameter. For example, iax2.c in bank5 makes a function call UdpDebugString("Logon Refreshed"). The string "Logon Refreshed" is compiled as const in bank5, for example in bank5 address 0x9000. In TaskSyslog, it will pass 0x9000 address to bank2 function Syslog, and then Syslog will send the data in bank2 address 0x9000 out to the server. The only way to avoid this problem is to add another SRAM buffer in TaskSyslog, for example address 0x3000, copy bank5 0x9000 const to 0x3000 before switching to bank2, and call bank2 Syslog function with 0x3000 buffer address. Put syslog directly in common bank will have better performance and save unnecessary SRAM usage.

To be clear, please refer to Z80 memory map, and we will list some new words above with addresses:

"bank2": 0x8000-0xdfff, for each 32k program flash space, the first 24k bytes are different

"common bank": 0xe000-0xffff, for each 32k program flash space, the remaining 8k bytes are always the same

"TaskSyslog() in main.c": 0x0000-0x1fff, main.c functions are in the SRAM to run Z80 program

"bank5": 0x8000-0xdfff, same as bank2, AR1688 uses internal registers to identify different banks, those registers are mapped t"0xo Z80 SFR

"0x3000": 0x2000-0x3fff, this is the SRAM for global var and stack