More on the Icom IC-2820h receive audio distortion

At this evening's NSARC club BBQ I was able to air the issue of audio distortion with very strong signals on the IC-2820.

Most people seemed to agree - including stalwart "radio men" Nick (VA7NRM), John (VA7JW) and Adam (VA7OJ) that it sounded like a front end problem in the radio. There have been several comments online about the radio having poor intermod rejection characteristics, and it was supposed by those present that this could bode badly for the overall design and perhaps has a bearing on the observed characteristics of the radio.

Over the next few days I'll hopefully get to learn more about the problem via:

1. Adam's radio lab - with an RF generator and analysis gear. I'm taking the radio over tomorrow for a shake-down.
   
2. The club's antenna and bandpass filter set-up. We'll try to discern if the problem is intermod. Should be able to see this on Saturday at the club radio room.
   

Hopefully these will shine a more scientific light on the nature of the problem and then we can hypothesise over whether the problem is likely a design flaw, or something specific to my particular radio - or indeed the unlikely scenario of user error -perhaps a "don't distort strong signals" setting that I've neglected to turn on :-)

IC-2820 audio distortion on loud/pure signals?

Ever since marrying up the IC-2820 with its intended antenna, the newly erected GP-98, I had been wondering about some distortion that was particularly apparent on the audio from the club repeater's idents (both morse and voice). The audio gets distinctly raspy, and although the S meter is pegged fully high, the BUSY indicator flickers when the audio is affected. The worst occasions sound really quite bad, but the situation seems to vary somewhat. This afternoon I noticed a particularly bad phase, and decided I had better investigate.

From a high-level point of view, the problem can only be with the radio or antenna system (including feed line). Luckily, I have a perfectly good radio to act as a comparison - in the form of my IC-7000, which of course does 2m and 70cm. Connecting the, very 'gainy' GP-98 to the IC-7000 I was able to listen to a number of idents from the repeater, and these were all noticeably clean and very nice sounding audio. I also took the trouble to test the antenna SWR on the upper part of the 2m band, and found it satisfyingly very low. That should have been the case, but I had never analysed the GP-98 since installing it, so that's nice to have verified.

My Yaesu VX-8R had also had clean audio on every occasion I had used it with the repeater, though I have no way of currently connecting it to the GP-98, so couldn't achieve a good comparison there.

In any case, it certainly looks like the problem lies with my IC-2820 right now. Perhaps this is a mis-calibration or something in the radio that manifests the poor handling of a strong FM signal and/or its generated audio levels. I shall do some more listening in the next few days, and also sample opinion on the matter.

RF sloshing about

I had a report on the Canada-wide Aurora net (which I just bumped into while tuning around on 40m) that my audio was distorted at the peaks. The on air suggestion was that I might have RF getting into the radio. As I had so far experienced nothing but good reports, I was a little dismayed to hear this and immediately got to wondering what change I might have made that might have caused a deterioration. The main recent change to the station was the new V/UHF antenna, so I was a little worried that might be the cause (somehow!), but instead a quick radio check and experimentation on 40m with Adam VA7OJ revealed that it was the cable to my SignalLink USB box that was causing the pickup (or something in the box itself). A couple of ferrite chokes on the cable was reported to help a little, but the audio was only completely clean when this cable was unplugged.

More research is required as to a full solution here, and I'm somewhat at a disadvantage in the sense that my shack is directly beneath my R8, so I'm possibly even in the near field at 150 Watts peak output. Perhaps some grounding of the SignalLink box, and/or a better cable would do the trick.

Cappuccino anyone?

This is supposed to be an amateur radio blog, rather than a computing one, but seeing as I just helped out the club website with a small JavaScript enhancement, I got to wondering about the state of the art w.r.t. web programming frameworks - so perhaps you can say (obliquely) that amateur radio is partly responsible...

I've never been a fan of the web (from a programming point of view). It's really quite a hideous collection of historical artefacts, and belies the plain fact that it was never intended to be an application platform, but an information publishing platform. Who'd have thought that we would have demanded that our 'document' content should take on more and more complex behaviour and become dyed-in-the-wool applications? It's quite strange that the browser has come to be a cross-platform application runtime environment, when its only real strengths are that it acquires content on-demand (which can therefore be updated freely by authors), and it offers security by sandboxing the content from the rest of the user's machine. Neither of these advantages require a browser per se, and therefore a document rendering client would seem a poor place to start to arrive at a good general purpose application runtime environment. Indeed, IMHO, it's an awful choice, but probably the only way such a thing was really going to happen (and be so ubiquitous), because it had one other thing mostly in its favour - it wasn't formally controlled by any one commercial entity. I'm not even going to get started on the issues of standards and testing necessary to ensure that a myriad different browser clients are offering a consistent platform for applications!

Whatever the reason that a document rendered has been press-ganged into service as an application runtime, the "web" is here to stay. It offers just too many advantages to the consumer (and IT shops) in terms of the deployment flexibility and independence of other infrastructure decision making - such as what computers to buy and what software to install. Meanwhile, developers have been saddled with a pretty hostile platform for creating applications of any real sophistication, and until very recently most web applications patently 'sucked' when compared with ergonomics available in thick-client applications. The developer community knew it had to innovate new ways of coding applications in browsers, but how do you tame all the legion bits and pieces: HTTP, HTML(at various versions), DOM, Scripts, CSS, user sessions, server-side objects/databases, etc.? If you consider all this paraphernalia, most of the mess is on the client-side and/or historical artefacts of document rendering. If the world had grown comfortable with something like web-delivered pure Java as a standard cross-platform app platform, then there would still be a need to host the downloadable classes, and to provide any centralised services (such as databases), and maybe we would have kept a single port (e.g. 80) between the server and client 'sandboxes' for security - despite the drawbacks this represents. So, the server-side would look very similar to today's configurations for supporting web apps, save for the actual web service itself. The client however, would be much more homogeneous and based on fundamentally more appropriate principles for running applications. Alas, that was not to be.

So, the poor old web browser has been cast as the saviour of secure, on-demand, client-server general computing. How on earth are we going to turn this thing into a reasonable system to program? Well, unsurprisingly, the saviour seems to be JavaScript, or scripting more generally if you prefer. Each 'page' can contain script fragments that manipulate states on the page, and even the page's own structural description, in order to produce richer 'application-like' behaviour in the browser. This works fine, but has some weird properties:

1. The page structure is still at the heart of the 'application', even though any allusion to document-like behaviour may be extremely artificial for much 'application content'.
   
2. Scripts are delivered in little pieces, and an application must be partitioned into pieces (pages or bits of page) that are loaded. This is almost like the old "overlays" in applications when computer memory was stuck at 640k!
   
3. The 'drawing primitives' of the application are all derived from odd document description terms and primitives - essentially HTML tags, enriched perhaps with other technologies such as SVG that can draw on canvases that are a part of the loaded document.
   

Suffice it to say that *if* you truly want to deliver an application to some browser, then you probably don't care about having all that page description junk lying around. Rather, you just want to build your application, as usual including all the necessary logic, UI, communications, storage and other resources to allow it to perform its designed functions. Having to cross-cut all these things you actually care about, with arbitrary document/page principles is just annoying, and no fun at all. This is the background to my long-held somewhat dim attitudes to web-programming. I realised that it was necessary, but had literally no motivation to really get into it until I had some respect for the medium in which applications could be made.

Well, it looks like some interesting things are finally happening. After many years and many many frameworks, and the realisation that the only way to really achieve applications on the web was with a lot of scripting, the world finally gave a name to the way you pretty much had to develop (in just a regular browser, not a plugin like Flash). AJAX (asynchronous JavaScript and XML) was the way that the real pleasant-to-use applications were made. AJAX is all about sending (nominally) JavaScript down to the client, and then having this script request data from the server as XML. The scripts can alter page structure or draw UI elements in keeping with the data that is received on request. AJAX techniques gave us cool things like Google Maps, but AJAX was more of an idea than an actual technology until a few people started to codify the technique in higher-level frameworks that would generate appropriate AJAX web content automatically from some much more developer-friendly form of scripting. Google offered an early form of this called GWT (Google Web Toolkit), but the capabilities were still quite limited.

Wind the clock forward a few years and we now have some truly interesting new frameworks available. Two of these are SproutCore and Cappuccino. In particular Cappuccino does something quite remarkable. It actually lets you write an application as if you were writing a thick-client, modulo calls to a server to get data. Moreover, Cappuccino has chosen the rather excellent (IMHO!) Cocoa framework on which to model itself, including aping the language that underpins Cocoa - Objective-C. Thus, Objective-J is a language to JavaScript that Objective-C is to C. The Cappuccino framework is a rich library of objects that aims to deliver corresponding behaviour in a web application to that offered by Cocoa in a thick-client application. This approach completely hides all the document-centric behaviours of the browser, and instead treats the browser windows as 'screens' in which regular application windows reside. All the display entities (views/controls) can be manipulated just like their thick-client counterparts, and application logic is coherent and encapsulated in an natural way.

To my mind this is the natural evolution of the web as an application platform. If the browser has to be platform for general applications, then its document processing features should be deemphasised as much as possible - i.e. completely from a programmer perspective. It would be nice if browsers eventually turned into windows that ran JavaScript well and offered certain drawing primitives and functions. Those features could certainly include HTML rendering, but the scripting/programming layer should sit beneath the document layer, rather than the inverted case we have now.

In any case, and whatever the future holds, Cappuccino is a very interesting idea as it finally hides the mess. It also ostensibly provides a way to allow the underlying mess underneath to change while preserving the programming interface - but we'll see.
I shall certainly be spending a little time getting to know Cappuccino and perhaps I'll practice on a prototype of the D-WARP idea I've blogged about (though I've gone right off the name!)

D-STAR routing helper

Just a quickie...

I just found a very nice utility that would have helped a lot to confirm the right way to 'compose' D-STAR routings when I was first finding my way around (Icom manuals are no good for this, as I mentioned before!).

The WA4YIH "D-STAR Calculator", despite its odd name (IMHO), is a very nice little utility for demonstrating the various routings and commands that can be used in D-STAR currently (with the Gateway 2.x software and common extensions).

Though I've been au fait with the basic routings to ports/modules and individuals for a while (at least to initiate), this utility also shows how to do things such as linking and unlinking a repeater module to other repeater modules on the network - which I had only just been reading about, and have never tried.

Anyway, a very nice little tool that also hints at good practice with regard to announcing intention and calling CQ across bands/repeaters. If you're new to D-STAR and haven't played with this to get practised in setting up various calls, then I'd recommend it. Also, bear in mind that you should always put the gateway module in the RPT2 field if possible in order to allow dongle users to hear you. The "Local repeater with Gateway" and "Source Route" functions set out to do this.

VX-8R does 220 Mhz

Well, I thought I had bought a rather swanky tri-band HT, but thanks for Daniel, VE7HWD, I'm now acquainted with the 220 Mhz capability of this rather nice radio!

During a nice QSO a few weeks back Daniel and I went on a tour through a range of bands and modes just for fun. We QSY'ed our way through D-STAR, 2m FM repeater, 2m simplex, 11m FM, 11m AM and... 220 Mhz repeater. I had no idea that the VX-8R was opened for 1.25m in Canada - the radio's box and most of the manual refers to the 6m/2m/70cm bands. There are just a few references to the extra band in the manual, where you'll see it referred to as an extra US band. Anyway, suffice it to say that I was rather chuffed to discover that I had another band available to me without realising it!

On the few occasions I've monitored this band since, I can see that it's a rather quiet backwater - at least in these parts. Clearly, there are few radios that support the band out-of-the-box, and perhaps proper antenna systems are also relatively rare. Most V/UHF multi-band antennas seem to choose resonant bands at 2m, 70cm and maybe either 6m or 1200 Mhz as a third band. So, it seems that you pretty much have to know that you want 220 Mhz to get it, as it usually involves going out of your way to get this band - except of course if your HT happens to be delivered with it!

When I mentioned this discovery on the club net a few weeks back, it prompted the comment from another club member that it would be interesting to see who else has 220 Mhz capability and maybe talk the band up a little. Right now I'm finding that most of my VHF fun is currently on D-STAR (it hosts some nice nets, including Canada-wide and BC-San Francisco), but I've a mind to put a bit of a shout out on 220 Mhz sometime to get acquainted with the denizens of that band :-)