update

Attiny_Solar_Energy_Harvest/docs/44.aux

@@ -2,7 +2,7 @@
 \@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}}
@@ -34,4 +34,6 @@
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Further Notes}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Max Transmit Speed}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{18}}

Attiny_Solar_Energy_Harvest/docs/44.log

@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  28 AUG 2020 01:30
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  6 SEP 2020 00:35
 entering extended mode
  restricted \write18 enabled.
  %&-line parsing enabled.
@@ -259,11 +259,12 @@ Underfull \hbox (badness 10000) in paragraph at lines 34--37
 
  []
 
+[2]
 LaTeX Font Info:    External font `cmex10' loaded for size
 (Font)              <9> on input line 41.
 LaTeX Font Info:    External font `cmex10' loaded for size
 (Font)              <5> on input line 41.
-[2] [3] [4] [5]
+ [3] [4] [5] [6]
 Underfull \hbox (badness 10000) in paragraph at lines 164--181
 
  []
@@ -288,7 +289,7 @@ Underfull \hbox (badness 10000) in paragraph at lines 164--181
 
  []
 
-[6]
+
 Underfull \hbox (badness 10000) in paragraph at lines 184--201
 
  []
@@ -419,36 +420,36 @@ ain+0x20>[]
  []
 
 [17]
-Overfull \hbox (3.92412pt too wide) in paragraph at lines 466--467
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 480--481
 \OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
 ces-
  []
 
 
-Overfull \hbox (2.00143pt too wide) in paragraph at lines 468--469
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 482--483
 []\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
 5
  []
 
 
-Overfull \hbox (29.1366pt too wide) in paragraph at lines 470--471
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 484--485
 []\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
 comms-
  []
 
 
-Overfull \hbox (9.33832pt too wide) in paragraph at lines 470--471
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 484--485
 \OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
  project. 
  []
 
 
-Overfull \hbox (3.34335pt too wide) in paragraph at lines 474--475
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 488--489
 []\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
 pa/ -
  []
 
-[18] (./44.aux) ) 
+[18] [19] (./44.aux) ) 
 Here is how much of TeX's memory you used:
  3541 strings out of 494945
  53807 string characters out of 6181032
@@ -457,18 +458,18 @@ Here is how much of TeX's memory you used:
  8977 words of font info for 32 fonts, out of 8000000 for 9000
  14 hyphenation exceptions out of 8191
  39i,8n,39p,877b,250s stack positions out of 5000i,500n,10000p,200000b,80000s
-</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
-cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
-.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></
-usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/shar
-e/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texliv
-e/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-
-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/f
-onts/type1/public/amsfonts/cm/cmtt10.pfb>
-Output written on 44.pdf (18 pages, 178243 bytes).
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfont
+s/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/c
+mbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.p
+fb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr
+/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/t
+exlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/t
+exmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-d
+ist/fonts/type1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 44.pdf (19 pages, 181094 bytes).
 PDF statistics:
- 95 PDF objects out of 1000 (max. 8388607)
- 65 compressed objects within 1 object stream
+ 99 PDF objects out of 1000 (max. 8388607)
+ 68 compressed objects within 1 object stream
  0 named destinations out of 1000 (max. 500000)
  6 words of extra memory for PDF output out of 10000 (max. 10000000)
 

Attiny_Solar_Energy_Harvest/docs/44.tex

@@ -460,6 +460,20 @@ back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
 on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
 
 
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench).
+
+433MHz\_6: Adding in sleep code to get lower power use.
+
+\subsubsection{433MHz Max Transmit Speed}
+2KHz was OK. Beyond that, the RX signal goes out of phase. 5KHz is unusable. Tested with sig gen.
 
 
 \subsection{Further Notes}

Attiny_Solar_Energy_Harvest/docs/44.toc

@@ -1,7 +1,7 @@
 \contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
 \contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
 \contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
-\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
 \contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
 \contentsline {subsection}{\numberline {1.2}Programming}{3}
 \contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}
@@ -32,4 +32,6 @@
 \contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}
 \contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}
 \contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}
-\contentsline {subsection}{\numberline {1.7}Further Notes}{18}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Max Transmit Speed}{18}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{18}

Attiny_Solar_Energy_Harvest/docs/45.aux

@@ -0,0 +1,40 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces simple rx tx on 433mhz\relax }}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces With a delay, there is no ramping up.\relax }}{19}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Max Transmit Speed}{20}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{20}}

Attiny_Solar_Energy_Harvest/docs/45.log

@@ -0,0 +1,486 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:06
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/45.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/45.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./45.aux)
+\openout1 = `45.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./45.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `45.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2]
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 41.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 41.
+ [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+[7] [8]
+Overfull \hbox (2319.18137pt too wide) in paragraph at lines 252--252
+[]\OT1/cmtt/m/n/10.95 9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the 
+lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputd
+riveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpu
+llupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan 
+be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the v
+oltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayo
+fsensors 
+ []
+
+[9] [10]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 301--302
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+[11]
+Overfull \hbox (206.16063pt too wide) in paragraph at lines 307--308
+[]\OT1/cmr/m/n/10.95 I searched for LoRa mod-ules, and came across this https:/
+/www.disk91.com/2015/technology/networks/first-
+ []
+
+[12] [13]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 378--378
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+[14] <../pics/rxtx_433.jpg, id=55, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+
+<use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 390.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+ [15 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 405--408
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 405--408
+
+ []
+
+
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+[16]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 457--457
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+[17] <../pics/DSCN0200.JPG, id=65, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 467.
+(pdftex.def)             Requested size: 501.87378pt x 376.40532pt.
+
+Overfull \hbox (176.65878pt too wide) in paragraph at lines 467--468
+ [] 
+ []
+
+[18] [19 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 490--491
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 492--493
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 494--495
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 494--495
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 498--499
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[20] (./45.aux) ) 
+Here is how much of TeX's memory you used:
+ 3547 strings out of 494945
+ 53922 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6816 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,877b,291s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></
+usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/shar
+e/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texliv
+e/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-
+dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 45.pdf (20 pages, 326504 bytes).
+PDF statistics:
+ 103 PDF objects out of 1000 (max. 8388607)
+ 70 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 11 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/45.tex

@@ -0,0 +1,501 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I will 
+want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, 
+so no need to test much, yet.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop.}, and was able to Read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and
+likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout.
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I also learned that the cable I was using to program the attiny10 was giving me much trouble. I ended up soldering one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed.
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.5]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a delay, there is no ramping up.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Max Transmit Speed}
+2KHz was OK. Beyond that, the RX signal goes out of phase. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/45.tex~

@@ -0,0 +1,496 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I will 
+want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, 
+so no need to test much, yet.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop.}, and was able to Read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and
+likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout.
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I also learned that the cable I was using to program the attiny10 was giving me much trouble. I ended up soldering one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed.
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Max Transmit Speed}
+2KHz was OK. Beyond that, the RX signal goes out of phase. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/45.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}
+\contentsline {subsection}{\numberline {1.4}PCB}{10}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Max Transmit Speed}{20}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{20}

Attiny_Solar_Energy_Harvest/docs/46.aux

@@ -0,0 +1,40 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces simple rx tx on 433mhz\relax }}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{18}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{19}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{19}}

Attiny_Solar_Energy_Harvest/docs/46.log

@@ -0,0 +1,481 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:12
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/46.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/46.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./46.aux)
+\openout1 = `46.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./46.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `46.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2]
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 41.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 41.
+ [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 164--181
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 184--201
+
+ []
+
+[7] [8]
+Overfull \hbox (2319.18137pt too wide) in paragraph at lines 252--252
+[]\OT1/cmtt/m/n/10.95 9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the 
+lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputd
+riveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpu
+llupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan 
+be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the v
+oltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayo
+fsensors 
+ []
+
+[9] [10]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 301--302
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+[11]
+Overfull \hbox (206.16063pt too wide) in paragraph at lines 307--308
+[]\OT1/cmr/m/n/10.95 I searched for LoRa mod-ules, and came across this https:/
+/www.disk91.com/2015/technology/networks/first-
+ []
+
+[12] [13]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 378--378
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+[14] <../pics/rxtx_433.jpg, id=55, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+
+<use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 390.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+ [15 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 405--408
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 405--408
+
+ []
+
+
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+[16]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 457--457
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 457--457
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+[17] <../pics/DSCN0200.JPG, id=65, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 467.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [18 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 490--491
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 492--493
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 494--495
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 494--495
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 498--499
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[19] (./46.aux) ) 
+Here is how much of TeX's memory you used:
+ 3547 strings out of 494945
+ 53922 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6816 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,877b,250s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></
+usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/shar
+e/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texliv
+e/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-
+dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 46.pdf (19 pages, 326784 bytes).
+PDF statistics:
+ 100 PDF objects out of 1000 (max. 8388607)
+ 68 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 11 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/46.tex

@@ -0,0 +1,501 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I will 
+want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, 
+so no need to test much, yet.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop.}, and was able to Read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and
+likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout.
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I ended up soldering one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed.
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/46.tex~

@@ -0,0 +1,501 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I will 
+want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, 
+so no need to test much, yet.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop.}, and was able to Read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and
+likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout.
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I also learned that the cable I was using to program the attiny10 was giving me much trouble. I ended up soldering one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed.
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.5]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a delay, there is no ramping up.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Max Transmit Speed}
+2KHz was OK. Beyond that, the RX signal goes out of phase. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/46.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{3}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}
+\contentsline {subsection}{\numberline {1.4}PCB}{10}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{19}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{19}

Attiny_Solar_Energy_Harvest/docs/47.aux

@@ -0,0 +1,40 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces simple rx tx on 433mhz\relax }}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{16}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{18}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{19}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{19}}

Attiny_Solar_Energy_Harvest/docs/47.log

@@ -0,0 +1,480 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:21
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/47.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/47.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./47.aux)
+\openout1 = `47.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./47.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `47.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2] [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 161--178
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 161--178
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 161--178
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 161--178
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 161--178
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 181--198
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 181--198
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 181--198
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 181--198
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 181--198
+
+ []
+
+[7] [8]
+Overfull \hbox (2319.18137pt too wide) in paragraph at lines 249--249
+[]\OT1/cmtt/m/n/10.95 9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the 
+lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputd
+riveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpu
+llupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan 
+be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the v
+oltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayo
+fsensors 
+ []
+
+[9] [10] [11]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 298--299
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+
+Overfull \hbox (206.16063pt too wide) in paragraph at lines 304--305
+[]\OT1/cmr/m/n/10.95 I searched for LoRa mod-ules, and came across this https:/
+/www.disk91.com/2015/technology/networks/first-
+ []
+
+[12] [13] [14]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 375--375
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+<../pics/rxtx_433.jpg, id=55, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+ <use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 387.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+[15 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 402--405
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 402--405
+
+ []
+
+[16]
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 454--454
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+[17]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 454--454
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+<../pics/DSCN0200.JPG, id=65, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 464.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [18 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 487--488
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 489--490
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 491--492
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 491--492
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 495--496
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[19] [20] (./47.aux) ) 
+Here is how much of TeX's memory you used:
+ 3547 strings out of 494945
+ 53922 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6816 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,249s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfont
+s/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/c
+mbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.p
+fb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr
+/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/t
+exlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/t
+exmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-d
+ist/fonts/type1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 47.pdf (20 pages, 328246 bytes).
+PDF statistics:
+ 103 PDF objects out of 1000 (max. 8388607)
+ 70 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 11 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/47.tex

@@ -0,0 +1,498 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/47.tex~

@@ -0,0 +1,501 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I will 
+want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, 
+so no need to test much, yet.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop.}, and was able to Read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and
+likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout.
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz IO Switch
+128KHz CLK: 2.5KHz IO Switch
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/47.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{8}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{9}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{9}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{10}
+\contentsline {subsection}{\numberline {1.4}PCB}{10}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{11}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{11}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{11}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{12}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{12}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{13}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{13}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{13}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{14}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{15}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{15}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{16}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{16}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{17}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{18}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{19}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{19}

Attiny_Solar_Energy_Harvest/docs/48.aux

@@ -0,0 +1,40 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{1}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{5}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{5}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{9}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{14}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces simple rx tx on 433mhz\relax }}{14}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{17}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{18}}

Attiny_Solar_Energy_Harvest/docs/48.log

@@ -0,0 +1,488 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:28
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/48.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/48.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./48.aux)
+\openout1 = `48.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./48.toc)
+\tf@toc=\write3
+\openout3 = `48.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
+[2] [3] [4] [5]
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+[6]
+LaTeX Font Info:    Try loading font information for OML+cmr on input line 208.
+
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omlcmr.fd
+File: omlcmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OML/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OML/cmm/m/it' tried instead on input line 208.
+ [7]
+Overfull \hbox (2319.18137pt too wide) in paragraph at lines 250--250
+[]\OT1/cmtt/m/n/10.95 9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the 
+lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputd
+riveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpu
+llupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan 
+be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the v
+oltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayo
+fsensors 
+ []
+
+[8] [9] [10]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 299--300
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+
+Overfull \hbox (206.16063pt too wide) in paragraph at lines 305--306
+[]\OT1/cmr/m/n/10.95 I searched for LoRa mod-ules, and came across this https:/
+/www.disk91.com/2015/technology/networks/first-
+ []
+
+[11] [12] [13]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 376--376
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+<../pics/rxtx_433.jpg, id=53, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+ <use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 388.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+[14 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 403--406
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 403--406
+
+ []
+
+[15]
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 455--455
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+[16]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 455--455
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+<../pics/DSCN0200.JPG, id=63, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 465.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [17 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 488--489
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 490--491
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 492--493
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 492--493
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 496--497
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[18] [19] (./48.aux) ) 
+Here is how much of TeX's memory you used:
+ 3563 strings out of 494945
+ 54199 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6829 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,250s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfont
+s/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/c
+mbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.
+pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></u
+sr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share
+/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive
+/texmf-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-d
+ist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fo
+nts/type1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 48.pdf (19 pages, 334740 bytes).
+PDF statistics:
+ 104 PDF objects out of 1000 (max. 8388607)
+ 71 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 11 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/48.tex

@@ -0,0 +1,499 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/48.tex~

@@ -0,0 +1,498 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board.
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (<1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/48.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{1}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{1}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{1}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{1}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{2}
+\contentsline {subsection}{\numberline {1.2}Programming}{2}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{2}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{5}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{5}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{6}
+\contentsline {subsection}{\numberline {1.3}Application}{6}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{7}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{7}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{8}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{8}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{8}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{8}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{9}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{9}
+\contentsline {subsection}{\numberline {1.4}PCB}{9}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{10}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{10}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{10}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{11}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{11}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{12}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{12}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{12}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{13}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{14}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{14}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer}{15}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{15}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{16}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{17}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{18}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{18}

Attiny_Solar_Energy_Harvest/docs/49.aux

@@ -0,0 +1,41 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.\relax }}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{16}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces simple rx tx on 433mhz\relax }}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{19}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{20}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{21}}

Attiny_Solar_Energy_Harvest/docs/49.log

@@ -0,0 +1,518 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:44
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/49.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/49.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./49.aux)
+\openout1 = `49.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./49.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `49.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2] [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+[7]
+LaTeX Font Info:    Try loading font information for OML+cmr on input line 208.
+
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omlcmr.fd
+File: omlcmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OML/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OML/cmm/m/it' tried instead on input line 208.
+ [8]
+<../pics/adxl_pinout.png, id=37, 195.73125pt x 190.46156pt>
+File: ../pics/adxl_pinout.png Graphic file (type png)
+
+<use ../pics/adxl_pinout.png>
+Package pdftex.def Info: ../pics/adxl_pinout.png used on input line 230.
+(pdftex.def)             Requested size: 195.73076pt x 190.46107pt.
+ [9 <../pics/adxl_pinout.png (PNG copy)>]
+Overfull \hbox (25.45496pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 The push-pulloutputallowsfor the lowestsystempowerconsump
+tion[] 
+ []
+
+
+Overfull \hbox (31.20364pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 becausethereis no currentleakagepathwhenthe outputdrivesh
+ighor[] 
+ []
+
+
+Overfull \hbox (2.4602pt too wide) in paragraph at lines 264--264
+[] \OT1/cmtt/m/n/10.95 low. The open-drainoutputinvolvesa leakagepaththroughthe
+[] 
+ []
+
+[10] [11] [12]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 313--314
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 319--321
+
+ []
+
+
+Overfull \hbox (8.17953pt too wide) in paragraph at lines 322--324
+[]\OT1/cmr/m/n/10.95 https://www.disk91.com/2015/technology/ networks/first-ste
+p-in-
+ []
+
+[13] [14] [15]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 394--394
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+[16] <../pics/rxtx_433.jpg, id=63, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+
+<use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 406.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+Underfull \hbox (badness 10000) in paragraph at lines 411--413
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 415--417
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 422--425
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 422--425
+
+ []
+
+[17 <../pics/rxtx_433.jpg>]
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 474--474
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+[18]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+<../pics/DSCN0200.JPG, id=70, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 484.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [19] [20 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 507--508
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 509--510
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 511--512
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 511--512
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 515--516
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[21] (./49.aux) ) 
+Here is how much of TeX's memory you used:
+ 3569 strings out of 494945
+ 54329 string characters out of 6181032
+ 122046 words of memory out of 5000000
+ 6833 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,265s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb><
+/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
+are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share/texl
+ive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texm
+f-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 49.pdf (21 pages, 357179 bytes).
+PDF statistics:
+ 111 PDF objects out of 1000 (max. 8388607)
+ 75 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 16 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/49.tex

@@ -0,0 +1,518 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/49.tex~

@@ -0,0 +1,502 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\includegraphics[scale=0.5]{../pics/adxl_pinout.png}
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying this:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}9.1.1OutputTypeTradeoffsThe push-pulloutputallowsfor the lowestsystempowerconsumptionbecausethereis no currentleakagepathwhenthe outputdriveshighor low. The open-drainoutputinvolvesa leakagepaththroughthe externalpullupresistorwhenthe outputdriveslow.The open-drainoutputsof multipledevicescan be tied togetherto forma logicalAND.In this setup,if any sensordriveslow, the voltageon the sharednodebecomeslow. Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests today.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this https://www.disk91.com/2015/technology/networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer}
+These notes may be redundant, need to double check.
+
+When connecting, have a base setup that works as a sanity check.
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/49.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}
+\contentsline {subsection}{\numberline {1.4}PCB}{11}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{16}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{17}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{19}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{21}

Attiny_Solar_Energy_Harvest/docs/50.aux

@@ -0,0 +1,41 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.\relax }}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{16}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces simple rx tx on 433mhz\relax }}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{19}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{20}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{21}}

Attiny_Solar_Energy_Harvest/docs/50.log

@@ -0,0 +1,518 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:45
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/50.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/50.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./50.aux)
+\openout1 = `50.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./50.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `50.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2] [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+[7]
+LaTeX Font Info:    Try loading font information for OML+cmr on input line 208.
+
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omlcmr.fd
+File: omlcmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OML/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OML/cmm/m/it' tried instead on input line 208.
+ [8]
+<../pics/adxl_pinout.png, id=37, 195.73125pt x 190.46156pt>
+File: ../pics/adxl_pinout.png Graphic file (type png)
+
+<use ../pics/adxl_pinout.png>
+Package pdftex.def Info: ../pics/adxl_pinout.png used on input line 230.
+(pdftex.def)             Requested size: 195.73076pt x 190.46107pt.
+ [9 <../pics/adxl_pinout.png (PNG copy)>]
+Overfull \hbox (25.45496pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 The push-pulloutputallowsfor the lowestsystempowerconsump
+tion[] 
+ []
+
+
+Overfull \hbox (31.20364pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 becausethereis no currentleakagepathwhenthe outputdrivesh
+ighor[] 
+ []
+
+
+Overfull \hbox (2.4602pt too wide) in paragraph at lines 264--264
+[] \OT1/cmtt/m/n/10.95 low. The open-drainoutputinvolvesa leakagepaththroughthe
+[] 
+ []
+
+[10] [11] [12]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 313--314
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 319--321
+
+ []
+
+
+Overfull \hbox (8.17953pt too wide) in paragraph at lines 322--324
+[]\OT1/cmr/m/n/10.95 https://www.disk91.com/2015/technology/ networks/first-ste
+p-in-
+ []
+
+[13] [14] [15]
+Overfull \hbox (14.6069pt too wide) in paragraph at lines 394--394
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble Hooku
+p 
+ []
+
+[16] <../pics/rxtx_433.jpg, id=63, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+
+<use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 406.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+Underfull \hbox (badness 10000) in paragraph at lines 411--413
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 415--417
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 422--425
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 422--425
+
+ []
+
+[17 <../pics/rxtx_433.jpg>]
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 474--474
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+[18]
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 474--474
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+<../pics/DSCN0200.JPG, id=70, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 484.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [19] [20 <../pics/DSCN0200.JPG>]
+Overfull \hbox (3.92412pt too wide) in paragraph at lines 507--508
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-devi
+ces-
+ []
+
+
+Overfull \hbox (2.00143pt too wide) in paragraph at lines 509--510
+[]\OT1/cmr/m/n/10.95 leonerd TODO LINK HERE (book-marks in main mach) at-tiny81
+5
+ []
+
+
+Overfull \hbox (29.1366pt too wide) in paragraph at lines 511--512
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+comms-
+ []
+
+
+Overfull \hbox (9.33832pt too wide) in paragraph at lines 511--512
+\OT1/cmr/m/n/10.95 simple/msg3016400/#msg3016400 - Fo-rum post re-gard-ing this
+ project. 
+ []
+
+
+Overfull \hbox (3.34335pt too wide) in paragraph at lines 515--516
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[21] (./50.aux) ) 
+Here is how much of TeX's memory you used:
+ 3569 strings out of 494945
+ 54329 string characters out of 6181032
+ 122046 words of memory out of 5000000
+ 6833 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,265s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb><
+/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
+are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share/texl
+ive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texm
+f-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 50.pdf (21 pages, 357182 bytes).
+PDF statistics:
+ 111 PDF objects out of 1000 (max. 8388607)
+ 75 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 16 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/50.tex

@@ -0,0 +1,518 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/50.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}
+\contentsline {subsection}{\numberline {1.4}PCB}{11}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{16}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{17}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{19}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{21}

Attiny_Solar_Energy_Harvest/docs/51.aux

@@ -0,0 +1,42 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.\relax }}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Testing the RF Transmitter w/ PCB Rev 4\relax }}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{17}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces simple rx tx on 433mhz\relax }}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{18}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{20}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{20}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{21}}

Attiny_Solar_Energy_Harvest/docs/51.log

@@ -0,0 +1,521 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:48
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/51.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/51.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./51.aux)
+\openout1 = `51.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./51.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `51.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2] [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+[7]
+LaTeX Font Info:    Try loading font information for OML+cmr on input line 208.
+
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omlcmr.fd
+File: omlcmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OML/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OML/cmm/m/it' tried instead on input line 208.
+ [8]
+<../pics/adxl_pinout.png, id=37, 195.73125pt x 190.46156pt>
+File: ../pics/adxl_pinout.png Graphic file (type png)
+
+<use ../pics/adxl_pinout.png>
+Package pdftex.def Info: ../pics/adxl_pinout.png used on input line 230.
+(pdftex.def)             Requested size: 195.73076pt x 190.46107pt.
+ [9 <../pics/adxl_pinout.png (PNG copy)>]
+Overfull \hbox (25.45496pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 The push-pulloutputallowsfor the lowestsystempowerconsump
+tion[] 
+ []
+
+
+Overfull \hbox (31.20364pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 becausethereis no currentleakagepathwhenthe outputdrivesh
+ighor[] 
+ []
+
+
+Overfull \hbox (2.4602pt too wide) in paragraph at lines 264--264
+[] \OT1/cmtt/m/n/10.95 low. The open-drainoutputinvolvesa leakagepaththroughthe
+[] 
+ []
+
+[10] [11] [12]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 313--314
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 319--321
+
+ []
+
+
+Overfull \hbox (8.17953pt too wide) in paragraph at lines 322--324
+[]\OT1/cmr/m/n/10.95 https://www.disk91.com/2015/technology/ networks/first-ste
+p-in-
+ []
+
+[13] [14] <../pics/DSCN0132.JPG, id=57, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0132.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0132.JPG>
+Package pdftex.def Info: ../pics/DSCN0132.JPG used on input line 385.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+
+
+Package caption Warning: \captionsetup{type*=...} or \captionof
+(caption)                outside box or environment on input line 386.
+See the caption package documentation for explanation.
+
+[15]
+Underfull \hbox (badness 1292) in paragraph at lines 396--396
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble
+ []
+
+[16 <../pics/DSCN0132.JPG>]
+<../pics/rxtx_433.jpg, id=64, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+ <use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 408.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+Underfull \hbox (badness 10000) in paragraph at lines 413--415
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 417--419
+
+ []
+
+[17 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 424--427
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 424--427
+
+ []
+
+
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+[18]
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 476--476
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 476--476
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+[19] <../pics/DSCN0200.JPG, id=75, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 486.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [20 <../pics/DSCN0200.JPG>]
+Underfull \hbox (badness 10000) in paragraph at lines 509--510
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-
+ []
+
+
+Underfull \hbox (badness 6236) in paragraph at lines 509--510
+\OT1/cmr/m/n/10.95 devices-via-gpio-pins/msg2720044/#msg2720044 - Us-ing GPIO
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 513--514
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 517--518
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[21] (./51.aux) ) 
+Here is how much of TeX's memory you used:
+ 3574 strings out of 494945
+ 54440 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6837 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,249s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb><
+/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
+are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share/texl
+ive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texm
+f-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 51.pdf (21 pages, 597644 bytes).
+PDF statistics:
+ 112 PDF objects out of 1000 (max. 8388607)
+ 75 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 21 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/51.tex

@@ -0,0 +1,520 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+\includegraphics[scale=0.30]{../pics/DSCN0132.JPG}
+\captionof{figure}{Testing the RF Transmitter w/ PCB Rev 4}
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/51.tex~

@@ -0,0 +1,520 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+\includegraphics[scale=0.5]{../pics/DSCN0132.JPG}
+\captionof{figure}{Testing the RF Transmitter w/ PCB Rev 4}
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/51.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}
+\contentsline {subsection}{\numberline {1.4}PCB}{11}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{12}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{12}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{13}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{14}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{14}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{16}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{16}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{17}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{17}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{18}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{18}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{20}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{21}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{21}

Attiny_Solar_Energy_Harvest/docs/52.aux

@@ -0,0 +1,43 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Programming}{3}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Application}{7}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.\relax }}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces The silk screen pinout and instructions help.\relax }}{12}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.4}PCB}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{15}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces RF Transmitter w/ PCB Rev 4\relax }}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{17}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{18}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces simple rx tx on 433mhz\relax }}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{19}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{19}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{21}}
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.\relax }}{21}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{22}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {1.8}Further Notes}{22}}

Attiny_Solar_Energy_Harvest/docs/52.log

@@ -0,0 +1,527 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) (preloaded format=pdflatex 2019.8.17)  14 SEP 2020 14:53
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/
+Attiny_Solar_Energy_Harvest/docs/52.tex
+
+(/home/layoutdev/Desktop/code/documentation_general/Electronics_Projects_2020/A
+ttiny_Solar_Energy_Harvest/docs/52.tex
+LaTeX2e <2017/01/01> patch level 3
+Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+File: size11.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks14
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/10/09 v1.0u Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 99.
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2017/01/12 v0.06k Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2016/05/16 v1.4 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2016/05/16 v1.23 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count87
+))
+\Gin@req@height=\dimen103
+\Gin@req@width=\dimen104
+)
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
+Package: caption 2016/02/21 v3.3-144 Customizing captions (AR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
+Package: caption3 2016/05/22 v1.7-166 caption3 kernel (AR)
+Package caption3 Info: TeX engine: e-TeX on input line 67.
+\captionmargin=\dimen105
+\captionmargin@=\dimen106
+\captionwidth=\dimen107
+\caption@tempdima=\dimen108
+\caption@indent=\dimen109
+\caption@parindent=\dimen110
+\caption@hangindent=\dimen111
+)
+\c@ContinuedFloat=\count88
+)
+(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+Package: xcolor 2016/05/11 v2.12 LaTeX color extensions (UK)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+File: color.cfg 2016/01/02 v1.6 sample color configuration
+)
+Package xcolor Info: Driver file: pdftex.def on input line 225.
+Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1348.
+Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1352.
+Package xcolor Info: Model `RGB' extended on input line 1364.
+Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1366.
+Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1367.
+Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1368.
+Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1369.
+Package xcolor Info: Model `Gray' substituted by `gray' on input line 1370.
+Package xcolor Info: Model `wave' substituted by `hsb' on input line 1371.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+Package: geometry 2010/09/12 v5.6 Page Geometry
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2016/05/14 v3.1 Provides the ifpdf switch
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifvtex.sty
+Package: ifvtex 2016/05/16 v1.6 Detect VTeX and its facilities (HO)
+Package ifvtex Info: VTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty
+Package: ifxetex 2010/09/12 v0.6 Provides ifxetex conditional
+)
+\Gm@cnth=\count89
+\Gm@cntv=\count90
+\c@Gm@tempcnt=\count91
+\Gm@bindingoffset=\dimen112
+\Gm@wd@mp=\dimen113
+\Gm@odd@mp=\dimen114
+\Gm@even@mp=\dimen115
+\Gm@layoutwidth=\dimen116
+\Gm@layoutheight=\dimen117
+\Gm@layouthoffset=\dimen118
+\Gm@layoutvoffset=\dimen119
+\Gm@dimlist=\toks15
+) (./52.aux)
+\openout1 = `52.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen120
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks16
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen121
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks17
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2016/05/21 v0.22 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2016/05/15 v2.6 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2016/05/16 v1.2 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2016/05/16 v1.4 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2016/05/16 v3.12 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2016/05/16 v1.17 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+38.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 456.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+Package caption Info: Begin \AtBeginDocument code.
+Package caption Info: End \AtBeginDocument code.
+
+*geometry* detected driver: dvips
+*geometry* verbose mode - [ preamble ] result:
+* driver: dvips
+* paper: custom
+* layout: <same size as paper>
+* layoutoffset:(h,v)=(0.0pt,0.0pt)
+* vratio: 1:1
+* modes: 
+* h-part:(L,W,R)=(54.2025pt, 325.215pt, 54.2025pt)
+* v-part:(T,H,B)=(79.49689pt, 491.43622pt, 79.49689pt)
+* \paperwidth=433.62pt
+* \paperheight=650.43pt
+* \textwidth=325.215pt
+* \textheight=491.43622pt
+* \oddsidemargin=-18.06749pt
+* \evensidemargin=-18.06749pt
+* \topmargin=-29.7731pt
+* \headheight=12.0pt
+* \headsep=25.0pt
+* \topskip=11.0pt
+* \footskip=30.0pt
+* \marginparwidth=59.0pt
+* \marginparsep=10.0pt
+* \columnsep=10.0pt
+* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
+* \hoffset=0.0pt
+* \voffset=0.0pt
+* \mag=1000
+* \@twocolumnfalse
+* \@twosidefalse
+* \@mparswitchfalse
+* \@reversemarginfalse
+* (1in=72.27pt=25.4mm, 1cm=28.453pt)
+
+(./52.toc
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <10.95> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 2.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 2.
+ [1
+Non-PDF special ignored!
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}])
+\tf@toc=\write3
+\openout3 = `52.toc'.
+
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 22.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 22.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9> on input line 28.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 28.
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 34--37
+
+ []
+
+[2] [3] [4] [5] [6]
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 162--179
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 182--199
+
+ []
+
+[7]
+LaTeX Font Info:    Try loading font information for OML+cmr on input line 208.
+
+ (/usr/share/texlive/texmf-dist/tex/latex/base/omlcmr.fd
+File: omlcmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OML/cmr/m/n' in size <10.95> not available
+(Font)              Font shape `OML/cmm/m/it' tried instead on input line 208.
+ [8]
+<../pics/adxl_pinout.png, id=37, 195.73125pt x 190.46156pt>
+File: ../pics/adxl_pinout.png Graphic file (type png)
+
+<use ../pics/adxl_pinout.png>
+Package pdftex.def Info: ../pics/adxl_pinout.png used on input line 230.
+(pdftex.def)             Requested size: 195.73076pt x 190.46107pt.
+ [9 <../pics/adxl_pinout.png (PNG copy)>]
+Overfull \hbox (25.45496pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 The push-pulloutputallowsfor the lowestsystempowerconsump
+tion[] 
+ []
+
+
+Overfull \hbox (31.20364pt too wide) in paragraph at lines 264--264
+[]\OT1/cmtt/m/n/10.95 becausethereis no currentleakagepathwhenthe outputdrivesh
+ighor[] 
+ []
+
+
+Overfull \hbox (2.4602pt too wide) in paragraph at lines 264--264
+[] \OT1/cmtt/m/n/10.95 low. The open-drainoutputinvolvesa leakagepaththroughthe
+[] 
+ []
+
+[10] <../pics/DSCN2984.JPG, id=44, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN2984.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN2984.JPG>
+Package pdftex.def Info: ../pics/DSCN2984.JPG used on input line 283.
+(pdftex.def)             Requested size: 250.93689pt x 188.20265pt.
+ [11] [12 <../pics/DSCN2984.JPG>]
+Overfull \hbox (4.7657pt too wide) in paragraph at lines 319--320
+[]\OT1/cmr/m/n/10.95 Added ac-celerom-e-ter pcb break-out. Pack-age is small, b
+ut thanks
+ []
+
+[13]
+Underfull \hbox (badness 10000) in paragraph at lines 325--327
+
+ []
+
+
+Overfull \hbox (8.17953pt too wide) in paragraph at lines 328--330
+[]\OT1/cmr/m/n/10.95 https://www.disk91.com/2015/technology/ networks/first-ste
+p-in-
+ []
+
+[14] [15] <../pics/DSCN0132.JPG, id=61, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0132.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0132.JPG>
+Package pdftex.def Info: ../pics/DSCN0132.JPG used on input line 391.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+
+
+Package caption Warning: \captionsetup{type*=...} or \captionof
+(caption)                outside box or environment on input line 392.
+See the caption package documentation for explanation.
+
+[16]
+Underfull \hbox (badness 1292) in paragraph at lines 402--402
+[]\OT1/cmr/bx/n/10.95 Input Pro-tec-tion on Ac-ci-den-tal Re-verse Ca-ble
+ []
+
+[17 <../pics/DSCN0132.JPG>]
+<../pics/rxtx_433.jpg, id=68, 93.951pt x 43.8438pt>
+File: ../pics/rxtx_433.jpg Graphic file (type jpg)
+ <use ../pics/rxtx_433.jpg>
+Package pdftex.def Info: ../pics/rxtx_433.jpg used on input line 414.
+(pdftex.def)             Requested size: 140.92616pt x 65.7655pt.
+
+Underfull \hbox (badness 10000) in paragraph at lines 419--421
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 423--425
+
+ []
+
+[18 <../pics/rxtx_433.jpg>]
+Underfull \hbox (badness 10000) in paragraph at lines 430--433
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 430--433
+
+ []
+
+
+Overfull \hbox (151.92609pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 8c:   40 a1           lds     r20, 0x40       ; 0x80004
+0 <__DATA_REGION_ORIGIN__>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 8e:   51 a1           lds     r21, 0x41       ; 0x80004
+1 <__DATA_REGION_ORIGIN__+0x1>[] 
+ []
+
+
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 90:   62 a1           lds     r22, 0x42       ; 0x80004
+2 <__DATA_REGION_ORIGIN__+0x2>[] 
+ []
+
+[19]
+Overfull \hbox (174.92084pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 92:   73 a1           lds     r23, 0x43       ; 0x80004
+3 <__DATA_REGION_ORIGIN__+0x3>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 96:   04 c0           rjmp    .+8             ; 0xa0 <m
+ain+0x38>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 a2:   d2 f7           brpl    .-12            ; 0x98 <m
+ain+0x30>[] 
+ []
+
+
+Overfull \hbox (13.95758pt too wide) in paragraph at lines 482--482
+[]                \OT1/cmtt/m/n/10.95 __ticks_dc = (uint32_t)(ceil(fabs(__tmp))
+);[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 b0:   f1 f7           brne    .-4             ; 0xae <m
+ain+0x46>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 bc:   39 f7           brne    .-50            ; 0x8c <m
+ain+0x24>[] 
+ []
+
+
+Overfull \hbox (54.1984pt too wide) in paragraph at lines 482--482
+[]  \OT1/cmtt/m/n/10.95 be:   e4 cf           rjmp    .-56            ; 0x88 <m
+ain+0x20>[] 
+ []
+
+[20] <../pics/DSCN0200.JPG, id=79, 1003.75pt x 752.8125pt>
+File: ../pics/DSCN0200.JPG Graphic file (type jpg)
+
+<use ../pics/DSCN0200.JPG>
+Package pdftex.def Info: ../pics/DSCN0200.JPG used on input line 492.
+(pdftex.def)             Requested size: 301.12732pt x 225.84549pt.
+ [21 <../pics/DSCN0200.JPG>]
+Underfull \hbox (badness 10000) in paragraph at lines 515--516
+\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/microcontrollers/powering-
+ []
+
+
+Underfull \hbox (badness 6236) in paragraph at lines 515--516
+\OT1/cmr/m/n/10.95 devices-via-gpio-pins/msg2720044/#msg2720044 - Us-ing GPIO
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 519--520
+[]\OT1/cmr/m/n/10.95 https://www.eevblog.com/forum/beginners/rf-very-low-power-
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 523--524
+[]\OT1/cmr/m/n/10.95 https://blog.podkalicki.com/attiny13-blinky-with-timer-com
+pa/ -
+ []
+
+[22] (./52.aux) ) 
+Here is how much of TeX's memory you used:
+ 3579 strings out of 494945
+ 54551 string characters out of 6181032
+ 123046 words of memory out of 5000000
+ 6841 multiletter control sequences out of 15000+600000
+ 8977 words of font info for 32 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 39i,8n,39p,990b,291s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/
+cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12
+.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb><
+/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
+are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr6.pfb></usr/share/texl
+ive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texm
+f-dist/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/share/texlive/texmf-dist/f
+onts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmtt10.pfb>
+Output written on 52.pdf (22 pages, 819526 bytes).
+PDF statistics:
+ 116 PDF objects out of 1000 (max. 8388607)
+ 77 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 26 words of extra memory for PDF output out of 10000 (max. 10000000)
+

Attiny_Solar_Energy_Harvest/docs/52.tex

@@ -0,0 +1,526 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\begin{center}
+  \includegraphics[scale=0.25]{../pics/DSCN2984.JPG}
+  \captionof{figure}{The silk screen pinout and instructions help.}
+  \end{center}
+
+
+\subsection{PCB}
+I have built rev 2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+\includegraphics[scale=0.30]{../pics/DSCN0132.JPG}
+\captionof{figure}{RF Transmitter w/ PCB Rev 4}
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/52.tex~

@@ -0,0 +1,526 @@
+
+\documentclass[11pt]{article}
+%Gummi|065|=)
+\usepackage{graphicx}
+\usepackage{caption}
+\usepackage{xcolor}
+\usepackage[vcentering,dvips]{geometry}
+\geometry{papersize={6in,9in},total={4.5in,6.8in}}
+%\title{\textbf{Door Alarm}}
+\author{Steak Electronics}
+\date{}
+\begin{document}
+
+%\maketitle
+
+\tableofcontents
+\textcolor{green!60!blue!70}{
+  \section{Attiny Solar Energy Harvest Tests}}
+
+I have the following:
+\begin{itemize}
+\item Solar panels
+\item Attiny 10
+\end{itemize}
+To this list, I will add a supercap, and maybe an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
+\textcolor{green!60!blue!70}{
+\subsection{Micro Considerations}}
+The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free \footnote{I might backtrack on this, but I think I'll do one with and one without batteries.}. A super cap, however can be used to store energy. I'll get to that shortly.
+
+For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? Not sure yet.
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Micro Notes}}
+Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
+\\
+\\
+
+
+\textcolor{green!60!blue!70}{
+\subsubsection{Energy Storage}}
+I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{Make parts, not scrap}} I want to make sure that all parts I build are perf board parts, not 
+breadboard scrap (to be torn down and rebuilt again). This is an Attiny, so no need to test much, yet. Breadboards never really worked for me, so far. Too much build up, then tear down... I like things that are built to last. Parts, not scrap.
+
+\textcolor{green!60!blue!70}{
+\subsection{Programming}}
+To program the Attiny10, I'll use the Arduino adapter from the Junk + Arduino blog. I built it up\footnote{Had slight error where the Arduino + board wouldn't read - pins too short on headers, then the arduino wouldn't boot - due to bad connection on perf board shield. Thankfully, the USB port didn't try to run. Protection circuitry cut in on the laptop. This was all on a perf board. My proto pcb doesn't have this issue.}, and was able to read the memory. In order to upload to the board, you will need a compiler setup. You can possibly do it in AVRGCC, but instead I opted for either Arduino IDE (via Attiny10Core which didn't work), and then went to Mplab. In order for mplab 5.25 to work, it will need XC8 compiler, and there is a pack that can be downloaded through the IDE to get Attiny10 support. After that you can get .hex files to upload.
+
+It appears the AVR Dragon (which I have) can not be used. However, other programmers can be used. Pickit 4, Mkavrii, stk600, I think.
+
+
+\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
+Tested this with the blink\_LED.c in code folder. The code is as simple as possible. 
+It is the following:
+\begin{verbatim}
+//#include <xc.h>
+#include <avr/io.h>
+#include <util/delay.h>
+
+int main(void)
+{
+    // PB2 output
+    DDRB = 1<<2;
+
+    while(1)
+    {
+        // Toggle PB2
+        PINB = 1<<2;
+        _delay_ms(500);
+    }
+}
+\end{verbatim}
+\footnote{As a recap, this code is setting the 2nd bit of DDRB register high (1), and also the PINB register, bit 2. From this we get blinky, aka a square wave.}
+When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
+hex output:
+\begin{verbatim}
+:100000000AC020C01FC01EC01DC01CC01BC01AC01B
+:1000100019C018C017C011271FBFCFE5D0E0DEBF41
+:0A002000CDBF03D000C0F894FFCF5D
+:10002A0044E041B940B95FE966E871E05150604087
+:0A003A007040E1F700C00000F5CFB0
+:02004400DDCF0E
+:00000001FF
+\end{verbatim}
+The content of this hex isn't the focus of this passage. Instead, I want you to review the 
+results of a D for Dump Memory, by the Arduino Loader.
+\begin{verbatim}
+
+Current memory state:
+
+registers, SRAM
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
+0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00 
+0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F 
+0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12 
+NVM lock
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F00: FF FF 
+configuration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F40: FF FF 
+calibration
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3F80: 79 FF 
+device ID
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+3FC0: 1E 90 03 FF 
+program
+      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
+4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0 
+4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF 
+4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9 
+4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0 
+4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF 
+4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+(...some memory omitted here for brevity...)
+43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
+43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
+\end{verbatim}
+
+Notice that the "AC020C01F" is set. That is from the hex. But the 01000...
+before it seems to be missing. Some deciphering of how the Arduino programs
+the Attiny is in order here. It also doesn't end the same.
+
+Regardless, when programming, the Arduino reports 70 bytes written, and in the Mplab project memorymap.xml file, it notes 70 bytes
+for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
+
+The blinking LED works. Let's move on.
+
+\textcolor{green!60!blue!70}{\subsubsection{Conclusion on Arduino Programming Attiny10}}
+It's possible, but you have to make a dedicated jig (almost), so it might be easier to use the official programming tools. However, based on this https://www.avrfreaks.net/forum/pickit-4-and-avr-mcu I might not have a choice. So I will use the Arduino for now. But will have to devise what on board parts are req'd for programming, and incorporate into proto board layout. \textbf{NOTE: This was before I build the proto pcb.}
+
+\textcolor{green!60!blue!70}{ \subsubsection{IO Port Switching Speed}}
+Using the above code without any delay\_ms, I get the following results from a default clock
+speed, and a 128KHz clock speed. This test was done to confirm that I could change the clock with
+\begin{verbatim}
+    //Write CCP
+    CCP = 0xD8;
+    //change CLK to 128KHz
+    CLKMSR = 0b01;
+\end{verbatim}
+There was no issue.
+\begin{verbatim}
+Default CLK (8MHz? or 1MHz?): 160KHz square wave
+128KHz CLK: 2.5KHz square wave on GPIO
+\end{verbatim}
+I am going to pursue 128KHz for starters, for lower current dissipation. Note that with the Arduino loader, it is cumbersome to test and change code as you move along. It is
+therefore going to be necessary to use a programmer, with a dedicated header on board. \textbf{NOTE: this was before the proto board, which made programming slightly faster. Still not 100\%, but usable in terms of agility.}
+\textcolor{green!60!blue!70}{ \subsubsection{VCC 1.8V}}
+The lowest power supported: 1.8V can be applied, without any configuration
+needed. It does not affect IO switching speed (although obviously amplitude is affected).
+\begin{verbatim}
+128KHz CLK (5.0V): 2.5256  KHz IO switch
+128KHz CLK (3.3V): 2.5477  KHz IO switch
+128KHz CLK (1.8V): 2.5849  KHz IO switch
+\end{verbatim}
+As voltage drops, IO speed increases.
+\\
+\\
+\textbf{VCC Dropout voltage:}
+\\
+From 1.5, it drops out at 1.248V or so. Comes back at about 1.34V
+\\
+\\
+Test size of 1.
+\\
+\\
+Can't run this with one (AA) battery, but you could with 2.
+\\
+\\
+Current Draw: 128KHz - IO test, 1.8V, 0.08mA (~78uA) (tested w/ HP 3478A)
+\\
+\\
+\textcolor{green!60!blue!70}{\subsection{Application}}
+First, I need a board for these and a programmer, to quickly program. Second, I need an application. I want extremely low power. Hopefully, solar with no batteries, to start. This is extremely low - that is the point. Let's keep this ridiculous.
+
+Given the power requirements put me under 1mA (with my current panels), I'm considering the following: EEPROMs would require SPI protocol. Doable, but overcomplicated for now.
+\\
+\\
+Eink (need to find a small and cheap enough option. So far, they have either too many pins, and/or use too much current. Something like what stores use to display prices would work, but that doesn't get the data out, only makes it readable.),
+\\
+\\
+Third option would be RF. That is a viable path, but not today. Let's skip that for now.
+\\
+\\
+Fourth option that comes to mind is IR. IR diodes, as in TV remotes, would work well here. I am choosing this as the first project. I will have dumb clients, that consist of - Attiny / IR / Sensor powered by solar. I will have a BBB that receives the IR data, and does all intelligent data gathering. To keep things simple, the IR will be binary ADC data, or otherwise sensor numbers. No SPI, no protocol complexity. That would require space on the Attiny.
+\\
+\\
+Let's build some boards based on the above.
+\\
+\\
+For sensors:
+While building, I came across an option. Hall effect sensors. I think also capacitive sensors can be used. This may find a use in a gate sensor, for when a driveway gate is opened or closed. With a small battery, it would work for years.
+
+Footprints: I had to make a footprint for this module on board package for one sensor. The solution to get footprints right? copy graphic image and make it into silkscreen on the board. Easy.
+
+The sensor I looked at was a temp and humidity sensor SHT11 (SHT10 is obsolete). It is low power enough. However, it's \$20. So not in my price range. Otherwise, it would work here. Looks like communication is a shift register, or SPI.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Magnetic Current Sensor}}
+There is this:
+BM14270AMUV-LB
+Which is low enough current here (\textless 1mA). But \$7 in qty, and req's I2C. Not today.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Accelerometers}}
+These are an option.
+
+Best pinout (for deadbug) is LIS344ALHTR (but lacks vcc down to 1.8)
+2nd Best pinout with full 1.8 -3.6 vcc is ADXL337BCPZ-RL7
+(Keep in mind, these are low end options only)
+(Analog output only. keep it simple for now.)
+Runner up to all above, is KXTC9-2050-FR . But has worse pinout.
+
+Going with AD part. \$5 in single qty.
+Digital output Accelmeters are cheaper.
+
+All have tiny package sizes.
+
+Since I am grabbing 1 output only, will need to orient or choose correct output.
+
+PINOUT: When I said best pinout, I meant that you can solder this by hand or with hot air, without much difficulty, because the layout does not require all pins to be connected (hoping I don't get bit by floating pins, though). Or, the layout has PWR and GND together, which means some pins can be bridged.
+
+\begin{center}
+  \includegraphics[scale=1]{../pics/adxl_pinout.png}
+  \captionof{figure}{Some pinouts are easier than others. That said, this would still benefit from a custom breakout board. Bridge the V+ and GND, omit NC, RES pins and then you will want hot air and solder paste. Those looking for trouble can try magnet wire in a pinch.}
+\end{center}
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Temperature Sensors}}
+Temperature can be boring, but why not. Let's throw one of these on:	LMT84LP . Pin compatible with LM35. Supply current is maybe 8uA. Extremely low.
+LM84 (1.5V starts, to 5.5), LM85 (1.8V to 5.5)
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Gas Sensors}}
+Lowest is 5mV as of writing on dkey. Skipping. The SHT would work, but its too expensive.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Supercap}}
+For now, trying whatever I have in my junk box, as super caps are expensive. If I had money, I'd try:
+FG0V155ZF 
+
+
+
+
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Hall Effect Sensors - Push Pull vs Open Drain Outputs}}
+\begin{verbatim}
+9.1.1OutputTypeTradeoffs
+The push-pulloutputallowsfor the lowestsystempowerconsumption
+becausethereis no currentleakagepathwhenthe outputdriveshighor
+ low. The open-drainoutputinvolvesa leakagepaththroughthe
+ externalpullupresistorwhenthe outputdriveslow.The
+ open-drainoutputsof multipledevicescan be tied
+ togetherto forma logicalAND.In this setup,if any 
+sensordriveslow, the voltageon the sharednodebecomeslow.
+ Thiscan allowa singleGPIOto measurean arrayofsensors
+\end{verbatim} From DRV5032 data sheet.
+
+\textcolor{green!60!blue!70}{ 
+\subsubsection{Conclusion: Starting Sensors}}
+So as a recap, to start with affordable, low power sensors for my project, I have the following types:
+\begin{itemize}
+\item Temp sensor (cheapest)
+\item Magnetic Sensor (hall effect) 
+\item Movement Sensor (accellerometer) (analog output) (tiny package) 
+\item capacitive sensor (azoteq)(may only be short range)
+\end{itemize}
+
+Output, I have not determined yet. IR will not work, as its too high power. Unless I dedicate a battery just for the IR diode... Or make it battery powered. I'll start with batteries, but for solar panel and supercap, it will likely not be viable, unless I transmit extremely rarely. That is also an option, however.
+
+\subsubsection{Farad to mA}
+1.5F supercap can supply 1.5A for 1 second. That is 0.025A for 60 seconds, or 25mA for a minute.
+Let's stay I use half that, so 12mA for 60 seconds is my supply. If I transmit once every other hour (when in sunlight)...\footnote{However, upon my testing, I found that the super cap is only useful while there is light. After dark, it won't hold for very long. Perhaps 1 hour.}
+
+\begin{center}
+  \includegraphics[scale=0.5]{../pics/DSCN2984.JPG}
+  \captionof{figure}{Note the silk screen pinout and instructions. These help a lot.}
+  \end{center}
+
+
+\subsection{PCB}
+I have built rev2 of the board today. Using an Uno, user must remember to include VCC and GND. So the programming takes up all 6 pins. The 0.1'' headers were slightly close to the resistors, and the top row of VCC and GND headers are separated, so I labeled them V+2, and GND2.\footnote{Forgetting to plug in GND, and or 5v+ (for Uno), while still plugging in the TPI pins, did not break the Attiny10, in my tests.}
+
+The 0.05'' pin headers work perfect for scope probes. The extra breakout I made demonstrates this.
+
+\subsubsection{PCB Programming}
+
+By default, the Attiny10 idles around 1.5mA (5V), before programming.
+
+First thing to do, is to program it into a low power mode.
+
+In order to use low power, whilst using the Uno, I will need to add a jumper to the PCB,
+so that you can switch between V+2, and V+1. Three pin jumper. Outside pins are each V+, internal goes to Attiny V+. I'll need to remove the trace on gerber rev2, that goes from 4 to VCC.
+
+\subsubsection{PCB programming and use}
+It's not possible to leave the Arduino plugged in, while testing the Attiny10. 
+example: Even if you power down the Uno, and use a jumper to change V+ rails,
+the power dissipation through the TPI pins (10,11,12,13) will cause a draw of about 545uA, and the Attiny10 will not toggle its led.
+Therefore, not only a power jumper is required to use the Attiny, but also
+a 4 or 5 pin 0.1" cable for the TPI pins, must be disconnected before using the Attiny.
+\footnote{In code section, mplab - tests2, the power draw of the 128KHz internal CLK with PB2 flipping at about 400us a cycle, at 3V VCC is about 115uA. At 2V it is ~95uA.}
+
+\subsubsection{PCB Rev3}
+\begin{itemize}
+\item Added jumper to switch between different power rails, so that
+  Arduino can be left sort of plugged in (turns out, it is still required to disconnect 9,10,11,12,13 pins, so use a 4/5 pin cable). This makes testing low power (2-3V) code, easier, while still programming with the 5V Uno.
+\item Added SOT23-6 breakout
+  \item Moved Resistors further from 9,10,11,12,13 pins.
+  \item Added separate board for analog Accelerometer.
+  \item Moved VCC breakout (0.5'' header pins) to connect directly to tiny, not to bottom Voltage rail.
+  \item Added note about VCC and GND must be connected when programming.
+    \item Added accelerometer pcb breakout. Package is small, but thanks to pinout/unused pins - is reasonable to solder with hot air. I knew this when I chose it... Then I forgot it earlier today.
+\end{itemize}
+
+\subsubsection{RF Comms}
+I want to use RF to communicate with this device. The IR would work, but would require batteries. If I'm going to use batteries I may as well use RF. Ideally, RF without batteries would be nice.
+
+I searched for LoRa modules, and came across this
+\\
+
+https://www.disk91.com/2015/technology/
+networks/first-step-in-lora-land-microchip-rn2483-test/
+
+I've added the datasheets. The RN2483 can be set with a UART, which means two pins on the Attiny. I will want to use a transistor to turn off the module (not using sleep mode), when not in use, so that's another pin. The 4th pin would be for whatever sensor I'm using. Right now, I'm thinking an accelerometer to watch for motion on a door or gate. I may need more pins, as I'd like to be able to switch the accel ic on and off as well.
+
+There is the Attiny40, and also an Attiny402. Different, but both worth considering. The Attiny40 is covered by my programmer, the 402 is not. 40 is from early 2010's, the 202/402 is from 2017. Also the Attiny20, which is less pins than the 40. But covered by my programmer. I would lean towards the 10 or the 20. 40 is too much IO.
+
+Attiny10 has I2C on board (TWI). I'm going to stick with the 10. Keep it simple.
+
+\subsubsection{Present Questions}
+Questions:
+is a two pin UART the best I can expect to find for simple rf comms
+is lora a reasonable solution here? I want as low power as possible,
+   Lora is not the lowest but if I transmit rarely, and for a short time perhaps it won't matter.
+
+Is there some other way to transmit data? I don't want to use ultrasonic waves, and IR seems to be too much current, as well
+as requiring line of sight / lens.
+
+\subsubsection{Plan of attack}
+I'm going to prototype with the Microchip RF modules for now, and see if I can get this working off a solar panel. I have an ADC, and with RESET disabled another IO. Goal is now:
+
+Configure RF modules w/arduino.
+
+
+Configure RF module (one Uno receiver, other tiny transmitter)
+
+
+Attach any sensor that uses ADC. (temp sensor, resistor light or thermocouple, current sensor (monitoring power supply), and I have the ones I already tested today (but will hold off on - the accelerometer, and hall effect).
+
+Desired applications
+- Temp of hot surface (boiler) monitoring
+- Solar current input monitoring.
+
+As I've already worked with a current sense before in my battery project (Electronics\_Projects\_2019), I will use again the INA169. It seems to be low enough power for my needs, though I will double check in practice. The data sheet lacks obvious power dissipation figures, while sensing, though quiescient is about 50uA.
+
+\subsubsection{Other Sensors}
+I need to verify that the following sensors could be used with low power:
+
+Light dependent Resistor / Diode
+
+
+Sound sensor (mic)
+
+\subsubsection{RF Searching}
+RF Transceiver ICs require assembly/programming/time, so we want RF Transceiver modules instead. There are a number of roughly 10mA TX active, but that is the lowest I can find. Among these ics (not modules), most are SPI, have their own ARM core... The modules are a bit better in having some that can be controlled by serial. I like the TRM-433-LT, but I will skip this for now (\$20 each).
+
+I also like the RC11xx-RC232, though the latter is about 30mA TX. That may be the best I can hope for. These two are 433MHz (ISM is 433 - 434MHz). The radiocrafts product is essentially a simplified solution, preprogrammed with a uart which can be used to adjust settings. This option appears to be on part with the microchip offering I've looked at, the RN2483, in fact they both came up on my search results, next to each other. RN doesn't have what IC they use but RC, uses CC1110.
+
+Another option:
+
+ZETAPLUS-433-SO is faster than others (500Kbs), and has lower TX (18mA). Up to 2KM range...
+
+There's more options (over \$18), but for the following specifications, the above three are basically what you can choose from. Ignoring those with high TX power rates (sparkfun), or requires SPI (stmicro)
+Specs:
+\begin{itemize}
+\item In stock
+\item Frequency 433-434MHz
+\item battery powered vcc range (2)
+\end{itemize}
+\footnote{There's only 25.}
+
+I will start with two Radiocraft modules. Let's see how that plays out.\footnote{A set of Dev boards for the radiocraft are \$250. Ouch.}
+
+\includegraphics[scale=0.30]{../pics/DSCN0132.JPG}
+\captionof{figure}{Testing the RF Transmitter w/ PCB Rev 4}
+
+\subsubsection{PCB Rev 5}
+\begin{itemize}
+\item Added instructions to back of board to speed up getting back to this project after some time.
+\item Moved resistors to be further away from programming header
+\item Fixed missed connection from JMP to V1 / V2 when I moved barrel plug, and added back the bottom right mounting hole in rev4.
+\item Changed prg/jmp/vcc to v1/jmp/v2 (either v rail can be used for programming)
+\end{itemize}
+
+\subsubsection{Input Protection on Accidental Reverse Cable Hookup}
+I'm going to want something to block plugging in the dupont cable backwards from breaking things. I had a square wave outputting on one pin of the Attiny10, and programming was going well, with the cable left in, until I removed, then connected it in backwards. The square wave blew something on the Atmega328p of the uno. This led me to quick replacement of the Uno atmega's here: electronics\_projects\_2020/AVRdragon\_Optiboot\_Atmega328
+
+I don't know what's better. Make it foolproof, or let people learn the hard way. With the latter, they at least get a way to reprogram blank Atmegas (quite useful with Unos).
+
+Perhaps instead, a mated connector would be enough on the breakout...
+
+\subsubsection{Nuts \& Volts 433MHz RF Transmitters}
+A recent nuts and volts issue (2019), covered a few sections on RF in one magazine. They covered, transmitters, as well as measuring power output of a transmitter (in separate articles). The RF transmitters they covered were 433MHz, ebay transmitters. The transmitters output the square wave you feed to them. Extremely basic. But also open to modifications and adaptations. The part count is very low, with minimal ICs. (The receivers do have an IC, though.)
+
+I've bought some of these, and will do some testing. One benefit (or drawback) of these, is that they output whatever you feed them. They don't require UART.
+\begin{center}
+\includegraphics[scale=1.5]{../pics/rxtx_433.jpg}
+\captionof{figure}{simple rx tx on 433mhz}
+\end{center}
+
+\subsection{Connecting to Programmer Tips}
+When connecting, have a base setup that works as a sanity check. Then work on a second setup.
+\\
+
+
+It may be possible to blow out atmega328p pins if you leave attiny running, then plug in the cable back to front (i.e. pin 13 in 9).
+\\
+
+Make sure the cable is connected well. Loose cables, will cause the programmer to fail. Solder wires to Uno if necessary.
+
+
+\subsection{Attiny10 Timer Fail}
+\textbf{Note: this is a segway, where I tried to get a 6KHz clock out of one of the Attinys for the 60Hz project).}
+\\
+\\
+
+The goal was to get a 6KHz square wave out of the Attiny10 (first using the timer). After a night of trying to wrangle with timer 0 and CTC mode of the Attiny10 timer (which failed to work as expected). I've decided to buy a 6KHz oscillator. I was able to get 60.3KHz out of the Attiny using no optimization in mplab and IO as fast as possible. I was able to get 6.13Khz using optimization and a for loop (unfortunately the nops got optimized out).
+
+I learned that the cable I was using to program the attiny10 was giving me connection trouble. I soldered one side to an uno. That out of the way, When programming the attiny10 with my protoboard, it's as easy as, 1) connect cable to protoboard, 2) press P in serial monitor of Uno, 3) paste hex contents of mplab build into serial monitor. No need to ever reset the uno, even if it doesn't print that it detects the attiny. It's pretty good about this, and if connected correctly, will just write to the chip, when P is pressed. Then disconnect the cable, and the sketch will run. When it's time to reprogram, reconnect the cable, hit P, and paste contents, etc...
+\textbf{End Segway.}
+
+\subsubsection{AVR-objdump -S}
+Here's some code from lowpower\_tx433mhz\_2/3:
+\begin{verbatim}
+            PORTB = bitRead(*strctPtr, i) << 2;
+  8c:   40 a1           lds     r20, 0x40       ; 0x800040 <__DATA_REGION_ORIGIN__>
+  8e:   51 a1           lds     r21, 0x41       ; 0x800041 <__DATA_REGION_ORIGIN__+0x1>
+  90:   62 a1           lds     r22, 0x42       ; 0x800042 <__DATA_REGION_ORIGIN__+0x2>
+  92:   73 a1           lds     r23, 0x43       ; 0x800043 <__DATA_REGION_ORIGIN__+0x3>
+  94:   08 2f           mov     r16, r24
+  96:   04 c0           rjmp    .+8             ; 0xa0 <main+0x38>
+  98:   76 95           lsr     r23
+  9a:   67 95           ror     r22
+  9c:   57 95           ror     r21
+  9e:   47 95           ror     r20
+  a0:   0a 95           dec     r16
+  a2:   d2 f7           brpl    .-12            ; 0x98 <main+0x30>
+  a4:   41 70           andi    r20, 0x01       ; 1
+  a6:   44 0f           add     r20, r20
+  a8:   44 0f           add     r20, r20
+  aa:   42 b9           out     0x02, r20       ; 2
+        #else
+                //round up by default
+                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
+        #endif
+
+        __builtin_avr_delay_cycles(__ticks_dc);
+  ac:   43 e0           ldi     r20, 0x03       ; 3
+  ae:   4a 95           dec     r20
+  b0:   f1 f7           brne    .-4             ; 0xae <main+0x46>
+  b2:   00 00           nop
+  b4:   8f 5f           subi    r24, 0xFF       ; 255
+  b6:   9f 4f           sbci    r25, 0xFF       ; 255
+    uint8_t i = 0;
+    
+    while(1)
+    {    
+        
+        for(i=0;i<32;i++){
+  b8:   80 32           cpi     r24, 0x20       ; 32
+  ba:   91 07           cpc     r25, r17
+  bc:   39 f7           brne    .-50            ; 0x8c <main+0x24>
+  be:   e4 cf           rjmp    .-56            ; 0x88 <main+0x20>
+
+\end{verbatim}
+It's easily readable assembler. See at the end, are the two jumps
+back in the loop 0x8c (for loop), and 0x88 (while 1). See the read
+on PORTB, and see the delay, which was \_delay\_us(10), but expands to the avr library definition.
+
+
+\subsection{Attiny10 w/Solar and w/433MHz TX}
+There was an issue with 433MHz\_1 and 2 that the output was not on time. I have a 32 bit struct, and when reading the bits, the first 10 bits slowly ramp up from say 500us to 2ms for a 1 or 0. This was resolved by putting in a delay in between reads.
+
+\begin{center}
+\includegraphics[scale=0.3]{../pics/DSCN0200.JPG}
+\captionof{figure}{With a \_delay\_ms, there is no ramping up. But, the delay had to be a minimum, otherwise some ramping did occur. It's very slow, but usable for things without a lot of data to transmit.}
+\end{center}
+
+Some code revision notes:
+
+433MHz\_3: 128000 KHz, 3ms delay in between bit reads being output to PORTB >> 2 (PB2). Timing is now perfect, albeit slow.
+433MHz\_4: 8Mhz: 60us delay in between bit reads. faster, but has a slight time difference. RX seems to not be working right.
+
+I have 433MHz \#4 running under a LED light w/solar panel. 1.4Volts on the Attiny and its able to transmit successfully (when the rx is right next to it on the bench). 1.3Volts and noise appears on RX. So about 1.4Volts is the lower limit... Perhaps.
+
+433MHz\_7: I confirmed in 6 and 7 that 8MHz is not working (at least consistently). Sticking with 128KHz for now. Seems to work as long as all wires are connected. Sometimes I power cycle if something is knocked.
+
+433MHz\_8: adding sleep in place of delay\_ms(100). Will have Watchdog
+power back on.
+
+
+
+\subsubsection{433MHz Module TX Max Speed}
+2KHz was OK. Beyond that, the RX'd signal goes out of phase, i.e. can't keep up. 5KHz is unusable. Tested with sig gen.
+
+
+\subsection{Further Notes}
+https://www.eevblog.com/forum/microcontrollers/powering-devices-via-gpio-pins/msg2720044/\#msg2720044 - Using GPIO to power devices.
+
+leonerd TODO LINK HERE (bookmarks in main mach) attiny815 with rf. notice the coiled antennas
+
+https://www.eevblog.com/forum/beginners/rf-very-low-power-comms-simple/msg3016400/\#msg3016400 - Forum post regarding this project.
+
+https://trmm.net/ATtiny10 - Programming Attiny10 with free / open source toolchain
+
+https://blog.podkalicki.com/attiny13-blinky-with-timer-compa/ - Similar example for Attiny13, adapted but did not work with Attiny10.
+
+\end{document}
+

Attiny_Solar_Energy_Harvest/docs/52.toc

@@ -0,0 +1,37 @@
+\contentsline {section}{\numberline {1}Attiny Solar Energy Harvest Tests}{2}
+\contentsline {subsection}{\numberline {1.1}Micro Considerations}{2}
+\contentsline {subsubsection}{\numberline {1.1.1}Micro Notes}{2}
+\contentsline {subsubsection}{\numberline {1.1.2}Energy Storage}{3}
+\contentsline {subsubsection}{\numberline {1.1.3}Make parts, not scrap}{3}
+\contentsline {subsection}{\numberline {1.2}Programming}{3}
+\contentsline {subsubsection}{\numberline {1.2.1}Testing Arduino Loader}{4}
+\contentsline {subsubsection}{\numberline {1.2.2}Conclusion on Arduino Programming Attiny10}{6}
+\contentsline {subsubsection}{\numberline {1.2.3}IO Port Switching Speed}{6}
+\contentsline {subsubsection}{\numberline {1.2.4}VCC 1.8V}{7}
+\contentsline {subsection}{\numberline {1.3}Application}{7}
+\contentsline {subsubsection}{\numberline {1.3.1}Magnetic Current Sensor}{8}
+\contentsline {subsubsection}{\numberline {1.3.2}Accelerometers}{9}
+\contentsline {subsubsection}{\numberline {1.3.3}Temperature Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.4}Gas Sensors}{10}
+\contentsline {subsubsection}{\numberline {1.3.5}Supercap}{10}
+\contentsline {subsubsection}{\numberline {1.3.6}Hall Effect Sensors - Push Pull vs Open Drain Outputs}{10}
+\contentsline {subsubsection}{\numberline {1.3.7}Conclusion: Starting Sensors}{11}
+\contentsline {subsubsection}{\numberline {1.3.8}Farad to mA}{11}
+\contentsline {subsection}{\numberline {1.4}PCB}{12}
+\contentsline {subsubsection}{\numberline {1.4.1}PCB Programming}{12}
+\contentsline {subsubsection}{\numberline {1.4.2}PCB programming and use}{13}
+\contentsline {subsubsection}{\numberline {1.4.3}PCB Rev3}{13}
+\contentsline {subsubsection}{\numberline {1.4.4}RF Comms}{14}
+\contentsline {subsubsection}{\numberline {1.4.5}Present Questions}{14}
+\contentsline {subsubsection}{\numberline {1.4.6}Plan of attack}{15}
+\contentsline {subsubsection}{\numberline {1.4.7}Other Sensors}{15}
+\contentsline {subsubsection}{\numberline {1.4.8}RF Searching}{15}
+\contentsline {subsubsection}{\numberline {1.4.9}PCB Rev 5}{17}
+\contentsline {subsubsection}{\numberline {1.4.10}Input Protection on Accidental Reverse Cable Hookup}{17}
+\contentsline {subsubsection}{\numberline {1.4.11}Nuts \& Volts 433MHz RF Transmitters}{18}
+\contentsline {subsection}{\numberline {1.5}Connecting to Programmer Tips}{18}
+\contentsline {subsection}{\numberline {1.6}Attiny10 Timer Fail}{19}
+\contentsline {subsubsection}{\numberline {1.6.1}AVR-objdump -S}{19}
+\contentsline {subsection}{\numberline {1.7}Attiny10 w/Solar and w/433MHz TX}{21}
+\contentsline {subsubsection}{\numberline {1.7.1}433MHz Module TX Max Speed}{22}
+\contentsline {subsection}{\numberline {1.8}Further Notes}{22}