The Voice/Data Divide

There's a discussion over on K3NG's blog over the legality of D*STAR, given that D*STAR uses AMBE, a proprietary vocoder the details of which are not publicly known. K3NG raised, reasonably, the FCC's prohibition (in §97.309) on the use of data encoding methods which are not publicly documented. I've previously mentioned this here in this blog, discussing APCO-25, which uses AMBE's sister protocol IMBE. The reason why §309 doesn't apply is that D*STAR transmissions (at least those using AMBE) are regulated as voice, not data, and §309 applies only to data transmissions. There is nothing anywhere in Part 97 that regulates what encodings we can use for voice transmissions; the only limitations presented to us by the FCC relate to bandwidth.

The FCC and Congress (and for that matter, the ITU) persist in maintaining an artificial divide between the voice and data regulatory regimes that has not been logically sustainable since digitization of voice became widespread in the late 1990s. Perhaps the best expression of this inanity is Rep. Ed Markey's proposed amendment to the Freedom and Broadband Deployment Act of 2001 (the Tauzin-Dingell Bill):

The term 'high speed data service' includes any telecommunications service delivering data, represented by a string of binary bits transmitted digitally as a series of zeroes and ones, but such data services do not include, under any circumstances, bits representing voice communications, even though such voice services are also expressed digitally as a series of zeros and ones, data services being digital bits of special importance. Someone, preferably a senior corporate employee with years of experience in analyzing zeroes and ones, shall posses authority to determine which bits are which as they zip through a network literally at light speed. All decisions of such employee may be challenged and brought to the attention of government officials, but only after a wee bit, and only bit by bit.

Rep. Markey's proposal was, sadly, ruled out of order by the committee chair. This amendment (which was clearly offered for comic value) underscores the fact that, at least in 2001, while telecommunication providers could not meaningfully distinguish between digitized voice data and other forms of data passing through their network, Congress (and therefore also the FCC) continued to operate under the assumption that they could. (For more on the Tauzin-Dingell bill, see this interesting article from llrx.com.)

Sadly, neither Congress nor the FCC appears to have learned anything in this regard since 2001; even as the FCC (and also Homeland Security) pushes commercial and public safety licensees into digital voice, the FCC continues to be burdened by an obsolete voice/data regulatory dichotomy. To be fair, much of this is forced on them by Congress, and even to some degree by the ITU (emission designators, which drive the regulatory picture at a very deep level, are based only on the superficial RF modulation technique and the ultimate payload, without regard to any intermediate encoding).

As to D*STAR itself, and its reliance on AMBE, I'll simply repeat what I said back in October: "We need to encourage the development of open digital voice standards, not make excuses for perpetuating existing closed ones just because they already exist."

Syndicated 2009-06-30 00:09:00 (Updated 2009-06-30 00:52:58) from Kelly Martin

Field Day 2009

This weekend was my first Field Day, at least the first that I went to (I got my license in April 2008, but I didn't have any connections with any group, nor any radios of my own save a simple HT, in June of 2008 so I didn't participate in the event then). I must admit that I had a great time and look forward to doing it next year.

I had originally planned to mainly be a support person at this year's event, helping with setup, food, and so forth over the course of the event. At the last planning meeting I volunteered to co-captain the GOTA station this year (since my license is barely a year old I'm a good candidate for that) but my co-captain came down ill, leaving us with no station to operate. So I was back to helping with antenna lifts and such. No big deal.

I should mention that the club I worked Field Day with is the Du Page Amateur Radio Club, W9DUP, in northeastern Illinois. We ran 7A this year out of our usual site, the Hawthorne Hill Woods, a relatively undeveloped property owned by the Woodridge Park District. Running 7 stations means there's a lot of antennas to go up.

I reported to the site a little after 6pm Friday and helped with the first erection of the minibeam that one of the CW stations was going to use. Getting that up took most of the available daylight that evening. We took two shots at putting up the 40m/15m dipole for the other CW station but couldn't get a good position in the trees before it got too dark. That would have to wait until morning. I went home around 9pm and went to bed.

Saturday morning I headed back into the site arriving just before 9am. By this time it had been determined that we needed to take down the minibeam because there was a configuration problem with it and it wasn't tuning up. I missed the takedown, though. Most of my time that morning was spent helping get the previously mentioned 40m/15m dipole, the 80m dipole for the first CW station, and the G7 longwire that the digital station would be using up. One of our members has an air launcher that works really well and we got very good placements for all these antennas.

We got the last of these up around 12 noon, giving me just enough time to grab something to eat. After that I went over to the digital (PSK) tent because this was the mode I was most interested in anyway, and watched Bob KA9BHD try to work digital for about an hour, without a lot of luck; band conditions weren't very good, and there was just too much traffic to have much luck at working anything. I wandered around for a while, helping out with little things here and there, and ended up at at the 75m SSB table where I logged for a half hour or so for Pat K9PPP and then operated for a half hour or so before we decided that the impending storms to the west were generating too much QRN to make many more contacts and took a break. I went back after a bit and managed to work a couple more stations but the storm-related QRN was continuing to build. I wanted to go back home for a bit anyway, so I left the site again around 5:30 to go home for a few hours.

I returned to the site around 9pm just as the rain from the storm system that mercifully passed mostly south of us hit in earnest. After putting a couple of tarps over the digital tent to keep water out and deciding that the dangerous part of the storms were past, we decided to bring the PSK station back up. Marianne KC9JLK worked the station for about an hour making some contacts, then I took over around 10pm and worked it until midnight with Bryan KC9GRH logging for me until he went to bed around midnight. Activity was poor to moderate until around 11:30, then it finally started to take off.

I had not planned on working the station all night, but shortly after Bryan went to bed the bands really started to pick up. We had three antennas configured for this station, a longwire dipole that Marty got way far up in the trees for us that would tune on just about anything that I was using, which was mainly 80m, 40m, and 20m (I also tried 15m and 10m but didn't find anything to work), plus a pair of horizontal dipoles on a mast, one tuned for 40m and the other for 20m. The longwire was by far the best of the three, but it was much more suspectible to QRM from the CW operators, especially on 40m when they would turn their beam to point at my antenna and swamp me with S9+80 dB QRM.

Anyway, between midnight and about 5am I managed to work about 50 stations across all three bands, logging my own QSOs as I went and switching from band to band as the CW QRM got to be too bad or when I'd worked out the selection of who there was to work on any particular band. I took a short nap around 5am, at the operating position, then woke up in time for East Coast sunrise, which heralded a great opening on 20m and another 30 contacts over the next 90 minutes along the east coast. At 8am, when I finally broke for breakfast, we had logged 102 contacts, two over our 24-hour goal of 100. I did go back after breakfast and worked one more contact, then decided that if I didn't go home then I'd be too tired to drive safely at the end of the day, packed up and went home.

If you worked W9DUP on PSK during Field Day, the chances are good that you worked me. I had a great deal of fun, and you can bet that I'll be doing this again next year. About the only thing I think we need to do is work something out between digital and CW stations so we don't interfere with each other as much. And maybe add a second digital station.

Syndicated 2009-06-29 15:27:00 (Updated 2009-06-29 19:55:44) from Kelly Martin

Not dead yet!

I know, I haven't posted in a while. I've been otherwise occupied, by a whole host of other things:

1. I've returned to working on my rewrite of MediaWiki into Java. The work is progressing much better this time. I've discovered some really glaring bugs, too, although probably most of them are uncommon code paths and so don't often affect anything. Unfortunately, the way I'm using phc as part of the translation process strips comments and destroys line number relationships, so it's difficult for me to back-relate the logic errors to the original PHP.
2. Sims 3 has occupied some not insignificant part of my time lately. I'm not going to comment a lot here about the Sims; suffice it to say that I think this release is an interesting addition to the franchise with enough difference from Sims 2 (which I also enjoyed) to seriously capture my interest.
3. It's the warm season again, and that means it's time for household projects of all stripes.

I just haven't had a lot to say here, and so I haven't said much.

See you all at Field Day.

Syndicated 2009-06-25 01:18:00 (Updated 2009-06-25 01:35:41) from Kelly Martin

TLS blackhole?

So today I was called by one of my clients to assist with a problem they were having accessing a secured website operated by a major business data processing company (you know, those big companies that do payroll, that sort of thing). One of their accountants reported that he could access the site from home, but not from the office, and the behavior suggested to them that the issue was a firewall issue of some sort, and since I do their firewall consulting they called me.

Now, I strongly doubted that it was a firewall issue, but the facts did fit that pattern (as they had tested accessing the site from a laptop on the outside of the firewall and that worked), so I made a trip to the client site to investigate further.

Investigation determined that the laptop in question actually worked from inside the firewall as well as outside, which flatly ruled out firewall issues. I noted that the laptop was not in the domain while the computers being used to test were inside, and suggested that we remove one of the nonfunctioning computers from the domain. This did not help, and we pursued other options. I also noted that the functioning machine was running IE6, while the nonfunctioning one was running IE7. (The complaining user states that he was using the same computer at home as at work, a traveling laptop, but I believe he misrepresented that fact to us and was actually using a different home computer, which caused me to waste considerable time investigating whether there was a domain authentication issue going on). Further investigation showed that the site could be accessed with Firefox, Opera, and IE6, but not with IE7, Google's Chrome, or Apple's Safari. (No machine with IE8 was available.) After using Process Monitor (which is a most excellent tool, although it does generate great gobs of output that takes some effort to sort through) to understand what was causing the hang. This having led to the determination that the web server not responding for some reason, I decided to sniff packets using Wireshark, freshly installed on the laptop. The network traces for sessions using IE6, Firefox, and Chrome were quite illuminating.

The site in question was hanging when being presented with an https session using TLS 1.0. TLS 1.0 is enabled by default and used preferentially by IE 7, Chrome, and Safari, but is not enabled by default in IE 6. Since the remote server's response to an attempt to negotiate a TLS 1.0 session is to hang (it sends a TCP ack to the TLS "hello" packet, but no further traffic), these browsers will wait indefinitely on the stuck connection. Firefox (and apparently also Opera) apparently have programmers who have run into sites like this and have coded defensively around them: Firefox also tries to use TLS 1.0, but when the TLS session times out, it retries the session with SSL 2.0/3.0, which the web server was happy to accept. IE 6, on the other hand, works merely because TLS 1.0 isn't enabled by default in this browser.

The "solution" for my client was to disable TLS 1.0 on the affected user's computer; not ideal, but it works. It would be nice if Microsoft made IE smarter (like Firefox), or if they gave me a way to disable TLS 1.0 only for this site; or if the Large Data Processing Company would just fix their server....

Syndicated 2009-05-29 01:23:00 (Updated 2009-05-29 02:44:25) from Kelly Martin

Dayton approaches

It's time again for the Dayton Hamvention; once again, I will not be going. I don't have the funds this year to spare for the trip and admission. And the main point of going to Hamvention (as far as I can tell) is to buy stuff, another thing I can't readily do with limited funds.

For those who will be passing through the Chicago area on the way to Hamvention, some driving advice: Do not follow I-90 all the way through Chicago. You will run into the badly congested O'Hare Toll Plaza at the end of the Jane Addams if you do this, not to mention I've heard that the west end of the Indiana Toll Road is a mess as well. You'll be better off bypassing around the city with a combination of I-290, I-294, and I-80. If you need help, there will be, no doubt, plenty of local hams monitoring on the local VHF and UHF repeaters; for example, I'm almost always monitoring the DuPage Amateur Radio Club's 2m repeater at 145.43(-) PL 107.2, and I'll be monitoring 146.52 as well starting tomorrow or so.

Syndicated 2009-05-12 14:34:00 (Updated 2009-05-12 14:49:52) from Kelly Martin