标签: antenna

敬请点击如下链接，或者通过微信搜索个人公众号：InterCar，或者微信号：CarRadio_engineering来订阅个人公众号，谢谢关注！ http://mp.weixin.qq.com/s?__biz=MzIwMDU5MzY5NA==mid=402622124idx=1sn=0398ffcec3b8b5971c6f8554fa0223cb#rd

The Heathkit HR-1680 is no longer produced these days, but during its time it was a low-cost and reasonably high-performing, ham-band-only (80 through 10m) radio receiver marketed as a build-it-yourself kit. With the audio CW filter on the front-end dual-gate-MOSFET, it could pick 0.1 uV signals out of the mud. Not quite in the same class or selectivity performance as the Heathkit SB-series, but—damn!—it worked great for its price. Sometimes the front end would oscillate if the RF gain was turned up too high, easily cured with a resistor in series with the hot end of the RF gain control. Its main problem that many Heath customers complained to me about was that all signals were S9. The S-meter tended to hang in the middle across a wide range of input signal levels, only very weak or very strong signals pushed the pointer below or above S9. I studied the circuit and came up with a modification to make the S-meter behave better, displaying a less-compressed response to the relative incoming signal level. I'm sure many HR1680s are still in use, if their owners happen to read this they might want to try this fix. Heathkit Engineering approved my change, to be applied whenever a customer complained about this defect. All Heathkit retail stores received a weekly compilation of Technical Exchange Bulletins, an in-house publication to keep field technicians abreast of the latest product updates, modifications, repair techniques and troubleshooting tips. With the kind permission of Ken Kaplan, who has gone to great lengths to preserve Heathkit Technical Exchange Bulletins, the fix as published by the Heath Company is reproduced below. It was quite a surprise when I first stumbled across Ken's website and recognised stuff that I had written as a Heathkit retail store technician 35 years ago. *** February 8, 1980 HR-1680 Bulletin No: S/S Receiver HR-1680-15 S Meter Reads S9 or Pins for Most Signals To improve the HR-1680"s S meter response, make the following modification: Parts Required: 2 1N4149 diode 1 560Ω, 1/2 watt resistor 1 1kΩ, 1/2 watt resistor 1 PCB connector Procedure: —Install a kilohm resistor on Q203, base to collector. —Disconnect the wht/blk lead from board D, pin 7 and reconnect it to board A, pin 9. —Connect the "+" meter lead to board B, pin C. —Install a 560Ω resistor in series with the "-" meter lead at PCB connector. —Connect the PCB connector to board B, pin B. —Solder two series-connected diodes from the "-" lead of the meter to ground (cathode to ground). —Zero the meter with the zero control (no signal input), tune in the calibrator signal on 80m and adjust meter sensitivity for +60 dB (tuning dial at 300). Typical readings: UV AT ANT. METER (BEFORE) METER (AFTER) 10 S9 S5 100 S9 40 dB 1000 Pinned 60 dB 1000 60 dB Install this modification only if the customer specifically complains about the S meter response. *** The astute reader will note that this is still not the proper response of 6dB per S-unit, the change from 10uV (S5 reading) to 100uV (40dB reading) is only 20dB, not 64dB, but the meter did respond much nicer and the customers went away happy. I think there is a typo in the last table entry, I seem to recall the final level into the antenna jack was 10,000uV without pinning the meter, not 1000uV. Glen Chenier, Engineer, submitted this article as part of Frankenstein's Fix, a design contest hosted by EE Times (US).  

1. WizFi210/220天线 在WizFi210/220系列中有3个版本。 lWizFi210 CON版本(接头) lWizFi210 CA版本 (芯片天线) lWizFi210 EX版本(外部天线) lWizFi220 CON版本(接头) lWizFi220 CA版本(芯片天线) lWizFi220 EX版本(外部天线) 默认版本是CON版本。 只有在特定订货时才生产EX版本。   WizFi210/220 CON 版本 : 包含 U.fl 接头   WizFi210/220 CA 版本 : 包含芯片天线   WizFi210/220 EX 版本 : 不包含任何天线   2.阻抗匹配   去 WIZnet官网 参考更多有关 WizFi210/220 的资料信息。谢谢关注！

1. WizFi210/220天线   在WizFi210/220系列中有3个版本。 lWizFi210 CON版本(接头) lWizFi210 CA版本 (芯片天线) lWizFi210 EX版本(外部天线) lWizFi220 CON版本(接头) lWizFi220 CA版本(芯片天线) lWizFi220 EX版本(外部天线) 默认版本是CON版本。 只有在特定订货时才生产EX版本。   WizFi210/220 CON 版本 : 包含 U.fl 接头   WizFi210/220 CA 版本 : 包含芯片天线   WizFi210/220 EX 版本 : 不包含任何天线   2.阻抗匹配     去 WIZnet官网 参考更多有关 WizFi210/220 的资料信息。谢谢关注！  

  My next real-time job was among the most fun, mainly because I got to recommend all the parts of our development system and tools. It was for yet another satellite tracking antenna, only this one was in an airplane, and therefore bopping around instead of bolted to the ground. We chose the Motorola 68332 chip. We used the Intermetrics C compiler, which included a very nice source-level debugger. For once, I didn't need floating-point software, but I still needed—guess what—functions for square root, sine, cosine, and arctangent. We also gave the customer an added feature. Instead of a readout showing hex numbers in green, uppercase characters, we gave him a Windows-based interface, complete with multicolored graphs, simulated compass needles, spin-dials, and point-and-click inputs. Nice. I'm particularly proud of the operating system I wrote for this job. First, it used all the real-time features of the 68332—watchdog timer, counter-timer, etc., to the fullest. More importantly, it was rather unique in that the interrupt handler was itself reentrant. That is, the system could tolerate one or more new interrupts coming in, while it was still processing the last one. The only requirement was that the average time required to service the interrupt had to be less than the interrupt time. We delivered this system on time and on budget, and it met its performance specs. We also did several other jobs for this company, all successful. As a "reward" the customer, thinking to save some money, cut me out of the next contract, and hired my ex-partner. My only satisfaction out of the deal came from learning that, because he didn't understand the OS, his job went two years over schedule, was way over cost, and under performance. The company is no longer in business. Payback is sweet, but I'd much more have preferred that both our companies had prospered. The medical business I have one more job to tell you about. A medical electronics firm wanted to replace their existing patient monitor, which used something like eight Z80's, with a new one using a single Intel 80286. Our job was to port the code from Z80 assembler to C. Now, as you might guess, medical electronics is special because if it fails, it has the potential to kill people. The FDA has very strict rules for certifying a given system as safe. To create the new patient monitor, we had to assure the FDA that it would perform exactly the same functions, using the same algorithms, as the old one. That's not easy when you're changing both the CPU(s) and the programming language. To make sure that happened, I first had to understand, in precise detail, the Z80 code in the old one. And that was the rub, because while the original programmer was superb, he wasn't big on comments. As in, there were none. So before I could write the first line of C, I had to psychoanalyze the Z80 code, commenting and studying it until I knew it as well as I know my own memories. To get that job done, I used every programming trick I'd ever learned, and then invented some more. It was a hard job, but also exciting and instructive. I extended the concept of the dataflow diagram, to include real-time interrupts, synchronous, asynchronous, and background tasks. My design evolved into a set of nested, hierarchical state machines. It was very slick, if I do say so myself. In any medical application (and most other real-time applications), it's important to quickly respond to, and recover from, errors. In my design, each state machine returned an enumerated state identifying, some of which were typically error conditions. Looking back, I see that the design amounted to sort of a do-it-yourself exception mechanism. It worked just fine, and the software turned out to be both robust and error-free. See Jack write I've always enjoyed writing. My first creation, as I recall, was a comic book when I was around 10. During my aerospace days, I wrote many technical reports, white papers, and some journal articles. The biggie was my Ph.D. dissertation, which ran to 140 pages. Later I was writing software requirements specs, test plans, etc., for NASA and DOD customers. When I got involved with microcomputers, I wrote a few articles for magazines like Byte, Kilobaud, and ProFiles, the house organ for the Kaypro computer. In 1988, I started writing a tutorial on compiler construction. It's still on the web here at www.freetechbooks.com/let-s-build-a-compiler-t56.html. JD Hildebrand, then editor of Computer Language magazine, saw the tutorial and asked me to write an article on the topic. I did, and presented a paper at the next Computer Language Conference. That article and paper started my long relationship with Computer Language and its sister publication, Embedded Systems Programming. Computer Language also maintained a forum (CLMFOR) on CompuServe, and I spent many hours chatting about computers, and almost any other topic, with its denizens. In 1992, I was laid off from my day job. It was most probably the shortest of unemployment periods on record. That night, I got on CLMFOR and said, "Guess what? I've been laid off. Anyone want me to write an article or two?" JD responded immediately, with "I can take an article every two months." Tyler Sperry, then editor of Embedded Systems Programming, said, "I'll take one a month." And that was that. I didn't stay "unemployed" forever. I worked at other companies, and ran my own company for a time. But my writing for Embedded Systems Programming started then, and has never stopped. And, as Paul Harvey used to say, "Now you know the rest of the story."