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

[Nathan Hackett]

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.com>
> 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.hackspace.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://swansea.hackspace.org.uk/pipermail/hackspace/attachments/20180714/38cf9680/attachment.html>