I've got another grab-bag of miscellaneous news for this post, but I'm going to lead off with the big one: I'm going to be a presenter at the world's preeminent QRP convention: Four Days In May 2012. The tentative topic for my presentation will be about the free and open source tools that I use in the development of my products and how you can put them to use in your own homebrewing endeavors. This will be my first time speaking to an audience larger than about 25 people, so I hope that I can provide an entertaining and informative talk at such a prestigious event. I'll be speaking in front of a lot of people who I consider to be much more capable than I and some who I consider my virtual Elmers. It is my sincere desire to not disappoint.
I am very excited for the opportunity to go back to Dayton so soon after my last trip. I really didn't expect to have the chance to go again for quite a few more years, so the ability to get back to the convention after only two years is a great blessing. I owe a great debt of gratitude to Jennifer, who didn't hesitate to encourage me to go, even though she will be dealing with a 2-month-old baby and a near 2-year-old by herself for a few days while I'm away.
In other news, I feel like I've gotten over the steep part of the learning curve with Kicad, having successfully made PCBs for my little Twin-T code practice oscillator. You can see a short video of it in action above. The output level is suitable for modern, sensitive headphones, but if you want room-filling audio such as in my video, you'll need to connect it to an amplified speaker. The PCB is designed to fit in the ubiquitous Altoids tin, with room to spare for a 9 V battery. I expect that this will eventually make it to my stable of products, but it's low priority considering the long delay on the CC-Series and the need to get it ready to sell by May. If you are really interested in the project, write a comment or shoot me an email (milldrum at gmail) and I'll see if I can't work something out to get you hooked up with a kit early.
The OpenBeacon project is cruising right along. Now that I know that I can successfully make a PCB with Kicad, I've taken the plunge and decided to migrate all of my workflow there (I think this will include the next board spin of CC-Series, since there are so many changes to be made there will be no real advantage to staying with TinyCAD/FreePCB). The OpenBeacon PCB design is nearing completion. Once I get a shipment from Mouser in the next few days to verify that my newly-created PCB footprints match the actual physical components, I'll be ready to submit my CAM files to Seeed Studio for prototype boards. With any luck, I'll have them back within about two weeks. (Protip: it's worth taking the time to place your component against a 1:1 printout of your Gerber to make sure it will fit. Don't ask me how I know this.)
Once those CAM files are off to China, it will be full-bore on the CC-Series. With the deadline of mid-May staring me down hard, I figure I will have to get those CAM files out within no more than three weeks. That will put me into mid-March for getting the PCBs back, which will give a pretty slim margin of time to beta test and prepare the kit for final sale. Going to be pulling some long, late-night shifts...that I can already see.
I've also got a few more projects in the pipeline for after FDIM and the deployment of CC-Series and OpenBeacon. The first is a fairly simple and inexpensive VXO DC transceiver that I hope to initially kit for the high bands of 10, 12, and 15 meters. It uses a topology which is somewhat unique. The other is an extrapolation of the receiver circuitry of this rig to use as a dedicated QRSS grabber receiver. But I may be getting a bit ahead of myself. Let's get this CC-Series launched, then see where the winds take us.
Tags: cc-series, dayton, fdim, OpenBeacon
The year is not starting out as well as I had hoped. Back during the beta test of the CC-20 I had set a goal to complete my revisions and be ready to sell production kits by 1 January 2012. Obviously that date has come and gone and I'm still not on the market. A few circumstances have contributed to this situation. First, the days available for me to work exclusively on Etherkit has been cut from 4 per week to less than 2 due to family member's work schedules being changed. Second, it took me longer than expected to tackle the bugs in the CC-20 beta; the worst being the high number of spurs in the receiver.
So where does thing sit right now? The next CC-20 board revision is just about ready to be implemented. I've had to move to a DDS with a higher master clock frequency and change out the product detector from a dual-gate MOSFET to a diode-ring mixer. One advantage of the new DDS is that I can greatly simplify the transmitter circuitry, but this will require the trade-off of a fairly significant revision of the PCB.
I have been getting my PCBs manufactured in China, and right now many of the manufacturing firms (my board house included) are shutting down for two weeks to observe the Spring Festival (Chinese New Year). So even if I do send my Gerber files to the board house, they probably won't be back for at least a month. In the meantime, I've decided to work on a side project that's been rattling around in my head for a while: a QRSS/CW/Feld Hell/Etc. beacon. Also, in response to a lot of positive response that I have received from my simple Twin-T code practice oscillator, I also spent a few days revising the circuit to make the output a bit more robust and then created a PCB for the circuit in Kicad so I could transition my EDA to an actively developed software package (I was using TinyCAD/FreePCB previously, which seems to be pretty much a dead end).
OpenBeacon Prototype
So allow me to tell you a bit more about the beacon project. For now, I've decided to dub it OpenBeacon (I know, so very original). But there is a decent reason for the name. Much like the CC-Series, I intend for this project to fill a niche in the market that is very empty right now. The list of notable open source/open hardware kits out in the market is very small. The only one I think of off the top of my head is OpenQRP. As far as QRSS kits, I'm only aware of the one from the talented Hans Summers. My goal for this project is to provide a kit that is open, extensible, relatively inexpensive and simple, and ripe for user modification. Let me tell you a bit more about the project specs and how they fit into this goal.
Let's start with the bare hardware. The transmitter is a standard, vanilla Colpitts oscillator followed by an emitter follower buffer, which feeds a class A PA with fully adjustable output power (provided by a very cheap and cheerful part, the BD139). At full-bore with 13.8 VCC, the transmitter can put out about 300 mW into 50 Ω. The brains of the operation is an Atmel ATtiny85 microcontroller. The way that it interacts with the transmitter is via its PWM output, which can generate a voltage from 0 V to 5 V after proper filtering. This control voltage is fed to a reversed-biased LED which acts as a varactor to tune the oscillator in very tiny amounts (< 10 Hz). The PWM output is essentially an 8-bit DAC, so not only can the varactor be flipped between 0 V and 5 V, but it can be set to many intermediate values, which allows for things like Feld Hell and just about any kind of graphic or glyph you can think of to be transmitted. The transmitter PA is also keyed with a PNP transistor which is controlled by the ATtiny85, which allows the OpenBeacon to operate in standard CW beacon mode.
The main way in which this project will meet the goals I stated above is in its user interface. There is a handy open source project called V-USB which gives USB interface capability to AVR microcontrollers that do not have USB built-in. This allows me to wire a USB port to the ATtiny85 and have the V-USB firmware take care of all the ugly business behind the scenes so that I can focus on interfacing the OpenBeacon to a PC. With a simple command line program, the user will have the ability to switch between the many operating modes available, set his own callsign and beacon message without having to have the microcontroller programmed for him, upload custom glyphs to be transmitter, and monitor the status of the beacon. No need to mess with jumpers or in-circuit programmers (although the ISP port will be available for those who want to hack their OpenBeacon). The client program is written in C and should be able to be compiled for Linux, Windows, and OS X machines.
KI6FEN Grabber Capture
Right now, the prototype is pretty much complete save a few minor tweaks. Yesterday, I got the code for the CW modes completed and put the beacon on the air in DFCW 6 second dit mode just above 10.140010 MHz. Conditions weren't great, but I did manage to get a few weak captures on the KL7UK grabber and one from KI6FEN via Twitter. The signal was way too wide and extremely drifty, but I've solved those problems by changing the coupling capacitor between the LED varactor and the oscillator and by creating a rudimentary thermal chamber for the beacon out of pink antistatic foam. I'll be leaving the beacon on for the next few days when I'm not working on the project (which will be most of the day). Any reception reports would be greatly appreciated!
So the plan is to get the CC-Series PCB revisions hopefully done by next weekend so that they can be sent off to the board house before their vacation is over. In my little bits of downtime, I'll continue work on the code for the OpenBeacon. The plan for this project is to get the PCBs cranked out very quickly. Now that I'm familiar with Kicad, I think it won't be too difficult or take too long to design the boards. I'm also going to be trying out a new PCB vendor which promises much cheaper prices and faster turnaround times on smaller boards such as this. With any luck, I can fast-track OpenBeacon testing and production and have it out while the CC-Series is in it's final beta test. Stay tuned, this is make-or-break time!
Tags: avr, cc-20, cc-series, OpenBeacon, QRSS
This post is a bit late, but I wanted to be sure to document my first attempt at a SOTA activation and what I learned from it. The title is probably a bit harsh, but the eternal pessimist in me couldn't help it. I decided to attempt a SOTA activation after seeing a lot of increased activity from my esteemed ham colleagues such as KK7DS, KD0BIK, and of course the guy who probably introduced most of us Americans to the activity: WG0AT. I've always loved outdoor hikes and have done my share of outdoor operating from parks and campgrounds, so the idea of packing a portable station up to the top of a local peak has been sounding appealing for quite a while now.
The plan was put together with much haste, as I wanted to get up in the mountains before any bad storms hit. I used the tools at SOTAWatch to find some candidate peaks that were within reasonable driving distance and not very high, then digitally scouted them using Google Earth. The initial research yielded a list of about 5 candidate peaks which fit my criteria. After more studying, I decided to try for Clatskanie Moutain W7/NC-039. It's roughly 60 miles from my house, which translates to a one-way drive time of about 1.5 hours. The logging road from the highway to the peak was only about 3 miles, and it looked like I could drive all the way to the peak if I wanted to. The plan that I had in mind was to park at the cutoff to the little spur road that branched off to the peak. The distance from this intersection to the peak is only about 500 meters, an easy hike, but one that would fit within the spirit of the SOTA rules.
After deciding on a peak, I managed to rope Dave W8NF into going on the trip with me, a decision that I would be very grateful for later. Since I recently sold my FT-817, the only portable radio that I currently have is my CC-20 beta unit, and it was in a bit of a torn-up state since I've been making corrections that will be implemented in the final version. I also wanted to do some 10 meter operation, so I thought it would be fun to slap together a VXO-tuned DSB rig that might allow me to snag a few voice QSOs. Without getting into the painful details, I worked furiously to build the DSB rig and get the CC-20 back into working condition (without a proper enclosure!). In a homage to my school days, I didn't finish until late night just before the day we were to go on our little expedition, and even then I wasn't sure that my 10 meter DSB rig was working correctly.
So the designated day, Saturday, 3 December came around and I was running on about four hours of sleep, but still excited to get up around 8 AM to get going. By 9:30 AM, I was out the door, able to grab my coffee, and get to Dave's house. We quickly made way to the peak, and had little difficulty finding the logging road off of the highway that would take us up to the peak. There was only one small problem. The gate was locked. I should have done better due diligence (such as experienced SOTA expeditioner KK7DS explains here) and picked up a proper topo map from the local forestry office. I was planning on a short hike to the peak, but I really didn't want to turn around and drive back 1.5 hours having not even tried. I knew we were about 3 miles from the peak, which was a bit of a hike for some one as out of conditioning as me, but I felt I could probably hack it. Graciously, Dave agreed to hike it, so we grabbed our packs and I lugged the bulky, oversized sack with the Buddipole and we made way for Clatskanie Mountain. Fortunately for us, the weather couldn't be any better for a December trek in the Oregon Coastal Range. The skies were mostly clear, with just a bit of high clouds and some patches of fog below us.
We had a pleasant hike up to the peak, and while I (the guy who is mostly sedentary and fat) had to stop for frequent breathers, Dave (the guy who runs half-marathons) didn't seem to have too much difficulty with the 3 mile hike and 700 foot elevation gain. When we reached the peak at sometime around 1:30 PM, we were greeted with a very spiffy microwave tower and wonderful view of the Columbia River below us to the north. The temperature was chilly (I'm guessing around 35° F) but the wind was slight.
There was a large earthen berm behind the microwave facility that gave us a point to operate with the mountain sloping away west, north, and east. I brought along my EFHW antennas, but decided not to deploy them at first since there weren't any trees at this location. I deployed the Buddipole in L-configuration with Dave's help and he broke out his FT-817 and started listening on 10 meters. As expected, the bands were ultra quiet up here far away from any big RF noise generators (save that big microwave tower right behind us!).
While Dave sent out some CQs on 28.060 MHz, I unpacked my DSB radio and the CC-20 beta. Dave didn't have any luck getting responses, which struck me as a bit odd. We could hear plenty of signals, and we had his Elecraft T-1 in-line and tuned-up. So I decided to try the DSB radio. A few quick cable changes and it was ready to go. Only one small problem. It was completely deaf. Well, that's what I get for trying to get a radio on the air in such a hasty fashion. I felt bad because I knew that there were people listening for me on my pre-spotted frequency of 28.650 MHz, but somewhat surprisingly I was wasn't successful in getting cell service on the peak, so I couldn't spot a new notification. Sometime around these events, the wind started picking up, making the temperature feel wicked cold with the wind chill factor.
So next up was the CC-20. Again, dead as a doornail (I later found out that it was a bad solder joint in the VFO circuitry that popped loose on the hike). Dave was kind enough to let me use his FT-817 to try to get my four required QSOs to count for a proper SOTA activation. The 10 meter QRP watering hole was awfully quiet, but I figured that some CQing should bring people out. Turns out that I didn't have much luck. I managed to work a weak WA8REI, then a booming JA1KGW (this guy is an awesome QRPer). By this time, both Dave and I were getting awfully cold. The wind seemed to be getting stronger and the temperature felt like it kept dropping. My further CQs were going unanswered, so I thought that 10 meters might be starting to close up and that we should move to 20.
We quickly re-resonated the Buddipole for 20 meters and re-tuned the T-1. I tried calling CQ on a few different frequencies near the QRP watering hole, but never did get any calls on 20 meters. I'm not sure how long I tried calling, but I didn't have a memory keyer to use, so I was manually sending the CQ each time, and it was getting sloppier and sloppier due to my numb hands. Poor Dave was pacing around to keep warm by this point. As much as it killed me to leave before activating the summit, we we both very uncomfortable and needed to leave soon regardless, because we only had about 1.5 hours of sunlight left at this point.
All of our stuff got packed up in record time and we started downhill at a brisk pace. But only a few hundred meters from the peak, my leg started cramping up bad from the cold weather. A bit of stretching worked it out, but then it kept recurring every few hundred meters! We both wanted to get back to the warmth of my pickup as fast as possible, but my leg was not cooperating very well. Dave patiently waited as I stopped each time to try to work out the leg cramps. Although it took longer than expected, we did reach the gate right when the dark was really starting to set in. Getting back in the truck and heating up my body mercifully ended the awful leg cramps.
I'm a perfectionist by nature, so it still bothers me that I didn't get my activation of Clataskanie Mountain. And it's tough to try to demonstrate the fun and effectiveness of QRP to a non-QRPer like Dave when you have such a lousy radio day as I did. I am very glad that Dave was there, as I might have stayed on the peak too late to get back before dark if I was only thinking of myself and of trying to complete my activation. I also realized that a nearly 7 mile round trip hike for a unconditioned hiker such as myself would have been incredibly foolish. If my leg cramps had been worse, I could have been stuck up there in the dark over night. I used to hike like this with no problems, but I have to remind myself that this was 10+ years ago and that I was in much better shape then.
It's a cliché, but I did learn a lot from the trip, regardless of the radio results. I do intend to try it again in the spring, once the bad winter storms have passed and I have my radios really ready to go. Stay tuned for further adventures!
Tags: Clatskanie, KD0BIK, KK7DS, sota, W7/NC-039, W8NF, WG0AT
I'm in the process of selling off some of my ham radio stuff so that I can fund further development of the CC-Series. Right now, I've got a Yaesu FT-817ND along with a few other items for sale. I've also got a very lightly used Kindle with the leather case with integrated reading light. Occasionally I will be posting more items there, so please check back periodically. Thanks!
Progress on CC-Series development proceeds at a reasonably-good clip right now. One of my last big hardware bugs to stamp out is some nasty microphonics that seem to be generated by the combination product detector/BFO. Today, I believe that I made some significant progress towards solving it and wanted to share what I learned.
IF Amp & Product Detector from CC-20 Beta 1
I've done a lot of reading in Experimental Methods in RF Design (EMRFD) about microphonics in DC receivers (read chapter 8!), and the number one cause of it is poor LO-RF port isolation in the mixer. The CC-Series uses a venerable old circuit which hasn't seen much use in a while. A dual-gate MOSFET is pressed into double-duty as a product detector and BFO (see above). Since the dual-gate MOSFET product detector is in a single-ended configuration, it inherently has bad LO-RF isolation. This allows VFO (or BFO in this case) signal to leak out the product detector input, and have a good portion of that signal reflect back into the product detector. So naturally, the CC-20 could be experiencing the microphonics because of this phenomena. One of the solutions mentioned in EMRFD is to put an amp in front of the mixer which has excellent reverse isolation (signals coming into the amp output don't tend to get out of the input, and therefore can't reflect back in again).
I had the suspicion that the common-source JFET amp in front of the product detector might be the culprit. So what's the best type of amp to place in front of a single-ended mixer? The common-gate JFET amp is a good and popular choice. However, VE7BPO notes on a recently published web page that the best commonly found amp configuration for this particular parameter appears to be the cascode (see the bottom of the page).
In order to test this theory, I went to work on a project that I had set aside earier: a direct conversion receiver based on the CC-Series product detector. When there was no preamp in front of it, the microphonics were unbearable. I figured that a good way to test my theory would be to put a cascode amp in front of this mixer and see how much it helped. I decided to put a dual-gate MOSFET preamp in front of it, as this is essentially a cascode amp and it fits with the dual-gate MOSFET product detector. Once the new preamp was added, the change was dramatic. The microphonics were gone.
Next, I decided to be a bit more rigorous in my study and quantify the exact difference between the common-source JFET amp and the dual-gate MOSFET amp. First I breadboarded the common-source JFET amp and ran it through the test procedure in the page linked above (at 18 MHz). The results were atrocious. Only 30 dB of reverse isolation, which is worse than the worst amp listed there (the feedback amp). Next, I dug out an old dual-gate MOSFET amp I had breadboarded for my 2008 investigations and ran it through the same test. As expected, the results were vastly superior: 68 dB of reverse isolation. This lines up nicely with Todd's measured results of >64 dB for the hybrid cascode (I used a spectrum analyzer while he used an oscilloscope, so I was able to get a pretty good measurement down to low signal levels).
So this appears to be strong evidence that the IF amp is the problem. It seems certain that the next version of the CC-Series is going to scrap those awful common-source amps for a much nicer dual-gate MOSFET amp. The lesson to take away from this is that if you are going to use a single-ended mixer for any but the most simplistic applications, it must be fronted with an amplifier with an excellent reverse isolation. While the typical common-gate JFET amp will work OK, for best results it looks like a cascode or dual-gate MOSFET amp is the way to go.
Tags: BF991, BF998, cascode, cc-series, dc, microphonics, mosfet, VE7BPO
I don't know exactly why, but I've had a bit of an obsession with the T32C DXpedition to Kiritimati since they got started a few weeks ago. Maybe because I found them easier to work than many of the DXpeditions that I've tried before. The fact that they are a very well-run operation has something to do with it, I'm sure. Whatever the reason, once I got a few contacts under my belt, I became driven to try to work them on all band slots practical for CW and SSB. I have a ZS6BKW antenna, so I can load it up from 10 to 80 meters. I figured 10 — 80 was a reasonable goal, but I knew the lower bands were going to be tougher since my antenna is only up at about 30 feet.
With the bands being as hot as they have been in the last month or so, it hasn't been a great challenge to fill up the band slot chart for the most part. Almost all of the QSOs made over the last few days have been snagged within one or two calls (I also thank W9KNI's book The Complete DXer for teaching me very valuable basic DXing skills). I will admit that I've been running 100 W output for these QSOs — with one important exception.
20 meters CW was one of the slots that I had not yet filled as of this morning (oddly enough, since that's THE DX band). Over the last few weekends, I've been hacking away on the firmware to the CC-Series, trying to get the last major features up and working bug-free. Thanks to a request from AA7EE, I just implemented XIT on top of the RIT that was already in the firmware (speaking of Dave, go check out his even more impressive T32C QRP story). The nice thing about XIT is that it allows you to relatively easily work split stations like DX, even though there is no "official" dual-VFO capability in the rig. Since the XIT capability seemed to be mostly working correctly, I wanted to put the CC-20 on the air to try it out and be certain. The first station that I worked today with the CC-20 was K6JSS/KL7, operated by well-known Alaskan QRPer AL7FS. It was a simplex QSO, but it was nice to bust the mini-pileup with my first call. While continuing to work on CC-20 development, I monitored the DX cluster to see when T32C would show up on 20 meters. Sure enough, I ended up seeing him pop up on the cluster at about 0200 UTC. Time to put the CC-20 to the test.
I don't have a valiant battle to describe. It took me about 10 calls to finally get him, although there weren't a lot of people calling him. I suspect that the majority of my trouble in getting him was in zero-beating him with the unpackaged encoder knob. While in RIT or XIT mode, pressing in the tune knob toggles between the TX and RX VFOs. Trying to do that quickly when it's not mounted on a chassis is tricky! Regardless, it didn't take long until I heard the sweet sound of my callsign coming back to me across the vast Pacific Ocean. Two watts spanning 3600 miles to a tropical island in the middle of a huge ocean is pretty neat. This doesn't rank in the annals of great QRP achievements, but it will always be a memorable QSO for me.
I'm happy to report that the second of four CC-20 beta kits is completed and working! Mikey, WB8ICN got his all finished up with no major problems and made a first QSO with N1WPU. It looks like he made a nice custom enclosure out of some very sturdy copper clad. Very, very nice! Please click on over to Mikey's blog and have a look for yourself.
During some discussions with AA7EE regarding a seeming lack of 20 meter propagation between us at any time right now, we both decided to do a bit of research into what was even feasible according to predictive software. Dave went to the VOACAP web service from OH6BG to get some nice plots which showed that indeed it would be nearly impossible for us to make a 20 meter QSO right now.
The web site is nice, but being a Linux nerd, I wanted to see if I could find comparable software for my PC. A small bit of searching led me to VOACAPL from HZ1JW, and the matching package pythonProp, which gives a GUI frontend to the CLI VOACAP interface.
The installation of the VOACAPL software is quite easy if you are using Ubuntu. Just download the .DEB file and install using your favorite package manager. Installing pythonProp is a bit more involved, since there are a fair number of dependencies to install first, but as long as you closely follow the instructions on the website it shouldn't be much of a problem.
If you are like me and the thought of tackling VOACAP through the command line was a little bit daunting, then the voacapgui tool (in the pythonProp package) is just what you are looking for. The GUI has three main tabs for interacting with the program: one for the site information (transmitter and receiver QTH, antenna, and power), one tab to execute point-to-point channel analysis, and one for generating area propagation maps.
As you can see above, the P2P tab can get you a nice plot of the probability of making a QSO over a certain path with the specified antennae and power levels. And since this is a Linux port of the program that Dave used on the web, the data we got back was nearly identical. No 20 meter QSOs for us right now.
Here you can see an area map showing circuit reliability for 7 MHz at 0300 UTC during Oct 2011 using 5 watts. That doesn't look very good! (Sometimes I wonder if the predictions for low power are a bit out-of-whack. This software was originally written for VOA, so I wonder if it's really calculating the reliability for a 5 W AM signal. I am a total novice at this, so I expect some VOACAP expert will probably put me some knowledge on this, as the kids say).
Any way, it's a neat package to play around with if you have a Linux box. Many thanks to HZ1JW for taking the time to port VOACAP over to Linux in a easy-to-use package.
Update
Sure enough, I made a mistake. Had I read the documentation more thoroughly, I would have seen that parameter Required SNR was set to a default suitable for SSB. At least I was onto the right idea a few paragraphs above. Here's the same area plot as before, but with the Required SNR set for a suggested value of 24 for CW operation.
That looks better!
AA7EE CC-20 Beta 1 Interior
AA7EE CC-20 Beta 1
Here it is, the first CC-Series beta unit completed by someone other than me! As is obvious by glancing at the photos, Dave AA7EE has done a magnificent job of assembling the CC-20, as well as creating a custom enclosure for the radio out of red copper clad using the WA4MNT technique. There's really not much more for me to add, except to tell you to get yourself over to Dave's blog to check out his story about the build and to see more shiny photos.
No earth-shattering news to report on the blog, but a few little things to mention (hence the "junkbox" title).
The CC-20 Beta 1 test is proceeding pretty much as planned. As of tonight, AA7EE has his receiver up and running now and a couple of the others are close behind. I'm eagerly awaiting the results of at least a couple of the builds so that I can get moving on the revisions for the Beta 2 circuit (which will hopefully also be the production PCB). I'm anxious to get the business up and running!
I got a very nice mention from Bill Meara on the latest episode of SolderSmoke. He talks up Etherkit and my blog, then mentions that he's going to try to use the single-ended passive MOSFET mixer from the VRX-1 in his homebrew WSPR transceiver. I hope that the experiment works out well for him.
As we approach the halfway point of the gestation of our new little one, I got to thinking about mortality a bit. I hope to be around for a very, very long time to come and have been taking steps to improve my health to make that more probable. But in the awful case that something were to happen to me in an untimely fashion, it seemed that I'd like my family to have a little bit of my own thoughts with which to remember me. At first, I thought that maybe I should do a private journal, but then it occurred to me that wasn't necessary. Barring a complete collapse of civilization, all of my descendants will be able to access an archive of all of my Internet activity. Every blog post, tweet, Google+ post, website comment...and perhaps even my email. If you Google my last name, I'm the first result. I'm active enough online that it's not entirely inconceivable that a reasonable avatar of myself could be created sometime in the distant future (given that Moore's Law holds up in some fashion for the next 50 years or so). Perhaps this is all pie-in-the-sky speculation and will look as foolish as the "flying car future" does to us now, but I'm pretty sure that I'll live on in human information space in some fashion long after I'm gone.
Tags: cc-20, cc-series, soldersmoke, VRX-1
