[Swansea Hackspace] Flip-Dot Display Group Project: Update

Wed Jul 25 18:09:22 BST 2018

Justin,

If I find myself in the Hackspace between now and Monday, i'll give the new
test script a go.

I came across this blog post <https://damow.net/fun-with-flip-dot-displays/>
today, from a maker who has reversed engineered a similar Hanover display
that he is now controlling with an ESP32 on a custom PCB.

By using frame interpolation he has achieved a very good refresh rate, see
- https://www.youtube.com/watch?v=XZV0VF4d4HE

I sent him a message to let him know what we're doing and he came straight
back asking for more information.

Peter

On Tue, Jul 24, 2018 at 3:31 PM Justin Mitchell <
justin at swansea.hackspace.org.uk> wrote:

> Has there been any progress on this since Monday 16th ?
>
> Following the experiments that day i read through the signaltrace file
> and noted several things of interest:
>
> 1) That there is one commit pulse per row pulse, 16 row pulses per
> column pulse, and after 32 column pulses there is what i can only
> assume is a 'reset' pulse.
>
> 2) each commit pulse changes all 4 enable lines, with P1-P3 always high
> during a commit/reset pulse and low the rest of the time, with P0 being
> high most of the time, and low during the commit pulse.
>
> 3) the reset pulse is similar to a commit pulse, but all enable lines
> (P0-P3) are high, so is the column line, when the commit line is
> pulsed.   This presumably resets all the row/column counters.
>
> 4) There is an even stranger variant, like an elongated variant
> combining both commit and reset, which may be some kind of panel
> selection instruction.
>
> I'm now certain that the P0/enable line has to be controlled, and
> possibly the other three, although it may be possible they can just be
> pulled high.
>
> The simple_test arduino code has been updated to reflect these
> observations, although we still dont know the correct pulse intervals
> as theres no timing info with the trace, so that may need some
> experimentation.
>
> Once someone can confirm that simple_test works I can combine the
> changes with the gfx_test code which gives you full Adafruit_GFX
> interface to the panels. Its fairly simple from there to write the code
> to do a serial interface to gfx primitives as i outlined elsewhere.
>
>
>
> On Sat, 2018-07-14 at 10:50 +0100, Nathan Hackett wrote:
> > Thanks Peter for the info! My immediate thought was to add active
> > cooling to the coils although I know that's ridiculous...
> > I think a nice web interface would be a good approach - if it works
> > on the network then great, if not we just fullscreen a browser on the
> > pi and run it from localhost.
> > Given that this potentially has some 'realtime' requirements for web
> > based control pads etc, and the need for some glue logic to talk to
> > the serial interface, personally I'd gravitate towards a basic python
> > framework like Flask, or maybe one of the asyncio variants with
> > websockets support such as Quart or Sanic. Just in terms of speed and
> > ease of development, they're great for toy projects. I guess it comes
> > down to which stack is preferred among those willing to help. :)
> >
> > I can lend a couple of wireless Gamecube Wavebird pads with usb
> > adapter, which are very robust. As long as they're not likely to
> > wander off on their own. ;)
> >
> > On Fri, Jul 13, 2018 at 12:29 AM Peter Barnes <pe5erb at gmail.com>
> > wrote:
> > > Nathan,
> > >
> > > The spec sheet for the panels is that we can refresh an entire
> > > display at 2Hz. We may be able to push this further, but the coils
> > > will burn if they are left on too long / used too often.
> > >
> > > As we will be driving each display individually, this refresh rate
> > > will not be affected by combining multiple panels into a billboard.
> > >
> > > I'm sure we can achieve a much higher refresh rate by only changing
> > > the pixels that need changing (frame interpolation), enough to run
> > > a game such as Tetris etc.
> > >
> > >
> > > If we use an RS-485 bus to connect the panels, this will not limit
> > > the refresh rate, we will almost certainly be limited by the
> > > maximum duty cycle of the coils or the speed at which we can
> > > address the panels.
> > >
> > > We haven't had much discussion about the front end software, but
> > > it's looking like we might write something that will run on a Pi 3
> > > with a monitor, that will let us switch between different programs
> > > that we've written for the panels.
> > >
> > > For games, wired pads would work well but they could get broken
> > > easily. We could make a web controller that people could use with
> > > their phones. The network was rock solid last time but i'm a little
> > > apprehensive about relying on a connection for everything to work.
> > >
> > >
> > >
> > > Peter
> > >
> > > On Thu, Jul 12, 2018 at 10:31 PM Nathan Hackett <nhackett1 at gmail.co
> > > m> wrote:
> > > > Great to see this project take shape, amazing the motivation a
> > > > deadline can create. ;)
> > > >
> > > > You're all better placed to make decisions about driving the
> > > > board's so I won't jump in on that except to ask, what do we
> > > > think is the theoretical refresh rate for the entire display?
> > > > Assuming a low number of pixels changing each frame, like in
> > > > Pong. And is the proposed serial interface fast enough to update
> > > > the entire panel matrix at this rate from a bitmap source?
> > > >
> > > > What's the plan for the software, who's helping? I'd love to help
> > > > with the games - would we be going for wired pads or some sort of
> > > > web interface? What's the wireless network situation at EMF?
> > > >
> > > > I'm still planning to donate up to two panels to the space once
> > > > this display has served its promotional purpose, but just so
> > > > everyone's aware I'll want the rest back in time to split up for
> > > > xmas gifts! :)
> > > >
> > > >
> > > > On Tue, 10 Jul 2018, 16:32 Justin Mitchell, <justin at swansea.hacks
> > > > pace.org.uk> wrote:
> > > > > On Tue, 2018-07-10 at 13:47 +0100, Peter Barnes wrote:
> > > > > > Justin/Gwion,
> > > > > >
> > > > > > > Have you documented which pins do what, the voltages and
> > > > > currents
> > > > > > > required, etc ?
> > > > > >
> > > > > > Yes, Tom has put together a full schematic in KiCad for the
> > > > > display,
> > > > > > which along with exported logic analysis from a scope at uni
> > > > > has
> > > > > > allowed us to figure out which pins do what.
> > > > > >
> > > > > > > I looked at the project page you listed but it only points
> > > > > to other
> > > > > > > peoples similar projects.
> > > > > >
> > > > > > I've just updated the Project Page with all of this new
> > > > > information,
> > > > > > so that should make a lot more sense now.
> > > > >
> > > > > I have grilled Tom to get a breakdown of how you communicate
> > > > > with the
> > > > > panels, as this info is not yet on the project page or reverse
> > > > > engineering log.
> > > > >
> > > > > So it boils down to 4 IO lines at 5V, plus a 15V power supply.
> > > > >
> > > > > Column select, row select, pixel value, and latch.
> > > > >
> > > > > So assuming some goals for the drivers:
> > > > >
> > > > > * one driver per display panel, so they are interchangable.
> > > > > * minimise changes to individual dots when changing display
> > > > > * minimise data between master controller (RPI?) and panels.
> > > > > * keep costs low whilst avoiding too much hardware building
> > > > >
> > > > > My first suggestion would be to drive each panel with an
> > > > > arduino pro
> > > > > mini board, they cost about a pound each these days, and
> > > > > running them
> > > > > from a 5V power supply line means they can interface directly
> > > > > with the
> > > > > panel.
> > > > >
> > > > > If they implement a double-buffered graphics controller, 16x32
> > > > > pixels =
> > > > > 64 bytes ram per buffer is easily achieved. so that when
> > > > > signalled it
> > > > > will update the display from memory flipping only the dots that
> > > > > have
> > > > > changed since last update.
> > > > >
> > > > > Then use a simple serial protocol to feed it graphics commands
> > > > > over the
> > > > > serial port. just a few commands box, circle, line, text,
> > > > > bitmap,
> > > > > update-display, would probably do.  there are plenty of
> > > > > libraries
> > > > > around to implement the actual drawing and fonts eg u2g or
> > > > > adafruit gfx
> > > > > library
> > > > >
> > > > > to attach several panels to one master controller, assuming it
> > > > > doesn't
> > > > > have many serial ports, and you want to run them fast, i would
> > > > > suggest
> > > > > adding RS485 interface chips. You can get breakout boards with
> > > > > MAX485
> > > > > chips on them from aliexpress for 25p each.  that lets you have
> > > > > upto 32
> > > > > devices share one serial port.
> > > > >
> > > > > you then run whatever high level code you want on the RPi,
> > > > > receive
> > > > > twitter messages, decode videos, play games, whatever.  it
> > > > > creates a
> > > > > set of gfx commands to update the display panel buffers, and
> > > > > when the
> > > > > updates are complete send a sync/update command to all the
> > > > > panels to
> > > > > have them flip the dots to match the internal memory.  nice and
> > > > > smooth.
> > > > >
> > > > >
> > > > >
> > > > > as an alternative, for single panel independence you could
> > > > > drive a
> > > > > panel using an ESP8266/32 with just a few transistors or a
> > > > > level
> > > > > shifter to connect to the drive pins. a cheaper solution when
> > > > > you just
> > > > > want a single panel to be doing some things on its own, like
> > > > > being a
> > > > > clock or status display or something.
> > > > >
> > > > >
> > > > > happy to help implement parts of that, although i dont get to
> > > > > the space
> > > > > all that often lately.
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Hackspace mailing list
> > > > > Hackspace at swansea.hackspace.org.uk
> > > > > http://swansea.hackspace.org.uk/mailman/listinfo/hackspace
> > > >
> > > > _______________________________________________
> > > > Hackspace mailing list
> > > > Hackspace at swansea.hackspace.org.uk
> > > > http://swansea.hackspace.org.uk/mailman/listinfo/hackspace
> > >
> > > _______________________________________________
> > > Hackspace mailing list
> > > Hackspace at swansea.hackspace.org.uk
> > > http://swansea.hackspace.org.uk/mailman/listinfo/hackspace
> >
> > _______________________________________________
> > Hackspace mailing list
> > Hackspace at swansea.hackspace.org.uk
> > http://swansea.hackspace.org.uk/mailman/listinfo/hackspace
>
>
> _______________________________________________
> Hackspace mailing list
> Hackspace at swansea.hackspace.org.uk
> http://swansea.hackspace.org.uk/mailman/listinfo/hackspace
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://swansea.hackspace.org.uk/pipermail/hackspace/attachments/20180725/b7a1d8fd/attachment.html>