这是一款四路的网络继电器, 本来之前设计好的那款, 没有加锁存, 这一款是前几天拿去重新生产的带锁存的版本,通过网络控制四路继电器的开和关。
最近电路板做的频率有点高，这款出来后会暂时降低电路板的出品频率，因为软件的框架还需要继续完善。

之前的网络红外学习控制器, 为我自己实现了卧室空调和风扇的自动控制(我还特地买了红外控制的风扇), 再也不用一大清早被空调冷醒; 或者定时关空调又会热醒的问题。

然后我又做了wifi版的, 通过wifi接入互联网, 省掉很多主板空间, 整个wifi功能所占的空间跟一个RJ45占的空间差不多.

焊接的时候还遇到问题, 第一块板子不知道哪里没焊好, 主控芯片总是不能正常运行, 还好, 第二块成功了, 主控和wifi都没问题

RFID卡每个区分4个块, 前3个块为数据块, 第4个块为控制块, 控制块的结构如下:
密码A(6字节)|存取控制码(4字节)|密码B(6字节)

以下转自: http://blog.sina.com.cn/s/blog_9ed067ad01010i4v.html

S50和S70的块分为数据块和控制块，对数据块的操作有“读”、“写”、“加值”、“减值(含传输和存储)”四种，对控制块的操作只有“读”和“写”两种。

S50和S70的每个扇区有两组密码KeyA和KeyB，所谓的“条件”就是针对这两组密码而言，包括“验证密码A可以操作(KeyA)”、“验证密码B可以操作(KeyB)”、“验证密码A或密码B都可以操作(KeyA|B)”、“验证哪个密码都不可以操作(Never)”四种条件。

这些“条件”和“操作”的组合被分成8种情况，正好可以用3位二进制数(C1、C2、C3)来表示。

数据块(每个扇区除区尾块之外的块)的存取控制如下表所示：

控制块(每个扇区的区尾块)的存取控制如下表所示：

S50的每个扇区有4个块，这四个块的存取控制是相互独立的，每个块需要3个bit，四个块共使用12个bit。在保存的时候，为了防止控制位出错，同时保存了这12个bit的反码，这样一个区的存储控制位在保存时共占用24bit的空间，正好是3个字节。我们前面说存取控制字有四个字节(区尾块的Byte6～Byte9)，实际上只使用的Byte6、Byte7和Byte8，Byte9没有用，用户可以把Byte9作为普通存储空间使用。各块控制位存储格式如下：

由于出厂时数据块控制位的默认值是C1C2C3=000，控制块的默认值是C1C2C3=001，而Byte9一般是69H，所以出厂白卡的控制字通常是FF078069H.

上周五连续向工厂发了两块板, 其中一块是wifi板, 另一块是继电器的板子.
今天到货立马把wifi的焊上测试, 一切OK, wifi芯片使用的是esp8266, 是我目前焊过最小的片子, 还不错,感觉比stm32的片子还要好焊一点.

继电器的板子因为提交工厂过急, 忘了加上锁存芯片(明明就在待办事项里写好要加的,结果忘了), 也不想去焊接它了, 下次重新改版后再焊吧.

昨天晚上搞了很久, STM32的独立看门狗就是无法让系统复位, 于是在网上找到了答案, 网上说复位电路使用10K电阻和104电容就可以, 我用的是100K电阻加104电容.
尝试换上10K电阻, 配合104电容真的可以完美实现看门狗复位。

再来思考原因， 因为我使用的是100K上拉电阻和104的电容, 导致RC电路的充电放电时间长, 长于看门狗的下拉时间, 从而看门狗的下拉动作被电容稳压了。

这一款是最近做的网络红外学习板, 板载一个红外接收头和一个温度传感器, 3个不同方向的红外发射管(没有做360度全方向), 可以实现网络控制电路板学习和发射红外控制信号。

上周又设计了W5500网卡芯片的板子, W5500相比要多很多的外围器件, 功耗低一些,关键是硬件内置的TCP/IP Stack可以省掉很多程序空间, 以后有线网络的板子主要还是用这款芯片了. 之前那款那来做定制功能用。

以太网转串口控制器, 将作为未来的一款副产品,后期还计划将其优化一版.
今年计划出好几款板子.

最近给客户做了一个类似摩拜的应用, 采用的智能锁的技术方案与摩拜的类似: 锁带GSM和GPRS及蓝牙, 自动同步位置到服务器, 带太阳能充电, 由服务器控制开锁。
这种方案的成本比较高，每辆自行车的成本要上千元。
另外一种市场上的共享自行车ofo, 使用的是锁是比较简单的密码锁, 内部带有一个gsm的芯片, 可以进行不太精确的gsm定位, 精确的定位可由使用者的app提供。不使用太阳能电池板， 内置一块不需要充电的电池， 由于与服务器的通信数量特别少(或许只需要在开锁和关锁时向服务器提交一下数据即可),所以电池的使用时间可以达到数月甚至一年以上。

两家公司的技术方案相比，其实ofo是更牛逼的，主要包含以下几点:
1. 用户体验: ofo的体验肯定会差一点,因为服务器是通过提供密码,由用户手工输入密码开锁（两种可能,一是采用类似银行口令卡的模式，通过精确的时间来算出当前的密码;或者还有更简单的,就是类似短信验证码的方式, 服务器随机生成一个开锁码, 用户在锁上输入码后,由锁提交到服务器验证, 验证通过后开锁）；而摩拜是由服务器控制开锁, 只需要app上操作好即可自动开锁, 看起来更牛;

2. 前期成本: ofo的方案肯定比摩拜低很多, 成本低可以带来更加友好的商业模式(比如你300押金我只要100, 你1元1小时我5毛等等等), 光这一点, 完全可以抵掉用户的软件体验上的不足;

3. 后期运维成本: 可能从直观上看来, ofo的运维成本是比摩拜高很多的, 但实际确不一定。

• 首先，由于智能锁是运行在恶劣环境下的，所以报废率肯定都是比较高的。摩拜的锁技术含量更高，涉及的芯片和外围设备比较多，出现问题的概率肯定高于ofo的简单锁；而且摩拜换一把锁、一个太阳能电池板的成本也是大大高于ofo的成本;
• 其次，摩拜因为是服务器控制开锁， 所以锁与服务器是要保持一个长连接状态，而ofo不需要与服务器保持长连接, 当用户输入了密码时、锁成功打开或者锁关上以后,再向服务器发个短连接交互一下状态即可, 如果一辆车不使用， ofo基本可以做到不交互数据,那么给运营商的流量费用,绝对是大大低于摩拜的;
• 最后是电池,很多人觉得ofo到批量换电池的时候肯定是个大成本, 其实也不一定：ofo就算每一年所有车统一换一次低成本的不可充电电池, 成本也不一定比摩拜换电池的成本高, 在恶劣环境下运行的充电电池,我感觉差不多也就一年左右的寿命。而且如果ofo所有自行车统一换电池, 或许一两个月的工人就全部搞定, 而摩拜,估计得长期养着大量维护人员去给自行车换电池。

所以，从这些方面比起来， 我认为目前ofo其实是更胜一筹的。您觉得呢？

有计划做一个工作流编辑器用于协同工作的应用里面, 最近顺便用svg做了一个简单的测试下, 先收藏起来, 以后做的时候再来回顾

demo地址: http://www.hoverlees.com/U/flowDemo.html
另外有个相关的项目jqplumb以后也可以参考下