Friday, March 31, 2017

Radio 2017 - Progress March

I don't want to admit it, but no, not a lot of progress on this. No long vacation excuses this time, just busy with life. What can I say?

I did get to review the WWDC videos regarding storyboards. I (re-)discovered a few interesting things:
  • Set the main storyboard in the info.plist - I had done this.
  • You can build up window content by using content segues to multiple view controllers. I didn't have a need for this yet, but I'm sure it's coming.
  • Control-Drag directly from a menu or button to a window content view. This will produce a segue to the view controller. Easy and useful. The host view controller receives a method call prepareForSegue:sender: before the window appears for the segue. I'm not using this because there doesn't seem to be a way to associate the document window for this action when it appears on the application menu. 
So, my main question became -- how does all the other document stuff work? When you select File / Save, how does that get to the NSPersistentDocument class? Turns out, it uses a basic target/action to the First Responder. 

I just had to figure out is how to add my action method for my modes window to the First Responder. That turns out to be easy. Select the First Responder icon of the main menu. Then, use the Attributes inspector, and you'll see a list of User-Defined actions. The weird thing is, though, once you've defined them, they disappear from this list.
No matter, just add an action, then edit it to be the method name you want. Then wire it up to the menu with control-drag as before. Implement the method anywhere in the responder chain. I implemented this in my document class. And my mode window comes up correctly, and I have a unique instance of it for each document. Cool.

Next is the hard part -- trying to figure out how to associate the managed object context of the document with the modes view controller. This is were it gets weird. The window controller has a property document which points to the document for that window. How you get to that value from the view controller is something I have not figured out yet. 

Tuesday, March 28, 2017

Cycle 25

Smoothed SSN of the last six sunspot cycles.
Cycle 24 sucked.

I mean, really. Look at this graph. It's pretty clear that Cycle 24 was barely half as tall as the three cycles before it. It wasn't even as good as Cycle 20.

Smoothed SSN in Cycle 24 never made it over 82. The previous four cycles had several years over 100.

And that was after a sunspot low that lasted a couple of extra years before Cycle 24 began an upswing.

Now we're in that downward slide again. I know from experience that we're not seeing the end of the lull between cycles until the 2800 MHz solar flux gets down to 66 or 65. That's probably three years away. And then it will take a couple of years to build up. I'm thinking it will be about 2022 before Cycle 25 shows it's colors.

In the meantime, propagation on 160m and 80m should be pretty good in the winter months for the next several years.

I've told my wife, I want to be ready for Cycle 25. I want to have my antennas and station ready to rock when the sunspots come back.

Tuesday, February 28, 2017

Radio 2017 - Progress February

Well, I can't say that I've made much of any progress since the last posting. I took a 10-day trip to Israel to visit Bethlehem, Masada, Galilee, Jericho, Jerusalem -- all the holy sites. The trip was very intensive, and after I returned home it took me about a week to recover and then catch up on all my missed work.

I did spend a little time going over my test programs trying to figure out the right way to write Cocoa code for MacOS X document-based apps with Storyboards. What I'm doing seems too complicated.

So, I've decided I need to go back and find the WWDC videos regarding using storyboards with MacOS X, and it also might be useful to view the the ones for iOS docment-based apps as well, to see if that gives me any insight.

With any luck, I'll make much more progress in March.

The Station Notebook

When I originally set up my station as a novice, I didn't make a lot of notes. I wrote a few things on the back-side of my logbook pages: radios I used, antennas I put up. But, for the most part, I freely made changes to my setup without a lot of documentation.

Some years later, I had a small steno-style notebook lying around, and I used it to record certain information. Like the exact color-code of the RS-232 cables I wired up for my computer. That sort of thing was handy to have written down, because it saved a lot of reverse-engineering later I went to make another cable. But that was about it.

Perhaps a dozen years ago, I read a couple of articles about James Lawson, W2PV, and how he kept copious notebooks about his station. He even solved a sticky problem during a contest, because he kept notes about his antenna installation.

After that, I started writing more things down in my little Steno notebook. Most of it was changes I made to the station -- radios or antenna modifications. Or if something big happened -- like I blew up the amplifier. I recorded a lot more details, and I put dates on everything.

But when I began to spend most of my time out in Floyd County it put my little steno notebook out of reach. I had a new station and I still wanted to keep notes. My solution was dead simple -- I created a text document using TextEdit. I called it Floyd County Station Log.

Looking at it today, it's more like a diary. Each month, I put in a new heading: March 2017. And below that I record anything interesting that I do. I record the things that work, and I also record the things that don't work! If I don't do anything that month, I'll just change the heading to the next month.

The bottom of this document has a list of projects to be worked on. Silly now, since I'm no longer at that QTH: 6m antenna, K9AY controller, 20m and 30m traps for the dipole, tribander-Moxon  times 3 (now that's an interesting project I'll need to write about some day!), remote antenna switch, etc.

This method worked so well, in May 2015, I adopted it for my main station log. Not only did I make new entries, but I also entered all the data from the steno notebook. Plus, I went back through all of my contest comment submissions and recorded all the changes I had made to the station from November 1994 to date.

Today the Gwinnett County Station Log is a reasonably complete record of all the things I've done with the station for the last 22+ years. It has six pages of project notes at the end. Lots of stuff to work on! And, yes, I also have a smaller document for the Walton County Station Log.

I guess my point is that having a station notebook is extremely valuable. It doesn't matter if you use a small steno notebook, a spiral-bound notebook, a composition book with graph paper, a loose-leaf notebook, or a computer document. The important thing is to find a style that works for you to keep notes. After a while, there's just too much to try to remember. So keep good notes.

Tuesday, January 31, 2017

Radio 2017 - Progress January

Quick progress report on the Radio 2017 project. I've managed to get started on the casual logging program. I've created the basic framework and a local Git repository. An early cut of the Core Data model is in place. You can't do much more than run the program and create, save and close documents so far.

I have discovered that Storyboards on MacOS don't quite seem ready for prime time. First, there's a bug that windows don't cascade when creating a new document. Second, the split of the original NSDocument class into NSViewController and NSPersistentDocument subclasses creates something of a conundrum. The NSPersistentDocument owns the Managed Object Context, but the NSViewController subclass is the place that owns all of the UI actions.

To make things worse, the main menus actions only appear to be able to effectively target the application delegate. If you want to target something in the NSViewController or NSDocument, you have to write a handler in the application delegate to find the current document view controller and call the right method.

I've figured out the proper way to do the menu actions, but I'm still puzzling out how to handle the managed object context from the view controller actions.

None of this is rocket science, but it's certainly slowed things down, as I have had to create separate projects in order to figure out the most appropriate way to do things.

I'm still learning Swift. The nuances of optionals and when to use the various operators is something that will come with practice. The compiler is keeping me on the straight and narrow.

Monday, January 23, 2017

5BDXCC? - Well, Not Really.

Back in December, I made my annual submission to the DXCC desk. In addition to adding a few endorsement entities to my DXCC Mixed, CW, Phone, Digital, 40m, 20m, 15m and 10m, I also submitted enough credits for DXCC 30m as well.

Let's see, thats 40m, 30m, 20m, 15m, and 10m. That's five bands! 5BDXCC, right?

No, not really. 5BDXCC requires DXCC on 80m, which I haven't accomplished yet. Getting there.

Monday, December 26, 2016

The Radio 2017 Project

My long-time friend Chris, K4JCW, invented the term GUP. It's an acronym for Great, Unfinished Project. Naturally, any unfinished project can always be great. Because, well, it is unfinished. If it lacks greatness at the moment, there's always a chance it could be added. The greatness of any project reaches maximum before it starts.

A couple of months ago, I got to thinking about some of my unfinished software projects. I've already talked about my casual logging program. While I've made a few small enhancements over the years, it's basically the same program I wrote in 2006. There are others I've been meaning to write for the Mac for several years.

This summer, after the Apple World Wide Developers Conference (WWDC), I studied the updated Swift 3 language. It seemed to me that Swift was probably mature enough to start using. I also caught up on several videos, including those on how to use storyboards in MacOS applications, something that was certainly not possible ten years ago.

I decided it is time to develop some new Mac software. I've labeled this the Radio 2017 project, as I hope to be done within the year 2017. I have identified the need for the following applications:
  • Casual Logging Program - very basic logging program with import / export to ADIF, control of the Elecraft K2/K3, support for RTTY and PSK operating, as well as CW keying, automation via AppleEvents / Automator
  • Contest Logging Program - logging program with contests, supporting main ARRL, CQ and NA contests. Import / export to Cabrillo, ADIF. Support for CW keying and RTTY and PSK operating.
  • SDR Software to use with SoftRock Lite II - I purchased the SoftRock Lite II to use with the K3 IF frequency. This would serve as a pan adapter / spectrum analyzer.
  • Remote Control Server  and Client - to allow me to operate my Gwinnett station from anywhere.
  • QSL Tracking Software - track paper QSLs against awards.
All of these would be useful to me. There are probably a couple of utility applications to consider as well.

In writing this software, I've decided to stick to a few goals:

  • Swift 3 - the applications should be written almost entirely in Swift 3. (There are a few APIs -- notably Core Audio -- that are more appropriately accessed with Objective C/C++. I'll likely use Swift-callable wrapper classes for those)
  • Storyboards - the UI should be constructed using storyboards.
  • UI Guidelines - applications should follow the latest Mac UI guidelines.
  • Store-ready - should these applications turn out well, my stretch goal is to publish them on the Macintosh App store.
The hardest part of this sort of project is maintaining focus and motivation. I hope to help that by publishing my progress here each month. Wish me luck!