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. 

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.

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.

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!

Honey, I Bricked My K3

K3/100 in the operating position

A couple of weekends ago, I noticed that Elecraft had updated the release firmware for the K3 back in February. I'm not much for trying beta firmware, but I try to keep up to date. 

So, I fired up the old Elecraft K3 Utility and set it to go. I did not realize at that moment that I was to undergo a multi-day ordeal. 

MCU load went OK, but then it decided to upload the FPF. It kept getting stuck on the FPF. I figured it was just a glitch, so I tried it a half-dozen times. Each time, it would fail on the FPF load.

Of course, this left the K3 unusable. Without the front panel firmware, there's no front panel. My K3 was just about as useful as a brick.

Frantic e-mail to the elecraft email list brought several helpful responses, the most helpful was from Elecraft support.

Unfortunately, it would be a couple of days before I could try their suggestions, as I had to leave my Floyd County QTH for Gwinnett County. 

Three days later, I was able to put my full efforts into the solution. Apparently, I had tried to load the firmware with an old version of the K3 Utility. While Elecraft says this won't work, what they don't tell you is that it breaks your K3 in a weird way. 

That was easy enough to figure out. However, my problem was that even after I updated the utility, it wouldn't load the firmware, either.

At some point, someone suggested I try to load the old firmware. Well, doing that is not straightforward. You see, you have to go to your firmware download directory and remove all the files that weren't in the previous firmware. That's not obvious.  Eventually, I figured out that the FPF firmware hadn't changed -- only the MCU and DSP firmware were updated. Removing those files, I attempted a full download.

Voila! It worked. My K3 is un-bricked. I was now back to firmware 4.67. Now to try the update.

Instead of selecting the option to download all firmware, I chose the option of only downloading the updated firmware. That way, it wouldn't have to try to re-load the existing FPF, saving a bit of time.

Of course, it upgraded without a hitch. Goes to show you need to use the right tool. And follow directions -- the Elecraft instructions stated you need to use the latest utility. I should have checked instead of just assuming.

The Reason I Hate Windows

It was going to be a typical casual contest weekend. I had the new 160/80m Inverted L ready to go. I had hoped to work a few more countries on 80m for DXCC, as I inch ever closer to 5BDXCC. My employer even let us out a little early, so I should have plenty of time to get everything set up. Right?

Wrong.

It seemed simple enough. Just crank up the Acer and set the N1MM software for the WPX CW contest.   The Acer started ok, but for some reason, the N1MM software would not run. Strange, it ran just fine last time I tried it. Well, that's ok, the copy I have is a few months out of date anyway, I ought to update the software to the latest before the contest.

So, uninstall N1MM, go out to the site, grab the base (2011) installer, install it, then install the latest build. Try running. Oh, it says it has to reboot before you can run. Go to reboot - the Acer waits a long time at Logging Out....

And it was about time to go off to marital arts class, so I just left the computer Logging Out.... I figured it would be done by the time I got back, and maybe I would finish the setup then. But, after three hours of class, I was pretty beat and figured I would tackle that job in the morning.

So, around 1300z, I hop out to the shack and crank up the Acer -- and it is STILL Logging Out.... Well, it spent so long trying to log out that the computer went to sleep. I'm out of patience at this point. So, I pull the battery, and unplug the power, and poof, it is ready to reboot.

Turns out, the reason it was taking forever to log out was because it was installing updates. You see, somewhere in the infinite wisdom of the Windows designers, they decided that the best time to install updates was when you were trying to log out of the computer. It obviously never occurred to them that you might want to log out only to log back in on some other account, or perhaps just reboot the machine so some software you just installed would work. No. You say you are done using that account, and it's time for Windows to take over and install the almighty updates.

Oh, and if you happen to bypass that by yanking the power and rebooting the machine, Windows takes care of that by installing the updates when you boot up. But, at least during the boot-up phase, it gives you progress information as to what it is doing, rather than simply saying it is Logging Out....

Half an hour later, it finally finished the update process, and I could successfully run N1MM. Set it up for the WPX CW contest and....

It can't talk to the K3.

OK. It was working just fine back in March -- what changed? Well, nothing, really -- except I had just installed an upgraded copy of N1MM. The Elecraft K3 Utility has no trouble talking to the K3 at all through that same port. Hmm. Maybe I should go back to the old version that was working, except when it didn't work for some weird reason.

So, uninstall N1MM, go out to the site, grab the base (2011) installer, install it, then install the latest build. Go to reboot - the Acer waits a long time at Logging Out.... Hey, I just installed all those updates! Pop battery, pull plug, restart. OK, there's just a handful of updates, should only take a few minutes.

And, once Windows had finished updating AGAIN, run N1MM and.... It can't talk to the K3. Looking more closely, it is repeatedly reporting 8020 errors. A bit of searching the internet, and this appears to be a problem related to the serial port drivers. Seems some USB serial port drivers work fine with other applications (and the Elecraft K3 Utility had no trouble talking tot he K3)

So -- what changed? Looking at the Plugable site, the latest driver is v1.8, and that's exactly what's installed. However, from my work back in January, I remember a different version -- v1.7. Maybe that's what happened -- one of those many updates must have updated the serial port driver in a way that's no longer compatible with Visual Basic.

Easily fixed, right? Just install the old driver. Well, first you have to FIND the old driver. Unfortunately, I did not make a copy of it when I installed it in January. Fortunately, after about 15 minutes of searches, I did find a copy of v1.7. Uninstall, reinstall, and pray that plug-and-play doesn't just go update it all anyway.

Behold, start up N1MM and -- it can talk to the K3! It's now almost 1500z, I've wasted two hours of contesting time fighting with the stupid computer over what was, in reality, a dependency of the N1MM software on a serial communications driver that hasn't been supported by Microsoft for five years now. (All Visual Basic support ended in March 2008)

I need to wean myself off Windows software. If only there were decent contesting software for the Mac. Hmm.

USB to Serial

Re-arranged a few things in the Micro-Shack just before the RTTY Roundup.

For years, I have been using an ancient Toshiba 4000-series laptop. My wife bought this monstrosity back in the late 90's in order to work with custom embroidery software. I'd upgraded it to Windows 98 SE, and it managed to do OK running various Windows contest logging software. While I'd rather run stuff on the Mac anyway, writing some good contest software for the Mac has been one of my Great Unfinished Projects (GUP) for many years now. That's far too long a story to go into right now.

The old Toshiba 4000 wasn't much, 400 MHz Pentium, 800x600 screen. One serial, one parallel and one USB port. It didn't even have networking (much less wireless networking). Old.

When I purchased my MacBook, I set it up through BootCamp to boot in Windows 7. I had tried to run the Windows contest software using it, but I ran into a weird problem. Randomly, after a few minutes to an hour, the machine would flash the screen blue, then reboot. Certainly you could use this in a contest -- at least, not one you were serious about.

About the same time, I attended PDC 09 and came home with an Acer 1420P. Every attendee got one. Although Acer built it, Microsoft had specced this machine. The idea was pretty simple. Microsoft had been tired of evangelizing technologies such as Tablet PC, or 3G networking, Windows 7, etc. Only to have developers say "Well, I don't have a machine that does that." Instead, they seeded the 4000 or so attendees of the conference with these machines. Sweet.

I tried to use the Acer to run contest software, but ran into the same weird problem. Since I couldn't see what flashed up on the blue screen before the reboot, it was hard to tell what was going on. So, I went back to the old Toshiba, and the Acer found some utility at work. Until about a year ago, when the Acer took a tumble off a desk and cracked the screen. It still worked, but the two jagged cracks across the screen made it difficult to use.

My XYL wanted the Toshiba back to do some embroidery, so I went about fixing the Acer. I found a replacement screen for $70, which seemed a reasonable investment. The replacement didn't have the touch interface -- so no Tablet PC. Considering I have an iPad anyway, and Microsoft has moved beyond the Tablet PC with the Surface, it seemed to be a small loss.

As I was setting up for the RTTY Roundup, I ran into the same problem as before -- random BSOD and reboot. However, I'd learned more about Windows 7 in the intervening years. Turns out the automatic reboot is a "feature" you can turn off. Now I can read that blue screen.

After a couple of trials, the culprit appeared to be the driver for the Keyspan USA-19HS. You see, the one thing that the MacBook and Acer have in common (other than running Windows 7), is they have no serial ports. In order to talk with the K3/100, you need a serial port. So I used this Keyspan device that I bought several years ago. Updated drivers were no help. Same problem.

This surprise me somewhat. I really like the Keyspan. It works great on Mac OS X. I was a big fan of Keyspan products -- a decade or so ago, I even met a couple of their developers at Apple's WWDC. At least, I was a fan until Tripp-Lite bought them out. Now, I'm not so sure.

While I suffered through the RTTY Roundup with the occasional BSOD, this seemed like an easy problem to fix. Elecraft sells the KUSB device which would be sure to work, but it's a little expensive at $40. I found a Plugable 2303 USB to Serial converter on Amazon for $13. I was encouraged when I read the driver release notes for this device had the same BSOD problem on Windows 7, but it had been fixed in the latest release.

I got a chance to try it earlier this week. Getting the drivers and setting the thing up was an experience, but not atypical for Windows. Once configured, I cranked up N1MM, put the K3 in TEST mode, and set it up to repeat CQ in CW after 1 second and left it for a few hours. All the DTR access should give the serial port a work-out. Six hours and no BSOD. Seems like it works.

The Plugable 2303 appears to be a good solution. I also tried it on MacOS X. Works fine there. It appears I can retire the Keyspan USA-19HS to MacOS X-only use.