Monthly Archives: December 2016

Syncal 2000 display project, part 5

Some interesting data.  I placed the old LCD against the zebra pads and realized that there was another item initially displayed, a “PASS” indication.  I took a video of my Arduino LCD as the radio powered up and say this which happened just before that “PASS” indication:

display-pass

Ok, so what does it mean?

E1     LCD chip device select 1
E0     LCD chip device select 0
C9     Mode set:  static, normal, enabled, bias set
F8     RAM bank select:  Bit 0 for both loading and display
F0     Blink mode:  normal, off

Segment mapping is using the standard 7 segment A-G pattern:
00     10 MHz:  blank
00     1 MHz:  blank
CE     100 kHz:  “P”
EE     10 kHz:  “A”
B6     1 kHz:  “S”
B6     100 Hz:  “S”
00      Ch 10:  blank
00      Ch 1:  blank

Well, it does seem not all display writes have 16 bytes, and I’m not sure why some were missing from the first line, perhaps the Arduino is reading them faster than they are coming in, that doesn’t make any sense but in any case the above decoding makes perfect sense.  I also captured a full data display in operation but will save decoding that for a later time, if it proves necessary or helpful.

So there it is!  I’ve established:
1:  The Arduino can read addr 57 I2C data from the Syncal 2000 radio control data bus
2:  The status words being written to the LCD control chips make sense
3:  My reverse engineering of the segments to loaded data make sense

Enough for tonight.  Tomorrow we will go out but when I’m in later I will write some rudimentary code to interpret the data and write the radio frequency to the Arduino LCD display.

Things are moving quickly so I will also take final mechanical measurements and order the OLED display which best fits in the radio display available space.  By the time it arrives I should be far enough along that I will have most original display elements written to variables and can start on creating a visually appealing OLED graphic display.

Peter

 

Syncal 2000 display project, part 4

Spent some time studying the PCF8576 LCD driver chip and decided I would try some code:

  1. Set up the Arduino as a slave receiver at I2C address 57,
  2. Pulse a spare output pin when that address was hit,
  3. Print a “* to the LCD each time the address was hit

I then wired the Arduino to the radio front panel, like this:

img_8939b

Originally I was going to power the Arduino from a nearby computer, but then decided I would just power it from the radio +5 regulated supply.  For those looking carefully you would see I only have three wires in the photo, the black one connected to the ground pin on the Arduino and the two I2C lines (SCL and SDA).  I added the fourth wire after this photo.

Before I did I wanted to double check the +5 supply pin I had previously located and to my dismay the radio was dead.  This happened before and I thought I had fixed it by resoldering the flex cable that goes from the side interconnect board to the front boards.  But the same problem had me tracing what I had learned about the power supplies in the radio and found that pin 40 of that cable was open.  It takes a pull-down from the front panel switch to turn on the main supply and with that open obviously the radio wouldn’t work.  So I put a fine flexible wire jumper in and the radio came right up.

So I turned the radio on, and got four asterisks on the LCD.  What that told me was that the I2C receiver in the Arduino was likely working and that four sequences were detected as being sent.  I changed channel and each time I did that I got another asterisk.

So now I got bold and instead of the asterisk I changed the code to print the number of bytes received, brought it back to my bench, turned it on and got “16.”  I changed radio channel and 16 came up again.  Well, well.  What that seems to indicate is that each time the radio wants to modify the display it writes the entire block of data representing the entire display.  Here is what it looked like:

img_8941

So now I will set the LCD to display the data bytes received in hex.  There’s a hitch in that it’s a little of a pain to buffer and stop the display to read the initial 4 writes.  I am not sure what those 4 are, but I know that one is a LCD test, turning on all segments, and another is to make the regular display.  Perhaps there are a couple of clear displays in there, or there is a control chip initialization then self test then clear then normal?  Who knows, but to some degree it doesn’t matter, all I really want is to read the normal display as I will do self test of the new display myself.

The LCD above is 16 characters by 2 lines.  That will just fit a hexadecimal display of 16 bytes, two characters per byte.

What happens will be the subject of my next post!