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
web page for detailed information about the
II doppler unit. Note:
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
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
Further discussion of the antenna drive circuit and the
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.
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.
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
make it display any text, the
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:
clock/data is handled by the chip itself and the process can be put
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:
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:
This is a work in progress, but here are a few of those things that have been completed thusfar:
There are a few more features that I will either add, or consider adding:
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.Return to the KA7OEI ARDF Page.
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
is "peloruses" - rather than "pelori." Look it up if you don't