Part of the  

Chip Design Magazine

  Network

About  |  Contact

Part II: The Ecstasy and the Agony of UVM Abstraction and Encapsulation Featuring the AMIQ APB VIP

April 23rd, 2015

Part II of our tour through UVM reusability through TLM ports and the factory in the AMIQ APB VIP.

by Hamilton Carter – Senior Editor

Tuning the Receiver
Part I didn’t answer how, (or indeed if), the monitor’s messages make their way over to the write_item_from_mon method in the coverage collector.   Remember, the method is defined in the coverage collector, but apparently called from nowhere.  It gets worse.  Not only is the method not called from within the AMBA/APB package, but apparently it’s not called from the cagt package either!  Go ahead and look.  Take your time, grep through the files… I’ll be here when you get back.

You probably found the definition of the method up in the cagt package, but not a call to the method.  There’s a bit of UVM macro chicanery going on here.  You might have noticed a macro call at the top of the cagt version of the coverage file:

       `uvm_analysis_imp_decl(_item_from_mon)
       //coverage class
       class cagt_coverage#(type VIRTUAL_INTF_TYPE=int, type MONITOR_ITEM=uvm_sequence_item) extends 
             uvm_component;
              //pointer to the agent configuration class
              cagt_agent_config #(VIRTUAL_INTF_TYPE) agent_config;
               //port for receiving items collected by the monitor
               uvm_analysis_imp_item_from_mon#(MONITOR_ITEM,
                cagt_coverage#(VIRTUAL_INTF_TYPE, MONITOR_ITEM)) item_from_mon_port;

 

Interestingly, the argument to the `uvm_analysis_imp_decl macro contains the last few underscore terms of the method we’re looking for, ‘_item_from_mon’.  A little further down, notice that the partial phrase turns up again where the ‘port for receiving items…’ is declared.  The macro sets up a subclass of a TLM analysis port that’s specifically named uvm_analysis_imp* where the * is replaced by the macro’s argument.  Within that sub-class, unseen by mortal code-browsing eyes, the macro also sets up the call to the coverage collectors input method ‘write_item_from_mon’ which is defined as write* where the *, you guessed it, is once again replaced by the argument to the macro: ’_item_from_mon’.

Connecting the Components
OK, now we’ve located the pertinent communications methods, but where are the two ports attached to each other?  Is magical code automatically created that attaches the ports under the sheets?  Nope!  Look in the agent file within the cagt package.  There, you’ll find both the instantiation code for the monitor and the coverage collector, as well as the code that connects the two:

       if(coverage != null) begin
               coverage.agent_config = agent_config;
               monitor.output_port.connect(coverage.item_from_mon_port);

There, everything is well-explained… except for one last little detail.  Remember the cagt package doesn’t know a thing about the APB monitor or the APB coverage collector, nor should it.  It just sits back and happily and dumbly connects an abstracted monitor, (that doesn’t do anything), to an abstracted coverage collector, (that also doesn’t do anything).  Getting the environment to actually work requires the UVM factory to pull a switcheroo of object types using set_inst_override at the last minute in the APB agent file:

function new(string name = "amiq_apb_agent", uvm_component parent);
        super.new(name, parent);

        cagt_monitor#(.VIRTUAL_INTF_TYPE(amiq_apb_vif_t),
          .MONITOR_ITEM(amiq_apb_mon_item))::type_id::set_inst_override(amiq_apb_monitor::get_type(),
          "monitor", this);

        cagt_coverage#(.VIRTUAL_INTF_TYPE(amiq_apb_vif_t), 
          .MONITOR_ITEM(amiq_apb_mon_item))::type_id::set_inst_override(amiq_apb_coverage::get_type(),
          "coverage", this);

 endfunction

 

So, there you have it.  It took a bit of up-front planning—mostly defined by the UVM architecture—and a bit more work to dig through the code, (the first time anyway). Here’s what we got in return:

  1. Using the cagt package as a base, we never have to wire monitors to coverage collectors again.  We can build subclasses of cagt_monitor and cagt_coverage that add our specific code.  The banal connection code is executed automatically in the cagt_agent.
  2. Again with cagt: we never have to instantiate TLM analysis ports in either our monitors or coverage collectors ever again.
  3. Our monitor has no ties to the rest of the environment.  It needs its cagt base class, but it knows nothing of the specific objects it’s attached to, or for that matter, who’s doing the attaching.
  4. Ditto for the coverage collector.
  5. The base class can be used as the basic structure because it has no knowledge of what it’s specifically putting together.  Specifics are all handled by the factory’s switch at the last possible moment.  Here are more details about that little trick.

Consequently, we get a much better chance of write-once-and-walk-away-code—WOAWAC, as the natives say.   Oh!  And we get to look super-smart in the process!

 

The Ecstasy and the Agony of UVM Abstraction and Encapsulation Featuring the AMIQ APB VIP: Part I

April 21st, 2015

An interesting thing happened on the way to arriving at a completed article about the AMIQ APB VIP:  the code-base changed completely removing a layer of abstraction!  It’s a pretty cool little testament to the age of open source coding, and perhaps also to the agile manifesto which reads, in part, “…we have come to value…working software over comprehensive documentation.”  I’ll save the—maybe obvious—digression into inheritance vs. duplication of code for another post.  For now, I’ll go ahead and post the original article—a bit of a historical anachronism even if only by five days—because it provides perspectives into the design and construction of UVM objects that are hopefully still valuable examples.

by Hamilton Carter – Senior Editor

Why UVM and reuse?
Build it once, use it anywhere?  You can have that, but you’ll have to pay.  The good news is that if you do your job correctly, you only have to pay once.  The really good news is that the authors of UVM have already done most of the heavy lifting.

As you build each gleaming piece of your verification environment, there are a few reuse goals you should keep in mind:

  1. If at all possible, you don’t want to ever touch the code again… not ever.  You’ve got better things to do with your life, not the least of which is to create the next piece of gleaming verification goodness.
  2. You’ll want to be able to pass it around.  It’s good stuff!  Your buddies should totally get the benefit of knowing you—by having easier verification lives—through reuse of your stuff.
  3. Since you’re going to pass the code around, you’ll want it to seamlessly play with other pieces of verification IP.  This will make it easier for your buddies to use it and make you look like a genius!  It will also cut down on the number of support calls you get because—you know—you’re already working on the next great thing!

Amiq’s recent open source release of their AMBA-APB, UVM-compliant verification IP, (acronyms!  Everywhere acronyms!!!), gives us a nice platform to play around with and have discussions about UVM without the usual ‘invented here’ and NDA burdens to carry.  As an example of what UVM can buy for you, and what you have to pay to get it, let’s review an otherwise rather innocuous part of the APB UVC’s architecture: the connection between the monitor and coverage collector.

The above-mentioned reuse goals are accomplished for the APB bus monitor and its associated coverage collector.  Either of the two pieces can be used independently of the other.  It’s all done through the use of TLM ports and the factory.  Let’s walk through the code to get a good firm grounding of what’s there and how it’s done.  As we do, I’ll sprinkle in architectural and procedural details.

If you want to follow along in your code editor, you’ll need to pull the code repository for the AMBA APB project from https://github.com/amiq-consulting/amiq_apb as well as the supporting abstraction layer, (also from AMIQ), at https://github.com/amiq-consulting/cagt.  We’ll be rooting around in the sv subdirectory in each case.

NOTE:  With the recent code changes to the AMIQ APB VIP, to follow along clone the historical version of the APB code from https://github.com/hcarter333/amiq_apb.git.

Broadcast News
First, a few introductions:  The monitor’s job is to watch the APB bus and report, (broadcast actually), everything that’s happening.  The coverage collector’s job is to receive information from the monitor and format it into a cogent picture of the functional coverage generated by a given testcase.

A little bit of scrounging in the coverage collector code quickly reveals that it’s activated when the write_item_from_mon function is called.

       function void write_item_from_mon(amiq_apb_mon_item transfer);
             if(transfer.end_time != 0) begin
                   cover_item.sample(transfer);

This is also where the mysteries begin.  Who calls this function?   Since we’re collecting coverage based on what the monitor sees, the monitor would be the logical culprit.  A quick look at the monitor though reveals nothing.  The function is never mentioned.  The monitor does call a write function, but not write_item_from_mon.  Could the two be related?  Yup, they are.

Here’s what’s going on.  At the end of the day, you’d like to be able to use the monitor minus its associated coverage collector, (in an accelerated environment for example), without the monitor being any the wiser.  To pull this off, the authors used something called a TLM analysis port.


Monitor and coverage collector each with their associated TLM ports

The TLM port instantiated within the monitor provides a broadcast method named ‘write’.  The monitor calls this method without a clue as to whether anyone else is listening.  He proudly proclaims his latest APB news, and couldn’t care less if anyone hears.

The write method lives inside the monitor’s output_port and this brings up our next mystery.  Try to find where in the monitor the output_port was instantiated.  I dare you!  It’s just not there.  Careful attention to the figure above reveals answer.  The output port is declared in an abstract version of the monitor defined in the cagt package mentioned at the start of the article.

Amiq encapsulated the most basic, (and by basic I mean foundational, and by foundational, I mean the literal foundation of the environment), elements of the verification environment in the cagt package.  Almost all verification environments have monitors right?  Consequently, we’d like to have to write the foundational monitor code once and then leave it alone.  To accomplish this, the basics for the monitor are setup in the more abstract cagt package instead of the AMB/APB package.

A look at the cagt monitor reveals the declaration and instantiation of the monitor’s output port.  Now we know how the monitor is sending it’s messages out—using the output ports write method—as well as where the output port is declared—in cagt_monitor.sv.
Next: Tuning the Receiver

Citizen Science and The Search for Sputnik IV: Part 1

November 23rd, 2014

The holiday season is once again upon us, and, as usual this time of year, my thoughts are running to stories of science oddities in preparation for the holiday serial.  This week I’ll present a three part warmup serial grounded in mainstream science with just a hint of the fringe… if you know where to look.

While writing on the topic of 1950′s crowdfunding and satellites, I happened upon an interesting article about Operation Moonwatch.  Operation Moonwatch caught my eye for two reasons.

1.  One of the members of Operation Moonwatch’s National Advisory Committee was Dr. Clyde Tombaugh.  Dr. Tombaugh not only discovered the erstwhile planet, Pluto, but also worked as a professor at my now twice almost-alma mater, New Mexico State University.  This story won’t be about Dr. Tombaugh though.

2.  The article focused on another hot topic of late, citizen science, and not just citizen science, but crowd-sourced citizen science.

Operation Moonwatch was a network of citizen scientists, specifically amateur astronomers.   It turned out the term Moonwatch was a bit misleading though.  Members of the project had little interest in watching the moon.  The operation was setup prior to 1957 to track meteorites and satellites should such exotic vehicles ever be launched.  Members of the Operation Moonwatch network were encouraged to submit time and coordinate data for satellites or meteorites that they observed to members of the aforementioned National Advisory Committee.  Because the operation was actually setup before the surprise Sputnik launch in 1957, its citizen scientist members were able to fill gaps in the nascent government system for tracking the Soviet bird.

Anyone with a telescope who made a request was provided with procedures on how to manage a moonwatch observation station with their neighbors and friends.  If you didn’t have a telescope, no problem, you could also request instructions on how to build your own moonwatch telescope!.  The Operation Moonwatch story was fascinating , but after taking a few notes, I was forced to squirrel them away while I dealt with other projects…

Civil Service Journal April-June 1963

 

Programming as Writing as Programming

October 25th, 2014

In my writing studio recently, a grad student spoke about finding motivation to return from coding to writing his dissertation.  My colleague opined that he while he certainly could write for long stretches, (as it turns out, he write beautifully), that before long, the time to code would come again.  He’d drop the writing, move to coding, and the writing groove would be lost.  It seems to me that it need not be that way.  Writing and coding don’t have to be mutually exclusive events.

Have you ever picked up a piece of code without comments, without a specification, or without a detailed guide for its use and upkeep?  Have you ever not?  Writing about our work is one of the most powerful, most life extending things we can do for a piece of code.  We start in our coding classes with professors that urge, ney, implore us, to somehow document what we’re going to do before banging out the real deal.  Plan your work they say; document by commenting they say; write a document that describes what your code should do; for God’s Sake, use pseudo-code if you must, but write!  We all listen attentively, and then begin coding the small projects assigned in earnest.  It all fits in our head, why should we write it down.  Even if it’s a relatively large project, we can still usually push ourselves and get our mind around the whole thing at once.  It feels good, it’s like flexing a muscle.  It’s like the feeling you have after a long day of manual labor.  You did something; you stretched yourself;  you beat the odds.

Ayn Rand memorialized this feeling in her book “The Fountainhead”.  She describes Howard Roark taking the simplest building jobs during the summers he spent away from architecture school.  She describes the beauty in the task.  This is how I see people in our trade when we heft a large piece of a coding project and force it to our will.

 

“The Dean had seen him, last summer, on his vacation, catching rivets on a skyscraper in construction in Boston; his long body relaxed under greasy overalls, only his eyes intent, and his right arm swinging forward, once in a while,expertly, without effort, to catch the flying ball of fire at the last moment, when it seemed that the hot rivet would miss the bucket and strike him in the face.”

Rand’s romanticism of work doesn’t stop with the line worker though.  She also describes how Roark took this knowledge and used it to inform and inspire his bigger dreams.  How he was able to plan whole buildings that fit together seamlessly; how he was able to draft plans as exquisite pieces of art that not only informed builders how to construct each part of the structure, but also fed their souls.

What she’s describing is what I believe we as designers and builders of code should aspire to.  The ability to walk from the trenches, to write what we’ve seen, to create a document that tells others how to follow in our footsteps.  There are plenty of chances for writing in the coding arts.  If you’re in the trenches, write comments about what your code does.  Write about why you made one decision instead of another.  Write about how the blocks of your code fit together and how they allow for expansion by developers in the future.  Let your code blaze a trail in front of you and your documentation serve as a map for others to follow.

Metric Are… Everywhere

September 30th, 2014

I’m taking a class on academic writing this semester.  It’s been quite the experience.  For the most part, the class is populated with social science majors.  Attending class each week is like taking a dip in a refreshing cold stream after the clinical dryness of my usual physics and engineering activities.  For class, we’re required to keep both a writing and a reading journal.  The word journal, makes the activity sound soft – touch-feely – but it’s not.  At the heart of the activity is a metric driven process like the ones that Shankar Hemmady, myself,  a few industry luminaries wrote about back in 2007.  In our writing class, the process is more organic than what’s used in most planning/metric driven verification processes.  Rather than planning which metrics to measure before we begin, we start by measuring metrics that have served other others in the past.  As we build up a set of data, we start to analyze it, and of course from there fall into the usual plan/execute/measure/analyze/plan loop.  For folks who are not using a metric driven approach yet, here are the basics.

1.  Measure what’s going on in the project.  Ideally, you should figure out what you want to measure before the project begins.  No worries though, as the project evolves, you’ll figure out what information is important to you.  In our writing class, we’re measuring the time of day of each writing session, its location, how long it lasted, and where it took place.  Since we are actually a little touchy-feely, we’re also measuring the writer’s emotions at the end of each session, were you tired, elated, powerful, etc…?

2.  Analyze the data to determine where the project could be improved.  For verification engineering, code, functional, and assertion coverage tell us which parts of he design have been thoroughly tested and which parts need more work.  For writing, word count vs. location might tell an author where they’re most productive.  Word count vs. time of day, might suggest the optimum time to shut the door and just sit down and write.

3.  Make necessary changes, but most importantly, keep measuring results!  Each round of improvements will bear fruit or it won’t.  If you have metrics, you can find out the hows and whys of the improvements, or lack there of.  As processes improve, you might drop some measurements and start taking others.  Remember to document everything.  Documentation is the history that will remind you why decisions were made and keep you from repeating mistakes.

 The Metric Driven Life

If you’d like to take metrics to the extreme and make them your life, there’s an app for that.

Debugging and the Scientific Method

September 24th, 2014

 

Laboratory work is getting fairly heated here at A&M. Equipment is becoming available for use, and as each new bouncing bundle of joy makes its way into the laboratory, it has to be fully characterized. Many times, sadly, the initial characterization is that the ‘new to us’ piece of equipment is just flat out broken. Here’s where our laboratory work parallels the world of chip design and functional verification. While it’s rather easy to determine that the damned thing has bugs, it can be a complete bitch to figure out their root cause. Not shockingly, since my work is taking place in a laboratory these days, I’m using the scientific method, to weed through the possibilities. What’s interesting is that I’m using a technique I brought with me from the world of functional verification which I learned in a management training class of all places.

A Few Debugs Moments Back on the Homestead

The technique starts with that buzzword of all management buzzwords, brainstorming. Wait! Don’t run! This brainstorming can be done in the relative peace and quiet of your own desk. Of course, it would probably be even better if you involved few of your cohorts, but we’ll save that for another post. In a spreadsheet, or word processor table, just write down every possible thing you can think of that could cause the bug.

Each of these ideas is a hypothesis. There are no bad ideas in brainstorming.  We’ve all heard that in teambuilding class right?  We do, however, have to qualify each hypothesis just a bit. Can you devise an experiment that will prove or disprove the hypothesis by changing only one piece of your simulation? If not, then rework the hypothesis into two or more independent, (In the lab we like to use the big word ‘orthogonal’. Makes us feel important.), hypotheses each of which can be tested by modifying only piece of the simulation. As your doing this work, be sure to document in a sentence or two what the test for the hypothesis is in a column to the right of the one holding the hypothesis. By orthogonalizing your hypotheses in this manner, you won’t have to perform further analysis later to figure out which modification resulted in a change in the simulation. In addition, should your modification result in the simulation being even more broken, you’ll have an easy time finding the culprit.

Now that you have a list of orthogonalized hypotheses, the next step is to assign a priority to each of them. Ideas that you believe are more likely to be the root problem should receive a higher priority. Experiments, or tests, are then run in the order in which they were prioritized. When each experiment is complete, its results are recorded in an additional column in the spreadsheet, and any new hypotheses based on the data returned are added as new rows.

 

Utilizing the Compute Farm
In functional verification, one of the beautiful advantages we have over working in a lab with an actual piece of hardware is that we can kick off hundreds of simulations in parallel if we want to. If it’s possible to check all your hypotheses at once, do it! Make sure to retain any testcases you generate, even for hypotheses that weren’t correct. If you suspected a problem could arise for whatever reason, chances are it eventually might. Now, you have a testcase watching for the issue moving forward.

 

Wringing Every Last Drop from the Process
Once the issue is completely debugged back to its root cause, take a few minutes to review your debug spreadsheet. Look at your failed hypothesis, there’s still value there. Why did you think that hypothesis might be an issue? Was it a piece of your code that’s broken frequently in the past? Does it need more random testing? Was it an under-documented portion of the design? Can you file an issue to enhance the documentation, or add a few assertions that will fail if your perception of the block’s use model turns out not to be correct? It’s a simple game, look at the hypothesis, ask yourself what was worrisome there, and then ask how these worries can be addressed most efficiently so they never have to be addressed again.

Finally, embed the spreadsheet into revision control and record a link to it in your bug database. It memorializes your monumental effort to make everything right with the design once again. More importantly, when something similar comes up, you won’t have that, “Does anyone remember what we tried when…?” moment. You’ll know what you did, what did and didn’t work, and why you did it.

 

Listening to Meteors

August 31st, 2014

The View from the Front Yard 3:30 AM, August 30, 2014

Texas A&M, hot on the heels of their newfound football success has upgraded Kyle Field, their legendary football stadium where undergrads aren’t allowed to sit.  They’re allowed into the stadium mind you, it’s just considered poor form to sit.   We found out early one morning last week that a portion of the upgrade was a brand new jumbotron.  This became somewhat blindingly apparent when the pup and I were treated to technicolor clouds on our morning walk.  The jumbotron sits atop the newly refurbished end zone bleachers over a mile away from our house.  We wouldn’t be treated to such displays if it wasn’t for Johnny Football, and of course, our rather persistent low-lying early morning cloud cover that wafts in from the gulf.  The same circumstance that made for our polychromatic morning walk , (the cloud cover, not Johnny Football), obscured most of the Perseids meteor shower a few weeks ago.  As it turns out though, we could have listened to the meteor shower uninhibited.

When meteors hurtle through the atmosphere they leave a column of ionized gas in their trail.  Radio signals are reflected by this column, and so, while listening to a far-away mostly unintelligible TV or radio station, using a shortwave AM radio receiver, you can actually hear meteors whistle as they fly overhead.   The whistle is caused by the falling meteor Doppler shifting the frequency of the station you are listening to.  Most people are familiar with audio frequency Doppler shifts like the change in pitch of a moving fire engine siren.  As a source of waves, (sound waves in the case of the fire engine siren), moves, the frequency of the waves  changes with respect to a stationary listener.  Thus, as a fire engine approaches its siren goes first up in pitch, and then down as it passes by, and drives away.  Radio waves bouncing off the ion cloud created by a falling meteor exhibit the same effect.  Their frequency changes in proportion to the speed of the meteor.

Dr. .William Lonc of St. Mary’s University in Halifax, Canada[1] suggests listening for the video carrier of a television channel using an AM shortwave radio.  See Wikipedia for a list of television channel frequencies.  As a meteor cruises by, the Doppler shifted television signal will heterodyne with the local oscillator signal in your radio, and create a beat signal, or whistle in your speaker with a frequency determined by the speed of the meteor,

During a meteor shower like the Leonids, coming up in November, you should hear several pings, (in the older literature, they’re called whistlers), per minute.  Give it a try and please let me know how it goes.  I’ll try to do the same here at A&M and keep you posted.

 

References:

1.  William Lonc,Meteors by radio: Getting started,The Physics Teacher 37, 123 (1999); doi: 10.1119/1.880168

 

 

 

Math for Nothing and Refactoring for Free

August 20th, 2014

With all the requests by scientists and the government for money lately, here, finally, is something you can get from the government… for free.  Yes, that’s right, applicable scientific and engineering tools that are the result of NSF funding that your taxes paid for and that you can actually use… today… really!  If, like many engineers, you find yourself in need of the functionality Mathematica provides, but you’re reluctant to ask your boss for the money to purchase a license, sagemath might be for you.  Sage provides a lot of the same functionality that Mathematica does, and you don’t have to pay for it.  You can even use this Python based tool without making an install, with a cloud based version of Sage.  If you’ve ever played with Python, then you’re already most of the way to using Sage.

 

Functional Verification and Software Development, Brothers from a Different Mother

Verification Process Advise In Disguise as a Software Development Forum

Do you need better insights on improving your verification processes?  Are you running into issues like these?

  • Revision control nightmares
  • Blindingly and debilitatingly fast feature changes from marketing
  • Difficult to follow information trails on code verification history
  • Days and hours spent fixing broken designs after “No one changed anything” or only added “Correct By Design” fixes

As it turns out, the software industry had all these problems and beat the functional verification automation gang to the punch by several years.  While there is an ever growing cadre of EDA tools available to cure the above woes, there are also simple process steps, identified by the software folks, (as well as my own humble offering along with Shankar Hemady and a host of industry luminaries), that you can take to improve things now.  One of the beautiful things about the software industry  is that lots of its denizens love to share.  Checkout http://programmers.stackexchange.com, a forum that regularly discuss project management, debug, and code refactoring, (known as ‘garshdarned feature creep’ in our lingo).  As I was writing this, a question appeared on the board:

Develop in trunk and then branch off, or in release branch and then merge back?

Sound familiar?  Don’t let the name of the site fool you.  It’s not about how to program, it’s about how to be a programmer.  In addition to revision control, you’ll find posts about how to best change code, without destroying the code around it, and, equally importantly, with the advent of UVM, questions about design patterns, (think factory pattern).  Don’t worry about having to share in kind.  Stackexchange seems to have realized that your design, and or processes may actually be unique and beautiful snowflakes, in which cases, they’re quite happy with folks ‘just’ reading.

In the same vein, Coverity, a software verification company regularly publishes a software testing blog.  If you remember to squint your eyes, and say to yourself, ‘hardware systems’, or ‘embedded systems’, everywhere the blog says ‘software systems’, there are many good tricks and processes just waiting there for the taking.

 

 

 

Satellite Crowdfunding, Then and Now

July 30th, 2014

Did you know that the first satellite sent up by the United States was originally planned to be crowdfunded? Did you also know that the newest amateur satellite sent up in the third quarter of next year will be crowdfunded as well?

While researching a project on how fringe physics ideas make the transition to the mainstream, I came across this gem of a magazine from 1958.

The magazine’s first article discussed the birth of the Earth Satellite Vehicle, (ESV), program, as it was called at the time.  The main players followed by the article were Fred Singer, Andy Haley, and George Trimble.  Fred was an up and coming physicists from the University of Maryland, Andy was the head of the American Rocket Society, and George was an engineer working for Martin Aerospace who would one day become the deputy director of NASA.

A few year before the article was published, Trimble and Singer, lamenting that they might not be able to garner support from either industry or the government for a satellite program, hatched a plan to crowdfund the United States’ first fledgeling step into outer space.  Trimble said:

“We were going to sell shares, at five bucks per head.  In return, we were going to give the shareholders each a photograph of the Earth from outer space, taken by a camera in the satellite. That’s all they would get, but we felt that a lot of people should be interested in the view  and that we ought to be able to raise five or ten million dollars in this way – eenoughto send up a half dozen satellites, we thought.  But we never found time to organize the project.”

Fortunately for all of us who are fascinated with the U.S. space program in its many incarnations, the reason Trimble and Singer ran out of time was that the satellite project finally did gain financial backing due to the efforts of Trimble’s friend Andy Haley.  The American Rocket Society with Andy at its helm  had submitted two proposals to the National Science Foundation for satellite launch projects.  The first proposal was dismissed, but this didn’t dissuade the society who simply resubmitted the following year.  Finally, Andy received a head’s up that the project would happen, albeit under a different guise, as Project Vanguard.  Where did he receive the head’s up?  At a tea party for the Queen of England in Washington D.C. of course.  It could be that science was way more fun in the 1950′s!

Fox-1C

AMSAT is launching three cube satellites, designated the Fox series, in partnership with American universities.  The universities will place science experiments on each of the Fox cubesats.  Each experiment will use the cubesat’s onboard transceiver to communicate data and control telemetry with ground based experimental stations.  Once the experiments are complete, the satellite will be switched into an FM repeater mode which amateur radio operators can make use of to reflect their communications to other operators stations located over the horizon, completely obliviating the need for something like Operation Smoke Puff.

A few of the experiments that will be launched on the Fox satellites are a gyroscopic MEMs experiment from Penn State to determine how much the satellite wobbles while in orbit, and an experiment from Vanderbilt, (see picture below), that will detect the flux of low energy protons that impact the satellite.  Low energy protons are a concern in outer space, where, without the Earth’s atmosphere acting as a shield, the protons can actually damage spaceborne electronics.

And the Pitch!

As it turns out, AMSAT needs an extra $125k to get the Fox-1c satellite into space.  If you’d like to help out, you can donate at http://www.amsat.org/?p=2957.  You can also follow all the news on the development of the little satellite at http://www.amsat.org/?cat=21.

References and Notes of Interest:

George Trimble on Nixon and the Plaque on the Moon:
http://news.google.com/newspapers?id=GzhSAAAAIBAJ&sjid=ZjYNAAAAIBAJ&pg=2261%2C1927890

Amateur Satellites that flew over the U.S. during the writing of this article:

ArtSat
http://artsat.jp/en

BeeSat2
https://directory.eoportal.org/web/eoportal/satellite-missions/b/beesat-2-3

RS-39
http://www.arrl.org/news/amateurs-asked-to-listen-for-rs-39-satellite

The Satellite Magazine
Mallan, L. (1958). Space satellites (How to book 364). Greenwich, CT: Fawcett Publications

View Amateur Satellite Orbits in real-time
http://copaseticflows.appspot.com/sattrack

Help Save HAARP

July 16th, 2014

Millions of conspiracy theorists are about to lose their number one climate change explanation. The United States Air Force, with very little fanfare, and almost no mention in the press, has begun dismantling HAARP, the High frequency Active Auroral Research Program.  The HAARP antenna field and associated high frequency, (HF), transmitters were purportedly used to:

…”analyze the ionosphere and investigate the potential for developing ionospheric enhancement technology for radio communications and surveillance.”[1]

Or at least that’s what the government would have us believe.  Almost since it’s inception, HAARP, which can beam gigawatts of HF power into the ionosphere, was blamed for all manner of things, including tornadoes, earthquakes, and the occasional air or space disaster.  Oh, and I almost forgot, (or did I?), it’s also been hypothesized to provide the government with mind control capabilities.

Amid the recent sequesters, the Air Force decided that it would be more cost effective to shut down the $300 million dollar facility.  Alaska Sen Lisa Murkowski, has pointed out[2] to the Air Force and to Congress that it costs less than one percent of the stated value of the facility to operate it each year.  Scientists and amateur radio operators have pointed out that the facility should be saved for its scientific research value.

Senator Murkowski

Secretary James

It appears that the repeated requests for a scientific safeguarding of HAARP have not fallen on somnolent ears.  On July 2nd, Deborah Lee James, sent correspondence[3][pdf] to Sen Murkowski indicating that HAARP would be saved from the chopping block for at least another year.  She did maintain however that the Air Force would continue to remove non-essential equipment and winterize the facility in order to reduce costs.

For a far more scientific and less jovial take on all of this, please see the recent press release on HAARP[4] form the American Radio Relay League, (ARRL).

A letter writing campaign led by Dr. Christopher Fallen, KL3WX, of the Geophysical Institute, Space Physics at University of Alaska Fairbanks helped delay the demolition of HAARP for one year.  If you’d like to get involved with science and your government, and help to save HAARP, here’s your chance.  Dr. Fallen suggests modifying this template letter, with your information, and sending it to the Secretary of Defense, as well as to your congressional representatives and Senator Murkowski.  The template is rather specific to ham radio operators, so some readers may have to modify it more than others.  In my experience, when you contact your representative, they send you a reply on especially nice congressional letterhead.  It’s cool, and your kids will love it!  Heck, if nothing else, this might be among the strangest requests your representative has ever received.  Dr. Fallen also passed along this link to a HAARP happenings Facebook page.  The page contains posts about actual science going on at HAARP as well as the latest conspiracies and the status of the effort to save the facility.

In addition to the letter writing campaign, I think a bumper sticker in support of HAARP would be a nice gesture.  I’ve laid out a few possible slogans below.  Please vote for your favorite, or, even better propose your own HAARP saving slogan!

1.Don’t Let Taos Go Quietly into that Dark Night!  Harbor The Hum!  Save HAARP!

2. Help Save HAARP!  Better Living Through Mind Control.

3.  Seal the Science!  Help Save HAARP!

 

References:

1.  Wikipedia on HAARP
https://en.wikipedia.org/wiki/Haarp 

2.  Murkowski on HAARP
http://www.murkowski.senate.gov/public/index.cfm/pressreleases?ContentRecord_id=18cedde2-86f3-4d1b-b204-d26f869d5ad4

3.  Air Force Secretary James’ letter to Senator Murkowski
http://www.murkowski.senate.gov/public/_cache/files/9d9ea420-e081-4adb-a1af-571814044ab5/14.07.02.haarp.pdf

4.  ARRL on HAARP

http://www.arrl.org/news/view/haarp-death-sentence-stayed-but-facility-being-dismantled-piece-by-piece

5.  Cool research done at HAARP:  Ionospheric Ducts
http://spp.astro.umd.edu/SpaceWebProj/milikh/found/Formation%20of%20artificial%20ionospheric%20ducts.pdf 

6.  Dr. Christopher Fallen’s template letter for imploring your congressman to save HAARP
http://goo.gl/cH8S0P

7.  HAARP Happenings
https://www.facebook.com/pages/Gakona-Ionosphere-Research-Station/1533089153586494

 

Next Page »