The next step, going to a graphics display, is a big one.  There are several reasons for this:

1. The display interface is 8 bit parallel with a number of control lines
2. The display requires a 2 kHz clock signal
3. The display controller chips are complicated to program
4. I will be sending pixel data to the display instead of ASCII characters

So this is taking me some time.  I found some other Arduino projects on the web where this particular type of display is used, but they are rather complicated and since they are not for this exact Arduino processor, they would require a number of changes.  They are also for a C++ compiler and I’m using the very simple plain C Arduino IDE.  So much for code re-usability, it looks like I’m going to have to write my own.

In the meanwhile, some hardware notes.  My measurements worked out well and the displays I ordered fit nicely.  Here is a photo of the front of the panel with the LCD held in with my fingers.  Note I still have the blue protective film on the display.

Here it is from the back:

It fits nicely!

Note on the paper behind some data.  I was playing with triggering on the I2C bus when changing mode switch positions.  With the digital scope I could read both clock and data and see what happened.  I think I have a real shot at picking up mode info from the bus and displaying it.  But that’s for later.

I’m using the Arduino Uno for development but will use the Nano for the final installation.  The Nano is VERY small!  Here is a photo of the display next to the Nano.

How cool is that?

Anyhow, here I am beginning to wire it up.  Those 50 mil pitch pins on the display are small to solder, and all 20 are used.

Back to the software.  The display needs a 2 kHz clock and in the example I found on GitHub (from the guy behind Vanyamba Electronics) an interrupt is used to toggle an output pin based on a timer which fires every 500 microseconds.  My experience is that these clock speed requirements are frequently not very demanding and I wondered what frequency the built in PWM ran at.  It turns out it defaults to 1 kHz and can be changed.  So my simpler solution will be to set a PWM output to 50% and get the frequency as close to 2 kHz as I can.  Voila! No dealing with interrupt coding or latency effects on the I2C slave code.  This will be the first thing I test and bring up in my step-by-step march to getting the display to work.  I can easily check that with the scope.

Probably next I will write some basic routines to send and receive data from the display.  I’ll need this of course for writing pixels, but also for reading and writing commands, setting position, etc.  The way I imagine this working is to, in sequence, toggle microprocessor output pins in the right sequence, like set CS, E, then present data to the 8 outputs, then the WR pin to write it out.  Something like that.  The data sheet for the SBN1661 chips in the display give some program sequences.  I’ll start with that and if I run into trouble see what Vanyanba did.  If I really run into trouble I’ll take out the logic analyzer to make sure I’m outputting what I think I am.  Once I can initialize the display and write pixels to it the rest will be pretty easy as I found a whole library of LCD fonts:

https://github.com/basti79/LCD-fonts

I’ll give an update when I have a little progress in coding.

This is only a slight update.

The mechanical space in the front panel of the radio permit only a limited number of different models of display.  The Vishay-Dale unit I want to use which fits nicely is very new, so new that it is nearly impossible to find.  I am getting one via a connection, but also found a LCD which will fit as well.  The reason I am so constrained is that I want a large display area yet there isn’t much room around that area in the front casting.

The LCD I want to try is a Newhaven Display NHD-12232KZ-NSW-BBW-P.  I have a couple on order from Digikey.  At this point I will write the driver code to handle both types of display and show pictures of both the older technology LCD and how it looks done in the new OLED technology.

As for fonts, I found a number of ones available in open source, in different XY pixel sizes, so I will be able to have the frequency in a large font and the channel and status info in a smaller font.  I’m still playing with design ideas for layout.

Both displays aren’t expected until sometime next week, and I might be too busy the end of next week going into the weekend to get to further development.  But after that, with all the holidays and days off I will have plenty of time.

I still want to set up an Arduino as a I2C bus monitor to dump all bus transactions to the PC.  This will require rewriting the wire.h library functions to operate in either promiscuous mode or with selectable filtering while not sending the acknowledge signal back to the master.  I’d also modify it to print the bus address before each transaction data.  Why do this?  Because I’d like to be able to display radio mode and this can be read out from one of the bus expansion chips which the mode switch connects to.  Who knows what else I can find.  I could also display when the radio is in a ham band (as a reminder) and what class of license segment as well.  Stuff like that.

I did a few code tweaks:

1. Instead of calling it Channel 0, I had the display say “VFO” because that’s what it really is
2. Added power indication to display
3. Added the left and right arrows for tuning indication
4. Cleared display between modes
5. Most importantly, fixed the bug where it wouldn’t update.

The problem with not updating was due to my not reading in all the bytes on a receive.  One of those typical n/n-1 programming errors.  At this point I’m pretty much going to put this aside until I get the desired display.  I’ve decided to use a Vishay-Dale O128O032ALPP3N0000 OLED unit.  It’s 128×32 pixels and I’m going to need to find some decent font to use for it.  I’ve heard those can be found on the net.  I’d like the frequency to be reasonably large and the status etc can be smaller and off to the sides.  This isn’t a perfect display as it’s smaller than the window, but it’s a standard part and the larger ones won’t fit in the radio mechanically.  This will change as a lot more are being made as the OLED ones replace the older LCD types.

Interestingly, the display doesn’t show operating mode.  I’m investigating whether I can intercept the switch status from the I2C bus and then display it.

Alright, spent a bunch of hours coding.  As typical of coding, some things went easy, some were worthy of tearing my hair out over.  I finished and tested the LCD driver chip emulation including indexing and loading actual display data to an array.  I also wrote and debugged the subroutine to recognize both number and letter data from the individual 7 segment signals and turn it back into numbers and letters (some is not possible, such as “5” vs “S”).

I finally had enough for the day and called it quits.  I am now able to read out and display the radio frequency and channel like this:

The bottom line is some diagnostic info I no longer need.  This is a big deal!  With all the command and data properly read out, most of the hard part is already behind me now.

One weird thing though, and I have no idea what’s up.  Previous to today, the data receive routine would update on each packet received.  But now, it only runs once.  It runs properly, but only once!  I tried commenting out large sections of code to no avail.  I may have to post my code to Stack Exchange and ask if anyone has encountered this before or has any hints.  I don’t mind posting it since I will open source it to GitHub when I’m done anyway.  I don’t think my rusty coding will be too embarrassing, ha ha.

While attempting to debug this problem I put statements which turned on and off an output pin so I could observe it on a scope.  This also allowed me to time certain sections of code, and I was curious about how fast the C code ran.  It turns out, respectably fast: my command decoder and data retriever, dozens and dozens of instructions, takes a grand total of 62 microseconds to execute.  As for size, with the libraries my code right now stands at about 15% of the available space on the chip.  Not too bad, these parts have pretty decent capability both in speed and size of program you can fit into them.

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:

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

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:

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:

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!

One of the steps I described earlier was to map the LCD segments to the LCD driver chip pins and then to the internal memory of those chips.  This is because when I receive that data in my microprocessor I will have to be able to interpret it.

I first examined the LCD display itself and carefully followed each pin to a segment.  I ended up with this sketch:

Then I used a special set of HP probes on the DMM in continuity mode.  The probes are super tiny and have spring probe tips like used for PCB test probing.  I followed each LCD pin back to the driver chips.  That led to this:

1S and 2S represent the two LCD driver chips.  It turns out 2 is the low order and 1 is the high order addressed chip but that doesn’t matter.  The S number is the segment output number of the chips.  The 7 segment below has the standard segment labeling.  Still looks confusing?  Patience…  Now I put the segment outputs in order and get:

LCD Driver 0 segment outputs
S0      10 MHz A
S1      10 MHz B
S2      10 MHz C
S3      10 MHz D
S4      10 MHz E
S5      10 MHz F
S6      10 MHz G
S7      Decimal point
S8      1 MHz A
S9      1 MHz B
S10      1 MHz C
S11     1 MHz D
S12      1 MHz E
S13      1 MHz F
S14      1 MHz G
S15      PROG
S16      100 kHz A
S17      100 kHz B
S18      100 kHz C
S19      100 kHz D
S20      100 kHz E
S21      100 kHz F
S22      100 kHz G
S23      RX
S24      10 kHz A
S25      10 kHz B
S26      10 kHz C
S27      10 kHz D
S28      10 kHz E
S29      10 kHz F
S30      10 kHz G
S31      EXTERNAL
S32      1 kHz A
S33      1 kHz B
S34      1 kHz C
S35      1 kHz D
S36      1 kHz E
S37      1 kHz F
S38      1 kHz G
S39      CH

LCD Driver 1 segment outputs
S0     100 Hz A
S1      100 Hz B
S2      100 Hz C
S3      100 Hz D
S4      100 Hz E
S5      100 Hz F
S6      100 Hz G
S7      MHz
S8      10 Channel A
S9      10 Channel B
S10     10 Channel C
S11     10 Channel D
S12     10 Channel E
S13     10 Channel F
S14     10 Channel G
S15     Right arrow
S16     1 Channel A
S17     1 Channel B
S18     1 Channel C
S19     1 Channel D
S20     1 Channel E
S21     1 Channel F
S22     1 Channel G
S23     Left arrow
S24     HI
S25     M
S26     LO
S27     F
S28     K
S29
S30
S31
S32     Bar graph L
S33     Bar graph M
S34     Bar graph H
S35
S36
S37
S38
S39

Now it makes sense, doesn’t it?  So now I can decode the binary data sent to the LCD drivers.

I looked at the LCD driver chip data sheet (PCF8576) and see that there are both command and data words.  Most of the command words have to do with LCD configuration and I can ignore them; I will have to pay attention to the cursor index set command but that is trivial.

To be continued…

I had less time to play than I thought I would have this Thanksgiving weekend, but I did make a little progress.  I started the actual code, included libraries, did some reading up on how to use them.

I also hooked up a simple LCD display.  Here it is:

My plan is to use this setup to develop code to read the data from the Syncal, piece by piece.  This alphanumeric display is extremely simple to use so I can concentrate on the radio interface and not have to develop and debug both the radio interface and the graphic display at the same time.  I can decode what I get from the radio and display as text, each element of the display one by one, this way.  Once I know I have all the data received properly I can replace the display with the actual graphic one I will use and concentrate on the graphical layout of the data I have.

My next step will be to finalize my understanding of the Syncal display mapping, then how the two LCD chips are addressed, then lift their response pins on the I2C bus, wire up the I2C ground and power and route them out of the radio with a small connector to tie to my little Arduino test board.

Then it’s just a matter of slogging through the different segment mappings.

After posting about my Syncal display project I was asked if there was space in the radio for the Arduino board:

There isn’t, but fortunately it doesn’t need to be installed into the radio.  The board is to make it easy to develop projects and also program the microprocessor chip.  The chip is the socketed DIP below the green LED.  The rest of the board is for power supplies, USB interface etc.

So what will happen is that I will get the code working then take the CPU chip out and mount it on a small perfboard with RC (no need for crystal accuracy in this application).  It will run right off the radio +5 volt logic supply.  This goes right between the OLED graphic display and the existing display board.

Then I buy another Atmega 328P chip to put on the development board for my next project.  Of course, I could be lazy and load my completed program onto one of these:

https://www.adafruit.com/products/2590

That’s a surface mount version which is 0.7″ x 1.7″ and only 0.2″ thick.  Then there’s only the need for 5 wires to the radio and 5 wires to the graphic display, no discretes.

The Racal Syncal 2000 is an amazing “pack” set for amateur use.

1.  It is built to British military specifications,
2. Designed for outdoor use in the field,
3. One of the lightest of its type,
4. Built in fast auto-tuner,
5. VFO knob (VERY rare in a military set!)

Unfortunately these are very hard to find, and when they are, they can be extremely expensive.  Not wanting to get a second mortgage, but really wanting one, I was able to get one for a very attractive price.  The hitch was that the LCD display had some bad segments.

I thought there was a small chance the problem was board corrosion and the LCD itself was ok, but that was not to be.  The problem is actually with the LCD display itself, and it is a custom part, and of course no longer made.

When I opened the unit I discovered a couple of design weaknesses.  The seal around the LCD is poor, and the mic connectors are not nearly as robust as the US type, and both of mine had cracked, letting in water.  This water caused corrosion of the LCD contacts.

First I addressed these concerns.  I was lucky to find replacement connectors, for way less than list price, via a surplus seller in the UK.  I then siliconed in a piece of actual glass in the front panel, which completely solved water ingress.

Now, as to the display, I decided I would see if I could find a graphic OLED display which would fit in the existing space.  Although limited due to several mechanical constraints, I found several in stock at Digikey.  I need to re-verify the mechanicals then I will order one, although I’ll probably wait until I need parts for another project since the cost is low enough that I’d like to share the shipping cost among more parts.

The schematics are so far not available for this radio.  However, the LCD driver chips are well documented PCF8576T devices which have a I2C interface.  My plan is to use an Arduino chip with the “wire.h” library which can emulate a I2C device, then a standard library to talk to the SPI interface in the OLED display.  Besides a filter cap or two and maybe a few resistors there won’t be much else in the circuit.

I’ve never used an Arduino before so I bought one from Adafruit and downloaded the development environment.  I bought a relatively simple one called Arduino Uno.  It looks like this:

It attaches to your computer via the USB port.  I loaded the dev environment and it came up incredibly easily.  All I needed to do after installation was to change the default port from Com 1 to Com 7.  I was able to open a sample program and upload it to the board, and it ran just fine.  Here is the board connected to my computer:

So here is my plan for doing this:

1. Acquire Arduino and set up dev environment (done)
2. Get to where projects can be edited and loaded to device (done)
3. Determine radio LCD segment to driver chip mapping (25% done)
4. Determine addressing of LCD driver chips in radio, and how they are daisy chained
5. Install wire.h and configure to emulate radio configuration
6. Wire up basic LCD display to dump data to as debugging aid
7. Write code to interpret segment data and convert to numerical frequency data, then display
8. Write code to trap text messages such as Good, Pass, tune, etc
9. Acquire the chosen OLED display, wire it in
10. Write code to make nice graphical display
11. Final debug
12. Remove LCD driver chips and other associated components from radio display board
13. Package to fit onto radio display board
14. Final checkout

More as I make progress!

Syncal 2000 display project, part 2