Acer K330 LED beamer repair

IMG_0575

This article is about one of my recent spontaneous projects. A few days ago, I got lucky on an ebay auction and picked up a broken Acer K330 beamer. I often look for these kinds of offers because I have spent several years in the audio/video repair business and am pretty confident in my skills when it comes to fault-finding. So I figured, saving some money by restoring a broken device couldn’t hurt.

First some facts and features: The K330 uses a three color LED module, which promises a long lifetime and low energy consumption. A Texas Instruments DLP module handles image generation. In sum this lets me hope for good contrast and strong colors, even if the brightness of 500 lumens doesn’t seem that much. An interesting thing about this DLP chip is that it uses an uncommon diamond pixel grid for size reasons. Diamond in this context means that the pixels do not form a rectangular pattern like in the usual TFT monitors but rather a grid of 45° rotated and slightly squeezed, not completely rectangular tiles. Of course, this means that internal resampling has to occur to map the image from the rectangular domain onto the diagonal domain of the IC.

So, this projector was obviously broken when it arrived – what a surprise. The seller had already informed me that it had suffered from overvoltage of unknown cause. The VGA picture was supposed to be very green-ish, the HDMI input dead in whole and the media player erratic. A slight flickering in the picture was also mentioned. I’ll take you through the repair process for this device from here on. [Read More]

Tagged as: , ,

Wacom digitizer screen

Anyone who has already tried to use some kind of tablet device for writing should know that there are fundamental differences between screen types.

The most common is the capacitive type, where you use a finger or some kind of conductive pen to write on a glass surface, while the touchscreen device captures movement of the capacitance change through a grid of transparent electrodes on the backside of the glass. This works, but it sucks for writing precise text or drawing sketches. You can find these screens in almost every modern smart phone, tablet PC or kitchen appliance. They are cheap!

Next is the resistive touchscreen, where a small, hard point presses down on a plastic surface. The touch element is composed of two pieces of clear foil, coated with a conductive material. While the two layers stay isolated when there is no pressure applied, the pen forces them together in a certain point, forming a conductive path. By knowing the specific resistance of the surface coating, the circuit can determine the position of the pen tip by measuring path resistance from different edges of the screen. This type was pretty popular in PDAs (which have by now been fully replaced by smart phones, what a shame ;-) ) as well as the almost equivalent navigation assistants – and is not that common anymore. Writing performance is fair but not exceptional, though.

The third kind is the most interesting one. Real tablet PCs (the ones with the flip-over display) have this normal-looking pen with the nylon tip, which you can use to accurately write on the glass/plastic display surface. Many even feature some buttons on the pen, some kind of eraser on the backside – and they are damned accurate! They have another thing in common: Most of them use technology by a company called Wacom, also producer of digital writing and drawing pads for artists.

This type is called a “digitizer screen”, and it uses a sensing panel *behind* the actual display to recognize and track the pen. The digitizer panel contains an amazing set of surface coils to provide an alternating magnetic field through the screen. Inside the pen, there is a resonant circuit which uses the field energy to transmit the button states and even pressure on the pen tip back to the coil. By monitoring the strength of the resonance through different surface coils, the digitizer then calculates the position of the pen above the surface. In other words, you get a high-res info about the pen position (easily above 25.000 points resolution along the surface edge, depending on the digitizer type!), you know the pressure applied, button presses on the pen and even where the pen is when it is not yet touching the surface.

I recently disassembled a trashed tablet PC (Toshiba Portege) with a broken motherboard for interesting parts, and came across this:

tablet01The LCD panel is a LTM12C328T type. Attached to the backside is a SU-010-X01 tablet pen digitizer, and the marking on the ICs clearly suggests that it is made by Wacom. This would make a fine graphics tablet – but how to attach it to any other PC?

Further examination shows two Wacom ASICs (W8001) and a board number (PWB-A542-X). No pin markings, though. And, as usual, no datasheets available.

tablet02The digitizer was connected to the original mainboard through this 14 pin connector (pin 1 on the top end). All wires end at the LVDS display connector on the motherboard, which is the singular connector for all display-related components in this tablet device. No pinout information is available, however – except for some speculation on the internet.

What we have is: 14 pins total, 3 wired red (1, 13,14), 7 wired blue (6 through 12) and 4 unconnected (2 through 5). I already removed the original wires when I took the pictures, sorry!

From the coloring of the cables it is pretty obvious, that some are different. My assumption about the red ones being power while the blue ones carry data can be confirmed by analyzing the layout of the interface PCB. Pin 14 attaches to the large ground plane – ok. 13 leads through some SMD parts, probably coils, to two different paths, decoupled by capacitors. Probably VCC, ok. The voltage is unknown however, so I just assumed it to be either 3.3V or 5V. Any higher stabilized voltage is uncommon for this type of circuit.

That leaves pin 1, which is also colored red. This one leads directly to the interface chip, but there is a solder bridge (open), which connects it to the GND plane – which makes it GND, but probably some kind of semi-isolated GND for the interface. I closed the solder bridge to nail this to ground. Then I applied 3.3V from my lab supply to the board and probed all remaining pins with the scope.

The first thing I found was that there is no data activity going on with the pen away from the display. In this case, all pins are low except for #12, which has an on-board pullup resistor of 22 kOhms. Maybe some kind of reset signal.

When the pen gets near the display, stuff happens. While it is still a short distance from the surface (even through 15mm of wood table!), pin #6 jumps to high. At the same time, a continuous data stream appears on pin 9. No other activity can be detected though, so I suspect a serial interface. If the pen touches the surface and pressure is applied to the tip, pin 5 also goes high. By now I know that this was only a lucky coincidence, because the panel not necessarily transmits stylus position data right away.

That brings me to a preliminary pinout:

  1. GND (logic)
  2. ?
  3. ?
  4. ?
  5. TOUCH (active high)
  6. PRESENT (active high)
  7. ?
  8. ?
  9. (Serial?) TX
  10. ?
  11. ?
  12. RESET?
  13. VCC (3V3)
  14. GND (common)

Another assumption needs to be made about the serial interface. First, a back channel is likely to exist, as the PC can usually query the tablet for parameters. This can be deduced from linux Wacom device drivers for the W8001 chipset. Also, the typical baud rate for serial tablets seems to be 19200 or 38400. I am not sure, however, if the tablet supports any type of flow control. The extra connected pins suggest that at least two such lines exist (probably DTR/RTS), but the scope shows no activity.

Now I connected the panel to my linux PC through a MAX232 IC and a cheap Prolific PL2301 serial-USB converter. Pin #9 goes to the PC RX, and I tried pin #10 as PC TX, because the pair #7/8 somehow seemed much more probable to be flow control lines by layout. Next, I managed to find out something about the serial protocol. There appear to be several, which are quite well documented. I guessed the panel to be of the ISD V4 type, because it was previously connected to an ACPI internal serial port – so, ISD probably stands for “Internal Serial Device” or something like that. These devices feature a reduced command set without any response to presence detection, which means that no auto detect is possible and it therefore won’t work with Windows – even if you use tricks like editing the registry for serial tablet detection. The driver needs to KNOW that a panel of this type is present, and where it is. Wacom had a special driver for such tablets, but it is no longer available.

Care has to be taken with the MAX232 though. The panel seems to be 5V-tolerant, but I did not want to take chances. I dropped the MAX232 supply voltage as far down as possible, which is around 4.5V. Depending on the components used, that may or may not work. A proper USB/3.3V serial coverter is the correct choice.

More info about the protocol:

http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview

http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=ISDV4_Protocol#Format_of_Stylus_Query_Response

Using a serial terminal, I set the port to 38400 baud and tried to send the ASCII “*” character, which queries the stylus info. No response. The same happened on 19200 baud. This is not surprising though, because the panel only responds to “*” if it is in the stopped mode, so a “0” (zero) has to be sent first. I found that out by probing around on different baud rates and combinations. Finally, the panel responded with 10-byte sequences and could also be switched to stylus streaming mode.

At this point I tried to hook the archlinux XServer onto the device. After installing xf86-input-wacom, I created a new config file in /etc/X11/xorg.conf.d which I named 99-wacom-isd.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Section "InputDevice"
Identifier "WACOM ISDV4 stylus"
Driver "wacom"
Option "Device" "/dev/ttyUSB0"
Option "Type" "stylus"
Option "Button2" "3"
Option "AutoServerLayout" "on"
EndSection
 
Section "InputDevice"
Identifier "WACOM ISDV4 eraser"
Driver "wacom"
Option "Device" "/dev/ttyUSB0"
Option "Type" "eraser"
Option "AutoServerLayout" "on"
EndSection

This tells X to try and add this tablet, whenever a new hardware device is plugged in. Note that it does not use a device class, because the tablet will not broadcast its type! After a reboot, the tablet is recognized by default and usable as a pointing and drawing device. If it does not work, chances are that the panel requires a reset (read on below) or that the serial port is not setup correctly (should be 19200-8-N-1, no flow control). This leaves a final pinout (highlighted are all pins used in simplified operation):

  1. GND (logic, can be shorted to common by solder bridge)
  2. ?
  3. ?
  4. ?
  5. TOUCH (active high)
  6. PRESENT (active high)
  7. Flow control (?)
  8. Flow control (?)
  9. Serial TTL TX
  10. Serial TTL RX
  11. ?
  12. RESET (?)
  13. VCC (3V3)
  14. GND (common)

Some questions are left:

  • Is there flow control? What about pins #7,8,11?
  • How is the reset handled? Often the tablet will not react to serial commands after power-up and will therefore not interact with the driver. In this case, pin #12 needs to be pulsed low to make it work. It appears as if there is no internal power on reset circuit, so this was probably triggered by the tablet driver after booting.
  • What about the pins #2-5? Some devices seem to have an USB port on these, but mine does neither have any kind of pullup on these pins (needed to select USB speed) nor does it react to applying a USB bus.

Now, all that is missing to my very own LCD graphics tablet is the LCD part. Panelook.cn tells me that it is a Toshiba 12.1″ 1024×768 TFT display with CCFL backlight, but again – no datasheet. The interface is probably LVDS, judging from the cables and mainboard trace layout. I still have one of these VGA-LVDS converters laying around, so I will use it for this project. There is also a model with DVI in, to which I will upgrade later on – or replace the panel, something like that.

tablet06What is missing is – again – the pinout for the 20 pin panel connector. From examining the panel input header and measuring conductivity, I decided on the following layout:

  1. VCC 3.3V (red)
  2. VCC 3.3V (red)
  3. GND (red)
  4. GND (red)
  5. LVDS O0- (blue)
  6. LVDS O0+ (white)
  7. GND (red)
  8. LVDS O1- (blue)
  9. LVDS O1+ (white)
  10. GND (red)
  11. LVDS O2- (blue)
  12. LVDS O2+ (white)
  13. GND (red)
  14. LVDS O3- (blue)
  15. LVDS O3+ (white)
  16. GND (blue, to shielding)
  17. N/C
  18. N/C
  19. GND (blue, to shielding)
  20. Unknown signal (blue, to shielding)

This layout is pretty much the standard LVDS header layout, with the ground lines in between and all, so I am pretty confident with this. As for the data format, this can be guessed: 1024×768 is obviously the resolution, and color depth is usually 6 bit if we are talking about a portable screen. 8bit are only common in desktop displays. The converter needs to be jumpered to these values. And – after hooking the panel up to the LVDS converter – it works like a charm!

tablet07A little hard to see, but we have picture! This needed some wine until it worked…and the backlight is not yet plugged in.

Finally, a little calibration is needed on the software side to fix the digitizer mapping to the screen surface (xsetwacom) and the DIY paperless scratchpad is finished! Well, it still needs a case of some kind, but some CNC work will fix that.

 Appendix:

  • Calibration:
    #!/bin/bash
    # WACOM SU-010-X01 calibration data
     
    xsetwacom --set "WACOM ISDV4 stylus" area 0 0 24000 18300

    This script needs to be run after attaching the tablet. It tells the driver to map pixel position 24.000 in X direction (right border of tablet) to the right border of the screen, and the same for the vertical axis. All values are approximated by trial and error, but they fit pretty well. Note that the aspect ratio of your configured active area should be the same as that of the screen, so you may lose some space if you want to write on a (extra) widescreen display or else the drawing might be squeezed slightly. If the attached display is used, everything is fine.

  • Backlight: tablet11Again, this time with the backlight enabled. The display is not the best in terms of contrast, I will try to get my hands on a Lenovo X230 IPS tablet screen. In the meantime, it is sufficient as a secondary display. Even though the writing looks kind of crude from the picture, the digitizer picks up every last nuance of the pen movement.
    By the way, the CCFL inverter is a special type. It uses a piezoelectric transformer instead of a standard magnetic one, probably to avoid emissions near the digitizer. Its pinout is #1/2=VCC (>=5V), #3/4=GND, #5=Dimming (connect to VCC), #6 unknown, #7 unknown

Shiny parts: Laser diode

During disassembly of some old CD/DVD drives, I stumbled across a pair of *really* beautiful laser diodes. Not much use for them right now, except practicing macro shooting – pretty hard to get good pictures of the structures inside and the dichroitic filter blue at the same time.

Tagged as: , ,

TSOP as a proximity sensor?

A few days ago, a friend came over to talk about some microcontroller related projects. One of the topics was distance sensing, or rather proximity/movement sensing with low technical effort.

The basic idea was to detect movement of an object or person within a short distance to trigger events. Typical sensors for this kind of application would be passive infrared (PIR) modules, radiowave sensors (microwave or radar) or active infrared distance sensors. All of these can be quite pricey, perhaps with the exception of the PIR, which cannot detect objects very well.

So, I thought about how the goal could be accomplished with standard parts. Active infrared is the most simple choice for this one.

The demands:

  1. Detection of objects, not only persons/pets.
  2. Ranging if possible.
  3. High immunity agains disturbance signals.

From (3) I can already define that pulsed IR will be needed. Well, no problem so far. Detection has also been done: Take the standard TSOP17xx IR receiver block and some kind of modulated IR source, make sure they don’t see each other while pointing in the same direction, and you are good to go. This principle has the benefit of being dead simple, because the TSOP chip has all the fancy stuff like AGC and disturbance filters integrated – just watch the output go low and you have just detected a reflecting object.

But how to do the ranging? The best idea would be to send out a sequence of pulses that become weaker and weaker until no signal can be received anymore. By comparison of the power needed for sufficient reception, one can then draw a conclusion about the presence of reflectors. But this means that the LED current would need to be modulated, too, which makes things more complex. I wanted to use a standard Atmel AVR microcontroller with no external parts.

At this point I had an idea: What if I not the LED current but rather the sensitivity of the TSOP receiver were the variable? A look in the datasheet confirmed my thoughts: Filters almost never have infinitely steep transition bands (which is where the “pass” to “no pass” transistion occurs), especially analog ones like the bandpass filter inside the TSOP17xx receiver. The sensitivity vs. absolute frequency curve is given in the datasheet. My thought was that by frequency-modulating the transmission signal, I could change the sensitivity of the receiver in a way that lets me make a decision about the reflected IR power without having to change the LED current at all.

tsop-datasheet[1] TSOP1736 datasheet rev. 10, published by Vishay Semiconductor. Page 4, figure 1. See http://www.alldatasheet.com/datasheet-pdf/pdf/26588/VISHAY/TSOP1736.html for details.

So we set up a test circuit: An ATMega8 controller generates an 1:1 PWM signal to feed the IR LED. As for the receiver, we used an TSOP1738 type sensitive to 38kHz. The datasheet specifies a drop in sensitivity of 80-90% for a frequency deviation of 8kHz, which means we will sweep over the range from 30 to 38 kHz.The microcontroller does exactly that, sending out 1 millisecond of signal before turning off the IR LED and examining the TSOP output for response. If the TSOP has received something, the sequence is aborted and an index value about the frequency is returned to the main loop, where the decision about proximity or no proximity is made.

The AVR is configured to use its TIMER1 as a modulator in CTC mode, toggling the OC1A pin for each compare match while resetting the timer. Using an 11.059.200 Hz quartz as the main clock source, we needed a frequency divider of 145.51 (38 kHz) to 184.32 (30kHz), which can be reached by setting the OCR1A registers to the divider value corresponding to the desired frequency. Without the fractionals, of course, but that doesn’t matter much.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
const uint8_t lim_up = 145; // 38 kHz
const uint8_t lim_dn = 184; // 30 kHz
...
uint8_t measure( void ) {
    uint8_t= 40;
 
    for (uint8_t i = lim_dn; i--; i >= lim_up) {
        // Set frequency divider
        OCR1AL = i & 0xFF;
        OCR1AH = (i >> 8) & 0xFF;
 
        // Enable transmitter for 1ms
        TCCR1A |= (1 << COM1A0);
        _delay_ms(1);
        TCCR1A &= ~(1 << COM1A0);
 
        // TSOP output low now? Output has certain lag, so it
        // will still be active, even if TX is off!
        if (!(PIND & (1<<PD2)))
            return k;
 
        k--;
    }
 
    // Aww, no signal returned at all.
    return 0;
}

(For this code example, the TSOP output is connected to PD2 and the LED to the OC1A pin of an ATMEGA32 processor.)

After setting up the threshold value and switching an indicator LED according to the results, this method proved very usable.

There IS one problem though: The TSOP contains an AGC (auto gain control) stage that changes sensitivity according to ambient light. If the ambient light levels change during operation, the overall sensitivity of the sensor and therefore the meaning of the index value are likely to change. This means that the sensor will operate much better at night than at day, but it also depends on the electrical and mechanical properties of sensor and sensed object.

For the future, I plan to add some other routines that allow live sensor calibration and tracking of the values over time, so that slow changes will not trip the sensor while fast changes will. Precise distance sensing will be pretty much impossible, because the response of the sensor depends on reflectivity of the object in range. It will, however, be sufficient for a aeparation of moving/not moving.

Another possibility is to use more than one transmitting LED and switch them between sequences. This way, multiple sensing zones could be created, while only one receiver is needed.

Array microphone

So…it’s been a while. Somehow I thought, I’d have finished the CNC writeup by now, as well as my plans for continuing work on my plasma-bar meter project. Things turned out different.

I got into my Bachelor’s thesis after completing the preceding seminars, which kept me busy since june ’13. The topic is centered around signal power based speech DOA estimation using directional microphones, very interesting stuff from the domain of signals processing. I had a very interesting time learning lots of new things, and somehow I also wanted to get hands-on with the matter since attending several advanced DSP courses during the last two terms.

While working on the thesis, I realized that microphone array systems are really nice things to have to play around with. I decided to make my own, which I did in my free time in parallel to the thesis. Let me at least show some pictures as long as I still don’t get around to working on other stuff.

Basically, the array consists of four Panasonic WM-61A electret capsules, which are known for their robustness under high sound pressure levels. The capsules are mounted on several 140mm long, 6mm dia. brass tube segments using aluminum sticky tape and heatshrink. The mounting method ensures no acoustical reflectors or flat faces in the near field of the microphones, which enhances the acoustical properties of the whole assembly. All sound ports are pointed upwards to keep the characteristic beam patterns of the microphones as similar as possible. According to the datasheet, this should be an omnidirectional pattern for each capsule, but the mounting causes some deformation. In this case, the bottom direction (sound coming from along the brass tubes) is somewhat sub-optimal.

To connect the capsules, I used 2-lead shielded microphone cable with a 3-pole headphone plug at the end. I applied the “Linkwitz mod” (http://www.linkwitzlab.com/sys_test.htm) to rewire the capsules for better preamplifier performance, using the described two-wire connection for the capsules. I didn’t connect the shield on the capsule side, but the capsule has a pretty good metallic connection to the brass tube, which means that the shaft is connected to microphone ground. For the meantime, this solution is sufficient, even though it would be better to connect the shaft to the shielding and keep the capsule isolated to prevent a ground loop. I will correct that at a later point since it is pretty hard to connect a wire to a brass tube from the inside, if you can’t solder for fear of the cable melting ;-) Well, I’ll figure that one out eventually. For now, humm and distortion is low enough for the purpose.

To keep the array together I cut a piece of layered wood (called “Multiplex” here) on the CNC mill, drilling holes for the brass holders in predefined distances that match the parameters of my DOA estimator project. The brass tubes are pushed tightly into the holes and the cables dangle out of the bottom. An extra hole in the middle allows the assembly to be attached to any kind of support with a 6mm screw.

The preamp is still breadboarded for now. Shielding is pretty bad (or in other words “not present”), but nevertheless it performs rather well. I get a little bit of hum from nearby power lines, but I can blank that out in software for the time being. The case (cast aluminum) is already in the making, and has also proven to be an adequate test for the CNC to demonstrate its ability to mill aluminum. Not perfect to the 0.001, but near enough. I will integrate the amplifier into its new home as soon as I get a little more free time to mill a pcb, which will be in another two weeks, when all the other stuff is finished.

For signal acquisition, I currently use an ESI MAYA 44 USB+ 4ch-in/4ch-out external soundcard, which has the nice benefit of being ASIO-capable and can be used with MATLAB and especially Simulink. The latency is not as rock-stable as with cards like the RME Fireface series used in the university labs, but with some MATLAB trickery, I can get more than acceptable results out of it.

Tagged as: , , ,

CNC finally running

The CNC mill got into a working state right before christmas eve. I know it’s not a present in that sense, but still! :3

Some parts of it are still fixed with a lot of glue and tape (or zip-ties ^^), but for now that’s perfectly sufficient. Right now. it can already mill hard wood and MDF, so I will be redoing some critical parts that lack in precision and/or quality before I write up the whole project as one. Unfortunately, I fear that the original plan about using an (older) EPIA 800 board as a controller can not be followed, EMC2 just refuses to start on that thing. Grrrr…

More pictures and text will follow in a few day’s time. Until then, enjoy the holidays and have a nice and safe start into the new year!

Oh, right, and two Stellaris Launchpad eval-kits from TI that I ordered back in September arrived JUST ON the 24th. How great of a timing is that? I don’t care about the wait, it was well worth it and I knew up front – but thanks again to the girls and guys of the TI support, for solving all the technical difficulties along the way :-)

PBG12201 plasma displays

Bar display with reservoir cap in HV circuit

I picked up some unusual plasma displays from ebay some weeks ago, which I have been searching for quite some time now. The picture above shows an illuminated Burroughs PBG-12201 plasma bargraph display. They are pretty hard to get by now, and if available, prices are a real shocker. Some shops in the US that carry them ask for 230 USD and some even more. Sometimes they appear on ebay for about 50 USD, but you have to be real quick to get some. Best chances are with surplus stores that sell off leftover production stocks or disassembled devices that originally contained such tubes. A few very retro and very popular mixing consoles for audio applications used them as main VU meters (eg. made by Lexicon),  as well as some current professional grade standalone meters (eg. RTW, one of those is where I first saw such a display and was absolutely fascinated by the deep orange hue). As they eventually get old and start flickering or burning in if not properly cared for, spare parts have become rare, and since Vishay – the most recent producer of these displays – has discontinued the product line in early 2012, I would expect the market to dry up even more.

Mine were obviously scavenged from some kind of device by a Hungarian ebay seller, he offered some 10+ pieces of the PBG-12201 type display for 8 Euros each – a real steal! I just couldn’t resist and got myself three of them, together with matching sockets. Thinking back, I don’t get why I ordered three instead of four…oh well, it’s done. The tubes show some signs of wear, like glass chipped off around the edges and burn marks on the cathode traces, but they all work fine.

Devices like these use an interesting driving technique (from a retro point of view, today it is more of an old hat) as they are linear dot scanning displays – and befitting, the trade name for them is “Self-Scan”. The basic structure resembles a nixie tube: An evacuated sandwich made out of a glass plate and a ceramic back plate is filled with neon gas that can be ionized by applying a high voltage between a transparent anode metal film on the backside of the glass front plate and some printed cathodes on the back plate. However, this is a linear display, so it doesn’t consist of numbers but instead of small lines that have been masked by some isolating grey lacquer applied on top of the conductive traces. The left-out spaces in the mask form the slightly brighter active areas where the neon glow will appear. All in all, the tube provides two independent bargraphs with 201 segments each.

There even was a cool circular type of this display, but I don’t think there is any recent production of those.

The port at one end of the tube features connections for:

  • A pair of standby keepalive electrodes (Anode/Cathode) that are placed opposite of each other on the glass and ceramic plate. These are permanently lit up to keep a level of ionisation and never let the tube supply idle.
  • Two independent anodes for the two bar strips.
  • A reset electrode (actually the first strip in the bar)
  • Three connections to an interleaved network of fine traces on the ceramic plate that are used to control the length of the bar. These cathodes are laid out to form three phases, meaning the 1st, 4th, 7th, etc. dots are connected to each other. As are all the dots shifted by one upwards, e.g. 2nd, 5th, 8th and so on. Finally, the same goes for the 3rd, 6th, 9th, etc.

To control the length of the bar, a rotating three-phase signal is applied to the three electrode combs. The comb corresponding to the currently next segment is switched to ground using a high voltage capable transistor (MPSA42 or comparable) and thereby “pulls” the glowing dot one step forward, then the connection is broken and the next comb in turn is switched to ground. When the end of the bar is reached, the phase signal is reset to the first phase and the reset electrode is pulled to ground for a fixed period of time. This extinguishes the glow and reignites it back at the first bar of the display. Only one electrode is glowing at a time, which gives the display a very precise scale and (in my opinion) makes it much more appealing to the eye than any continuous-glow linear nixie, like for example the IN-13.

Just to have covered the fundamentals: If you would slow down the scanning process of the display – which you actually can as the display is VERY tolerant of SLOW scanning times) – a single dot would travel the length of the bar. Persistence of vision (the slow recovery of the retina) makes this scanning process appear as a bar if the scanrate is high enough. Today, it is called multiplexing and used extensively in LED matrix displays. This also explains the missing-piece phenomenon in the second picture: Imagine the shutter of the camera opening while the dot wanders from 2/3rds of the bar to the end, wraps around and runs from the beginning up to 1/3rd.

A bar of varying length can be displayed by running the glowing dot up as many steps as needed, then resetting the display and starting again. There are specific minimum times that need to be maintained for phase on-time and reset on-time, so the display won’t start to flicker around erratically. One can achieve “frame rates” of up to 70 Hz for these displays according to the datasheet, which makes them flicker-free. My first attempts showed that there is some margin to the values, so experimentation is definately useful. Even more so if some of the dots should be of varying brightness. The way to achieve this is actually described at some point in one the datasheets if I remember correctly, but the principle is the same as when scanning LED displays: on-time control for each dot). In the pictures I have highlighted some random bars, this could certainly be used to make a scale. Unfortunately, the scale can only be visible in the lit-up area of the bar, because the display does not allow dark-scan to the point a scale mark is wanted at. Remember, the glow follows the grounded electrode – we can’t really make it jump across multiple bars, can we.

Also, there is some ghosting of the highlight marks because I drove the display with only about 180V dirty unfiltered DC with some serious ripple on it – probably as many as a few dozen Volts – where it typically needs about 250V pure DC to run. Well, it can’t be helped for now until I manage to find a matching ferrite for a step up supply in the depth of my boxes, so I used an old cheapo EL foil inverter I had lying around.

Maybe there is a possibility to scan the dark parts of the bar super-fast if the operating voltage is high enough, but I can try that only after I construct a proper supply.

I am currently driving the display from a simple breadboarded test circuit around an ATMEGA8 MCU while the high voltage side is handled by four MPSA42-transistors that I still had lying around from some recent audio power amp repair job. Note that I have not used base resistors, since the datasheet rates these transistors for Ib,max=100mA. While this is quite reckless to the chip and the transistors, it usually works for a crude test – a typical case of the “don’t want to walk to the basement and get some”-disease. Even so, it’s a no-no in proper designs. Collector resistors are not needed for the phase drivers because the current is limited by anode resistors already. The anode voltage is generated by said battery EL inverter which outputs about 150V of far-from-sinusoid AC, which I then one-way rectify using a single HV diode of a rectifier bridge to obtain about 180V DC. This is just sufficient to make the display ignite, but it causes severe troubles with stability. Misses a beefy cap.

EDIT: As usual, found a cap that I was looking for all over the place just when I had finished writing. Scavenged from a photo flash unit, 330V at 100 µF, plenty of charge. While the supply is still far from perfect, it does help to smooth the DC some. Enhances the risk of a painful encounter, too. This fixes most of the trouble with the bar for the moment, see the added a picture above. I will try for some daylight-comparable shots tomorrow.

In the link section below is a link to the official application note by Burroughs, which explains all the details of the drive circuit and also the possibility to drive the display using logic only. It’s nothing complicated really, but using a microcontroller brings all the advantages of being able to control precise on-times of each dot indepentently, so I guess that’s the way to go.

The next step will be to make a proper schematic and board for this with a proper supply and some analog or digital audio analysis circuitry and/or a digital control input. One of these would look great in the front of some big DIY amp, maybe behind a piece of smoke-colored acrylic or tinted glass :-)

Some background info and other projects for this kind of display:

Stereo-Balkenanzeige mit der Anzeigeröhre PBG12201 @ www.jogis-roehrenbude.de (German page)

Vishay PBG Plasma VU-meter…photos @ www.groupdiy.com (English forum thread)

PLASMA PBG12201 VU KITS @ www.groupdiy.com (English forum thread)

PBG display datasheet @ www.vishay.com

PBG display datasheet @ www.alldatasheet.com

Burroughs PBG application note no. BG101C @ www.brianroth.com

Tagged as: , , ,

Workbench #3

Work on the CNC continues…the end draws nearer. I am currently disassembling the whole thing as far as necessary to clean up all the edges and burrs and fix the positions of the parts relative to each other using hammered-in stainless steel pins. After that, it is just coupling the threaded rods to the moving parts and bring the stepper drivers alive.

DNS problems with Netgear FVS equipment

A follow-up on the recent DNS-related stuff:

I figured out today that my router had a hand in those weird random connection problems. What made me especially nervous was the almost systematic way that DNS and other random UDP packets vanished from the ‘net during browsing or testing with various tools. The requests were shown to be sent in both the Wireshark protocols and the router packet capture, but an answer never arrived. As it turns out, Enterprise-class devices have their firewall preconfigured to block UDP flood from inside the local network.

The definition of “flood” used here is:

“20 simultaneous, active UDP connections from a single computer on the LAN”

http://documentation.netgear.com/fvs336g/enu/202-10257-01/FVS336G_RM-06-09.html

Now, somehow my setup managed to step over that line, and from what I gather on the ‘net I am not the only one experiencing this. Sometimes the system will run clean for a few days, then bug in increasing frequency until I get fed up with it and kill the whole DNS process plus cache. Apparently, this fixes the problem for some time as a good reset almost always does, but it is no permanent solution.

To debug, first turn on the attack-related logging functions in the router and clear the logs. Then call up “nslookup” on Windows based systems and fire some random URL DNS requests in fast sequence. In my case, after four requests the firewall kicks in and UDP flood warnings appear in the log. Maybe Windows 7 just leaves the ports open a little too long, I don’t know and I haven’t checked. However, since this feature has been turned off in the firewall settings I had no further DNS problems, and the speed of browsing has increased a little.  Hopefully that was all there was to it.

Another point of interest: Some Netgear devices have developed a habit of kicking lots of NBSTAT-packets on the LAN, one about every 5 seconds or so. Seems to belong to some type of NETBIOS detection mechanism, though the sense escapes me. The packets are of unicast-type and therefore disrupt everything one could possibly have in the way of wake-on-unicast, which linux supports to wakeup devices from standby if they are talked to directly. NETBIOS features are nowhere to be found in the configuration menu, so I guess at some point the checkbox for that must have gotten mislabeled. The one responsible is “ARP broadcast” found with the LAN settings. Turning it off quiets things down a lot.

But: You lose the capability to show unknown devices in the LAN clients list for simple management of DHCP fixed leases. You can still turn on ARP for a few minutes if you need to detect anything, though.

Tagged as: , ,

Faulty IRC DNS lookup

I’ve been having some problems connecting to IRC through the miranda client on Win 7 lately.

Miranda features several “serverlists” for different IRC networks – QuakeNet in my case. Some of the lists work, some don’t, some work at some times. Now, upon clicking edit only one fixed web address shows up. The way this works is, the DNS server knows multiple IP subentries for those servers. You can check with some web-based lookup tools that show all of those entries. Windows’ own command (“nslookup <address>”) only shows the one delivered by the server, as it needs only one precise IP to communicate.

Multiple entries exist to balance load between servers, they are delivered round-robin. If you flush your dns cache locally (Win 7 wants you to do “ipconfig /flushdns” on the console in admin mode, for example) a new IP is acquired – and this one is ideally different from the one before. Now, because Windows does not clear the cache between requests for several logical reasons (it’s a cache, right?) the client program obviously also knows only one of the possible IPs. All the better if exactly that IP is down.

It took me quite some time to figure out where the problem was (all the while thinking there may be something wrong with the router or the net is just in a weird mood today). After checking the DNS entries sequentially using ping and a connection attempt through Miranda, I found to my surprise that while some lists work partially others are simply dead.

irc.quakenet.org 1/8 working Compilation of all subranges
se.quakenet.org 1/3 working
de.quakenet.org 1/2 working
uk.quakenet.org 1/3 working

Remember that this data is momentary from the time I checked the servers. The status might be different now. Anyways, this is some russian roulette!

The lists may fluctuate though, I am pretty sure I got a connection using the german list at some time. It is also possible, that the lists are updated dynamically from time to time, but I haven’t seen it so far.

Fixing this mess is quite easy: just edit or add a list in Miranda for the corresponding network and enter the exact IP. You best find that one yourself by pinging, start with one of the shorter lists you are comfortable with. You will experience trouble if that server goes down, but at least then you will know what the heck is wrong right from the start. Saves time and nerves.

Tagged as: ,