The Blog Continues.....

 (Random Internet Screen Shot)

New Blog Posts have moved (at Least Temporarily) to EDN.com.

Read more at: https://www.edn.com/author/steve-hageman/

 

Or you can see a complete lists of the Blogs, Articles, etc. at,

https://analoghome.com/publications/

 

A complete list of posts here at Blogspot should be at the bottom of this page.

The 1980s called, they want their C compiler back

 

(Random Internet Screen Shot)

Plaguing your code with debugging statements

I know how this happens, it is the belief that making a function call, even an empty one will create overhead in a C program. However, that is not the case anymore. Today's C compilers are very aggressive in optimizing, especially at cutting out dead code.

Example: I was looking through a micro-controllers library so that I could figure out how I could use it, and I saw a bunch of code that looked like this,
 

Figure 1 – Nothing wrong with debugging statements, it’s the distraction of all those #ifdef / #endif statements that make the code hard to understand.

Figure1 is really very hard on the eyes, the indent level keeps changing and all those #ifdef / #endif statements really make a visual mess out of the whole code base.

Do yourself a favor and write a simple logging function, then your code can look much cleaner like this,
 

Figure 2 – Refactoring the debug statements into a debug function really cleans up the appearance of the code.

I still don’t like the indention style, but that is a matter of preference, as the indention style that this author used is certainly a common convention.

The logging function can be as simple as this,
 

Figure 3 – Refactoring the serial debug print statements into a function can be as simple as this and can be used everywhere throughout the code if desired in the future.

Logging still works the same way, add a #define DEBUG_TO_SERIAL in the code to enable logging, and then do a #undef DEBUG_TO_SERIAL to stop logging.

Objection

The main objection is usually this: “You will still have a function call with debugging turned off, making your code bloated, slower, and bigger.”

This isn't the 1980's anymore and our modern compilers are very good at optimizing out code that does nothing. In fact, every compiler I have used in the last 10 years, especially the ones derived off of GCC, when doing even minimal optimizing (Level=1) will see that the function call is empty and that the passed variables are not being used and the compiler will simply not generate anything if the flag DEBUG_TO_SERIAL is not defined. It just ignores the entire function call as if it never existed.

This is the same as most compilers today will totally ignore “Quick and dirty delay” statements like this ‘attempt’ to make a delay, not generating any code at all,

     For(int I = 0 ; I < 1000 ; i++)
     {
          int j = I * 1000;
     }

Snippet – A modern compiler, like GCC, will easily see that the code above does nothing and will completely ignore it, not generating any assembly code at all.

Conclusion: 

Remember that the compiler you are probably using is very, very good at getting rid of dead, unused code even at low optimization levels. Therefore you can write code in a very clean way, and help those who come after you in more easily comprehending your code.


Bonus:

You now have the makings of a very nice debug / logging library that you can start to use everywhere, while still keeping your code very readable.

 

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).

Simplify Testing Of Embedded ADC's

  

Blog Post @ EDN.com - June 22, 2022 - Simplify testing of embedded analog-to-digital converters - Shows the open source 'BlasterAmp' that uses a USB Sound Blaster sound card and a custom PCB to easily make high quality test waveforms that really helps testing embedded, or any ADC, up to about 16 bits.  Open Source Documentation Location: https://github.com/Hagtronics/BlasterAmp

Calling External Tools From Visual Studio 2022

   

(Random internet image grab of: Software Tools)

QT Designer is almost a substitute for the wonderful Drag and Drop Winform's GUI Interface that we have used for decades with Visual Basic and C# inside of Visual Studio.

The worst part is that they are not integrated well within any IDE, forcing you to go to a command prompt to run the Designer, then compile the UI code with the pyuic5.exe compiler. Linux folks are fine with running command-line tools all day long, but as a Windows user I don’t want to have to remember command line prompts, so I wrote a script to automate the PyQT5 GUI building process.

The python script and methods for calling external programs from within Visual Studio apply to a wide range of possible uses. For instance, if one wanted to call and execute a GCC Make file, the same basic automation steps would be applicable.

Prerequisites:

PyQT5 Designer has been changing fast, so it is liable to change again by the time you read this (March 2022), so check online for the latest instructions.

To use PyQT5 Designer you have to have this package installed in your Python environment, either use a windows command prompt or if you use Anaconda, type this command at the Anaconda command prompt,

pip install PyQt5Designer


Automating with a Python Script:

While it is simple to launch a program from the Visual Studio Tools menu, automating a process where you need to select an item and then do some automation is not easy to do without a script of some sort. Python is the perfect language for these sorts of applications. It is relatively easy to get going on a windows PC and it is a well-known scripting language with millions of example scripts on the web to learn from.

The script that I wrote to automate the PyQT5uic compile process is available on GitHub [1]. Basically, that script, when run, opens a file Tkinter dialog box that asks you to select the PyQT5 Designer XML GUI file (the file with a .ui extension).

After a file is selected the script then assembles a command line like this,

pyuic5.exe “-x myGui.ui -o myGui.py”

Where myGui.ui is the GUI file that you make with the PyQt5 Designer program (it can be any name) and the myGui.py is the output file for the compiled .ui input file.

The ‘-x’ command tells the compiler to make the resulting .py file ‘executable’, which means that it includes a: if __name__ == __main_ block this option that allows you to execute the myGui.py file to see if it works immediately.

While sometimes this can be hard to get right using other languages, what with the need to make a string with the quotes in the proper spot and then call a shell to run it on the command line. In Python, there is this wonderful thing called “subprocess”. It allows us to very simply just build a list of the commands to be output in sequence, then with one simple call to: “subprocess.run()” we get a perfect output every time.
 

subprocess.run() – Should be the heart of any Python Automation Script. With subprocess.run() a simple list is made up with the various command line parameters and then with a single call the external process is called with the parameters being perfectly ordered.

In the example below I downloaded and placed the automation script from GitHub [1] in the directory,

C:\Users\steve\AppData\Local\Programs\Python\Python39\Lib\site-packages\QtDesigner\RunPyUic5WithPrompt.py

Your exact path will be slightly different. See below on how to find where your site-packages directory is if you don’t know already.


Integrating PyQT5 Designer and Compiler Workflow

There is a myriad of videos on YouTube on how to step by step build a GUI using PyQT5, so I won’t repeat that. What I want to do is to integrate the workflow into Visual Studio.

The process is,

1) Make a GUI page with Designer.exe, save it as an XML .ui file.
2) Compile the XML GUI file (.ui) to Python code file (.py)
3) Add the GUI Python code to your project.

Steps 1 and 2 above usually require the programmer to go to the command line to execute the various commands. That is annoying and I will show how to integrate those steps into the main Visual Studio Workflow here.

Visual Studio has a mechanism to add external tools to the Visual Studio IDE itself via the menu item: “Tools”.

To add your Tools to this menu follow the steps below,
 

Figure 1 – Select Tools, then External Tools
  

Figure 2 – In the External Tools dialog, you can add, delete or modify your add-in tools. Here I have three tools defined. I deleted the two default tools that Visual Studio ships with.

 

Figure 3 – To make the QT Designer entry, press “Add”, then add the following items,
1) I called the Title: “QT Designer” but you can use any title here you want.
2) In the Command, I added the path to the QT5 designer.exe program. In my case it is,

C:\Users\steve\AppData\Local\Programs\Python\Python39\Lib\site-packages\QtDesigner\designer.exe

Once you find where the designer.exe is on your system, then add that path instead.

Note: You can always find where your site-packages folder is by running this command at the command prompt,

python -c "import site; print(''.join(site.getsitepackages()))"

The initial directory is pointing to your current project as most people will want to keep the GUI code with the project. If not then select some other Initial Directory.

 

Figure 4 – Now “Add” another item for the PyQt5 UIC compiler – this is the program that converts the XML .ui file into Python code.
1) As above – Add any title that you like.
2) For the command, since this will be running a python script, we want to launch python itself, and in my system, this is the path to python (it will be slightly different for your system),

C:\Users\steve\AppData\Local\Programs\Python\Python39\python.exe

3) In the Arguments field add the following path to the automation script that we got from GitHub,
Again this exact path will be slightly different on your system,

C:\Users\steve\AppData\Local\Programs\Python\Python39\Lib\site-packages\QtDesigner\RunPyUic5WithPrompt.py

4) The Initial Directory is again set to the project directory.

 

Figure 5 – As a bonus, since we are here, let’s just add a tool that opens a command prompt in the current directory with the fields set as in the figure above.


Using The New Workflow:

Start a new Python Project in Visual Studio. To add a GUI element using the PyQT5 Designer, select: “Tools” → “Qt Designer” from the main menu. The PyQT5 Designer window should open.

Design your GUI as normal, then when you select “Save As” in the designer, it should be in your current working project directory. Save your new GUI element as a .ui file. Then exit the designer.

To compile your GUI .ui code file, again go to: “Tools” → “Qt PyUic5 Compiler” as shown in figure 6.
 

 

Figure 6 – To compile your .ui GUI files using the automation script, select: the “Tools” → Qt PyQTUic5 Compiler” item from the Visual Studio main menu.

 

Figure 7 - The automation script that we added will pop up a dialog box asking you to select the .ui file that you wish to compile. Select the proper .ui file and then push “Open”.
  

Figure 8 – The PyQtUic5.exe program will then be called on the selected .ui file and compile to a .py file. When the script completes it will say that it is finished. If some error happens during compilation, that will also show up in the Python command window.

Warping it up:

You can easily extend Visual Studio by writing automation scripts and then including the workflow commands into the Visual Studio External Tools to make any process much more user-friendly.

With the automation here, you can then start a Python project, design a PyQT5 GUI, and compile it all without having to leave the Visual Studio IDE.

Almost all IDE's have the hooks to add calls to external tools, so the concept presented here can be implemented in a wide variety of IDE's and programming environments.


Bonus Information:

While PyQT5 is the tool to use for large GUI’s, it still leaves a lot to be desired and is not as easy to use as the Visual Studio Winform’s designer.

In those instances where just a file or general dialog box are needed then it may be better to just use the base functionality in Tkinter itself (Also see the python automation script that I wrote) [2].

If a slightly more complex GUI is needed, then consider PySimpleGUI [3]. This is a simple row and column-based way to make a GUI. It is made simple to use by the hundred or more demo programs provided on the PySimpleGUI GitHub page [4]. Just find something close to what you need and clone it as a starting point – that IS simpler than the Visual Studio WinForm’s designer.

References:

[1] The Python automation script presented here can be found on GitHub at,
https://github.com/Hagtronics/PyQt5-Designer-Automation-Script

[2] Tkinter documentation
https://docs.python.org/3/library/tkinter.html

[3] PySimpleGUI home on GitHub,
https://github.com/PySimpleGUI/

[4] PySimpleGUI Demo programs,
https://github.com/PySimpleGUI/PySimpleGUI/tree/master/DemoPrograms

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).

Philbrick Research P65 OPAMP From 1962

 

This has got to be the longest I have ever procrastinated on any project! I ‘Saved’ this Philbrick P65 OPAMP from a Dumpster in about 1980 and I have treasured it ever since then. I mean who wouldn’t want a little discrete OPAMP in a nice cardboard box, and housed in a shiny metal case?

Finally, I have powered it up and tested it. And..... Yes, it still works. Did you think it wouldn’t?

The Presentation:

The George A. Philbrick Research (GAP/R) P65 came in a fine little cardboard box with a nice enameled black label. Inside is a neatly folded data sheet on top of the P65 itself, which is kept in place by little cardboard tabs (See figures below).

The P65 itself was billed as,

“Model P65 is an all silicon solid-state unit designed for applications in instrumentation, computing, and control where plug-in versatility, low cost, long life, low power consumption, low noise, and operation at any temperature from -25°C to +85°C are desirable.”

I’m not sure exactly when this unit was made or purchased, but the date on the datasheet says 1962.

An “All Silicon” amplifier was cutting edge, and more expensive in 1962 as there was still a lot of Germanium floating around then.

I powered the unit up and not surprisingly, the OPAMP still works. I checked a lot of the specs on the datasheet, and did some tests on loop gain, step response, and noise. The P65 all pretty much works today just like it did in 1962.

As can be seen from the board topside photo below, it is a mix of Texas Instruments, I think the “Diamond N” logo is the old Panasonic house brand ‘National’ (I may be wrong, it may be National Semiconductor) and there is another logo that I can’t quite make out, it’s red - whatever it is, so we will just call it TI also. 

Conclusion:

The first transistors I ever ran into were from really old radios and they were in metal cans that had Phenolic headers, I doubt that any of them work anymore as the Phenolic wasn’t a very good hermetic seal, these transistors are sealed well enough to have lasted from the 1960s and still operate.

Now I guess I have to go out and buy three or four more of these to make some sort of Analog Computer out of them. That's the way it always is: One thing leads to another.

Perhaps it would have been best if I hadn't powered on the P65 on after all! 

Figures:

 

Data Sheet Page 1

 

 

Data Sheet Page 2

  

Box Outside

 

Box Inside - Showing how data sheet is supplied.

  

Box Inside - Showing P65 in its little nest

  

Box Inside - P65 Removed, empty box

  

P65 - Top - The Offset Trim adjustment screw hole is on the opposite side.

  

P65 - Bottom - Trim Adjustment screw hole is on the top of this picture.

 

P65 - Side view with side cover removed. The side covers were tacked in place with solder. You can see the Trimpot pointing out the side inside the unit.

 

P65 - PCB Top - Yes that is a Offset Trim Adjustment Potentiometer. At a Gain of 10, It was easy to adjust the P65 to less than 1 mV offset using the Potentiometer.

 

P65 - PCB Bottom - The solder joints still looked nice and shiny.

 

P65 - Large Step Response AV=10, Red = Output, Blue = Input

 

P65 - Small Signal Step Response AV=10, Red = Output, Blue = Input

 

P65 - Closed Loop Gain Measurement AV=10, & AV=1. Just about the same as a LM741 which was designed in 1968.

 

P65 - Input Noise Voltage Measurement - Not too bad for 1962 - 18 nV/rt-Hz > 1000 Hz

Not shown but measured: I measured the Full Power Bandwidth and with 20Vp-p output the P65 easily met the 10 kHz specification.

References:

All of the documentation on the P65 here has been placed at the Internet Archive,
https://archive.org/details/philbrick-p-65-opamp


Also see the Philbrick Archive for a lot of other Philbrick information including some magazine advertisements for the P65 at,

https://philbrickarchive.org/

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).

 

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).