Please realize this is a log of thoughts and impressions. I am learning as I go. Often my "problems" are cleared up later on as I learn more about the radio. If I am critical, it is because I see a lot of future potential.

The latest installment comes last. Jump to the bottom, if you like.

Quick jumps to subjects covered

2/12/2004

Orion #12C10493, received today

• Hooked up with Bencher paddle, old Sony headphones, and antenna.
• Downloaded the latest firmware 1.369, which came out while the unit was being shipped.
• The firmware upgrade utility is Windows specific and not especially smart about ports. Running under VMWare & Linux host, there was confusion about how to map USB-based serial ports to COM ports in Windows. Eventually, we connected OK, but not before being warned that your firmware load might have corrupted the transceiver in a permanent way...
• I did not even try the "verify" function, based on some other users' comments about their problems. Anyway, I assume that the Orion loader does its own validity checking, right?
• The upload is quite slow – about 10 “lines” per second for some 9600 lines of code. A higher speed port would have been nice – say USB or Ethernet.
• One CW QSO with N9VB to prove that we can do it. (That's a $3,000 QSO!) Trouble working with the RIT to keep in the passband.
• 10 Hz is too small and 100 Hz is too big a step size for tuning. And it's a little too awkward to change step size when you want to search a wide band and then zero in on a signal (CW). The “xm” feature takes care of this pretty well.
• Note that the receiver is very “noisy” -- with the AGC working to keep the noise floor up close to the level of a strong signal. This is a “feature”, but it's tiring on the ears if you want to listen to a signal that's well above the noise floor. Cutting RF gain seems to help, but it's probably not the right way to handle the situation.
• Using “multi” to select integers (e.g., NR setting) is not positive enough. Need a click detent kind of thing. Maybe just slow down the sensitivity.
• Selecting NR, NB and other integer things might be better done with two buttons: “up” and “down” rather than the rotary encoder.

2/13/2004

The LCD panel:

• Off-axis viewing is a problem. You have to be more careful about angling the radio so that you view close to head on, within 30 degrees or so for best results.
• Display esthetics. I'm used to a 1280x1024 color screen with 400:1 contrast for computer work, which allows lots of room for artful display icons, etc. A monochrome 320x240 display with fairly low contrast is rather too stark. You can get better displays on PDAs and cell phones nowadays. Well, not quite.
• Push button/multi controls, e.g., NR. The “multi” knob is too far away from NR and some other buttons. I would say that “multi”, because it has a special and frequent function, should be different from other knobs – size, color, shape, etc. Ideally, it would be “centered” among the buttons – in the middle of the LCD?

The display/control paradigm

• The control panel could reconfigure itself according to operating mode. I was struck by how much simpler it was to move to my IC-R8500 to do some SWLing. (The 8500 performance is not as good, but its controls are very straightforward compared to Orion's.) If you're not using the subreceiver, why display it? If you're doing RTTY or PSK, you want to see a better narrowband spectrum display, etc. How about a RTTY/PSK tuning indicator? Not to mention decoding & display on screen. A visual zero-beat for CW would eliminate the “spot” button.
• In general, the screen should provide more information about the signal. A simple oscilloscope to see waveforms, tuning data for cw/psk/rtty. AM & FM carrier offset. Very importantly, more visual clues about how the AGC, NR, notches, etc. are working.
• The front panel display should show more info about the hardware: model number, revisions, serial number, possibly owner id and address (password protected?).
• Provisions for accurate frequency measurement (zero beating, etc.) - both to measure off-air signals and to calibrate local standard.
• Don't understand interaction of DSP (e.g. NR) and S-meter reading.
• Continuously adjustible BW/PBT is nice, but it would also be nice to be able to switch quickly among some standard settings – CW narrow, CW wide, SSB narrow, wide, etc. Adjustable step size helps.

2/17/2004

The RigBlaster Saga

• We spent a day or two trying to figure out how to set up for PSK31 and other “sound card” modes. Specifically, how to configure a RigBlaster Pro for the Orion. The RBP is an amazing device, with lots of flexibility. It is well-constructed and packaged, and it isn't cheap. Unfortunately, it is not as flexible as it needs to be for the Orion. The obvious interface on the Orion side is the AUX control cable, which has audio in and out and push-to-talk all available through a supplied cable terminated with RCA phono sockets.
• First problem: the RBP is provided with 1/8” female stereo phone jacks. So an adapter cable or connector surgery is required from the start.
• Push-to-talk 1. Orion wants a pull-down to ground at the control input. RBP does not provide for this obvious possibility. However, by adding one wire jumper to the RBP board, I can cross-connect the EIA RS-232 RTS line (coming from the computer serial port) to a line receiver that drives the FSK open collector output port. [That is, connect one end of a jumper to R26 (on its J17 side). The other end plugs onto P16 pin 11.] What happens if/when I want to do “true” FSK control? We will cross that bridge later.
• Push-to-talk 2. After implementing the FSK solution above, I realize that (at least with my KPSK software on Linux) the CW signal is asserted along with RTS by the RS-232 port. So, the CW output can switch the Orion PTT line. However, with other software and other modes, the CW signal may not be the right choice.
• Audio Input (computer to Orion). The Orion mic wiring uses the connector shell as a signal lead, which the RBP can't handle. That's OK, we don't want to use the Orion mic input, asince we have the AUX input available. Best not to insert a device between the microphone and the rig, anyway, because it's a route for noise, hum, and stray RF to get into the low-level audio line. The RBP does not (as far as I can tell) provide an isolated high-level output to drive the AUX input on the Orion. There is the “Speaker output” jack, which will work, however. Thinking that the “microphone output” might have better isolation as well as being controlled by the “level set” pot. on the RBP, I decided to use that output instead. Two problems: the level is pretty low, and the only jack provided is a female RJ-45. I made up an adapter of RJ-45 to RCA phono -- as strange a pair as you're going to find. I had to sacrifice a good 8-wire Ethernet cable. And it turned out the level is acceptable if you run the sound card near its maximum output (almost 4v p-p for me) and if you run the AUX input gain at 100.

PSK31 operations

• Having done all this, I've been happily working PSK31. The Orion is a vast improvement from my old rig on receive. The flexible and sharp DSP PBT options really help to minimize dynamic range & interference problems.
• The one operational problem is the awkwardness of using the DSP controls and coordinating with what I see on the waterfall display. Ideally, we could do the passband tuning from the computer display via point & click. The two operations I think you would normally want would be “isolate this signal in the narrowest window” and “open up to full 3 kHz passband”.
• In an ideal PSK world, you'd like to monitor the spectrum while sending (sort of like QSK) and you'd like to see the whole 3 kHz waterfall, while decoding a narrow bandpass. I suppose you need to use the subreceiver and a second soundcard (or maybe the other channel of a stereo soundcard).

CW

• QSK is neat. I hadn't used it before. I find the relay noise a little objectionable. The relay has a odd high-pitched squeaky note. Sounds like a cricket back there somewhere, and it doesn't help my sending.
• The other problem so far is the “Spot” button. I'm not completely non-musical, but it is hard to “zero beat” a CW signal by comparing with this tone, especially if the signal is weak. There ought to be a better way, given all that DSP power.
• It's dangerous to leave the Orion set up for CW. Several times I've done this and randomly bumped my key paddle. You can end up sending lots of junk out on the air this way. There should be some kind of easy-to-set “transmit enable” function to prevent miskeying. It would be worse if there were little harmonics and pussycats around.
• I suppose the same comment applies to SSB and VOX operation. If the rig is “primed” for action, this is important to know at a glance. Maybe there should be a red flag for this condition.
• Using QSK, there is an annoying "thump" between code elements as the RX comes back on. The effect depends on the selected bandwidth. It is worst at about 1 kHz BW and it gets more bearable for BW < 600 Hz or > 2 kHz.
• A really odd one: The Morse keying rate slows down if you vary the DSP quickly settings while sending. (Try this with the TX disabled!) Apparently, TT uses the control processor to do the keying, and it gets loaded down. I wish they'd spent a dollar and implemented keying in its own chip...

The Display

• Oops, we are only black & white! Color would add a lot when you think about mode flags, warning conditions, etc, that would be visible at a glance across the room if you had color.
• Thank goodness there is no BLINKING on the display! Although it would be a way to highlight error conditions or special modes.
• Well actually there is a blink-like function - the display of SWR when transmitting. This is not well described in the manual. What is that SWR reading? Is it SWR out of the RF final and into the Antenna Tuner? Or is it the SWR on the Antenna Output connection (after the tuner)? I guess it's the former, because the SWR is lower if the tuner is engaged and tuned up.
• What's with those vertical bars where the SWR displays? Oh, yeah, it's the subreceiver S meter...
• This brings up the “display paradigm” issue. Can users have a clear model in mind when dealing with the display? Are we talking “desktop metaphor” like a computer? (No.) There should be some philosophy, however. The SWR/sub-S-meter is the only example I have found of screen space overlaying. You could easily see the spectrum analyzer space as a utility area for other signal/status displays. Curiously, there is nothing to show there if the sp. analyzer is off. Can't we be more creative?

The Power Supply (963)

• A nice black box, but the TT label is garish.
• Problem: the fan is controlled by a simple on-off (click-click) thermostat mounted on the big heatsink. This is effective and cheap, but you really notice it in a quiet environment when the thing clicks on. The fan isn't loud, but is very noticeable. This seems to be a few percent of the time for the Orion in receive mode. It would be a lot friendlier to have a variable controller that lets the fan run continuously but only as fast as necessary. Ask any "quiet PC" builder. The technology is out there.

2/18/2004

TX/PTT Control

• The AUX input for PTT is a real problem for me, since I have my RigBlaster Pro connected there. Several times I have inadvertently let Bill Gates and Linus Torvalds key the Orion as I have rebooted my Linux-VMware-WinXP computer. (This happens even with the RBP power OFF!) Sure, the Orion's transmitter enable menu option is there, but it needs to be up front with a physical switch. I may have to install an outrigger box with a switch and pilot light just for this! Some people are more paranoid about this than I, for example someone who had installed a key-operated switch to be sure that unauthorized people could not transmit. (Afraid of the cleaning lady, it seems.) [Update 2/24/2004: Deselecting the Tx VFO (neither VFO A nor VFO B) disables the transmitter more easily than using the menu.]

Computer Communications

• I am interested in rig control software, having developed some for my Icom IC-R8500 receiver. My tool of choice is Python (an interpretive language similar to TK/TCL, PERL and others) running on Linux. Python is also available for Windows & Mac. For now, I'm interested in simple command-line interfaces that can be plugged into scripts. N4PY has a nice product that offers the full visual experience, although only for Windows.
• Cracking the "Orion Programmer's Reference Guide" for the first time, I am relieved to see that the command syntax is very straightforward. You give it an ASCII text string and it gives you back a string. It is easy to generate and to decode. This compares with the IC-R8500 which is a horrible mash of packed BCD codes, with incomplete documentation. It only takes a minute to get a "hello world" program running.
• The format is easy, but inefficient, for example, if you want to get a full dump of everything. It will be interesting to see how much time that will take. I was hoping for a single "status dump" command that transmits everything in one gulp. No, you don't need that very often if at all, but if you want a fast, live display on the computer, you'd rather not have hundreds of separate queries.
• One of the first commands I wanted to check is not documented in the Guide: the "?V" command to see the Firmware version number.
• The "XX" command (software restart) is interesting. This is supposed to "cause the DSP firmware to reinitialize", but there is no visible effect on the Orion panel. I was expecting to have it go through the power-on restart. Is there another command for that? Not to mention the dreaded master reset option? What does "XX" really reset?

Aside on Time of Day

• The Orion is one of the few computer based devices around here that does not have a time of day clock. This is good and bad. There is nothing to set, but it means that the system has no idea of the passage of time. It would be interesting to have the Orion keep track of hours of operation, and maybe even keep an internal event log. It could tell you when you are due for an oil change... etc. So, there's my first candidate for how to use the "analyzer off" blank LCD space. A fancy day/date, local/utc clock.
• (Update 2/23/2004) Looking over the Orion schematics, I see a M48T35 256 Kb timekeeper SRAM chip, which has a clock & calendar function. So we could get the clock function on screen with just a little more firmware! The hard part is figuring out how to set the time & date -- using the "multi" knob? Decode WWV?

2/19/2004

Frequency Accuracy

• You can use the "spot" method to measure frequency to < 1 Hz precision. I checked this on WWV at 10 MHz. With my 700 Hz spot, I can get a aural zero beat at 10.000696 MHz. This means that the Orion oscillator is 4 Hz high at 10 MHz, an error of 4 x 10**-7 or 0.4 ppm, well within the "+/- 3 ppm over temperature" specification. This assumes that the "700 Hz" is accurate better than 1:1000, which I cannot easily verify. It's amusing to do this by ear, but I'd still prefer a tuning indicator on the screen.
• [Note added 8/2005] With current firmware (1.372), if you get a zero beat with the Spot tone in CW mode, the VFO reading is correct without adjustment. I.e., zero beat does not depend on sidetone frequency. See blog.aa6e.net for further information.

2/23/2004

Back to the Serial Port

• I've been spending some days working on Orion-to-computer communications. Looking carefully at the radio from the "back side" has been illuminating. While TT gets a "5" for the RF platform, which is what most users probably ever see, I'd give it somewhere from a "3" to a "4" (on the eHam scale) for the control software and interface. I will be offering more details and the software itself on this site soon, so you can judge for yourself. I am coming to the view that the control processor (Motorola Dragonball) is either underpowered for this application or that the firmware running on it has design problems. Lots of users point out that the radio hangs up or shows unexpected behavior arising from bugs or overloads in the control software, and I have seen this too. Spinning the tuning knobs shouldn't kill the serial I/O. The radio should know what mode it is in without any master resets. The purist in me says this is unacceptable. A radio design that is going for state-of-art RF performance at a premium price point should have bulletproof controls.
• On the other hand, we can't argue with success, and maybe the glass is half full rather than half empty. The positive side of the firmware situation is that updates and bug-fixes are coming out frequently. Still, incremental fixes aren't going to make more horsepower in the CPU and a basic redesign of the software architecture is probably unrealistic.
• So, I have mostly finished a Python program that more-or-less replicates the Orion's front panel display and does not self-destruct (due to shakey communications) very often. It is only a status readout and does not control the radio. It is interesting to learn Python, curses, and Orion-speak at the same time.
• The Orion is sold as a radio and not as a computer peripheral. I have to remind myself of that.

2/24/2004

• The OCTL software is now on-line. Have fun!

2/25/2004

• Added info on my PSK and RigBlaster Pro setup.

2/27/2004

Power and PSK

• I set up with a vswr meter (Heath SA-2060A tuner) and dummy load to check some reports I saw on one of the reflectors. It's not clear how the Tx power meter and power control setting actually work. With a steady CW signal, the external meter and the Orion meter and control setting are roughly consistent, within 5 or 10%, anyway. I could verify the automatic Tx level system by transmitting at 1 W, then key off, set power to max, and key again. The Tx output ramps up smoothly over about a second to full power. I guess this has a protective function, in case the Tx is facing a poor match. The delay is also there when power is decreased. It's not clear why that would ever be desirable.
• Transmitting PSK into the dummy load at maximum power and the meter indicating 100 W, I see the output power is about 50 W. Apparently the Orion meter indicates peak and not average power. This helps explain how transmitting full power with PSK shows so little distortion. The AGC adjusts appropriately. Very nice.

2/28/2004

Serial Port quirks

• Posted a list of odd facts and observations on how the Orion looks to a PC program talking on the serial port.

AGC, Oh no!

• I'm getting a little more motivated to look at the digital AGC situation. Sinisa Hristov (YT1NT, VA3TTN) has posted his "Using Orion's Receiver " which is helpful, but apparently not the full story.
• It's distressing, as Sinisa points out, that the "uV" units used in the AGC setup are not related to S meter display or any other data that are visually available to the user. The "signal splitting" or "expansion" feature could be very useful for weak signals, but requires a critical adjustment. I would want support (on the LCD) for setting this number. I could imagine a histogram of output power showing the AGC threshold as an arrow.
• The "NR" function seems to be an automated version of the "expander" - suppressing everything below a noise threshold and boosting signals above. The NR works amazingly in some circumstances, but it is on autopilot operation except for the averaging time.

3/1/2004

More PSK!

• I have posted PSKmeter.py, an open-source Python version of the display & analysis software for the PSKmeter accessory. It uses the Tkinter GUI system. It works pretty well, but could use a little more polishing. (No, this is not about the Orion!)

3/13/2004

• PSKmeter.py is much improved. It is now at release 0.20, well on the way to an "alpha distribution".

3/15/2004

• The final piece to tie together the Linux/ORION/PSK desktop is a little frequency and filtering application called OPSK. This is still a work in progress, but you can get the flavor of it from the screen shot. It's in Python, of course.
  
  You can select the "official" PSK frequency in each band, and then you can set the filter width and PBT offset to zero in on the desired signal.
  
  The "Wide" button lets you instantly select full 3 kHz bandwidth. The "Tune" button lets you cycle the ORION's auto-tuner. Or at least it would if the "*TTT" ASCII command was not broken, as it seems to be with firmware version 1.369!
• The objective of all this is to get an integrated desktop for PSK work (or other digital modes). The current AA6E desktop looks like this
  
  
  
  What you see is the KPSK PSK send/receive program, OPSK to control the ORION, PSKmeter.py running the PSKmeter signal monitor, and jLog logging software. (KPSK has a "baby" logging facility, but jLog is much more powerful.) I think we're getting there!
• There are some features we don't have yet, but would like. The PSK data software should be integrated with receiver control, so you could use drag & drop to zero in on signals without moving to another window. jLog will talk to the ORION, but it won't share the port (I think), and that will be a problem. The "right" solution would be to provide for interprocess communication between the apps, which doesn't exist now, alas.

3/23/2004

RTTY!

• The Orion supports old-fashioned RTTY via true FSK keying. Trouble is, much of the RTTY action these days -- and all of PSK31 -- uses PC soundcard interfaces. How many old-style RTTY terminal units are still in use? I haven't run across any Linux software for FSK keying and RTTY operation. In principle, FSK keying is simpler and produces a better signal than soundcard audio. However, you still need the soundcard and sophisticated programming to decode the digital modes. (Hmm, I do have an old KAM+ around that will do the FSK signal processing. All you need is a dumb terminal or emulator.)
• It shouldn't be a big leap for TT to include full RTTY encode/decode in firmware. (The IC-7800 has it.) The DSP hardware could clearly do it, but you need a good tuning indicator. Apparently, the '7800 can also handle PSK31 encode/decode, but without AFC, tuning is tricky. See JA7UDE's excellent IC-7800 web page. (Bloggers of the world, unite!)
• I haven't found many software options for RTTY under Linux. I have been working with hfterm from Günther, DL4MGE. This software handles Pactor (I), Amtor, GTOR, as well as plain old RTTY. It is a little more tricky to set up than I would have expected, requiring a root privilege process (for real-time priority) and a user-level process. I am still climbing the learning curve. Unfortunately, it does not support the newer digital modes (PSK31, MFSK, et al, or Pactor II or III), so it will not be a complete solution for me. One quirk that annoys me: it does not seem to know how to send RTTY idle characters. That means if you stop typing, you're sending pure carrier.
• I think MixW is great. If only it could run on Linux! (or MacOS, etc.) It handles the modes I'm most interested in. It would be a shame to switch operating systems just to get the application I want. I can (and have) run MixW, Digipan, and Multipsk under VMware on my Linux system. They do run OK there, but I hate to keep VMware up all the time (300-500 MB, viruses, etc.), and there's the problem of coordinating logging between the two environments.

3/26/2004

Band-Stacking Registers and Mode Selection

• Someone gave the Orion a -40dB IMD reading while running PSK31 today. Amazing, if true!
• These "band stacking registers" are odd. There are four "registers" for each band, and you cycle through them by repeatedly pressing the band select button. Each register remembers the VFO setting, mode, and bandwidth. BUT there is no indication on the LCD which register you have selected, and there is no way to explicitly set up the registers the way you want them. They are not accessible from the computer port.
• What are the stacking registers for? The way I use them is generally to keep one set for each mode I am likely to use in each band: one for CW (LCW) in the low end of the band, one for PSK (USB), and one for voice (USB or LSB). But they frequently get messed up and disorganized because you can't tell which one you're using a given time, etc.
• I would prefer to have the registers to be programmable and lockable and visible on the LCD panel. I would want to set them up once for each mode and each band. But...
• Really I'd like a band-mode-select switch -- which could be the existing MODE button coupled with the band stacking registers. When I switch mode, I (often but not always) want to switch to a standard filter settings. Of course, I don't necessarily want to switch the VFO setting (except for PSK31, where I might want to go to the standard frequency in each band).
• Changing modes in the current system is just too inconvenient. It takes 3 button presses: MODE, followed by mode selection, followed by MODE again to unselect. There should be a simple multipole rotary switch to select modes! This problem was solved a long time ago on my Kenwood TS-520S!

4/14/2004

A Little Repair Episode

• One day recently, the Orion's speaker quit. Headphone audio was normal. After a while, I discovered that the speaker came back to life if I pushed the CW key plug in one direction or the other. Something mechanical was busted.
• I had opened the Orion's case a couple of times to admire the contents (and the empty space), and I had noted how inaccessible the front panel logic was. That's where the control computer, DSP, and LCD live, of course. Lots of little screws! A fair amount of plastic and expensive stuff that you don't want to break. I opened it one more time to look at the headphone/CW jacks. How could I check out the jack? Its shorting element that enables the speaker was probably disconnected or bent, I thought. They are mounted on a small adapter board, which plugs into the big keypad/front panel motherboard. And you can't disconnect the adapter without disassembling the whole front panel assembly.
• I was worried about going further, because of the chance of doing "real" damage. I placed a call to Ten-Tec repair, which was answered by a gracious gentleman who encouraged me to send the rig back for them to look over. I wasn't ready to give it away for a week or two and subject it to the hazards and costs of shipping. He suggested using some "de-ox" to clean the contacts. The main thing he told me is that, no, this was not a "known problem" and there was no "magic" to recommend to me. That's what I needed to know.
• To make a long story short, I did disassemble the front panel, found an unsoldered hole on the front panel motherboard, and got it all back together and working. This was very educational, but it was a high-risk project. I wouldn't recommend it if you haven't had a lot of experience with electronics assembly. The trickiest part was figuring out how to remove the front panel knobs. You have to remove the rubber skirts of the big knobs and the plastic (silver) skirts of the small knobs. Then loosen the set screws. For the tuning knobs in particular, this is informative. It becomes clear what to do if you want to adjust the knobs' drag. (The instructions say something about adjusting the rear skirt, but this is very hard to do if you don't take the knob off first.)
• The take home here is that the Orion is not built with easy servicing in mind. There are no service instructions. It would have been very useful to be able to read how to disassemble the front panel before digging in.
• TT's quality control isn't perfect. The unsoldered hole (J7 pin 8 on board A8) was obvious once I looked in the right place.
• Still, I have committed yet another "act of amateur radio", learned a few things, and the rig is running good as new.

5/14/2004

PSK vs AGC

• I think I saw something interesting when receiving PSK31 signals. Using my MEDIUM or FAST AGC settings (I think these are the factory defaults), I noted some "broadness" on the waterfall display looking at PSK signals. When I switched to my SLOW AGC, which is modified to allow for a positive hang time, the display cleared up. This may be a confirmation of what others were saying -- agressive AGC settings produce audio distortion. The AGC tries to track every burble of noise and signal, which tends to flatten (clip) the real signal. I need to work on this to confirm it and get some numbers.
• Were things so bad in the old days of analog AGC? There is something about a real R-C time constant that is easy on the ears and easy to understand.

5/27/2004

Firmware Upgrade

• I got up my courage and installed version 1.370 today. People had been reporting problems with the serial interface being slower, but so far so good for me. No problem with my PSK control operations. I am keeping the previous version, 1.369, around just in case.
• This came hard on the heels of upgrading (if that's the word) my computer OS from Fedora Core 1 to Fedora Core 2 Linux. Lots of things got upgraded. In particular, we now have Python 2.3.3, which may help some of the programming projects.
• Started up an RFI resource site. I have a particular interest in computer networking (Ethernet) interference and connections to the radio astronomy world. There seems to be a gap when it comes to this kind of information online, especially for hams.

6/11/2004

Another Firmware Upgrade!

• Downloaded and installed version 1.371, which was rapidly put out to fix a number of the bugs introduced by 1.370 and other issues.

1/2/2005 (I've been away being a happy user for a while.)

Power Metering

• For fun I recorded the problem with Orion's power metering system as suggested by a complaint from Frank, I2DMI. See results including Quicktime videos.

[Return to Orion log start]