Commonplace Thoughts

 RCTiming_capacitance_meter
April 02, 2016, cap_feather_apr02; modified for 12 Bit ADC, including threshold increasing
Zero Voltage threshold to prevent hanging waiting for full discharge.
Adafruit Feather M0 Basic Arduino Board
Uses MICROSecond timer, not MILLISecond timer for greater precision and to measure caps below
1 nF in value.
1) There is a noticable error (DC offset from ADC of around 14 of 4096 full scale
2) Settling to full discharge so a non-zero threshold is set, ~50 count
3) ADC conversion time is about .5 milliseconds, so this is subtracted from measurement
4) Added loop counter Mar 27, so see if ADC compensation is correct
5) Added input selection via digital inputs
Derived from program from Arduino site, from Paul Badger 2008 Uses of RC time constants to
measure the value of a capacitor.
TC = R * C – The capacitor’s voltage at one time constant is defined as 63.2% of the charging voltage.
6)  Changed to nF printout, and also added A9 as input for 10M Charging R

Hardware setup (verbal schematic):
Test Capacitor between common point and ground
Test Resistor between chargePin and common point
220 ohm resistor between dischargePin and common point
Wire between common point and analogPin (A/D input)

Software:  Cap_feather_apr02, Win 10 GA9 machine, in Arduino folder and in DB>project folder

Platform: Feather M0 Core from Adafruit.

Components:  Resistors

Schematic: See above

Layout: See photo

Notes:

MetaData: In lab notebook (3/15-4/02) and in DB>Projects, and in Project 3 Ring Binder.

In the post before last, the documentation of project was defined (see the list below).  What was not defined is where this should be stored, nor how.  Dropbox seems like the ubiquitous platform for doing all this, as it can easily capture and distribute the various files to different platforms.  Some additional thoughts about documentation:

Take a picture:  Cell phone cameras are ever available.  Take a picture of the project and upload it into the project folder.

Record where physically documented:   Describe the date and location of any project notes that are not captured in the digital documentation.

Create a consistent file naming convention:  For the project names and the source code at a minimum.  For example file name – Platform_Date; for a source file – Purpose_Platform_Date.  Keep all files in a folder “Projects” in Dropbox.

Document What Needs to be Done Next:  Yes, what improvements would you make going forwarded, what is undone?

Documentation List

Software:  Current source file, with name and date.  Have this displayed during wakeup of embedded device.  Location and computer should be listed.  The source code should be printed out.

Platform: The HW platform should be noted, including revision number, and special characteristics (like Arduino UNO SMD, Rev 3).  Where possible an image of the platform should be captured as a photograph.

Components:  Document a bill of components, noting source and version number or distinguishing type (often very important).  Include pinouts of components, and any important parameters.

Schematic: Draw the schematic in any form.  Acorn for the Mac works well and is cost effective, or capture freehand sketch and convert to PDF via CS Scanner.

Layout: Capture the physical design and arrangement of the components.

Notes: Describe any additional documentation that might be helpful including reference web sites, notes about operation, changes required/warnings/guidelines.

MetaData: Finally, this file should be easy to find.  It should be printed out, indexed/filed in a convenient place, and put away.  There should be a pointer from the physical device to the documentation.

Documenting a project is the goal of design, not an artifact… not a struggle to complete during the project and regretfully past the last design review and after it is shipping.  Documentation is the design.  It is the result.  It is the artifact.

Although many fret with this activity and postpone it to the end, or denigrate it to the last priority it should be the first.  This is where knowledge and advancement is embodied – NOT in the minds of the creator.  Let me be very clear on this point.  The documentation is the goal.

Now when we consider a hobby project, or a project of an individual researcher or inventor, what is sufficiency as there are different standards depending on the type of company and the scale of deployment.

There are classifications of the components of a design that can be helpful in this discussion.  For example, how can we decompose a design?  Over functions? Over Times? Over Stages? Over levels of complexity/systems? Separate HW from HW.

This can only be answered by the answer to this deeper question.  What is the lasting benefit of documentation?  For individual experimentialist projects, which is the category I inhabit, this is very useful – skillful even.

For us, at this point in time (salaried man, with 4 hours a week of time available to experimentation) the primary benefit of documentation is the ability to immediately pick up what I was dong last, and resume from exactly the same place, but this time rested and armed with a set of ideas on how to confront the challenge ahead.

This kind of documentation is SO much more useful because you only document what you will find immediate utility as opposed to patents, where your goal is to map out an entire universe where this new idea si not only prohibited,but morally bad for you.

Immediate Utility:

1.  Can I resume where I left off when I shut off the power yesterday (or when I was experimenting last)?

2.  Will the system behaved the same way as it did when I last encountered it?  This is VERY important.  We should be able to document a system so that when we return or repeat the initial conditions, we get exactly the same output!

Software:  Current source file, with name and date.  Have this displayed during wakeup of embedded device.  Location and computer should be listed.  The source code should be printed out.

Platform: The HW platform should be noted, including revision number, and special characteristics (like Arduino UNO SMD, Rev 3).  Where possible an image of the platform should be captured as a photograph.

Components:  Document a bill of components, noting source and version number or distinguishing type (often very important).  Include pinouts of components, and any important parameters.

Schematic: Draw the schematic in any form.

Layout: Capture the physical design and arrangement of the components.

Notes: Describe any additional documentation that might be helpful including reference web sites, notes about operation, changes required/warnings/guidelines.

MetaData: Finally, this file should be easy to find.  It should be printed out, indexed/filed in a convenient place, and put away.  There should be a pointer from the physical device to the documentation.