OK, I’m home now and looked. The FT900 will run when set to FT100 but obviously there are some commands that don’t work like PL freq, VHF/UHF bands, etc. And I find it way easier to use with pre-programmed frequencies in Asterisk/app_rpt…Trying to enter frequencies can be a pain. I have a FT757GXII that I didn’t try, also a TS-480S that I never tried since I wanted to concentrate on the FT900, to me the perfect HF remote radio. Very good tuner in it. I might add that for HF remote I added a syllabic squelch which does not squelch the radio but only wiggles the COS input to app_rpt. The idea being to not have the non-remote radios (repeaters, etc) stay keyed up while using the HF remote. Level squelch is useless there. My remote is not on at the moment, needing to rebuild the interface (the squelch) from a bunch of clip leads to something more orderly. With Yaesu it is pretty easy to look at the CAT command list to see what should or should not work. I’d love to use one of my FT1000D’s but remote control of them is touchy. -W2DB
As I remember it, the 767gx2’s had a auto reply and the rx buffer data would have to be not used and cleared to make it universal. Whereas whenever you querry a radio for data, that is were many unexpected results come from and incompatibility.
So, I just don’t do it in my code.
Without looking deep, just from memory, there should be no reason basic function for the ft1000 would not work. And it should not be buggy at all unless app_rpt is querying the radio at some point.
I wrote a pretty deluxe program for it back in the 90’s and think I still know it well? But it’s in dos.
I also wrote a command interpreter for my cat1000 controller using it’s output in kenwood and ran my ft1000 remotely via external modem. Completely automated. You did not know it was remote location with link radio’s.
I was looking at doing something like that for app_rpt to make a universal interface from existing but I can’t imagine trying to support that. Hard to make newb proof.
But we will have to create a new thread when I get this competed just on VOX for HF and app_rpt.
There has to be a fair method.
I just compared CAT codes and the FT757GXII should work as FT100 and FT900/FT890 can work as FT100 (I know the FT900 does and the 890 is prety much the same. The FT1000 should work. The first gen, the MP, etc, not sure. I need to re-try my FT1000D as a remote. The FT817, however, has totally different CAT commands.
Lunch time at the ranch…73 de W2DB
George, The issue of compatibility actually requires a physical test.
The reason is that I do not know is if app_rpt query’s the radio (or which models were written that way) if at all and once that happens, then you have to look at that part as well. Sending commands or just checking that part is quite easy, but it’s not the whole story to be told.
One would hope not, but as the ic706mkiig that the program was written to does this and makes it completely incompatible with the standard 706 (1st gen) and will lock the software up as the software is looking for a particular data length and type to be returned when queried. But you can set freq and mode and thats about it without locking up.
So, I am asking for known physical tests for compatibility. Understanding that not all features are going to be present in all like model radios within each CAT. But can set freq and mode and switch vfo’s and memories would be a plus.