This article gathers my previously posted blog entries concerning the FT-817 CAT. The blog entries have now been archived and are not available anymore; however, all info should be present in this article.
1. Initial CAT Tests
I have now been studying the CAT section of the operating manual and I must admit that I am not impressed at all. Only a rather small number of settings can be set and not all of them can be read back again. For example, you can toggle between VFO A and B but you can not read back which one of them is currently the active VFO. Or, you can set the clarifier frequency (RIT) but you can not read it back again.
On the positive side one can mention that the FT-817 can do CAT at both 4800, 9600 and 38400 baud. Good!
I have run through the functions in the ft817.c hamlib backend to get a picture of what works and what doesn’t. Those functions, which do not work can probably be copied from the ft857.c backend, since these two rigs have an almost identical CAT interface.
Here is the list:
- set_func / get_func (LOCK) returns feature not available => FIX
- set_ptt is OK, but get_ptt returns not implemented => FIX
- set_freq / get_freq are OK
- set_mode / get_mode works but does not have CWR and PKTFM => FIX
- set_rit says feature not available => FIX
- get_rit is not possible except that one can return the last set frequency.
- set_vfo / get_vfo: haha… they actually work, but there is no way to tell, which VFO is active; the backend assumes that VFOA is active on startup. => just remove this function? Use rig_op_toggle or whatever it is called, instead.
- set_rptr_shift / get_rptr_shift return feature not available => FIX + | – | simplex
- set_rptr_offs / get_rptr_offs retrurn feature not available => FIX
- get_level says feature not available for anything => FIX should be able to read s-meter and TX power.
- CTCSS, DCS, PSTAT, SQL, etc TBC
I will ask on the hamlib list to see, whether anybody is actively working on the ft817.c backend or I can just go ahead and hack on it.
2. FT-817 into Hamlib
We got a nice discussions going on regarding the the FT-817 backend in hamlib. You can follow the thread here.
So far it seems that people wouldn’t particularly mind if the backend will support the undocumented/dangerous features, as most of the wintendo programs do by default. At least not as long as somebody else plays around with their own radio. Fortunately, Clint KA7OEI, has done a tremendeous work in documenting the hidden features of the FT-817 CAT interface. See his pages here.
One of the major decisions will definetely be whether to have a separate “dangereous” backend or just use the original backend and have a set_conf parameter to enable the undocumented features. Hmm… Both methods have their pros and cons.
3. More Undocumented CAT Commands
I discovered yet another undocumented CAT feature, which I don’t recall to have seen on any of the other sites…
I was actually debugging grig because it seemed to display the wrong mode when the rig was in CW, CWR and RTTY modes. I was digging deep inside the hamlib code using the source browser of ddd (gdb interface) when I came to the conclusion that it was the FT-857 backend, which returned RIG_MODE_NONE for the above mentioned modes. When grig receives RIG_MODE_NONE, it will simply select the first mode in the list, which happens to be RIG_MODE_AM. I switched to rigtl where I noticed that the backend was receiving wrong data from the radio:
CW: xx xx xx xx 82 instead of xx xx xx xx 02
CWR: xx xx xx xx 83 instead of xx xx xx xx 03
RTTY: xx xx xx xx 8A instead of xx xx xx xx 0A
Here, the xx is the frequency data, which was 100% correct, so I was quite sure that it was not due to transmission errors. Also, the set_mode command worked fine. I was begining to worry… Is my radio already messed up before I actually got into experimenting with undocumented CAT commands? I was also quite convinced that the FT-857 backend returned correct values, while I was playing with it sunday afternoon. I was very confused.
I quickly switched to wintendo in order to try the demo version of the program, which accompanied the CAT interface cable. It worked fine, although I wasn’t sure that it was using the official/documented CAT commands; it had too many controls in the main window, which are impossible to access using the modest set of commands described in the operating manual.
Anyway, I switched back to Linux and tried rigctl again. Both the FT-857 and FT-817 backends. At this point, I found my notes from testing the FT-817 backend where it said that “both CW and CWR return CW”. Appearantly, the backend *did* work a few days ago and it wasn’t my memory, which has been failing – I’m not that old yet. So, what the hell was going on here???
I decided to try the other bands as well and this excercise had a very surprising result: On the 160-30 meter bands the rig was returning 0x82, while on all the other bands it was returning the correct value 0x02. Hmmm… I began to suspect that it had something to do with those one or two “extra bands” available for tuning the rig outside the ham bands. Therefore, I did the following:
- Select the 20m band where the returned value was OK.
- Set the frequency using rigctl to one of the lower bands.
- Do the above exercise for all the lower bands.
After that the rig was returning the correct value on all bands. Pheww… It didn’t really answered the question but, at least, my rig was working properly again and I could continue to work on important stuff.
Then, a few minutes later while I was listening on 40m CW, the damn thing began to return 0x82 again… I was getting quite fed up with it and so I did a detailed analysis of every single step that I have taken since the last time it returned the correct value. There was only one thing that has changed the state of the rig: I turned ON the narrow CW filter. I quickly switched it OFF, executed the get_mode command and voilà: 0x02. I turned the filter ON again: 0x82. The same was happening in CWR and RTTY modes. Go figure…
My feelings concerning this discovery are rather mixed. On one hand, I think it’s great that one is able to detect whether the filter is ON or OFF using nothing but the documented CAT commands. On the other hand, hidden features like this make any driver carefully written by the book to be buggy, since they don’t know that the rig will return an undocumented value when the narrow filter is ON. Come on YAESU-folk… This is a great little radio. I would be willing to give it 4 out of 5 stars if it wouldn’t be for this crappy “documented CAT interface” (oh yeah… and the tons of clicking relays).
As you know, one answer raises several new questions. In this case:
- Is it the same in SSB modes as well? Will the rig return 0x80 and 0x81?
- How about the other radios in the series, FT-857 and FT-897?
- Can we also use 0x82, 0x83 and 0x8A to set mode and filter ON?
If you have the answers for any of these question, please let me know!
4. Mail to YAESU
I have sent an inquiry to YAESU in order to have the previously mentioned discovery concerning the undocumented return values confirmed. Here is the message:
—
From: Alexandru Csete (email)
To: Tech Support
Subj: CAT interface
Hello,
I am the happy owner of a newly acquired FT-817ND. It has the optional 500Hz CW filter installed. Let me briefly say that this radio is an impressive piece of engineering.
I am currently working on some CAT software for linux and I noticed that my FT-817ND returnes some undocumented values when reading the frequency and mode status with the optional CW filter turned ON. It returns:
CW: xx xx xx xx 82 instead of xx xx xx xx 02
CWR: xx xx xx xx 83 instead of xx xx xx xx 03
RTTY: xx xx xx xx 8A instead of xx xx xx xx 0A
where the ‘xx’ are frequency data and are always 100% correct. When the CW filter is turned OFF, the radio returns the correct values 02, 03 and 0A. The operating manual does not mention the values 82, 83 and 8A.
Can you please confirm whether this is the correct behaviour or there is something wrong with my radio? If this is the correct behaviour, can you tell me whether something similar happens if the optional SSB filter is installed? Furthermore, I would like to know, whether the FT-857, which is very similar to the 817, behaves the same way?
Thank you in advance.
Kind regards
Alexandru Csete
Denmark
—
Let’s hope they give a positive feedback very soon.
5. No Response from YAESU
Ten days have passed since I sent my email to YAESU and still no answer. I recall a confirmation text saying something about answer within 48 hours… Well…
In the meantime I have finished the hamlib backend by applying Tomi’s imprivements from the FT-857 backend with some minor modifications and additions (vfo toggle, powerstat, …). This makes the FT-817 backend rather complete, at least when one only considers the documented command set.
Next, I will take a backup of the calibration settings and start playing with the undocumented commands.