在美国第一个周末，没有人陪同，决定一个人出去逛逛。于是就把旅馆Gest Service Directory里的Area　Map拍了下来，做成JPG放在PPC里作为简易地图使用。３５０D套着１７－４０L背在身上，７０－２００F4L和闪光灯扔在包里，还带了一些水和食品，以备急用。由于出门之前看了看天，昨天还是可以穿短袖T－Shirt的天气今天居然飘起了小雪，看来东部山区的天气真是多变；于是不远万里背来的羽绒服终于有了用武之地。把自己包的像个熊，然后出发。
　　此行的路线是沿着４１９（Electric　Rd）向北走，由KEAGY　RD至Sugar　Loaf　Mountain　Rd，最后上至半山的一个别墅区，俯瞰整个Salem地区。由于没有详细的地图，我事先也没有制定详细的步行路线，反正是沿着公路，一路向小镇背後的山区逼近。
　　今天天气不算很好，间或的有太阳，主要是以多云为主，天空中又不时的飘着小雪，有时一阵风吹来，让人摇晃不已。不过沿途的风景实在迷人。山区的冬天刚过，满地金黄的落叶；光秃的树干苍虬地扎向碧蓝的天空；还有一些新绿、嫩黄、和粉红也不时的出现在一些灌木从中，点缀着整个画面。各式的别墅依山而建，与山势地形相得益彰；没有过于人为的奢华，一切都显得如此自然、和谐。可能是由于休息日的原因，家家户户大门紧闭，只有院子里的狗儿们见了陌生人还是会窜出笼子，警觉的叫上两声。眼前的一切让人无法使之与美国的国际形象联系在一起；一边是桃花源式的安静生活，一边是硝烟滚滚的战场，我想普通美国人民还是会选择前者的。
　　一路停停拍拍，大概走了两个半小时左右在走到半山的别墅区。这里的别墅显然更加高大和美观，一般都是２层以上的，除了普通的车库、泳池、篮球架外，有的在主体建筑之外还有一些小规模的亭台楼阁，想是当地的富人区了。还是一样的含蓄和谐，丝毫没有做作的感觉。奢华的也许是屋子的内部，那是主人自己享用的；但就外观而言，是给别人看得，也就没必要这麽的张扬了。美国人的实用主义在这里体现的淋漓尽致了。
　　说是半山区，其实是众多山中较矮一座的山顶。远眺整个小镇全景尽收眼底。在小山顶转了不到半小时开始返回。至于没有到达真正Sugar　Loaf　Mountain的山顶，倒也不是特别的遗憾。享受过程比追求结果更重要，就象我沿途拍了几十张照片，但真正到了半山一张好的也拍不出，天气、光线的角度，器材这时候都成了出片的限制。还是一路走走拍拍的，还颇有几张满意的；甚至小手机里的片子也可能会超过DSLR的，这还是时机的问题。所以有时候还是随性随缘的好，努力去做了，无论何种结果都是令人满意的。
　　最后是拍摄的一点总结，光线还是很重要；光线好的情况下，器材的差异在这时候变的不那么敏感；因此拍风光片踩点、定路线和选择时间很重要。另外，有一个随身的小相机很重要，可以作为拍摄时的记录，以便以后多次拍摄时寻找合适的地点。还有，手头的１７－４０广角端的形变很厉害，风光片里一定要注意控制。
　　今天就到这里，下此继续。

Hi Jinbo,
Sorry to have the technical conflict with software developing group again, I mean to express my idea of what good test software is and how to design qualified test software I think for your reference. In order to make myself fully understood, I will use Chinese instead of English.
1.       什么是一个好的测试软件？
作为一个硬件工程师，软件方面的内容本来我是不应该发表过多的建议的；但是鉴于之前您让我来lead整个项目，因此我觉得我有义务也有责任承担起这部分的工作。之前我在原公司的时候在我的lead下做过2个正式生产测试仪的项目，其中的一个生产测试仪经受着多达50,000,000片样片／年的测试考验，还有一个测试仪经受着在－55℃～＋125℃环境温度下连续测试3个月的考验。事实证明，这些测试仪都能够长期稳定和有效的工作着。当然，我只是承担其中一部分的工作，还有很大一部分的工作由胡林安、满佳喜（都是我向您推荐的工程师）……这样的工程师来完成的。
从软件的角度而言，我不是科班出生的程序员，但像VB这类高级软件的代码至少也有上W行的coding经验；而且由于我们之前的设计都是基于8／32位微处理器和CPLD／FPGA的应用，firmware都是由我们自行开发的，所以在firmware开发方面可能有着十几万或几十万行代码的开发经验。当然，这些经验对于一个专业的电子工程师而言还差得很远，但从我个人角度而言我对一个好软件或者测试软件的定义如下：
a.       良好、专业的人机界面。
b.       高效、安全的运行过程。
c.        清晰、合理的模块划分。
d.       高效、合理的数据结构。
e.       简明、高效的coding风格。
f.         详尽的程序开发文档。
2.       如何设计一个好的测试软件？
针对我们现在的Wire-Check Tester，我在实现文件中针对以上要求提出了自己的设计思路，有抛砖引玉之意，但更重要的是想指明整个测试软件的设计方向。
a.       良好、专业的人机界面。
   我在设计实现文件中给出了一个界面的Demo，这个Demo是基于原来我所做过项目的经验而提出的。我个人的意见是界面的具体布局可以依据个人审美观不同进行改动，但其中提到的几大要素必须包括。比如像“用户模式”下的测试信息滚屏窗口，用来显示所有的测试操作和测试结果，最后结束测试时只需将该窗口内容存档就可以生成log文件。再比如“工程模式”下的通信输入、输出窗口也非常重要；通过观察该窗口的内容，可以直接了解通信命令的收发是否正常，从而在现场一旦发生问题时，支持工程师可以不借助任何外部仪器和调试程序直接确定通讯模块是否存在故障。还有“工程模式”下的测试命令输入行可以帮助测试程序开发人员快速有效的调试测试向量……当然，以上都是有关软件界面的问题，其实真正的人机界面还远远不止这些。
   下面我要提到的“测试向量”（Test Pattern）也是人机界面的一种形式。所有专业的电路仿真软件、IC测试仪（如J750……）、PCB自动测试仪（如AEBI测试仪）……都将测试向量从测试软件中独立出来。这样，验证、测试工程师可以在不熟悉任何软件的情况下，通过简单的文本编辑器开发测试向量，完成对产品的测试过程开发。但是这里必须明确一个概念“什么是测试向量？”简单的说测试向量就是一组测试激励和指标的集合。举个简单的例子，一个与电路有2个输入A,B，1个输出C，则以下是这个电路完整的测试向量：
A  B  C
0  0  0
0  1  0
1  0  0
1  1  1
       基于以上的认识，我们提出了在我们的Tester软件中测试向量文件.VEC文件的设计思路（参考设计实现文件相关内容）；并根据我们的实际情况，添加了命令字的内容。但是大家必须明确一点，测试向量文件应该仅仅是一组基于测量的输入、输出信号值，最多添加一些注释和索引信息，其他多余的信息（如庞大的Debug信息），放在该文件中是不合理的，也是不合逻辑的。但是，考虑到再建一个DEBUG信息文件的的工作量，我在此已做了妥协，加上了所谓“From”和“To”的内容，在形式上可以看作是注释信息（向量开发人员所做的注解），但实际上可以用作DEBUG信息显示。而且我个人认为，这样的DEBUG信息足够了，有时候在系统设计上我们必须做取舍，但必须注意在哪里做取舍，至少在这里的妥协我认为是值得的！！
    回到人机界面的问题，我一直认为专业的测试开发工程师应该依靠文件而不是图形界面开发测试流程；因此一个简单、可靠且能被最普通的文本编辑器编辑的文本格式用于.VEC文件显得十分重要。
b.       高效、安全的运行过程。
      这里主要要求程序设计有一定的健壮性。如各模块异常处理机制等。另外我在实现文件的有关“File System”章节特别强调文件的保护的重要性和要考虑的设计要点，因为测试过程记录文件（.log文件）和测试结果记录文件（.dat）是测试仪赖以生存的重要文件。
       c.       清晰、合理的模块划分。
   我在实现文件“Software Design Implementation”章节的开始就给出一个分模块设计的Demo，这里并不是想给整个软件设计定一个死的条条框框，我的目的有两个。一.是告诉软件开发组：你们现在马上要做的事情就是分模块，而不是其他的事情。不要过于纠缠在诸如信号的分配等设计细节上，模块一旦划分完毕，除了仪器控制模块和其下层的通讯模块不能进行外，其他模块的设计可以在仪器到来之前完成。分模块每耽搁1个工作日，实际相当于耽搁3人×天的工作时间。二.是给大家一个概念，一个测试软件至少应该有几部分。大家可以在这个基础上再增加，但是不能少于这些部分。
       在软件开发的具体过程中，我不应该去指手化脚，但是从整个项目的开发过程中，作为leader我有必要基于我的经验去把握整体的开发方向。我认为，作为一个R&D项目的Project Leader，我所要做的事情就将项目分成若干模块，定义模块接口，在系统级调试前，向各模块设计人员屏蔽其他模块的设计细节。因此在模块设计时，各组、各人按照要求做好自己模块的事情就可以了。
       回到有关软件模块的划分方法，我的思想基本是基于分层设计的思想。软件开发和项目开发的道理基本相同，分层、分模块设计，各模块之间必须互相屏蔽设计细节。这样做的好处不仅仅是为了听上去更符合软件工程的原理，而是有非常大的实际意义。首先，一个软件是否分层明确会直接影响到这个软件的维护成本。我个人认为，一个程序的设计者在程序完成3个月后，如果不能在30秒内在源代码中找到任何一个关键变量的定义、所在位置，互相关系和作用阈；那么他的继任者将会花上10分钟以上的时间去搞清楚这个变量的作用，甚至永远也搞不清。其次，合理的分模块设计可以大大提高整组的开发效率，以软件组现有3人而言，在3周内将会完成9人×周的工作量。按照我现有的模块划分，除了“仪器控制”“通讯”，只有7个模块需要完成；即使1人×周完成一个模块，软件组仍有充足的时间完成设计。事实上除了命令解析和文件处理外，每个模块的实现时间恐怕不会超过0.5人×周。所以合理、清晰的分层、分模块设计非常重要。
       d.       高效、合理的数据结构。
       在实现文件中，我提出了4个文件的概念，反映在程序设计中，即是4个相关的数据结构。当然程序中还有其他的数据结构，但在这里我仅仅说说我对这四个文件的理解。
       .VEC文件之前已经谈到过，基本上是一组测试方法、输入、输出的组合。.DAT和.LOG文件的区别在于平时我们不会去关注.LOG文件，我们只需要获得包含测试结果的.DAT即可，但是一旦出现FPY或者测试设备发生问题，我们可以从.LOG文件记录的测试操作中获得非常有用的信息。下面我想重点说说 .CFG文件。
       .CFG文件主要是用于实现软件参数和测试参数的自动配置的。我们知道，一个软件运行时都会调用一个或一组配置文件（如windows启动时调用win.ini等文件），这是由于有时候我们并不希望把很多参数写死在程序中（如Windows的启动等待时间，开机需要自动运行的程序列表……），这样做的后果是往往为了更改一个参数我们必须去发布一个新的软件版本（如为了修改Windows启动等待时间）。在我们的测试程序中如GPIB仪器的地址号、采样求平均次数、.DAT文件 .LOG文件自动保存间隔时间、测试出错停／否……都是可配置的参数，将这些参数写死在程序中这是不合理的，也是不符合专业软件开发的要求的。为此，我们需要将这些参数放在一起，保存在一个配置文件中；而且在我们的测试软件中，我并不希望这些参数能在界面上被更改，对操作员来说，它们仅仅是可见的就可以了。这样做的好处是不言而喻的。而且对于设备的支持工程师来说，在需要的时候用一个通用的文本编辑器去编辑这个.CFG文件比去在界面上靠鼠标修改这些参数更合理。回到程序可扩展性的角度来说，有一天我想为测试程序增加一条新配置时，无需修改界面，只要直接修改.CFG文件和添加底层的应用服务程序就可以了。
       最后讨论一下这些文件的实现。其实这些的文件用VB实现是非常方便的，都有专门的函数可以调用。而且像.CFG文件这种配置文件，程序全局变量初始化时只要读入该文件并将其送入相关全局变量中即可。所增加的仅仅是读文件一个操作而已。真正会有多大的代码量，coding的人应该很清楚；而且这四个文件的读写程序几乎可以相互借鉴，工作量远远小于我们想象（我个人的经验是完成一个完全不同的3种文件读写模块 需要2人×天）；这里我想说的是：能不能实现和我们怎么定SPEC没有太大的关系，定SPEC的时候我们只要考虑是否需要这样定。另外想强调的一点是这些文件的文本格式，现在业界通用（如各类专业仿真软件、J750……）的就是普通TXT文件的格式即ASCII格式，这样的好处是最普通的文本编辑器都可以查看与编辑，同时导入EXCEL、MATLAB等数据分析软件异常简单。
       e.       简明、高效的coding风格。
    关于coding风格，各有不同，而且VB我也只是写过几W行，属于新手，没有资格评论别人。但是有一点我要提出的是代码注释要详细，不需要一句一个注释，但也最好不要像我原来一样一段才一个。我的风格也不好。这个东西还是涉及维护成本。另外，在多人协同coding时，有必要先统一变量的命名规则，这点很重要。
    f.         详尽的程序开发文档。
    我个人估计这项工作会在我去Salem之后开展，但是我依然要提出我的看法，我觉得好的项目管理中，文档不比产品本身地位低，甚至有过之而无不及。随着我们Team以后的发展壮大，Salem肯定会把越来越多的任务交给我们来完成，设计难度会越来越高。这时没有一定的技术积累是不行的，而技术积累就是体现在文档中的。我原公司的态度就是“留文档不留人”。
    以上是我个人对这个项目的测试软件开发的所有看法，有所偏重一定也有所不足。在整个项目的lead过程中我一直是以要求自己的标准来要求各组的，当然我不知道大家的实际的看法是怎么样的，也许有人会觉得过于严格，但是我想这是我们组的第一个项目，仅仅把东西做出来最多只是60分；做的符合规范，易于扩展和维护也只有80分；只有形成了一个好的开发流程，以后无论有什么项目都可以依次贯彻执行下去了才是满分。
    另外，关于现阶段诸多争论的问题上我先检讨我自己，我犯的最大的错误是在项目策划阶段没有起草一个详细的SPEC而去直接写实现方案，导致现在在实现阶段对很多项目目标不明确，从而引起诸多争论。这个是由于我项目管理经验不足而造成的，不怪别人。
   但是我想是人都会犯错误，几年前我也有控制不住继电器的时候、也有被冰箱压缩机启动电流打的MCU不断重启的时候、直到现在我还困惑于我的HelloWorld程序为什么在ucLinux跑不起来。每当这时，我很希望有一个Experienced people 告诉我为什么，因为他能够帮助我在技术的道路上不断的前进。Unfortunately，没有，所以我不断的在一次一次的失败中学习。现在我愿意与大家share我的这些经验，就是希望大家不要再去走我之前走过的弯路，完全是出于为项目和Team的发展考虑，没有任何的其它原因。我想这就是劲波您希望我带到Team中来价值不是吗？现在项目由您来重新lead，我依然会像过去一样，把他当作自己的项目来做。我对软件设计的看法基本上也就这些了，上面明确提到的一些设计细节是我个人认为不能作出设计妥协的，其他的设计细节我个人不关注，可以由Product Support组给出要求。
Thanks.
        
Best Regards
XuYe

匆忙的结束了三天在青岛的工作，我们准备搭乘1月12日21：40的飞机去大连，最糟糕的飞行经历就此拉开了序幕：

2006年1月12日
20：00 在酒店订的面包车准时来到预约点接我们，本以为酒店的车么总是还可以的，虽然不是什么好酒店。结果上车才发现这个车脏脏的湿湿的，像是刚运过什么货，而且车上除了司机还有另外一个大汉。这个司机好像不咋认路，车一开出去就开错了地方，小朋友悄悄的跟我们说：“这两个人会不会把我们拉到什么荒郊野外去啊，就我一个男的，搞不定这两个人的啊。”说得我们心里怕怕的，不过另外一个大汉打从我们上车起就一直在睡觉，倒像是司机怕被打劫找的保镖押车。

20：30 司机终于有了方向感，开着他的小破车放着音乐一路欢快的带着我们赶往机场。

21：00 我们很准时地到了机场，结果发现我们的航班Delay了，Delay到23：10。心里一阵郁闷，心想今天可得要几点才能睡下啊。但也没办法，又不能自己游过去，只好Check-in后在候机厅等着，顺便做了一会Working Paper，时间紧迫啊，可得抓紧。

23：10 飞机这次倒是很准时地到了，我们得以在23：10准时起飞去大连。从青岛飞大连不远，大约50分钟的样子，预计00：00能到了。那么，乐观一点的话，最晚1：00能睡了吧。

23：50 在快要到大连的时候，飞机上的广播响了，说是由于大连的天气不适合飞机降落，机长决定飞去沈阳，预计于00：30降落在桃仙机场。听到这个消息，真是郁闷之至，这么深更半夜的降在沈阳，叫我们住哪里去，就算是机场给安排住宿，估计也不会好到哪里去。MD，青岛飞大连就这么点路，要是大连天气不好干吗要起飞，难道一个小时之内的天气都预测不出来吗？！

2006年1月13日
00：20 终于又煎熬了半个小时，飞机到了沈阳上空，此时广播又响了起来，这次说由于沈阳的天气情况也不适合飞机降落，机长决定继续朝北飞，预计在1：00降落在长春机场。天哪，这次彻底绝望，我已经由郁闷转为不安了。WolfGG没有能准时收到我报平安的电话，他一定很担心呢，这都比计划到达时间晚了一个半小时呢，飞机上又不能用手机，WolfGG联系不上我，一定是睡不着了，可怜他明天还要上班的呢。照理说青岛飞大连也就一个小时不到的路程，还是那个疑问，难道一个小时之内的天气都预测不出来吗？！要是大连天气不好干吗要起飞？我开始怀疑是不是飞机坏了，不能降落，天气不好是不是为安抚乘客而制造的借口，要不然干吗只是很笼统的说是天气不好，而不说天气到底是哪里不好，是有雾还是其他什么；要是到了长春还不能降落，飞机上的油还够不够坚持把我们送到下一个机场，我想到时候就该去哈尔滨了吧。恐慌啊恐慌，乘飞机几乎从不买保险的我，这次居然还心血来潮的花了二十块钱买过一张保险，要真有什么三长两短的，还能拿个四十万，但我长到这么大，就值四十万？继续胡思乱想，想到这次出门前，我妈和WolfGG同时眼皮狂跳，再加上这次我鬼使神差的买了保险，啊……不能再想下去了，不要自己吓自己，既然上了飞机就一切都已经Out of control了，任你再有本事也没有用，听天由命吧，还是睡觉算了，说不定一觉醒来就已经落地了呢。

1：00 这次总算没让我们失望，飞机终于安全的降落在了长春机场。飞机一落地第一件事就是给WolfGG打电话报平安，我想他肯定是担心了半天，还没睡着。下了飞机，长春市一片白雪茫茫，我们真是越飞越远了呢，本来的青岛还离目的地近一点，结果折腾一晚上到了个更远的地方。

2：30 真佩服我们这一飞机的人，个个都很有涵养似的，居然没有人和机场的工作人员吵架，本以为在飞机上不吵是怕影响机长情绪，考虑到飞行的安全问题，结果下了飞机也没人吵。机场工作人员说我们今晚要在长春过了，预计明天乘中午11：30的飞机回大连，现在给安排住宿，于是我们一大堆的人就乖乖的等在候机厅。等啊等，等了一个多小时，终于有车来接我们了。上了车，车子开啊开，又开了足有一个小时来到了一个小破宾馆。

3：30 终于在凌晨三点半的时候我们得以在机场安排的地方休息了。这是我迄今为止住过的最破的宾馆，与其说是宾馆不如说是招待所更贴切一点。

首先，我们是没有房门钥匙的，到了房门口要叫服务员来开门，也就是说只有服务员才有我们房间的钥匙，顿时很没有安全感，好在我们行李多，搞了四个箱子堵在了门背后。后来又想到，万一半夜真有人闯进来，碰到了箱子发出声音把我们惊醒又怎么样，难道我们两个弱女子能打倒强盗不成，还不如索性装不知道来的安全一点，算了不想了，还是洗洗睡觉吧。

现在要讲其次了。其次，这个宾馆的水很有问题，不知道是不是很久没有人用水的缘故，这个水管里面好像都锈掉了，开出来的水先是发黄，然后并未随着水的流出而把水管冲干净，水的颜色越来越深，我几乎觉得这个水就是红的了，就像是中学里做化学实验看到的正三价铁离子的红色。妈呀，这还能洗漱嘛，得了，今晚就什么也不干了。

最后，这个招待所的床也很不干净，掀开被子还能看到床单上有头发丝。这时我庆幸自己穿的是那个超长羽绒服了，今晚就穿羽绒服睡吧，长到脚跟的羽绒服，配上其超大的帽子，穿着这个行头睡，就像是睡在睡袋里一样的。Frieda羡慕的看着我的装备，说我全身上下差不多都Cover了，而她自己的短款羽绒服还没过膝，只好靠招待所的被子遮遮下半身了。

我想实在是太累了，躺下没多久居然也就睡着了。

8：30 被一阵电话铃吵醒，本来不想去接的，后来想到是不是通知我们能飞了，于是很不情愿的爬起来抓起了电话。结果是通知我们去吃早饭，没兴趣的说，肯定不会有什么好吃的，再说现在也没啥胃口。顺便问了一声中午11：30能准时起飞吗，得到的回答是还不肯定，等待机场那边的通知，哎……看来是没啥希望了，再睡一会吧，挂了电话继续睡觉。

9：30 这次又是被一阵阵急促的敲门声吵醒，得到可以起飞的通知，要我们马上到楼下集合，好在我们是穿戴得很整齐的睡觉的，爬起来就能走。来到招待所门外，经过一整夜的雪，地上的雪已经积得很厚了，我觉得这车一定开不快，11：30起飞希望不大。

11：00 车子又开啊开，开了一个多小时到了机场，一路上尽是扫雪的清洁工，蛮有意思的。我坐在第一排，视野开阔，再加上地上滑，车开不快，于是我在车上拍了若干照片，以留作纪念，后边会贴出来的。

12：00 飞机起飞了。

13：30 飞机降落在了大连机场，差不多Travel了一天一夜，终于到达了我们的目的地，好累啊。

14：30 到了酒店Check-in后开始洗漱，客户那边还是要去的，总不能蓬头垢面的吧。

16：00 到客户那边已经是下午四点了，他们都要下班了，把我们的遭遇说给了客户听，不过好像并没有得到多大的安慰，哎……客户真没有同情心的说。

好了，汇报到这里也就差不多了 ，下面贴几张照片给大伙开开眼哈，拍得不咋地，以记录为主：

深更半夜滞留机场的可怜旅客们

有部分和机场工作人员交涉的人们，不过都很文明，没有吵架的

下了一整夜的雪，长春积了很厚的雪

马路上到处都是扫雪的队伍

由于积雪，车子排起了长队

积雪的长春机场

临上飞机拍得，不像是飞机场啊，倒像是某旅游风景区

祝WolfGG生日快乐，身体健康，财源滚滚

Cissy终于用上了第一件奢侈品，庆祝一下

猫MM不在这两天闲着无聊，实在受不了联想的那个破音箱，今天去JS那里搞了个漫步者R1000TC北美版
结果JS自称是代理，从他那里拿到的价格比京东还贵了5块钱，我开始不爽了……
于是到家拿出螺丝刀，我拆我拆我拆拆……
先把前级的运放拆下来 费了我九牛二虎之力 用吸锡枪折腾了40多分钟才搞定 这个PCB果然到底是国产的东东 成本便宜 质量不行 有些焊盘已经翘起来了 不管三七二十一我先焊个DIP8的座上去 然后用什么运放就由我了阿
手头没有网友看好的OPA2134，就弄了个手头找得到的LF353来苟且一下。以前用过LF353，感觉还不错；从参数上看，至少比网上很多人看好的NE5532要好，估计比原配的MC4558要好上一个数量级。尤其是从电源抑制比的角度看，353比4558要高10dB以上；而且353是JFET输入，输入阻抗高对前级驱动能力的要求就比较小。另外我个人比较关注SR特性，也就是俗称压摆率；353是>8V/us，而4558>1.2V/us；因此有理由相信353的动态特性会比4558好，高频响应会比4558要好。OPA2134的SR>15V/us，因此我相信以后换上OPA2134后前级电路的高频特性会更好。另外OPA2134和353的带宽增益积达到4MHZ比NE5532的1MHZ要好，因此对高频信号的衰减会比NE5532要小。还有忘了说通道隔离度，OPA2134达到135dB、353这点和4458差不多都有120dB。
换上LF353后，发现高音区的音质有了一定的改善，整体效果提升不明显;用示波器观察变压器次级过桥后的正负电源端交流纹波有200mV以上，要提升音质必须抑制电源的纹波。
一开始我怀疑是两个滤波电解2200uF／50V的高频特性不好；但我手里没有日本的品牌电容无法替换，只能在2个滤波电解两端并联1uF的CBB电容，开机后用示波器观察电源纹波依然有200mV作有，音质没有明显改善。观察纹波的频率为100HZ，正好为50HZ桥式整流后的纹波频率，因此可以确定是由于前级的2200作为储能电容容量不够大。论坛上看到有网友抱怨漫步者R1200的3300uF也不够，因此随手找了两个2200uF/25V并上去。开机一测电源纹波小于100mV，播放歌曲高音清脆，中音圆润，层次感明显。最后在353的V+端对地飞一个104的瓷片电容（V-附近没有GND就不飞了），装箱开始堡音箱……
总结一下：
1.厂家对成本的控制实在过分,从线路的角度看R1000TC和R1200TC的差别可能仅仅是变压器功率的差异和前级滤波电容容量2200对3300差别;加在一起估计也就1-2块钱左右，实际价格差不少。
2.厂家用的材料不厚道，LF353比MC4558贵不了一块钱，为什么不用LF353或者NE5532？
3.音响类产品电源绝对是关键，电源纹波做小了整体性能才能上去；以后如果自己设计功放线路的话直接上大功率线型源，功放电路的品质绝对会比现在市面上的东西高很多。
4.买现成的有源音箱的话，最好自己加电源滤波电容，只要体积不受限能加多大加多大；这比去换一根所谓的金线要有效的多。
累了，今天就折腾到这里，过两天去倘科技京城，掏块好点的运放再玩玩，还有就是折腾一下功放级，呵呵。

今天周日，睡到日上三竿头，懒得出去吃饭了，还好我早有防备，昨天买了恶大的苹果和梨，就吃它们啦，呵呵

今天飞青岛，又碰上飞机误点，
本来七点二十的飞机一直到九点半多才飞，
不知道是不是我RPWT，最近三次乘飞机次次延误，
靠，气死我了

同事要去深圳出差，顺道去HK Shopping，于是Cissy打算托她带点香水什么的咚咚回来，但是Cissy是一个对香水是毫无研究的MM，于是今天中午快快的解决掉了中饭后，召集了另外两个MM一起去梅龙镇试香水，呵呵……是不是有点BT啊
梅龙镇的香水还是挺多的，MMs从CD，Chanel，Lancome，Issey Miyake，一个品牌by一个品牌，一款产品by一款产品的试过来，闻了不下十种香水，三个人六只手也分别被喷上了不同的香水，后来我们的鼻子几乎已经失灵了，开始感到头昏昏的，我们称之为香水中毒，呵呵……自找的哦。
香喷喷的回到Office，鼻子还没缓过来，听说咖啡香可以解毒，于是贤惠的Cissy冲了一杯咖啡给JMs解毒，不过好像效果并不像传说中的那么神奇，那就随它去吧，后来不知什么时候我们的鼻子终于正常了。