The Great LoTW Outage - Continues.

Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.

--

When I wrote the article back in May, I hardly thought that LoTW would be down a month later.

Sadly, the outage continues. 

My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.

Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.

I do hope it is soon. I'm really missing this service.

The Great LoTW Outage

May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.

That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error. 

So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.

Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.

But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information. 

Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.

What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.

I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.

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!

2Wire 2701HG-B Disconnect Problem - SOLVED

It's been eleven months since we got AT&T internet at the parsonage. At first, we ordered Comcast internet. They even sent us a modem. But there was this little problem of not actually having a cable plant out in the country where the parsonage is. They did finally quote us a price -- $5400 to install cable. No thanks.

So, we were thankful to get 6 Mbps/.5 Mbps AT&T DSL. They installed the 2Wire 2701HG-B Modem/Router/Wireless access point. This has been OK, except for one nagging problem.

Randomly, without warning, the router INTERNET indicator would go dark, the DSL indicator would go red and start blinking. Soon, the DSL indicator would turn to green blinking, then solid green, and the INTERNET indicator came back green. This takes 8-10 seconds, all the time the internet would be inaccessible. This might happen a couple of times a day, but more like twenty -- and more often, it seemed when someone was actively trying to use the internet.

This was especially bad when I was using Skype or my cell phone (my microcell is connected through the same internet connection). Or if I was using a virtual private network connection (VPN) to my work computers. That disruption would reset the VPN connection, and I'd have to go through a ten step process to reconnect. Perhaps two minutes later, I could try to work again. At least until it tries to reset.

Last weekend, I finally got tired of it. So I searched the web for information. Using some of the diagnostic pages inside the 2Wire router, I determined that the sequence of flashing lights represented a DSL Link Retrain. Those of you old enough to use analog modems will remember the distinctive sound of tones just before the modem connected. A DSL Link Retrain is much the same think -- only at 300 kHz instead of at audio frequencies.

Further searching revealed several articles by those unimpressed with 2wire products. One of the options is simply to replace the router. Being a ham, I'm not one to want to rush out and spend money I don't have to.

The AT&T Community Support forum unearthed an excellent thread: AT&T 2Wire 2701HG-B Disconnects / Drops. This had six pages of comments, and it took nearly an hour to read.

One of the suggestions was to measure the throughput of the connection using SpeedTest.Net, in order to determine that the DSL line was provisioned correctly by the phone company. When I tried this, as soon as I hit the uplink test -- DSL Link Retrain. I tried it a half-dozen more times. Every time I hit the uplink test, the router would do a DSL Link Retrain, save one. I now had a reproducible test, so I could try the various suggestions.

1. Turn Packet Flood Attack Detection to Off - the theory is that activity on the router looks like a denial of service attack. Easy enough. Turn off the settings and try again. DSL Link Retrain.
2. Move the Power Supply Brick to the Wall Outlet - theory here is that the 2Wire devices have marginal power supplies, and any reduction in voltage might cause a random glitch when the device draws power when doing something. Another easy test - replug and try again. DSL Link Retrain.
3. Switch to 802.11b Wireless Networking - the theory here is that the 2wire devices can't internally handle the speed of 802.11g (54 Mbps) and the slower 802.11b (11 Mbps) allows the device to work correctly. Change the settings, re-do the wireless connection on the computer and try again. No DSL Link Retrain in five tries. 

At this point, I switched back to 802.11g, just to be sure the problem didn't just randomly go away. DSL Link Retrain. OK -- I'm not real happy about running 802.11b all the time. Not because of the internet connection, because it is only 6 Mbps/.5 Mbps anyway. No, two things bother me. First, I have other devices on the wireless network, such as iPads and iPhones, and I don't relish synching them at 11 Mbps. Second, the results from SpeedTest.NET were about 10% slower on 802.11b than on 802.11g.

I did notice that the router does have a speed limit setting for 802.11g. I switched it to a limit of 12 Mbps and tried again. No DSL Link Retrain in five tries. OK -- that works. And my 10% improvement in internet speed over 802.11b is back. Good. Try limit of 24 Mbps. DSL Link Retrain. The only other setting between them is 18 Mbps so try again. No DSL Link Retrain.

I've been running like this for most of a week and am pleased to say that I have suffered no further DSL Link Retrains logged by the router. It seems that high wireless speeds cause the router to reset the DSL connection. 

Frankly, this seems to be a product defect. It might be best to disable the wireless access point in the device and instead use a separate wireless access point connected to one of the Ethernet ports. (Unless, of course, that triggers the problem) I have not tested this.

A better solution may be to replace the 2Wire equipment with something that actually works. If anyone has suggestions, let me know. In the meantime, I'll be enjoying my slower (but working) wireless internet.