Memos From the Cube

Yesterday, I bought a new external drive for my laptop. This one’s a full desktop-sized driver in an external case rather than a laptop “portable” external drive like my existing external. Both coincidentally happen to be Maxtor Onetouch products, however in the external market not much matters other than the quality of the drive inside. Having a new 750GB external for my media is a great thing; it frees up the 120GB mini external for backups, and my laptop’s internal 120GB for programs.

There’s only one problem; 750GB it ‘aint.

As anyone in computer science knows, 1GB is 1024MB. This is due to everything being specified in powers of 2 rather than 10, as computers use a binary two-state storage mechanism. However, in the storage market, the more literal interpretation of the “Giga” prefix yields 1GB = 1000MB. While technically accurate due to the use of the SI prefix “Giga”, it goes against all of Computer Science and digital history, and is used for only one reason: money. By shaving a few megabytes off each gigabyte in the true capacity, the drive can be marketed as something it isn’t — for example, my new 750GB (from the box) appears to the OS as a 698GB disk, a loss of 52GB, or 7% of the stated capacity.

The situation is so bad, a new set of prefixes have been standardised to reduce confusion - enter the Gibibyte (GiB), Mibibyte (MiB) and Kibibyte (KiB). Each of these are the binary power-of-two honest-to-god real Computer Science definitions of the respective data sizes. Despite this, these prefixes are rarely used outside of the Linux and *nix realms, and thus OSes such as Windows still use the common Gigabyte, Megabyte and Kilobyte distinctions in the power-of-two sense, rather than the power-of-ten sense.

That means that the only people who insist on using the 1000MB = 1GB definition are the storage manufacturers, who have a definite advantage to doing so, since it allows them to sell products with less capacity than expected. In fact, the Seagate (owner of the Maxtor brand used on my new drive) has this to say about the subject:

Once upon a time, computer professionals noticed that 1024 or 2¹⁰ (binary) was very nearly equal to 1000 or 10³ (decimal) and started using the prefix “kilo” to mean 1024. That worked well enough for a decade or two because everybody who talked kilobytes knew that the term implied 1024 bytes. But almost overnight a much more numerous “everybody” bought computers, and the trade computer professionals needed to talk to physicists and engineers and even to ordinary people, most of whom know that a kilometre is 1000 metres and a kilogram is 1000 grams.

What utter tripe. Everyone excluding storage manufacturers use the power-of-two system, thus I say the manufacturers are breaking user expectations by representing their capacities in the “incorrect” base system. If a user sees 750GB on the box, he or she expects the computer to recognise it as 750GB, regardless of the base system. Storage manufacturers should give their capacities in the same manner as the OS, to reduce confusion. The fact that the above article is even in the Seagate knowedge-base to begin with is ample proof of this. Users don’t care how many MB are in a GB, just so long as what’s on the box is what’s shown in the OS.

I wonder what Seagate’s response will be if I ask for 7% of my money back, to cover the discrepancy.

I’ve not been completely idle these past few days, despite “being on holidays” from University until next semester starts in 2009. On Monday and Tuesday, my friends and I undertook some work from my microprocessors lecturer to design and build some low-cost educational robots for use in schools to get young students interested in the world of electronics.

We ended up with two prototypes, a submarine built by myself and my friend Luke, and a obstacle avoidance robot built by my friends Alan and Jim. Both are made from cheap components (PVC tubing, foam, film canisters, hobby motors, etc.) and are specifically designed to be educational rather than amazing feats of engineering. The submarine shown here uses three hobby motors mounted in film canisters and sealed with electrical tape, petroleum jelly and blue-tack for propulsion and dive/surface control:

Pictured without the right propellor, as we only had two at the time, and were testing the third (dive/surface) motor when the photo was taken.

The second model to come out of what can only be described as a Mythbuster’s lab was the avoidance robot, pictured below. Built using a CD as a base with small Perspex wheels lined with rubber bands for traction, it ended up working reasonably well, for a design with zero components other than batteries, micro switches and motors. Of course, I was itching to put in an ATTINY to make it somewhat intelligent, but alas that was out of the project’s complete-beginner scope.

Aside from the above, I’ve also been busy working on some more contract work over at the local Alfred hospital, continuing my work on a blood barcoding project which is progressing slowly but surely. In my downtime at night, I’ve been working on my Ray Tracer I blogged about previously, to improve its capabilities somewhat. I’ve managed to accomplish the following in the last week:

• Fixed shadowing - was accidentally taking the compliment of the shadow factor
• Fixed horrible hack for preventing secondary rays from returning a collision with the stating object - a better (and common) hack of moving the start point slightly in the ray’s direction fixes “invisible starting object” problems I was having when calculating shadows
• Added Max U/V values to the TexImage image texture object, so that the texture image can be tiled any number of times across an object
• Added correct Phong shading, moving the ambient light to a constant rather than a lighting object for speed, including correct diffusion and specular lighting
• Added in translucency support for transparent or semi-transparent objects
• Added in spot and flood lights in addition to the existing omni light lighting object
• Added refractions and corrected reflection mixing routine to give better results

The results of which are much better than the previous code’s output (click to enlarge):

EDIT: Added photo of avoidance robot - thanks Jim!

A quick update, so that people actually notice it; I’ve created a new MyUSB suggestion box Wiki. Feel free to post your development suggestions there — anything (related) is fine, so go nuts! I’ll tag suggestions once they’re implemented, or I’ve read and decided against them (I’ll give the reason alongside the original suggestion).

Suggestions I deem feasable to implement will then be transfered over to the MyUSB bug tracker as an enhancement request, whereupon I’ll implement the proposed feature.

What are you waiting for? Go make yourself heard and leave a suggestion on the MyUSB Suggestion Box Wiki!

Woohooo - exams are officially over! I’m now a free man for the next few months, excluding any contract work I decide to take up. Yesterday I recieved my results for my Java Algorithms class, which was to design an efficient (non-database) transaction system for a ficticious phone company. Emphasis was placed on efficiency, which was a nice change from regular “whatever works” Java classes; I got to do some proper profiling of my Java code and ended up with something quite decent (the fastest in the class, in fact).

From that, I’ve learned one interesting thing: Exceptions really aren’t that bad. Last year when I first started out into the mystical land of Exceptions I honestly couldn’t see the appeal — it just seemed like an alternative to the tried and true method of returning an error code in a function. Of course, I’ve since seen the light and I realise how powerful exceptions are and how much clearer exception handled code can be in contrast to the old methods. The fact that my assignment was the fastest (slightly edging out my friend Alan, who took a very similar approach to mine minus all the exceptions) seems to reinforce that notion.

I’ve also discovered the fearesome power of hindsight, along with my other discovery that Javadoc/Doxygen comments don’t have to make your code into a complete an utter unreadable mess. I really wish I found that out for myself sooner, since I’m now stuck documenting all my demos in the MyUSB library — and there are a lot of demos. Still, with the addition of a few extra “articles” in the documentation on how the demos work from a higher level than the raw code, the next release should be sock-propelling-off-feet good. There are a lot of other changes to the library scheduled for the next release as well, of course, including a fixed and cleaned version of the DFU bootloader — no more bugs and wonky logic!

I’m thinking of setting up a freely editable “brainstorm” wiki, for people to leave suggestions for me - either new projects, interesting things to investigate, or ideas on inproving my existing projects. The comments I’ve recieved here and via email have been good, but I’m perpetually in danger of losing some of them, so a Wiki or something similar seems like a good idea to me.

UPDATE: I’ve started the new suggestion Wiki here: http://wikihost.org/wikis/myusbsuggestion/.

Next week I’ll be attending my final two exams for the year, first DDP (Digital Design and Programming — essentially, a beginner’s course to the VHDL language on CPLD chips) on Monday, then ALG (Algorithms) on Thursday. Neither are particularly difficult in the brains department, but both require a lot of memorizing. While I fully understand all the algorithms covered, I do think it’s a bit much to make students remember every possible case for every covered algorithm for repitition on demand — Red-Black Trees alone have a good five seperate cases for insertion. I’ve always been cursed with a poor memory, so I’m possibly doomed on that alone.

On a brighter note, Gary sent me a link to his own blog, detailing some of his AVR exploits, the most recent of which is MyUSB related. It’s always gratifying to see my work being used by both commercial and hobbyists - the latter was a great consern in the design of the library, since commercial outfits would use a bad library warts-and-all if no alternative was avaliable. It’s fantastic to see that people are using it for their personal projects, proving to me that it is at least somewhat accessible to the normal AVR folk out there.

During the course of our exam study the other day, myself and my techno-geek friends got to discussing absurd communication mediums. Honestly — the lot of us looked almost identical to the characters in the awesome show “The Big Bang Theory”, with a tablet PC connected to our TV, and iPhones and laptops flying every which way. That’s neither here nor there however, as the discussion moved from the mundane (TCP/IP over LEDs) to the outrageous (TCP/IP over SMS). This was my suggestion; correctly coupled with a free online SMS service, it would be theoretically possible to write a proxy which sent out TCP/IP packets over 150 byte long SMS messages.

I don’t think SMS supports much other than the basic latin alphabet, so that means that packets would be base-64 encoded. A typical TCP/IP data packet (as opposed to a non-data containing signalling packet such as an ACK, SYN or FIN) header is around 50 bytes, so there would be sufficient space for a tenth of a kilobyte or so of data to be transmitted per message. I can’t imaging the phone company being to happy about the torrents of messages it would produce, but the TCP layer would ensure data integrity on the recieving end (even for out-of-order packets) and would probably out-strip GPRS anyway ;).

I really should spend more time studying.

The first two of my exams are over, and I’m thankfully still alive - although somewhat battered. Tomorrow brings my Analogue Electronics exam, soon followed by my Calculus Maths exams, then my…on second thought, I need to have a lie down.

I’m still working (slowly) on the MyUSB documentation, but exams are taking priority — and there really is a mountain of work to be done, with each demo taking at least half an hour. On the plus side, I’ve taken the opportunity to clean up other areas of the documentation, so the next release will have more information pages.

Yesterday I used some downtime after an exam to work on the RNDIS MyUSB demo. The RNDIS (Remote Network Driver Interface Specification) demo is an implementation of Microsoft’s RNDIS protocol, used to create USB-over-Ethernet devices via a virtual network adapter. My previous efforts made a working implementation on top of which I hastily wrote a TCP/IP stack - but it left a lot to be desired. For one, you couldn’t close the connection from the application side, so the webserver demo left connections opened indefinetely.

My work yesterday was to implement proper application closing code, so that the established connection can be cut via a FIN message and a transition to the CLOSING and FIN WAIT 1 TCP states. I also took the opportunity to fix a few of the poor code which left it anything but a standards compliant TCP/IP stack. The result is still not clean nor fully complaint, and I recommend replacing it with a properly written stack like uIP for full functionality, but it serves as a working demonstration.

Aside from the documentation I’m really running dry on further development ideas. I’m going to investigate host-side driver development and the TMC USB class, but if you have any ideas of your own to share, leave a comment!

One thing I’ve learned in the last week - everyone loves a good ray tracer. Even my first, poorly written one. It seems that every man and his dog who has ever touched a computer has written one, and is able to give me advice. That’s a neat feeling; I’m following in the footsteps of many of those before me, and poorly reinventing the wheel for my own amusement and education.

I’ve just submitted my course enrollment for next year. It seems my fears about my failed calculus unit in first year preventing me from doing anything until I’ve completed the subsequent maths units is unfounded, as while I have different units to normal students in my course this and next year (due to the shifted maths units), I’ve still got a normal workload. It sucks that my course will be extended by at least six months at the end due to my inability to keep up in second semester last year, but it’s a part of life and something I cannot change.

For my specialties next year, I’ve decided to skip database fundamentals - I already have them, “DROP {Tablename}”, “TRUNCATE {TableName}”, “‘ OR 1=1″, *grin* - and go for the network engineering instead. That means I’ll be learning TCP/IP for real next year, which should cement the knowedge of TCP/IP I gained this year while writing my RNDIS Ethernet USB demo application for my MyUSB stack.

Speaking of the MyUSB stack, I’ve bitten the bullet and started to fully document all the demos with Doxygen. That means that the next release will contain function, macro, enum, file and global documentation for all of the demos, projects and bootloaders in the MyUSB library. It’s an absolutely enormous amount of work to be done, which will delay 1.5.4 for quite a while, especially due to my end of year exams which start in two days. Pray for my sanity, or better yet, donate!

My continued apologies to anyone whose messages to me I’m neglecting while I study for my exams. Please be patient, and above all understanding!