Pro jects: projects
    • Showing posts with label projects. Show all posts
    Showing posts with label projects. Show all posts

    Sunday, November 5, 2017

    Analog Devices HMC8205 GaN RF Amplifier | New Product Brief

    November 05, 2017 0
    Analog Devices HMC8205 GaN RF Amplifier | New Product Brief


    This New Product Brief (NPB) is part of a video series highlighting the features, applications, and technical specs of newly-released products.

    Analog Devices HMC8205

    Analog Devices’ HMC8205 is a GaN RF amplifier that provides high gain, high power, and high efficiency with an instantaneous bandwidth of 300 MHz to 6 GHz. The HMC8205 operates from a 50 V supply at 1300 mA and provides 20 dB power gain with a saturated output power of 46 dBm and 38% power added efficiency. It uses a 10-lead LDCC package with an input and output that are internally matched to 50 Ω and AC-coupled, and RF chokes on each drain, all of which simplify design by reducing the external component count. The HMC8205 is ideal for pulsed or continuous wave applications, including military jammers, radar, wireless infrastructure, and other applications.
    • Instantaneous Bandwidth: 0.3 GHz to 6 GHz
    • Power Supply (VDD): 50 V, 1300 mA
    • High Power Gain: 20 dB
    • High PSAT: 46 dBm
    • High PAE: 38%
    • Internal matching (50 Ω) and DC block on RFIN and RFOUT
    • RF chokes on each drain

    Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.
    By في No comments:
    التسميات:

    Testing for a Robot’s Collision Detection System with Varying Impact Resistance

    November 05, 2017 0
    Testing for a Robot’s Collision Detection System with Varying Impact Resistance
    We’ll use real collision data to refine the detection algorithm, and even better, we’ll confirm that the system actually works.

    Supporting Information


    We started this project on a robot collision detection system by gathering acceleration data for simulated collision events and non-collision impact events (i.e., finger taps). We then used this data to formulate an algorithm that would recognize real collisions and ignore the various bumps and knocks that a robot might experience as part of normal operation. In this article, we will adjust that algorithm based on real collision data.

    Vibration, Acceleration

    First, though, I want to explain something that I mentioned in the previous article. It became apparent that the motors are a significant source of high-frequency, low-amplitude acceleration, which means that an algorithm that works well without the motors might work not so well with the motors active. The following plots illustrate my point. Here is a simulated acceleration profile that was generated with the motors stopped.


    The noise is minimal—maybe a few millivolts peak to peak. The next waveform was recorded with the motors running:


    Now the noise is more like 30 to 50 mV peak to peak. An acceleration event looks very different with all this extra noise:


    As shown in the last video included in the previous article, my initial algorithm (somewhat to my surprise) remained functional despite this motor noise. It also turns out that (as you’ll see in a minute) real-life collision events result in higher-amplitude acceleration profiles, so the motor noise is easily ignored by the updated algorithm. Nonetheless, motor vibration is something you need to keep in mind if you’re developing sensitive acceleration-based robot functionality.

    Different Collision, Different Acceleration

    My real-life collision tests made one thing clear: it might be a bit difficult to develop one algorithm that is effective for most events that could be described as a collision. I gathered data by driving the robot into four types of surfaces:
    • solid wood covered by a blanket;
    • solid wood (without a blanket);
    • cardboard forming part of a cardboard box without much weight to hold it in place;
    • and cardboard forming part of a heavier box.
    As the following plots demonstrate, the acceleration differences are significant enough to complicate the process of designing a universally effective algorithm. Each plot is preceded by a video of the collision that generated the data.









    The sizes and timescales for all these plots are equivalent, so you can visually compare the widths of the different waveforms. The real question here is the following: Are all these profiles sufficiently distinct from those of non-collision events to allow for a universal algorithm? Maybe so, but I can’t say with any certainty because the only non-collision events that I have considered are taps. And of course, there are other types of collisions that might be more difficult to identify without making the algorithm oversensitive.
    One thing to note from the above data is the generous amplitudes: three of the four profiles actually saturate at the ADC’s 2.4 V reference voltage, and the fourth (for the lighter cardboard box) reaches 1.917 V. These maximum amplitudes are significantly higher than those of the simulated collisions (around 1.685 V) and that of the tap event (about 1.81 V). So it’s possible that the temporal details of the collision profiles might not create too much difficulty because the algorithm could be developed primarily around the amplitude characteristics.

    Fine-Tuning

    For the purposes of this article, I decided to focus on the wood-covered-by-blanket collisions. Here are profiles from three collisions, including the one shown above.


    You can see that they all pass 2 V fairly quickly and maintain a high slope up toward the saturation point (2.4 V). So compared to the simulated collisions, the maximum amplitude is much higher. They are also of much shorter duration than the simulated profiles; the width of the main pulse is generally around 12 ms, whereas the simulated pulses (just the positive section) were at least ~100 ms wide. This initially caused me a bit of concern because I was using the pulse width to differentiate simulated collisions from tap events, but it really isn’t a problem because of the amplitude advantage mentioned above.
    I saw no reason to abandon the general structure of the original algorithm; all I did was adjust the constants based on the new data. Here are the updated values:
    • First threshold: 12971 counts (1900 mV)
    • Second threshold: 15019 counts (2200 mV)
    • Maximum number of samples from first threshold crossing to second threshold crossing: 7
    • Minimum width (i.e., minimum number of samples from rising-edge second threshold crossing to falling-edge first threshold crossing): 4
    I also had to convert the firmware from the data-gathering version used previously to an operational version. Here is a description of the overall program flow:
    • I manually set the ADC window-compare greater-than value to the first threshold, so that I don’t have to remember to change the configuration file every time I adjust the threshold.
    • The firmware delays for three seconds to give the operator time to prepare.
    • Collision detection is enabled (previously this statement was commented out).
    • The motors are enabled and set to full-speed forward motion.
    • At this point, you can call StartAccelerometerDataCollection() if you want to collect data, but currently, this statement is commented out because data gathering and collision detection cannot occur simultaneously. You uncomment either Enable_CollisionDetection() or StartAccelerometerDataCollection(), not both.
    • A delay statement is used to disable the motors after three seconds; this prevents the robot from running amok if it misses the target, or if the collision detection system doesn’t work as expected. It’s easy to distinguish a detected collision from the three-second-delayed disabling of the motors because the motors brake (i.e., stop rapidly) in response to a collision.
    You can use the following link to download the source and project files:

       Collision Detection Source and Project Files  

    The algorithm works consistently. The following video is a montage of successful collision detections.


    And this next video confirms that the algorithm is robust against tap events. These taps are pretty rough, which makes me think that the algorithm would successfully ignore many non-collision bumps and knocks.


    Conclusion

    We’ve successfully developed and tested an automatic collision detection system built around an accelerometer, a microcontroller, and some carefully designed firmware. The current algorithm is optimized for collisions involving a surface that has a small amount of cushion, as opposed to a very solid surface composed of wood or concrete. However, the algorithm is flexible and can be easily adjusted by modifying the constants.
    By في No comments:
    التسميات: