Saturday, August 16, 2014

The miniaturized sunbox is a wrist watch

The smart watch is a watch that integrates a motion based electricity generator and several display, audio DSP, video DSP microcontrollers microcontrollers stacked vertically on a watch-like power system using a highly specialized lithium-ion battery. These microcontrollers all have an independent wireless interface device that they use to communicate between each other, but encased in appropriately shielded Gaussian enclosure such that they comply with local FCC regulations.
 
Each microcontroller is designed to interoperate independently of the other microcontrollers as a service, creating a modular and expandable design that can be easily modified to include new features.
 
Each controller incorporates a momentum-based rotary device that generates electricity through rapid motion of the device as well as a small integrated band on either side of the display for accumulating solar energy.
 
The watch has a 1 cm x 1 cm display that is a touchscreen. It integrates with a head mounted display wirelessly over a Bluetooth or similar connection. It has two buttons on the side that are abstracted as mouse clicks to correspond to the trackball touchscreen.
 
Although I think really deserves the partnership on this one
 
This device incorporates a proprietary low-powered design architecture and toolchain using specialized instructions incorporated into the program automatically to save power.
 
Under Chinese patent law, it could be replicated, but not marketed in the USA without a partnership.
 
 
Expandable features include
 
An integrated video camera for video chat and playback on the device.
 
An integrated projector for display.
 
Integrated display with a nearby wireless television device.

I would love to partner with somebody like or to productize this invention
 
Or possibly give up and be acquired by for fabrication
 
Patent pending "GMS Smart Watch"
 
It is much like the watches in Dick Tracy.






UPDATE(s):


User stories in development.


As an astute reader probably guessed, this device wishes to employ RF energy harvesting technology. Its special capacitor design it has in common with the sunbox is key in this capacity or role.





The design will incorporate an emulated animation of a standard watch face that makes it appear to be a standard watch that is backlit at night when it is not in use.




The design shall incorporate a rotary style telephone dialing system in addition to the 9-key approach.




The device shall support normal music playback through headphones or through a Bluetooth headset using the same hardware as telephony.


The device employs a clockwork mechanism to switch a cathode tube ray from projecting a reverse image onto an opaque, curved spherical screen located inside of the device to projecting onto an arbitrary surface.  This clockwork mechanism is built directly into the integrated circuit.


The device employs a rotary linkage to a small electric motor and capacitor that allows it to charge a lithium-ion battery.




A provisional patent for this design, as well as an exploratory patent for a design that is miniaturized to a ring is being prepared and may already be in shipment by the time you read this.

























Wednesday, August 6, 2014

For the perplexed




Nicholas Hall is well known by an alias "Damius" which is a hidden representation of his last name he has used for over 16 years in internet relay chat communities and represents a Hellenized form of wordplay and is a DBA alternative to Gaius Municipal Services. It also has roots in ancient Iranian languages and is seen as an important name to Nicholas Hall in his individual, esoteric and very unique cultural belief system. In English, it pronounced A as in "Day", followed by "me", followed by "us." Its pronunciation may vary in Hellenistic, Semitic and Aryan languages. It is usually used exclusively as a nickname to those close to Nicholas Hall such as family members, almost always without the "-us", simply as "day-mee."

Nick HATES cults, and has a personal vendetta to destroy all cults. As a matter of course in this profession, he studies them intensively. He is a firm believer in freedom of religion and believes people should be free from criminal religious manipulation of any kind, especially when it involves forcing people into joining using things such as threats or deception. He studies theology to distinguish cults from the many diverse legitimate religions of the world and believes in the unity of the human spirit.

Some of Nick's forebears were European crusaders and members of religious orders. He does not endorse this activity but is interested in its history.

Gaius Municipal Services takes its "Gaius" from "Gaius Julius Caesar," a flawed historical figure who laid a lot of pipe. It's cognate to the word Gaia for Earth but in common Latin means something like "List." In its acronym form, "GMS" is pronounced as "Grams," with the intended meaning of micrograms or milligrams.


Nicholas Hall is an amateur population geneticist and bioinformatician to the delight and detriment of many in the scientific community. He has forensically verified his own haplogroup and origin independently using scientific research at least as far back as the middle of the 19th century and in some branches as far back as the 11th. He wishes to succeed so that he may support his ever-expanding and ever-aging family, as well as over-determine the story of their origin on planet Earth. He is Y-STR I2b1* and mtDNA J1b1a.

His academic interests include lambda calculus, medical imaging, optics and inorganic chemistry.

He also wishes to employ some local physical and cultural anthropologists to study Ohlone phylogeny in the San Francisco Bay Area before development destroys thousands of years of human history.

This is more information about Nick than necessary for SUNBOX but now nobody can say he has not disclosed everything.

Manifestos, rigidity of software processes and fluid creativity


Stop cramping my style, boss

We've all been there. The boss is demanding we follow a rigid software process and all we want to do is prototype a solution that demonstrates a more profound understanding of the problem then another proposed solution. 

Younger software engineers who show a great deal of aptitude often fall victim to this type of thinking, because for tasks that are beneath the scope of a few weeks of work, they are completely correct. 

If your task granularity and project load is incredibly low, say limited to homework programming assignments, you can absolutely attack the problems with an unstructured process such as rapid prototyping or just hack away.

However, I think it is actually beneficial for students, particularly for those seeking to join an embedded development community, to understand the kind of software process used by real hardcore engineering shops that deliver world-acclaimed products that save lives. 
 
Not only are these people on a mission to fix world problems, they are also keenly aware that they could be held responsible for deficiencies in the software. 

This article addresses C++, C or similar language-based embedded development in an integrated posix programming environment that employs agile methodologies and pair programming. It is the author's belief that this does not apply to softer sciences such as web services or script-based programming, even if that programming is compiled to actual instructions or if C and C++ code can be virtualized. 

No matter how execution of your code is performed, you must be able to fully model it and demonstrate it completely to the extent that would be satisfiable by a forensic investigation.


What goes wrong?

All software design involves risk. The key is to disambiguate risk vs management dysfunction vs programmer dysfunction. Usually, if something goes wrong, it is the result of a product of these factors.

When a software shop becomes dysfunctional, it is usually due to an abridgement or abortive use of this process in favor of fire fighting, rapid development, or vague and poorly understood alternative software processes, often in order to save the engineering team's reputation from the viewpoint of a hostile non-technical manager in sales, or to beat a competitor to the delivery of a feature in competing software.

It used to be the case that this process was at odds with a process often referred to as the "waterfall model." It is my belief that this "waterfall model" can be shown to be out of date even for complex engineering tasks like medical ventilators or motor vehicle control systems.

What is the new alternative? TDD specified design combined with integrated task tracking and source control.

A fully integrated software development environment should include a task management system such as Jira, a source control versioning system, as well as a fully articulated release and quality assurance cycle. 

Without these crucial elements, any agile environment will quickly descend into chaos, even if it is populated by very talented research and development engineers with doctoral degrees.

The biggest mistake I have seen in software shops is when teams get too adversarial with each other and do not interoperate with a sufficiently unified goal. This is not always due to the executive or manager's poor decisions, but can also occur because of:
  • Geographic separation of teams causing rivalries, mutual social exclusion and dislike.
  • Interpersonal conflict among staff due to diverse differences in upbringing.
  • A single engineer who does not work well with others and excludes them from development decisions.
  • Several engineers who do not produce quality code but depend on a single quality engineer for sustained effort.
  • Talented engineers who produce quality code but are dismissive of management concerns and process accountability.
  • Grandfathered engineers who no longer produce quality code, but have institutional knowledge crucial to company survival which they depend on for employment
Motivated by what I saw as past failures in software process, occasional non-technical mismanagement, and observation of incredibly effective management alternatives in the biomedical devices industries, I have decided to establish my own minimalist approach to engineering management that I feel combines the wisdom of all of my previous successes, failures and experiments.


The bare necessities and no more 

Here is my personal addendum to the well-composed and well-thought out agile manifesto.
  • Engineering approaches should almost always be minimalist, because this usually reduces cost.
  • Safety-critical engineering should be performed in pairs with task management and source control integrated directly into the software development environment.
  • Creativity should never be restricted, but should always be integrated into the process. Any code produced by an engineer alone should be tracked and in source control. Coding alone when not assigned to a task should be encouraged and appreciated.
  • Design acceptance criteria should be specified entirely using the unit tests. Extensive annotation and comments are unnecessary and a sign of poor code construction.
  • Build release cycles, branch integration and build errors should be detected automatically by a build management system and blame assigned automatically. It may be reassigned at the appropriate management authority's prerogative.
  • Commits should always occur in pairs and this process should be integrated into the version control system.
  • Designers and web service engineers whose industry values expediency over code quality but whose artistic talent is seen to be valuable should be accommodated through an integration process that is as rigid as any other part of the project and conforms to basic engineering expectations and guidelines, such a testable design acceptance criteria.
  • Any region of code, physical component, integrated circuit, or user interface that has a user story that is not testable by a design acceptance criteria is considered insufficient. A user story that is not testable is considered to be out of scope and non-information.
  • Code analysis tools must be integrated into the build cycle and must include test coverage tools. An engineer should make his test design acceptance criteria his contract and as part of that contract be expected to show complete code coverage of all his tests. The mechanism through which this should be achieved should be agreed upon through engineering consensus of the entire administrative staff.  

Brevity, clarity, with redundancy only when necessary by design.

  • Do less with more. Do just enough and no more. Save on costs.
  • Work in pairs. Engineers hold each other accountable. Rotate pairs often.
  • Do not restrict individual creativity when it is useful, but track it and save it diligently. 
  • Keep unit tests minimal but sufficient, and time needed to understand them short. Break up any large test into smaller tests if it does not comply with this maxim.
  • Build releases and assign blame automatically. Be flexible with humans. Assign responsibility using empirical evidence.
  • Commit only in pairs and require two-level authentication of both engineers.
  • Accommodate non-technical designers, but prevent them from introducing harmful code unintentionally.
  • Keep designs testable or throw them out.
  • Use empirical data alone to show test coverage.

Process, no matter how well designed or enforced, is no guarantee of code quality

Any belief that following a code development process rigidly guarantees an improved or even successful result is as silly as believing that prayer alone will heal a sick child and should be avoided. 

Talent is necessary but not sufficient for code quality. Process is necessary but not sufficient for code quality. Both are necessary but insufficient for code quality. Code quality is a factor of effective team management, mentorship of the most talented but sometimes impetuous junior engineers by tempering it through the wisdom of older engineers, and effective guidance of the executive and involvement of the executive at all levels of engineering.

As a follow up to these posts, we will be expanding our material to cover the following topics. Please stay tuned.

Coming soon 

  • Specifying a C++ design entirely in unit tests
  • A manager's view of integrated circuit design testability
  • Design testability: It applies to engineering, too. 
  • Acceptable risk is *testable* risk: Disambiguating mismanagement and bad engineering from acceptable risk using test criteria

Tuesday, August 5, 2014

A note on nuclear power

We must establish a green power infrastructure immediately or we shall see catastrophic ecological changes that could potentially claim human lives, as well as catastrophic economic externalities if not reigned in soon.

Consider this post from ISIS, the institute for science and international security. It is interesting to me how ISIS in Iraq chose a name identical to this one.

If we do not immediately make a concerted, cooperative and globally unilateral effort to deplete these dangerous isotopes immediately in a controlled manner, it could also spell nuclear doom for us.

The scientists of the world must speak out and agree that acting immediately on the three following issues is important, regardless of their original cause:
  • Too Hot - Ecological calamity due to global warming
  • Too Explosive - Nuclear doom due to poor security management
  • Too Criminal - Aggressive misinformation and propaganda, enhanced interrogation and absolute media control due to governmental corruption
We must immediately stop any sort of this manipulation by taking responsibility and engaging industry, our peers in the public, our governments, our enemies and our world in a manner that resolves these problems with expediency.

Friday, August 1, 2014

Funding

  • If we do not meet our funding goal in 60 days, all donations shall be refunded and we shall start a new funding cycle
  • Funding shall be jointly controlled by the five trustees consisting of Nicholas Hall, two members of industry, and two academic representatives.
  • We are soliciting donations in the Bay Area today and Monday.
  • Keep an eye out for us!

Wednesday, July 30, 2014

SMS-CB Standards

Anticipated milestones upon receipt of funding

  • +12 weeks - Generating enough electrical power to power ARM-based datacenter using solar panels should be achieved within 3 months of project start. This should include a prototype integrated circuit, large capacitors, rack, generator control system,  software, documentation and everything necessarily
  • +18 weeks - The project should be powering an SMS antenna and notifying an administrative number of power status periodically.
  • +24 weeks - The project should be filtering water, generating power and SMS messages in a manner fully compliant with military telemetry systems and with a fault tolerance testing and software bug fixing stages.
  • +28 weeks - Project shall be completed and up for industry consideration.