Javier Albinarrate - LU8AJA

  • Increase font size
  • Default font size
  • Decrease font size

Yaesu FT-757GX Enhanced CAT Interface

I have a FT-757GX from the 80s, I inherited it from my uncle. I just cannot afford what a newer HF costs and also like this one :) since it is special.

It has a very primitive CAT interface, which can be used only to command the radio. (Change VFOs, Frequency, enable/disable functions). It was the first Yaesu transceiver which had a CAT.
The idea in this article is to build a USB interface which serves as a huge enhancement to completely control the transceiver, as less invasive as possible.
2008-05-13 18:23:03

Unfortunately the current CAT has several disadvantages:
  1. It cannot change the mode (a rotary switch makes this nearly impossible, and I don't intend to replace that with a relay bank)
  2. It cannot report information back (the CAT is unidirectional from PC to TRX)
  3. As a consequence of 2 if you make a change in the front panel of the TRX, it goes completely unnoticed in the PC.

What can be done then?

So, what I did was the following:
  1. I gave a very deep read to the Tech manual and schematics.
  2. I opened the unit, and with the Tech manual, identify all the signals I am interested in:
    • Display unit 5 wires (Int, K1, K2, K3, K4)
    • PO FWD (J27.3)
    • PO REV (J27.1)
    • ALC (bridge near Q54) (or outside via RCA, but I have this one in use by the ATT)
    • AGC (J35.5) (Or outside at the remote connector, but I didn't notice this first)
    • IF Width (I intercepted this one)
    • IF Shift (I intercepted this one)
    • CAT Remote connector (back, 3 wires remote connector)
  • All these can be easily tapped at the connectors, so no PCB soldering was needed.
  • All these signals were taken outside with CAT5 wires. The digital signals were shielded, just in case
  • Decoding the signals

    1. With the display control lines plugged to a scope, and afterwars the PC via LPT, and using DigiTrace software, I started taking samples and writing everything on a TXT file.
    2. With that on hand I easily decoded all the information of the display, so now I am able to read the information back into the PC.
    3. The control signals are basically 13 nibbles of 4 bytes, BCD encoded:
      • The first 4 nibbles seem to be a fixed preamble 0A FF
      • The next nibble is for VFO-A / VFO-B / MR
      • The next nibble is for Clarifier / Split / Lock
      • The next 6 nibbles are the main digits
      • The final nibble is for the Channel memories
    Its nibbles look something like this:
    0A FF VFOX XTRA D1 D2 D3 D4 D5 D6 CH
    The VFOX and XTRA nibbles, are BCD numbers, which at the TMS2370 display driver, get converted to 7 segments.
    The lights you see at the display for VFO-A, etc correspond to segments of a "virtual" 7 number.

    By using DigiTrace (with allowio to access the LPT port in Windows 2000), I was able to setup different information in the TRX display and the give a look to the data channels in DigiTrace. Of course, this can be done in an oscilloscope, as I first did, but it is easier to follow it in DigiTrace.

    Here you have an example of the first sample:

    DigiTrace Sample 1
    Click on the image to open the full screenshot.
    Here you can find a few saved dumps of the captured data which can be opened in DigiTrace YaesuCATsamples.zip

    Bit Stream

    These are the details of the samples on the 5 data channels comming out from the microprocessor into the display unit.
       Shown in display                         Bit stream
    ---------------------------------------- ----------------------------------------------------------------
    -- ---------------------------------------- ----------------------------------------------------------------
    01 8.888.8 1 1010 0000 1111 1111 0001 1111 1111 1000 1000 1000 x0x0 0100 1111
    02 8.888.8 1 1 1010 0000 1111 1111 0001 0001 1111 1000 1000 1000 x0x0 0100 1111
    03 8.888.8 1 1010 0000 1111 1111 1100 1111 1111 1000 1000 1000 x0x0 0100 1111
    04 11.111.1 1 1010 0000 1111 1111 1100 1111 0001 0001 0001 0001 00xx 0100 1111
    05 22.222.2 1 1010 0000 1111 1111 1100 1111 0010 0010 0010 0010 0010 0100 1111
    06 3.333.3 1 1010 0000 1111 1111 1100 1111 1111 0011 0011 0011 001x 0100 1111
    07 12.345.6 1 1010 0000 1111 1111 1100 1111 0001 0010 0011 0100 0xxx 0100 1111
    08 10.000.0 1 1010 0000 1111 1111 1100 1111 0001 0000 0000 0000 00x0 0100 1111
    09 5.678.9 1 1010 0000 1111 1111 1100 1111 1111 0101 0110 0111 x0x0 0100 1111
    10 19.900.0 1 1010 0000 1111 1111 1100 1111 0001 1001 1001 0000 00x0 0100 1111
    11 19.900.0 1 1 1010 0000 1111 1111 1100 1100 0001 1001 1001 0000 00x0 0100 1111
    11 8.888.8 1 1 1010 0000 1111 1111 0001 1100 1111 1000 1000 1000 1000 1000 1111
    12 8.888.8 1 1 1 1010 0000 1111 1111 0001 0000 1111 1000 1000 1000 1000 1000 1111
    13 8.888.8 1 1 1 1 1010 0000 1111 1111 0001 0110 1111 1000 1000 1000 1000 1000 1111
    14 8.888.8 1 1 1 1010 0000 1111 1111 0001 1110 1111 1000 1000 1000 1000 1000 1111
    15 8.888.8 1 1 1010 0000 1111 1111 0001 1101 1111 1000 1000 1000 1000 1000 1111
    16 3.584.0 P 1 1 1010 0000 1111 1111 0010 0001 1111 0011 0101 1000 0100 0000 1110
    17 7.000.0 7 1 1010 0000 1111 1111 0010 1111 1111 0111 0000 0000 0000 0000 0111
    Note: There are a few "x" instead of 0 or 1 in the bitstream, that was because there was a transition shown in DigiTrace, but they were not reals, instead they were a missconfiguration of DigiTrace.
    Channel 1 is called INT in the Tech Manual, and is in the connector J2020 pin 2
    It serves as a clock for transferring the nibbles from the CPU to the display driver.
    The display driver ignores anything it comes until it sees a pulse in the Int line.
    Keep in mind that the MCU also uses these 4 data lines (K1 .. K4), to scan the keyboard in the display unit. It does that by writting the lines PB0 .. PB2 and verifying from what Kn lines come the data.
    If you don't have the manual, the lines for the J2020 connector are:
    • 1 Rst - Reset the display driver
    • 2 Int - Interrupt? Signal the display driver that has data on the K lines
    • 3 K1 Data line
    • 4 K2 Data line
    • 5 K3 Data line
    • 6 K4 Data line
    • 7 PB0
    • 8 PB1
    • 9 PB2
    • 10 500k switch
    • 11 PMS button

    The connector itself can be viewed right in the front, middle of the "local unit" pcb, you will find it easily because it has many wires and goes to the front right at the back of the display.

    WARNING: Do not try to unplug the cable connector from the display unit, as it is SOLDERED & GLUED and you will end up with broken wires. I had to solder them again and it looks awfull now. Unplug it from the local unit pcb.
    Speciffic important nibbles:

    Nibble VFOA / VFOB / MR
    A B M
    0001 1 0 0
    0010 0 0 1
    1100 0 1 0

    Nibble XTRA: Lock / Split / Clarifier
    Lk Sp Cl
    1111 0 0 0
    1100 A 0 1 0
    1101 d 0 1 0
    1110 E/P 0 1 1
    0001 1 1 0 0
    0000 0 1 1 0
    0110 6 1 1 1

    2008-06-01 04:27:31

    Hardware & Firmware

    I chose a PIC18F4550, because it has plenty of ROM and RAM, USB, ADC, SPI, UART and many available pins. And I needed them all!
    The firmware is based on the CDC (Virtual COM port) from Microchip, and getting it to work was effortless.
    I implemented a command line interpreter to control and debug everything.
    Next I implemented the decoding of the display data, using INT2 pin connected to the INT line of the display. With every interrupt, I simple read the 4 bits of the 4 lines, and use that in a state machine. Once I have all the nibbles of the 13 nibbles data burst, I simply take that information as valid. The header as well serves as validation.
    Just to make sure that no false data is read (for example is you power cycle in the middle of a data burst), I configured Timer2, to produce an interrupt after 8 ms, which is longer than the data burst and shorter than the repetition. This acts as a timeout, and if that happens I simply reset the state machine.
    The next issue was the DACs, I need them to control Shift, Width, Drive and Squelch. I gave a long look to my samples box, and found a DAC0854 from National Semiconductors. This is a Quad DAC, 8 bits, serially controlled with SPI.
    Using SPI has a problem with the PIC, an it is that the SDO pin is shared with the RX pin of the UART. In short, even if you don't use the UART to receive data and just to send (which was my case), anyway that pins gets reserved by the UART, thus unavailable for the SPI. I solved this by just disabling the UART and enabling the SPI every time I had to use the SPI. And after that, enabling again the UART. It is not the best solution and you completely loose the capabilities of the RX, but anyway it served my purpuses and as not a big deal in my case.
    If I had had a I2C DAC, then that wouldn't have been a problem, because I2C does not use the SDO pin at all.
    Having done so, the next issue was using a few Op Amps, because the DAC provides only 2.8V and I needed 8V. You cannot just put there a 8V reference (at least the specs are against that), so simple voltage amplifier was used. One for each function I intended to control.
    With all that working, I was able to read and write everything, both digitally and analogically. The next step was to provide the commands to the existing software. The solution to this was...
    MODE0 - All the custom commands I implemented, for control and debug.
    MODE1 - A 5 byte Yaesu FT757GX command passthrough. With that I was able to transparently use the original CAT with MixW. Of course I was unable to read any change done in the transceiver, as that is precisely the limitation of the original CAT.
    MODE2 - A Kenwood command interpreter. These commands are simple ASCII commands, with decimal parameters expressed in ASCII and commands separated by a ";". It is simple and somewhat universal as all the Kenwoods use them and actually several others have used it as a standard. Also there is some documentation about it. So it was the natural choice to implement here. This allowed me to use Ham Radio Deluxe, to completely control and monitor the transceiver.
    After having all that working I connected 6 lines to the FC-1000 Automatic Antenna Tuner, so I could completely control it. I connected GND, Green "Read" Led, Red "Thru" Led, Start button, Reset button, Thru button, and the Antenna current Meter.
    That was a piece of cake.
    The next step was to put a DB25 connector in the transceiver so all the wires could be connected and everything was nice and tidy. I spent a few hours doing the soldering and it was very tricky to attach the connector and push the cables inside the transceiver. There actually isn't much room inside it, and 25 cables lying arround is not easy. Yet... that was done.
    So right now Hadrware design and Firmware are done. I am currently designing a PCB. I haven't done any PCB design in 10 years so it is time to get updated... I already hate Protel99 and Ultiboard... too many things are completely against intuition.
    In a few days I expect to have a PCB done, and I'll just have to prepare a tidy firmware.
    then I will update this website, and add source, schematics, and photos...

    CAT capabilities

    This CAT interface has the following features:
      • Split On/Off
      • Exchange VFO with Memory (Useless in this case, but available because of the native CAT)
      • Write VFO into Memory (Useless in this case, but available because of the native CAT)
      • Lock tuning dial
      • Change VFO A/B
      • Write Memory into VFO
      • Up
      • Down
      • Clarifier On/Off
      • Frequency Set (The most important one!)
      • Exchange between VFO and Memory (Useless in this case, but available because of the native CAT)
      • PTT
      • Read transmit status
      • Read/Write IF filter Width (write with a DAC)
      • Read/Write IF filter Shift (write with a DAC)
      • Read AGC (Signal strength)
      • Read ALC
      • Read Output forward power
      • Read Output reverse power

    FC-1000 Automatic Antenna Tuner

    I also have a FC-1000 Automatic Antenna Tuner. With this, I have as well the following features:

      • Read antenna current
      • Read match status (matched/not matched)
      • Execute antenna tuning (I have to study how to do this because I cannot change the rotary switch to change to CW)

    Update 2008-07-10 - It's alive! It breaths!

    OK, the thing has been working for some time now, I have achieved almost everything I wanted, except for switching modes (It's just gets too invasive to replace that switch), and controlling the drive level. I yet have to calibrate some stuff like the SWR reading, and to replace the long cable (Yep... I have a 1meter DB25 cable with lots of digital and analog signals alltogether and it still works.).

    And finally, I have to polish the firmware and schematics, before posting them here. If you want them just ask. You'll need MPLAB with a fully working C18, because without the procedural abstraction (no available in demo or expired student versions), it just doesn't fit the ROM (yep... It is a LOT of code!).

    Update 2008-08-21 - Some photos

    Here you have some photos taken throughout the project. I haven't posted any schematic, board layout or firmware yet, because it suffered some modifications on the board afterwards which were not yet included on the Eagle files. Also the firmware is a work on progress, I keep adding stuff all the time.

    If you click on the photo you can view it in full size.

    Local Unit Board
    Local Unit Board

    This is the local unit, where the "inteligence" is. Most control, modulation, demodulation, and audio takes place here. Here you will see the microprocessor as well.

    RF Unit Board

    RF Unit Board

    This is the RF unit, lots of transistors, coils, etc. Many weak signals as well.

    Display cable (signals tapped)

    Display Cable

    Here you can see the display lines, which I decode to get the frequency, status, etc. I simply tapped the lines on their way to the connector.

    Protoboard with experimental desgin



    Cables flying everywhere, many ICs, leds to debug and my USB PIC programmer.

    DB 25 Connector

    Lots of lines with both digital and analog information have to come out of the transceiver. Figuring out a way to take them out, which would not cripple the rig, which would allow the rig to work without the CAT board, and were analog and digital could coexist, was one of the most messy things to achieve.

    CAT Board (Components side)

    The board as I currently use it.

    CAT Board (Copper side)


    The copper plane of the board. Note that it has suffered quite several important changes after I designed it, to solve different problems that I initially didn't take into consideration. That is the reason I haven't placed the schematics, these changes were not yet updated in the files.


    Update 2009-05-25 - Simplified version

    I know... I haven't posted yet schematics, PCB, or firmware... The reason is that I modified quite some stuff after the PCB was done because there were some design errors at first (and I never updated the schematics or PCB), and another reason is that the DAC I used, was obsolete and sucks... So I should really redo the design and adapt the firmware to keep all the analog capabilities. However, a few hams have emailed me requesting for information, and after all.. all what they wanted was the digital control capabilities, not the analog stuff, so I made a smaller, simplified version, with PCB and FW, that should be working. It has not been built by anybody else, so if you want to be my beta tester, just email me.



    Also another possible project would be to entirely replace the rig CPU with a new one, and program the CPU control like this project directly in my firmware. However I still don't have the guts to make the replacement, also pin count and available space are real problems. Perhaps in a few months I would go for it.

    Last Updated on Thursday, 29 October 2009 15:13  

    Google Translate

    English French German Italian Portuguese Spanish