search

qmsk / e2

E2 Client, Tally output
Mozilla Public License 2.0
26 stars 7 forks source link

Tally Pi HAT? #8

Open dougthebug opened 8 years ago

dougthebug commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/qmsk/e2/issues/8#issuecomment-248000161, or mute the thread https://github.com/notifications/unsubscribe-auth/AHJoOQxWbfs0inHNl8vH7OOZ-nMJnHkmks5qrpStgaJpZM4J64ZS .

SpComb commented 8 years ago

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:

SpComb commented 8 years ago

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 commented 8 years ago

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. img_8591 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