https://wiki.hackmanhattan.com/api.php?action=feedcontributions&feedformat=atom&user=Rmd6502Hack Manhattan Wiki - User contributions [en]2026-05-17T23:01:00ZUser contributionsMediaWiki 1.40.1https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5374FlashlightTron2015-07-09T20:50:42Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [http://www.linino.org/product/linino-one Linino], which is essentially an [https://www.arduino.cc/en/Main/ArduinoBoardYun Arduino Yún] (Sparkfun, Digikey, Ebay, etc)<br />
* 4x18650 size LiIon cells (Ebay) + charger<br />
* [http://www.adafruit.com/products/618 Cheap Nokia TFT LCD] (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-11-24&diff=5370Meeting 2015-11-242015-07-05T22:06:37Z<p>Rmd6502: /* Consensus Agenda */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
== Change in Bylaws: termination for failure to pay dues ==<br />
<br />
The third paragraph of Article 2, Section 7, is amended to<br />
<br />
<blockquote><p>Termination of membership due to failure to pay dues, fees or assessments is self-executing and automatically effective</p><br />
<p>(i) 60 days after the period for which dues have been paid has lapsed, for failure to pay dues,</p><br />
<p>(ii) 30 days after fees or assessments are due, for failure to pay fees or assessments, or</p><br />
<p>(iii) when otherwise effected by the board.</p><br />
<p>A former member must make immediate arrangements to resolve the practical implications of termination, according to procedures adopted by the members or the board. No act, omission or failure by the corporation may prejudice the requirement of former members to fulfill their obligations under the corporation's Bylaws or rules.</p></blockquote><br />
<br />
This paragraph is added to Article 2, Section 7, of the Bylaws: <br />
<br />
<blockquote>The members may adopt abbreviated procedures for the admission of former members whose membership was terminated by resignation or for failure to pay dues, fees or assessments.</blockquote><br />
<br />
== Proposed change to bylaws: ==<br />
<br />
I would like to add an official amendment to the bylaws for termination of membership due to serious safety violations.<br />
<br />
These include:<br />
* Failure to wear required safety equipment (e.g. safety glasses, welding mask, gloves) while operating tools or machinery<br />
* Failure to properly turn off power tools or other machinery when done using it and/or leaving the space<br />
* Failure to disassemble, shut down, or put away tools when finished - for example leaving drill bits or milling bits attached<br />
* Misuse of tools or equipment whether through intent or lack of proper knowledge<br />
* Any other behaviors which make anyone, member or not, feel that a significant safety risk is posed to themselves or others, or that damage will occur to expensive equipment as a result.<br />
<br />
rmd6502<br />
<br />
== Date of annual meeting ==<br />
<br />
Article 3, Section 1, is amended to read:<br />
<br />
<blockquote>Meetings of members must be held in New York County, no more than one kilometer from the corporation's premises, not on a major public holiday as recognized by New York City, and between 6pm and midnight on weekdays or 10am and 10pm on weekends. The board must call the annual meeting of members in accordance with Section 603 of the Not-for-Profit Corporation Law to be held in January or February.</blockquote><br />
<br />
A consequence will be that there will be another meeting in January or February 2016.<br />
<br />
== Lower quorum requirements ==<br />
<br />
Article 3, Section 6, is amended by replacing the first two paragraphs with the following:<br />
<br />
<blockquote><p>A quorum for regularly scheduled monthly members meetings is zero members.</p><p>A quorum for meetings of members as provided in Article 6 of the Not-for-Profit Corporation Law, including annual meetings, is the lesser of one hundred members or one-tenth of the members entitled to vote at the beginning of the meeting.</p><br />
<p>Members represented by a proxy continue to count as present for the purpose of determining whether a meeting is quorate.</p></blockquote><br />
<br />
(The original version proposed lowering the quorum requirement to zero. That is illegal for "real" member meetings.)<br />
<br />
== Relax proxy limits ==<br />
<br />
Article 3, Section 4, is amended by replacing the last paragraph with the following:<br />
<br />
<blockquote>Except for elections, a member may vote on behalf of at most two other members, or one-tenth of the members entitled to vote at the meeting, whichever is higher. A proxy is valid only for the specific meeting or meetings designated in the proxy.</blockquote><br />
<br />
== Clarification of obligation to pay dues ==<br />
<br />
The last paragraph of Article 2, Section 7, of the Bylaws is amended by replacing the two instances of “or omission” with a comma and “omission or failure”.<br />
<br />
== Confirming power of members to make rules for the space ==<br />
<br />
Article 2, Section 5, is amended by adding:<br />
<br />
<blockquote><p>The members may continue to make rules for limiting the access of individual members to use the corporation's facilities and equipment under urgent or extraordinary circumstances, pending a decision on termination of membership.</p></blockquote><br />
<br />
== Board term does not end if no election was held due to lack of a quorum ==<br />
<br />
Article 4, Section 3, is amended by replacing "at the following annual meeting" in the first sentence of the last paragraph with "upon the next election for that office or directorship at a meeting of members", and by adding at the end of the last paragraph: "If an election at a meeting of members is not held due to the lack of a quorum, the board must call a new meeting as soon as practical."<br />
<br />
== Other technical corrections to clarify our compliance with the law ==<br />
<br />
Article 3, Section 6, is amended by adding:<br />
<br />
<blockquote><p>The procedure for online votes continues to apply only to matters which are not required to be decided by a vote at a meeting of members by the Not-for-Profit Corporation Law.</p></blockquote><br />
<br />
= New Business =<br />
<br />
''It is ordinarily not in order to introduce new business at the meeting.''<br />
<br />
== Formerly in Consensus Agenda ==<br />
<br />
== Sponsored Members Induction ==<br />
<br />
For each prospective member, please confirm no later than Thursday before the meeting:<br />
<br />
* Has the member visited 3 times at the regular Tuesday and Thursday open nights?<br />
* Has the member received the briefing? When, and who was the briefer?<br />
* Has the member's bio and photo been circulated on the members list? (not just blabber)<br />
<br />
== Other New Business ==<br />
<br />
== Elections ==<br />
<br />
=== President ===<br />
<br />
=== Treasurer ===<br />
<br />
=== Secretary ===<br />
<br />
=== Directors-at-Large ===<br />
<br />
= Member Reports =<br />
<br />
=== President's report ===<br />
<br />
=== Treasurer's report ===<br />
<br />
=== Secretary's report ===<br />
<br />
=== Directors-at-Large's reports ===<br />
<br />
=== Member Reports ===<br />
<br />
== Proxies ==<br />
<br />
= Adjournment =<br />
<br />
[[Category:Meetings]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5369Meeting 2015-07-282015-07-05T22:05:18Z<p>Rmd6502: /* Proposed amendment to section 7 of the bylaws */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5368Meeting 2015-07-282015-07-05T21:02:16Z<p>Rmd6502: /* Proposed amendment to section 7 of the bylaws */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
== Proposed amendment to section 7 of the bylaws ==<br />
<br />
I would like to add an official amendment to the bylaws for termination of membership due to serious safety violations.<br />
<br />
These include:<br />
* Failure to wear required safety equipment (e.g. safety glasses, welding mask, gloves) while operating tools or machinery<br />
* Failure to properly turn off power tools or other machinery when done using it and/or leaving the space<br />
* Failure to disassemble, shut down, or put away tools when finished - for example leaving drill bits or milling bits attached<br />
* Misuse of tools or equipment whether through intent or lack of proper knowledge<br />
* Any other behaviors which make anyone, member or not, feel that a significant safety risk is posed to themselves or others, or that damage will occur to expensive equipment as a result.<br />
<br />
rmd6502<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5367Meeting 2015-07-282015-07-05T20:55:24Z<p>Rmd6502: /* Proposed amendment to section 7 of the bylaws */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
== Proposed amendment to section 7 of the bylaws ==<br />
<br />
I would like to add an official amendment to the bylaws for termination of membership due to serious safety violations.<br />
<br />
These include:<br />
* Failure to wear safety glasses or other required safety equipment while operating tools or machinery<br />
* Failure to properly turn off power tools or other machinery when done using it and/or leaving the space<br />
* Failure to disassemble, shut down, or put away tools when finished - for example leaving drill bits or milling bits attached<br />
* Misuse of tools or equipment whether through intent or lack of proper knowledge<br />
* Any other behaviors which make anyone, member or not, feel that a significant safety risk is posed to themselves or others, or that damage will occur to expensive equipment as a result.<br />
<br />
rmd6502<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5366Meeting 2015-07-282015-07-05T20:54:06Z<p>Rmd6502: /* Proposed amendment to section 7 of the bylaws */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
== Proposed amendment to section 7 of the bylaws ==<br />
<br />
I would like to add an official amendment to the bylaws for termination of membership due to serious safety violations.<br />
<br />
These include:<br />
* Failure to wear safety glasses or other required safety equipment while operating tools or machinery<br />
* Failure to properly turn off power tools or other machinery when done using it and/or leaving the space<br />
* Failure to disassemble, shut down, or put away tools when finished - for example leaving drill bits or milling bits attached<br />
* Misuse of tools or equipment whether through intent or lack of proper knowledge<br />
* Any other behaviors which make anyone, member or not, feel that a significant safety risk is posed to themselves or others, or that damage will occur to expensive equipment as a result.<br />
==~<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5365Meeting 2015-07-282015-07-05T20:53:50Z<p>Rmd6502: /* New Business */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
== Proposed amendment to section 7 of the bylaws ==<br />
<br />
I would like to add an official amendment to the bylaws for termination of membership due to serious safety violations.<br />
<br />
These include:<br />
* Failure to wear safety glasses or other required safety equipment while operating tools or machinery<br />
* Failure to properly turn off power tools or other machinery when done using it and/or leaving the space<br />
* Failure to disassemble, shut down, or put away tools when finished - for example leaving drill bits or milling bits attached<br />
* Misuse of tools or equipment whether through intent or lack of proper knowledge<br />
* Any other behaviors which make anyone, member or not, feel that a significant safety risk is posed to themselves or others, or that damage will occur to expensive equipment as a result.<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2015-07-28&diff=5364Meeting 2015-07-282015-07-05T20:42:48Z<p>Rmd6502: Created page with "= Consensus Agenda = = New Business = = Member Reports ="</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
= New Business =<br />
<br />
= Member Reports =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Main_Page&diff=5363Main Page2015-07-05T20:41:04Z<p>Rmd6502: /* Monthly Business Meetings */</p>
<hr />
<div>[[File:HMpano2.jpg|800px]]<br />
<br />
<br />
= Hack Manhattan! =<br />
<br />
Hack Manhattan is a nonprofit cooperative space in Manhattan dedicated to technology, science, and the arts. We're the only public hackerspace in Manhattan. Get involved. Bring your curiosity, intellect, and imagination. Visit [http://hackmanhattan.com our website].<br />
<br />
'''NOTE: ''' This wiki is public, but only approved users may edit. All Hack Manhattan members should have an account. Non-members -- to contribute, please sign up for an account and we'll respond ASAP.<br />
<br />
<table width="100%"><br />
<tr><br />
<td valign="top" width="48%"><br />
<br />
== Location ==<br />
<br />
We're centrally located near the L/F/M/1/2/3/A/C/E/PATH trains and 2.5 blocks west of Union Sq (4/5/6/N/Q/R trains).<br />
<br />
[http://maps.google.com/maps?q=137+West+14th+st+ny+ny 137 W 14th Street, Studio 201, New York, NY 10011-7308]<br />
<br />
== [[MembershipInfo|Membership]] ==<br />
<br />
Hack Manhattan is accepting new members. See [[MembershipInfo]] for more details.<br />
<br />
== Meetings & Events ==<br />
<br />
=== [[Calendars|Events]] ===<br />
<br />
* [http://hackmanhattan.com/calendar/ Calendar]<br />
* [http://www.meetup.com/hackmanhattan/ Meetup]<br />
<br />
=== Monthly [[Business Meetings]] === <br />
(Held the last Tuesday of the month at 7:30PM. Conducted in accordance with [[MIBS Rules]].)<br />
<br />
Next Meeting:<br />
* [[Meeting_2015-07-28 | Business Meeting July 28, 2015]]<br />
<br />
Annual meeting:<br />
* [[Meeting_2015-11-24 | Annual and Business Meeting November 24, 2015]]<br />
<br />
[[:Category:Meetings]]<br />
<br />
== About the space and building==<br />
<br />
Looking for something? Try [http://things.hackmanhattan.com/ Things]!<br />
<br />
* [[Rat Park]] (the building)<br />
* [[Facilities]]<br />
* [[Wish_List | Gear wishlist]]<br />
<!-- * [[Space_wishlist | Facilities wishlist]]<br />
* [[Donated_or_Loaned_Gear | Donated or Loaned Gear]] --><br />
* [[Tools and Equipment]]<br />
<!-- * [[New_space_checklist | Requirements and notes about the "new space"]] --><br />
<br />
== Resources ==<br />
* [[Administration]]<br />
* [[Building]]<br />
* [[Bylaws | HackManhattan! By-laws]] and [[MIBS Rules | Meeting Procedure (SRC3)]]<br />
* [http://list.hackmanhattan.com/mailman/listinfo/blabber Mailing list] ([http://www.mail-archive.com/blabber@list.hackmanhattan.com/ archives])<br />
* IRC: #hackmanhattan @ irc.freenode.net [[http://webchat.freenode.net/?channels=hackmanhattan Web Chat]]<br />
* [http://www.reddit.com/r/hackmanhattan/ /r/hackmanhattan]<br />
* [[Suppliers | Suppliers, Vendors, Sources of stuff!]]<br />
* [[FundRaising | Fund-raising ideas, links, projects]]<br />
* [[Meeting_2013-03-26#Space_use_policy|Space Use Policy]]<br />
* [[Cool Links | Cool Links to Hackerspaces, Blogs, Etc.]]<br />
* [[Local Resources]] Places of interest close to HackManhattan!<br />
* [[Bad Jokes Related to Hacking]] Like the name says it....<br />
* [[Logos and Files]]<br />
* [[3D Printing Resources]]<br />
* [[Welding Resources]]<br />
* [[Affiliate]]<br />
* [[Operations]]<br />
* [[Electronics]]<br />
* [[Hackerspaces]]<br />
* [[Gigs]]<br />
</td><br />
<td width="1%" style="<br />
border-right:solid 1px #a7d7f9;"></td><br />
<td width="1%"></td><br />
<td valign="top" width="48%"><br />
<br />
== [[Projects|Projects / Interest Groups]] ==<br />
<br />
{{:Projects}}<br />
<br />
== [[Individual Pages]] ==<br />
<br />
{{:Individual Pages}}<br />
<br />
</td><br />
</tr><br />
</table><br />
<br />
__NOTOC__</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5238FlashlightTron2015-06-27T21:30:36Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [http://www.linino.org/product/linino-one Linino], which is essentially an [https://www.arduino.cc/en/Main/ArduinoBoardYun Arduino Yún] (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* [http://www.adafruit.com/products/618 Cheap Nokia TFT LCD] (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5235FlashlightTron2015-06-27T19:13:21Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [http://www.linino.org/product/linino-one Linino], which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* [http://www.adafruit.com/products/618 Cheap Nokia TFT LCD] (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5234FlashlightTron2015-06-27T19:12:10Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [http://www.linino.org/product/linino-one Linino], which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5233FlashlightTron2015-06-27T19:11:30Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [http://www.linino.org/product/linino-one/|Linino], which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5232FlashlightTron2015-06-27T19:11:15Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [[http://www.linino.org/product/linino-one/|Linino]], which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5231FlashlightTron2015-06-27T19:10:46Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the [[http://www.linino.org/product/linino-one/|Linino], which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5226FlashlightTron2015-06-27T16:03:05Z<p>Rmd6502: /* Assembly */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
* My plan is to use the linux board as a HTTP server - POSTing an image or small video will cause it to be projected<br />
* The Arduino side of the linino board will control the display - it will receive bitmaps from the linux side over SPI, and paint them on the display<br />
* This could also be done with a Raspberry Pi, maybe a compute module.<br />
* Ultimately also have physical controls to change the brightness (20w is pretty bright and the batteries won't last long) and have builtin images for e.g. colored light<br />
* Screen savers, kaleidoscope?<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Projects&diff=5225Projects2015-06-27T15:58:50Z<p>Rmd6502: /* Active Projects */</p>
<hr />
<div>=== Active Projects ===<br />
* [[Keyless Entry]]<br />
* [[hackmanhattan.club]]<br />
* [[3D Printing|3D Printer/CNC]]<br />
* [[3D Projects|3D Projects originating at HackManhattan!]]<br />
* [[FurrBot Final]]<br />
* [[Gardening]]<br />
* [[Disaster Plan]]<br />
* [[Classes|Class Offerings]]<br />
* [[Security and privacy]]<br />
* [[Lathe Operations Wiki]]<br />
* [[Amateur Radio]]<br />
* [[NRF51822|nRF51822 and Bluetooth Low Energy]]<br />
* [[Energy harvesting]]<br />
* [[Data Logger]]<br />
* [[π r no longer ²]]<br />
* [[Charlieplexed PWM Heart]]<br />
* [[Little Dave's BIG Adventure]]<br />
* [[Mailman Replacement]]<br />
* [[FlashlightTron|FlashlightTron™ 8000]]<br />
<br />
=== Dormant Projects ===<br />
<br />
Please revive!<br />
<br />
* [[Store-Front]]<br />
* [[LPC Programmer]]<br />
* [[page:Telescopes/Astronomy|Astronomy]]<br />
* [[page:RC/Autonomous Aircraft|Aircraft]]<br />
* [[page:Assembly Robot|Assembly Robot]]<br />
* [[Bike workshop]]<br />
* [[Making Things Talk]]<br />
* [[Cicada Tracker]]<br />
* [[Brain Bats]]<br />
* [[page:Darkroom|Darkroom]]<br />
* [[Interactive Automaton]]<br />
* [[Scanning Electron Microscope]]<br />
* [[World Maker Faire 2014]]<br />
* [[Cheap Wireless Node]]<br />
* [[Nixie Tube Calculator!]]<br />
* [[Slot cars]]<br />
* [[Happy Happy Brew Time]]<br />
* [[Vending Machine]]<br />
* [[Infrared Arduino]]<br />
* [[Newsletter]]<br />
* [[OpenBrainLab]] - EEG and biosensors workshop<br />
* [[CADathon]]<br />
* [[2014 Group Project]]<br />
* [[Hackerspace of Things]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5224FlashlightTron2015-06-27T15:57:09Z<p>Rmd6502: /* Assembly */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
# Build and test boost converter<br />
# Peel the back off the Nokia display<br />
# In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5223FlashlightTron2015-06-27T15:56:53Z<p>Rmd6502: /* Assembly */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
1. Build and test boost converter<br />
1. Peel the back off the Nokia display<br />
1. In progress<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5222FlashlightTron2015-06-27T15:55:39Z<p>Rmd6502: /* Components */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
* Convex lens - good quality is important for a good projection<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5221FlashlightTron2015-06-27T15:54:28Z<p>Rmd6502: /* Assembly */</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png|800px|Exploded Schematic]]<br />
<br />
--[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 15:54, 27 June 2015 (UTC)</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=File:FlashlightTron.png&diff=5220File:FlashlightTron.png2015-06-27T15:50:35Z<p>Rmd6502: </p>
<hr />
<div></div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=FlashlightTron&diff=5219FlashlightTron2015-06-27T15:49:44Z<p>Rmd6502: Created page with " == FlashlightTron™ 8000 == FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite ca..."</p>
<hr />
<div><br />
== FlashlightTron™ 8000 ==<br />
<br />
FlashlightTron™ 8000 is a combination light source, graffiti projector, and personal protection device. The system is built into a Maglite case.<br />
<br />
=== Components ===<br />
<br />
* Maglite<br />
* 20W cool white LED (Ebay)<br />
* Small cheap linux board - I used the Linino, which is essentially an Arduino Yún (Sparkfun, Digikey, Ebay, etc)<br />
* 12xAA size NiMH cells (Ebay) + charger<br />
* Cheap Nokia TFT LCD (Adafruit)<br />
* Boost converter (Ebay, or build your own)<br />
<br />
=== Assembly ===<br />
<br />
[[File:FlashlightTron.png]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=User:Rmd6502&diff=5218User:Rmd65022015-06-27T14:18:16Z<p>Rmd6502: /* Current Projects */</p>
<hr />
<div>== Robert Diamond ==<br />
<br />
[[File:rob_bot.jpg]]<br />
<br />
Mobile Software Engineer by day<br />
<br />
Master Geek at Hack Manhattan and Alpha One Labs<br />
<br />
Reachable at rmd6502@gmail.com<br />
<br />
== Current Projects ==<br />
* [[FlashlightTron|FlashlightTron 8000]]<br />
* [[Nixie Tube Calculator]]<br />
* Arduino-based [[line following robot]]<br />
* [http://en.wikipedia.org/wiki/Charlieplexing Charlieplexed] [[led bracelet]]<br />
* [http://www.neurosky.com Brainwave] controlled [[slot cars]]<br />
* [[π r no longer ²]]<br />
* [[Identifying Devices for the Internet Of Things]], or IDIOT for short</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Individual_Pages&diff=5217Individual Pages2015-06-27T14:17:02Z<p>Rmd6502: </p>
<hr />
<div>Please add yours!<br />
* [[user:Cstratton|Chris Stratton]]<br />
* [[user:Obscurite|Obscurite (Daniel Packer)]]<br />
* [[user:citybadger|citybadger (Stephen Lynch)]]<br />
* [[user:skreuzer|Steven Kreuzer]]<br />
* [[user:Jonathan|Jonathan]]<br />
* [[user:Jeff|Jeff McCrum]]<br />
* [[user:Ananda|Ananda]]<br />
* [[User:Guan|Guan Yang]]<br />
* [[User:Sam|Rotabush (Sam Brown)]]<br />
* [[User:DrReeves|Dave Reeves]]<br />
* [[User:shenkin|Peter Shenkin]]<br />
* [[User:Jsadusk|Joe Sadusk]]<br />
* [[User:ximox|Antonio]]<br />
* [[User:SuperLuckyCat|Crystal]]<br />
* [[User:Conor Russomanno|Conor Russomanno]]<br />
* [[User:Merylgreenblatt|Meryl Greenblatt]]<br />
* [[User:Krassimir Iankov|Krass]]<br />
* [[User:Matthew Duepner|Matthew Duepner]]<br />
* [[User:Ben S|Ben S]]<br />
* [[User:konsgn|Konstantin]]<br />
* [[User:Nickolai|Nickolai]]<br />
* [[User:Vitallish|Vitaly]]<br />
* [[User:KonstantinLeonenko|Konstantin Leonenko]]<br />
* [[User: Curiocity|Annie H]]<br />
* [[User: Rmd6502|Robert Diamond]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Arduino_Workshop_rev2&diff=4928Arduino Workshop rev22015-03-31T23:51:18Z<p>Rmd6502: </p>
<hr />
<div>[[Category:Electronics]] [[Category:Workshops]]<br />
<br />
Will be based on the Teensy LC. Late April or early May.<br />
<br />
Pre-class session where users come in, are handed their parts, and their software installation and drivers is verified. About 15 minutes.<br />
<br />
Class itself will be 3-4 hours on a weekend afternoon.<br />
<br />
Basic class, topics:<br />
<br />
* What is an Arduino?<br />
* Blinking the on board LED<br />
* How a solderless breadboard works<br />
* Blinking an external LED, sizing the current limiting resistor<br />
* Input from a pushbutton, how pull-up resistors work<br />
* Driving a WS2812, Arduino libraries, 3.3V vs 5V issues<br />
* Potentiometer (analog input)<br />
<br />
Date requests:<br />
<br />
* Not May 3<br />
* Not April 11 or May 2<br />
* Sunday instead of Saturday</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Identifying_Devices_for_the_Internet_Of_Things&diff=4296Identifying Devices for the Internet Of Things2014-05-26T19:26:51Z<p>Rmd6502: /* Proposals */</p>
<hr />
<div>''I''dentifying ''D''evices for the ''I''nternet ''O''f ''T''hings<br />
<br />
The purpose of this page is to create a set of taxonomies for connected devices - despite the flippant name, it's a serious topic.<br />
<br />
I am aware of the following classifications, no doubt there are more:<br />
<br />
<table class="wikitable"><br />
<tr><th>Classification</th><th>Description</th><th>Examples</th></tr><br />
<tr><td>Processor</td><td>The CPU for the device</td><td>ATmega328, NRF51822</td></tr><br />
<tr><td>Board</td><td>The board name from the manufacturer</td><td>Arduino, Nordic Semiconductor development board, Guan 8051</td></tr><br />
<tr><td>Connectivity</td><td>How this Thing communicates - include manufacturer specifics if appropriate</td><td>Wifi, 6LowPan, BLE, 315mHz, XBee (ZB)</td></tr><br />
<tr><td>Operating System</td><td>Optional, what OS is running, if any</td><td>Linux 3.2, Android, FreeRTOS</td></tr><br />
<tr><td>Appliance Type</td><td>The actual purpose of the Thing</td><td>Lamp, Beer Brewing, Power Strip</td></tr><br />
<tr><td>Appliance Details</td><td>Implementation-specifics that may be important</td><td>Voltages and warnings, Consumables needed, etc.</td></tr><br />
</table><br />
<br />
=Guidelines=<br />
<br />
When creating devices I try to avoid binary communication formats, to make debugging easier.<br />
<br />
I also like to include a help function that describes the basic commands this device accepts.<br />
<br />
=Proposals=<br />
<br />
The ultimate purpose of this is to catalog Things as they are created, and be able to tell at a glance how they might work.<br />
<br />
In addition, I have a fairly ambitious idea, to enable IPV6 connectivity for all things through a gateway specification. Users could ssh into any device, regardless of connectivity, and be able to talk to it directly, or create communication libraries that are agnostic of how it's talked to.<br />
<br />
The magic would be accomplished through a manager daemon, which would be the 'shell' for the connection user. The daemon would poll connected devices and instantiate virtual network adapters for each. Different devices would be cataloged via the IPV6 address bits, which will be more than adequate for classification.<br />
<br />
For example, if the classification for XBee devices was 1234, and the XBee address desired was [00:13:a2:00:40:8c:56:9c]!, the IPV6 address/80 might be 2604:2000:1085:1234:0013:a200:408c:569c. The manager would have already created this virtual interface after doing an XBee node discovery, and have opened a server socket to it.<br />
<br />
The manager daemon would accept connections on all these virtual devices, and check the IPV6 address for the device type and device address. It would delegate the device address to the appropriate connection daemon, which would send and receive data to the device.<br />
<br />
Finally, a username, e.g. 'iot' is set up, and its 'shell' is a client that connects to the manager daemon and sends its IP address to it, then establishes a two-way connection through the manager.<br />
<br />
This has the benefits of<br />
* secure communication to devices<br />
* enabling connectivity-agnostic device connections<br />
* ability to filter access to devices with router firewall rules</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Identifying_Devices_for_the_Internet_Of_Things&diff=4295Identifying Devices for the Internet Of Things2014-05-26T19:19:03Z<p>Rmd6502: Created page with "''I''dentifying ''D''evices for the ''I''nternet ''O''f ''T''hings The purpose of this page is to create a set of taxonomies for connected devices - despite the flippant name..."</p>
<hr />
<div>''I''dentifying ''D''evices for the ''I''nternet ''O''f ''T''hings<br />
<br />
The purpose of this page is to create a set of taxonomies for connected devices - despite the flippant name, it's a serious topic.<br />
<br />
I am aware of the following classifications, no doubt there are more:<br />
<br />
<table class="wikitable"><br />
<tr><th>Classification</th><th>Description</th><th>Examples</th></tr><br />
<tr><td>Processor</td><td>The CPU for the device</td><td>ATmega328, NRF51822</td></tr><br />
<tr><td>Board</td><td>The board name from the manufacturer</td><td>Arduino, Nordic Semiconductor development board, Guan 8051</td></tr><br />
<tr><td>Connectivity</td><td>How this Thing communicates - include manufacturer specifics if appropriate</td><td>Wifi, 6LowPan, BLE, 315mHz, XBee (ZB)</td></tr><br />
<tr><td>Operating System</td><td>Optional, what OS is running, if any</td><td>Linux 3.2, Android, FreeRTOS</td></tr><br />
<tr><td>Appliance Type</td><td>The actual purpose of the Thing</td><td>Lamp, Beer Brewing, Power Strip</td></tr><br />
<tr><td>Appliance Details</td><td>Implementation-specifics that may be important</td><td>Voltages and warnings, Consumables needed, etc.</td></tr><br />
</table><br />
<br />
=Guidelines=<br />
<br />
When creating devices I try to avoid binary communication formats, to make debugging easier.<br />
<br />
I also like to include a help function that describes the basic commands this device accepts.<br />
<br />
=Proposals=<br />
<br />
The ultimate purpose of this is to catalog Things as they are created, and be able to tell at a glance how they might work.<br />
<br />
In addition, I have a fairly ambitious idea, to enable IPV6 connectivity for all things through a gateway specification. Users could ssh into any device, regardless of connectivity, and be able to talk to it directly, or create communication libraries that are agnostic of how it's talked to.<br />
<br />
The magic would be accomplished through a manager daemon, which would be the 'shell' for the connection user. The daemon would poll connected devices and instantiate virtual network adapters for each. Different devices would be cataloged via the IPV6 address bits, which will be more than adequate for classification.<br />
<br />
For example, if the classification for XBee devices was 1234, and the XBee address desired was [00:13:a2:00:40:8c:56:9c]!, the IPV6 address/80 might be 2604:2000:1085:1234:0013:a200:408c:569c.</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=User:Rmd6502&diff=4294User:Rmd65022014-05-26T18:15:45Z<p>Rmd6502: /* Current Projects */</p>
<hr />
<div>== Robert Diamond ==<br />
<br />
[[File:rob_bot.jpg]]<br />
<br />
Mobile Software Engineer by day<br />
<br />
Master Geek at Hack Manhattan and Alpha One Labs<br />
<br />
Reachable at rmd6502@gmail.com<br />
<br />
== Current Projects ==<br />
* [[Nixie Tube Calculator]]<br />
* Arduino-based [[line following robot]]<br />
* [http://en.wikipedia.org/wiki/Charlieplexing Charlieplexed] [[led bracelet]]<br />
* [http://www.neurosky.com Brainwave] controlled [[slot cars]]<br />
* [[π r no longer ²]]<br />
* [[Identifying Devices for the Internet Of Things]], or IDIOT for short</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=User:Rmd6502&diff=4293User:Rmd65022014-05-26T18:15:16Z<p>Rmd6502: /* Current Projects */</p>
<hr />
<div>== Robert Diamond ==<br />
<br />
[[File:rob_bot.jpg]]<br />
<br />
Mobile Software Engineer by day<br />
<br />
Master Geek at Hack Manhattan and Alpha One Labs<br />
<br />
Reachable at rmd6502@gmail.com<br />
<br />
== Current Projects ==<br />
* [[Nixie Tube Calculator]]<br />
* Arduino-based [[line following robot]]<br />
* [http://en.wikipedia.org/wiki/Charlieplexing Charlieplexed] [[led bracelet]]<br />
* [http://www.neurosky.com Brainwave] controlled [[slot cars]]<br />
* [[π r no longer ²]]<br />
* [[Identifying Devices for the Internet Of Things (IDIOT)]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=User:Rmd6502&diff=4292User:Rmd65022014-05-26T18:14:45Z<p>Rmd6502: /* Current Projects */</p>
<hr />
<div>== Robert Diamond ==<br />
<br />
[[File:rob_bot.jpg]]<br />
<br />
Mobile Software Engineer by day<br />
<br />
Master Geek at Hack Manhattan and Alpha One Labs<br />
<br />
Reachable at rmd6502@gmail.com<br />
<br />
== Current Projects ==<br />
* [[Nixie Tube Calculator]]<br />
* Arduino-based [[line following robot]]<br />
* [http://en.wikipedia.org/wiki/Charlieplexing Charlieplexed] [[led bracelet]]<br />
* [http://www.neurosky.com Brainwave] controlled [[slot cars]]<br />
* [[π r no longer ²]]<br />
* [[Identifying Devices for the Internet Of Things][IDIOT]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=41062014 Group Project2014-02-18T15:50:56Z<p>Rmd6502: /* Humans versus zombies */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
This could be a cellular automaton game - the probability of converting a human to a zombie is proportional to the number of zombies attacking vs the number of humans in range. Both much simpler and much more complicated to implement. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
I like it - we could hang these all over the island. In fact, if I can get my attiny85 sound project working, we could use that as the codec, and use either wireless or let the string be a wire. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"<br />
… That's broken in half --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=41052014 Group Project2014-02-18T15:50:44Z<p>Rmd6502: /* Humans versus zombies */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
This could be a cellular automaton game - the probability of converting a human to a zombie is proportional to the number of zombies attacking vs the number of humans in range. Both much simpler and much more complicated to implement. ---~~<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
I like it - we could hang these all over the island. In fact, if I can get my attiny85 sound project working, we could use that as the codec, and use either wireless or let the string be a wire. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"<br />
… That's broken in half --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=41042014 Group Project2014-02-18T15:50:30Z<p>Rmd6502: /* Humans versus zombies */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
This could be a cellular automaton game - the probability of converting a human to a zombie is proportional to the number of zombies attacking vs the number of humans in range. Both much simpler and much more complicated to implement. ===~~<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
I like it - we could hang these all over the island. In fact, if I can get my attiny85 sound project working, we could use that as the codec, and use either wireless or let the string be a wire. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"<br />
… That's broken in half --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Charlieplexed_PWM_Heart&diff=4061Charlieplexed PWM Heart2014-02-07T04:17:49Z<p>Rmd6502: /* Demo */</p>
<hr />
<div>== Demo ==<br />
* [File:https://dl.dropboxusercontent.com/u/10205003/VIDEO0005.mp4]<br />
* [https://docs.google.com/file/d/0ByQl1ZrtYxQuOXRvRXFicUV2V3M/edit Another demo]<br />
* [http://www.instructables.com/id/How-to-make-a-charlieplexed-LED-heart/ On Instructables]<br />
<br />
== Step-by-step Assembly Guide ==<br />
<br />
[http://www.flickr.com/photos/dcreeves2000/sets/72157640155673266/ Photos of assembly]<br />
<br />
== Source Code for firmware and 3D-printed case ==<br />
Github: https://github.com/rmd6502/charlie_heart<br />
<br />
Eagle files are in the Charlie directory<br />
<br />
== Parts list ==<br />
<table border="1" style="border:solid;"><br />
<th> Quantity</th><th> Description</th><th> Location</th><br />
<tr><td>1</td><td>ATTiny85</td><td>[http://things.hackmanhattan.com/559]</td></tr><br />
<tr><td>5</td><td>3Ω resistors</td><td>[http://things.hackmanhattan.com/562]</td></tr><br />
<tr><td>1</td><td>1kΩ resistor</td><td>[http://things.hackmanhattan.com/562]</td></tr><br />
<tr><td>1</td><td>.1 µF capacitor</td><td>[http://things.hackmanhattan.com/233]</td></tr><br />
<tr><td>20</td><td>SMD LEDs</td><td>[http://things.hackmanhattan.com/561]</td></tr><br />
<tr><td>1</td><td>P channel MOSFET</td><td></td><br />
<tr><td>1</td><td>Tactile NO SPST switch</td><td></td><br />
<tr><td>1</td><td>CR2032 battery holder</td><td>[http://things.hackmanhattan.com/176], or part number 270-009 at Radio Shack - I'll order more from Digikey</td></tr><br />
<tr><td>1</td><td>CR2032 battery</td><td>[http://things.hackmanhattan.com/88]</td></tr><br />
</table><br />
<br />
To program the firmware you'll need an [http://www.atmel.com/tools/avrdragon.aspx AVR Dragon], and the tiny [http://www.tag-connect.com/TC2030-IDC-NL-10 JST 6pin header]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40572014 Group Project2014-02-05T21:09:23Z<p>Rmd6502: /* One time pads */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
I like it - we could hang these all over the island. In fact, if I can get my attiny85 sound project working, we could use that as the codec, and use either wireless or let the string be a wire. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"<br />
… That's broken in half --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40562014 Group Project2014-02-05T21:04:55Z<p>Rmd6502: /* New take on old technology */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
I like it - we could hang these all over the island. In fact, if I can get my attiny85 sound project working, we could use that as the codec, and use either wireless or let the string be a wire. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]])<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40552014 Group Project2014-02-05T20:46:36Z<p>Rmd6502: /* Humans versus zombies */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern. --[[User:Rmd6502|rmd6502]] ([[User talk:Rmd6502|talk]]) 20:46, 5 February 2014 (UTC)<br />
<br />
(mg) This could get ugly :) It's a good idea for trying to get the entire attendee community involved, like at Figment, but maybe a bit much for MakerFaire? Also, how many would we have to make??<br />
<br />
(robby o) I like this idea as well...can we do diff projects for Makerfaire and Figment?<br />
<br />
50 is probably a good number. At Maker Faire it is an added benefit that we could sell them. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:33, 5 February 2014 (UTC)<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
(rmd)I like it - we could hang these all over the island<br />
<br />
(mg) I like both suggestions.<br />
<br />
(robby o): love it!<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
Throughput is not as important as being simple to explain. A typewriter also provides something to look at. It's ok if there's a line.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
(mg) Yeah, I think it's about time we built some of these. This would be a good group project. We could hack something like toy cars for bodies if you'd like.<br />
<br />
=== Printing Press ===<br />
<br />
A modern take on movable type. Slide in a sheet of paper, roll ink over an 8x8 (roughly) grid of 'pixels' made of rubber pads, and actuate the solenoids to reproduce a pixel pattern on the paper. With a satisfying 'clunk'.<br />
<br />
(robby o.): support this idea!<br />
<br />
I am strongly opposed to this idea because it would not only be very difficult to build, but it would take too much explanation to each person who walks up to it. --[[User:Guan|Guan]] ([[User talk:Guan|talk]]) 20:27, 5 February 2014 (UTC)<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
(mg) Doesn't sound like as much fun as the others.<br />
<br />
(robby o) I like this...maybe we can build an Enigma Machine replica? <br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40442014 Group Project2014-02-05T18:42:19Z<p>Rmd6502: /* Tin cans */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
(rmd) In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern.<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
(rmd)I like it - we could hang these all over the island<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40432014 Group Project2014-02-05T18:26:35Z<p>Rmd6502: /* IP over avian carriers implementation */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
(rmd) In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern.<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
(rmd) Drones!<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40422014 Group Project2014-02-05T18:26:07Z<p>Rmd6502: /* Typewriter ASCII art */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
(rmd) In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern.<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
I like this idea, except that it would of necessity be slow - we want to get a lot of throughput through our booth.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=2014_Group_Project&diff=40412014 Group Project2014-02-05T18:25:34Z<p>Rmd6502: /* Humans versus zombies */</p>
<hr />
<div>= Requirements/desiderata =<br />
<br />
* Minimal explanation for the audience<br />
* Easy to accomplish<br />
<br />
= Ideas =<br />
<br />
== Humans versus zombies ==<br />
<br />
Participants are issued badges that pin to clothing. Zombie badges broadcast an infrared signal (possibly only when a button is pushed). If a human badge receives that signal, the human is turned into a zombie.<br />
<br />
Badges have to be visible. You never know if someone is a zombie. Maybe there should be an incentive not to avoid anyone with a badge - perhaps you get a point if you make contact with another human.<br />
<br />
(rmd) In zombie mythology, it's usually pretty obvious who's a zombie and who isn't. I'd say have a distinctive red blink pattern for zombies, and then require a zombie to e.g. press a button for 2 seconds to "attack" a human. If the human notices the attack, she/he can turn away and/or run and the attack is unsuccessful. Else that human's badge beeps loudly and starts blinking the zombie pattern.<br />
<br />
== New take on old technology ==<br />
<br />
=== Tin cans ===<br />
<br />
Two high tech tin cans with microphones and speakers, that will only work if the string is taut.<br />
<br />
=== Typewriter ASCII art ===<br />
<br />
A webcam takes a photo. A typewriter style printer renders it as ASCII art.<br />
<br />
=== [http://www.ietf.org/rfc/rfc1149.txt IP over avian carriers] implementation ===<br />
<br />
Two nodes communicate with the full IP stack, using notes that are passed by something low tech. Pigeons will be too much hassle. Maybe toy cars?<br />
<br />
== Cryptography/security/NSA ==<br />
<br />
=== One time pads ===<br />
<br />
A hardware random number generator (based on [http://en.wikipedia.org/wiki/Avalanche_breakdown avalanche noise]) prints one time pads for free on thermal paper, that also includes a guide for encrypting using the one time pad. Probably using Base36 and XOR.<br />
<br />
Branding: "Unbreakable Crypto Stand"</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Charlieplexed_PWM_Heart&diff=4024Charlieplexed PWM Heart2014-01-27T21:27:55Z<p>Rmd6502: /* Parts list */</p>
<hr />
<div>== Demo ==<br />
* [File:https://dl.dropboxusercontent.com/u/10205003/VIDEO0005.mp4]<br />
* [https://docs.google.com/file/d/0ByQl1ZrtYxQuOXRvRXFicUV2V3M/edit Another demo]<br />
<br />
== Step-by-step Assembly Guide ==<br />
<br />
[http://www.flickr.com/photos/dcreeves2000/sets/72157640155673266/ Photos of assembly]<br />
<br />
== Source Code for firmware and 3D-printed case ==<br />
Github: https://github.com/rmd6502/charlie_heart<br />
<br />
Eagle files are in the Charlie directory<br />
<br />
== Parts list ==<br />
<table border="1" style="border:solid;"><br />
<th> Quantity</th><th> Description</th><th> Location</th><br />
<tr><td>1</td><td>ATTiny85</td><td>[http://things.hackmanhattan.com/559]</td></tr><br />
<tr><td>5</td><td>3Ω resistors</td><td>[http://things.hackmanhattan.com/562]</td></tr><br />
<tr><td>1</td><td>1kΩ resistor</td><td>[http://things.hackmanhattan.com/562]</td></tr><br />
<tr><td>1</td><td>.1 µF capacitor</td><td>[http://things.hackmanhattan.com/233]</td></tr><br />
<tr><td>20</td><td>SMD LEDs</td><td>[http://things.hackmanhattan.com/561]</td></tr><br />
<tr><td>1</td><td>P channel MOSFET</td><td></td><br />
<tr><td>1</td><td>Tactile NO SPST switch</td><td></td><br />
<tr><td>1</td><td>CR2032 battery holder</td><td>[http://things.hackmanhattan.com/176], or part number 270-009 at Radio Shack - I'll order more from Digikey</td></tr><br />
<tr><td>1</td><td>CR2032 battery</td><td>[http://things.hackmanhattan.com/88]</td></tr><br />
</table><br />
<br />
To program the firmware you'll need an [http://www.atmel.com/tools/avrdragon.aspx AVR Dragon], and the tiny [http://www.tag-connect.com/TC2030-IDC-NL-10 JST 6pin header]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Charlieplexed_PWM_Heart&diff=4023Charlieplexed PWM Heart2014-01-27T21:26:56Z<p>Rmd6502: /* Source Code for firmware and 3D-printed case */</p>
<hr />
<div>== Demo ==<br />
* [File:https://dl.dropboxusercontent.com/u/10205003/VIDEO0005.mp4]<br />
* [https://docs.google.com/file/d/0ByQl1ZrtYxQuOXRvRXFicUV2V3M/edit Another demo]<br />
<br />
== Step-by-step Assembly Guide ==<br />
<br />
[http://www.flickr.com/photos/dcreeves2000/sets/72157640155673266/ Photos of assembly]<br />
<br />
== Source Code for firmware and 3D-printed case ==<br />
Github: https://github.com/rmd6502/charlie_heart<br />
<br />
Eagle files are in the Charlie directory<br />
<br />
== Parts list ==<br />
<table border="1" style="border:solid;"><br />
<th> Quantity</th><th> Description</th><th> Location</th><br />
<tr><td>1</td><td>ATTiny85</td><td>[http://things.hackmanhattan.com/559]</td></tr><br />
<tr><td>5</td><td>3Ω resistors</td><td>[http://things.hackmanhattan.com/562]</td></tr><br />
<tr><td>1</td><td>.1 µF capacitor</td><td>[http://things.hackmanhattan.com/233]</td></tr><br />
<tr><td>20</td><td>SMD LEDs</td><td>[http://things.hackmanhattan.com/561]</td></tr><br />
<tr><td>1</td><td>P channel MOSFET</td><td></td><br />
<tr><td>1</td><td>CR2032 battery holder</td><td>[http://things.hackmanhattan.com/176], or part number 270-009 at Radio Shack - I'll order more from Digikey</td></tr><br />
<tr><td>1</td><td>CR2032 battery</td><td>[http://things.hackmanhattan.com/88]</td></tr><br />
</table><br />
<br />
To program the firmware you'll need an [http://www.atmel.com/tools/avrdragon.aspx AVR Dragon], and the tiny [http://www.tag-connect.com/TC2030-IDC-NL-10 JST 6pin header]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Meeting_2013-12-03&diff=3889Meeting 2013-12-032013-11-19T18:11:47Z<p>Rmd6502: /* Consensus Agenda */</p>
<hr />
<div>= Consensus Agenda =<br />
<br />
* Purchase and installation of a thick curtain to be installed between the machine shop area and the large common area. This will provide some noise separation and safety when people are working on projects while other events are going on.<br />
<br />
Cost Estimate: $500<br />
Proposed by: Robert Diamond (rmd6502)<br />
<br />
= New Business =<br />
<br />
== Amendment to Bylaws ==<br />
<br />
=== Order of voting ===<br />
<br />
[[User:Guan|Guan]] will propose, for unanimous consent, that Proposals 1 and 2 are considered as a block, and Proposals 3 and 4 are considered as a block.<br />
<br />
=== Proposal 1: Clarification on when annual meetings are held ===<br />
<br />
Article 3, Section 1 (titled "Annual Meeting") is amended by stricking the entire section and replaced with:<br />
<br />
<blockquote>The board shall call the annual meeting of members in accordance with Sections 603 and 605 of the Not-for-Profit Corporation Law. The meeting shall be held in November or December.</blockquote><br />
<br />
=== Proposal 2: Clarification on notice of meetings ===<br />
<br />
Article 3, Section 7 is added:<br />
<br />
<blockquote><p>It is the policy of the corporation that an email sent to the corporation's member email list as well as a member's personal email address, if one is on file with the corporation, shall constitute personal notice of meetings to that member within the meaning of Section 605 of the Not-for-Profit Corporation Law, and that personal notice is the only means of notice that is ordinarily employed.</p><p>A member may opt out of personal notice and instead receive notice of meetings by first or second class mail. A member who wishes to opt out shall notify the corporation of the member's mailing address and any change of address. The opt out shall be effective for meetings held 20 days or later after the corporation has received the member's notice.</p></blockquote><br />
<br />
=== Proposal 3: Even more relaxed quorum requirements ===<br />
<br />
Article 3, Section 6 is amended by adding the following after the first paragraph:<br />
<br />
<blockquote><p>For the purposes only of unanimous decisions on matters that were announced with sufficient notice in the call to the meeting, including decisions made with no opposing votes, regular meetings and annual meetings held at the corporation's premises shall be considered quorate notwithstanding the number of members present.</p></blockquote><br />
<br />
=== Proposal 4: Quorum not required for elections at annual meetings ===<br />
<br />
Article 3, Section 6 is amended by adding the following after the last paragraph:<br />
<br />
<blockquote><p>A quorum shall not be necessary to carry out elections at regular annual meetings held at the corporation's premises and called in accordance with the Not-for-Profit Corporation Law and this article.</p></blockquote><br />
<br />
Note: A quorum would still be required to carry out elections outside annual meetings.<br />
<br />
=== Proposal 5: Members are responsible for satisfying the conditions of membership ===<br />
<br />
Article 2, Section 7 is amended by adding the following:<br />
<br />
<blockquote><p>Each member is solely responsible for maintaining his or her membership in good standing, including observing these by-laws and the rules of the corporation and the payment of dues, fees, or assessments. No act or omission by the corporation shall prejudice the power of the corporation to terminate membership because of a member's failure to pay dues, fees, or assessments. No act or omission by the corporation shall prejudice the power of the corporation to terminate membership for any other reason, except by a decision of the members.</p></blockquote><br />
<br />
== Election of Officers == <br />
<br />
=== President ===<br />
<br />
(Candidates - Justin Levinson, )<br />
<br />
=== Treasurer === <br />
<br />
(Candidates - Guan Yang, )<br />
<br />
=== Secretary ===<br />
<br />
(Candidates - Robert (Robby) O'Connor ,)<br />
<br />
=== Director-at-Large===<br />
<br />
(Candidates - David Reeves, )<br />
<br />
== Sponsored Members Induction ==<br />
<br />
= Member Reports =<br />
<br />
=== President's report ===<br />
<br />
=== Treasurer's report ===<br />
<br />
=== Secretary's report ===<br />
<br />
=== Director-At-Large's report ===<br />
<br />
<br />
<br />
== Member Reports ==<br />
<br />
= Roll Call =<br />
<br />
In Person: <br />
<br />
Over IRC:<br />
<br />
= Adjournment =<br />
[[Category:Meetings]]</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Power&diff=3888Power2013-11-18T16:07:13Z<p>Rmd6502: /* Flyback */</p>
<hr />
<div>= Batteries =<br />
<br />
In general, each battery chemistry has a nominal voltage (actually a curve of voltage over discharge). For example, alkaline batteries are 1.5V, NiMH is 1.2V, lithium ion is 3.7V, etc.<br />
<br />
Capacity is usually indicated in amp-hours. A 1 Ah battery can source 1A for one hour. Smaller capacities are indicated in mAh.<br />
<br />
Capacity is sometimes indicated in watt-hours, especially for chemistries with dramatic voltage drops during discharge.<br />
<br />
Cells can usually be made larger, for more capacity at a given voltage. For example, an alkaline D cell is simply a larger version of an AAA cell, with very similar electrical characteristics apart from capacity.<br />
<br />
Cells can be paralleled to get more capacity, or placed in series for greater voltage.<br />
<br />
Due to the internal characteristics of some battery chemistries, putting cells in parallel or series should be done with great care to avoid overloading individual cells. This is done either using specialized ICs or with careful binning and balancing of cells.<br />
<br />
A primary battery cannot be recharged. A secondary battery can be recharged.<br />
<br />
== Alkaline ==<br />
<br />
== Nickel metal hydride ==<br />
<br />
== Lithium primary ==<br />
<br />
=== Coin cells ===<br />
<br />
CR2032 coin cells (20mm diameter, 3.2mm thickness) are common in blinkies and small battery powered transceivers. They are very bad for most of the purposes we put them to because of a very high internal resistance (up to 30 ohm). The internal resistance is high enough that most LEDs can be connected to them without a current limiting resistor.<br />
<br />
They are only rated for about 0.2mA sustained current draw, and cannot reliably source more than 10-15 mA.<br />
<br />
[[Bluetooth Low Energy]] has apparently been engineered to work well with CR2032. The receivers typically draw 10-15mA and transmitters a bit less, but BLE has very low duty cycles and parts such as [[nRF51822]] can get away with being powered with a CR2032.<br />
<br />
CR2032 cells are rated for 210mAh, but only at less than a mA current.<br />
<br />
CR2016 are half the height and half the capacity.<br />
<br />
=== Lithium thionyl chloride (Li-SOCl₂) ===<br />
<br />
Li-SOCl₂ have very low self discharge and very high energy density. They also have very low voltage drops, staying at 3.6V through almost all of the discharge cycle. A D cell typically has a capacity of 20 Ah.<br />
<br />
Li-SOCl₂ are used in [http://www.ifixit.com/Teardown/Tracking+Device+Teardown/5250 FBI tracking devices].<br />
<br />
Beware that these batteries are considered a class 3 hazmat - they don't leak or explode often, but if they do the contents are extremely toxic.<br />
<br />
== Lithium ion/lithium polymer (secondary) ==<br />
<br />
These are the most common kind of lithium cells for electronics. They charge at 4.2V and discharge all the way to 2.75V. That makes them a challenge to use with most ICs that can't go above 3.6V. One easy and cheap strategy is to operate the circuit at 2.5V, supplied by a buck converter. 1.8V is also viable for some circuits: most digital and RF ICs can operate at 1.8V, but many sensors can't.<br />
<br />
EDIT 11/18/2013 -Konsgn<br />
1)While lithium cells can go to 2.75V, you should not let them fall below 3 Volts per cell. Some applications even use a cutoff of 3.3v. <br />
2)Individual cells can be scavenged from many different things like laptop batteries or R/C battery packs. If you have a bad lithium battery pack, it is usually the fault of one of the cells. Re-purposing the good cells from a bad pack is possible. <br />
3)Another easy way to use them easily is by having a LDO 3.3v regulator and powering your microcontrollers at 3.3V.<br />
4)The chemistry will ignite if brought to 60 Celsius. This will cause the rest of the pack to ignite in something referred to as thermal-runaway.<br />
<br />
Charging lithium secondary cells should be done with a specialized battery charging IC. They are charged with constant current up to a certain voltage, then constant voltage. This is known as Constant Current Constant Voltage or CCCV charging. Charging at 0.5C is usually safe; higher charge rates require monitoring battery temperature through a thermistor built into the lithium cell.<br />
<br />
Note that if you use a battery charger that has auto termination, you should be very careful about connecting the load directly to the battery while the charger is powered: the load will appear as the battery charging, which means that the charge will never terminate. There are several solutions to this problem. Some battery charging ICs have a separate pin for the load. There is also a simple circuit with a P-channel MOSFET and a Zener diode that can turn off current from battery to load while an external power supply is connected.<br />
<br />
Lithium ion/polymer batteries are among the most dangerous electronic components a hobbyist will encounter, especially individual soft cells without hard packaging. Treat them with great care. Do not put cells in parallel or series yourself. Do not expose to excessive forces.<br />
<br />
== Lithium iron phosphate (LiFePO₄) ==<br />
<br />
LiFePO₄ are much safer than lithium ion/polymer, with roughly 2/3 the energy density. They are charged in a similar way. LiFePO₄ cells discharge at 3V, through almost the full discharge cycle. Because of their voltage, they can directly power most ICs without a regulator.<br />
<br />
In New York, you will often see LiFePO₄ battery packs on delivery people's electric bicycles.<br />
<br />
= Regulators =<br />
<br />
A regulator maintains a constant voltage (or in the case of a current regulator, a current voltage).<br />
<br />
You will sometimes encounter unregulated power. For example, an unregulated 12VDC regulator fed with 120V AC power might consist of a 10:1 transformer followed by a diode bridge rectifier and decoupling capacitors. The output voltage will be approximately 12V, but will vary with the input voltage and other factors. It is a cheaper way of supplying power if you only need approximately, but not exactly, 12V, for example because you know that the voltage will be further regulated to lower voltages.<br />
<br />
A 5V DC regulator will attempt to maintain its output voltage at 5V and a properly functioning one will do so as long as conditions remain within its specification. Most regulators specify a maximum current. For example, the popular LM7805 linear regulator will only work well up to 1.5A. If the load is well above the specified maximum load, the regulator may no longer be able to maintain regulation, and its behavior is unspecified. Typically it will be able to supply higher currents at a lower, unregulated, voltage. In rarer circumstances, it will fail completely.<br />
<br />
== Linear regulators ==<br />
<br />
<br />
<br />
== Linear regulator replacement switching modules ==<br />
<br />
== Buck, boost and buck/boost ICs ==<br />
<br />
Robert will volunteer to teach an ''advanced'' class in buck, boost, buck/boost, and sepic theory, especially if Guan will cohost.<br />
<br />
The theory for all is the same: utilize reactive elements and rapid changes in current or voltage to exchange current for voltage at fairly high efficiency. This works because these components output current or voltage proportional to the rate of change of voltage or current in, so modifying the duty cycle of a PWM input will control the output.<br />
<br />
Around that core are rectifiers and filters to turn the pulsed signal to smooth DC, and drivers to increase efficiency.<br />
<br />
== Flyback ==<br />
<br />
These are similar to the switching regulators above, with the addition of a flyback transformer. The flyback transformer adds isolation, which is crucial for safety when using mains-powered circuits. Because the transformers can have different numbers of windings on each side, a greater range of voltages can be realized.<br />
<br />
= Solar panels =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Power&diff=3886Power2013-11-18T15:58:01Z<p>Rmd6502: /* Lithium thionyl chloride (Li-SOCl₂) */</p>
<hr />
<div>= Batteries =<br />
<br />
In general, each battery chemistry has a nominal voltage (actually a curve of voltage over discharge). For example, alkaline batteries are 1.5V, NiMH is 1.2V, lithium ion is 3.7V, etc.<br />
<br />
Capacity is usually indicated in amp-hours. A 1 Ah battery can source 1A for one hour. Smaller capacities are indicated in mAh.<br />
<br />
Capacity is sometimes indicated in watt-hours, especially for chemistries with dramatic voltage drops during discharge.<br />
<br />
Cells can usually be made larger, for more capacity at a given voltage. For example, an alkaline D cell is simply a larger version of an AAA cell, with very similar electrical characteristics apart from capacity.<br />
<br />
Cells can be paralleled to get more capacity, or placed in series for greater voltage.<br />
<br />
Due to the internal characteristics of some battery chemistries, putting cells in parallel or series should be done with great care to avoid overloading individual cells. This is done either using specialized ICs or with careful binning and balancing of cells.<br />
<br />
A primary battery cannot be recharged. A secondary battery can be recharged.<br />
<br />
== Alkaline ==<br />
<br />
== Nickel metal hydride ==<br />
<br />
== Lithium primary ==<br />
<br />
=== Coin cells ===<br />
<br />
CR2032 coin cells (20mm diameter, 3.2mm thickness) are common in blinkies and small battery powered transceivers. They are very bad for most of the purposes we put them to because of a very high internal resistance (up to 30 ohm). The internal resistance is high enough that most LEDs can be connected to them without a current limiting resistor.<br />
<br />
They are only rated for about 0.2mA sustained current draw, and cannot reliably source more than 10-15 mA.<br />
<br />
[[Bluetooth Low Energy]] has apparently been engineered to work well with CR2032. The receivers typically draw 10-15mA and transmitters a bit less, but BLE has very low duty cycles and parts such as [[nRF51822]] can get away with being powered with a CR2032.<br />
<br />
CR2032 cells are rated for 210mAh, but only at less than a mA current.<br />
<br />
CR2016 are half the height and half the capacity.<br />
<br />
=== Lithium thionyl chloride (Li-SOCl₂) ===<br />
<br />
Li-SOCl₂ have very low self discharge and very high energy density. They also have very low voltage drops, staying at 3.6V through almost all of the discharge cycle. A D cell typically has a capacity of 20 Ah.<br />
<br />
Li-SOCl₂ are used in [http://www.ifixit.com/Teardown/Tracking+Device+Teardown/5250 FBI tracking devices].<br />
<br />
Beware that these batteries are considered a class 3 hazmat - they don't leak or explode often, but if they do the contents are extremely toxic.<br />
<br />
== Lithium ion/lithium polymer (secondary) ==<br />
<br />
These are the most common kind of lithium cells for electronics. They charge at 4.2V and discharge all the way to 2.75V. That makes them a challenge to use with most ICs that can't go above 3.6V. One easy and cheap strategy is to operate the circuit at 2.5V, supplied by a buck converter. 1.8V is also viable for some circuits: most digital and RF ICs can operate at 1.8V, but many sensors can't.<br />
<br />
Charging lithium secondary cells should be done with a specialized battery charging IC. They are charged with constant current up to a certain voltage, then constant voltage. This is known as Constant Current Constant Voltage or CCCV charging. Charging at 0.5C is usually safe; higher charge rates require monitoring battery temperature through a thermistor built into the lithium cell.<br />
<br />
Note that if you use a battery charger that has auto termination, you should be very careful about connecting the load directly to the battery while the charger is powered: the load will appear as the battery charging, which means that the charge will never terminate. There are several solutions to this problem. Some battery charging ICs have a separate pin for the load. There is also a simple circuit with a P-channel MOSFET and a Zener diode that can turn off current from battery to load while an external power supply is connected.<br />
<br />
Lithium ion/polymer batteries are among the most dangerous electronic components a hobbyist will encounter, especially individual soft cells without hard packaging. Treat them with great care. Do not put cells in parallel or series yourself. Do not expose to excessive forces.<br />
<br />
== Lithium iron phosphate (LiFePO₄) ==<br />
<br />
LiFePO₄ are much safer than lithium ion/polymer, with roughly 2/3 the energy density. They are charged in a similar way. LiFePO₄ cells discharge at 3V, through almost the full discharge cycle. Because of their voltage, they can directly power most ICs without a regulator.<br />
<br />
In New York, you will often see LiFePO₄ battery packs on delivery people's electric bicycles.<br />
<br />
= Regulators =<br />
<br />
A regulator maintains a constant voltage (or in the case of a current regulator, a current voltage).<br />
<br />
You will sometimes encounter unregulated power. For example, an unregulated 12VDC regulator fed with 120V AC power might consist of a 10:1 transformer followed by a diode bridge rectifier and decoupling capacitors. The output voltage will be approximately 12V, but will vary with the input voltage and other factors. It is a cheaper way of supplying power if you only need approximately, but not exactly, 12V, for example because you know that the voltage will be further regulated to lower voltages.<br />
<br />
A 5V DC regulator will attempt to maintain its output voltage at 5V and a properly functioning one will do so as long as conditions remain within its specification. Most regulators specify a maximum current. For example, the popular LM7805 linear regulator will only work well up to 1.5A. If the load is well above the specified maximum load, the regulator may no longer be able to maintain regulation, and its behavior is unspecified. Typically it will be able to supply higher currents at a lower, unregulated, voltage. In rarer circumstances, it will fail completely.<br />
<br />
== Linear regulators ==<br />
<br />
<br />
<br />
== Linear regulator replacement switching modules ==<br />
<br />
== Buck, boost and buck/boost ICs ==<br />
<br />
Robert will volunteer to teach an ''advanced'' class in buck, boost, buck/boost, and sepic theory, especially if Guan will cohost.<br />
<br />
The theory for all is the same: utilize reactive elements and rapid changes in current or voltage to exchange current for voltage at fairly high efficiency. This works because these components output current or voltage proportional to the rate of change of voltage or current in, so modifying the duty cycle of a PWM input will control the output.<br />
<br />
Around that core are rectifiers and filters to turn the pulsed signal to smooth DC, and drivers to increase efficiency.<br />
<br />
== Flyback ==<br />
<br />
= Solar panels =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Power&diff=3885Power2013-11-18T15:56:23Z<p>Rmd6502: /* Buck, boost and buck/boost ICs */</p>
<hr />
<div>= Batteries =<br />
<br />
In general, each battery chemistry has a nominal voltage (actually a curve of voltage over discharge). For example, alkaline batteries are 1.5V, NiMH is 1.2V, lithium ion is 3.7V, etc.<br />
<br />
Capacity is usually indicated in amp-hours. A 1 Ah battery can source 1A for one hour. Smaller capacities are indicated in mAh.<br />
<br />
Capacity is sometimes indicated in watt-hours, especially for chemistries with dramatic voltage drops during discharge.<br />
<br />
Cells can usually be made larger, for more capacity at a given voltage. For example, an alkaline D cell is simply a larger version of an AAA cell, with very similar electrical characteristics apart from capacity.<br />
<br />
Cells can be paralleled to get more capacity, or placed in series for greater voltage.<br />
<br />
Due to the internal characteristics of some battery chemistries, putting cells in parallel or series should be done with great care to avoid overloading individual cells. This is done either using specialized ICs or with careful binning and balancing of cells.<br />
<br />
A primary battery cannot be recharged. A secondary battery can be recharged.<br />
<br />
== Alkaline ==<br />
<br />
== Nickel metal hydride ==<br />
<br />
== Lithium primary ==<br />
<br />
=== Coin cells ===<br />
<br />
CR2032 coin cells (20mm diameter, 3.2mm thickness) are common in blinkies and small battery powered transceivers. They are very bad for most of the purposes we put them to because of a very high internal resistance (up to 30 ohm). The internal resistance is high enough that most LEDs can be connected to them without a current limiting resistor.<br />
<br />
They are only rated for about 0.2mA sustained current draw, and cannot reliably source more than 10-15 mA.<br />
<br />
[[Bluetooth Low Energy]] has apparently been engineered to work well with CR2032. The receivers typically draw 10-15mA and transmitters a bit less, but BLE has very low duty cycles and parts such as [[nRF51822]] can get away with being powered with a CR2032.<br />
<br />
CR2032 cells are rated for 210mAh, but only at less than a mA current.<br />
<br />
CR2016 are half the height and half the capacity.<br />
<br />
=== Lithium thionyl chloride (Li-SOCl₂) ===<br />
<br />
Li-SOCl₂ have very low self discharge and very high energy density. They also have very low voltage drops, staying at 3.6V through almost all of the discharge cycle. A D cell typically has a capacity of 20 Ah.<br />
<br />
Li-SOCl₂ are used in [http://www.ifixit.com/Teardown/Tracking+Device+Teardown/5250 FBI tracking devices].<br />
<br />
== Lithium ion/lithium polymer (secondary) ==<br />
<br />
These are the most common kind of lithium cells for electronics. They charge at 4.2V and discharge all the way to 2.75V. That makes them a challenge to use with most ICs that can't go above 3.6V. One easy and cheap strategy is to operate the circuit at 2.5V, supplied by a buck converter. 1.8V is also viable for some circuits: most digital and RF ICs can operate at 1.8V, but many sensors can't.<br />
<br />
Charging lithium secondary cells should be done with a specialized battery charging IC. They are charged with constant current up to a certain voltage, then constant voltage. This is known as Constant Current Constant Voltage or CCCV charging. Charging at 0.5C is usually safe; higher charge rates require monitoring battery temperature through a thermistor built into the lithium cell.<br />
<br />
Note that if you use a battery charger that has auto termination, you should be very careful about connecting the load directly to the battery while the charger is powered: the load will appear as the battery charging, which means that the charge will never terminate. There are several solutions to this problem. Some battery charging ICs have a separate pin for the load. There is also a simple circuit with a P-channel MOSFET and a Zener diode that can turn off current from battery to load while an external power supply is connected.<br />
<br />
Lithium ion/polymer batteries are among the most dangerous electronic components a hobbyist will encounter, especially individual soft cells without hard packaging. Treat them with great care. Do not put cells in parallel or series yourself. Do not expose to excessive forces.<br />
<br />
== Lithium iron phosphate (LiFePO₄) ==<br />
<br />
LiFePO₄ are much safer than lithium ion/polymer, with roughly 2/3 the energy density. They are charged in a similar way. LiFePO₄ cells discharge at 3V, through almost the full discharge cycle. Because of their voltage, they can directly power most ICs without a regulator.<br />
<br />
In New York, you will often see LiFePO₄ battery packs on delivery people's electric bicycles.<br />
<br />
= Regulators =<br />
<br />
A regulator maintains a constant voltage (or in the case of a current regulator, a current voltage).<br />
<br />
You will sometimes encounter unregulated power. For example, an unregulated 12VDC regulator fed with 120V AC power might consist of a 10:1 transformer followed by a diode bridge rectifier and decoupling capacitors. The output voltage will be approximately 12V, but will vary with the input voltage and other factors. It is a cheaper way of supplying power if you only need approximately, but not exactly, 12V, for example because you know that the voltage will be further regulated to lower voltages.<br />
<br />
A 5V DC regulator will attempt to maintain its output voltage at 5V and a properly functioning one will do so as long as conditions remain within its specification. Most regulators specify a maximum current. For example, the popular LM7805 linear regulator will only work well up to 1.5A. If the load is well above the specified maximum load, the regulator may no longer be able to maintain regulation, and its behavior is unspecified. Typically it will be able to supply higher currents at a lower, unregulated, voltage. In rarer circumstances, it will fail completely.<br />
<br />
== Linear regulators ==<br />
<br />
<br />
<br />
== Linear regulator replacement switching modules ==<br />
<br />
== Buck, boost and buck/boost ICs ==<br />
<br />
Robert will volunteer to teach an ''advanced'' class in buck, boost, buck/boost, and sepic theory, especially if Guan will cohost.<br />
<br />
The theory for all is the same: utilize reactive elements and rapid changes in current or voltage to exchange current for voltage at fairly high efficiency. This works because these components output current or voltage proportional to the rate of change of voltage or current in, so modifying the duty cycle of a PWM input will control the output.<br />
<br />
Around that core are rectifiers and filters to turn the pulsed signal to smooth DC, and drivers to increase efficiency.<br />
<br />
== Flyback ==<br />
<br />
= Solar panels =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=Power&diff=3884Power2013-11-18T15:55:43Z<p>Rmd6502: /* Buck, boost and buck/boost ICs */</p>
<hr />
<div>= Batteries =<br />
<br />
In general, each battery chemistry has a nominal voltage (actually a curve of voltage over discharge). For example, alkaline batteries are 1.5V, NiMH is 1.2V, lithium ion is 3.7V, etc.<br />
<br />
Capacity is usually indicated in amp-hours. A 1 Ah battery can source 1A for one hour. Smaller capacities are indicated in mAh.<br />
<br />
Capacity is sometimes indicated in watt-hours, especially for chemistries with dramatic voltage drops during discharge.<br />
<br />
Cells can usually be made larger, for more capacity at a given voltage. For example, an alkaline D cell is simply a larger version of an AAA cell, with very similar electrical characteristics apart from capacity.<br />
<br />
Cells can be paralleled to get more capacity, or placed in series for greater voltage.<br />
<br />
Due to the internal characteristics of some battery chemistries, putting cells in parallel or series should be done with great care to avoid overloading individual cells. This is done either using specialized ICs or with careful binning and balancing of cells.<br />
<br />
A primary battery cannot be recharged. A secondary battery can be recharged.<br />
<br />
== Alkaline ==<br />
<br />
== Nickel metal hydride ==<br />
<br />
== Lithium primary ==<br />
<br />
=== Coin cells ===<br />
<br />
CR2032 coin cells (20mm diameter, 3.2mm thickness) are common in blinkies and small battery powered transceivers. They are very bad for most of the purposes we put them to because of a very high internal resistance (up to 30 ohm). The internal resistance is high enough that most LEDs can be connected to them without a current limiting resistor.<br />
<br />
They are only rated for about 0.2mA sustained current draw, and cannot reliably source more than 10-15 mA.<br />
<br />
[[Bluetooth Low Energy]] has apparently been engineered to work well with CR2032. The receivers typically draw 10-15mA and transmitters a bit less, but BLE has very low duty cycles and parts such as [[nRF51822]] can get away with being powered with a CR2032.<br />
<br />
CR2032 cells are rated for 210mAh, but only at less than a mA current.<br />
<br />
CR2016 are half the height and half the capacity.<br />
<br />
=== Lithium thionyl chloride (Li-SOCl₂) ===<br />
<br />
Li-SOCl₂ have very low self discharge and very high energy density. They also have very low voltage drops, staying at 3.6V through almost all of the discharge cycle. A D cell typically has a capacity of 20 Ah.<br />
<br />
Li-SOCl₂ are used in [http://www.ifixit.com/Teardown/Tracking+Device+Teardown/5250 FBI tracking devices].<br />
<br />
== Lithium ion/lithium polymer (secondary) ==<br />
<br />
These are the most common kind of lithium cells for electronics. They charge at 4.2V and discharge all the way to 2.75V. That makes them a challenge to use with most ICs that can't go above 3.6V. One easy and cheap strategy is to operate the circuit at 2.5V, supplied by a buck converter. 1.8V is also viable for some circuits: most digital and RF ICs can operate at 1.8V, but many sensors can't.<br />
<br />
Charging lithium secondary cells should be done with a specialized battery charging IC. They are charged with constant current up to a certain voltage, then constant voltage. This is known as Constant Current Constant Voltage or CCCV charging. Charging at 0.5C is usually safe; higher charge rates require monitoring battery temperature through a thermistor built into the lithium cell.<br />
<br />
Note that if you use a battery charger that has auto termination, you should be very careful about connecting the load directly to the battery while the charger is powered: the load will appear as the battery charging, which means that the charge will never terminate. There are several solutions to this problem. Some battery charging ICs have a separate pin for the load. There is also a simple circuit with a P-channel MOSFET and a Zener diode that can turn off current from battery to load while an external power supply is connected.<br />
<br />
Lithium ion/polymer batteries are among the most dangerous electronic components a hobbyist will encounter, especially individual soft cells without hard packaging. Treat them with great care. Do not put cells in parallel or series yourself. Do not expose to excessive forces.<br />
<br />
== Lithium iron phosphate (LiFePO₄) ==<br />
<br />
LiFePO₄ are much safer than lithium ion/polymer, with roughly 2/3 the energy density. They are charged in a similar way. LiFePO₄ cells discharge at 3V, through almost the full discharge cycle. Because of their voltage, they can directly power most ICs without a regulator.<br />
<br />
In New York, you will often see LiFePO₄ battery packs on delivery people's electric bicycles.<br />
<br />
= Regulators =<br />
<br />
A regulator maintains a constant voltage (or in the case of a current regulator, a current voltage).<br />
<br />
You will sometimes encounter unregulated power. For example, an unregulated 12VDC regulator fed with 120V AC power might consist of a 10:1 transformer followed by a diode bridge rectifier and decoupling capacitors. The output voltage will be approximately 12V, but will vary with the input voltage and other factors. It is a cheaper way of supplying power if you only need approximately, but not exactly, 12V, for example because you know that the voltage will be further regulated to lower voltages.<br />
<br />
A 5V DC regulator will attempt to maintain its output voltage at 5V and a properly functioning one will do so as long as conditions remain within its specification. Most regulators specify a maximum current. For example, the popular LM7805 linear regulator will only work well up to 1.5A. If the load is well above the specified maximum load, the regulator may no longer be able to maintain regulation, and its behavior is unspecified. Typically it will be able to supply higher currents at a lower, unregulated, voltage. In rarer circumstances, it will fail completely.<br />
<br />
== Linear regulators ==<br />
<br />
<br />
<br />
== Linear regulator replacement switching modules ==<br />
<br />
== Buck, boost and buck/boost ICs ==<br />
<br />
Robert will volunteer to teach an *advanced* class in buck, boost, buck/boost, and sepic theory, especially if Guan will cohost.<br />
<br />
The theory for all is the same: utilize reactive elements and rapid changes in current or voltage to exchange current for voltage at fairly high efficiency. This works because these components output current or voltage proportional to the rate of change of voltage or current in, so modifying the duty cycle of a PWM input will control the output.<br />
<br />
Around that core are rectifiers and filters to turn the pulsed signal to smooth DC, and drivers to increase efficiency.<br />
<br />
== Flyback ==<br />
<br />
= Solar panels =</div>Rmd6502https://wiki.hackmanhattan.com/index.php?title=User:Rmd6502&diff=3762User:Rmd65022013-10-17T00:54:45Z<p>Rmd6502: /* Robert Diamond */</p>
<hr />
<div>== Robert Diamond ==<br />
<br />
[[File:rob_bot.jpg]]<br />
<br />
Mobile Software Engineer by day<br />
<br />
Master Geek at Hack Manhattan and Alpha One Labs<br />
<br />
Reachable at rmd6502@gmail.com<br />
<br />
== Current Projects ==<br />
* [[Nixie Tube Calculator]]<br />
* Arduino-based [[line following robot]]<br />
* [http://en.wikipedia.org/wiki/Charlieplexing Charlieplexed] [[led bracelet]]<br />
* [http://www.neurosky.com Brainwave] controlled [[slot cars]]<br />
* [[π r no longer ²]]</div>Rmd6502