An SDR For All Seasons

 

 Random Internet screen shot of Vintage Lock-In Amplifiers

I recently acquired one of the Open Source, Analog Devices Pluto Software Defined Radios (SDR) [1] to do some experiments on making a DC-1 GHz Lock-In Amplifier out of it. Since I had some questions when starting it up and I saw that the Internet had some confusion also, I thought I would add my findings and research.
 

Figure 1 – My Pluto connected to my trusty, 45-year-old HP355D, 100 dB Attenuator, to simulate the loss of a test sample in my initial Lock-In Amplifier investigations.

The Analog Devices Wiki for the Pluto [2] does a great job of getting you the right drivers, etc. They also have a demonstration program called “IIO Scope” which is a quick way to get the device running. They also have videos on the web that go through a lot of this.

I suggest that you follow the directions from the Wiki [2]. I run Windows 7 / 10 and I had no issues with any of the drivers or IIO Scope.

Frequency Extension

[Edited  9Jan22 - This section works for all Pluto's so far. If you have a Rev D PCB and want the frequency extension AND access to the other two RX/TX channels, skip ahead to the next section.]

The first issue that comes up is that Analog Devices is somewhat unclear about modifying the software configuration to extend the frequency range from 325-3800 MHz to 70-6000 MHz (Figure 2). They kind of lead you the believe that this configuration modification is only available for the very first devices that they made (Figure 2). Upon further research, it turns out that even the current Matlab Toolbox does this configuration upgrade on every device, and it does indeed work on my Rev C software, Rev D PCB (The current design as of Dec 21).

Figure 2 – The note from the Analog Devices Wiki is unclear as to the ability to do the frequency range extension configuration change for all Pluto’s – but it does indeed work for ALL Pluto's ever made (as of Dec 2021).

The exact commands used for the Frequency Extension Configuration Change are also somewhat muddled on the Wiki, but for the current Rev C / Rev D PCB Pluto the commands shown in Figure 3 are all you need. To log into the Pluto I just used the serial terminal that I use for embedded debugging as the Pluto enumerates itself as a Serial COM port also. See the Device Manager in Windows to find the COM port where the Pluto has been enumerated as. The default user name is: “root” and the password is: “analog” (without the quotes). Again this is all on the Analog Devices Wiki.
 

Figure 3 – Log in to the Pluto with your favorite terminal program and type the commands as shown above and like magic you will have an extended frequency range Pluto. (Rev C / Rev D PCB running FW Version 0.32, these commands may change in the future, this is current as of Dec 2021).

You can use IIO Scope to confirm that the device will now sample at 61.44 MHz and tune to 6 GHz as shown in figure 4.

Figure 4 – By running IIO Scope you can confirm that the configuration changes now work. The Properties panel now will let you set the bandwidth, sampling rate, and upper-frequency range to the enhanced limits as shown.

 

Possibly Useful Configuration Changes

[Edited- 9Jan22 - This section is for Rev C Pluto's with Rev D PCB's only]
The Pluto has a single RX and TX port to the outside of the box via SMA connectors, but the AD9363 transceiver chip that the Pluto is based on has two RX and two TX ports. The Rev D PCB has the extra two ports pinned out to UFL snap connectors that are populated on the board (inside the case). There is a configuration command that activates the firmware in the Pluto to be able to access these two extra ports. The command is,

fw_setenv mode 2r2t

However, there is a problem with the Firmware Version 0.32 that my Pluto arrived with. According to a post on the Analog Devices User Forums [3], there is an issue that prevents the 2r2t command from actually surviving a reboot. So it won't work.

The post describes that you should download [4] the latest firmware zip file, yes the entire zip file, place it in the root directory of the Pluto's onboard drive and then follow the rest of the procedure to upgrade the firmware as detailed here [5]. Today (January 2022) the latest version of firmware is 0.34, that is what I used.

With FW version 0.34 to get both the extended frequency range and the 2 RX and 2 TX paths enabled use these commands,

fw_setenv attr_name compatible
fw_setenv attr_val ad9361
fw_setenv compatible ad9361
fw_setenv mode 2r2t

Then reboot the device. So far this has worked for me - Now I have both extended frequency range and both RX / TX ports enabled.

If you have problems and the settings get confused, just re-update the flash to get everything to a known state and try again. If things go badly, you can always revert to the version that your Pluto shipped with.

Firmware updates always scare me, but I updated my Pluto about ten times today trying different versions out and they all went just fine. So just follow the instructions here [4] and it will all (probably) be fine.

To change back to 1r1t mode just use this command then reboot the Pluto,

 fw_setenv mode 1r1t

Note: Setting the 2r2t mode reduces the maximum sampling rate from 61.44 MSPS to 30.72 MSPS.

Useless Configuration Changes

There is a lot of 'chatter' on the internet on turning on the second ARM core in the ZYNQ FPGA that is used in the Pluto. No one pushing this change can point to any real benefit, however. 

Remember, the XC7Z010 FPGA is not a multicore Intel i7 processor, but instead has two seperate high-performance ARM cores that can indeed share peripherals, but they aren't "multicore" in the same sense as a modern Intel i7 processor that can 'spawn' threads quite easily onto other cores. Hence the standard Pluto firmware won't use the other core, just because you turn it on.

Analog Devices 'official' response is: Is it won't do any good on the standard Pluto (See below). If you are going to write custom FW for the Pluto then, yes by all means you can use the second core as you wish. All that turning on this core will do for the standard Pluto is again 'presumably' turn on the second ARM cores clocks and probably consume more power without any benefit to the standard Pluto.

 

If you read or watch any of the Analog Devices Webinars, then Robin will be a familiar name to you. Here is his take on turning on the second ARM core on the stock Pluto. Bottom Line: It won't help you at all. Source: SignalsEverywhere Youtube channel.

The Analog Devices Wiki documents all the firmware configuration options that may be set - see Reference [6] below.

RF Performance

So the next question that arises is: “What is the performance”, well I have not tested the EVM yet, but just doing a CW source to Single-frequency receiver FFT shows that the uncorrected response is perfectly fine for what this device was designed for, there is no undue roll-off in the extended frequency bands, so excellent job Analog! (See Figure 4).

 

Figure 4 – Using the freeware program SATSAGEN [7] getting a source to receiver plot is easy. This plot, made without any corrections shows a very flat source to receiver response curve over the full 70-6000 MHz frequency range is just over 2 dB peak-peak. I did use a 10 dB attenuator between the TX and RX ports on the Pluto to improve the match.

I also measured the match of the RX and TX ports on my Network Analyzer as shown in Figures 5 and 6. The match is also perfectly acceptable for what this device is intended for.
 

Figure 5 – S-Parameter Plot of the RX port match over the full frequency range. This is perfectly usable for what this device was intended for.
 

Figure 6 – S-Parameter Plot of the TX port match over the full frequency range. This is perfectly usable for what this device was intended for.


Software Compatibility

I found that the Pathosware open-source collection of tools [8] was the easiest way to get GNU Radio and the Pathos Flow programs running on a Windows PC. The only gotcha that I found was that the current release needs Python for Windows 3.9.0 installed. The current Python release is 3.10 and this did not work for me. This information is current as of December 2021 and will change in the future, so be sure to check the Pathosware release notes. I had issues getting the SDR radios to show up with every other release of GNU Radio for Windows install that I tried, but Pathos ware worked the first time out of the box. This is probably because Pathosware uses its own SoapySDR radio drivers. Pathosware also has excellent tutorials on GitHub along with instant help (I got a question answered the same day).


Programming With Other Languages

It looks like Analog Devices has a pretty robust binding package for Python, but my go-to language is C#. Analog Devices also has C# bindings on the Github page [9] and I was able to build a working example in an hour without any major issues, that’s a first, I assure you! Just start a .NET Framework project using a Winform or Console project, and add all the *.cs files from the Analog Devices Github c# bindings to your project. You don’t have to add any references to any DLL’s as Windows will find the proper DLL's at runtime.

On my first compile, I got the error as shown in Figure 6. I searched for this error and found a Forum Post at Analog Devices that told me that this was because I had my C# program in “Any CPU" mode and that the DLL that is referenced is a 64 bit DLL. So by changing the program to "X64" mode this error went away.
 

Figure 6 – If you get this error from the Analog Devices C# example program, then switch to “X64” mode instead of “Any CPU”. The reason is that the DLL being called here is a 64 Bit DLL and won’t work in 32 bit, "X86" mode.

The only other error that I found was with the initial context instantiation in the supplied Example Program. The sample IP address shown in the Example Program is not correct.

You can address a locally connected Pluto one of three ways,

1) Through the USB descriptor (USB:3.7.5) (Your exact digits will be different, here and will change every time the Pluto is plugged into a different USB Port on your PC, so beware).
2) Through the default Pluto IP Address (ip:192.168.2.1)
3) Through the string: “ip:pluto.local”

To verify these Addresses, open a Command Prompt window and type: “iio_info -s”, the results will be something like as shown in figure 7.
 

Figure 7 – The command “iio_info -s” will show you the possible descriptor strings that you can use with the C# bindings to open your Pluto. Don’t worry about the warning (see Red Arrow above), apparently this is not important, and I have even seen it in some Analog Devices Webinars and they go right past it, so it is not an issue. The important bits are the USB descriptor, shown here on my PC as: [usb:3.7.5], note however that this number will change every time you plug the Pluto into a different port of your PC, so beware. The second descriptor is the IP address shown here as “192.168.2.1”, and the third, and easiest one to use is the “ip:pluto.local”, this last descriptor never changes.

If you only have one Pluto connected to your PC then this is the way to go, just use the descriptor “ip:pluto.local” and be done with it.

If you are going to have multiple Pluto's connected then see the Analog Devices Wiki on how to change the default IP address as you will probably want to give each Pluto a unique IP address and then use that as the context descriptor.

 

Figure 8 - An excerpt from the the Analog Devices C# Example program, this context descriptor is not correct for most Pluto users, you should use instead the descriptors as shown in the list above and figure 7. The safest descriptor for most people to use is: "ip:pluto.local".

Conclusion

The Pluto uses a LINUX Industrial IO (iio) interface that also can be wrapped for windows. This is a great concept and one that works well. Overall the entire Pluto Eval Board and Software Ecosystem is very, very well thought out and well documented. Pluto works with nearly every open source SDR tool out there and is a great tool for teaching digital communications concepts. It is even is a passably good scanner receiver even without any filtering or amplification on the input.

I am running my Pluto on a very low performance Dual Core/Windows 7 computer in the lab and it works just fine, so there are not a lot of performance constraints on the host PC's horsepower either.

Extra Bonus – Filter plot

SATSAGEN has a tracking generator/receiver mode that allows a calibration by normalizing the response over a band. I dug up a 1.26 GHz Cavity notch filter that I had in the junk box and measured it with the Pluto (Figure 9). Even without optimizing anything, the dynamic range was excellent and the response showed good agreement to what my ‘real’ HP Network Analyzer showed.
 

Figure 9 – I dug up and measured with SATSAGEN an old 1.26 GHz Notch filter that I in the Lab with the Pluto. The gain response showed good agreement with what my real network analyzer measured. Thus the Pluto is a truly universal kind of RF Building Block, it even works as a Scalar Network Analyzer, and Lock-In Amplifier!

 

References:

[1] https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html

[2] https://wiki.analog.com/university/tools/pluto

[3] User forum post on problems with 2r2t command,

https://ez.analog.com/adieducation/university-program/f/q-a/544531/pluto-rev-c-how-to-activate-the-2nd-rx-channel

[4] Pluto Firmware download location,

As per [3] download the ENTIRE Zip file, do not unzip it, just use this ENTIRE file as per the update procedure below,

https://github.com/analogdevicesinc/plutosdr-fw

[5] Pluto Firmware Update Procedure,

You will want to follow the "Mass Sorage Update" procedure listed here.

https://wiki.analog.com/university/tools/pluto/users/firmware

[6] Pluto list of firmware configurations,

See: "Updating to the AD9364" on this page,

https://wiki.analog.com/university/tools/pluto/users/customizing

See: "All Environmental Settings Table" on this page,

https://wiki.analog.com/university/tools/pluto/devs/booting

[7] SATSAGEN home page, there is no manual, but the author has how-to videos on Youtube.
http://www.albfer.com/satsagen-download-page/

[8] Pathosware homepage,

https://pothosware.com/

Pathos Project on Github,

https://github.com/pothosware/PothosCore/wiki

[9] Analog Devices Pluto C# Bindings and example project on Github

https://github.com/analogdevicesinc/libiio/tree/master/bindings/csharp

 

Post updated: 9Jan22

 

Article By: Steve Hageman www.AnalogHome.com    

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project. 

This Blog does not use cookies (other than the edible ones).

The Perfect DC/DC For IoT Sensor Nodes

   

For once Battery technology and electronics are aligning pretty well for portable equipment. Sure in the last Century we could use some sort of AA Battery holder and get our supply voltage in 1.5 Volt increments, but with today's single Lithium cells operating over a 3 to 4.2 volt range and our 32 Bit Processors able to operate down to 2.5 volts, it is a far simpler task to design a small, battery-operated smart sensor node.

Sensor Operation

Sensors are naturally the heart of any remote sensing scheme. They typically run on 3 to 5 volt power supplies, and in the case of air quality sensors can draw anywhere from 30 mA to 100 mA. If your sensor node is wireless, the Radios also can draw upwards of 50 mA when transmitting.

While 100 mA at 5 Volts is a lot of power, the good news in most of these remote sensors is that they do not need to stream a lot of data. In the case of a recent Air Quality sensor project I did, it didn’t need to read faster than about 1 reading every 10 minutes, since the air quality really can’t change all that quickly. The Wireless data link and processor on time were similarly limited to just a few seconds of operation every 10 minutes, making for a very favorable power profile.

This operational profile leaves a lot of potential power optimization potential for extending battery life or reducing battery size.

Simple Sensor DC/DC

The Air Quality sensor that I was working on required two 5 Volt Sensors, an Air Particle sensor, and a CO2 sensor, the rest of the circuitry was designed to run on a continuous 2.9 Volt low power, linear regulated supply.

What is needed then to power the sensors is a 3 to 4.1 input voltage range and a 5 volt output at up to 100 mA, a further requirement of an enable control was needed to turn the sensors on only for a reading and a power good signal was required also so that the processor can judge and transmit the condition of the measuring system.

Looking around at the various manufacturer's section guides turned up the LTC1751-5, an Inductorless Switch Capacitor Voltage Doubler.

Inductorless is nice to remove the radiated EMI of a boot converters inductor from being a possible problem and possibly reduce the overall size of the DC/DC.

Figure 1 shows the basic circuit configuration of the converter. As mentioned the Power Good signal is useful for the Microprocessor to monitor if the power is good, this is an early warning that something is wrong with the sensor and this information can be sent with the wireless data back to the sensor data collection hub.

  

Figure 1 – The application circuit of the LTC1751-5 is the definition of simplicity itself. No inductors and even a Power Good output.

For instance, if the Microprocessor reads an out-of-bounds sensor value – what does that mean? But if the Microprocessor reads a out-of-bounds sensor value AND the power good signal is low, that is almost certainly a shorted sensor and the Microprocessor can not only tell the data collection node that the sensor is faulty, but the Microprocessor can also turn that sensors power off to make sure that there isn’t excessive power drain.

Application Hints

The circuit of figure 1 is nice and compact, but there are several points that are worth noting,

#1 - The output voltage ripple can be quite large – the LTC1750-5 datasheet shows 100 milli-volt peak to peak at 100 kHz with the circuit values shown. To get these values you must take care with the capacitor selection. This is one place where a ceramic capacitor's voltage coefficient can cause you trouble. Carefully look at the capacitors data sheets to make sure that your selected 10 uF output capacitor isn’t acting like a 1 uF capacitor with 5 volts of DC bias [2]. The same caution applies to C1 and C4. A couple of eye-opening articles on this subject are noted in Reference [2] below.

Capacitors of the rated value with DC Bias with low ESR are a must, and possibly secondary filtering may be required. To keep the noise levels low. See Figure 2.

#2 – The input current ripple from the LTC1751-5 running at full load is in excess of 100 mA peak to peak at 100 kHz. If operating on a small battery be sure that this amount of ripple won’t cause undue stress on the battery, especially its protection circuitry. Extra filtering may be required. A small, low ESR Super Cap may be an optimum solution to buffering the battery. Less optimum is the addition of a small LC input filter, but it can do the job very well.

#3 – Inrush, or start-up current may be a factor when running on a small battery, be sure to take this into consideration when designing the circuit. A large inrush current may cause the battery's short circuit protection to activate, especially at low temperatures.

Figure 2 – Three ceramic capacitors rated at 6.3 Volts were measured on my bench versus DC bias. The only totally safe one is the upper trace, a COG type (Blue curve above). COG types are the largest of ceramic capacitor family, but also always have a very low capacitance change with DC bias. Even X7R types can be worse than you think! Check every capacitor datasheet carefully [2].

#4 – Output noise is potentially considerable even in the suggested circuit on the datasheet, the output noise is in the 50 to 75 millivolt peak to peak range. Again you may need to increase the output capacitance and or C4 or use secondary filtering. See the datasheet for some suggestions.

#5 – Turn-on time – you have a few adjustments for turn-on time. Larger output capacitors will slow turn-on time as will adjusting the “Soft Start” capacitor (C3 in Figure 1).

#6 – Simulate or be prepared to rework: Of course, nothing beats an actual breadboard of a circuit for testing, but Linear Technology provides a “Test Jig” circuit of the LTC1751-5 for use in LTspice, it seems to simulate the noise and turn-on characteristics accurately.

#7 – If you do use an inductor-based LC filter to reduce the conducted noise, do yourself a favor and ALWAYS use a ‘Shielded’ type construction unless you want radiated noise everywhere [x].
 

Figure 3 – Linear Technology provides a LTC1751 “Test Jig” circuit for use in their LTspice circuit simulator, it is highly recommended that you simulate your circuit before committing to an actual PCB. Do be sure to accurately model the capacitor ESR - because this default Test Jig From Linear Technology uses ideal capacitor models, that's kind of overly optimistic for any power supply! Power Supply Circuits Live and Die based on the capacitors ESR!

Alternatives

You might be thinking: “Why not just use a regular Boost DC/DC Converter, it has a built-in LC filter on the input that reduces input current ripple, so it might be simpler in the long run.” See Figure 4.

 

Figure 4 – A standard Boost DC/DC converter has the power inductor on the input circuit that reduces the input ripple current, and that can simplify the overall application circuit. But it does have a potentially major fault for a battery-operated circuit, and that is it has no inherent short circuit protection. If the output is shorted for whatever reason, the controller can do nothing abort it as there is a straight-through path from the input to the output through the inductor to the boost diode to the short circuit.

And that is a valid point, but in my battery application, the short circuit protection was a requirement to keep the main application running in case of an Air Quality Sensor failure. That short circuit protection combined with the “Power Good” signal out of the LTC1751-5 gave me a level of onboard diagnostics to be able to deal with a potential sensor failure.

Bonus Information

Some manufacturers have wonderful online/interactive tools that allow you to pick any of their ceramic capacitors and get a display of all the pertinent parameters including ESR and the effect of DC Bas on the capacitance value.

One such tool is from the AVX Website [4], and picking a typical 10uF, 6.3V, X7R, 0805 capacitor produces this result,

 

Figure B1 – A typical Capacitance value drop of a 10 uF, 6.3V, X7R 0805 capacitor that took only seconds to generate from the AVX website.

 

Figure B2 – A typical Capacitance value drop of a 10 uF, 6.3V, X7R 0805 capacitor that took only seconds to generate from the Murata website.

Beware #1 – This is typical data only – i.e. Even the manufacturer didn’t go measure each, and every one of their thousands of different capacitors.

Beware #2 – Don’t think that all manufacturer's capacitors will perform the same as these will, while they might be similar, they won’t be the same and you could still expect to see variation from these capacitors from some other brand. If there isn’t an interactive tool, then you will just have to search the datasheets, or better yet, make your own measurements.

References

[1] Linear Technology LTC1751 Data Sheet

[2] Mark Fortunato, Maximum Integrated Circuits Tutorial, TU5527,
https://pdfserv.maximintegrated.com/en/an/TUT5527.pdf

Also this excellent article,
https://passive-components.eu/dc-and-ac-bias-dependence-of-mlcc-capacitors-including-temperature-dependence/

[3] Hageman, "Friends don't let friends use un-shielded inductors",

https://analoghome.blogspot.com/2017/10/friends-dont-let-friends-use-un_5.html

[4] I am sure that these links will be broken in just a few months from now, but it will be on the AVX and Murata websites somewhere, just go there and search for them....
 

AVX Online Selector Tool,

https://spicat.kyocera-avx.com/mlcc
 

Murata online tool, they call it ‘SimSurfing’
https://ds.murata.co.jp/simsurfing/mlcc.html?lcid=en-us

These sorts of tools from manufacturers are always changing - be sure to check all the manufacturers websites for the latest available information. 

Article By: Steve Hageman www.AnalogHome.com    

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project. 

This Blog does not use cookies (other than the edible ones). 

Preventing Design and Support 'Oopsies'

    

This is a story of how easy it is to have ‘Oopsies’ in the development of products, new, and old. It’s all related to the Data Sheet, and mostly out of your control.

Case 1:

Over a decade ago new FPGA designs came online and naturally everyone used one since they were 'big and fast'. In one FPGA project I was associated with we could not get the FPGA to ‘turn over’, this was perplexing. Everything looked wired OK, yet the FPGA would not start. Since everything looked to be done according to the data sheet, what was the issue? Everyone started to take an interest in this and another engineer downloaded the datasheet directly from the manufacturer's website ‘freshly’ as it were.

Well – ‘Big Surprise’ !!!! This new revision of the datasheet had added in the fact that the power supplies were required to be sequenced in a certain way for proper operation, where the previous datasheet said nothing of the sort! Once the Power Supplies were sequenced as per the latest datasheet – then the FPGA started right up.

Now you know why there was suddenly a rash of FPGA power supply sequencing IC’s released a decade ago!

Lesson learned: At the start, middle, and end of the current project, download ALL the critical parts datasheets and check them for changes (at least check the revision date). IC manufacturers are rushing just as fast as everyone else, and you have no idea when they will find an ‘issue’ and report it.

Aside: This is probably the reason why so many so many FPGA designers are Bald, they didn’t start out that way, it just comes from scratching their head so much.
 

Why FPGA Designers are mostly bald! 

Photo by Ketut Subiyanto from Pexels, used with permission.

Case 2:

Last year I started working on an Air-quality Data Logger. This was a battery-powered device with an LCD and SD Card for data logging. I started the project and immediately found that the I2C connection to the Air-quality sensor was not reliable at the rated 100 kHz clock speed. But seemed to work at 40 kHz and below, well to measure Air Quality doesn’t take Gigabits of bandwidth, so I started running reliability tests at 40 kHz, by sending random commands and making random measurements and found that there were no connection issues. I have used the I2C with this particular hardware setup for years with no issues at all, so I doubted that the issue was on my end. The fact that I could not reach the datasheet speeds was still disconcerting, but you know – put off till later.

As things go this project got put aside for more pressing projects, and about 6 months later I had time to start it up again. I found the same issue and I found that if the Air quality Sensor hung a power cycle was required to clear it. The operation mode was to have the air quality sensor off for 10 minutes then turn it on for one minute to make a measurement then turn it off again, so this seemed like a sure-fire way to clear any errors that may happen in real use.

Since it had been six months I had in the meantime forgotten what the sensors units of measure were, so on a summer afternoon break under a big Oak Tree, I downloaded that datasheet again on my Tablet to refresh my memory….. and – well you know what I saw! Yes, the datasheet had been updated the previous month to show that a non-standard I2C delay needed to be inserted between the writing of the command byte and the subsequent reading of the data. Normally an I2C compliant device would use “Clock Stretching” to achieve the required delay, but…

When I got back to the lab, I modified my I2C driver and – Viola! No communication issues even at 400 kHz!

Lesson learned: Don’t ignore issues like this, at the very least call the manufacturer or see if they have a user forum, or search the web for some forum entries on the part to see if anyone else has found the issue you have. If I hadn’t had the project break, I would have not found this datasheet change and would not have had the confidence to know if the driver was robust or not.

Aside 1: This is not the first time that I have had a timing issue between sending a command to some device and having some issue with how long it takes the sensor to process the command and send the result. So hopefully in the future, if I see this problem again I will hook up my logic analyzer and vary the delay between the command to return to see if the issue can be resolved as experience has shown this is the most likely issue.

Aside 2: The most common issue with I2C devices is the Stop/Start versus Repeated Start operation, while in theory, most devices like EEPROM’s work equally well with either a Stop/Start or Repeated Start sequence, many modern and complex IC’s do not. Also, many data sheets are unclear as to their particular device's exact requirements. So if you can’t get your device to respond correctly try exchanging a Stop/Start with a Repeated Start and visa versa.

  

STM32 I2C Register Configuration Bits

Case 3:

I have used this one microprocessor for several project generations, so there is little risk when updating one generations product to the next, and that is mostly limited to the changed parts of the design that happens between generations. I was wrapping up the Firmware Drivers on one of the latest projects and out of the blue, I decided that I should check the latest Errata on the part to see if anything got better. Sometimes, just sometimes, Silicon changes for the better between revisions, after all.

As I read the newest Errata, which had only been updated the month before, I was aghast to see that the required processor wait states had increased for the newest silicon revision! This doesn’t affect any parts already built, but certainly does affect any new parts that might be built, and the scary part is it was by total happenstance that I found the issue to begin with. A simple fix for this latest project, but I needed to go ‘touch’ all the previous Firmware on any shipping product to roll this fix it. That entails doing at least some targeted QA on all the projects to look for unintended side effects also. This could be a large unplanned cost.

Think about what can happen here: Someone designs a product, it works, then they move onto something else, and as long as it keeps working, they never look back, yet the part changed its characteristics in the meantime, which can now cause ‘corner case’ failures where there were none before it. The issue is: no one is in charge of ‘Maintenance’, so if someone doesn’t notice this change you can end up with a lot of iffy parts in the field that fails for baffling reasons, under certain conditions.

Lesson learned: Check the Datasheet for Errata at the beginning and end of every project to make sure that you understand the changes that have happened, don’t be lulled by ‘Familiarity Bias’. Don’t rely on the manufacturer issuing a PCN (Product Change Notice), because everyone has a different ‘definition’ of what a PCN is and this change did not elicit that kind of trigger from this manufacturer.

Aside 1: Sometimes Erratas are buried in the pages of the data sheets – most Microprocessors have 500-page plus data sheets and who can get through that? So look at the end of the datasheet where the Revision History is kept and try to discern when and where the changes have been made.

   

Microchip dsPIC Silicon Revision Eratta

Bottom Line:

A small number of manufacturers, and even some distributors allow you to sign up for ‘product updates’ – Always do this. Sadly not enough do, also sadly most manufacturers don’t use PCN’s in the spirit that they were intended: “Any change to form fit or function that might cause a customer grief”.

The only thing you can do is to keep checking the datasheets for updates, especially when actively working on a project. It is a less than ideal situation, but a very important one.



Article By: Steve Hageman / www.AnalogHome.com
We design custom: Analog, RF, and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help with your next project.

Note: This Blog does not use cookies (other than the edible ones).

The Digital Filter You May Not Have Known You Were Using…

 

(Random Screen Grab From The Internet)

You use this digital filter knowingly or not, every day – it is inherently built into every Digital Volt Meter (DVM) by the fact that a common DVM is set to integrate its input signal over one line frequency cycle on every measurement. Most people know that the integration period of 1/60 Hz (or 1/50 Hz depending on where you live), or one power line cycle, allows the DVM to reject the 50 or 60 Hz noise and that noise is everywhere. You simply can’t get away from line frequency voltages and interference in the modern world. It turns out that this natural line frequency rejection is a form of a digital filter and it follows the Sine X / X, or Sinc() function as shown in Figure 1.

 

Figure 1 – Sine X / X, or Sinc() function frequency response. This response is ‘naturally’ built into every DVM by their integration over an exact number of power line cycles. This sampling then provides a null at the power line frequency, providing rejection to any power line noise. This is perhaps the most common form of a Digital Filter Around. The Blue Curve above is the Sync() filter frequency response, the Orange lines are the asymptotes that converge on the -3 dB response point.

The Sync() function is equivalent to sampling the input voltage with a rectangular window of time T.

The great advantage of the Sync() function is a Null at known intervals, and smooth transient response, this is of great advantage in a DMM. Its disadvantage is the passband is not very flat and has a long, droopy roll-off as is characteristic in these linear phase sort of filters.

As figure 1 shows the -3dB point is at 0.45 times the first null frequency. Table 1 lists some other pertinent roll-off points. The Frequency is normalized to the first null frequency.

Table 1 – A Sync() filter has various amplitude roll-off points as listed in the table above. The frequency is normalized to the first null frequency. Example: A DMM integrating for 1/60 seconds would have a -6 dB noise bandwidth at 36 Hz (60Hz*0.61 = 36Hz).

This same filter function happens if I take a 1 Mega-Sample Per Second (MSPS) ADC and store it, then average the samples over a 1/60 Hz (16.6 milli-second) period. Essentially the ‘integration time’ is 1/60 Hz and the same Sinc() filter function is again the result.

The integration time of the DVM can also be thought of as the ADC’s ‘Aperture Time’. That 1 MSPS ADC that was used in the averaging example also has an ‘Aperture Time’ that is the length of time that its internal Sample and Hold takes to switch from: Acquire to Hold modes. Aperture time, as the Analog Devices tutorial on Sample and Hold Amplifiers [1] points out,

“Perhaps the most misunderstood and misused specifications are those that include the word aperture. The most essential dynamic property of an is its ability to disconnect quickly the hold capacitor from the input buffer amplifier. The short (but non-zero) interval required for this action is called aperture time.”

Yes, misunderstood and in modern ADC’s not even commonly specified on the datasheet! The Acquisition Time is commonly specified as the time required to acquire any signal to the specified accuracy, but the Aperture Time itself is not.

Most higher speed ADC’s now have a very, very, very small Aperture Time, this can be inferred by the Analog input bandwidth which is usually much, much greater than the ADC's Nyquist frequency. For instance: A Linear Technology LTC2328-16, 16 Bit, 1 MSPS ADC has a specified analog input bandwidth of 7 MHz. The Data Converters have these large bandwidths to accommodate under-sampling and Nyquist folding of the input signals. In the LTC2328 case, this input bandwidth limitation is due to the Analog Input Circuit inside the ADC, not the Aperture Time. As an example calculation on the upper limit of Aperture Time on this ADC let's assume that the input bandwidth is set by the Aperature time and not the RC time constants in the ADC’s input circuit.

From Table 1 the -3dB point is found to be 0.45 the first null frequency, so if the -3dB point is 7 MHz, that would mean that the Aperture Time of this ADC is: 7 / 0.45 = 15 MHz or 1/15 MHz = 66 nSec. This is entirely wrong of course as the input bandwidth is not set by the Aperture Time, but by the input circuits time constants. This is however an upper limit on how big the aperture time could be to explain the input bandwidth effect, meaning: “The Aperture Time could not be longer than this and still get the rated input bandwidth of 7 MHz”

Analog Bonus Circuit

It is possible to simulate the Sync() filter with an OPAMP active filter circuit. Philbrick / Nexus research published this analog Sync() filter way back in 1968 and was named after its inventor, Henry Paynter who was a partner in the firm [2].

This circuit of figure 2 is a Third Order Liner Phase Shift ‘Paynter’ filter. Paynter filters are still widely used today in filtering biological types of signals and are even synthesized in many ‘digital’ implementations.

As per Philbrick: “...This filter is particularly useful for averaging functions of non-stationary random variables since its transient-response time is minimum for a given averaging time…” [3]

 

Figure 2 – The circuit for a Paynter filter that simulates a Sync() function response. All the values are normalized to the ‘notch frequency’.

Notch is at Wc = 1/(RC) or Fc = 1/(2*PI*R*C) Hz

 

Figure 3 – Frequency Response of the Paynter filter of figure 2 (Orange Curve) with the ideal Sync() filter response superimposed on it (Blue Curve). This filter was designed to have the 'Null' at 60 Hz.

 

Figure 4 – Linear phase filters like the Paynter have good transient response without excessive overshoot as shown from this LTSpice simulation of figure 2.

References:

[1] Analog Devices “Sample-and-Hold Amplifiers” MT-090
[2] https://en.wikipedia.org/wiki/Henry_Paynter
[3] Application Manual for Operational Amplifiers
December 1965, Philbrick / Nexus Research, Dedham, MA


Article By: Steve Hageman / www.AnalogHome.com
We design custom: Analog, RF, and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help with your next project.

Note: This Blog does not use cookies (other than the edible ones).