This one will be short as I don’t have a lot of time and there isn’t so so much to report. I have been able to identify the EPROM checksum routine and was able to trace where in the code the frequency entry code checks the entered frequency for correct range.
Thus, I was able to patch the bounds checking routine as well as the checksum to get this when entering 28 MHz:
Looks good as a first step!
Unfortunately, after several seconds I get this:
So there is a second bounds checking. Tomorrow I will try and trap on that message to find where that code is and do another patch.
At least I have verified that I found the data entry bounds checking code and know how to patch the checksum to not produce a BITE error.
I ended up with an interesting little VHF low band transceiver made by Tadiran:
The frequency range is 30.000 to 87.975 MHz, FM wide or narrow band.
The radio seems to operate as intended.
But it’s boring to have it only cover the 6 meter band. I wonder if it can be made to go down into the 10 meter band? The first step would be to change the lower frequency limit in firmware from 30 to 28 MHz.
So I opened it up and looked for the control processor. Found this:
Processor is a 80C188EB. Like the PRC-2200 made by Tadiran, the EPROM chip only has the four corner pins soldered with the rest in mini sockets.
I removed the EPROM and read it on a programmer. Then I started analyzing using Ghidra. One of the first things I look for are ASCII messages. This can sometimes lead to hidden features. I did find a lot of strings, but very strangely there were long messages which looked like they were for some kind of debugging work.
Then going through the startup code I saw that the area where these messages were was in an area of ROM that wasn’t mapped as active! And there were no ASCII messages, like are seen in normal operation, anywhere in the EPROM! That’s when it dawned on me there may be another processor in this radio.
Sure enough, on another board I found this:
This one is a NSC800D, which is like a Z80. Same deal with the EPROM pins so I removed it and read it on a programmer. 27C512 part.
Loading into Ghidra showed all the messages you would see in normal radio operation so this is the correct processor to start my hacking with.
By the way, I found this in the code:
I was able to locate Michael Rapoport but he has not responded to my inquiries. I wanted to tell him I found his little comment.
Even with Ghidra it is not easy to reverse engineer code so I like to trace code execution using a logic analyzer. I use a huge, noisy and heavy HP 16702B. It is an old beast but quite capable and was a steal at around $200 for analyzer and a bunch of cards and cables.
Hooking up to the microprocessor bus can be a challenge and I have worked out a quick hack which not only solves that but helps later on when I want to try different patches to the EPROM. I make an extender for the EPROM itself, like this:
I use a ZIF socket so it is easy to put different chips in and 0.025″ headers wired to each pin for connecting the logic analyzer. Here’s how it looks once connected to the analyzer pods:
Now I can watch as code is executed. The analyzer setup looks like this:
What I am doing is looking at the EPROM address and data lines and triggering each time the chip select goes inactive after being asserted. This shows me every EPROM read, whether code or data.
MY next step was to set trigger on seeing address 0000 as this is the processor reset vector. This will allow me to quickly find the EPROM checksum test and I will need to understand that before making any patches.
After that I found the address of the INV FREQ message which is displayed when I try to enter 28.0000 MHz. I set the analyzer to set the middle of its 2 million address read memory on the trigger of seeing address C15E which is the message. Note that the analyzer needs to be armed for capture AFTER the radio boot-up as otherwise the analyzer will trigger on the EPROM checksum routine scanning through.
Both captures were made and a quick look shows they make sense and are good.
The second trace is extremely useful in that it tells me many things:
I now know where the routine to display messages is and how it works. This tells me how the display is addresses which helps fill out the hardware addressing puzzle.
I can see how the message display routine is called especially the argument which is the message pointer. I can now backtrack to every place which calls this routine and by looking at the messages, I can get a good idea of what each section of code does.
In this case, I can backtrack to the keypad entry routine and see how that is addressed. This is helpful to further solve the hardware interface puzzle and if I ever want to modify the keypad routine.
And finally, this will lead me to where the 28.000 I entered was compared to the lower limit 0f 30.000 and rejected. Now it will be easy to change.
All for part 1 of this adventure. Analysis follows.
Update: If you look carefully you will notice I was disassembling the backplane wiring. This was actually being done on a separate, scrapped unit. I still have the fully intact IMU in the photos.
The reason I was removing wires is because there is virtually no information or documentation available for this unit. The Technical Orders (manuals) are not released to the public. Since the wiring is extremely dense and in layers, the only way for me to trace it out and reverse engineer this unit is to carefully remove each wire and mark what it connects to.
You may consider this insane and hopeless, but at this point I am able to power up the unit, get the gyros to spin, the platform to erect and respond to movement and see data output. I found a photo of the control head and have identified (sort of) how it interacts with the unit at a high level. Next I will start the ALIGN process where the unit carefully measures accelerations from the stabilized platform to determine the unit orientation in reference to true north. Apparently this can take 15 minutes and I will monitor the completion signal “Ready to Nav”.
The data buses will take some work to figure out as the unit does not just spit out all the internal data, you have to request it. There are no microprocessors in this thing, it is just a large collection of state machines with logic that resembles the backplane wiring – spaghetti. I do see 3 phase roll and pitch synchro outputs and can even drive a small 26 volt synchro and have it move when I pick the IMU up and move it about.
Powering this thing was a little bit of a challenge. It needs 120 volts 400 Hz 3 phase power. I tried, you can’t get away (at least not easily) running it on single phase 400 Hz even though the gyros and all electronics are run from a switching power supply that runs from 32 volts DC rectified from the 3 phase as there are some reference signals based on the phases.
I have an old 750 VA 3 phase inverter. Hooked it up with a 30 amp 28 volt DC supply and it promptly fried one of the power bridges. Big germanium transistors! I eventually troubleshot it to the startup surge taking enough current to collapse the DC supply and the low input voltage to the inverter was what killed it. Now I have two big supplies feeding into the inverter and it runs well.
To start the IMU, first I turn on the 3 phase power. Then I momentarily apply 28 volts DC to a pin and the internal power relays pull in and latch. There is an input line which must be grounded to enable gyro spin (this seems to be the standby/operate line from the control head). After about 45-60 seconds the gyros stabilize and the platform is enabled and erects itself.
I have identified the ALIGN input which causes a precision leveling of the platform and precise measurement to determine earth’s rotation and hence true north. That will be next and I watch for a signal which indicates completion.
By the way, the mating connectors were a challenge to find as they are a discontinued size and contact configuration. I finally found someone who could identify them and supply them at surplus prices (both normal and A rotation, too!).
The PRC-104 is an interesting portable radio. Some complain it is hard to repair, but fortunately they are pretty reliable if they are working, and extremely rugged.
There are two battery boxes, a small one which you can put your own cells or small pack into, and the larger pack which takes the standard BB-390 batteries. It is designed with a charger circuit for those packs with an external connector.
The problem is, that while the case will take modern BB-2590 batteries, those have a higher fully charged voltage than the radio can work with and this could damage the RT power supply.
I decided to use a cheap Chinese buck-boost DC-DC converter to solve this problem and another one, the lack of ability to run the 104 from a 12 volt supply. Here I removed the original (useless) BB-390 charger and have the DC-DC mounted on a small piece of fiberglass.
This is a difficult install. This DC-DC is just a tad too long to fit and the case needs some modification internally. I think if you just decide to drill more holes in the aluminum plate you could dispense with the intermediate fiberglass board and it would work out better.
The switch has two functions: one, to select batteries or external power as the source, and two, to disconnect the DC-DC from the batteries to eliminate the 32 mA idle drain when not using the set. I set the DC-DC output to 26.0 volts. The output is steady from 8 to 35 volts (the LTC3760 chip is rated for a max of 36 volts).
Here it is all finished:
I wired a cigarette lighter plug to the external connector. It works very well, here it is running on 13.6 volts:
The drain is 422 mA with the RT in receive.
Here is the display during this test:
During transmit into a dummy load wattmeter the voice peaks look good at close to 20 Watts and the current (using the larger power supply below the digital one above due to current requirements) the peaks are showing at about 4.5 amps on the analog meter.
I tried the radio in my car and it works great.
The advantage of this DC-DC is that it is under $12 shipped and based on a great LTC part.
I checked for RFI and found I could hear weak birdies with the antenna terminated that varied with DC input voltage. However, the levels are low enough that as soon as an antenna is connected there is no way they could be heard.
Sadly, I am forced to shut off comments on my postings. Even with spam filtering add-ons I am getting 5-8 spam comments every day and I’m tired of having to delete them.
You’ve seen my requests for information on the GRC-215 man pack recently.
The GRC-215 is an unusual set. It seems like almost an afterthought that it was made into a portable set. I’ve been interested but several have told me that it is built of potted modules and unrepairable so I’ve stayed away.
This turns out to not be true.
In any case, I had the opportunity to acquire one of these sets for a reasonable price, except it had a problem which seems to be an ATU tune failure. Photos of the inside showed that the guts were not potted but rather conventional design so I went for it.
I found that detailed service information is EXTREMELY hard to find, most notably schematics. A kind soul has sent me the module level manuals, which curiously have PCB component location diagrams and parts lists, but no schematics! There is a general module wiring diagram with labelled signals included.
***
The fault is indeed that the ATU does not tune, but oddly enough, the tuner tries even when it’s not supposed to, when no whip is attached.
I made up a 25 pin D connector extension cable to operate the R/E with the ECCM control head detached.
After a little reading of the very basic qualitative circuit descriptions I understand that there is a “50 ohm” signal which comes from the ECCM unit to tell the switching logic to send the PA output to the BNC connector and disable the ATU. As the ATU always seems to run, I took a look at this signal and it indeed is always indicating to (falsely) use the tuner. That’s a problem.
But where does this signal come from? There is a switch in the whip connection which activates when a whip is attached, but all that seems to do is make the RF path to the whip. There is a capacitor to a coax back to switching relays but no sense connection. How does the ECCM know whether a whip is connected or not? There is no explanation of how this works that I can find in the manuals, and it definitely isn’t working.
Well, what about if I just attach a whip? Tried that, same ATU fail problem.
Here’s a weirdness: not knowing how the radio works I placed a wattmeter and dummy load on the BNC connection. During the tune cycle the power goes up to about a watt before ending in failure. Why would the tuner affect the 50 ohm output? And what’s with the 1 watt?
I am suspecting a PA problem now. In low power mode there should be 5 watts out. Was the PA damaged by a problem in the antenna switching leading to running into an open? That’s pure conjecture. But very low tune power could definitely lead to faults being registered and tune failure.
So I decided to see what happened if I changed that 50 ohm signal. Since I have the ECCM on an extender cable I disconnected that signal and grounded it. First I did it the wrong way and nothing changed (duh) but I realized my stupid mistake and grounded the correct side and sure enouth the tuner doesn’t run and I get the full 1 watt on the BNC right away.
So the handset is specially wired and called a H-356. Modifying a H-250 is tough as there aren’t enough wires in the cord but I found it is possible to modify a H-350 handset as used in those digital field phones.
Looking on a scope there is a good SSB modulation, but only 1 watt. Going to high power gets to 5 watts. Should be 25.
So, one of the following:
1) PA problem
2) drive problem
3) control problem
4) harmonic filter problem
I tried on a bunch of different frequencies and they all behave the same so I’m thinking it’s not #4 but I will still check.
Now I need to open the unit up enough to get some test points temporarily brought out when I put it together and look at maybe the ALC first, then undo and extend the little coax in and out connectors to the PA itself and measure those. That will be next!
I have some catching up to do in terms of the full story here so this time I’ll start with the bottom line, a fully working radio.
The KY-67 was designed as a super heavy duty 30-76 MHz FM military pack set with built in encryption. Since encryption devices are not allowed to be surplussed out, the crypto boards have been removed from all of these radios which made it out. Unfortunately, for a number of reasons hardware and software, the radio will not operate as a regular radio without those cards.
I read out the microprocessor code and after disassembly was able to patch the code to allow it to run without the crypto cards present. Removal of a FET allowed the processor to run with missing hardware.
The last part was that both receive and transmit audio go through the missing cards. To solve that I had to build equivalent circuitry. Here is a picture of the top of the card I made:
Here is the bottom:
And here it is in the radio:
With this done (and a few jumpers on the backplane) the radio operates as it should. Volume, squelch and squelch disable all work as intended. Those functions and both transmit and receive audio amps and filtering are on the new card.
Oh, and one more fun thing: another very smart engineer joined me later on in this project (very pleased to meet an engineer of that caliber!) and located in the code where it could be patched to extend the low frequency limit from 30 to 28 MHz. So now the radio will do FM on 10 meters as well as 6!
I guess time to post here rather than just on the Yahoo milpack group. This way it’s easier to find all the updates in one spot and in order.
The KY-67 is a very rugged VHF backpack transceiver covering the usual 30-88 MHz and made in the eighties. My impression was that it was made for an amphibious vehicle which experienced program delays so by the time the program went into production the radio’s technology and features were dated and not many were produced.
The unique part for the time was that the radio had integral digital encryption. Of course what this means is that for all radios which were surplussed the encryption boards had to be removed so every one of these anyone outside the military has seen is missing all those cards. While I commend the surplus disposition people for not just grinding the radio up to scrap, the removal of those boards renders the radio inoperational. Completely dead. Some have tried, but no word of anyone ever succeeding. Of course, the funny part is that I will likely only use this radio several times a year, and probably all on 51.0 MHz. But it looks really cool and rugged, like you could run over it with a truck. So I’m going to try and get it to run.
A kind soul offered me one with mounting base, unused, for the cost of shipping. Let the games begin, it against me.
Next post I’ll add some photos.
Here’s a summary of my progress to date:
Two battery connectors for two 2590 type batteries. One runs the encryption boards, the other the radio itself.
The CPU board operates the front panel display. I was worried it might be controlled by the missing cards. CPU is a NSC800, an extended temperature range Z80, Firmware was on a socketed (yay!) 27C256. Hmm, only 64k instructions at most, doable..
Read it out, ran some Z80 disassembler I found on the web, got this:
Look at the .asm file, that’s the one I’m annotating as I go.
Oh, one more thing in the hardware, you have to remove the little gold case FET on the CPU card near pin 72 of the connector. This will allow the processor to run when the missing cards are out.
Once running, the displays blinks 6 6 6 five times and shuts off. After a lot of tracing, I’ve identified the display writing routine, error reporting, and the entire extensive POST routine.
Also discovered some funky backup battery scheme which I don’t understand at all quite yet.
Found the routing where the 6 6 6 is displayed and bypassed the call to that subroutine. Now the radio gives a 1 09 indication, or sometimes a 1 07 one. I bet this means some other CMOS signal is floating coming from the missing cards.
Probably going to wander around the software and try and figure out more stuff.
I wrapped up the radio for the time being. It’s not internally 100% the way I’d like it but I need some time to work with it before I consider the firmware truly final.
A few notes:
1) I traced out the radio LCD backlight wiring. There are four LEDs in series with the high side connected to 10 volts and the low going through a transistor and resistor. I had previously found that 1k in series was nice for general LCD lighting and full 5 volts for high brightness. I tied the new display positive backlight to +5 and the negative to the collector of that transistor. I put a 1k resistor across the transistor and shorted out the 220 ohm resistor. Here is what that mod looks like:
Yes, that’s a really tiny resistor I used!
2) The flex cable to the front processor board is not very robust. Earlier I lost the ability to turn the radio on and found that the pin 40 to pin 40 connection was lost in the cable. Now the 3 bars started going intermittent and I traced it to the loss of connection in pin 39. Here is my fix:
About the only choice seeing as the part is unobtainium. But it works great.
3) The new LCD display annoyingly requires a negative ~1.66 volts for bias to work. More annoyingly there is no negative supply I could find in the radio so I had to make a small 555 based charge pump. I would prefer to use a tiny SO-8 part to do this, one meant for the purpose, but that will have to wait until I have enough to order from Digikey to have a reasonable size order. In the meanwhile I stuffed it here:
Left of that are three precision resistors which make the voltage divider for the voltage display I added. When I go back in I will tack glue three SM resistors on the other side to eliminate this eyesore. Here is where the sense wire ends up connecting to the CPU board pin 39:
I didn’t take a photo of it but have the 6 wires from the Arduino going to a tiny connector which is between the boards. I can connect my code development computer to it if I want to update the code without having to disassemble the whole thing.
I took a video but it is too large for this site so I placed it on my site at the following address:
Note that when the display goes to the bright setting the iPhone camera can’t handle it and washes out. It’s pretty bright, gotta love these new high efficiency LEDs!
I’m done with the software for now. It was a big deal to get the radio programming mode to work right on my display but I’m through it.
I used my digital scope to trigger on I2C bus activity and captured the data stream the radio sent to the original display chips. I then scrolled through the data and clock and wrote down the bit values. I was able to determine that the way a digit was made to blink was to load a second page of segment on/off data and have the LCD control chips alternate between those two pages. The data would be identical except for the flashing digit which would be blank on one of those pages. Hence, it would flash.
The problem was that right after the second page data started being sent, the bus showed a conflict and the data wouldn’t get received or acknowledged. After finding nothing regarding this on the net, I considered all that could go wrong and realized the architecture of my code was wrong.
What I had been doing was to have nothing happen in the Arduino main loop and have all activity triggered when I2C data was received. This included the LCD chip device emulator and command decoder as well as processing all the data and writing to the new display. In normal operation, the data packet to the LCD chips was relatively infrequent, but the problem was that when put into programming mode, the radio sends two packets right next to each other, one to load each segment data page. Because my code remained in the receiveEvent interrupt service routine (ISR) so long it blocked reception of the second data packet.
What I did was restructure my code. I made the ISR as short as possible and I moved all processing and display code to the main program loop. Since I had everything stored in global variables this wasn’t terribly difficult. Now I have a continuously running loop which looks at stored raw display data and then processes and displays it and a completely separate asynchronous event which updates the data as it is received. I don’t need any lockout semaphores as it is only display data and the display is itself relatively slow responding.
Interestingly, this change fixed some odd and infrequent display bugs so now it is very solid. I did notice that the text messages (Tune, Pass, Good, etc.) were flickering so I added code to only write them once until the data changes and that resolved that issue.
What I do with the frequency digit data is to load to different locations in an array and if the radio is in program mode AND the digit data is different between the two areas (for each digit) I then set a bit indicating to the display routine to invert the digit. Here is what it ended up looking like:
So now the radio frequency programming works like it should. All other messages and modes seem to work as well so now it’s time to move on towards wrapping up the last electrical and mechanical integration tasks.
I mentioned previously that the display brightness was very high, too high for most operation. The backlight LEDs are designed to be fed directly from 5 volts and there is a resistor on the LCD PCB. This is a transmissive display so you can’t just turn off the backlight as the display is nearly impossible to read. I experimented with adding series resistors and found that a 1k one gives a nice pleasant readable display in normal indoor light so there’s my choice. I will tie into the radio light switch so when that is turned on the display will go to full brightness which is necessary in bright outdoor sunlight conditions.
The LCD needs about -1.66 volts for contrast. I tried building a small diode charge pump running from the Arduino pin I set up for the LCD clock but there’s not enough drive so I’m going to use a charge pump chip which runs from the 5 volt supply directly. I have to order this as I don’t have any so will wait until I need some more parts from Digikey as I don’t want to pay $6 shipping for a 40 cent part. This will also give me a more regulated output.
Next I’m going to work on the mechanical mounting of the Arduino to the back of the LCD and getting that combo into the radio. I know the LCD itself fits beautifully but now I need to get that little Arduino in there nicely as well. I won’t be able to fully button it up until I get the charge pump IC but might jury-rig in a 7555 driven charge pump for the time being.
Once I have it all together I’ll write up the final installment of this and include the final wiring diagrams and mechanical photos.
The code can be found at: https://github.com/kb2vtl/Syncal_2000
P.S., I am still thinking about adding battery voltage. I also found out that the I2C addressing uses hardware on the Arduino Atmega328 processor so it will be extremely difficult to get it to monitor for mode and other data at different I2C bus addresses.
