Blog

Voice of America Radiogram

Sun, 24 Jul 2016 15:00:00 GMT

About two weeks ago I was lounging around in the backyard drinking an iced tea and reading the July issue of QST when I stumbled on something I thought was really sweet. The Voice of America is broadcasting weekly radiograms! I didn't even know the Voice of America was still in existence, so it was awesome to hear they are still around. It's doubly-awesome because the Voice of America Radiogram is an all digital broadcast which means you need to be into digital modes to receive it and I am very into all things digital. My first attempt at googling the website for VOA landed me on the VOA News website here http://www.voanews.com - which is not what I was looking for. (I should note however, there is a LISTEN button in the top right corner of the page that will allow you to listen to the VOA over the interwebs which is mildly interesting for a little while.) Further research revealed the radiogram site is located at http://voaradiogram.net. Scanning around the page revealed the following transmission schedule (all days and times UTC):

Sat 0930-1000 5745 kHz Sat 1600-1630 17580 kHz Sun 0230-0300 5745 kHz Sun 1930-2000 15670 kHz

These seem to be standard times used every weekend (but don't take my word for it, check the VOA website before planning any activities). The page also mentions the radiogram broadcast is transmitted from the Edward R. Murrow transmitting station in North Carolina. After futzing around converting UTC into local time, I discovered the Sunday 0230 UTC broadcast would be 7:30pm AZT which was just perfect! I was less sure about picking up North Carolina from Arizona (a distance of approximately 1,800 miles), but I decided to give it a try.

Setting Up

My receiver for this experiment is a Tecsun PL660 'PLL World Band Receiver' connected to a 40meter-ish dipole antenna oriented east-west in my attic. I say 40meter-ish because this antenna is approximately 66 feet long, but isn't used for transmitting and is connected to my radio by a rather rube-goldberg-esque run of feed line. The computer used is an old homebrew 2.4GHz Pentium 4 with 1 Gig of RAM running Windows XP SP3. As the Voice of America Radiogram website recommends, I downloaded and installed fldigi available from https://sourceforge.net/projects/fldigi/files/fldigi and flmsg from https://sourceforge.net/projects/fldigi/files/flmsg. I also found this bit of useful configuration information on the Voice of America Radiogram website:

"To make Flmsg work with Fldigi, in Fldigi: Configure > Misc > NBEMS > under Reception of flmsg files, select Open with flmsg and Open in browser, and below that indicate where your Flmsg.exe file is located – probably somewhere in Program Files(x86)."

Tuning In

My first step was to see (generally) what reception was like. The Voice of America Radiogram was listed as broadcasting on 5745kHz, so I tuned to the WWV beacon at 5000kHz to listen to Colorado for a little while. WWV was audible but with some pronounced fading in and out, so I wasn't overly optimistic I was going to hear the VOA clearly enough to decode anything. The audio is a little strained, but if you turn up your volume you can hear my reception of WWV in this video. When 7:30 AZT finally rolled around I strained to hear anything and... nothing. I was starting to think I had the time wrong, or my flaky antenna arrangement wasn't up to the task, or the reception conditions weren't right, or... Then I heard the music and the infamous "Voice Of America" introduction and got goose bumps. After that, the whole shebang was almost idiot proof. fldigi started decoding MFSK32 and I was kind of amazed how reliable it was. Here you can see everything in action (with a brief shot of my PL660 about halfway through). As this portion of the program was about to wrap up, it occurred to me that some of the programs in the radiogram contain images. I wanted to be sure I had a video of receiving my first image via MFSK32 but unlike the awesome slow scan television (SSTV) images I received from the ISS last year (Image1, Image6, Image8, Image9), the received image was a little underwhelming. I also recorded my reception of two other images from this radiogram. If you are really interested, you can watch them all on YouTube. VOA Radiogram 173 (4 of 7) VOA Radiogram 173 (5 of 7) VOA Radiogram 173 (6 of 7) The final portion of the program was an encoded HTML message about the Kepler Space Telescope. This is where flmsg comes into play. It looks like the message is encoded and transmit as a Base64 string, which is then decoded and launched in your favorite web browser. I'm doing some extrapolation here, I don't know how the data is encoded for sure, but when you see something like this

<transfer> [b64:start]

it sure smells like Base64 encoding. After looking at the received HTML document, its a bit of a cheat. Yes, the HTML was received via MFSK32 but the linked image and (obviously) hyperlinked content point to URLs on the interwebs, which (to me) feels like it violates the spirit of the whole thing. You can see the decoded HTML message thanks to the wonderful folks at YouTube. VOA Radiogram 173 (7 of 7)

Winding Down

I never expected that I would be able to copy the entire program without any data loss. The images looked a bit sketchy, but these days any image that's only 200x180 pixels with artifacts looks pretty bad. You just have to remind yourself how you received those sketchy looking images. That's the cool part. I made sure to capture my audio with fldigi and have provided a download link to the audio and the full broadcast text below. I was unable to figure out how to 'save' the received images with fldigi, so I unfortunately don't have any links for the received images, but trust me, your not missing anything. VOA Radiogram 173 Text VOA Radiogram 173 Audio All in all, this was a great first-time experience with receiving MFSK32. If you've never done it, the VOA Radiogram is a fantastic way to get your feet wet. I highly recommend giving it a try! 73

Retrocomputing StackExchange

Fri, 22 Jul 2016 15:00:00 GMT

Just a quick note, StackExchange now has a Retrocomputing site in beta. I almost never sign up for anything on the interwebs. I don't face-space or my-book or twit-trist or any of that nonsense. But I had to join this one... Check it out! http://retrocomputing.stackexchange.com/

Non-blocking semaphore to avoid reentrancy in .NET

Fri, 29 Jan 2016 15:00:00 GMT

Here is a small programming tip I thought I would share. Sometimes in .NET / C# I find myself needing to write a pattern similar to this:

private bool m_bSemaphore = false;

private void DoSomethingCrazy()
{
   if (m_bSemaphore == false)
   {
      m_bSemaphore = true;
      //Do some crazy stuff
      m_bSemaphore = false;
   }
}

This intent of this code would be to prevent the DoSomethingCrazy() method from being executed simultaneously. The first thread to invoke DoSomethingCrazy() would set the semaphore and all subsequent calls from other threads would be ignored until the semaphore is reset. The problem with the code above is that it is not thread safe. It is possible two competing threads could both execute the IF clause and decide the semaphore is false at exactly the same time. The entire point of the semaphore is to prohibit this from happening, so the code above is actually a very subtle bug waiting to happen. Most of the time it's going to work, but there is that small chance things are going to go wonky when least expected. A more robust solution which is thread-safe would be to craft the logic similar to this:

private object m_objSyncLock = new object();

private void DoSomethingCrazy()
{
   if (Monitor.TryEnter(m_objSyncLock))
   {
      //DoCrazyStuff
      Monitor.Exit(m_objSyncLock);
   }
}

By using the .NET static Monitor class makes we make the testing of the lock (TryEnter) and the acquisition of the lock into a single atomic operation (ie. only 1 thread can do both steps at a time).

article copyright © 2015 devMash.com

Get duration using Media Foundation and C#

Sat, 29 Aug 2015 15:00:00 GMT

I was sidetracked today by a rather interesting problem; How to get duration using Media Foundation and C#? I've worked on several projects over the years where I needed a simple method to get the duration of a multimedia file. In the past I turned to DirectShow but this time I wanted to get the duration using Media Foundation and I wanted the code to be written in C#. After wandering around the Media Foundation documentation for a while, I discovered an article titled Using the Source Reader to Process Media Data. The interesting bit was the section called Getting the File Duration which served as a starting point for my implementation.

The Method

Enough talk. Lets jump straight in. Here is the finished method:

public double GetDuration(string filename)
{

    double duration = double.NaN;

    const int S_OK = 0;
    const uint MEDIA_SOURCE = 0xFFFFFFFF;

    int hr;

    //Startup media foundation 
    hr = MFInterop.MFStartup(MFStartupFlags.Full);
    if (hr == S_OK)
    {

        //Create source reader
        IMFSourceReader sourceReader;
        if (S_OK == MFInterop.MFCreateSourceReaderFromURL(filename, null, out sourceReader))
        {

            Guid MF_PD_DURATION = new Guid("6C990D33-BB8E-477A-8598-0D5D96FCD88A");

            //The duration timebase is 100-nanosecond units
            double timebase = 10 * 1000 * 1000;

            //Get the multimedia duration 
            PropVariant propVariant;
            sourceReader.GetPresentationAttribute(MEDIA_SOURCE, MF_PD_DURATION, out propVariant);
            if (propVariant.Type == System.Runtime.InteropServices.VarEnum.VT_UI8)
            {
                duration = ((ulong)propVariant.Value) / timebase;
            }
            propVariant.Clear();

        }

        //Shutdown media foundation
        MFInterop.MFShutdown();

    }
    return duration;
}

The method itself is relatively simple, but gathering the supported enumerations, interfaces, and structures takes a bit of research and know-how. I am going to discuss how I found each of these required elements in due course, but if you are on a deadline and want to push the easy button you can find a working example solution for Visual Studio 2013 at the bottom of this article.

Startup and Shutdown

You can see in the GetDuration method that we are required to startup and shutdown Media Foundation. If we neglect this step our method will fail to work properly. I like to create a static utility class named MFInterop to house my external function calls. I find this a handy way to group all my external calls together and I can easily add more declarations when needed. It looks like this:

using System.Security;

public static class MFInterop
{

    [DllImport("mfplat.dll", ExactSpelling = true), SuppressUnmanagedCodeSecurity]
    public static extern int MFShutdown();

    [DllImport("mfplat.dll", ExactSpelling = true), SuppressUnmanagedCodeSecurity]
    private static extern int MFStartup
    (
        int Version,
        MFStartupFlags dwFlags
    );

    public static int MFStartup(MFStartupFlags objFlags)
    {
        int MF_VERSION = 0x20070;
        return MFInterop.MFStartup(MF_VERSION, objFlags);
    }

}

and the MFStartupFlags enumeration:

public enum MFStartupFlags
{
    Full = 0,
    Lite = 1,
    NoSocket = 1
}

I had to scrounge around the header files to figure out the values for MF_VERSION and MFStartupFlags. Instead of making MFStartup public, I instead chose to write a small wapper method that encapsulated the version information. You can find the documentation for MFStartup and MFShutdown in the Microsoft Media Foundation Programming Reference. It is worth pointing out that you would probably want to initialize Media Foundation one time in your startup logic, and correspondingly shutdown when your application exits. Putting the startup and shutdown logic directly into our method isn't terribly efficient.

IMFSourceReader

To get the media duration we are going to need an IMFSourceReader interface and according to the documentation, we can use MFCreateSourceReaderFromURL to get one. Let's add another static external declaration to our MFInterop class, like this:

[DllImport("mfreadwrite.dll", ExactSpelling = true), SuppressUnmanagedCodeSecurity]
public static extern int MFCreateSourceReaderFromURL
(
    [In, MarshalAs(UnmanagedType.LPWStr)] string pwszURL,
    IMFAttributes pAttributes,
    out IMFSourceReader ppSourceReader
);

This is where things start to get interesting. You will discover very quickly that Media Foundation methods expect to work with Media Foundation interfaces, and Media Foundation interfaces will reference various enumerations, structures, and further interfaces. Each time you declare one you create a need to declare three more. It feels almost viral trying to get everything declared properly. Fortunately for the purposes of this article, we only have to declare a few things.

Jiggery Pokery

But where do we look to find a C# declaration for IMFAttributes or IMFSourceReader? It took me a while to figure this part out. The answer lies in understanding IDL files, type libraries and interop assemblies. I don't pretend to be a C++ guru, and when people start throwing around terms like interop, IDL, and type libraries my eyes start to go a little out of focus. But after a bit of jiggery pokery, I discovered it's actually not that difficult to get the IDE to do the heavy lifting for us.

The first thing we need to locate is a file called Mfobjects.idl. On my machine, this file was located at

c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include

If you open the Mfobjects.idl file in your favorite text editor and snoop around, you will find the interface declaration for IMFAttributes. Everything you need to know is right there; but it is unfortunately written in the wrong language. What we need is an easy way to convert the IDL version of the interface into a C# version we can use in our project. After a few hits and misses I discovered that we can use some of the command line tools included with Visual Studio to generate a type library (TLB) from the IDL and then generate an interop assembly from the type library. Finally, we can use our favorite reflection tool to examine the interop assembly and look at the C#. Still with me? Excellent. Everyone get out your command lines...

MIDL

Start by opening the Visual Studio Native Tools Command Prompt. If you use a standard Command Prompt you will have to add the path for the Microsoft tools manually or change directory to the location of the tools on your hard drive. Try typing MIDL at the command prompt and you should get some output like this:

C:\>midl
Microsoft (R) 32b/64b MIDL Compiler Version 8.00.0603
Copyright (c) Microsoft Corporation. All rights reserved.
midl : command line error MIDL1000 : missing source-file name

As I understand it, IDL is an Interface Definition Language developed by Microsoft to define interfaces for COM objects. It has always been one of those technologies that dances on the periphery of my skill set. I won't pretend to explain or even understand IDL but I will tell you that with a bit of tweaking to the Mfobjects.idl file we can easily create our type library. My approach was to first make a copy of the Mfobjects.idl so I could safely screw things up without permanent damage.

c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include>mkdir c:\temp
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include>copy mfobjects.idl c:\temp
     1 file(s) copied.
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include>cd c:\temp
c:\temp>

For some reason, the MIDL tool can only generate a type library for IDL files that conform to a specific format. Of course, all the IDL files we are going to play with don't seem to have the magic bits that the MIDL tool requires, so we are going to add them manually. It's dead simple, here is all we need to do:

[
uuid(4A3AE19D-C636-44B2-B554-10B87BF7E6EE),
lcid(0x00),
version(1.0),
helpstring("devMash mfobjects type library")
]
library dm_mfobjects
{
    INSERT ORIGINAL FILE CONTENTS HERE 
}

As you can see, we simply place the original file contents in between the curly braces. One thing you will want to be cautious about is the UUID. Use the Create Guid tool in Visual Studio to create a unique Guid for each type library you decide to generate. It is also a good idea to give your type library a unique name and help string so you can easily identify it later. Save the changes to your copy of Mfobjects.idl (we don't want any accidents!) and let's generate our type library:

c:\temp>midl Mfobjects.idl /tlb Mfobjects.tlb
Microsoft (R) 32b/64b MIDL Compiler Version 8.00.0603
Copyright (c) Microsoft Corporation. All rights reserved.
    MIDL OUTPUT REMOVED FOR BREVITY
c:\temp>dir
08/25/2015  04:42 AM           153,410 Mfobjects.idl
08/25/2015  04:46 AM            81,260 Mfobjects.tlb

After entering the MIDL command above you will see some output scroll by. You can safely ignore it as it appears to be nothing more than a list of external IDL files and headers that were referenced by Mfobjects.idl. Do a directory and if all is well you will see we have created a new file called Mfobjects.tlb.

TLBIMP

Now that we have a type library we need to generate an interop assembly. This step is pretty easy:

c:\temp>tlbimp Mfobjects.tlb /out:Mfobjects.dll
Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.33440
Copyright (C) Microsoft Corporation.  All rights reserved.
    TLBIMP OUTPUT REMOVED FOR BREVITY
c:\temp>dir
08/25/2015  04:42 AM           153,410 Mfobjects.idl
08/25/2015  04:46 AM            81,260 Mfobjects.tlb
08/25/2015  05:09 AM            42,496 Mfobjects.dll

You will probably see a lot of warnings scroll by when generating the interop assembly. I happily ignored this and pressed on into the fog bank with absolute confidence. You can too.

Reflection

For our next step you are going to need a reflection tool like Red Gate's .NET Reflector or Telerik's JustDecompile. I am partial to .NET Reflector because I have used it for years and it is conveniently bundled with other Red Gate products that I own. If you don't already have a favorite reflection tool, JustDecompile is free and is a quality product but you have to create an account and sign up to do the install. I am sure there are other tools out there that would work equally well. Once you have settled on a tool you are happy with, simply open the interop assembly we generated earlier. In .NET Reflector this is done via the usual File->Open metaphor. If all has gone well, you should be able to see your assembly in a treeview navigation panel, and if you expand a few nodes you will eventually come across the IMFAttributes interface. In most reflection tools, selecting the node in the tree (clicking on IMFAttributes) will cause the associated code to be displayed in the main window. Some tools offer options about what language (VB, C#, etc.) and what version of .NET you would like to target. You should be able to see something similar to this: [caption id="attachment_84" align="aligncenter" width="1243"] Using .NET Reflector to display the IMFMediaAttributes interface[/caption] Simply select the decompiled code for the IMFAttributes interface and paste it into your Visual Studio project. Viola! Well, almost Viola. Don't forget to add the following using clauses:

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.Text;

Stragglers

If this code is ever going to compile, we are going to have to cleanup the remaining stragglers. The IMFAttributes interface contains methods which in turn make references to PROPVARIANT, MF_ATTRIBUTE_TYPE and MF_ATTRIBUTES_MATCH_TYPE. The last two are simply enumerations and are easy enough to lookup but we are going to have to ignore PROPVARIANT for a little while. When I migrate enumerations from C++ to C# I like to do a little refactoring. Generally, I will camel-case the naming and remove any redundant prefixing that made sense in C++ but is out of place in C#. Also, I have a tendency to look up actual values from the headers and incorporate them directly. For example, here is the original enum for MF_ATTRIBUTE_TYPE:

typedef enum _MF_ATTRIBUTE_TYPE { 
  MF_ATTRIBUTE_UINT32    = VT_UI4,
  MF_ATTRIBUTE_UINT64    = VT_UI8,
  MF_ATTRIBUTE_DOUBLE    = VT_R8,
  MF_ATTRIBUTE_GUID      = VT_CLSID,
  MF_ATTRIBUTE_STRING    = VT_LPWSTR,
  MF_ATTRIBUTE_BLOB      = VT_VECTOR | VT_UI1,
  MF_ATTRIBUTE_IUNKNOWN  = VT_UNKNOWN
} MF_ATTRIBUTE_TYPE;

and here is my version in C#

public enum MFAttributeType
{
    UINT32 = 0x13,  // VT_UI4
    UINT64 = 0x15,  // VT_UI8
    DOUBLE = 5,     // VT_R8
    GUID = 0x48,    // VT_CLSID
    STRING = 0x1f,  // VT_LPWSTR
    BLOB = 0x1011,  // VT_VECTOR | VT_UI1
    IUNKNOWN = 13   // VT_UNKNOWN
}

This is obviously a matter of style, but you get the general idea. That takes care of the most of the stragglers, but we still have those pesky PROPVARIANT references. Again, let's defer addressing that particular problem just now.

Rinse and Repeat

If you remember, we were trying to simply declare interfaces for IMFAttributes and IMFSourceReader so we could execute the Media Foundation call MFCreateSourceReaderFromURL. It's been a long road and we only have a partial IMFAttributes interface to show for all of our hard work. But this kind of work is like rolling a snowball down a hill. Once you get started it goes faster and faster. At this point you might be tempted to think copying the IMFSourceReader interface will be a simple matter. Unfortunately you will quickly discover that the IMFSourceReader interface does not appear to be defined in Mfobjects.idl. Instead it is found in Mfreadwrite.idl. So we will need to generate a type library and interop assembly for Mfreadwrite.idl in exactly the same way we did for Mfobjects.idl. After generating an interop assembly for Mfreadwrite.idl, you can open it in your favorite reflection tool and copy/paste the interface declaration for IMFSourceReader into your C# project. Notice that the interface declaration for IMFSourceReader includes several methods which reference to two more interfaces, IMFMediaType and IMFSample, as well as our hanging PROPVARIANT problem. A quick look in our reflector reveals IMFMediaType was part of Mfreadwrite.idl, and so we can easily copy the interface declaration without have to resort to further conversions. Don't forget to clean up MF_ATTRIBUTE_TYPE and MF_ATTRIBUTES_MATCH_TYPE after copying, and please continue to patiently ignore those darn PROPVARIANT references. The same holds true for IMFSample, simply copy and cleanup. Notice IMFSample makes a reference to IMFMediaBuffer so we are going to need to get that interface also, which is also conveniently found in our interop assembly. (If you notice the IMFAttributes interface can also be found in our interop assembly for Mfreadwrite.idl, but we had no way of knowing that when we started.) You should now have the following interfaces:

and the following enumerations:

with the only remaining errors related to...

PROPVARIANT

The PROPVARIANT structure is deserving of it's own article. It's a verbose and ugly looking structure with a C++ Union occupying half the declaration. I was confident that given some time and experimentation the PROPVARIANT could be ported to C#. It would make an interesting topic to write about and much to my delight I discovered an excellent article has already been written titled Interop with PROPVARIANTs in .NET by Adam Root. After reading through Adam's article a few times to get the gist of it, we can copy his PropVariant structure without modification directly into out project. All that should remain is refactoring the PROPVARIANT references found in our copied interfaces to use PropVariant. With some luck, your code should now compile but we aren't done yet.

Getting the Duration, Finally!

We had to do a lot of work to create an instance of a new IMFSourceReader but it's about to pay off. The IMFSourceReader exposes a method called GetPresentationAttribute which according to the Media Foundation documentation, "gets an attribute from the underlying media source". To call GetPresentationAttribute we will need to pass two parameters; the stream index and a presentation descriptor attribute. For our purposes the stream index is quite simple and according to the documentation it is easily declared:

const uint MEDIA_SOURCE = 0xFFFFFFFF;

For the second parameter we will need to consult the documentation and examine the list of possible Presentation Descriptor Attributes that we can use with GetPresentationAttribute. A quick look will reveal MF_PD_DURATION can be used to get the duration in 100-nanosecond units. Presentation Descriptor Attributes are declared as Guids so we have to look in mfidl.h to find the actual definition:

EXTERN_GUID( MF_PD_DURATION, 0x6c990d33, 0xbb8e, 0x477a, 0x85, 0x98, 0xd, 0x5d, 0x96, 0xfc, 0xd8, 0x8a );

converting this to C# gives us:

Guid MF_PD_DURATION = new Guid("6C990D33-BB8E-477A-8598-0D5D96FCD88A");

The output from GetPresentationAttribute will be a PropVariant containing the duration in 100-nanosecond units. A nanosecond is a billionth of a second or 10⁻⁹ seconds. Therefore a 100-nanosecond unit is actually one ten-millionth of a second or 10⁻⁷ seconds. We can express the timebase like this:

double timebase = 10 * 1000 * 1000;

and finally invoke GetPresentationAttribute like this:

PropVariant propVariant;
sourceReader.GetPresentationAttribute(MEDIA_SOURCE, MF_PD_DURATION, out propVariant);
if (propVariant.Type == System.Runtime.InteropServices.VarEnum.VT_UI8)
{
    duration = ((ulong)propVariant.Value) / timebase;
}
propVariant.Clear();

If all has gone according to plan GetPresentationAttribute should return a valid PropVariant structure with a Type of VT_UI8, which is really just a 64-bit unsigned long. Dividing the returned value by our timebase will yield the duration in seconds. Lastly we should release our PropVariant by calling the Clear method. You now have the duration in seconds! Huzzah!

Source Code

I've created an example project in Visual Studio 2013 targeting the .NET framework 4.5 called GetDuration.zip. This example contains all the source code discussed in this article; including the PropVariant structure written by Adam Root. The project is released under the MIT License so you can use it as a starting point for your own Media Foundation projects in C#.

Conclusion

Hopefully this article has helped you to learn how you can get duration using Media Foundation and C#. We have covered how to reference external Media Foundation methods, how to look up and translate Media Foundation enumerations and how generate Media Foundation interface definitions using various Visual Studio Native Command Line tools and reflection. You should now have a good foundation to build on while developing your own Media Foundation applications using C#.

FLEX-1500 Software Defined Radio

Thu, 27 Aug 2015 15:00:00 GMT

I have been exposed to amateur radio all of my life. Some of my earliest memories are of myself and my Dad playing with his old Hallicrafters SX 110. When I was 13 (with a lot of encouragement and help) I managed to get my Novice license and I have been continuously licensed ever since. However, I also discovered the magic of computer programming about the same time. The latter became an obsession while the former faded into background noise. [caption id="attachment_100" align="aligncenter" width="640"] Dad in the Wayback Shack[/caption] About 2 years ago I decided to upgrade my hopelessly out-of-date Novice license to Technician and even more recently upgraded to General. I even managed to convince my Dad to come along and get his General at the same time, which was great fun! This flourish of activity has naturally left us both thinking about getting a new rig. While we seem to have lots of radios kicking around, even some transmitters, nothing quite fits the bill. We do have the Heathkit my Dad built in the early 1980's, but it never quite worked properly. It's on my list as an "electronics" & "retrotech" project someday. [caption id="attachment_101" align="aligncenter" width="640"] Heathkit HW-101 Transceiver[/caption] So we are on the lookout for a new radio. We've been flipping through QST and reading blog posts but so far the vision is still a bit foggy. I'm slowly assembling a mental inventory of attributes like power and frequencies and modes and... well, there is a lot to consider. Anyway, I randomly found this video on Youtube yesterday. It's a short ARRL review of the FLEX-1500 SDR (software defined radio). If you are new to the idea of SDR don't worry you are not alone, but as a computer guy the idea of SDR makes perfect sense to me. I find this little QRP (low power operation) transceiver to be fascinating. I don't think it's quite what we are looking for, but I would love to have one to play with anyway! .

EAARS Broadcastify Live Autio Feed

Tue, 25 Aug 2015 15:00:00 GMT

I just wanted to jot off a quick post regarding the Eastern Arizona Amateur Radio Society (EAARS). These guys have a really nice 2 meter repeater network set up covering several thousand square miles in the southwestern United States. If you are interested you can listen to the repeater traffic live via their Broadcastify Live Audio Feed.

I have too many computers!

Mon, 24 Aug 2015 03:00:00 GMT

I have too many computers. There. I said it. My friends and family all tell me to get rid of some of this stuff. They roll their eyes when I get excited about some new piece of ~~junk~~ equipment. But I can't help myself, I never saw a computer, radio or television sitting in a dusty corner at the Goodwill that I didn't want to take home and restore or tinker with or disassemble, etc. I can't even go near Ebay without spending $150 on something nobody in their right mind would spend $150 for. So I thought it would be fun to try to enumerate (that's fancy programmer talk for 'list') all my computers. I am going to take a shot at it now, off the top of my head. Hang on, here we go...

Commodore

I love commodore. The first computer I ever actually owned was a Commodore 64. I think I got it for Christmas in 1982 or 1983, and I spent a large chunk of my youth programming, calling bulletin boards, and playing games. I got my Amiga 1000 for Christmas in 1986 and it was nirvana. Nothing has ever come close to the awe I had for my first Amiga.

1ea Commodore VIC-20
2ea Commodore 64
1ea Commodore SX-64
3ea Amiga 1000
1ea Amiga 3000

Apple

My school district bought Apple ][+ computers in either 1980 or 1981 and they had no idea what to do with them. Some educational professional must have reasoned that if computers have a keyboard and electric typewriters have a keyboard it therefore makes sense that computers belong in the typing lab. Which is where the new Apples landed. It is also what we did with them; learned how to type. However, I was not satisfied with merely typing random letters on the keyboard. Within a week I was learning BASIC and shortly after that I dove straight into Machine Language. I still have my first ever Floppy Disk. Elephant Memory Systems - Elephant Never Forgets.

1ea Apple //e
1ea Apple //c
1ea Laser 128
1ea Mac 512K (?)
1ea Mac SE/30 (?)
1ea Mac Performa (?)
1ea Mac Power Book 150 (?)
1ea Mac Ruby G3
1ea Mac iBook G3
1ea Mac Mini G4
2ea Power Mac G4
1ea Mac PowerBook G4 (Titanium)
2ea Power Mac G5
2ea Mac RAID
1ea Power Mac (Intel 8 core)
1ea MacBook Pro (i7 2010)

Radio Shack

The first computer I ever touched was a TRS-80 Model I. My Dad was managing a Radio Shack store when the first Model I arrived. To my 10 year old mind it was absolutely the coolest thing ever (well, short of Star Wars anyway). I remember my Dad struggling to get the tape player to load a game called 23 matches, which I played endlessly in the store. It was about this same time I read Issac Asimov's book "Adding a Dimension" and being fascinated by the chapter "One, Ten, Buckle my Shoe" which was about binary number systems. Unfortunately, I didn't connect binary math and computers until I started programming on the Apple ][+.

1ea TRS-80 Model 100
1ea TRS-80 Color Computer

PC (Brand-name)

I loathed PC's. Hated them. It was a religion. PC's sucked and only idiots bought them. Of course, back in 1990, if you were cruising along on your U.S. Robotics Courier 9600 HST with your multi-tasking Amiga 3000 while playing MOD files in the background and someone showed you a PC running Windows 3.0 it was easy to snort in derision. With supreme irony I somehow ended up turning programming PC's into a career. I also managed to collect quite a few along the way.

1ea Epson PS2 L40 SX
1ea Acer Notebook (?)
1ea Panasonic CF-41 Notebook (486)
6ea Dell Desktop (P60) (?)
1ea Dell Inspirion (?)
1ea Intel ThinkPad (P60) (?)
3ea Gateway Notebooks (?)
1ea Compaq Presario V4000
1ea Dell Desktop (P4)
1ea HP Pavillion (P4)
1ea HP Pavillion (AMD A8)

PC (Homebrew)

Maybe the single greatest thing about PCs is that you can build your own. You have ultimate control over speed, memory, storage, peripherals, operating system, etc. Back when Computer Shopper was an inch thick and mail order clones were in vogue, I worked for a company called Fast Micro as a technical support representative. During that period of my life I built, configured, and repaired thousands of 386 and 486 systems. I hated doing technical support, but I have a huge library of technical documentation for motherboards and multi-i/o cards from those days.

1ea "Bridgette" P3
1ea "Gaming Rig" I7

Concluson

Whew! I think that's all of them. I didn't even bother to try listing peripherals or the associated piles of junk I have collected (cases, motherboards, disk drives, hard drives, audio cards, video cards, cd-roms, etc.). I've got a mountain of books and manuals, and (quite literally) a dozen legal boxes full of software. It's quite a lot to store, and even harder to actually get stuff out and set it up but I am slowly getting organized. In the future I hope to add a Comodore 128 and an Amiga 2000 to my collection. I would also very much like to get some Atari gear; maybe a nice 800 XL with some disk drives. Anyway, thanks for taking a trip down "inventory lane" with me. Cheers!

Compute!'s Gazette

Thu, 21 Aug 2014 15:00:00 GMT

When I was just a kid, I loved computers. Everything was 8 bit back then, and everything was comprehensible by a 14 year old. 65xx assembler wasn't very difficult, and you could apply your knowledge to Commodore, Apple and Atari products; which was the lions share of what you and your friends probably had access too. Of course, before we even knew there was such a thing as an 'Internet' and before we got our first 300 baud modems, information was somewhat tricky to come by. Finding good code examples usually meant scrounging around the school library for terribly written and hopelessly out of date books. Sometimes my friends and I would go to the mall just to slum at Waldenbooks where we would endlessly drool over the 10 books in the 'computer section'. I remember we did a lot of disassembling and arguing and experimenting, and consequently a lot of frustrated swearing. But for a Commodore 64 Junkie like myself, there was a shining beacon of digital enlightenment, guaranteed to arrive monthly. Compute!'s Gazette was like Manna from Heaven. I don't exactly remember the first time I ever saw this magazine, but I think it was when my parents blindly bought me a subscription. My Dad was an electronics and amateur radio enthusiast, but I think my passion for computers had both my parents mystified. Whatever the circumstances, at some point I started reading the Gazette... Every single page.... Over and over and over... I would type in the programs... I would read the articles... I would pour over the letters to the editor... I would drool over hardware advertisements for things I knew I would never afford... It's safe to say, I obsessed over that magazine and the precious bits of data it contained. I often wish I still had my hard copies of Compute!'s Gazette. Like an idiot, I junked my entire stash one year in a rash decision to try and save a relationship with an Ex. (She said I keep too much junk, but I don't see it?). - So now, gentle reader, we reach the point of this post, which is that now anyone can read the Gazette in all it's original glory. Thanks to the Internet Archive, and God-Knows-Who taking the time to scan every single page of every issue, everyone can sample this wonderful magazine and experience, just for a moment, the simple beauty of retro computing. If you are interested in old computers (and even if you aren't) I invite you to visit the Internet Archive collection of Compute!'s Gazette magazines and sample a few. Issues are available in a variety of formats, including PDF. Try to imagine the thrill of typing in a FREE word processor, or getting your computer to display 80 columns, or lusting after that new 9 pin dot matrix printer... I hope you can, maybe for a little while, find as much joy in those pages as a certain young programmer did all those years ago.

NTSC Demystified

Fri, 18 Jul 2014 15:00:00 GMT

I was browsing through posts on Hackaday and found a link to an excellent series of articles by Sagar GV entitled "NTSC Demystified". If you enjoy electronics and have wanted to learn more about NTSC video but could never seem to find the right resource, these articles are for you!

Disclaimer: To be clear, I take no credit for any of the work done in this series of articles. All credit should go to the original author(s).

Machine Language for Beginners

Sun, 22 Jun 2014 15:00:00 GMT

Like a gazillion other people, I now have a WordPress site. Unlike a gazillion other people, this site is (currently) has no point. It is simply a playground for me to get my feet wet. I wanted to learn more about WordPress, so it seemed like a logical thing to do... I figure if I am going to do anything, it will probably be related to my hobbies and interests, so for my first post I would like to mention I recently located a book called Machine Language for Beginners that I read when I was in high school. This book might be the most influential book I ever read (well at least in relation to my career as a computer programmer). I've linked it here for you to download and enjoy.