Tally Pi HAT?

[dougthebug]

I'm interested in implementing a Pi HAT, a la https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/

Ideally this would interface with the classic 8-relay DB-25 internal to the legacy Encore and ScreenPro-II controllers, as well as providing headers for SPI LEDs and some diagnostic LEDs

Is anyone working on something like this?

[depili]

Easiest solution (that I ended using on one tally box) was just getting a relay module like this: http://4tronix.co.uk/store/index.php?rt=product/product&product_id=154 and wiring it to the rpi GPIO. Most 5V relay boards such as that work with 3,3V control signals, just make sure you provide 3,3V on the Vcc pin to the module and 5V on the Vd, the voltage actually used to drive the relays.

[dougthebug]

I have a few relay boards I can wire up, that's the 'easy' part. What I'm curious about is if anyone in this circle has giving thought to laying out a PCB just for this system that would have a few relays on it as well as diagnostic LEDs and a power button. To include a useful number of relays and a terminal block would make a device at least twice the size of the Pi, but could also provide space for a LiPo battery and breakouts for additional relays. I see some of this as potentially being essential to the adoption of this by both owner/operators as well as event production companies.

[depili]

While designing the hat PCB wouldn't be too major project getting the boards manufactured would certainly be. And if the end-user isn't willing to connect few wires between a relay module and pi then soldering all components to the pcb wouldn't work either.

[dougthebug]

Right. Breadboards and jumpers are for prototypes, not for production. If
you and your clients are satisfied with a mess of wires then so be it, but
I cannot imagine a scenario in my field in which anyone would be okay with
a breadboard in a production environment. My terminal strips for
tally scare the shit out of my clients, who have no idea how any of our
systems work, which is why we keep them hidden. Let's not even consider
the extra mass that jumpers and breadboards and terminal strips add to the
bulk of any system, the mere sight of a mess of wires is likely to throw me
under the bus for a laptop or media converter or human failure and will
lead to the subsequently intentional or not dismantling of said tally
system by an over eager freelancer staying late to "fix the problem." I
can't seriously sell this system to my clients without it at least being
enclosed in a steel case, and I'm not trying to fly with that in my pelican.

I'm glad you have clients who are happy to use your homebrew systems, but I
can't present any system to a client that isn't at least nominally "shrink
wrapped" by a manufacturer, let alone a convenience like tally.

I'll design my own breadboards, and I'll have them manufactured in small
quantities, for pennies on the dollar compared to losing a client or my
reputation over a misunderstanding, or having my gear confiscated at
customs because it looks like a bomb.

If anyone in this group has any input on how to polish this interface, I'd
love to hear it, but your suggestion that the overwhelming majority of
Encore operators and audiovisual companies can't afford a manufactured PCB
to achieve this end is amateurish and unprofessional.

I am very impressed by your team's development of this software, but I
sincerely hope that you don't speak for the group in the matter of making a
standardized PCB for this application. In my humble opinion, it's a major
hurdle to overcome in the common acceptance of tally for graphics by the
event producers and the people who actually pay our wages.

I'd love to hear any opinions from the other developers of this software
that aren't defeatist. I'm seriously asking the question, "is anyone
working on a standard for breaking out GPIO to extend this system," not
"can anyone recommend a way to further the stereotype that live event video
engineers are mavericks that refuse to fall in line with the most basic
rules of production equipment."

To get back on track, I suggest a HAT which would allow room for four
relays with standardized terminals, as well as expansion I/O via the
standard interfaces exposed by the Pi platform. Would anyone like to
contribute any productive ideas that don't involve jumpers outside of the
prototyping phase?

I must sound like an asshole if you're new to this thread, but please
understand that I posed this question a week ago and the only response
(repeatedly) I've received amounts to "use jumpers and breadboards," which
does not begin to address my question.

Yours in Solidarity,

Douglas Owen Baker

On Monday, September 19, 2016, depili [email protected] wrote:

While designing the hat PCB wouldn't be too major project getting the
boards manufactured would certainly be. And if the end-user isn't willing
to connect few wires between a relay module and pi then soldering all
components to the pcb wouldn't work either.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#8 (comment), or mute the
thread
https://github.com/notifications/unsubscribe-auth/AHJoOQxWbfs0inHNl8vH7OOZ-nMJnHkmks5qrpStgaJpZM4J64ZS
.

[SpComb]

The qmsk-e2 tally stuff is still at a very early stage, and you are definitely the first person that I know of to consider using this outside of the event where we originally started developing this :)

The background here is that we're volunteers at a biannual event, and we started writing some code to scratch our own itch with the E2 system that showed up at the venue, that was (at the time) missing the control panel (hence the original preset manager, if you look at the git history). So while our own budget and needs for a bi-annual weekend event are something adequately addressed by breadboards and jumper wires between relay modules (which were packaged into an enclosure as a prototype unit), the current tally code does work well enough now that there's definitely some scope for starting to work on production-grade hardware.

To answer your question, no, I don't know of anyone designing a Pi HAT approach. It sounds like it would make a nice compact solution, assuming you can figure out some kind of enclosure that supports the DB-25 connectors. Perhaps use a RJ-45 socket with a DB-25 breakout instead?

I do however know that there is some work going on for a rackmount unit with an embedded rPI, but I'm not working on that myself.

My own stance here is that this is a hobby project that I'm working on in my spare time, and approximately bi-annually as a full-weekend volunteer project. I am happy to fix issues in the code to maintain a high level of quality, and occasionally spend time developing new features, but I myself am not going to be selling nicely packaged tally boxes, and I am also not going to be providing end-user support for those kinds of deployments.

However, you are more than welcome to use the open-source qmsk-e2 code as part of such a packaged solution for your needs or others' needs, as long as you understand the following:

• The source code is MPL v2.0 licensed, which means that you are more than welcome to package it up into a product. Any modifications to the qmsk-e2 source code files must also be available as open source under the MPL v2.0 or a compatible license. For example, as a GitHub fork. Ideally with pull requests, so there's a single up-to-date upstream.

• I disclaim any warranty for the code, and I will not provide end-user support. For example, if someone files a github issue about some bug in a product running an old version of this code, where the bug has already been fixed in the newest master version, I will go ahead and close it with extreme prejudice. It's the responsibility of anyone providing a product to support it, including updates to newer versions with fixes.

  Which happily also coincides with the first point above, if all fixes make their way into this upstream... and actual bug reports with issues in the code are naturally always welcome.

• Avoid upsetting Barco by doing anything silly like misusing their trademarks. Or inflict them with undue support issues caused by third-party components on the network, which we unfortunately already did once...

[SpComb]

Oh, and to clarify, I think the only breadboard involved here is the one I took a picture of for the README, which was just a debugging aid for development :P

AFAIK the prototype box we have ATM is just hardwired with jumpers directly between commodity modules. It's easy to fix anything that breaks, replace any modules, or any change the design post-hoc.

I would gladly accept a more presentable example picture for the GPIO section :) Should perhaps move that kind of stuff to the wiki, where it's easier to edit.

[TobiasBecker]

I'm working on this, including proper tally boxes. Idea is to have 16 tally outs and all based on a raspi with Autostart.
So essentially a proper box (maybe 19") with BNC or XLR. Everything sorted nicely because of relais & optocopplers.

Here is a sample of a project with a custom build PCB for a Phidget / Universe Breakout. The idea is the same style for this (high quality, custom PCB, but BNC instead / plus Phoenix).
Greetings, Tobi from Germany