Designed & Made
in America (DMA)

BASIL Networks Blog BN'B | December 2018

7 Dec, 2018

Internet of Things (IoT) Security, Privacy, Safety -Platform Development Project Part-15

Part 15: IoT Core Platform Development;- Peripheral I/O Device Design
The IoT Embedded Core Platform -Analog Input Peripheral Device Design - Continued

"There is no end to education.  It is not that you read a book, pass an examination, and finish with education.  The whole life, from the moment you are born to the moment you die, is a process of learning". - Jiddu Krishnamurti (May 12, 1895 - Feb 17, 1986)


Quick review to set the atmosphere for Part 15:
From the previous Internet of Things Part-1 through Part- 14:

We will be presenting documentation throughout the design process to keep it interesting.  At first we dove right in to the actual design and created several pieces of documentation during the process. This part will give some more insight on the actual documentation process setup for product development and how to create Project Requirements Documents in a simple step by step process.  This is the right time to introduce the Project Management (PM) and Project Requirements Documentation process for traceability using a Database Management System and the IPD System.

The basic features incorporated into the IPD system are:

Additions were made to the Opening IPD System MAIN MENU as shown below.- Part 13 was also updated to reflect these changes.  As we see there have been a few additions and we will present the additions that are effected in this part of the series.


Figure 15.0 IPD Interactive Product Development System Top Menu Update

What we want to cover in Part 15:
It is time we addressed the technical side of the RTM (Requirements Traceability Matrix documentation since we will be setting up test cases.  There is no magic to Project Management practices as we will see by the end of this series.  We will present some documentation requirements for a few more parts at the introduction in order to become familiar with the IPD Systems flexibility.  This is still a development project series and our intent is to remain at the technical level while highlighting/outlining the documentation requirements of product development.

Traceability during development covers all aspects from Business, Legal as well as Technical and  is essential when validating each stage of the project.   We will keep this more at a technical project development, PoD (Proof of Design) level for a while until we get to a point where the business side is required.  At this time the IoT Core Platform is a universal platform that may be applied to many infrastructure critical applications as well as commercial simple applications giving it a wide range of applications.

We will answer questions sent in for our readers about the design in general and why certain parameters and parts were chosen.

Lets Get Started:
The IPD Documentation - Developing Documentation Discipline
It is always beneficial to review the documentation process being used to keep the our development processes organized and to review the areas that have not been completed, not that we have to complete them in any order per ser,  it is to initialize a mind set for the section currently being developed.  The mind of the passionate creator is not a linear step function, 1, 2, 3 ...N, probably because humans are not robots, that follow a preprogrammed set process.  The mind fills in parts of the process sometime a few steps ahead and changes a few steps back as the development progresses.  What is required is flexibility to perform tuning the development in real time.

Organization and Project Management (PM) are important parts of any development project period.  However it is only a part of the project that keeps it on a direct path to completion.  The intent/goal is to have a PM application program that allows the entrepreneur to focus their passion for product design while "intuitively" keeping track of all the different aspects of product design.  As we will see as the development moves forward the organizational and security of the IPD system incorporates a simple interactive step for each stage of the development which allows the creator to focus on the technical details of the design, make changes along the way while maintaining an organizational methodology for the documentation of the project.

IPD System Directory Structure Architecture:

Naming Conventions:
When the average reader looks at the diagrams of the directory structure there is always the thought of why so many directories?  Answer:  - Quick review.  There are several reasons, which we will highlight with a few now and address more in depth as the series moves forward which will be self explanatory as we enter different developmental stages.  The engineering practice answer is "a good naming convention is a must for all application packages and mandatory for any project or product development".  Naming conventions allow instant memory recall (the human type) on what is in the file and provides simple filename organization for search and retrieve applications.  As shown Figure 14.0 IPD Directory Structure our naming convention for the IPD system directories are IPD_Top-Level-Project-Name, hence: IPD_IoT-PLATFORM for this series project.  SS_xxx for the various SaveSet sub-directories identifying various related development categories, hence: SS_IPD for the core IPD sub-directory, then one more level sub-directories IPD_xxx for the specific category types of designs and documentation, hence: IPD_CPLD for the CPLD design sub-directory, IPD_FPGA for the FPGA sub-directory and so on for each category of development.

File names for the actual files within the design sub-directories are users defined since this main objective in the IPD naming convention is to organize the development process by directory level and leave the individual filename of the user that will have a better relationship to the users project, this allows easy navigation to though the IPD system by project.  One of the important features of writing software is the naming convention used, we will address programming naming conventions when we get into the software part of the series.  As we see product design is easily broken down into several categories and subcategory types which entails multiple disciplines to be successful.  The intent/goal of the IPD system is to allow the focus on design and development while intuitively documenting the process for traceability.   As we stated many times during this series that product development of any type requires a unique combination of documentation along with an intuitive mind-set for a successful product.

It would be interesting to hear from my readers how many have experienced difficulties of "Now Where Did I Put That File?"  The Internet encourages the download of PDF and other files to read at will.  So, speaking for myself only, I download the file and put it on our internal public drive to share.  You would be amazed how fast the drive gets filled with random files that have to be opened to figure out the contents.  When I was starting out I filled up hard drives real fast, over the years organization developed and today the structure I am presenting here is used to relate files to projects.  The experienced gained over the years as an entrepreneur developer will now be implemented in the new IPD System with the goal to help entrepreneur's and small businesses compete in product development and time to market.

Traceability Required Documents:
Today's product development requirements have changed over time from a couple of business and technical documents to many documents that have to deal with various rules and regulations in both consumer and industrial market arenas.  To name a few requirements documents, legal, business, and several technical documents to cover computer hardware, software and validation documentation to register compliancy.  There are special documents on security breach compliancy as well to adhere to the many regulations that the industry is plagued with.   Organizing these documents and being able to track the document requirements through the development process requires vigilant monitoring to insure all the requirements have been met and validated.  For our project the documents that we will be creating over this series are listed below.  The IPD System allows the registering of these documents with a unique Document Trace ID for tracking throughout the development process.  Figure 15.1 IPD System Required Documents Dialog allows the user to assign a unique Document ID for tracking each of the required documents for the project through the RTM (Requirements Traceability Matrix) relational database network as shown in Figure 15.2  IPD System Traceability Matrix Database Dialog below.


Figure 15.1 IPD System Required Documents Dialog

RTM (Requirements Traceability Matrix) Database:
Organized development documentation is only one issue being able to trace the development process bi-directional throughout the development cycle to correct any errors or make specification changes that arise during the process is totally an different issue.  There are so many snippets on the Internet about Requirements Traceability Matrix methodologies along with many do's and do not, one could make a career out of it, Oh!! wait, there is a career and certification on it already.  Figure 15.1 is the IPD Systems RTM documents dialog for traceability.

Top level Project Management where the entire project or program is managed at the 50,000 foot level, hence the main management level of all projects, however for both large and small companies the breakdown of the product development process is the same, the main difference between large and small company sizes is the amount of human resource availability.  The IPD System allows the entrepreneur and the small company to develop projects and organize the different aspects of projects development intuitively.  For the entrepreneur, the mind-set is always active and many ideas flow for projects to design, manufacturer etc., the IPD System allow the entrepreneur to organize multiple projects and add top them at will when the ideas flow and maintain the organizational requirements to clearly see the state of development of each project intuitively.

When the small company decides to outsource some of the development, the IPD system handles each outsource as a project base allowing control and security protecting the Intellectual Property of the full program.  The out sourced project when completed becomes a reuse module for the larger project and is introduce through the reuse section of the IPD System with all of its documentation intact for a true reuse module (If there really is such a thing as complete reuse!) either way it just becomes a component for the larger project.

Security is also designed in at the ground level.  Initially this was performed in a manual process, this was relatively easy since we just filed the documents in a physically secure location of course in a Top-Level_Directory identifying the project.  Automating the process using relational databases creates a new security issue which we have designed in for the ground floor on the IPD system.  Security access is controlled an assigned by several security access level ID's for the Server itself, the different project databases, Programs, Projects, Categories, Sub-Categories and Filenames.  This is controlled by the Access Level Management section and is accessed by assigned program managers for the project. This is for each project base development and is the bottom level of security access.  Top Level security access is controlled through a secure server by the Security Officer who assigns responsible manger for each project at the project level.  We will address this more as we get closer to the end of the project series and introduce both IoT Platform security protocols and IPD System protocols.  As stated our intent/goal is to present a solid product development platform that is intuitive and second nature for the control and organization for product development.

OK, I do realize that we just jumped right into designing without using the Required Documents except for the IoT Conceptual Document back in part 12 or any of the RTM databases for the design, however it was intentional.  The intention was due to the facts that we were making changes to the IPD Systems as we are developing the IoT Platform in order to insure we cover all the bases of development.   What better way than to interact with all the required rules and regulations during the design process for present day technology development to insure a true intuitive organizational methodology.

It is easier to understand when you have a device being developed to reference then doing all the paperwork first, and it is important that the development shows the flexibility of the intuitive process that the entrepreneur can update at any time to comply with the required documents.  Since we are only at the first peripheral design stage we will enter this RTM case for that section and publish the result for each DED (Deliverable Expectation Document) created and put in the Requirements sections.


Figure 15.2 IPD Traceability Matrix Database (RTM) Dialog

OK, Now that we understand the number of documents that are the top level of product development - we will create these as we proceed with the design and update them as the need exists to track the details of the development.  For entrepreneurs the top level idea is always the most exciting, it is the detailing to bring it to fruition that tends to slip on the documentation, so it is a good idea to have an intuitive system that will keep track as the ideas and details come into play during development, hence the IPD system.  We will be adding information to the top two dialogs, treating them as a living document system.  Lets get on with the design and address the questions that have been asked.

[Selection_Menu]            [Top_Menu]

Questions & Answers - Analog Input Design:

What was the criteria for selecting 16 bits?
Basically the selection is one of 35 years of designing data acquisitions and process control systems.  To shorten the answer and validate the suggestion look at the website page About->History to start.  A 16 bit 1 MHz Successive Approximation converter covers many of the general purpose applications for an analog input peripheral and falls in the balance of bit to performance ratio for the majority of analog input resolution.   This also give the opportunity to add different type of analog front end signal conditioning to allow windowing to increase the dynamic capture range which is part of the next question.

Why the 11 range gain setting and not the typical 1,10,100,1000 range like many other DAQ systems?
There are actually 22 ranges on the PGA281 which allows a wide range of inputs to accommodate various type of transducers and sensor devices to get the maximum dynamic range from the sensor.  The 22 voltage ranges are calculated from the max input range of the A/D which is bi-polar of +/-1.25000 volts DC.  Applying the ranges the table below shows the full scale A/D range for each gain range.  Table 15.0 below shows the full scale input range to the amplifiers gain range.

PGA 281 Gain Range (G4=0)

FS A/D  = ±1.250Vdc/Gain Range 0 Resolution 0 = (FS Range / 216)-1) PGA 281 Gain Range (G4=1) FS A/D  = ±1.250Vdc/Gain Range 1 Resolution 1 = (FS Range / 216)-1)
0.125 ±10.00 Vdc 152.592 x10-6 0.172 ±7.2674 Vdc 110.8951 x10-6
0.250 ±5.000Vdc 76. 2962x10-6 0.344 ±3.6337Vdc 55. 4475 x10-6
0.500 ±2.500 Vdc 38.1481 x10-6 0.688 ±1.8168 Vdc 27.7230 x10-6
1.000 ±1.250 Vdc 19.0741 x10-6 1.375 ±0.9090 Vdc 13.8706 x10-6
2.000 ±0.625 Vdc 9.53703 x10-6 2.75 ±0.4545 Vdc 6.93533 x10-6
4.000 ±0.3125 Vdc 4.76852 x10-6 5.5 ±0.2272 Vdc 3.46690 x10-6
8.000 ±0.15625 Vdc 2.38426 x10-6 11 ±0.1136 Vdc 1.73345 x10-6
16.00 ±0.078125 Vdc 1.19212 x10-6 22 ±0.056818 Vdc 0.67000 x10-6
32.00 ±0.0390625 Vdc 0.59606 x10-6 44 ±0.028409 Vdc 0.43350 x10-6
64.00 ±0.0195312 Vdc 298.032 x10-9 88 ±0.014204 Vdc 216.742 x10-9
128.0 ±0.0097656 Vdc 149.016 x10-9 176 ±0.0071022 Vdc 108.374 x10-9

Table 15.0  Analog Full Scale Input Range to Gain Ranges

OK, why so many ranges? When you look at the gain ranges 1, 10, 100, 1000 and usually follow the +/- 10.00 volts, 1.00 volt, 0.100 volt and 1.000 x10-3  volts full scale.  The few ranges limits the resolution of the sensor because of the large jump in ranges. Hence: for a 2 volt sensor the Gain of 1 must be used and that limits the full range of the analog input effective resolution to (2.0vdc ÷ 152.588 x10-6 ) = 13,107 bit counts out of 65535 bit counts effectively a 13 bit A/D.  By adding more gain ranges you get a closer match to the analog sensor point yielding a more accurate representation of the signal being measured.  The PGA281 has 22 different gain ranges (G0-G4) to handle many different sensor ranges.

The other reason we selected the PGA281 is for the full differential input capability up to ±15.0 Vdc as well as the large full scale common mode rejection ration.  This allows the use of additional signal conditioning to apply an offset to one side of the analog input.  This is easily used for monitoring noise on say a 5 volt line.  By adding a 5 volt signal to on side of the input you get to monitor the noise from a relative 0 volt input and use the gain to get full scale noise on a DC level.  We will be adding this capability to the analog input as the series moves forward.  The A/D converter that is used only has a 2.5Vdc full scale Range or ±1.25 Volts Bi-Polar which is what out ranges are based on.

What is the purpose of putting an A/D  2Megx16 buffer memory?
There are many useful purposes for the A/D buffer memory, the main reason is to free up the CPU for difficult periodic conversions.  Today's CPU's handle many tasks and collecting data with a timed periodic conversion rate becomes challenging.  Setting up a DMA memory area varies from hardware to hardware and is generally limited in size and the memory refresh rate.  A buffer allows data to be collected at a precision periodic rate using a controlled timer counter that is in the CPLD design.  An external trigger to start the data collection is generally part of the memory buffer features. A typical application is to collect data at a 1Meg Sample Rate for two seconds and perform an analysis on the captured data frame.

Why just a single A/D channel? Why not just put a multiplexor for many channels ?
The next session is to add other analog input features.  We have scheduled a multiplexor and a Analog Output control for applying a voltage offset to the analog input to capture smaller signals that ride on a DC voltage within the analog input range. Generally 8 channels differential and 16 channel single ended are the typical expectations of the industry.  We will also be adding programmable channel sequencing - Start Channel to Final Channel with various gain levels for each channel.

Why start with a CPLD and not use an FPGA from the start?
This question arise on a regular basis. The answer is it depends on the application.  Our initial intent for the Analog Input was to make it a Plug-N-Play module to be added to the application as required.  Designing that initially with a CPLD does not prevent us from making it part of an FPGA if the application calls for it.  The CPLD just makes it easier to make it a module and validate the PoD.

[Selection_Menu]            [Top_Menu]

There are still a few more sections for the Analog Input peripheral that has to be completed that we will cover in the next part of the series.  What we have been able to accomplish to date is a solid ground floor understanding of how the IoT devices are configured.   The selection of the Analog Input device is a good start to understand how peripherals are configured and controlled regardless of the type of BUS interface used to communicate with the host CPU.

Each part of this development series shows a little more the advantages of  an IPD system as we incorporate each stage of the IoT Platform development into the IPD system to organize and track the development stages. All functions neatly organized in the appropriate folder with a easy Click'N'Open to continue the development process.  

Thank you everyone for the encouragement and kind communications directly on this blog series.  I am available for consultation on this series or any other projects that you would like consultation or help with.   As the series progresses the author will be available for discussion for those that want to follow this series in detail and conduct their own experiments.  Contact me directly through the BASIL Networks Contact Form.  I will create a sub category for this series on unique questions and answers as not to be embedded by multiple post comments and hard to review.

Part 16 Preliminary Outline" A/D Channel Hardware/Software Design: -Continued

Reference Links for Part 15:

PGA281 Programmable gain Amplifier Datasheet

Intel®/Altera® Quartus Download 9.1 sp2 from Archives

Intel®/Altera® Quartus Lite 18.x Download

Requirements Traceability Matrix  (RTM)
Project Management
Mezzanine Board

The majority of Internet scheme and protocol information are from a few open public information sources on the net, IETF (Internet Engineering Task Force) RFC's that explain details on the application of the protocols used for both IPv4 and IPv6 as well as experimental protocols for the next generation Internet and the Network Sorcery web site.  The remaining of this series on the IoT platform will be from BASIL Networks MDM (Modular Design Methodology) applied with the Socratic teaching method.   Thank You - expand your horizon- Sal Tuzzo

Network Sorcery:
The Internet Engineering task Force: IETF - RFC references

Memory Segmentation
The Memory Management Unit (MMU)
Virtual Address Space
Virtual Addresses and Page Tables
Extended Memory

Part 14 IoT Core Platform - Peripheral I/O Development - Analog Input Peripheral Device Design (Oct 29, 2018)

Part 16 IoT Core Platform - Peripheral I/O Development - Peripheral Device Real World Testing (Feb 11, 2019)


Publishing this series on a website or reprinting is authorized by displaying the following, including the hyperlink to BASIL Networks, PLLC either at the beginning or end of each part.
BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-15 Peripheral I/O Design - Analog Input Peripheral Design - (Dec 7, 2018)

For Website Link cut and paste this code:

<p><a href="" target="_blank">BASIL Networks, PLLC - Internet of Things (IoT) -Security, Privacy, Safety-The Information Playground Part-15 Peripheral I/O Development:-<i>Analog Input Perpheral Device Design (Dec 7, &nbsp;2018)</i></a></p>



Sal (JT) Tuzzo - Founder CEO/CTO BASIL Networks, PLLC.
Sal may be contacted directly through this sites Contact Form or
through LinkedIn


Copyright© 1990-2019 BASIL Networks, PLLC. All rights reserved