Friday, May 28, 2004

Of Cell Phones, Signal Quality, and Loud Voices.

Was watching TV today and saw this commercial for some company's wireless service. They where showing a train full of cell users with signal quality bars over their head and one guy had really bad signal. This guy was basically screaming into his cellphone.

Now. There are 3 things wrong with this one. #1, I absolutely HATE people who yell into thier cellphones. That's just a personal pet peeve. But #2 is that ALL modern cell phones are digital. Now if you didn't know, digital cell phones use error corrected packets of data to carry the voice signal. When the signal quality fades, the packets pick up large amounts of errors, and when the packets are too corrupted to correct, they are dropped. This causes breaks in the voice stream. Yelling will not prevent packet loss. And #3, the problem of overmodulation. Basically because we're talking a digital stream, there is maximum limit to the sound intensity. If you go beyond this limit, the quantitizer maxes out and wont go any higher. This leads to clipping (The squaring off of loud sounds) in the audio stream.

But everyone seems to yell when they begin to loose signal. The part that confuses me ('cause I occasionally catch MYSELF doing it...) is WHY we do it...

Ring ring!!!

Mood: Confused

Monday, May 24, 2004

The Buu Suit and Nan Desu Kan

Well, I've decided: I'm going to Nan Desu Kan. This local convention of Americans to share their love for Japanese culture and entertainment (Mostly to talk about Anime, Manga, and Video Games.) This sounds like something I would love to attend.

However, there's a problem. I wanna cosplay. Just sounds like a fun thing to do. However, there just aren't that many 6'3" 285 LBs anime characters. I would rather not go as something that I really don't "fit" the role for. So I mulled the question over, and after talking with some friends, have decided to go a Majin Buu. Buu is a large guy, and if he where my height, he would probably weigh about 500 LBs. This is great because I can always make a costume to make me look bigger. ^^

However, any full body costume (Like this one will have to be) is going to get hot. VERY hot. So, I thought, "Hmm, I'm an engineer. I have a problem. So, let's apply my expertise and solve it."

So my friends and I did some more thinking, and this is what we came up with. First, we make a Buu body suit. We do this by sewing cloth together into a Buu shape (with elastic holes where his much smaller legs are). Then we take bits of foam and shape them the way buu is shaped and sew it into the cloth. The foam will give form to the Buu costume without sacrificing flexibility (Which is a good thin seeing as the costume won't fit through doors otherwise. ^^) Then we make a head out of paper mache and build it so it has a rack with Styrofoam insulation in the upper parts. This rack supports Peltier junction whose hot side is attached to a heat sink and fan combination and the other side have another heat sink and fan, except with the fan rigged to run backwards. This means that the fan will blow away from the heat sink. This will keep my hair from getting sucked in to the fan ^^;;;

The hot side fan intake will come from Buu's head tail, which will be made of fine mesh and thin nylon. This was it can be pink, and air permeable without having the cloth pulled tightly over chicken wire and looking really stupid.

The head will be built so it has supports that rest on my shoulders and will be strapped on. That way I won't have any problems with the head falling off since the head will be considerably unbalanced. This is going to cause a bit of a problem because Buu has a really small head as compared to his body, and I have a big head (Probably from all that ego stroking I give to myself. ^^)

Now, all I have to do is actually build it. Not that it is an easy task mind you ^^;;;


Applied engineering applied to cosplay. Scary.

Mood: Inventive

Thursday, May 13, 2004

Little Endian, the Big Indian on Campus

Wow... 1 week of not posting and look what you get. *Whistles* Blogger has really spiced it up.

But anyway, on to the point at hand. I was reading along in STL's website when what do I find? "Little Endian is evil"

I sat there stunned, "Did he just say what I thought he said?" And sure enough, he had. And I'm like, WOAH! A CS guy who doesn't see the silent beauty of little endian? Blastphemy!

Maybe it's just because I'm an Electrical Engineering student instead of a CS student (Although the current plan is to minor in CS) but little-endian numbers are to me what chocolate is to most. See, for those of you who are just plain ol' technically inclined (This topic is WAY beyond 'computer literate') I'll give a quick discussion of Big and Little endian numbers. See, computers keep their data in discrete digits, namely ones and zeros. Now these digits are combined together to form larger chunks of data. Often they're arranged into groups of bytes, words, D-words, and Quad-words (On 32 bit systems, these are 8,32,64, and 128 bits in size respectively.) Now, because numbers are usually made of values larger than one measly byte can hold, we use the larger words to hold them. But because memory is arranged into bytes for addressing purposes, we have to decide how they should be stored. Big endian uses the same principle as you would with notebook paper. If the top left corner of the page is the first spot, it would begin by writing the most significant (the 5 in the number 51223) digit first (or the most significant byte (MSB) in this case.) The last one it would write would be the least significant. Now this would seem obvious to anyone who's written on paper before, but little-endian takes a different approach. Instead of writing the MSB first, it writes the least significant byte (LSB) first. So this is like representing fifty-one thousand, two-hundred and twenty-three by writing 32215 down on the paper. Now this is counter intuitive to most people. Why would you write the last digit first?

This takes us into the beauty of little-endian numbers. Now, stop a second and add the numbers 123 and 789 together, taking notice of how you did it. Notice that you started the addition from the RIGHT and worked left? Now pretend that you could only read one digit at a time and couldn't rewind either the input number or the output numbers. Can you think of any way to do the addition under those constraints? You can't do it without first having yet ANOTHER sheet of paper to hold the values on for a moment. And it would take you a second to copy the numbers down. Now, consider how you would do it if the least significant digit (The one on the right) came first. For me, I'd do our example (123+789) by going: "OK, I have 3 and 9, add, get 2 and a carry. Now I have 2 and 8 and a carry, add, get 1 and a carry. Now I have 1 and 7 and a carry, add get 9. Now the answer I gave is 219, which is correct (in little-endian notation, the answer in common form is 912.) Notice, I was able to do the addition serially (one digit at a time with no look ahead) with only a one bit buffer (notice, I DO have to keep track of the carry.) Because of this, circuits of VERY low complexity can be designed and built to do addition as the numbers are read in. This is very fast and very efficient. Fewer gates mean fewer transistors, means less heat, means higher clock rates, etc. This holds true even if your bus is larger than 8 bits.

But this leads us into one of the pitfalls of big-endian numbers. Since bytes themselves are stored such that the lowest order bit is also the least significant bit, that means that a big endian system has it's bits ordered such that a 2 byte number is written in memory as (using bytenumber(bitnumber) notation) 1(0),1(1),1(2),1(3),1(4),1(5),1(6),1(7),0(0),0(1),0(2),0(3),0(4),0(5),0(6),0(7). Notice how the biggest byte is first but the biggest bit is last? Little endian puts the biggest byte last as WELL as the biggest bit. This means that the bits are ALSO sorted linearly by significance. This is very useful when doing significance (> and <) checks, since with little endian you can start at the very beginning of the two numbers and check them as you go (1 loop), rather than having to skip around to find the next most significant bit (1 loop and another nested loop. Oh, and usually > and < are done with subtraction instead, but there are other kinds of algorithms that bennifit by having sorted bits.)

But, unfortunately, little-endian is just backwards from what we're used to in significance, so programmers, like STL, just don't nessicarily see the essential beauty on the lower level.

I still don't know why we use big endian in handwriting anyway...

Mood: Actually informed by a class... Scary huh?

Wednesday, May 05, 2004

An Old Friend Reborn

Well, the time has finally come, after 2 and one half years, MuggleEater has gotten the finishing parts to his complete upgrade. Once an Athlon 2100+ XP with 512 MB of DDR 2100 Ram, 80 GB of UDMA 100 Hard drive space, sporting the then trendy GForce 4 4200ti Video card, MuggleEater was the best there was. But two and a half years if a full lifetime in the computer world, 2 for gaming machines, so I spent some money and brought him into 2004. Now, he's equipped with an Athlon 3200+ XP with 1 GB of DDR3200 ram, 160 GB of SATA 160 hard drive space, and the much powerful ATI 9600 XP graphics processor. And I must say: "DA----MN!"


The new upgrades give him about 100% more processing power. He scores well there too with a steamy 3801 on the 3DMark '03, up from 2882 (Compare your scores on the ORB at http://service.futuremark.com/compare?2k3=2474924). But we're not just talking the benches here. In my favorite test of total system power, the "Stand at the lower Jeuno AH and spin with the display res at 1600x1200 backed by a 1000x1000 3D buffer" test, he scored a clean 20 FPS (Or so, slightly noticeable frame lag, but damn close to smooth,) after standing there and letting the place fill up with character models. This makes me one very happy person.

The funny part though is the number of people who don't understand why a .5 Ghz processor clock increase (1.73GHz for the 2100+ and 2.2GHz) such a big change in power. And the first hint I'll give these people is: The CPU clock upgrade wasn't why I did it. Turns out that one of the biggest shortcomings of computer architectures is that the CPU needs to access the ram on a VERY regular interval. But unfortunately, the channel that carries the info to and from the CPU is MUCH slower than the CPU. So the reason I purchased the 3200+ XP CPU was the fact that the 3200+ XP (Barton) is designed for the 400MHz Front Side Bus (Well, actually 200MHz, but on both the rise and the fall...) Since the Front Side Bus (Or FSB) is the part of the computer that connects the CPU to the memory, it would follow then that I've effectively doubled the speed at which my computer can communicate with the RAM modules. Because of this, even a slower processor can get faster speeds because it spends less time waiting for memory transfers to occur. Now don't get me wrong, the increase in the CPU DOES matter (Especially since I moved from the thoroughbred core to the Barton core,) but memory is going to be the grand daddy pappa of the process. However... There is ONE tiny thing I overlooked in my upgrade...

column Access Select Latency (or CAS Latency). See I purchased CAS 3, when I really should have purchased CAS 2. The cost differential and the speed differential are about the same, Single digit improvements, but the eligibility for overclocking is much better. But then again, it's really not an issue because I'm not overclocking my system (Nor do I have plans to.) But it does matter. Now that I think about it, I'm using CAS 2.5 timing... Probably why I can't get my chipset to run in turbo mode, probably sends the memory requests a bit too fast for the ram. I'll have to tinker with that later.

Vroommm!!!

Mood: ecstatic