搜索

tag 标签: 工作原理

相关帖子

版块 作者 回复/查看 最后发表
膜厚仪厂家批发,高性价比光学测膜仪捷扬供应 attach_img 信息发布 jyzidkj 2017-6-23 0 1010 jyzidkj 2017-6-23 10:26
压敏电阻的工作原理 attach_img 信息发布 jec1688 2017-6-22 0 505 jec1688 2017-6-22 09:20
继电器触点灭火花电路的工作原理 模拟电子 wh8010jky 2017-6-7 14 5685 PowerAnts 2017-6-30 12:48
144芯三网合一光纤配线架【工作原理及功能详细介绍】 信息发布 lijin09 2017-6-6 0 1212 lijin09 2017-6-6 18:10
576芯光缆交接箱【工作原理及功能用途】 信息发布 lijin09 2017-6-2 0 2121 lijin09 2017-6-2 13:35
三网合一光纤分光箱【新设计产品详细介绍】 信息发布 lijin09 2017-6-1 0 808 lijin09 2017-6-1 18:22
二极管限幅电路工作原理 【模拟与混合信号】 fish001 2017-5-19 0 404 fish001 2017-5-19 11:40
CP2102 attach_img 信息发布 江右盟curry 2017-5-19 0 505 江右盟curry 2017-5-19 11:21
转载聚源门禁系统中摄像头的感应线圈应用认识 信息发布 juyuandianzi 2017-5-5 1 824 star_66666 2017-5-5 12:17
寻找一款电池充电-管理芯片,要带充电方案 attachment 电源技术 空岛小木 2017-4-26 6 3742 hbzyw2009 2017-6-9 18:35
压敏电阻的结构特点和工作原理 信息发布 jec1688 2017-4-18 0 505 jec1688 2017-4-18 11:06
无铅波峰焊机知识问答 信息发布 xylg88 2017-4-11 1 810 xylg88 2017-4-11 10:29
ST全球直播:针对产品设计,学习气压和温湿度传感器的设计技巧 attach_img ST传感器与低功耗无线技术论坛 nmg 2017-4-11 11 1148 windyICsocket 2017-4-12 17:53
市场上哪款远传型磁翻板液位计信号更稳定? 信息发布 1785908493 2017-3-30 0 606 1785908493 2017-3-30 13:40
Agilent安捷伦E4411B频谱分析仪使用注意事项 attach_img 信息发布 ch605577061 2017-3-29 0 909 ch605577061 2017-3-29 10:30
什么是示波器?示波器的种类,示波器工作原理 信息发布 ld056k 2017-3-28 1 746 ld056k 2017-3-29 16:12
EPS消防电源系统的组成及工作原理 attach_img 信息发布 上海耀亮 2017-3-28 5 908 上海耀亮 2017-4-18 14:33
频谱分析仪工作原理是什么?频谱分析仪的工作原理 模拟电子 ld056k 2017-3-29 0 505 ld056k 2017-3-29 10:27
PCB上板机的工作原理和技术特点 工控电子 xylianguang 2017-4-15 0 1212 xylianguang 2017-4-15 11:19
轮廓测量仪的工作原理 attach_img 信息发布 szzhongtu5 2017-6-12 0 606 szzhongtu5 2017-6-12 14:23

相关日志

分享 在4G网络下GPS定位器汽车进行动力控制(断油断电)工作原理
suruide 2019-6-11 09:10
4G 网络下, GPS 定位器对汽车的控制主要是针对动力的开闭或者汽车油门泵的继电器的控制,要求 GPS 定位设备必须带有 4G 网络、 GPS+ 北斗定位信息,内置继电器可以对外控制闭合开关。 工作原理上,不是真正的去关闭油路, GPS 平台买的 4G-GPS 跟踪器,一般都内置一个组合继电器,将继电器串接在化油器电子点火电源回路里即可。继电器与 GPS 跟踪器在 4G 网络下实现相互联通,并接收 GPS 平台指令下发跟踪器控制。当发现车辆被盗时,( GPS 跟踪器内插有接收短信的流量卡)平台发送短信指令(不同品牌有不同的命令), GPS 跟踪器接到对应的断电指令后启动继电器断开点火装置电源,没了电源汽车也就实现停止燃烧并熄火。 车辆装有 gps 定位系统和控制汽车油泵和总电源的控制系统,就这样通过 4G 无线数据网络,可以实时实现车辆数据、定位和监控中心双向数据互联互通。 业务上,当监控中心发现车辆出现异常,比如位置超出公司运营范围之外时,则监控中心会发出警报,值班人员可以实时查看车辆状况,如果判定为紧急状况,则可以通过无线数据网络向车辆上的控制系统发出指令,将汽车油泵和总电源切断,并根据车载 gps 定位系统发回数据定位车辆,派出人员前往处置。 产品上,之前了解过一款速锐得科技的 4G 的 GPS 定位器,产品稳定,价格合理
29 次阅读|0 个评论
分享 SES每周||工程知识问题解答
sestech 2016-8-12 10:02
1、EMI接收机与频谱仪有何不同? a. 基本原理 根据工作原理,频谱分析仪和接收机可分为模拟式和数字式两大类。外差式分析是当前使用最为广泛的接收和分析方法。下面就外差式频谱分析仪与接收机之间的主要差别作一分析。 b.输入RF信号的前端处理 接收机与频谱仪在输入端对信号进行的处理是不同的。 频谱仪的信号输入端通常有一组较为简单的低通滤波器,而接收机要采用对宽带信号有较强的抗扰能力的预选器。通常包括一组固定带通滤波器和一组跟踪滤波器,完成对信号的预选。 由于RF信号的谐波、交调和其它杂散信号的影响,造成频谱仪和接收机测试误差。相对于频谱仪而言,接收机需要更高的精度,这要求在接收机的前端比普通频谱仪多出一个预选器,提高选择性。 接收机的选择性在GB/T6113(CISPR16)中有明确规定。 c.本振信号的调节 现在的EMC测量,人们不止要求能手动调谐搜索频率点,也需要快速直观观察EUT的频率电平特性。这就是要求本振信号既能测试规定的频率点,也能够在一定频率范围扫描。 频谱仪是通过扫频信号源实现扫频测量的。通常通过斜波或锯齿波信号控制扫频信号源,在预设的频率跨度内扫描,获得期望的混频输出信号。 接收机的频率扫描是步进的,离散的,是离散的点频测试。接收机按照操作者预先设定的频率。 2.为什么频谱分析仪不能观测静电放电等瞬态干扰? 因为频谱分析仪是一种窄带扫频接收机,它在某一时刻仅接收某个频率范围内的能量。而静电放电等瞬态干扰是一种脉冲干扰,其频谱范围很宽,但时间很短,这样频谱分析仪在瞬态干扰发生时观察到的仅是其总能量的一小部分,不能反映实际的干扰情况。
383 次阅读|0 个评论
分享 smartconfig 工作原理
wateras1 2015-4-12 11:51
【转】smartconfig 工作原理 技术文章,转过来,省得以后找得费劲 ==================== Initially TI clearly documented how the SSID and password were transmitted to a CC3000 enabled device in their "CC3000 First Time Configuration" document. However with release 1.10 they changed the approach to one called Smart Config and now document the API but no longer explain what is happening at the network level. Here I cover this missing information for the new approach. So let's start at the start - we have a problem - we want to send two pieces of information, an SSID and the keyphrase, from one party that is already a member of the wifi network to an external party who can monitor all the encrypted wifi traffic but who cannot decrypt it. Someone who cannot decrypt the wifi traffic can still see quite a lot of information, e.g. they can see the source and receiver MAC addresses of every packet sent. They can also see the length of the data portion of the packets. The encryption affects that size of the packets sent but in a consistent manner, e.g. if one sends n bytes of data in a given packet then the encrypted packet will contain (n + x) bytes where x is constant across all packets. So the solution to our problem is to encode the information in the size of the packets sent (the actual content is irrelevant). The party on the secured network just sends UDP packets with particular lengths to another party on the network. That the other party is not interested in receiving the packets is not important. The external party cannot tell directly that a packet that it is looking at contains UDP data, however the packets still include basic type information that allows many packets to be excluded from consideration, e.g. any packet that is not of 802.11 subtype "QoS data" can be excluded. As the external party does not know in advance which wifi channel to look at or which source and receiver address pair to pay attention to one must, in addition to the underlying data, i.e. encoded SSID etc., send regular repeating patterns that allow this data to be spotted. We convert our SSID and keyphrase into a sequence of tag values, string lengths, nibble values and separators values and then encode and transmit all these values as packet lengths. Let's look in detail at the values sent. We use two tags - an SSID tag with value 1399 and a keyphrase tag with value 1459 and one standard separator sequence consisting of two values - 3 followed by 23. And we use two constants, L with value 28 and C with value 593, that we will see used below. So for the SSID the following sequence of values are generated in this order: The SSID tag 1399. L plus the length of the SSID in bytes. The two separator values 3 and 23. Then we loop over each byte of the SSID and generate a set of four values for each: Two values - onefor each nibble of the byte, as described in the next section. Followed by the two separator values 3 and 23. Values are generated in an identical fashion for the keyphrase (except that the keyphrase tag 1459 is used in place of the SSID tag). Note: the TI Android library and Java applet library generate values as described above, oddly the TI iOS library produces a slightly different ordering (which clearly doesn't affect the CC3000's ability to decode the data). This difference can be seen in the example data length dumps shown latter. Once we have all these values then UDP packets, each with an amount of data corresponding to one of these values, are sent from the machine running the Smart Config application, i.e. the one that has generated the values just described, to another system on the same network (currently always the network's default gateway). The values are sent repeatedly until the external party, i.e. the CC3000 enabled device, successfully sifts them out from all the other network traffic and uses them to connect to the network, at which point it advertises its presence on the network in a manner that the transmitting application can detect and which causes it to stop transmitting. Note that the range of packet lengths that need to be supported places a lower bound on the maximum transmission unit (MTU) for the network. Currently the Smart Config client application expects the MTU to be 1500 or greater (this is a reasonable expectation on any normal network). The TI Smart Config reference implementation resends the full set of UDP packets corresponding to the SSID and keyphrase repeatedly. The TI Java applet library pauses 100ms after each complete transmission of the full set of values, the Android and iOS libraries do not bother pausing. Encoding the characters of the SSID or keyphrase. If an SSID consists of n characters 0 to n - 1 then we generate 2n corresponding values. Note: according to IEEE standard 802.11i-2004 , Annex H.4.1, users may enter keys as a string of 64 hexadecimal digits (or alternatively as a passphrase of printable ASCII characters). Presumably WEP and WPA specify similar restrictions. The SSID must be a sequence of between 1 and 32 bytes, there is no mandated character set (more details in this StackOverflow answer ) and how the SSID is displayed is left up to the end user application (however many routers apparently only accept printable ASCII characters for the SSID). So if we assume ASCII characters encoded as 8 bit values then each value consists of a high and low nibble. E.g. 'M' in ASCII is hex 0x4D, the high nibble is 0x4 and the lower nibble is 0xD. If we maintain a sequence number starting from 0 and increment it each time we generate a value then for character i of the SSID, consisting of a high and low nibble H i and L i , we generate two values with sequence number 2i and (2i + 1) respectively. Each of these values has a high and low nibble calculated as follows: Seq. High Low 2i L i-1 ^ (2i % 16) H i 2i+1 H i ^ ((2i + 1) % 16) L i Note that the value containing the high nibble of i is generated before the one containing the low nibble of i. And note that caret, i.e. '^', is used here to mean XOR , rather than power of . The following shows how the SSID "MyPlace" would be split up into high and low nibbles: 'M' 'y' 'P' 'l' 'a' 'c' 'e' Hex: 0x4D 0x79 0x50 0x6C 0x61 0x63 0x65 Nibbles: 0x4 0xD 0x7 0x9 0x5 0x0 0x6 0xC 0x6 0x1 0x6 0x3 0x6 0x5 H 0 L 0 H 1 L 1 H 2 L 2 H 3 L 3 H 4 L 4 H 5 L 5 H 6 L 6 For each 4 bit nibble we generate a value whose lower 4 bits consist of the nibble itself and whose higher 4 bits consist of the current sequence number XORed with the value of the previouslyused nibble value. We then add the constant C mentioned above, i.e. 593, to each value generated in this way and this becomes the length of the packet that encodes such a value. Note that the 4 bit constraint means that we only use the lower 4 bits of the current sequence number, i.e. if the sequence number S is above 15 then we use S % 16 . This results in the generation of 14 values for the 7 character of the SSID name "MyPlace" like so: C h a r S e q → Hi Lo → Byte Hi Lo → Hi Lo → Sum → Len 'M' 0 0x0 H 0 0x4D 0x0 0x4 0x0 0x4 0x04 + 593 597 1 H 0 ^ 0x1 L 0 0x4 ^ 0x1 0xD 0x5 0xD 0x5D + 593 686 'y' 2 L 0 ^ 0x2 H 1 0x79 0xD ^ 0x2 0x7 0xF 0x7 0xF7 + 593 840 3 H 1 ^ 0x3 L 1 0x7 ^ 0x3 0x9 0x4 0x9 0x49 + 593 666 'P' 4 L 1 ^ 0x4 H 2 0x50 0x9 ^ 0x4 0x5 0xD 0x5 0xD5 + 593 806 5 H 2 ^ 0x5 L 2 0x5 ^ 0x5 0x0 0x0 0x0 0x00 + 593 593 'l' 6 L 2 ^ 0x6 H 3 0x6C 0x0 ^ 0x6 0x6 0x6 0x6 0x66 + 593 695 7 H 3 ^ 0x7 L 3 0x6 ^ 0x7 0xC 0x1 0xC 0x1C + 593 621 'a' 8 L 3 ^ 0x8 H 4 0x61 0xC ^ 0x8 0x6 0x4 0x6 0x46 + 593 663 9 H 4 ^ 0x9 L 4 0x6 ^ 0x9 0x1 0xF 0x1 0xF1 + 593 834 'c' 10 L 4 ^ 0xA H 5 0x63 0x1 ^ 0xA 0x6 0xB 0x6 0xB6 + 593 775 11 H 5 ^ 0xB L 5 0x6 ^ 0xB 0x3 0xD 0x3 0xD3 + 593 804 'e' 12 L 5 ^ 0xC H 6 0x65 0x3 ^ 0xC 0x6 0xF 0x6 0xF6 + 593 839 13 H 6 ^ 0xD L 6 0x6 ^ 0xD 0x5 0xB 0x5 0xB5 + 593 774 The keyphrase is encoded in the same way, note that the sequence number starts again from 0 when encoding the keyphrase, i.e. the value is not carried over from encoding the SSID. Currently Smart Config enforces an upper limit of 32 characters on the keyphrase length, i.e. shorter than the maximum length allowed by the relevant WPA2 standard. I find the approach used to actively leak information from a secure wireless network to an external party (that does not have the relevant network keyphrase) interesting and would like to hear if anyone has come across it before or whether it is novel? I asked about this onStack Overflow but have since moved the question to the sister site crypto.stackexchange.com after people suggested it was more appropriate there. Update Oct 21, 2013: I've now got at least one good answer . In a paper from 2007 by P. Martin called " Covert channels in secure wireless networks " you can find section 4.4.2 "UDP Packet Size vs MAC Frame Size Experiment" that essentially describes exactly the process used by Smart Config. The question of patents has come up once or twice in relation to Smart Config (though no one has ever provided pointers to any actual patent applications or granted patent numbers). The answers and other comments on my question would seem to suggest that there's definitely prior art for the fundamental idea behind Smart Config. Choosing the destination for the UDP packets The current logic always sends the UDP messages, that encode the SSID etc., to the default gateway address. However it doesn't actually matter what address they're sent to as long as it's the address of another machine on the network that actually exists and is capable of receiving packets. However it makes sense to have decided on a definite address. The CC3000 doesn't support ad hoc networks so you are never going to get a situation where it is used on a network that doesn't have an access point (AP), and in most normal setups the AP is also the default gateway. However I don't think a default gateway is mandatory (someone can correct me on this?), one can imagine aself contained wifi network where the AP isn't a gateway to anywhere else. I wonder why TI didn't choose on the address of the AP rather than the default gateway. Even if the two are almost always the same I think an end user is probably likely to have much more luck, if needed, asking Google or their ISP first level technical support how they find the address of their wifi AP than asking about default gateways. Note: in a network using an AP all traffic goes via the AP, so even if one chose the address of a machine other than the AP the traffic would still be received by the AP and retransmitted by the AP to the destination machine. This doesn't cause an issue if you try it with the CC3000 but it does mean the traffic in pointlessly duplicated. Further details of the Smart Config library The sections above cover the heart of how Smart Config works, the following covers details of TI's Smart Config Java applet library that don't immediately seem relevant - they may be left over from the development process and have just never been cleaned out or they may relate to non-default functionality that it's possible to use if a particular CC3000 device is configured in a particular way. One can set the DatagramSocket used to send the UDP packets to something other than one simply setup to bind to any available port on the local machine. One can set the port to which the UDP packets are sent to something other than 15000. One can set the port on which mDNS UDP messages are expected to something other than 5353. One can set can the timeout, i.e. the time the application waits, for the CC3000 enabled device to connect to something other than 5 minutes. One can set the number of times all the details are retransmitted before taking a 100ms pause. By default this is 1, i.e. the logic takes a 100ms pause between every full transmission of the details. One can set the two separators values, i.e. 3 and 23 mentioned above, to different values and more bizarrely set the characters used to make up the packets with these lengths. These features are available in the library but are never made use of by the TI Smart Config application built on top of this library. One can also set the network interface of the socket used to listen for mDNS message. However this seems completely pointless as this just affects outgoing multicast datagrams and the relevant logic is only looking for incoming datagrams. With one exception all of this configurability looks pointless. It's hard to think of why one might want to specify the bind address of the DatagramSocket used to send the UDP packets. The machine receiving the packets will ignore them and so choosing a particular port seems irrelevant and with encrypted network traffic one cannot see port information so it shouldn't be relevant to the CC3000 device's ability to detect the relevant traffic. mDNS always uses port 5353 and given how mDNS is used it's hard to imagine that port number being changed on a particular network. The timeout is fairly arbitrary, 5 minutes seems extremely long so it does seem reasonable to adjust it down if one really cares about this. Being able to set the number of full retransmits before a pause has no obvious benefits. That leaves us with being able to change the separator lengths. Perhaps this is configurable on CC3000 devices. I can't see a reason why you'd want to change the default values. And if one did I suspect one would have to be careful what values one chose. The tag values for SSID and keyphrase, and the constants C and L mentioned above, along with the two separator length values, all seem to have been chosen to ensure no overlap in values between one kind of thing and another, the current setup means no packet length encoding a nibble of an SSID character or keyphrase will end up with a length equal to the tags or separator values. Note: the port number 15000 mentioned above has not been registered by TI and actually belongs to a legitimate service called " hydap " which has been registered by HYPACK Inc. with IANA. This shouldn't be an issue for anyone. Multicast mDNS Above you saw some mention of mDNS. This is involved in detecting that a CC3000 device has successfully connected to the network and is discussed in more detail in this post . What character set does the CC3000 use? The Smart Config Java applet library stores the SSID etc. as standard Java strings, i.e. sequences of Unicode characters. It converts back and forward between these strings and arrays of bytes at various points, but takes no care of character sets, e.g. when it calls String.getBytes() it always uses the form that uses the platform's default character set. This will work on most systems, including pretty much everything in the US and Western Europe, but will obviously be an issue elsewhere. The CC3000 presumably has a fixed character set and this should be used explicitly in the library when converting between characters and bytes. Update: experimentation shows that while the TI Java applet library just uses the default character set of the machine it's running on, when converting to and from bytes, the TI iOS and Android apps both seem to consistently use UTF-8. Packet length dumps from the TI Smart Config applications If any of the above wasn't too clear, hopefully this section will help with a practical example of the packet lengths generated by the TI Smart Config applications when sending the SSID "MyPlace" and the password "LetMeIn". The first dump shows the packet lengths generated by the Android and Java applet applications. The first colum just shows the UNIX time the packet was sent at, the second column shows the length of the packet and this is then followed by an indication of what the length of packet is encoding. 1381084544.032552000 1399 ----- SSID tag 1381084544.033572000 35 ----- SSID length + 28 1381084544.033589000 3 --+-- separator 1381084544.033594000 23 --' 1381084544.033667000 597 ----- 'M' hi-nibble 1381084544.033675000 3 --+-- separator 1381084544.033723000 23 --' 1381084544.034369000 686 ----- 'M' lo-nibble 1381084544.035385000 3 --+-- separator 1381084544.036271000 23 --' 1381084544.036448000 840 ----- 'y' hi-nibble 1381084544.036467000 3 --+-- separator 1381084544.036481000 23 --' 1381084544.036541000 666 ----- 'y' lo-nibble 1381084544.037262000 3 --+-- separator 1381084544.037271000 23 --' 1381084544.037496000 806 ----- 'P' hi-nibble 1381084544.038019000 3 --+-- separator 1381084544.038032000 23 --' 1381084544.038097000 593 ----- 'P' lo-nibble 1381084544.043096000 3 --+-- separator 1381084544.044209000 23 --' 1381084544.044785000 695 ----- 'l' hi-nibble 1381084544.045422000 3 --+-- separator 1381084544.045855000 23 --' 1381084544.048359000 621 ----- 'l' lo-nibble 1381084544.049327000 3 --+-- separator 1381084544.049347000 23 --' 1381084544.049406000 663 ----- 'a' hi-nibble 1381084544.049412000 3 --+-- separator 1381084544.049416000 23 --' 1381084544.049568000 834 ----- 'a' lo-nibble 1381084544.050052000 3 --+-- separator 1381084544.050067000 23 --' 1381084544.050808000 775 ----- 'c' hi-nibble 1381084544.051463000 3 --+-- separator 1381084544.052082000 23 --' 1381084544.055415000 804 ----- 'c' lo-nibble 1381084544.056319000 3 --+-- separator 1381084544.056334000 23 --' 1381084544.056398000 839 ----- 'e' hi-nibble 1381084544.056404000 3 --+-- separator 1381084544.056407000 23 --' 1381084544.056644000 774 ----- 'e' lo-nibble 1381084544.058021000 3 --+-- separator 1381084544.058034000 23 --' 1381084544.059236000 1459 ----- passphrase tag1381084544.059252000 35 ----- passphrase length + 281381084544.059255000 3 --+-- separator1381084544.059258000 23 --'1381084544.059261000 597 ----- 'L' hi-nibble1381084544.059937000 3 --+-- separator 1381084544.059949000 23 --' 1381084544.060043000 685 ----- 'L' lo-nibble 1381084544.060723000 3 --+-- separator 1381084544.060729000 23 --' 1381084544.060884000 823 ----- 'e' hi-nibble 1381084544.061407000 3 --+-- separator 1381084544.061411000 23 --' 1381084544.061954000 678 ----- 'e' lo-nibble 1381084544.062651000 3 --+-- separator 1381084544.062709000 23 --' 1381084544.063217000 616 ----- 't' hi-nibble 1381084544.063696000 3 --+-- separator 1381084544.063699000 23 --' 1381084544.064344000 629 ----- 't' lo-nibble 1381084544.064893000 3 --+-- separator 1381084544.064897000 23 --' 1381084544.065561000 629 ----- 'M' hi-nibble 1381084544.066131000 3 --+-- separator 1381084544.066221000 23 --' 1381084544.066947000 654 ----- 'M' lo-nibble 1381084544.066955000 3 --+-- separator 1381084544.067371000 23 --' 1381084544.067491000 679 ----- 'e' hi-nibble 1381084544.067871000 3 --+-- separator 1381084544.068325000 23 --' 1381084544.069089000 838 ----- 'e' lo-nibble 1381084544.069097000 3 --+-- separator 1381084544.069593000 23 --' 1381084544.069711000 837 ----- 'I' hi-nibble 1381084544.070191000 3 --+-- separator 1381084544.070656000 23 --' 1381084544.074244000 842 ----- 'I' lo-nibble 1381084544.074259000 3 --+-- separator 1381084544.075225000 23 --' 1381084544.075286000 679 ----- 'n' hi-nibble 1381084544.075291000 3 --+-- separator 1381084544.075293000 23 --' 1381084544.075521000 783 ----- 'n' lo-nibble 1381084544.075533000 3 --+-- separator 1381084544.076058000 23 --'-------------------------- No delay on Android, 100ms delay with Java applet library, then repeat from start again. 1381084544.076246000 1399 ----- SSID tag 1381084544.076850000 35 ----- SSID length + 28... The output generated by the TI iOS and Java applet Smart Config applications is identical (except for the noted 100ms delay). However oddly the iOS Smart Config application does not interleave the separator values 3 and 23 between the characters of the SSID and keyphrase, instead it always sends out a sequence of 10 separator value pairs as shown here and then sends out the SSID and keyphrase. So here one can hardly call 3 and 23 separators but I've stuck with this name here: 1381085051.154799000 3 --+-- separator 1 1381085051.159414000 23 --' 1381085051.164143000 3 --+-- separator 2 1381085051.170050000 23 --' 1381085051.174861000 3 --+-- separator 3 1381085051.179503000 23 --' 1381085051.185282000 3 --+-- separator 4 1381085051.190274000 23 --' 1381085051.195296000 3 --+-- separator 5 1381085051.200047000 23 --' 1381085051.206394000 3 --+-- separator 6 1381085051.211076000 23 --' 1381085051.215383000 3 --+-- separator 7 1381085051.225363500 23 --' 1381085051.235344000 3 --+-- separator 8 1381085051.235459000 23 --' 1381085051.236902000 3 --+-- separator 9 1381085051.241718000 23 --' 1381085051.249366000 3 --+-- separator 10 1381085051.253099000 23 --' 1381085051.257767000 1399 ----- SSID tag 1381085051.262315500 35 ----- SSID length + 28 1381085051.266864000 597 ----- 'M' hi-nibble 1381085051.273117000 686 ----- 'M' lo-nibble 1381085051.278023500 840 ----- 'y' hi-nibble 1381085051.282930000 666 ----- 'y' lo-nibble 1381085051.291178000 806 ----- 'P' hi-nibble 1381085051.294688000 593 ----- 'P' lo-nibble 1381085051.299266000 695 ----- 'l' hi-nibble 1381085051.308603000 621 ----- 'l' lo-nibble 1381085051.311723000 663 ----- 'a' hi-nibble 1381085051.315706000 834 ----- 'a' lo-nibble 1381085051.321567000 775 ----- 'c' hi-nibble 1381085051.326156000 804 ----- 'c' lo-nibble 1381085051.332654000 839 ----- 'e' hi-nibble 1381085051.337025000 774 ----- 'e' lo-nibble 1381085051.342818000 1459 ----- passphrase tag 1381085051.346519000 35 ----- passphrase length + 28 1381085051.353083000 597 ----- 'L' hi-nibble 1381085051.359196000 685 ----- 'L' lo-nibble 1381085051.362984000 823 ----- 'e' hi-nibble 1381085051.366772000 678 ----- 'e' lo-nibble 1381085051.373192000 616 ----- 't' hi-nibble 1381085051.382117000 629 ----- 't' lo-nibble 1381085051.386131000 629 ----- 'M' hi-nibble 1381085051.390145000 654 ----- 'M' lo-nibble 1381085051.393997000 679 ----- 'e' hi-nibble 1381085051.400047000 838 ----- 'e' lo-nibble 1381085051.404880000 837 ----- 'I' hi-nibble 1381085051.412003000 842 ----- 'I' lo-nibble 1381085051.414365000 679 ----- 'n' hi-nibble 1381085051.420336000 783 ----- 'n' lo-nibble--------------------------- No delay then repeat from start again. 1381085051.432048500 3 --+-- separator 1 1381085051.443761000 23 --'... Dumping and decrypting wifi packets using tshark The above dumps were produced with the command line version of the well known packet analyser tool Wireshark that's called tshark . Wireshark is available for Mac OS X, Windows and Linux. The following shows how I used it to produce these dumps. First I started it off recording packets before doing anything with the particular TI Smart Config application I was working with like so: $ tshark -i en0 -I -w output.pcap Note that the -I flag puts your machine's wifi network interface into monitor mode, this disables standard network access for everything else on the machine while tshark is running but allows tshark to see all the traffic on the network, not just traffic intended for the machine that it's running on. On my Mac putting the network interface into monitor mode works fine but on other platforms this can be far more complicated - I'll discuss this further in a later post. I then ran the particular Smart Config application on a different machine, i.e. an iPhone, an Android phone or a different desktop machine. I hit the start button that you find in each Smart Config application that tells it to start transmitting the SSID etc., and let it run for a while. There's no requirement to have an actual CC3000 enabled device listening for the data. After a few seconds I killed the tshark process with control-C and hit stop in the Smart Config application. The resulting network traffic ends up in the file output.pcap, note the size of this file can grow very quickly as we're recording all traffic on a given wifi channel, not just the Smart Config related traffic. Then we can filter out the Smart Config traffic and dump it out as above like so: $ tshark -r output.pcap -o 'wlan.enable_decryption:TRUE' \ -Y 'wlan.fc.retry == 0 !icmp udp ip.src == 192.168.1.177 ip.dst == 192.168.1.1 udp.dstport == 15000' -T fields -e frame.time_epoch -e data.len | head -n 512ip.src must to be changed to the IP address of the device running the Smart Config application, e.g. an iPhone, and ip.dst must be the IP address used as the gateway by the application. Note that I exclude icmp packets, these are control packets that can contain embedded UDP packets that would be matched by the udp filter. In our case icmp packets are generated to tell us that the port we are sending the packets to is unreachable. With the wlan.fc.retry filter I also exclude retransmitted packets - I'll discuss this more in a later post. As shown here tshark can actually decrypt the wifi packets (something which a CC3000 enabled device that's waiting for the network password obviously cannot do). Having done so it can then filter the traffic using higher level network terms like the IP protocol, in this case UDP, and IP addresses. If the option wlan.enable_decryption is set to TRUE , as shown above, tshark will search for the keyphrase necessary to do the decryption in the file ~/.wireshark/80211_keys where it will expect to find something like: "wpa-pwd","LetMeIn:MyPlace" Note that the keyphrase comes before the SSID and that storing keys (in plain text, yes) in the file 80211_keys is relatively new to wireshark/tshark. For earlier versions of tshark you may have to specify the key information as a command line option - Google for what works for your version. However even if it has the keyphrase it can only decrypt the traffic if your pcap file contains the EAPOL packets that are generated when the device designated by ip.src goes through the initial negotiation of a secure connection with the AP. To force my devices to generate such packets I flipped the phones in and out of airplane mode and on my desktops I temporarily disabled and then reenabled wifi. This didn't always seem to work - I don't know if even on being disabled and reenabled a device can sometimes avoid having to renegotiate its connection. One can check if the pcap file contains EAPOL packets like so: $ tshark -r sc-ios.pcap -Y eapol You should see about four packets which correspond to your device (check that the displayed MAC addresses match the MAC address of the device). Obviously the CC3000 cannot decrypt the packets like this - I'll discuss in a later post how it does much the same as we've done here but without having the relevant decryption information. - See more at: http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-transmitting-ssid.html#sthash.hcSxoH32.dpuf
个人分类: ESP8266 WIFI|6991 次阅读|0 个评论
分享 电容式触摸屏原理及故障处理
terjin 2014-4-15 13:55
  电容式触摸屏概念   电容式触摸屏技术是利用人体的电流感应进行工作的。电容式触摸屏是一块四层复合玻璃屏,玻璃屏的内表面和夹层各涂有一层ITO,最外层是一薄层矽土玻璃保护层,夹层ITO涂层作为工作面,四个角上引出四个电极 ,内层ITO为屏蔽层以保证良好的工作环境。 当手指触摸在金属层上时,由于人体电场,用户和触摸屏表面形成以一个耦合电容,对于高频电流 来说,电容是直接导体,于是手指从接触点吸走一个很小的电流。这个电流分从触摸屏的四角上的电极中流出,并且流经这四个电极的电流与手指到四角的距离成正比,控制器通过对这四个电流比例的精确计算,得出触摸点的位置。   电容式触摸屏工作原理   电容屏要实现多点触控,靠的就是增加互电容的电极,简单地说,就是将屏幕分块,在每一个区域里设置一组互电容模块都是独立工作,所以电容屏就可以独立检测到各区域的触控情况,进行处理后,简单地实现多点触控。   电容式触摸屏原理   电容技术触摸屏CTP(Capacity Touch Panel)是利用人体的电流感应进行工作的。电容屏是一块四层复合玻璃屏,玻璃屏的内表面和夹层各涂一层ITO(纳米铟锡金属氧化物),最外层是只有0.0015mm厚的矽土玻璃保护层,夹层ITO涂层作工作面,四个角引出四个电极,内层ITO为屏层以保证工作环境。   当用户触摸电容屏时,由于人体电场,用户手指和工作面形成一个耦合电容,因为工作面上接有高频信号,于是手指吸收走一个很小的电流,这个电流分别从屏的四个角上的电极中流出,且理论上流经四个电极的电流与手指头到四角的距离成比例,控制器通过对四个电流比例的精密计算,得出位置。可以达到99%的精确度,具备小于3ms的响应速度。   投射式电容面板的触控技术投射电容式触摸屏是在两层ITO导电玻璃涂层上蚀刻出不同的ITO导电线路模块.两个模块上蚀刻的图形相互垂直,可以把它们看作是X和Y方向 连续变化的滑条。由于X、Y架构在不同表面,其相交处形成一电容节点。一个滑条可以当成驱动线,另外一个滑条当成是侦测线。当电流经过驱动线中的一条导线时,如果外界有电容变化的信号,那么就会引起另一层导线上电容节点的变化。侦测电容值的变化可以通过与之相连的电子回路测量得到,再经由A/D控制器转为数字讯号让计算机做运算处理取得(X,Y) 轴位置,进而达到定位的目地。   三、电容触摸屏的缺陷   电容触摸屏的透光率和清晰度优于四线电阻屏,当然还不能和表面声波屏和五线电阻屏相比。电容屏反光严重,而且,电容技术的四层复合触摸屏对各波长光的透光率不均匀,存在色彩失真的问题,由于光线在各层间的反射,还造成图像字符的模糊。   电容屏在原理上把人体当作一个电容器元件的一个电极使用,当有导体靠近与夹层ITO工作面之间耦合出足够量的电容时,流走的电流就足够引起电容屏的误动作。我们知道,电容值虽然与极间距离成反比,却与相对面积成正比,并且还与介质的绝缘系数有关。因此,当较大面积的手掌或手持的导体物靠近电容屏而不是触摸时就能引起电容屏的误动作,在潮湿的天气,这种情况尤为严重,手扶住显示器、手掌靠近显示器7厘米以内或身体靠近显示器15厘米以内就能引起电容屏的误动作。   电容屏的另一个缺点用戴手套的手或手持不导电的物体触摸时没有反应,这是因为增加了更为绝缘的介质。   电容屏更主要的缺点是漂移:当环境温度、湿度改变时,环境电场发生改变时,都会引起电容屏的漂移,造成不准确。   电容触摸屏最外面的矽土保护玻璃防刮擦性很好,但是怕指甲或硬物的敲击,敲出一个小洞就会伤及夹层ITO,不管是伤及夹层ITO还是安装运输过程中伤及内表面ITO层,电容屏就不能正常工作了。   四、电容式触摸屏故障处理   1、如果使用者使用的是电容式触摸屏,那么建议使用者在第一次使用时,首先先按照相关说明书的要求正确安装好电容触摸屏所需要的驱动程序,然后用手指依次单击屏幕上的“开始”/“程序”/“Microtouch Touchware”来运行屏幕校准程序,校准完成以后,系统自动将校准后的数据存放在控制器的寄存器内,以后再重新启动系统后就无需再校准屏幕了。   2、如果在中途操作电容触摸屏时,重新改变了触摸屏的显示器分辨率或显示模式,或者是自行调整了触摸屏控制器的刷新频率后,感觉到光标与触摸点不能对应时,都必须重新对触摸屏系统进行校准操作。   3、为了保证触摸屏系统的正常工作,除了要保证系统软件的正确安装之外,还必须记得在一台主机上不要安装两种或两种以上的触摸屏驱动程序,这样会容易导致系统运行时发生冲突,从而使触摸屏系统无法正常使用。   4、在使用电阻式触摸屏时,如果发现光标不动或者只能在局部区域移动时,使用者可以查看一下触摸屏的触摸区域是否被其他触摸物始终压住,例如一旦触摸屏被显示器外壳或机柜外壳压住了,就相当于某一点一直被触摸,那么反馈给控制器的坐标位置就不准确。   5、前面曾经提到,一旦系统在更换显示分辨率、调整屏幕大小和第一次安装时都有会出现单击不准或漂移,需启动应用程序中自带的定位程序重新定位,不过在定位时,最好要使用比较细的笔或指尖进行定位,这样比较准。   6、表面声波触摸屏的工作环境要求较高,它必须要求工作在一个干净、没有灰尘污染的环境中,而且还要定期清洁触摸屏表面上的灰尘,不然的话,空气中的灰尘覆盖在触摸屏四周的反射条纹或换能器上时,就会影响系统的正确定位。   7、不要让触摸屏表面有水滴或其它软的东西粘在表面,否则触摸屏很容易错误认为有手触摸造成表面声波屏不准。另外在清除触摸屏表面上的污物时,使用者可以用柔软的干布或者清洁剂小心地从屏幕中心向外擦拭,或者用一块干的软布蘸工业酒精或玻璃清洗液清洁触摸屏表面。   8、如果用手或者其他触摸物来触摸表面声波触摸屏时,触摸屏反应很迟钝,这说明很有可能是触摸屏系统已经陈旧,内部时钟频率太低,或者是由于触摸屏表面有水珠在移动,要想让触摸屏恢复快速响应,必须重新更换或者升级系统,或者用抹布擦干触摸屏表面的水珠。   9、触摸屏一般用串口进行信号的传输,从PS/2端口取信号,而TPS屏幕是从主机电源直接取电。如果指示灯不亮,说明没有取到信号,控制盒上的PS/2线可能坏了。如果灯亮着,但依旧不闪,说明控制盒坏了,因此使用者们必须更换控制盒。如果更换控制盒还是不行,有可能是屏幕被压得太紧,需要将四周的螺丝稍微松一下,因为触摸屏是由特殊材料组成,它该身不太容易损坏。如果串口是坏的或被禁用,将导致驱动程序无法安装,因为安装驱动时,会自动寻找串口。即使能够安装,也会出现鼠标不动或无法定位。最好不要用串口鼠标来判断串口的好坏,可能串口9根针对它们来说各自用的方式不一样。如果屏幕被压着,或者地线没有接好,会导致无法定位。如果出现有些区域无法点击或反应迟缓,有可能是灰尘影响,需拆开外壳来除去灰尘。   10、当用手指触摸电容触摸屏的某一位置时,触摸屏没有任何反应时,这很有可能是对应该触摸位不准确,光标当然也就不能正确定位了。如果是机柜外壳压住触摸区域使用者可以将机柜和显示器屏幕之间的距离调大一点,如果是显示器外壳压住触摸区域,使用者可以试着将显示器外壳的螺丝拧松一点试一下。本文由专业研发生产频谱分析仪(http://www.terjin.cn/)的公司整理发布
个人分类: 行业最新资讯|803 次阅读|0 个评论
分享 基于PWM的限流保护电路的设计研究
terjin 2014-4-15 11:18
  过载保护的功能是指在负载过载情况下能有效保护DC-DC变换器不致由于过热而损坏,即主要是控制功率MOSFET管的过载电流(输入电流)。由于用电负载不同,对过载保护功能要求也不同。如卫星控制系统要求过载后DC-DC变换器不能断电,因此采取限流保护;有效载荷系统要求可以在过载后DC-DC变换器断电,因此采取截流保护。本文提出了一种基于PWM的限流保护电路的设计方法,以及设计验证。   2 电流环控制方式的过流保护   电流型控制是双环控制系统,由开关器件的峰值电流信号反馈的电流环(内环)和输出电压信号反馈的电压环(外环)构成。功率变换部分是由电流环控制的电流源,电压外环控制功率级的电流环。电流内环负责输出电感的动态变化,而电压外环只需控制输出电容。   电流型控制方式的PWM有多种,诸如UC1842(3、4、5)系列、UC1846、UC1825(电压型和电流型)等,都设计了基于电流环的过流保护功能。   以UC1842为例,其工作原理是功率开关管由振荡器起始导通,当峰值电感电流达到误差放大器输出建立的门限电平时终止,这样使得在逐周基础上反馈的误差信号控制峰值电感电流。即电流取样信号逐周与误差放大器的输出电平比较,产生驱动脉冲来控制功率开关管的导通时间,从而实现闭环输出。在过流状态下,由于峰值电感电流斜率比较大,使得逐周比较产生的驱动脉冲很窄,从而大大限制了功率开关管的导通时间,实现了限流保护,是一种峰值电流控制方式。其峰值电感电流受误差放大器输出电压的控制,见式其中:VE为误差放大器的输出电压;RS电流检测电阻。   但根据多年工程实际验证,仅仅依靠电流环控制方式的过流保护不能有效的限制输入电流,电路仿真和试验测试结果比较一致,下面给出基于PWM 1845的电流环过流保护的仿真结果。仿真电路见图1,结果见图2.可以看到过流后输入平均电流为0.65A.   用电流采样信号控制PWM误差放大器反向输入端的过流保护   为了有效实现过流后限制输入电流,设计了一种用电流采样信号控制PWM误差放大器反向输入端的过流保护电路。   电路基本工作原理如下:图3中的三极管V2接成射极跟随器形式,电流互感器采得的输出端的电流信号作为控制信号来控制V2.正常输出时,电流取样信号电压很低,使得射随器输出电压低于误差放大器反向输入端(反馈端)设定电平,图3所示的过流保护电路不影响DC-DC变换器的正常输出特性。当输出过流时,电流取样信号电压增大,使得射随器输出电压高于误差放大器反向输入端设定电平,误差放大器输出电压Ve降低,PWM的驱动信号变窄,使输出电压降低,输入电流最终稳定在某一个值上。仿真电路见图4,结果见图5.可以看到过流后输入平均电流为0.157A.   用电流采样信号控制PWM误差放大器输出端的过流保护   从上述电路可以看出,相较于直接利用PWM电流环的过流保护,输入电流有明显降低,但源端仍有0.157A的电流,主要原因是该控制方式是平均电流控制方式。过流控制信号是将输出电流取样并整流成直流信号,通过误差放大器输入端参与比较形成驱动脉冲。因此当过载时,经过数个周期积累周后形成的过流控制信号输入到误差放大器反向输入端,使得误差放大器输出为低电平,此时无驱动脉冲输出,电源输出降低;又经过数个周期后,由于电源输出降低,过流控制信号也降低,此时又产生驱动脉冲输出,使电源输出升高。如此周而复始,使电源间歇振荡输出,从图5中也可以看出,输入电流也是间歇振荡波形。   为了进一步优化过流保护方式,将图3所示的过流保护电路改进如下:将控制管V2的集电极接到误差放大器的输出端,射级接地。   当DC-DC变换器工作于正常闭环状态时,PWM误差放大器工作在线性放大区,其输出电平取决于输入误差信号电平和放大器的增益。图6中的三极管V2工作在截至区,图6所示的过流保护电路不影响正常DC-DC变换器的正常输出特性。   本文设计的基于PWM的过流保护电路,是一种通用的DC-DC变换器过流保护电路,可靠性较高,可以有效地保护DC-DC变换器过载时由于过热而损坏。
个人分类: 行业最新资讯|841 次阅读|0 个评论

Archiver|手机版|小黑屋|电子工程世界 ( 京ICP证 060456 )

GMT+8, 2019-10-20 17:11 , Processed in 0.043412 second(s), 11 queries , Gzip On, MemCache On.

Powered by EEWORLD电子工程世界

© 2019 http://bbs.eeworld.com.cn/

返回顶部