I was playing with an idea yesterday for a very short film. I decided to set up the camera to shoot some experimental scenes just to get some ideas. After watching the footage afterward, I was laughing so hard I had to put an out-take reel together.

So here it is

It is a Windows Media file for a high-speed connection, so if you're on dial-up, it probably won't work for you. The reel starts with the basic scene I was shooting (ignore the technical aspects - the lighting is bad, etc. - it was just an experiment) and is then followed by a few out-takes. My abs are pretty sore this morning from laughing so hard last night.

Enjoy!

I think I have captured just the right attitude for a Nuke the Moon persona.

What do you think?

The link is for a Windows Media File, by the way...

It looks like I will be getting a Mac. A dual 2.0 GHz G5 system. With Final Cut Pro. I'll be editing the short film that the group just shot last week.

I am enrolling in a Final Cut Pro class at the College of San Mateo. Better late than never - I just got admitted, so now I have to go through all the remaining hoops to get in (assessment tests, meet a counselor, etc., etc.). Ugh. Not sure I'm ready for school again.

I may also enroll in this class: http://www.csmrobotics.com/. A friend of mine is taking it and I paid a visit to the shop last night - way cool. I guess I like doing combat robots. Hey, I need an outlet somewhere. Besides, I'll need something to pose with if I ever get a Nuke the Moon tee-shirt.

As for my RC4 device, I decided to stop wasting my time tracking down that one last issue, so I have frozen development and will soon (very soon) install it into my Trike, along with a computer, and start using it. I think I've been waiting long enough. Two years is about 1.75 years longer than I thought it would be.

Well, gotta get busy. Like I'm not - ha! How the hell do people work full time and have a life, too? I don't want to go back to work, but I just got a lead on a technical writing position. Ugh. We'll see where that leads. At least now I don't feel like I have to be married to a job. If I get the job and don't like it, I'll quit. Life is too short - I work to live, not live to work!

Live!

Oh, before I go, if you haven't seen the "This Land" animation at http://www.jibjab.com, then go check it out. That's my political statement for the day.

The better a day is, the worse the next day is. Yesterday was hell. I don't even want to talk about it. Now nothing works. At least my Trike is up and running with my PCM radio, so I got to drive it around a little yesterday. It's fun. I just need some wheels on it that have some traction. And maybe I'll add another battery and make it a 24V system so the thing will "haul ass" as they say.

Yesterday was one of those freakish days that are so rare I often believe they don't exist. I call them freakish because things go right. Things work. And I'm just not used to that.

To make a long story short (because I don't have much time), the revision G boards for my RC4 device arrived. Coincidentally, I also received four proximity sensors for my robot, and a new Jameco catalog. It was a day for electronics, I guess.

Here is a picture of the new board in its raw, uncut form:


There are actually six circuits on this board - RC4 is in the top right corner (you can see "RC4" printed on it). One of the circuits is an RS-232 interface board that lets me talk to RC4 via the computer, and the other large segment is my BX-24 Pilot board, which is actually two layouts on one board, that will serve as an auto-pilot carrier board for my Basic-X module that I will use in a flight test.

The remaining three little circuits were my first attempt at creating and assembling a circuit with SMD (surface-mount) components. I must say that I was immensely successful - very pleased with the end results. I don't have pictures of them, but they are used for my PCM radio to boost the signals from the PCM receiver that feed the Victor motor controllers on my Trike ground vehicle. As with everything else yesterday, they just worked. And now I can use my radio that has the ground-based frequency with my Trike, rather than the one I was using that is for aircraft use only (I don't want to get in trouble...or bring someone else's airplane down).

I cut up the boards, placed a will-call order to Jameco, took 26 minutes to go to Jameco and pick up the parts I needed, came back and cut up the boards, then immediately began assembling them. I assembled the booster boards (with the SMD components) first, followed by the RS-232 interface board (sorry, no picture of that, either), followed by RC4. Here is a shot of the Revision G board with all the components installed (except for the PIC chips, the 12 MHz oscillator and some jumper blocks):


I tested the RS-232 interface board and it just worked. So, I decided to plug in the RC4 board and test it. I simply pulled the PIC chips from the Rev. F board and plugged them into the Rev. G board and fired it up. And guess what? It just worked!

Among the parts I got from Jameco were some PIC16F648A microcontroller chips. They are drop-in replacements for the PIC16F628s that I was using, but they have twice the code space (4K!) and more RAM and more EEPROM data space. So I burned the firmware into one of them and plugged it in in place of PIC1, and - well - it didn't work exactly right, but that was because of a minor tweak I had to make to the code to tell the assembler I was using a different chip - but then it worked! It just worked! So now PIC1 is using the PIC16F648A, because it needs the expansion room (I was bumping up close to the 2K limit of the 16F628).

So here is RC4 Revision G in all its glory, with all the components and jumpers installed:


This is my test/development version, so I have jumper blocks installed where I might otherwise just solder a wire across on the board. Makes things easier for testing when I can just use a jumper block to change the configuration. For a flight-ready version, I would not install all the headers and would probably solder the oscillator right to the board (rather than have it socketed), and if I had in-circuit programming capability - which I don't - I would solder the PICs right to the board. All this to reduce weight.

And here is the beast on the development/testing platform (by the way, you can actually kind of see the RS-232 interface board in this picture off to the left in orbit around the planet on my mouse pad):


So far so good! I can't want to get it into a vehicle. I am still ironing out some final details (including that one last issue on my high-priority list that keeps me banging my head). Soon I will have to add a Revision G section to the web site. I'm actually trying to wrap up Revision F before moving on. But you know, I just realized that the letter "F" has been a miserable experience for me this year. Remember all the tragedy with my hard disks crashing, etc.? My "F" drive?

OH MAN! I can't WAIT to get past this "F"!

Well, my new code didn't work. I discovered I had made a couple transcription errors in the truth table when I entered it into my software - not the least of which being that one of the inputs was inverted. I also had an error in the code (I sent a branch to the wrong label).

Correcting the table led to some ugly Boolean equations which would have adversely cluttered up my code, so this gave me an excuse to explore the false table idea. I tweaked my program to spit out Boolean equations for the conditions where the outputs were false.

This was the solution I was looking for - it spit out much cleaner equations. I was able to rewrite the code based on the new equations. Unfortunately, it came out to be two instructions longer than the original pass. But only two! So, the count is up to 27 instructions. But now it works, so it should never have to be changed.

At least now I also have some reference material to work with, too!

Anyway, on an unrelated topic, I worked on another film over the weekend. It is an independent film called "Just Friends" that is a short comedy about dating. Not exactly my cup of tea, but hey - I'm making movies now. It was a late-nite stint from about 9:00 p.m. Friday night until about 3:30 a.m. Saturday morning. I have been instated as the editor of the film, so I guess I better get some tools together. It turns out the PC solution (you know, the computer that I was building when this 'blog all began) doesn't quite cut it in the professional film industry. It seems the way to go is Final Cut Pro on a Mac. So now we are seriously looking into getting a Mac. Perhaps I can get a few bucks for the PC, although it is obsolete already. Hell, it was obsolete when I built it. But that's the nature of the beasts.

So, I want to wrap up this RC4 thing. I may need to take a break from it for a while so I can concentrate on film-making. I ordered the revision G boards for RC4 last week and they are due to arrive tomorrow. I might go down to Jameco and pick up the parts I need to populate it and give it a quick test, but beyond that I may put the project aside [yet again] for a few weeks. I want to also get the Rev. F specs to some degree of completion before I freeze it and step into Revision G land. But I guess that will happen later.

I guess that's it for now. I just finished watching the movie Butterfly Effect. Maybe some day I'll figure out how to start my life over so I can avoid computers all together.

Ha!

I'm afraid to look. I was up a little after 2:00 a.m. this morning when the power went out. I was really mad, because I had been typing an entry into this 'blog for about an hour, and was about two minutes away from saving it.

I really (key word here: REALLY) don't like living in this area. I have seen more power outages since I moved here four years ago than I ever did growing up in Tucson, Arizona. At least in Tucson, the power would go out for a reason (thunderstorms, drivers mating with power poles, etc.). But out here, the power just seems to quit because it feels like it.

Maybe it's tired.

Anyway, I will try to recapture the 'blog entry that I tried to post this morning. I haven't checked to see if I have lost anything else, yet - I haven't gotten up the nerve. OK, maybe I will check now.

Whew! I didn't lose any work!

I would have been a little pissed if I had lost work, especially considering what I have accomplished over the past two or three days. I feel like I have created a whole new science. Well, I know it's not new - in fact, I have probably re-invented a couple of wheels. But it's just like me to re-invent wheels, because I am always hopeful that I will see something that the original creator missed along the way and wind up with a better wheel. Mostly, I just wind up wasting my time (although I do learn a lot in the process).

It all started with the one last critical issue on my issues list for my RC4 device. In the process of trying to determine where the problem was and how to fix it, I noticed some abnormal behavior on an unrelated issue. So, before I knew it, my issues list expanded to two items. I decided to tackle this new item, first, because I thought it would be easier.

HA HA HA HA HA HA HA HA HA HA HAAAAAAAAAA!!!!! Don't make me cry.

It is interesting that I had been thinking about bits and Boolean logic, etc., a couple of days before this new issue popped up - it is as if I somehow knew what was coming.

During the course of RC4's development, I have not created a concise reference document that consolidates all the features into one quick-reference chart. Due to feature creep, this information was not known, fully, at design time, so new conditions and new modes have been added along the way. I had failed at previous attempts to create a table listing all of the possibilities, but now it appeared it was something I had to do in order to make progress on this issue. So, I set out to reverse engineer my own creation, and now I have a better and clearer perspective on this thing than I ever have before.

It became important to attain this clarity, because there is one key routine at the very heart of RC4 that determines how the device behaves depending on current conditions. There is one of eight possible base modes of operation that RC4 can be set to at any given time (R/C, R/C Fixed, R/C FailSafe, R/C Presets, Command, Command Override, Command FailSafe and Command Protected). If you want to know more about what these modes are and what they mean, you can read all the gory details in the online docs for Revision F on the web site.

Each of these eight modes are augmented by the state of other features of the device, including the Fail-Safe mechanism, whether or not signal is currently detected, and whether noise rejection is enabled. Depending on these conditions, RC4 selects one of four tables as its source for input signal data. In fact, that is the sole function of this one key routine - to select the proper signal table based on current conditions.

In all, there are six bits that describe the possible states in question at any given time. Therefore, there are 64 unique conditions, and the proper signal source table had to be selected for each of those conditions. The code that was in place worked except for one or two conditions. After attaining this new perspective, I was amazed it was working as well as it was - I had done a good job of distilling the code down to a bare minimum without the help of a truth table. But without a truth table, it was a nightmare to try to figure out how to change the code to pick up that last incorrect state. And three attempts to change the code, failed.

So I embarked into the world of Boolean Algebra. My skills were rusty and weak, but I dove right in. I created a truth table with 64 "input" bits and four "output" bits to represent the logic needed for a fully functional routine. But in my efforts to simplify the resulting Boolean equations, I kept making mistakes and after a few tries, still did not have the correct equations.

So then I began to study the bits to see if there was some way I could distill the table down to a simplified form without the use of Boolean Algebra. This is where the [re-]invention of the wheel began. I don't know if I have re-invented a wheel here or not or if my algorithm is unique, but after a few false starts and dead ends, I began to feel as if I was just wasting my time again. But I eventually stumbled onto an approach along the way that led to success!

I now have a working algorithm (and some Delphi code) that will take a truth table and spit out the simplified Boolean equation(s) that describe it. I call it the "Bit Sifter." It works with any number of inputs and outputs (though currently with a 32-bit limit). I was able to use a couple of tricks the greater simply my immediate problem, which helped tremendously. First, two of the signal tables that RC4 chooses from are kind of shadows of each other, so I reduced the truth table output possibilities from four to three, as there was only one simple condition to check afterward to see if the selected signal table really needed to be the other signal table (otherwise, I actually would have needed to add a seventh input, with 128 possible permutations).

The other trick was based on the fact that the outputs of the truth table were exclusive - in other words, only one output was selected for any given input - and the fact that EVERY input condition resulted in an output. This enabled me to solve for two outputs, only, because if neither of the two produced an output, I could deduce that the third output must be the chosen one (essentially tying the two outputs to a NOR gate to get the third output). Therefore, I was able to pick the two simplest Boolean equations and model the code after them, leaving the third output condition as the default selection.

As a result of all my hard work, I was able to distill this truth table down to 25 instructions in the microcontroller code. It is amazing to me that 64 possible conditions with four possible outputs can be represented by only 25 lines of code! Not just 25 lines of code, but 25 INSTRUCTIONS!

I am now looking at the possibility of having this algorithm spit out optimized microcontroller code as well - something that I believe could be adapted to spit out code for any language, even Verilog or VHDL, or even spit out a schematic of logic gates. I am also looking for ways to improve the algorithm to determine the absolute simplest Boolean equation (I am exploring if there are conditions where a false table with an inverted output may produce a more simplified equation - you know, the other side of the bit, like I mentioned in an earlier 'blog entry).

Anyway, it is a whole new arena to explore. When I first learned Boolean Algebra so many years ago, I wanted to write software that would reduce the equations to their simplest form, but I just was never able to figure it out. And now I have it! I just wonder if maybe there is some way to make some money here. Perhaps a little utility to assist designers (hobbiests?) in hardware design, especially with the rising popularity of FPGAs (now that they're starting to become affordable to hobbiests).

Well, it's cool, and I'm happy. Now I just need to assemble my code and see if it actually works. I haven't done that, yet. But I am confident that it will work. At least, it will work according to the truth table I put togheter - this much I know. And if the truth table is wrong, at least now I have the tools to help me fix it!

YIPPIE!

I thought it might be interesting to show the code that resulted from this, so here it is:

        MOVLW   ITABLE              ; Default = ITABLE

        BTFSC   CHANNELX,cfCOMMAND  ; B

        GOTO    STCM                ; B+

        BTFSC   PSTAT,psFAILSAFE    ; B- : E

        GOTO    STRCFS              ; E+

        BTFSC   PSTAT,psLOCKOUT     ; E- : A

        BTFSS   AFLAGS,afSIGNAL     ; A+ : F

        GOTO    STIT                ; A- & F-

        GOTO    STOT                ; F+



STRCFS: BTFSC   CHANNELX,cfFAILSAFE ; E+ : C

        GOTO    STCT                ; C+

        BTFSS   CHANNELX,cfFIXED    ; C- : D

        GOTO    STIT                ; D-

                                    ; D+

STOT:   MOVLW   OTABLE              ; OTABLE 

        GOTO    STOEX               ;



STCT:   MOVLW   CTABLE              ; CTABLE

        GOTO    STOEX               ;



STCM:   BTFSS   PSTAT,psLOCKOUT     ; B+ : A

        BTFSS   CHANNELX,cfOVERRIDE ; A- : D

        GOTO    STCT                ; A+ & D-

        BTFSS   AFLAGS,afSIGNAL     ; D+ : F

        BTFSC   PSTAT,psFAILSAFE    ; F- : E

        GOTO    STCT                ; F+ & E+

                                    ; E-

STIT:   BTFSC   CHANNELX,cfPASSTHRU ; ITABLE

        MOVLW   PTABLE              ; PTABLE

The nomenclature in the comments is something I created to help me keep understand what is going on. The letters (A through F) represent the six inputs to the truth table, and the + and - indicates which branch of the decision tree the code is following. Where I have indicated a letter with no + or -, the instruction is testing the input that is represented by that letter. By the way, only the code needed to select the proper table is shown here - the branch to STOEX saves the selection into a register and returns to the caller...just in case you were wondering.

The point here is not to understand my work, but to show the small size of the code that resulted in my efforts. For what it's worth. "ITABLE" and "PTABLE" are those shadow input tables I mentioned, so the last test in the code checks to see if the ITABLE selection really needs to be PTABLE. That was the seventh input that I excluded from the truth table.

Oh, and if you want to see the truth table, here it is:

ABCDEF|CIO

------+---

000000|010

000001|010

000010|010

000011|010

000100|010

000101|010

000110|001

000111|001

001000|010

001001|010

001010|100

001011|100

001100|010

001101|010

001110|100

001111|100

010000|100

010001|100

010010|100

010011|100

010100|010

010101|100

010110|100

010111|100

011000|100

011001|100

011010|100

011011|100

011100|010

011101|100

011110|100

011111|100

100000|010

100001|001

100010|010

100011|010

100100|010

100101|001

100110|001

100111|001

101000|010

101001|001

101010|100

101011|100

101100|010

101101|001

101110|100

101111|100

110000|100

110001|100

110010|100

110011|100

110100|100

110101|100

110110|100

110111|100

111000|100

111001|100

111010|100

111011|100

111100|100

111101|100

111110|100

111111|100



Inputs:

(A) psLOCKOUT  - Lockout engaged (noise rejection)

(B) cfCOMMAND  - Command or R/C mode selection     (mode bit 2)

(C) cfFAILSAFE - Channel responds to FailSafe      (mode bit 1)

(D) cfFIXED    - For R/C Fixed or R/C Presets mode (mode bit 0)

(E) psFAILSAFE - FailSafe engaged

(F) afSIGNAL   - Valid signal(s) received



Outputs:

(C) CTABLE - Command Table

(I) ITABLE - Input signal table

(O) OTABLE - Output signal table

And here is the resulting output from my algorithm:

---- 001 OTABLE ----

x0011x

10xx01  

= /B/CDE + A/B/EF



---- 010 ITABLE ----

000000

0000x1

x00010

00x10x

00100x

01x100

10xx00

100011

= /B(/D(/A(/C + C/E) + A(/C(/F + EF) + C/E/F)) + D(/A/E + A/E/F))



---- 100 CTABLE ----

x01x1x

01x0xx

01x1x1

01x110

11xxxx  

= /BCE + B/A(/D + D(F + E/F)) + BA

As you can see, the resulting equation for ITABLE was really ugly and would have completely cluttered up my code. It was much easier to simply solve for CTABLE and OTABLE and then select ITABLE only if neither of the other two were selected.

And here is the decision tree (using my nomenclature) from which I implemented the code:

Decision Tree:



x01x1x  B-E+C+      = CTABLE

x0011x  B-E+C-D+    = OTABLE

10xx01  B-E-A+F+    = OTABLE

11xxxx  B+A+        = CTABLE

01x0xx  B+A-D-      = CTABLE

01x1x1  B+A-D+F+    = CTABLE

01x110  B+A-D+F-E+  = CTABLE

Everything Else     = ITABLE

I have not yet automated the process of creating a decision tree, but I have an algorithm worked out in my head to do it. That is my next task after testing RC4 with the new code.

I've had a hell of a time with the PIC16F87 chips.  I don't know if they're major flakes, or if it is my programmer.  But I have had a hell of a time.  I'm not even going to go into it.
 
I have ONE critical item remaining on my list.  One.  But it eludes me at the moment.  It's that last major deal that I have to conquer.  The one last great challenge.  But then I also just noticed that my RC4 device does not seem to be responding properly with channels configured in R/C Fixed mode.  Oh, well - I'll not it in my journal and move on.  That's the nature of this thing.  I fix one thing, and something else breaks.  I sometimes think I am running around in a circle, fixing this, breaking that, until I find myself back at the same problem I started with.
 
Anyway, I was thinking about programming last night and how the digital realm maps to real life.  I have heard analog people claim that they don't like digital, because nothing in real life is digital.  I would beg to differ, because it is the digital realm that has revealed a perspective of life, the universe, and everything to me that I would not have seen from a strictly analog perspective.
 
If I were to teach an introductory class in computer science, I would begin by spending an entire class session on one elementary, fundamental topic: the bit.  I think the power of the bit - and the meaning it can be associated with - is overlooked.  "Bit" - in its most literal translation - is short for "binary digit" and represents either a value of 0 or a value of 1.  But I think it is much more than that, from a conceptual perspective.
 
I define a "bit" as "a purely conceptual entity that can represent exactly one of only two possible states at any given time."  A bit has no gray area.  There is nothing in between.  There is either one state, or there is the other state, of the two possible states it can represent.
 
Now the interesting thing about bits is that combining them results in an entity that is greater than the sum of their parts.  One bit by itself can represent two states.  Two bits together can represent four states.  So far, they break even.  But add a third bit and what happens?  Instead of now representing six possible states, they can represent eight possible states.  Add another bit and now the four can represent sixteen possible states.  The effect of their accumulation is exponential.

This idea has led me to see that everything in this [seemingly complex] universe can be broken down into simple, fundamental components.  Look at DNA for example.  It has four basic components, but simply due to the sequence in which they are arranged in the strands that they form, we get plants and animals and people.  Well, people are animals, too, but you know what I mean.
 
The bit - or rather the concept of the bit - is fundamental to the universe.  Look at the greatest question mark of all: existence.  Things either exist, or they don't.  There really is no gray area.  One might argue that things change and mutate, but from the perspective of the bit, they are changing to become something else.  The moment one thing changes - so much as a single atom - what was once a certain thing before has now become something different - the previous state no longer exists.
 
Take photons for example.  They are either present, or they are not.  Light and dark is an example of a bit.  One might argue that there is infinite gray area here, but if you really think about it, there isn't.  There is either light in the room, or there is not.  If there is one photon in the room, there is light.  If that photon disappears, then there is no light in the room.
 
And there is a threshold there - some invisible, infinitesimally thin dividing line where the photon is considered to be out of the room or in the room.  The photon is either inside, or it is outside.  The moment the outer edge of the photon (if it has one) crosses over that line, its state changes from in to out, or from out to in, depending on the direction it is travelling.

A door can be either latched or unlatched.  Turn the door knob slowly as you pull on the door and there will be one point - one instantaneous moment - where the last atom of the latch clears the last atom of the jamb and the door opens.
 
I think the existence/non-existence, light/dark example has given me the greatest influence on my perspective of the universe.  It has made me think about everything to consider if there is an opposite to the things I observe.  I kind of look at the universe and everything in it as this state of existence - as one side of a bit.  And within that state of existence there are other bits - like matter and anti-matter.  I have heard it theorized that the total of all energy in the universe is exactly zero.  I tend to believe that.  I perceive the universe as this temporary state of existence, and that everything in it exists because the original state of nothingness has been split into two and stretched out like a balloon.  We exist in this universe in a state of tension, with that endpoint of non-existence trying to pull it all back.
 
Bring matter and anti-matter together and it ceases to exist.  There is a violent release of energy as the matter returns to its state of nothingness.  There's another bit: matter and anti-matter.  This thing we call matter can exist in one of those two states.  Anything in between and it is something else entirely.
 
Anyway, the bit is immensely useful in logic.  If you can break down a problem into its constituent bits, you can then represent it entirely in binary.  I think if I were to teach an introductory digital electronics class, I would expound upon the bit as well.  Digital electronics is an ideal playground for playing with bits.
 
One thing they teach you is about gates.  AND gates, OR gates, etc.  But what I don't remember ever being taught is a thing I refer to as "negative logic" or "inverse logic".  It's the other side of logic - the other state of the bit that represents logic. 
 
We tend to look at things from one perspective - one side.  When dealing with logic, it seems for some reason there is a great interest in the "1" (or the "true") state.  In fact, there is a little thing called "truth tables" that digital electronics students learn to make.  It illustrates what pattern of bits on logic inputs results in a 1 or true state on the output.
 
"True" is often associated with "1", and "false" with "0".
 
So, for example, a Truth Table for a two-input OR gate would look like this:
 A B : X
-----+---
 0 0 : 0 
 0 1 : 1
 1 0 : 1
 1 1 : 1
 
And a Truth Table for a two-input AND gate would look like this:
 A B : X
-----+---
 0 0 : 0
 0 1 : 0
 1 0 : 0
 1 1 : 1
 
For the OR gate, whenever any input is true, the output is true.  For the AND gate, only when both inputs are true is the output also true.
 
Then there is the inverter.  This simply takes an input and, well, inverts it.  If the input is true, the output is false.  If the input is false, the output is true.  One way to represent an inverted value is to put a bar over the input name, or put a slash in front of it - like /A.  So, if A=0, then /A=1.  Following this, if you invert all the inputs AND the output of an OR gate or an AND gate, you invert its function - the OR gate essentially becomes an AND gate, and the AND gate becomes an OR gate.
 
Here is an inverted OR gate Truth Table:
/A /B : /X
------+---
 1  1 :  1
 1  0 :  0
 0  1 :  0
 0  0 :  0
 
And here is an inverted AND gate Truth Table:
/A /B : /X
------+----
 1  1 :  1
 1  0 :  1
 0  1 :  1
 0  0 :  0
 
You can see that the inverted OR gate spits out a true only when the inverted inputs are both true, and the inverted AND gate spits out a true whenever any input is true.
 
But is this really inverting the function of the gate?  Well, yes.  But what about negative logic?  Look at the inverted gates again.  If you look at the zeros now instead of the ones, the gates haven't changed.  The OR gate is still an OR gate, and the AND gate is still an AND gate...but for "false" conditions!  The inverted gates have not so much inverted the logic operations they represent, rather they have inverted the focus from "true" to "false".
 
In negative logic, we're interested in the false conditions - the zeros.  So, when inverted, a truth table becomes a false table.
 
Anyway, I have some theories - or formulas - whatever you would call them - that I use to help me understand logic and maintain an understandable perspective on it.  If I could draw some diagrams here, I would.  But oh well.  There is one strange gate in particular, called the "exclusive OR" gate.  Again, there is the focus on "true", since in inverse logic, it is really an "inclusive AND" gate (where both the false-false and true-true conditions result in a false output).  I consider this gate to be one that straddles the line between positive and negative logic, kind of like the inverter that translates between the two.
 
I'm not sure where all this is going, but I was just thinking about all this stuff and thought I would write it down.  It is useful to have the concept of the bit in mind (in a more general sense) when looking at the universe...or at our small little corners of it.  I contend that what we see is not all there is, and try to look for the flip side of things, asking myself, "is this a bit I'm looking at?"  After all, where would our understanding of the universe and mathematics be if no one ever discovered "imaginary numbers?"  There's a bit: real and imaginary.
 
See, this really is a digital world we live in. 
 
Although, there are some analog advantages that might be spoiled if you try to break them down into bits.  Take my wife, for example...
 

 
She wouldn't like it one bit!
 

Wowie, wowie, wowie!

What the hell is wowie?

Just thought I would add a bit to my earlier statistics. The current instruction count is 1951 instructions for PIC1, and 1705 instructions for PIC2, for a total of 3656 instructions. I added a few today (trying to bring my development rate up to one instruction per hour - haha). And things are moving right along. I have only one critical item remaining on my list, then it's play time! But this last item is a bugger to track down, because it is a reset issue that has a lot of strings attached.

Anyway, I thought I would provide a count of RAM bytes that I use for accomplishing all that this device does. It's really pretty amazing (to me, anyway).

PIC1 uses 133 bytes of RAM and 60 bytes of EEPROM data (for identification purposes).
PIC2 uses 125 bytes of RAM and 84 bytes of EEPROM (that get copied into a portion of the 125 bytes of RAM on power-up). So, in total, RC4 uses 258 bytes of RAM and 144 bytes of EEPROM to do what it does. That's just amazing to me. Hey - it wasn't easy! It took me two years to figure out how to cram all that in there.

Hmm. Where would we be if Microsoft worked that way?

I think the days of writing efficient code to fit into tight spaces, are gone. I think that's why I like doing embedded stuff (well, I say I like it, but it's really a love-hate relationship...or an addiction) - I can hone my skills and my craft in the art of cramming code. I just don't want to let that art die, I suppose. It's not something people seem to learn these days. People these days seem to solve programming problems by throwing more memory at it. I like to solve programming problems by ripping out code that's not necessary. After two years, you can bet that every BIT in this thing is absolutely necessary. In fact, I had a long-standing issue (that is still open) about deciding what function to assign to one last bit that was available in a mode selection byte, as there were four competing potential features that wanted it. It turns out I had to use that bit to solve another issue that I just resolved last week. So there are four potential features that got locked out due to the lack of available bits!

But if I start using the PIC16F87 microcontroller, I will suddenly have a lot more room to play with. My code will port over to it directly as the chip is a direct upgrade from the PIC16F628 that I am using now. The 'F87 has twice the code space (4K!) and twice the EEPROM space (256 bytes!). But then again, I don't expect to be expanding this project, anyway. I've got other things I want to do with my life.

I was just thinking about my RC4 device this morning and all the time I have put into it. It is amazing how all this work just boils down to a collection of bits. All these bits have to be arranged just right in order for this thing to do what I want it to do.

The amazing thing is that I have developed firmware for two chips on this board. The first chip handles all the data communication (serial interface to the computer and data exchange between the two chips), and the second chip does all the signal processing (samples incoming signals, generates output signal, plus communicates with the other chip). The first chip accomplishes its job in 1940 instructions. The second chip accomplishes its job in 1699 instructions.

The chips use a 14-bit instruction word. So, for 1940 instructions, that's 27160 bits. For 27160, that's 9.4337037480804523995527931517583e+8175 possible bit combinations. At first glance, you might think 1940 instructions is not very much for two years of work, but you can think of it another way. Out of all the possible bit combinations, it only took me two years to find the right one.

Anyway, it is truly amazing that it all distills down to 1940 instructions (for PIC1) and 1699 instructions (for PIC2). That's 3639 instructions. Let's see what that works out to be. There have been entire months where I have not even worked on this project, but let's just pretend this was a job and I devoted 8 hours a day, 5 days a week on it for two years. At 52 weeks per year, that's 104 weeks, times 5 days, times 8 hours, or 4160 hours. 3639 instructions divided by 4160 hours = 0.8747596 instructions per hour.

This suggests I have developed less than one line of code per hour. Looks like I'm really sleeping on the job!

Now, if I was getting paid $35/hour for doing this, I'd be $145,600 richer!

Damn.

I think I'll go water the plants now.

My RC4 device is really shaping up! I have only four critical issues remaining (but two are so closely related that I really have only three issues remaining) before I will be ready to plug this into a computer and start playing with it. Oh man! All that hard work and I am finally approaching an end point!

I haven't ordered the Rev G boards, yet. I am glad that I gave myself the weekend to make changes, because I made some more changes today. The longer I look at this thing, the more issues I come up with. If I don't draw some [figurative] lines, this thing could go on forever.

Now, see, if I knew Verilog or VHDL, I could just get an FPGA and program in the peripherals I need and be done with this. There would still be issues going that route, but nothing like the route I took. Most of the tricky firmware I have developed for this thing is due to the lack of peripherals on the microcrocontrollers and employing every trick in the book to make use of the ones that are there to accomplish my objectives. I must say I have done a grand job of it, but at quite a price (ow, my neck and back, and the emotional strain - and all that TIME). But now I can reap the benefits...I hope.

I may still make one more change to the PCB layout before I order new boards. I would like to add in-circuit programming capability so I don't have to keep migrating the chips between the programmer and the RC4 board. The only problem is, I think I can get to one chip, but not both, so I don't know if it will be worth the effort. I just want some new boards that I can use, so I am more apt to just order them than try to add SOMETHING NEW.

Here's RC4 Rev. F in its test bed:

Not a very good photo (kind of dark), but there you have it. I just ordered some new servo wire today. The wire I used for the connectors currently on the test bed was too small and fragile and two connectors have gone bad on me. And I flew a test flight with those wires last year! I am revamping the wires to prevent disaster.

Here is the little programmer I use for burning the firmware into the chips:


It works well. Well enough for what I am doing.

Anyway, I have plans for a very small model airplane that I will be building soon. It will be a model just like this one, except with a few differences. It will be constructed as a night flyer (with LEDs and generator), but it will also be segmented so that I can disassemble it into smaller pieces. The wing will either separate into two halves or fold over, the tail boom will come off, and the tail fins (fin and stabilizer) will come off. This will allow me to pack it into a small bag/backpack so that I can take it anywhere. What I would like to do, eventually, is to hike up to a secluded lake somewhere and get into an inflatable boat at night and fly my plane around over the lake at night.

I can't wait.

Also, as electronics & computers keep getting smaller, I should be able to equip the plane with some gadgets at some point in the future, too. Even RC4!

Well, dinner is ready. Time to break from technology for the evening.

I had a rare day yesterday. Something actually worked.

I am working on my RC4 project, trying to wrap up the last few priority issues. Well, I was looking into an issue - that was more like just a question in my mind - and in the process discovered a number of issues.

Let's see...do I try to even explain it here? If I do, it probably won't make sense to anyone but me, but I'll try, anyway. I have what I am now calling the "Trigger Input" (formerly "Channel 5") that can be programmed to sample an incoming signal connected to it in order to control the engagement of Fail-Safe mode. When it is not programmed to be in that mode, it simply samples any signal that comes in and the pulse width can be read as a 16-bit value (13 bits, really). If signal is lost, a read always returns the value of the last signal received. But when it is programmed to control Fail-Safe, it returns zero whenever no signal is present (i.e. it does not return the value of the last signal before signal went away).

There's a lot more to the story than that, but this particular story began with the question, "why does this return zero in this mode?" There was a reason for it, but it was a reason I never documented (in my 238-page development journal).

The answer I won't even go into, since considerable familiarity with the code is necessary for a contextual foundation, but I wound up revisiting an issue (that I thought was unrelated) that I addressed three days earlier. It was a classic example of tugging on one string here to disturb other strings elsewhere.

I realized I had to implement another solution. It was clear now what I had to do without disrupting anything else. I formulated a solution in my head and started at it. Sometimes, the best and easiest way to represent a design is to implement it, so I dove right in - no preliminary design docs to get in the way. I don't know how long it took me to revise the code (I had to back out a previous "fix" while at the same time implement the new one), but it seemed like a long time, and I wound up in the end about breaking even on the instruction count, so I was pleased. Strangely, I was also very confident.

I wasted no time and I assembled the code (no errors, first time!), and immediately burned it into the PIC16F628 microcontroller chip (PIC2 in RC4). I plugged the chip into RC4, and it worked.

It just worked!

So, anyway, as much as I complain about technology and how it shreds my insides from time to time, I have to also devote some appreciation to the time when things actually go right. It's not often machines cooperate. Hmm... It's funny that I say that just after getting home from watching Spiderman II.

As of this writing, I counted 137 (documented) issues that have been closed, 13 priority issues still open, 27 low-priority (non-critical) open issues (that I won't even look at), 31 open issues on the back burner (many of which will never see the light of day), 8 situations to debug, and 14 situations I want to test. This is just regarding RC4, itself, and does not include the documentation issues or the control software I use to demo/control RC4.

And why am I doing this? I HAVE NO IDEA!

I'm trying to wrap up my RC4 project. It has been over two years now. I recall vividly, now, why I stopped working on it in the first place. It has become far too complicated, and the code has been distilled and compacted to such a degree that there is very little decoupling between routines, so if I so much as tug on one strand, a hundred other strands are disturbed.

It's like a giant tangled web.

And because I developed the firmware entirely in Microchip assembly, it takes a long time to make any significant changes to the code, and there are so many features that it is about impossible to fully test the thing to make sure it still works after I change something. Usually, when I change something - even the smallest of things - I discover weeks or months later that I broke something else in the process.

Anyway, the thing was so close to being in a usable state, that I wanted to finish it. I thought I could knock of a few items on the [HUGE] list of issues in just a few days. Well, it has been just a few days, now, and I have knocked off a couple of items, so I am making progress. It has just been slow-going.

I fixed two problems over the past two days. Each problem took me an entire day to troubleshoot and resolve. It's getting to that point. It seems with all programs - whether desktop applications or embedded drivers - once you get the main framework in and working, there are little details that pop up that need to be addressed. And the longer you work at it, the longer it seems to take to find the last of the details, and the harder it is to wrap up those last few.

Why is that?

I have been thinking of posting my RC4 development journal online as a 'blog of its own, just to give people an idea of what goes into developing a piece of technology (I'm sure some people would be interested in it). Just the journal alone is up to 228 pages as of today. That doesn't include the web documents already online, the technical reference documents I have created, and the source code...and the 10-page list of issues! Fortunately, most of the issues are resolved, now. But there are what seems like hundreds of items still open regarding little details or feature ideas that will never be implemented, or odd little quirky observations that I have made that I wanted to revisit to understand, etc., etc. I have even added to this list over just the past few days. But I am tackling the last few significant issues, of which there are only a small handful.

I think in another week I will have it pretty much wrapped up, at least to a point where I can start using it. I want to put it on my Trike, along with an embedded '386 computer and some sensors, and see what I can do with it. It should be fun.

That reminds me, I got a new power supply for the embedded computer that I was building inside of a power supply case. I installed it and...it exhibited the exact same behavior as the other power supply. I thought these things must be notorious for dying in this peculiar way.

But then something spoke to me. Remember a while back when I burnt up a ribbon cable while trying to connect RC4 to one of my embedded computer boxes? When I did that, the power supply kept trying to come on when the cable was shorted, but it just kept doing this on-off-on-off dance. Well, that's what this new power supply was doing with absolutely nothing connected to it.

I decided maybe there was something on-board that was causing it to shut itself down and maybe there was a short in the supply somewhere. However, after doing some research, I found the specs for this supply and discovered that it has a minimum load requirement in order to work. It needs a minimum 3A load on the +5 outputs, and something like a 0.12A load on the +12V outputs, in order to work!

Geezzz!

So, now I have to figure out how to create a 3A load on the thing so I can test it to see if it works. 3 amps!? The computer only draws 1.5A, max., and I just don't have enough stuff to add to it to bring it up to 3A. I guess I need to add a string of Christmas lights or something. I am thinking it must have on-board protection to shut itself off if there isn't any load on the outputs (at least that is what I am hoping) - there must be some reason it's doing the on-off-on-off dance.

Anyway, here is a shot of where I am working on RC4, now that I am on my big desk instead of the nice little workbench I built when I was in the thick of developing this thing.

I added the shelf with the oscilloscope on it today. Man, the 'scope is getting old I guess, because the trace would not focus very well, and my probes are all messed up. I need some new equipment.

Badly.

That's about it for today. I will be ordering a new round of boards for RC4 next week -- revision G. I can't wait to get them!

I'm writing this really fast in hopes of compensating for the speed of Blogger this morning.

Just kidding (for those who don't know me any better).

Well, last night - July 4 - was a little bit exciting. I went to see Fahrenheit 9/11 earlier in the day and didn't see a single thing that surprised me in the least about Bush. He's just exactly the weasel I imagined him to be from the day he announced his candidacy for president of this country that he doesn't belong in. The one thing that did surprise me was just how tight the Bush's are with the Saudis.

But that has nothing to do with the Computer Circus. Neither does the rest of this post, but then there are things that are more interesting than computers. Like fireworks for instance.

I just wonder if kids these days are getting more and more stupid, or if they were always this stupid, but I don't remember being quite so stupid when I was a kid. You see, I live with my wife and a roommate in a huge apartment on a hill. This hill is covered with grass and is usually very windy. This time of year, the grass is no longer green, and it makes great kindling, because it burns so easily.

Key word here: BURNS!

Funny thing about July 4 - people (mostly kids) like to shoot off fireworks. In order to shoot off fireworks, one needs a match or a lighter. This is because they are filled with highly flammable substances that are DESIGNED to burn quickly to either launch a stick of fire into the sky, or to make a loud BANG by making it hard for the fire to get out.

Key word here: FIRE!

Fire and dead grass mix very well...just not in a desireable way when you happen to live right next to the dead grass.

My wife and I decided not to go out for the evening and just spend a quiet night at home. I suppose that was a good thing, because it wasn't so quiet, and had I not been home, we may not have had a home to come back home to. We were watching the Twilight Zone, and there was this big balloon that the characters were shooting at, that looked like a big alien, but was actually constructed by these tiny little aliens that were trying to scare the humans. One guy shot at the balloon and it deflated and the little aliens got scared and took off. About that time, there was a very loud BANG near the apartment, followed by a series of smaller pops in the same vicinity.

I am always fire-conscious (or fire-fearful), living on this grassy hill, so I decided this event warranted an examination. I stepped out on the balcony and saw what I didn't expect to see, but feared most: two patches of flames eating at the dead grass on the hill behind the apartment building!

Here is a shot of the burned patch as of this morning, taken from the perspective from where I first saw it burning last night (the potted plants are on the balcony ledge).

It wasn't a big fire (partly because of my efforts to battle it). But you can see how close it was to the apartment building, and imagine how much worse it could have been:


I grabbed my fire extinguisher from the kitchen and ran out as my wife called 911. My roommate was yelling from downstairs - she basically had a ring-side view of the emerging blaze - but I already had one foot out the door.

It's funny how the mind works in a hightened state of excitement. Or doesn't work. My wife was yelling for me to grab some blankets to throw down, but I just imagined them lighting up, and I didn't think I had time to go downstairs, find some blankets, go back upstairs, run around to the back of the apartment building, and battle the fire. I had a fire extinguisher in hand, so I just ran. I remember thinking how badly I wanted a shovel, and how we got rid of all our yard tools when we moved out to California, thinking we wouldn't need them.

Anyway, the extinguisher still had the mounting bracket strapped to it (it was not actually mounted on the wall - it USED to be mounted on my workbench when I lived in Arizona). I popped the bracket off of it on my way out (I found it this morning right where I tossed it last night - in the middle of the garage).

This sequence of images show part of the route I had to take to get to the back of the building.


What you don't see is my exit route out of the apartment, out of the garage to the street and around the corner to the apartment building next door. What you do see is the stairs at the apartment building next door that I had to descend to get to a termite-eaten gate that led out to the grassy hill. I then had to traverse the uneven terrain in my tennis shoes to get to the fire.

As I approached the fire, I began to fumble with the extinguisher. Humans have a great capacity to project the future - or at least, a hundred possible futures based on emerging situations. By this time, I already imagined myself sitting in some shelter somewhere, holding a blanket around me, thinking about how I lost everything I ever owned to the great fire of July 4, 2004. So, my mind was not exactly focused on the fire extinguisher and how it worked. I just wanted the fire out.

In an emerging situation such as a fire, people tend to get a little excited - perhaps even panicky - and nobody thinks there is time to think. Thus, people react. The trick is to balance reaction with thought, so there is some purpose to what you are doing. I took a moment to pause, and I realized there is time to think. Lots of time, if you just slow down. I managed to remove the locking pin from the nozzle and situated the handle in my hand properly and found the lever to operate the extinguisher. I had never actually used one before.

The rest seemed easy. This magic tank was spitting on the fire line and squelching the flames on contact. There were three or four other (younger) guys on the hill, running up and down, bringing buckets and ice chests to dump water on the fire. They were yelling, "oh shit!", and I had to wonder if these were the kids responsible for the blaze. One of them slipped and fell and rolled over the fire line into the blackend area. By this time, the two small rings of fire had joined to become one larger ring.

I decided to fight the uphill fire line, since that was the line that posed the most danger in my mind. It was the line that was heading toward the apartment building. I can remember maybe a handful of days since I have lived up here, when there was little or no wind on the hill. It was just fate that this just HAPPENED to be one of those nights! Had the wind been blowing, this thing might have gotten out of hand very quickly.

I was doing OK with the blaze, trying to remain calm, when I suddenly found myself in a billow of smoke. I didn't take a deep breath, but I breathed enough to spur me to move away from the fire line. At that time, one of the kids asked me if I wanted him to do it, and before I could answer, he grabbed the extinguisher from my hand and went at it. I was using the extinguisher sparingly. Since it was small, I was using just enough to get the fire under control. But this kid took it from me, and within seconds, it was spent.

I was a little pissed.

So I started stamping the fire out with my feet. Not the smartest thing, but I was being careful, and the fire was small (and getting closer to being under control), and I just worked my way around the edge, stomping out small flames at a time, looking back occasionally to stamp out places where it flared up again. Although the grass was dry, the wind was calm, and the fire was not spreading very fast, so I made sure I thought about what I was doing. The other kids were still hyped up and excited and fumbling, spilling buckets, etc. It seemed to me that I did more toward putting the fire out than they did.

Just as I got around to stamping out the last bit of flame, the kids were already disappearing. This kind of makes me think they were...shall we say...hiding. I can't prove that they started the blaze, but, well, you know, it's not THAT hard to put two and two together. I can't prove it, so one of the hundred probabilities here is that I could be wrong.

The fire was out, but I knew it could flare up again at any time, so I made my way back to the front to see if the fire engine had arrived, yet. It was pulling up just as I got out there. To make a long story short, they had a hell of a time finding a way to get to the back of the apartment, and they had no way to get water there!

The fire started up again, but a fire fighter had finally made his way to the hill and was able to put it out with a shovel. Eventually, three of them started making a fire break around the perimeter. They were talking about how it was such a slow night for July 4.

Lucky me.

They finally were able to link together some garden hoses from a spicket near the front of the apartment building next door (on the other side) of my building and finally were able to wet down the area.

That's scary.

To think that the fire fighters couldn't get water to the hill behind the building - even from the street further down the hill. And to think this termite-laden structure is made of match sticks, nestled in a blanket of kindling, does not give me a warm fuzzy feeling.

Look at the building from the fire's perspective:


Where do you think it wanted to go? There's not much room between the fire line and the pile of driftwood I live in:


It was interesting to examine the area this morning. Here are a few things I found:


There is what looks like the handle of a cap gun. I'm surprised the fire crew didn't pick that up last night (maybe it was just too dark). I know that didn't start the fire, but it is discomforting to know that other potential fire sources were in the hands of kids in this same region at some point.

There's also a trash pail that I can only assume was being used by the other kids last night for transporting water to douse the flames. There is a pile of green, melted, something next to the pail. One can only guess what that is.

Then there is this black plastic pipe. I remember stepping on the end of it, trying to put it out, but it wouldn't stop burning, so I left it (it was already in the blackened area, so I figured it was not any real threat at the time). Who knows what the hell is or was inside of it. It's right about where I saw one of the first rings of fire emerge. What is interesting here, too, is the small branch that is under the pipe that is not burnt. I guess the fire wasn't hot enough to light it up.

Fortunately, it was a small fire and nobody got hurt and no property was destroyed. I just wish people weren't so STUPID! The cops asked me last night if I was lighting firecrackers. I just said "no, I don't have any," when I really was biting my tongue and wanted to say, "no, I'm not that stupid." I haven't been that stupid since October 14, 1980, when I put myself into the hospital for three days when I gave myself this little trophy:

But that's a story for another time.

What amazes me is that there is simply no (easy) way to get water to the rear of this building. I think a call to the owners may change that. Anyway, the apartment building still stands, and my web server keeps running, and I have a place to rest my head (still), so the Computer Circus can continue. As I am sure it will.

If you keep the fire burning, just make sure you keep it under control.

Who says BattleBots and computers don't mix?

http://robotcombat.com/video_moebius_music_video.html

Now I know what to do with MY battle bot!

I [expletive]-ing gave up. I'm back to using a stock template for this 'blog.

Live with it.

I could make a whole ton of religious references and throw in a bunch of other sordid words that you can't say on television, but what's the point? Words are simply inadequate. All I can say is, I am SOOOOOOOOOO GLAD that I am not a Web developer!

How in the HELL does anyone deal with this crap? Ok, the expletives are leaking out (not surprising - I'm full of them right now). I have tried and tried and [deleted expletive]-ing tried to get the template for this 'blog to be something...something SIMPLE...something BASIC...but holy [EXPLETIVE] I cannot phathom the level of astonishment I experience when I realize just how difficult Web technology really is to use.

I found out Style Sheets were created with the INTENTION of avoiding turning it into some kind of programming language. Well, you know, things would have been a LOT SIMPLER had they started out from the very beginning to make it a programming language. As it is, there are so many quirks and counter-intuitive inconsistencies that it is amazing - ABSOLUTELY AMAZING - that anyone can do anything with this crap!

Do you know that if I add a background color to this div, the background color will overlay any other div I try to put in here? I added a div to include a picture to float right, and the text wrapped around it like you would expect, but you couldn't see the picture - only the F-ING bacground color. Take the F-ING background color out, and the picture magically appears.

And don't even talk to me about Mozilla. At least Mozilla did what I expected, but everything is rendered larger and...well...I'm not even going to go there. It's just another one of the Web's inconsistencies.

There ISN'T enough money in this world to pay me to work with this crap. I'd rather take a swim in a cest pool.

OK, enough bickering.

Maybe this will cheer you up. If you think you've seen it before, keep watching.