Please note:  This is a work-in-progess and will be updated as time permits.  If you have any specific questions about something here (or, more likely, something that is not here) send me an email to the address at the bottom of the page.

As shown, this display integrates with the VE2EMM Montreal II doppler unit via the serial port - but it may be used with any RDF system that outputs the bearings and quality in the "Agrelo" (tm) format .

Please refer to VE2EMM's Montreal Doppler II web page for detailed information about the Montreal II doppler unit.  Note:  Because the  Original firmware supplied with Montreal Doppler III does not (at the time of this writing) have provisions to continously output bearing/quality information on the serial port, this display will not work with that unit.

Note, however, that this unit may be used with the Alternate Firmware for the Doppler I, II and III units - see the Main Doppler Index page for links to information on the alternate firmware.

Please note that this is NOT an official page of VE2EMM:  Any information concerning the contents of this page should be directed using the contact information at the bottom of this page.

 

A front view of the prototype OLED pelorus display showing recent bearings (see text for explanation.)
Click on the image for a larger version.

Further discussion of the antenna drive circuit and the antenna arrays usable with this system may be found on the Doppler Antenna page at this web site.

A Pelorus (or "Compass Rose") display - a recap:

For more information about a Pelorus and its use in a DF system, please read also the The LED-based Pelorus at this site as well as some of the related info at WB6EYV's web site.

A Pelorus or "Compass Rose" display is a very useful tool when attempting to locate a transmitter using direction finding techniques:  Its display is intuitively obvious in its nature in that the determined heading is visually indicated.  Such a display is also very useful when locating a transmitter as the way the display is behaving can tell the experienced user something about the quality of the information being displayed, such as the presence of multipath, as well as providing visual clues as to the possible true bearing when in the presence of heavy multipath.

Most Pelorus displays are constructed using LEDs:  Typically, 16, 32 or 36 LEDs are arranged in a circle, with the currently determined bearing being indicated by observing which LED(s) are on.  LEDs have been used for decades, but they have a significant disadvantage:  They aren't very bright!

From experience, it would seem that most serious DFing is done in the evening:  At this time, those doing the hunting (not to mention the that individual at the center of the DFing activity engaging in nefarious operations) are done with work for the day.  But there are instances where daylight (or near-daylight) DFing is carried out.

Typical LEDs aren't very bright and it doesn't take much sunlight (even indirect) to make it difficult or impossible to see the display.  Today, ultra-bright LEDs are available but these typically have focused lenses are quite directive and, unless they are pointing directly at the viewer, may appear to be no brighter than standard LEDs.  Also, the package in which LEDs are typically housed don't help matters either:   They are usually clear and do not "light up" in the way LEDs in diffuse packages do and thus do not offer a lot of contrast.

LCDs are a possible alternative as a pelorus could be easily represented graphically, but LCDs also have problems:  They typically have rather poor viewing angles, many have somewhat poor contrast unless viewed directly, and have the opposite problem that LEDs have:  They can't easily be seen at night.  This latter problem can be mitigated by using a backlit display - but the viewing angle problems still persist.

The OLED:

Recently, another alternative has become available:  OLED (Organic LED) displays.

These look very much like LCDs - but there is a critical difference:  They are transmissive - that is, they emit light directly.  LCDs, on the other hand, do not emit light, but rather pass or block light.  This light could be that ambient illumination that is reflected from the back of the display, or the display itself could use a backlight.  One of the problems with the backlight is that all of the display - even those portions which are not "lit up" (that is, not transparent) still need to be lit.  There is also the problem that LCDs intrinsically require the use of optical polarizers - but these let only about 25% of the light to pass through the display by their very nature.

OLEDs, on the other hand, consist of pixels that, by themselves, give off light.  These displays look very much like LCDs except that they are very dark (nearly black) when turned off - a feature that enhances visual contrast when viewing in light.  Since the pixels themselves give off light, the viewing angle is intrinsically wide - comparable to that of viewing a printed page.  Finally, the OLED technology has progressed to the point where the light emitters themselves are quite efficient, giving off quite a bit of light at low currents:  A typical small (4cm x 2cm) display consumes only 25-30 mA when all pixels set to full brightness - a fraction of what a comparable LED backlight on an LCD would consume - and this current is roughly proportional to how many pixels are being illuminated.  If the display is mostly dark with only a relatively small number of pixels being illuminated (as is often the case with a "light-on-dark" scheme) the current may be only a few milliamps.

Recent experimentation:

I recently obtained some Osram Pictiva (tm) displays (P/N:  OS128064PK16MY0A01) using the SSD0323 OLED driver chip (by Solomon Systech) and have interfaced them to a PIC16F88 processor with the prototype shown in the picture at the top of the page.  This picture shows the OLED display (at the bottom) mounted to a piece of prototyping board along with the PIC.  For this picture, it is displaying the current bearing, the past several bearings, a sliding average, and a numerical representation of the bearing and quality.

A brief rundown of the display's features:

- It uses a 128x64 graphical OLED matrix.  This is nota character-based display:  To make it display any text, the computer in control needs to graphically render
    any text appearing on the display.
- It can produce 16 levels of brightness, from total black (pixel off) to fully-on.  Having a grayscale display allows some use of shading.
- It is monochrome.  This particular display is green - almost exactly the same hue and saturation of a typical "high brightness" (but not "superbright") green LED.
- It's kinda small:  The display area is only 36 by 18 mm (approximately.)  This is 1.4x0.7 inches.  It would be nice if it were a bit larger, but when it's in front of you, it's better then you might think.
- It is pretty bright!  When used at night, may have to be toned down a bit.  Fortunately, brightness/contrast is completely software controllable.

These displays are quite thin, very light, and clearly intended for tight integration:  They connect to the rest of the world using an 18 conductor flex cable with 0.5 mm (yes, half a millimeter!) centers.  By comparison, normal DIP pins are spaced 2.54 mm - more than five times larger.  This daunting prototyping challenge was somewhat mitigated by the ready availability of connectors intended for this type of cable.  Using a very fine soldering iron tip, a small screwdriver, some #30 wire-wrap wire, and a steady hand, some "flying leads" were attached to the connector and immobilized with epoxy, yielding a "hobbyist-friendly" mechanical interface as can be seen from the picture.

This particular display uses an SPI (serial) interface - although the display is also available in a version with a CPU-compatible parallel interface (and may, in fact, be convertible simply by adding/removing a jumper.)  The serial interface was chosen for two reasons:

- The PIC itself has hardware support for the SPI interface:  All clock/data is handled by the chip itself and the process can be put under control of an interrupt driver.
- A serial interface means that there are fewer wires to connect.  It was difficult enough to attach wires to the connector anyway, and I didn't really want to connect any more than necessary for this prototype.

With this PIC's onboard SPI hardware, data is sent to the display faster than new data can be calculated, so there is (in this application) no penalty in terms of update speed or processor time incurred by the use of the serial interface.  The serial interface does have one drawback, however:  It does not allow a readback of the display RAM.  This problem is elaborated below.

What has been learned so far:
 

A closer view of the pelorus display in the "single-display" mode, showing the current bearing, several recent bearings, and the "average" bearing (see text for more info.)

Relatively little information is available about this display on the web, but an email to the manufacturer yielded a generic datasheet for the OLED driver chip used.  At the time of this writing, the manufacturer's web site contains data sheets, but these are curiously incomplete and vague with nowhere near enough information to make use of these displays.  Between the three datasheets (for three different models of OLED displays) and the driver chip's datasheet, I have been able to make the display operate as expected, learning a few things along the way:

• The chip's (SSD0323)  power-up defaults are not at all correct to make the display work properly.  The mechanical layout of the display matrix is not simple X-by-Y, but a somewhat odd interleaved pattern.  Fortunately, the display driver chip has a number of built-in options that may be used to remap the display to convert the odd addressing scheme to a straight XY scheme.
• OLEDs have certain challenges in being driven.  The segments themselves are highly capacitive - which can make them rather difficult to switch them on and off quickly - something required when using a multiplexed graphical array such as this.  This display is arranged in a matrix of multiplexed rows and columns which are scanned to drive the entire panel.  One of the techniques to drive an OLED display is to "precharge" the segments to a voltage just below that at which the display segment will illuminate.  If it turns out that a pixel needs to be lit up, it is only a very small voltage change to light up the display.  (It would appear that the OLED segments themselves need a bit over 3 volts to light up.)  Fortunately, all of this is handled on-chip - but one must program suitable parameters upon reset of the display.
• Again, the chip's power up defaults are terrible in terms of making for a clean looking display:  As-is, the display's brightness range is terrible and the display is very noisy.  Fortunately, all this requires is that, upon initialization, the display chip be loaded with some new settings.  Clearly, this chip's defaults were intended for a wide variety of displays - but obviously not (specifically) this one.
• When in serial mode, there is no way to read anything from the display:  Two-way communications is only supported in the parallel-interface version.  This causes some complications when interfacing the display with a processor such as the PIC that does not have much RAM onboard:  You can't read the display's RAM to see what is already there.  This has several implications:
• Add some RAM to the PIC.  This is perfectly feasible - albeit a bit awkward.  If this is done, one could simply modify the onboard RAM and then simply do a RAM dump to the display to update it.
• Recalculate/redraw the display constantly.  If the information shown on the display isn't particularly complicated, this is a perfectly reasonable option.  In the worse cast, one would simply blank the display and re-draw it every so-often, but a more reasonable approach would be to keep track of individual "objects" (like lines, text, etc.) and only erase/update those objects as necessary.
• A further complication is that each byte of display RAM contains two pixels.  Because it uses 16-level grayscale, only 4 bits are required for each pixel so two adjacent pixels are stored in each byte.  This complicates things a bit in that one cannot update just one pixel without modifying its neighbor, and if you can't tell what it is already, it may get obliterated.  Fortunately, there are a few workarounds to this problem that may be applied if the display isn't too complex.
• While this display is capable of displaying real-time video (assuming a fast enough input processor) it still has few shortcomings that would preclude it from replacing a more conventional LCD in this sort of application:
• With only 16 levels of grayscale, highly detailed shading isn't possible.
• It's green.  This color is a good match for the spectral sensitivity of the human eye - but it's not ideal for watching television.
• When all pixels are turned on, row/column brightness mismatches are apparent.  If one has a mostly-black display of graphics and text, such difference can't be seen easily owing to the lack of large blocks of pixels for optical comparison.

A close-up view of the pelorus in "Dual Display" mode.  The left side shows the current bearing while the right side shows the 4 most recent bearings along with the "sliding average" of the 16 most recent bearings.  (This picture was slightly underexposed to exaggerate the brightness differences between parts of the display.)
Click on image for a larger version.

This is a work in progress, but here are a few of those things that have been completed thusfar:

• Algorithms for drawing lines, circles, and alphanumeric characters are operational:  As can be seen from the picture, these functions are up and running.
• The GUI - Graphical User Interface.  I still haven't fully decided on what the display itself will look like but I've implemented a few features thusfar:
• The current bearing and quality is shown numerically on the screen.
• The current bearing and quality is also shown graphically on the screen:  The dot on the outer circle shows the bearing.  The line pointing at it serves two functions as well:  It points in the same direction as the bearing, and it's length indicates the quality of that bearing.
• The past 5 readings are also shown in the screen (on the pictures, two of them were the same, so only 4 vectors appear.)  These are shown as dimmer lines (a fact not immediately obvious from the upper picture) as to reduce the clutter of the display and allow quicker differentiation of the current bearing from a historical one.
• The "sliding average" of the past 16 bearings is shown.  If you look at the display, you'll see another dot just above the center:  The position of this dot is the calculated vector sum of previous bearings and can be useful in determining the trend
• There is a selectable "dual-display" mode.  The "normal" mode shows the current bearing, the history, and average on just one pelorus.  The dual-display mode uses the left side of the display to show the current bearing while the right side shows the history/averaging.  Both modes display, numerically, the current bearing/quality although that information is smaller when in the dual-display mode.

There are a few more features that I will either add, or consider adding:

• Enabling/disabling of some of the display features.  It would be nice to be able to turn on/off the historical and/or average displays as desired.
• Choosing the average/history size.  Being able to select the average/history size adds flexibility to operation.  There is enough RAM available on the PIC to allow a sliding average/history size of at least 32 readings - probably more.
• A "long term average" feature.  In addition to a short-term average (mentioned above) it is possible to have a long-term "running" average (rather than a sliding average.)  Since a running average doesn't require keeping in memory past readings, it would have no size limit.
• A "clear history/average" button.  If you are in a vehicle and turn a corner, the history is now invalid (assuming an "up is straight ahead" rather than an "up is north" orientation) so a quick button-press to wipe the history would be convenient.  (This could apply to the sliding and/or the "running" history.)
• Bright/Dim settings.  Because the OLED display has full brightness control capabilities, its brightness may be adjusted for day/night use.

It would seem that there is little information on the web specifically about programming this display:  The SSD0323 datasheet is somewhat hard to come by and the information on the OSRAM website is curiously vague - probably by omission rather than comission.

For a bit more information, go to my "Programming the Pictiva Display" page:  This has some very basic information on how to "talk" to the Pictiva display - but ONLY the OS128064PK16MY0A01 - which is the 128x64 serial version.  I do not have experience with any other version of this display:  While I believe that this information may apply to it, I cannot guarantee that it is correct.

Note:  Neither the author or UARC officially endorse any vendors mentioned above.  The level and satisfaction of performance of any of the above circuits is largely based on the skill and experience of the operator.  Your mileage may vary.

"Osram" and "Pictiva" are trademarks of Osram.

Do you have any questions on this or other DF-related topics?  Go here.

This page updated on 20050919

Note:  This page (and other pages on this site) are not "official" pages of VE2EMM.  These pages are simply set up to aid those who have built or might build the described equipment.

Yes, the plural of "pelorus" is "peloruses" - rather than "pelori."  Look it up if you don't believe me!