Thursday, August 20, 2009

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.

Monday, August 17, 2009

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!)

Tuesday, August 4, 2009

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.

Monday, August 3, 2009

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 :-)

Thursday, July 30, 2009

Finally, the station has a VHF/UHF antenna

Freshly back from a bit of a Summer jaunt around BC with my sister and family who were over from Switzerland, I finally got to tackle the installation of a main station VHF/UHF antenna. The procurement of a suitable antenna has been a bit fraught. Originally, I had intended using a old Comet dual band antenna that was last in use back in the UK in the 90's. That plan was kiboshed when I couldn't locate the three screw-in radials for the base. I'm sure these will eventually turn up, but I was surprised to find that they were not where I expected to find them - in a bag full of antenna paraphernalia that I had rather nicely organised when we moved to Vancouver almost 10 years ago.

While wondering whether to contact Comet to see if some new radials could be acquired, I developed an interest in D-STAR and indirectly in 23cm (the only frequency that supports the D-STAR 'high speed' DD data mode). I had installed a Comet 23cm Yagi to point at my local D-STAR repeater, but the experience got my thinking about adding 23cm in general - i.e. obtaining a VHF/UHF antenna that included this band along with 2m and 70cm. Taking the plunge, I initially ordered an MFJ antenna from Radioworld. This turned out to be a 'special order' and was backordered for weeks. When it finally arrived it was missing mounting hardware that had clearly popped out of the little plastic sleeve that most VHF+ antennae seem to be delivered in these days. Radioworld promised to obtain the missing hardware from MFJ (and I'm still waiting), but meanwhile I decided to opt for the Comet GP-98 anyway. This antenna has a slightly higher gain across all bands, and I was rather pleased with my Comet CYA-1216E yagi for 23cm, so decided to give Comet another shot.

The GP-98 duly arrived, with all its ancillary hardware, and as a two piece I assembled it without too much trouble. The only thing that caused a bit of a sweat was whether it was OK to pull a conductor/connector down from the upper section in order to mate this with the lower selection as shown in the sketchy instuctions. As it happens the whole inner section (the actual radiator assembly) does slide, but it took quite a bit of force to get it moving, and I wasn't convinced that I was doing the right thing! This antenna has a little compression fitting to physically connect the two fibreglass sections together once the radiating elements have been joined inside. There's a little rubber grommet that gets compressed as you screw a bezel from the bottom section into the upper section. All seemed to go well until a few days later, when the temperature in the room reached the high 20's, even 30's, thanks to a record-breaking heat wave here in BC. I was doing some email, with the assembled antenna lying on the floor a few meters away, when... *CRACK*. It didn't take more than a second to associate that noise with some plastic explosively failing, and sure enough, when I turned over the antenna, the compression fitting had failed, with a nasty big vertical crack up the joint. Presumably a combination of design/manufacturing defect, over(?) tightening and the high temperature combined to destroy the plastic under stress. So, this episode created the need for a new work item - repairing the connection. Luckily the strength of the antenna is mostly achieved by having the upper fibreglass slide into the lower section, so the joint is really only there to resist mild forces pulling the sections apart, and (mostly) to provide water-tightness. I affected a repair by cementing the crack with a sealant/adhesive before wrapping the whole centre connector in three layers: vinyl tape, self-amalgamating tape, vinyl tape - exactly like waterproofing an feed line connector. Then a number of tight nylon zip-ties around the connector were added to compress the connection and also to secure the tape. The outcome was quite acceptable, though it's always annoying to have something fail like this in the first place.

The next challenge was how to rig a side mount for the antenna. The standard arrangement is to use two lengths of tubing/pole horizontally strapped to the tower with two U-bolts apiece. A standoff mast is then secured between these using two more U-bolts, and the antenna is then installed on this. Taking some advice from John White (see previous posts) on the subject provided some recommendations for type of tubing (1-1/4" OD aluminium pipe for strength, with a nominal 1/8" wall thickness). I opted to get a mast made of the same pipe, and decided (somewhat arbitrarily) to make the distance between the horizontal members quite a large fraction of the almost 3m long antenna, for stability. I therefore ordered a 2m length of 'mast', with the intention that this distance be around 1.6m or so.

Obtaining the bolting hardware was the next challenge. I wanted stainless steel, as recommended, but the local purveyor of such things only had the U-bolts, lock washers and nuts - they were 'right out' of the backing plates required to cross-join two tubes with a diagonal U-bolt. I took what they had, but my hunt for the backing plates resulting in finding ready-made 'U-bolt kits' at a large big-name hardware store. These weren't stainless steel, but they had a backing plate. I intended using this backing plate with the other stainless hardware, but then realised that the holes in the plate were a tad too big. This meant also getting some flat washers. In any case, long story short, eventually I had a full set of fixing hardware, albeit a rather ragbag pick and mix.

John had also suggested installing the two horizontal members first, loosely and in such a way that the mast end is close to the tower. Then he suggested adding the mast, then the antenna itself, and finally sliding the whole assembly out to its desired standoff distance from the tower. When I sat down to think about this, it occurred to me that there would be an awful lot of dandling about on the outside of the tower with this approach. The fully assembled antenna, with feed line attached, with also have to be lifted to position, and the whole structure would also be rather flimsy until many of the U-bolts were properly tightened, as these diagonal connections all rely on each other and the maintenance of proper right angles. Instead, I opted to assemble the whole thing on the ground and then lift the entire subassembly up the tower, securing the horizontal tubes to the tower at the appropriate place. The main challenge with this approach is maintaining the structure, because as noted earlier, all the pre-tightened joints must be kept at right angles. To achieve this, the 'missing' side of the box, opposite the mast, was provided for with a wooden stick from the garden that was nylon-tied to the horizontal members (hoorah for nylon zip-ties!). The antenna was fully installed on the mast, and the feed line was nylon-tied down the mast, with the spare coax coiled and tied securely to the bottom horizontal. Not only does tying the coax keep it under control and out the way, but having it at the bottom also handily acts as a counterweight to the antenna. This meant that lifting could be done from the top horizontal and the antenna would stay upright.

Lifting of this whole subassembly was achieved by attaching pulleys higher up on the tower than the intended final height of the top horizontal. The pulleys were shacked to a tower cross member, and they were temporarily nylon-tied to the tower verticals in order to stop them migrating inward. Ropes were threaded through the pulleys, and the ends tied with appropriate position/spacing to the top member. The raising of the whole subassembly was relatively straightforward. The two ropes provided good side to side control, and another rope attached to the outer-bottom corner provided extra control when necessary. The only fly in the ointment was a realisation that my garden stick was protruding a little too high above the assembly and would hit the eaves soffit boards before the assembly was at the desired height. This was easily remedied and on the second try the whole assembly was easily lifted to the desired location and the ropes were tied off at the bottom of the tower.

With the whole assembly fairly accurately positioned, the next task was to go up the house side of the tower (affording the possibility of leaning back against the wall and using both hands) and the two horizontal tubes were U-bolted at the desired height. This was relatively easy, though it was at this point that I realised the backing plates I had were rather 'bendy'. I'm hoping that this doesn't translate to failure later - they are more 'strap' than 'plate'. I opted to secure the bottom horizontal first, then inspect the assembly from the ground to determine the final extension of the upper horizontal - in order to get the best 'vertical' on the antenna. Indeed on inspection the antenna was not quite vertical, but pushing out the upper horizontal a little was the right medicine. The upper horizontal was then properly secured in place. At this point, the "garden stick" is no longer required to keep the horizontal members parallel, and I could have cut the nylon ties holding it and let it fall. However, I opted to keep it in place for now (in case there some reason to need to disassemble the thing in the near future).

Finally, the feed line was run down the tower and into the house in the usual way. My initial attempt to fit the inside connector was challenged by failing light and I managed to miss a small fleck of braid material that must have shorted against the centre conductor when the plug was fully tightened. On my third try I had managed to find the culprit and had myself a non-shorted plug! Early tests (receive) show the antenna appears to be receiving the club repeater well (as expected), so hopefully all is OK.

My only concern remains with the quality of the backing 'plate' I have used with the U-bolts. I have no idea whether these bendy straps will end up providing the appropriate continued force, though they are done up nice and tight, so hopefully things will pan out fine. Also, some of the hardware is not stainless steel as I had wanted - time will tell what this will mean with respect to necessary maintenance due to corrosion. For now though, it's doing the job.



Tuesday, July 14, 2009

DV Dongle update

Well, I have the DV Dongle working after a fashion, with some interesting discoveries along the way:

  1. You really need to have your application (optionally your applet) JRE set up to be Java SE 1.6. This preference can be achieved in the Mac by using the included "Java Preferences" utility and moving this JRE to the top of the list(s). Note that AFAICT 1.6 is a 64 bit only option (at least it doesn't appear on my early Intel MacBook Pro).
  2. You must start the DV Tool application from the command line, rather than double clicking the JAR file, as is normally possible on the Mac. Apparently the application is quite sensitive to the relative location of some auxiliary binaries. I've played with the JAR packager tool included with the Mac dev tools to try to wrap this conveniently as a Mac OS X application bundle, but so far the correct setting of whatever search path is required to find these binaries has eluded me. I'm sure this is possible though, and presumably an app bundle could be created that just launches the shell script that can usually be used to fire up the app, rather than having the Java launcher load and run the JAR.
  3. On my set up, using a USB headset (at least my Logitech headset) for both input and output audio creates latencies that destroy the audio. You get about a half-second period clicking/drop-out in the audio in this configuration. The simple expedient of turning the output audio to another Mac audio device clears this up so the audio is clean. However...
  4. There is an approximate 2 second delay in audio pumped through the dongle. I have not been able to make this go away. I am running on a super-fast 8-way Mac Pro with loads of spare capacity (idle CPU and low memory pressure).

So, at present, I can connect to gateways and presumably (though I have not tried this yet) transmit audio to a repeater port. The approx 2 second latency though is still a question: is this nominal or degraded performance of the DV system? If the latter, can it be fixed and how?

I'm sure a 2 second latency would not unduly prevent reasonable use of the dongle on the D-STAR network (even if this behaviour isn't quite as designed). Except for timing a break-in, such a delay will only manifest, of course, at the ends of overs and you are supposed to leave plenty of time between overs on the D-STAR system anyway. The lag does sound quite noticeable however when you use a radio to monitor the same port that you have the dongle connected to.

I think my biggest use of the DV Dongle will be to monitor remote repeaters, which I don't think is possible on current radio D-STAR implementations - though I'll be the first to admit that I still have much D-STAR-fu to learn!

Wednesday, July 1, 2009

Fldigi for the Mac

I just bumped into Fldigi, a digital modes client that supports the Mac (...well as a cross-platform app, not quite a full Mac app, but that's OK).



I was idly looking for a client that supports the Olivia mode, having heard a few hams waxing about this on the air, and good ol' Google surfaced it as a result. There may yet be other clients to be fished out of the great internet ocean, but I'm going to give this one a try. It seems to have a fully fledged macro system, and an auto-logger that exports adif - for import to other logging software, as well as things like eQSL. It supports a fairly wide gamut of modes; certainly most I've ever heard of, though more flora and fauna are popping up regularly. It also integrates with QRZ.com, so my subscription for web queries that I paid for in order to feed VisualQTH can keep on giving!

Anyway, I now apparently have a choice of two clients (CocoaModem and Fldigi), though I've yet to check that it will interface properly to my SignalLink and CI/V rig control. I think there's a good chance as these are both pretty common interfaces/devices. I've noticed that the IC-7800 radio profile for the rig control is labelled as "untested", but hopefully that's just the authors being conservative... we'll see.

Saturday, June 27, 2009

DV Dongle Downer

A DV Dongle arrived in the post today - somewhat of a surprise as the online store of Waters and Stanton were showing it out of stock when I ordered it a few weeks back, and is still showing "Back Order" as I write this. I must have been lucky for once!

Anyway, the DV Dongle is a device that simply provides the hardware codec for AMBE, the digital audio compression standard currently used in the D-STAR DV mode. It is somewhat controversial, being a proprietary component of the otherwise open D-STAR spec. The DV Dongle isn't cheap, but it's the only product that I'm aware of that enables computer software to act as a D-STAR DV gateway to the network. Obviously, this has the upshot of allowing you to participate in D-STAR calls even when having a radio isn't too convenient (such as when I'm travelling).

A least that's the plan.

The DV Dongle fully supports the Mac, and indeed the supplied software to drive it "DV Tool" is a Java app, employing the Java audio framework, along with some native components to shuffle audio streams to and from the DV Dongle, connected to a USB port. In the installation instructions you are requested to download the latest serial drivers for the FTDI UDB-Serial bridge chipset. I had done this several weeks ago as I have other devices that use this chipset (including the Black Cat USB to CI-V interface). In any case, the software starts up and seemed to connect to the dongle hardware OK.

My problems began when trying the simple loopback audio tests with my Logitech headset (a recommended configuration). The software offers two loopback tests - one without needing the dongle (presumably just the Java audio stack), and one via the AMBE encoding/decoding hardware. My experience with either of these was not good - choppy sound with a distinct periodic transient (less than 0.5s I think), and a nasty lag. The lag with the dongle in the circuit is getting on for being between 2 and 3 seconds! In any case, the results are hardly broadcastable, and I believe I have a problem somewhere that is introducing enough latency that the audio streams are starved with the 0.5s period. I could also be sequential/blocking behaviour somewhere, where asynchronous behaviour is required. Anyway, at the moment I can only guess.

I've made a posting on the DV Dongle Yahoo discussion list, and so far I have been entreated to check that I am using the 1.6 Java stack (rather than 1.5 that apparently has issues). This has certainly been the case, though I have switched between 1.6 and 1.5 in a quest to find if that makes a difference - it did not.

So, hopefully some further ideas will come forth and I can experiment some more. I'm assuming that normal operation results in smooth/clear audio, and it looks like people are successfully using this on Macs - so I remain optimistic that this will turn out to be some irritating little piece of configuration that will eventually be a simple fix. Fingers crossed.

Sunday, June 21, 2009

D-WARP an idea for "contact agency software" for D-STAR

I was thinking a little about software that would make D-STAR even more interesting and convenient.

D-STAR provides relatively easy to use global communications through its gateway connections between repeaters. I've just been fooling around a little for the first time with gateway routing to some repeaters back in my old stomping grounds in the UK. This works rather nicely, and although I've not used IRLP, the setting up of routing seems less messy than what I've read is required for IRLP.

I don't know how many hams care about long-distance working, but it strikes me that it would be nice to be able to see which stations were on and interested in accepting non-local calls. To that end, I can image a sort of directory of D-STAR stations as a web application, which could show stations cartographically or in a tabular form. Maybe every station could indicate whether it was just "monitoring", "inviting calls" or "actively calling". It might also be nice if every station could offer a "synopsis" and perhaps keywords/tags indicating major interests of the operator. That might facilitate more engaging hook-ups/QSOs between hams who determine they might have similar interests. Clearly, the listings could allow linking through to other station details, such as QRZ, or a station web site.

A key feature of this facility might be to auto-tune/route an attached radio when a calling operator selects a station to call. Furthermore, it would be good if the status of both stations could be automatically updated when either or both stations transmit between them. This would indicate online that the stations are in QSO and are not awaiting a call (though of course other stations might want to join them). To that end, it might also be nice if such connections could indicate online the topic of a conversation (defaulting to "general") and whether others were actively invited to participate. Obviously, when parties sign-off, their status should revert to their original indication - it would be nice if this could happen automatically, but that might simply be a time-out; and of course the user should be able to do this with a single click.

As well as soliciting contacts and showing a global state of D-STAR stations in this fashion, it might also be nice if stations actively in a QSO could be offered a 'dashboard' showing all the contributing parties, and offering extra features such as 'quick email' or 'send file'. These features could be mediated by the central server (i.e. hiding the details of the end-points), and could also be 'unlocked' for a given user by issuing a single-use pin that one station would read to another over the air.

I'm still very new to D-STAR, but a service along these lines would seem to really augment the capabilities of the D-STAR network itself. I'd be very interested in feedback on these ideas, and although I doubt there are too many people reading this blog, I'll see what people think as I meet/talk with them.

Thursday, June 18, 2009

VisualQTH gets an airing

I demoed VisualQTH at the club this evening as part of a preparatory demo of the N1MM logging software by Dave Shipman VA7AM for the club field days (last w/e of June in the North Shore EMO, the club HQ).

We started the app up on the projector in the main meeting room - where we expect to receive visitors while the radios in the permanent club radio room are operating on a contest. Dave then made some entries into the N1MM logging software in the radio room, and these then appeared up on the display. So things went as expected :-)

Tuesday, June 16, 2009

First D-Star QSO, and more arcana

I had about an hour free today to see if yesterday's apparent successful round-trips to the ICM repeater would translate into an actual contact.

From my cursory understanding of routing configuration gleaned from various sources, I tried to cross-band on the repeater from my uplink port A to the 2m port C - I figured that fishing on 2m would most likely to find someone.

I tried a CQ call with
CQCQCQ VA7ICM A VA7ICM C
a few times and noticed a funny message "UR? VA7ICM A?" pop up when I unkeyed the mic.
Mmmm... I wonder what that message means, I thought. Maybe there's still something wrong with my routing/set up. I figured there would be something in the ID-1 manual on possible status/error messages, but on inspection... not a sausage. Icom are very light on documenting any operational aspects of the radio in the manual - it's mostly just buttons and menus that they care to comment on.

I then tried the following routing:
/VA7ICMC VA7ICM A VA7ICM G
figuring that maybe this was an alternative way to address a port C (2m) downlink on the local repeater. This flashed up another message: "RPT?", which was equally indecipherable (though strongly suggested that it didn't like something in an RPT field).

After checking that in both cases, my call was still appearing in the Recently Heard list of the repeater on the web, I resolved to try the original routine config once again, an called once more with that setting. I just wandered back to my computer once again to check that the repeater had seen me, when suddenly for the first time there was a voice emerging from the ID-1's speaker, and I just heard my call from across the room.

The caller was Gord VE7FKY, who kindly responded to my call out through 2m. Apparently I was getting out the whole time, and what I considered (still do!) the odd "UR?" message is simply some indication that nobody has responded.

Gord was kind enough to enquire whether I had completed my gateway registration correctly, indicating that you have to complete at least one extra row of information in the "Personal Information" screen of the gateway registration - something I had not done. It turns out that this extra information is essential to having the gateway accept and route your calls across repeaters, and it occurs to me that this might be why the second form of routing mentioned above resulting in the "RPT?" message.

It's not super-clear during registration that this step is required - though in retrospect I do see it mentioned various web pages. It entails adding a single space into one "initial" field, and adding your lowercase callsign as a "pcname", and finally clicking a checkbox and a button to tell the gateway software to update that row in the registration record.

Having done this, I need to test a gateway routing again, and I'm wondering about simply retrying that second form to see if it is now working (routing out via the gateway, then back into the same repeater to another port).

I've resolved to really read about and understand what the various rows are in the "Personal Information" screen, and how you use them when (unlike me currently) you do have multiple D-Star radios.

Anyway, with my first QSO properly under my belt, I can now safely assume that all the components of my 23cm setup is working satisfactorily. I'd still like to test the VSWR of the Comet CYA 1216E sometime, especially as the ID-1 got pretty hot (enough to actually smell strongly of "new electronics"!) when transmitting on the nominal 10W power. That's probably quite normal, but it would be nice to be confident that the antenna system and feed line are in the best shape they should be. That's going to be another investment in shack gear though (there are only a few SWR meters capable of covering the 23cm band) and you get to pay a pretty penny for the privilege, so it might have to wait a while!

Aside from enjoying a little ragchewing on my newly commissioned toy, I'm gradually accreting an agenda for other things to play with on D-Star. The DD mode is a must-try sometime very soon, but I'm also reading about various tools that make use of the "spare" 1200 bps bandwidth in the DV mode (for text messaging and maybe other purposes - a BBS anyone?).

D-Star lift off!

OK, I just tested my set up into VA7ICM using the trick of setting the local gateway for RPT2 routing, but with the CQCQCQ UR Call. Everything works hunky-dory... at least I get back the error message from VA7ICM saying it can't find the call CQCQCQ.

So it looks like I'm in business, and more to the point that my handiwork in getting the yagi up and pointing in the general direction, with the feed line in good shape, is all OK.

I've tried both 10W and 1W (low power), and seem to have no problem being heard/understood by the repeater, at least for this minimal handshake. It would be cool if you could get the gateway to respond with a signal/quality metric, perhaps displaying this with your call sign in the available online logs (last heard lists), that way I could ascertain whether 1W is genuinely sufficient for reliable communication with the repeater, or whether it is borderline.

.....

I've just tried VE7RAG, which is well off-axis of my beam, and still managed to wake up this repeater too on 1W! So, I'm a pretty happy bunny. When I get time I might see if I can wake up VE7VIC too. I very much doubt I can make it into that repeater as it lies some 61.33 statute miles to the SSW. This is well beyond the stated 20mi range claimed on the repeater. I don't know how this is computed, but it's noticeably less than the 40mi claimed for both VE7RAG and VA7ICM.

More D-Star learnings

Pete (AE5PL) replied to a few questions I posted up on the
DStarUsers.org forum concerning some outstanding questions I had.

Two items of particular interest:
1. I had asked whether there was a way to test D-Star access into a repeater without bugging anyone for a radio check.
Pete said:
Sure, place CQCQCQ in URCALL, VA7ICM A in RPT1, and VA7ICM G in RPT2. You should see VA7ICM G respond back that it doesn't know CQCQCQ (you will see VA7ICM G show up on the front display).

... pretty handy!

2. I asked about gateway registration on repeaters, considering I had registered on one repeater but am likely to be using another for most activity. I was concerned as to whether you should be registered on the gateway you were actually going to be using as a 'home'. Pete's response was that you only need register on one gateway (and indeed should not be registered multiple times), and that registration on any one gateway is sufficient to use all gateways.

Considering I have yet to raise the admins of VA7ICM with this same question, I'm pretty glad my VE7RAG registration (which went through in under a day) will work anywhere.

Tomorrow I intend giving my ID-1 its first airing with an attempt to wake up the VA7ICM repeater in the manner described in (1). If I get any sign of life from the repeater on its port A, then I'll try a CQ call onto its 2m port to see if I can magic up a real QSO!

Sunday, June 14, 2009

23 cm beam to VA7ICM

My 23cm capability got real today (theoretically) with the addition of a real antenna to replace the indoor mobile antenna I had hooked up as a temporary measure. A Comet CYA 1216E is now gracing my tower, pointed in the general direction of the VA7ICM D-Star repeater in Surrey.

The rough direction to point was determined from the location of the repeater available on-line:
VA7ICM location

Using this information, I was able to plot a line between my QTH and VA7ICM using Google Earth, and ascertain the direction to point in according to visible landmarks:


As usual bumbling around up the tower was 'fun'. I especially like the bit where you are holding the antenna, with an awkward 42' of LMR-400 coiled out the back, and trying to get the U bolt/nuts aligned and tightened without slipping anything or dropping anything (least of all oneself).

Anyway, I survived :-), and in theory the antenna is aimed at the right spot for VA7ICM. In practice I may have to wait to find out if everything is working until I'm properly registered on VA7ICM and unregistered from VA7RAG (which I registered with before realising that VA7ICM is probably a better choice in terms of line of sight, even if its a little more distant). I've been waiting for a response from the VA7ICM admin for a few days, so hopefully something will be forthcoming soon.

Here are a few pictures of the new tower denizen:


Friday, June 12, 2009

More D-Star experimentation (and reading)

With the ID-1 hooked up to a temporary indoor antenna, I was hoping to hear some activity on one of the two local repeaters.

The closest repeater is only about 8.5 miles away, but Google Earth strongly suggests that its antenna is not line-of-sight from my QTH. Despite being at almost 1300', and the VE7RAG repeater being at 2700', the southern flank of Mount Fromme comes between the two locations and so this repeater is masked (though this might not necessarily be entirely 'fatal').

The next closest repeater is VA7ICM. As far as I can tell, this should be completely line of sight to my QTH. Google Earth seems to indicate this is the case, though an attempt to verify this with binoculars this afternoon was rather stymied by the haze caused by the hot weather and the results of the wildfire burning near Lilooet. Hopefully the air will clear soon and I can retry the exercise. This repeater lies some 18.3 miles to the SE, but really ought to be perfect given the LOS.

I have not yet tried to fire up either repeater yet, but leaving the ID-1 on for a few hours while surfing for information about how to 'drive' a D-Star rig I heard nothing. This isn't a huge surprise, and I suspect it's mostly likely because I'm on 23cm, the least popular D-Star band (though the one I'm interested in because of its novelty and also the high speed data mode). Also, I imagine my temporary indoor mobile vertical on a mag mount isn't going to perform terribly well - though I simply don't have any experience to draw on at this point as to whether it would be completely useless.

I have decided to erect a Comet CYA 1216E antenna and point it at VA7ICM if all goes well. I'll measure the likely length of required LMR-400 tomorrow - I'm told this will do as a feed line, though obviously it has fairly large losses at 23cm.

My research in how to actually use D-Star to initiate (route) a call has turned up some useful references. It appears that it is generally accepted that Icom's manuals are pretty woeful when it comes to edifying the new users in this regard, so most repeater groups have some sort of "getting you going" notes on the subject. Here's a summary of what I've learnt (CAVEAT LECTOR: I could still be barking up the wrong tree on some of the details!).

To route a call, there are 3 requisite fields, aside from MYCALL, which in my case is never changed as I'm the sole operator. These are UR (your call), RPT1 (uplink repeater) and RPT2 (downlink repeater).

UR is the field that addresses a particular call sign on the network (at the last heard repeater) if set to a station call. This can be set to CQCQCQ to address any station on the destination repeater(s) or on the simplex frequency (essentially to operate like an analogue radio).

If the RPT1 field is set, then this specifies the uplink repeater call. This is composed of the call sign, plus the special band/port ID always at the 8th character position. Thus, if the callsign is shorter than 7 characters, there will be spaces to pad the string out to this 8th character.

When using a repeater to make calls, the uplink repeater is always your local repeater and the port is always the appropriate band ID for your radio's operating band (conventionally A for 23cm, B for 70cm and C for 2m). All transmissions via the uplink repeater are heard on this port of the repeater by everyone.

To this point, things work similarly to an analogue repeater. However, like IRLP, D-Star allows you to gateway to a downlink repeater, or another port on the same repeaters (i.e. talk on 2m from your 23cm radio). Unlike IRLP, this is done conveniently in terms of call signs and entered directly into the radio, rather than messing around with DTMF tones and node numbers. You can use the following routing settings for different purposes (UR, RPT1, RPT2):

1. To route to a 2m port on a repeater "VE7FOO" from the 23cm port and talk to anyone:
CQCQCQ VE7FOO A VE7FOO C

2. To route to a 2m port on a repeater "VE7FOO" from the 23cm port and talk to VE7HAM:
VE7HAM VE7FOO A VE7FOO C

3. To route to the 70cm port on a repeater "VE7BAR" from the VE7FOO 23 cm port, and talk to anyone:
/VA7BARB VE7FOO A VE7FOO G

Note that the / format call means "all at desination" (repeater/port), and the "G" port in RPT2 is the repeater's internet gateway port.

4. To route to a VA7HAM on whatever gateway/port he was last heard on the D-Star network:
VA7HAM VE7FOO A VE7FOO G

Aside from these basic principles, I have read the following advice:

- You should always put the gateway into the RPT2 slot if you want DV Dongle users to be able participate. In other words RPT1 is always going to carry your call, and even if you don't need to route across repeaters/ports, putting the a gateway port into RPT2 allows internet connected stations to participate. This suggests that the forms:
/VA7BARB VE7FOO A VE7FOO G
/VE7FOOC VE7FOO A VE7FOO G
... would always be preferable for talking to any station on another repeater or another port on this local repeater.

- You can leave the RPT1 slot empty on some radios, and when you key up the repeater, this field will be filled in automatically. Apparently the repeater is not 'opened' by this interaction. I shall try this on the ID-1. It's probably also a simple way to test that you're getting into the repeater.

Apparently V2 of the Icom repeater control software allows conferences, by using a conference name in the UR field.

All sounds like good fun. I just need to be able to make it into a repeater now to give it a go. Though I had registered with the VE7RAG repeater, it now looks like VA7ICM is going to be my home repeater, so I've requested registration there and hopefully this won't be long in coming (the VE7RAG registration was turned around in a day!).


Thursday, June 11, 2009

ID-1 and D-Star in the shack

The station grew a D-Star capability today as an Icom ID-1 was added as probably the last transceiver for a little while :-)
The shack now has at least a basic capability of operating from 40m through to 23cm, though I'm still waiting for a 2m/70cm/23cm vertical antenna to be delivered as the permanent antenna system for VHF/UHF, complimenting the Cushcraft R8 on HF/6m.

While I'm waiting for the antenna, I have a temporary mag-mount and Comet mobile 1.2GHz vertical with which to set up and test the unit.

As usual, I find it a little bit of a shame that there's no Macintosh software provided for the radio, but this isn't unexpected and Parallels or Fusion serves to run small apps such as the provided control software. I think the ID-1 was developed around the turn of the century and the Mac has only recently been making anything like meaningful market share gains.

Commissioning and using a D-Star system is completely different from a 'normal' analogue radio, as you might expect. So far I have only scanned through the manual and made a very few simple configuration settings: basically setting MY CALL and storing the local D-Star 1.2GHz repeater frequency for DV mode in a memory. I was expecting to see some kind of activity on the repeater frequency, but there was no obvious activity in the 10 minutes or so that I had the radio on and tuned to the correct frequency. Thus, I haven't even been able to test whether the repeater is workable from my little indoor antenna arrangement yet. Hopefully I'll figure that out tomorrow.

How one makes a D-Star digital voice (DV) call through the repeater isn't what I'd call super-clear from the manual. From what I can gather, having set up your MY call, tuned the radio to the repeater frequency, and registered your call sign with the repeater administrator, you are ready to actually make a call. The manual deftly omits to show any actual examples of routing a call through a repeater, and only shows CQCQCQ as the call sign to address as UR (your) call to make a CQ call, but it doesn't show what you put into the repeater box in the address strip. As far as I can tell from a bit of web searching, you need to address the right ports of repeaters through which you wish to connect to the desired call sign (or CQ). Thus, it appears that to send a CQ out through my local repeater's 2m port, I would use both repeater address slots, setting the first to VE7RAG A (my side of the connection is the VE7RAG repeater's "A" port, the conventional name for the 1.2GHz radio on the repeater). The second repeater slot would be set to VE7RAG C (the destination end of the call will be the same repeater's "C" port, the conventional name for the 2m radio on the repeater). Keying the PTT is then supposed to send the call/CQ. It turns out that the port letter has to be in the 8th character position of the repeater call to work properly. None of this D-Star-Fu is noted in the ID-1 manual as far as I can see (unless its in some appendix I haven't read yet). Having read that the gateway software has been upgraded since the initial release, I'm guessing that this isn't mentioned in the radio manuals for reasons of allowing for the details to change - accuracy but not precision!

Hopefully my first D-Star QSO will happen successfully tomorrow - if I can find a willing soul on one of the three local repeater ports! Otherwise, I'll see if I can figure how to point my local repeater at a distant one, perhaps one in an mid-evening time zone somewhere in the world where I might be able to drum up someone settling down to play a little radio after dinner on a Friday evening.


Ham Radio vs The Internet

Since getting back into the hobby a few months ago I've occasionally pontificated about the relationship between 'recreational radio' (mostly what Hams do) and the internet. There are lots of dimensions to this of course, and I'm sure this has been a subject pretty much done to death in the various Ham forums as well as on the air.

Taking a quick look around the club during regular meets, you can't help notice a certain skew in the demographic. The hobby has always been male dominated, and certainly the membership is also skewed according to those who have the time to spare on the hobby. Nevertheless, there are surely far too few young people in the mix to ensure a healthy future (it seems to me anyway). Maybe this isn't as bad as it might seem - perhaps the stats would show that enough people enter the hobby in their 40s and 50s when career and family demands begin to lessen a little. On the other hand, there might be a genuine crisis about to break.

Of course, one of the reasons that young people mightn't be quite so motivated to learn about radio and participate in the hobby is that radio is no longer the only/dominant communications medium if you are initially open to be hooked by the promise of being able to make friends at a distance. I think this was one of the real attractions for me - or perhaps in my case it was more the wonder of being able to do this.

These days, with broadband into essentially every home, with the web, email, instant messaging, chat boards, forums, mailing lists, Twitter, Skype, etc. etc., one is hardly starved of communication channels. Moreover, these cover a whole gamut of 'modes': written, audio, telepresence, video etc., so you are even presented with options to suit your preference - even mood!

The computer has become a window on the world like no other tool in history, and is the ultimate communication and information device, as well as providing for more 'traditional' processing requirements. Indeed, the biggest uptick in computer usage has not been with applications to enhance productivity per se, but rather with applications that amplify social and information bandwidth.

Every one of my kids has grown up with the computer and they have always considered it a way to interact with their existing friends, keep in contact with old friends and even make new ones - irrespective of any issues of locality. They hold essentially uninterrupted dialogues and conferences with their entourage, even when circumstances such as vacations dislocate parties. I'm sure this is a pattern that they will expect to be a constant factor in their lives - in other words they now treat constant high-quality communication to anyone, anywhere at anytime as essentially a 'right'.

A related observation about the 'next' generation (my perspective), at least in the West, is that they have a tendency not to want to wait for anything. They are a consumer generation, wanting the end, and seldom being concerned or interested about the means. They also live in a time of wonders, when new 'superpowers' are regularly bequeathed them through the means of new technology - it all happens so quickly and effortlessly, so I suppose there's little need to want to learn how it works, as it will all happen without this!

Bringing this back to amateur radio, the contrast is quite stark. The hobby is of course rather more than simply providing a way to chat to friends and learn interesting tidbits along the way, but that's still why many people got into it at the beginning, even if they subsequently get hooked on the technical aspects of what makes it actually work.

Still, many people in the hobby today are there because they enjoy the science and technology itself (not just what I'll call "the gadgets", and socialising). I'm sure this will always be the case at some level, because there will always be engineers, scientists, educators and others who will enjoy the 'how'.

As a technical hobby, there is a corollary challenge here. Amateur Radio enthusiasts have historically been at the forefront of advances in radio communications technology, but like every other scientific endeavour, the advances create ever depth, complexity and the need to specialise if you want to stay at the forefront. This makes it increasingly difficult for the larger population to contribute at this level - and perhaps you could argue that this is a dynamic that turns the hobby increasingly away from pursuits around technical advancement and more toward other aspects: social, sport radio, emergency support, etc. If that's true, then the hobby is really less and less about the brass tacks of radio per se, but rather more about learning to operate in various ways. Perhaps the hobby should more openly promote those aspects to the great unwashed, rather than allowing the persistent external perception that the hobby is actually all about obscure electronic circuits.

From a purely technical perspective, the internet (and its modern access points such as mobile phones as well as 'regular' computers) wins hands down over technologies currently deployed in amateur radio. Of course, the internet can sometimes 'go away', leaving other media as superior for a time, but in general it's easy to see (and my kids tell me!) that my iPhone is the pinnacle of communications devices while I'm in range of a functioning network.

On the social side, in comparison with the general internet at least, I do think that Amateur Radio has something special to offer in terms of creating a self-selecting community that by and large has a genuine interest in technical and scientific matters (by they radios, propagation, space, engineering, genetics, whatever). My experience, at least, is that you at least get to start a conversation in areas that are a common interest by definition, and thereafter you often learn interesting new factoids in topics that are much removed from the obvious radio-oriented subjects. I find that this existence of a 'starting point' of common interest, coupled with the fact that most participants are relaxed and in a frame of mind to simply enjoy contact with another human being, is quite a differentiator compared to the internet. For all the hundreds of thousands of communications channels and forums offered by the internet, all too often the kind of conversations had there are characterised by less positive dynamics: grandstanding, competitivity, prima-donna attitudes, and other things besides. The internet is not predominantly used in a spirit of fraternity, and that makes a big difference.

So, it will be interesting to see how Amateur Radio evolves in the future with all the pressures and challenges it will face. Hopefully though, at the very least, the sense of camaraderie can be preserved however the technical backdrop evolves, so it remains a positive experience on balance, and in particular a way to discover new friends and learn new things without so much of the noise, uncertainty and 'temperature' of the internet.

Friday, June 5, 2009

Considering an Icom ID-1

My first impetus to get into radio came at the age of 12, when I was enraptured by the idea of CB and got myself set up with a rig and indoor compact antenna (later to grow into a decent 5/8 wave strapped to the chimney - once my father was persuaded to do the hard work of putting it up there). Looking back, I can see that this was a variant of the attraction that today's youths have toward Instant Messaging, Twitter and other social media. It was a way to enjoy conversing with others from the comfort of your own home (or bedroom), whenever you wanted, and at very low cost.

However, as noted before, my first interest in 'serious' radio leading to my UK amateur radio ticket came when I was introduced to the concept of packet radio. Thus, digital radio has always really been a draw. The computer is a unit of universal processing capability, and as we all know, the amazing opportunities it presents are multiplied by networking. Software is magic - within the medium of the computer and the network, I can weave any spell to make amazing things happen. I'm only limited by my imagination, and my grasp of the 'arcane knowledge' of how to wield all the available power and potential capability.

Now, the wired internet is truly a wonder in our time. Perhaps there were those who dared to imagine what might be possible if all the computers in the world were permanently connected together, but now we essentially live in those times. How quickly it happened, and yet how little we have yet to leverage of the sheer potential it creates. But I digress... Radio too is a perfectly viable medium for carrying signals, yet as I have already blogged it is disappointing that amateur packet radio has lost much of the inertia it once seemed to have. Of course, much of the problem is lack of data rate, and this is a bandwidth issue, which translates to both an issue of use of the available ham bands, and the design of popular radios. So, because 2m and 70cm radios are a cheap and apparently rather acceptable set of compromises for most amateurs, we have not seen much opportunity for those interested in 'speeding up' packet to really be able to hit their stride. This is somewhat less of an issue in the 23cm band, and so its interesting to see that at least Icom and the DSTAR system offers the ID-1 digital rig to provide better data rates on this band.

Looking at DSTAR in more detail, I'm quite tempted to add the ID-1 to my station. It offers something quite unique and interesting. I would definitely be happier if the whole DSTAR stack used in the radio was open source (including the voice grain codec employed, which I understand is included in the radio under license). Nevertheless, with the apparent availability of local DSTAR repeaters, this radio looks like it offers an interesting dimension, distinct from the other HF, VHF and UHF radios in the station.

That's the theory anyway. I think I'd like a chance to play with the DD mode (although my shack is perfectly fed by high-speed cable internet). I'd also like to play with the DSTAR global repeater network (even though I've yet to try IRLP).

A local purveyor of radios say they have sold a total of 3 ID-1s ever, which is interesting. There are other retailers in the city, and plenty of online retailers too, but it perhaps provides an idea of how few of these units are actually being used. Nevertheless, DSTAR is much broader than just local 23cm band simplex (that's the whole point), and so it doesn't matter as much how many radios happen to have been sold in your locality alone. Anyway, it would be interesting to hear directly from people who have bought this radio - what their expectations were and how/if they were fulfilled in practice.

Thursday, June 4, 2009

Testing VisualQTH

I took the VisualQTH app to the club (NSARC) today and tested it with the club computers running the N1MM software, with the help of Dave Shipman VA7AM.

The app now has some extra 'stats features' along the bottom of the window, and looks like this:


Once we had added the requisite lines to the N1MM .ini file to have it send out UDP packets to the VisualQTH machine, the software was tested with the master logging machine in the radio room, and it worked fine. The other two stations also needed to have these configuration lines added - I had wondered whether the master machine would transmit UDP for all logging records send from the slave machines, but this is clearly not how it works.

Once running, we did a few tests, including attempting to send near-simultaneous contacts from two machines, and all seems well. There are some cases where there are no QRZ records available at all for callsigns (in which case the station lat/lon will be 0,0), which VisualQTH should probably not plot, even if it adds a database entry and a 'slot' in the QSL cards column. I'll make a change to the software to avoid plotting stations with no lat/lon, and to use a particular image in the QSL cards column if no details are available online.

There was also talk of validating station callsign formats, but this entails finding some list of all legal formats for all countries around the world, and I'm not sure if such a thing exists. One could probably research this and build a list of validation patterns without much technical difficulty, but that would probably take more time than I have available.

Otherwise, the next steps are to present this to the plenary session of the club at next week's "field day planning" meeting, and see if there are any suggestions that I can relatively easily achieve in the remaining time before the field day on w/e of June 27/28.

Monday, June 1, 2009

Adding some polish

Now that the main features of VisualQTH seem to be working, I have time to tweak a little bit.

The app currently looks like this:


This shot is taken after manually entering a few stations that are dotted around the world enough to have the map automatically zoom out to essentially its fullest extent. A station in Australia, North America and the UK was sufficient to do this.

Previously, if no station image (QSL card) had been obtainable via QRZ, then the contact would have appeared mostly blank in the contact stack to the right of the map. This isn't much fun, yet many stations have not registered a station image of any sort with the QRZ database. So, in this case I have opted to display the station country's flag - if this can be obtained via geocoding on other available fields. There will still be cases where no country code can be determined from QRZ information, and in this case the log record could be used, or I could encode the callsign prefixes for all countries (an obvious step really), but getting this data together and formatting it may take a little while. In the meantime, the lookup from other QRZ fields seems to be working very well (it's possible the country field is always filled when a callsign query is made against the QRZ database too - I haven't bothered to verify this though).

Image aspect ratio is now preserved for downloaded images. Before this, images were stretched to fit the standard QSL card aspect, which doesn't work with a surprising number of images I've found in the QRZ database!

In this screen shot, you can also see the beginnings of the stats information in the lower portion of the display. So far there's only a simple pie chart for contact counties, but given time there should be other stats. I'm thinking of adding "most distant stations" and "contacts per hour", being metrics that are possibly of interest to observers during field day operating.

Sunday, May 31, 2009

More on VisualQTH

VisualQTH is now essentially complete in its critical features.

A UDP listener is now implemented in order to respond to N1MM 'external broadcast' messages. As N1MM sends XML in the datagram, the actual code to handle the message is only about 4 lines long (Cocoa giveth very nicely in this case). Setting up the UDP socket isn't something Cocoa helps with, but I've done this a few times before, and some old code from my XPlaneCentre app served again very well :-)

So now, you can use N1MM on a machine on the LAN, and with 3 extra lines of code in the .ini file, you can have it send log messages to a machine running VisualQTH. VisualQTH maintains its own database of contacts and stations, thanks to the excellent Core Data, and so you can stop/restart the application and continue where you left off.

I'm now moving into the realm of "nice to have" features - at least for the intended purpose of the club field day. These will include synthesized 'QSL cards' for stations that don't have an image filed with QRZ. I'm thinking of putting up a flag of the country, with some overlaid text showing available address info.

I'd also like to implement some 'stats' in the bottom pane of the display, showing various totals and breakdowns (e.g. a pie chart for country). It would be nice to have a display of more information for the last contact made, if this information is available - perhaps in a pop-up info box in the map, or in the information display. Perhaps enough stations have a bio or website that could be displayed somehow.

After this, it's just a matter of testing it with the club machines to make sure everything works as planned.

Saturday, May 30, 2009

VisualQTH

VisualQTH - the app designed to visualise contacts during the club field day - is making good progress.

I have now implemented:

  • Map 'animation' (panning, then zooming out to show all contacts) when a new contact is registered
  • Voice announcement of the contact call sign and the station's morse ID
  • Loading of the station's image (QSL card) from the QRZ database and presentation of these cards in a column on the right hand side of the display
  • Overlay of the geodesic path from the home to the distant station when the station is announced
  • Overlay of station call, contact time, bearing and geodesic distance to the contact, over the QSL card image


There are still many bells and whistles to add, such as contact statistics (charts of contacts by country/state, by hour etc.).
The next important feature is to get the UDP listener working and to test this with an actual copy of the N1MM logging software.

Wednesday, May 27, 2009

Station Situation Display (part deux)

I've tinkered with the situation display today.

Here's the basic idea:

  • The application maintains a queue of contacts, which is filled as UDP packets are received from the N1MM logging software. I still don't know whether the master station transmits contacts received by its client stations, or whether we have to configure each station to send UDP packets - but that's a detail.
  • The situation display will dequeue a contact and look up the call sign online (at the very least using the QRZ service). It's primary goal is to ascertain the station's lat/lon. This may appear in the QRZ metadata for the station, but if not, Google geocoding is used with any information that we find in the metadata (full address, town, country, county, postcode etc.).
  • Once the station's location is determined, this is handed off to the visualisation (map), which will plot it with a 'pushpin' into a map. Using Google Maps is the easiest thing here.
  • When a new station is added, a short audio tone is played (maybe the station ID in CW), the map moves to show the location of the new contact, with good local resolution (i.e. it zooms), then after a few seconds the map zooms back out to possibly new bounds that shows the entires geographic extent of contacts made. In theory, this view should grow as contacts are made.
  • As contacts are made, specific metrics are computed from the set of contacts received during the session. For instance: totals by country, state, continent, greatest distance etc. These metrics could be shown on a ticker, or summary board along the bottom of the display.
  • Additionally, as contacts are made, if they have a station QSL card which we can retrieve, this will be downloaded, and presented in a column down the right hand side of the display, which will scroll down as new contacts arrive (i.e. the latest contact will appear at the top).


There may be other bells and whistles, but if I get anything like as much as this going for the 'field day' w/e then I think we'll be well served, and the display should serve as a point of interest for club members and visitors alike.

With that, here's the story so far...

We have the basic Google Maps integration. Here, we see it showing the 'starting condition' centred on the 'home station' QTH pin (configurable in a preferences panel):


The basic contacts data model has been created (not exactly a hard one):

This says "A contact has the attribute of occurring at a particular time and involves a single other station", and "a station has a bunch of attributes and may be involved in one or more contacts".

The basic QRZ database querying has also been written. There's also a test/manual contact entry dialog, available from the File menu that accepts a contact call sign and time and will look up QRZ metadata as soon as the call sign is typed in. Here's what it looks like currently:


Next steps are to write the contact queue and perform the map updating as new contacts are handled.
Watch this space...

Tuesday, May 26, 2009

Station Situation Display

At the NSARC HF meeting this evening, an interesting off-the-cuff suggestion was made that it would be nice to have a realtime projection of the contacts that the club station is making during the upcoming field day weekend (which this year is being held in the North Shore Emergency Management Office, where the club's permanent radio room is located).

It occurred to me, whether or not software already existed for this, that creating a realtime view of contacts made would not be too difficult endeavour, providing a few prerequisites can be established. These are:

  1. Obtaining near-realtime logging data for contacts being made (from the N1MM software the club uses)
  2. Obtaining position information as this data is received, from at least one call sign database


It appears that the N1MM software supports contact broadcasting via UDP, which is perfect for our requirements. This way, we can have the machine that is generating the contact visualisation receive contact data in real-time. Here's the reference I found.

Next, is the problem of obtaining position information for a call sign. The question here was whether there was a programmatic interface to a major call sign database, and indeed it appears that QRZ supports this via http, so long as you have a subscription. Clearly, any given query on this database for a given call sign is not guaranteed to provide lat/long info (if the owner of the call hasn't entered it), so it might be nice to use address info (at least state/province/county/town info) to derive an approximate lat/long. This might be possible via other web services such as Google, but will need further research.

So, it looks like we can cover the prerequisites for an application to work - at least at a minimum level. The next steps are to try out the QRZ look-up and build a call sign to lat/long class. If this works, another experiment should indicate whether N1MM stations can be configured to broadcast reliably to a 'visualisation machine'. If that also works, then things then the fun can really begin :-)

Monday, May 25, 2009

RS232 to USB

While I wait for confirmation that indeed, as I suspect, the 7800 has no way currently to get characters into the onboard PSK and RTTY utilities except via a directly connected USB keyboard, I have been looking for a suitable device to emulate a USB keyboard and drive key codes on the USB port form an RS232 (or other USB) port.

A device that looks promising is the Vetra Systems 331 USB protocol converter.



Such a device would certainly fit the bill, and allow me to use the internal utilities' presumably excellent radio integration with some home brew software that will do all the fancy text handling conveniences, including substitution macros and logging.

I shall probably order one of these (they're relatively cheap, and get even cheaper in OEM version without packaging). This also gives me the motivation to get cracking on my software, knowing that by hook or by crook I shall be able to use it as intended.

Saturday, May 23, 2009

IC-7800 PSK utility interface again

So far, no response on Icom Elmer (an Icom user's help site) regarding whether there's a way to scroll back through the text buffer of the PSK31 (or RTTY) tool built into the 7800. It strikes me that I'm either being dumb, or nobody knows of a way either but can't say categorically that one doesn't exist, or perhaps my question is too specific for many people to have any idea. Anyway, I'll keep monitoring for a few more days to see if anyone has anything useful to say on the subject.

In a related matter, I had a mind the other day to write a light-weight computer application for the IC-7800 to provide a richer PSK client for radio (e.g. including substitution macros and some logging capability). The idea was to continue to use the internal modulation/demodulation for PSK (or RTTY), which is presumably rather well integrated with the radio (e.g. correct drive level, filtering, AFC etc.), and to provide nothing more than a rich terminal client. My plans looked promising when I saw that the radio's RS232 interface can be configured to send decoded characters out... but there's no mention of receiving characters for transmission in the same fashion.

Assuming there's no way to inject characters into the PSK utility other than via a directly connected USB keyboard, there's still the option of building/obtaining a keyboard emulator and driving this to send appropriate keyboard key presses. This seems rather "round the houses" when one of the first things the PSK utility will do is convert key presses back to characters... but it might be the only way to achieve the desired ends. More research needed...

Wednesday, May 20, 2009

Update on Yaesu VX-8R charging cradle problem

As previously noted I have experienced a battery discharging issue when the radio is left turned on in its fast charging station.
This problem seems to be reproducible, as I have now experienced it multiple times with two batteries (regular and high capacity). Of course, it's simple enough to remember not to leave the radio on like this, and instead to plug the power adapter directly into the radio if you want to leave it on. The radio's trickle charge circuitry seems to work perfectly fine in this regard.

Nevertheless, I feel that this issue with the fast charge shoe should either be fixed or documented - assuming that it isn't unique to my unit. Given that my unit works perfectly to charge batteries when the radio is off however it would seem that the basic charge circuitry is working - and perhaps this is indicative of a general design flaw/limitation, rather than my unit being broken in general. I suppose though it is possible that my unit is incorrectly configured to charge correctly when there's a concurrent load on the battery, but the fast charger is extremely compact and probably designed for simplicity without an fancy configuration of this sort. It would be interesting to learn from other VX-8R owners with a fast charger whether they have had a similar experience.

Tuesday, May 19, 2009

PSK31 software on the IC-7800

All in all operating PSK31 on the Icom 7800 is quite a pleasant experience. As noted previously, the built-in software may not have all the features of external software - particularly substitution macros for stored messages and auto-logging, but it does a fine job at the business end of pulling the signal out the aether and of basic message transmission.

One question that's currently dogging me though is how to scroll back up the message buffer in the 7800's PSK decoder to review the QSO. I'm still a bit fumbly operating at the moment, and managed to forget another stations call after he sent a long 'brag' message. I simply wanted to scroll back briefly to remind myself of his call, but discovered that I didn't know how to do this! The manual is quite silent on the subject in both the RTTY and PSK31 sections, though it's possible that scrolling is a general feature that is dealt with somewhere in another part of the user manual (though I've been through this several times now for general background).

I'm assuming this is possible, but I just haven't figured it out yet. I shall ask around on some forums and check with my friend and Icom-expert Adam Farson. Without scrolling, I would certainly consider the decoder tool to be somewhat deficient - so hopefully it's in there somewhere!

Monday, May 18, 2009

First QSOs - 10W low power test, 30W SSB

With the R8 finally operational and connected to my IC-7800, it was time to properly commission the 7800 and start to open the envelope of the radio-antenna combination, not to mention time to start getting to know this monster rig.

The MFJ 259B analysis demonstrated that the antenna was basically functioning on all bands (despite the non-optimality of 10m), but it's another thing to see what it will do bringing in signals and usefully radiating the power fed to it. For reasons of curiosity, low-power requirements and relative simplicity w.r.t. radio configuration, I decided to try my hand at a PSK31 QSO to christen the HF station.

The 7800 has an RTTY and PSK31 terminal built right into its operating software, so there's no need to set up any esoteric computer connections, nor install/learn any other software. While the 7800 software environment for these purposes is quite simple by the standards of the latest PSK/digital mode software, it certainly covers the basics. Beyond straightforward typed transmission and reception on a given centre frequency, the radio software adds a simple 8-message memory facility. It also takes advantage of being tightly integrated in the radio by adding frequency lock-on features for RX and TX (known as AFC and NET modes, respectively). Presumably the integration must also extend to nicely tuned modulation, for a clean PSK signal - something that would otherwise need to be configured to achieve the proper modulation drive from an external AFSK audio signal.

Before setting out for a QSO, I edited the 7800's 8 message buffers to serve roughly for CQ, end of over, brag and signoff messages. A lot of PSK31 computer software seems to support message macros, complete with substitution for the other station's call, operator name etc. The 7800 does not have such a facility, presumably partly because without a mouse interface, the operator workload would be too great to set values for these elements in mid-QSO (most software simply has you click on pertinent pieces of received text to set these). Nevertheless some automated messages are useful, and you get to program the keyboard's F1 through F8 keys accordingly.

Having done basic prep, I hit the 20m waterfall, and found a little space for my CQ call. After only 2 automated CQ calls, I managed to 'scare up' a Minnesota station, KX0O, who I worked for a very brief QSO (I was interrupted by the XYL, so had to cut it short!). Still, the signal reports were 599 in each direction and I had my first BPSK31 contact under my belt!
All in all, my first experience of working PSK 21 was very pleasant. Using the mode is a quite a visual experience - the bandwidth being small enough to allow you to easily scan over many ongoing calls/QSOs and quickly move potentially interesting signals into the waterfall passband to investigate them. As mentioned, the 7800 has an excellent features (AFC and NET) to snap to the nearest strong signals, and holding down the appropriate function key, fully tunes the radio to the signal centre for the best possible copy. Working PSK31 for the first time unsurprisingly required more thinking about procedure than I'm sure it takes with practice, and I had to refamiliarise myself with some CW abbreviations to boot. In the heat of the 'battle' one is (overly) conscious about pauses, and because the radio is also new, I did not use the pre-programmed messages at all aside from the CQ call in this first QSO, nor any subsequent ones so far. No doubt, I will experiment with these over time and get them configured exactly how I want them - including some partial messages that require manual entry of the other stations details with the automated parts.

With some early PSK success, I increased the power a little to 20W and worked some other stations. At this power, my computer speaker system noticeably reproduced the "thrum thrum" of the PSK waveform - suggesting either poor electromagnetic immunity in its amplifier, or transmission along the mains. At this point the 7800 case is not separately earthed, so this seems like a good thing to try. PSK of course drives the transmitter at essentially 100%, so the effect is likely to be more noticeable than equivalent power 'average' SSB.

Finally, I decided to try my hand at 20m SSB with about 30W of power dialled in. The band was pretty noisy, but a number of stations were audible coming in from about a 1200 mile radius SSE to SE, from the US. Using the 7800's spectrum scope, I found a station calling CQ, and managed to work K6AER very successfully for a very pleasant 40 minute QSO, with a good report (he was coming in at 599+20dbs!). The computer speaker system seemed quiet while operating SSB (and I had compression off, so average power would be way down from 30W).

All in all, a very pleasant Victoria Day long weekend of playing radio and finally getting to play with (and learn) some of the 7800's features - including use of passband filters, notch filter and Noise Reducer, all of which worked amazingly well. The Digital Selector feature remains a bit of a mystery and will need some more experimentation to find when it can help pull a signal out of noise (I couldn't make it seem to improve matters, but that might be because it is mutually exclusive with the preamplifier).

As well as messing around with the radio, I got set up with eQSL ready to work the world!

My new Ham 'career' is shaping up nicely :-)