Syncal 2000 display project, part 14

Mystery solved.

One of the oddities of the Racal transceiver is how the front panel switches work.  There is a PCB right behind the front panel and it has a number of PCB mounted selector switches which take a flat blade to turn them.  The panel itself has shafts which go to the knobs and they have this flat blade which mates with the switches.  This allows for the shafts to be environmentally sealed and not require it of each individual switch.  Not a bad idea, but there is a hitch in that it is possible to have the tab 180 degrees off and then the switch will use positions it wasn’t intended to and this can cause mal-operation.

When I put the panel back together I thought this was what was happening with the Prog switch.  When I rotated it to the program position, the display went dark, voltages messed up, all sorts of grief.   So I disassembled and discovered, based on marks I had made, that it wasn’t rotated 180.  Uh-oh, something’s wrong with the radio.

Well, I don’t have the schematics, they seem impossible to get, so I’m kind of on my own so I started investigating further.  The radio also had other faults.  Receive had a loud pulsating noise and tuning, even into a dummy load, always resulted in a “Fail” indication.  Looked serious.

The first thing I did was to look at the 5 volts going to the display.  Well, it went down to 4.3 when I went into program mode.  Hmmm, how can that be?  Did I have a pinched wire?  So I removed the display and put it on the bench, no change.  Then I hooked the Arduino and display to a separate power supply.  That will fix it, right?  Wrong!  But how can that possibly be?  Well, it turns out that what I thought was the ground (Vss) connection wasn’t!  It was some sort of signal!  It was just low most of the time.  Connecting to actual chassis ground (for now) solved that problem and resolved ALL of the associated problems.  Now I can get into program mode.

The first thing I did was to hook the scope to the I2C bus.  I wanted to see if the CPU was “manually” toggling the blinking LCD segments.  It’s not, there’s no I2C bus activity during blinking.  This means the blinking is done by the LCD chips.  Oh, that’s a pain.  Why?  Because the way that works is to load another entire page of segment bits and set the LCD chip to rapidly toggle between pages.  Why is this a pain?  because that means I now have to look for the CPU storing another page of segment data and determine which ones are different and use that to identify which segment is the blinking one.  This will take some work, although I’m sure I have enough code space as so far I’m only using 28% of what’s available.

When I get into program mode some of the display data is wrong, such as channel number, so I think I have a problem in my LCD chip emulation code which I’ll have to investigate.  Well, at least the radio can be programmed now and I get a “Good” on tune.

More tomorrow.