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

Wed Jul 25 20:07:19 BST 2018

His circuit diagram matches ours, and it all sounds the same, except
his description and code do not match what we see in our signal trace.

Out signal trace definitely shows the commit/reset line being pulsed
for every pixel change, it therefore cant be reset, and the 18v coil
line always being high.

Unless of course the labelling of the signal trace is wrong ?

The need to pulse the 18v line could be an explanation of why pixel one
keeps getting hot, maybe?

On Wed, 2018-07-25 at 18:09 +0100, Peter Barnes wrote:
> 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 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.hacks
> pace.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 gmai
> > l.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.h
> > acks
> > > > > 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
> 
> _______________________________________________
> Hackspace mailing list
> Hackspace at swansea.hackspace.org.uk
> http://swansea.hackspace.org.uk/mailman/listinfo/hackspace