Thank you very much. I needed some reassurance that I am on the right track: I am trying the solution you mention (increased scan rate, scrolling every Nth period) but I'm getting unexpected results (pixels 'stretched' in the direction of the scroll). Now that you confirmed that the scrolling algorithm is sound, I will concentrate in fixing my implementation.

This is a more detailed explaination of my problem, in case someone can shed any light. Maybe the problem will turn out to be something embarrassingly simple :)


The display is driven dynamically, scanning over the rows. The display is arranged as a number of 8-row-high blocks which are scanned in parallel. Every 1/8th refresh period, the common column driver registers for each block are loaded with the row bitmap data. Then, the row is lit for a small amount of time, much smaller than the row period (actually it's more than 1 row because there are many blocks, but as far as timing is concerned this is irrelevant). The amount of time the row remains lit is variable; this is how the brightness is regulated.

The original scroll procedure is very simple and can be summarized as this:

Show display bitmap by scrolling over all 8 rows.
(Move bitmap left)
Show display bitmap by scrolling over all 8 rows.
(Move bitmap left)
...

 

The code uses double buffering to prevent flickering. This shouldn't be a problem, unless I have somehow upset the synchronization... will check that tomorrow.

I needed to modify the scroll rate by a noninteger, <1 factor. A simple reduction of the refresh rate was not possible because blinking started to become noticeable at such low frequencies.

I then tried raising the refresh frequency by a non-integer factor K so that I could perform the scroll every N refresh cycles, resulting in an overall scroll rate factor of K/N relative to the original -- which is the same as you proposed in your reply. Something like this:

Show the same bitmap for N display refresh periods (N*8 row periods).
(Move bitmap left)
Show the same bitmap for N display refresh periods.
(Move bitmap left)
...

 

In principle, this should give me the desired scroll rate. And it does, the problem is that there is some strange artifact which for lack of a better name I'll call 'pixel doubling': The pixels look two pixels wide, stretched in the direction of the scroll.

I think this effect is somehow related to persistence of vision because a digital camera can't 'see' the doubling (which BTW prevents me from uploading a picture...).

I tried turning off the leds one or more refresh periods before turning them up in their new position, like this:

Show the same bitmap for N-M refresh periods.
Leave the display blank for M refresh periods.
(Move bitmap left)
Show the same bitmap for N-M refresh periods.
Leave the display blank for M refresh periods.
(Move bitmap left)
...

 

The above scheme alleviates the pixel doubling but results in flicker, as was to be expected. The pixel doubling completely dissapears when M=N-1, i.e. when each bitmap is only shown for one refresh period. Conversely, that's the value for which the flicker is the worst.

At this point and after a number of experiments I began to think that I had misunderstood something very basic, and thus my question.


Uff, that was long.


Anyway, I don't expect anyone will be able to diagnose my problem with just the given information, unless it's some very glaring goof up. As I said, your reply already gave me what I was looking for.

Regards,

José A. Ruiz