Overall Design

[TerryJC]

Anticipating responses to the Requirements being positive, here is my high-level design for the re-engineered Minter Bells and MP3 Player.

Items being re-used are marked with an asterisk.

1. Raspberry Pi 3 to run the Bells software. *
2. Rapberry Pi Zero to run the MP3 Player in the Nave.
3. 2-off Pimoroni Pirate Audio 3 W Amplifier HATs to process and amplify the audio.
4. 2-off loudspeakers in the Tower for the Bells. * These will be reconfigured so that instead of being connected in parallel, they will each be connected to one of the Stereo O/Ps of the Bells Pirate Audio.
5. 2-off Speakers in the Nave for the MP3 Player. One of these will be the existing speaker * and the other will be a new one. They will each be connected to one of the Stereo O/Ps of the Bells Pirate Audio.
6. EW-7318USg USB / WiFi Adaptor with detachable Antenna.
7. 6 m coaxial RF extension lead. The Antenna will be removed from the Adaptor and located in the Bell Tower or on the roof and connected to the Adaptor with the RF extension.
8. Edimax EU-4208 USB / Ethernet Adaptor.
9. Short Cat 5 Ethernet cable. The two Pis will be networked together and the Pi 3 will be configured to route traffic on Eth0 to and from WiFi0.
10. 2-off GPIO breakout Boards to allow access to GPIO pins when the Pirate Audio HATs are fitted. (See Note.)
11. Quarterjack assembly. *
12. 2-off MOSFET drivers for the Quarterjack.
13. 12 V to 5 V DC / DC Converter. It may be that only one will be needed, but with the Pirate Audio HATs running off 5 V instead of 12 V as the current system uses, then this is unlikely.
14. 12 V PSU or external source. Current requirements are likely to be of the order of 3 to 5 A.
15. PSU filter circuit.
16. Equipment Case for the above.
17. Fan(s) if required.

Note:

I am still thinking about how to provide control of the Players and signals to trigger the Quarterjack MOSFETs. I will definitely need to provide two GPIO outputs for the Quarterjack MOSFETs, but the other functions (Next MP3 Track, Wedding March, Late Hours etc), could be triggered using a Webserver in a similar manner to the Engineering GUI currently in use on the River System. I'm open to suggestions, but it would greatly simpilify the hardware if we could lose the toggle switches, which i don't think were used a lot anyway and had real problems with bounce.

Please let me have your comments.

[TerryJC]

Hamish said:

I'd need to know more about how the system works and what it would need to do, but probably it would work. Are you thinking of a simple web GUI? I can probably throw something together fairly quickly as a proof of concept when I have a little time.

The current system has four spring-loaded three-way toggle Switches, each of which is connected to a GPIO pin via a debouncing circuit. Depressing a switch or pushing it upwards generates a GPIO signal which is detected by code that looks like this:

Code: Select all

def add_switch_events():
    GPIO.add_event_detect(20, GPIO.RISING, callback=extended_hours_trigger,bouncetime=3000)
    GPIO.add_event_detect(21, GPIO.RISING, callback=extended_hours_disable,bouncetime=3000)
    GPIO.add_event_detect(22, GPIO.RISING, callback=change_rings_start,bouncetime=3000)
    GPIO.add_event_detect(23, GPIO.RISING, callback=change_rings_stop,bouncetime=3000)
    GPIO.add_event_detect(24, GPIO.RISING, callback=mp3_player_start,bouncetime=3000)
    GPIO.add_event_detect(25, GPIO.RISING, callback=mp3_player_stop,bouncetime=3000)
    GPIO.add_event_detect(26, GPIO.RISING, callback=wedding_sequence_start,bouncetime=3000)
    GPIO.add_event_detect(27, GPIO.RISING, callback=wedding_sequence_stop,bouncetime=3000)

Once triggered, the callback executes the specified function.

Effectively, I'd want a button on the GUI to call the same functions, so we don't need the switches or debounce circuits.

[TerryJC]

Penri said:

Yes I think so, certainly easier than contorting oneself through the Minster window to read the switch labels.
If the GUI is simple and clear plus works on the devices people have then I would think it would be welcome.
Will access to the GUI be separate from the river?

I think that Hamish might be able to answer that better, but I will clearly have to run a modified version of the Bells software on one of the Pis and a different modified version of the MP3 software on the other. Presumably, I would also need to run a Webserver on the two Pis or maybe the control can be communicated using sockets code or something a little simpler.

Having said that, there is no reason why the GUI part of the thing can't run on the same server as the River System GUI with the buttons triggering a message to the appropriate Pi, although since that is an Engineering GUI and this will be an Operators GUI I think they would be better kept separate.

All that can be thrashed out over the coming months.

While I’m thinking about it could some sort of status be included in it, the GUI, too?

Just add any desires, must-haves or wouldn't-it-be-nice-ifs to the Requirements Topic at viewtopic.php?f=47&t=273.

[hamishmb]

NB: Would it be better to have this as a subforum of the existing Minster Bells forum so we don't have 2 forums for that system?

I'll respond to the other comments after spending a little time thinking about this.

[TerryJC]

NB: Would it be better to have this as a subforum of the existing Minster Bells forum so we don't have 2 forums for that system?

Once the re-engineered system is complete it will have little in common with the old one, apart from the basic requirements.

I started this as a separate Forum to avoid confusion.

Others may well disagree.

[hamishmb]

Thanks for the info on the callbacks Terry.

Penri,

I think it would be better to have a webserver (or some other server software to communicate with the Office/other PCs/phones/whatever) running on one of the minster bells pis. I feel like running the software on the NAS box like the engineer GUI is a bad idea, because we're mixing two different, complex systems that way, and also the NAS box hardware is quite weak - I don't want to add extra load by giving it anything to do that doesn't have to run on it.

Then, the code running on the "main" minster bells pi could talk to the secondary pi with Sockets (seeing as it's tried and tested).

Speaking of, why do we need two pis, instead of extra responsibilities for the existing pi?

Fair enough with the separate forum then I think. We can always mark the old one as "[OLD]" or "[DECOMMISSIONED]" or something if the requirements are approved.

[TerryJC]

Speaking of, why do we need two pis, instead of extra responsibilities for the existing pi?

There are two independent audio systems in the Minster; the bells and the music. The current system uses the standard audio Jack and a USB Audio Adapter, but the quality of neither is much good. The Pirate Audio HAT provides excellent quality but we need two or them. I very much doubt that I could stack them since they use SPI Bus and I don't think that they support changing of the address.

Fair enough with the separate forum then I think. We can always mark the old one as "[OLD]" or "[DECOMMISSIONED]" or something if the requirements are approved.

Good idea.

[hamishmb]

Ah, okay, that's fair enough. Have you looked into changing the bus address just in case? Might be a money saver if it does work.

[TerryJC]

Ah, okay, that's fair enough. Have you looked into changing the bus address just in case? Might be a money saver if it does work.

I've used one of these before in the Railway Room. This device wasn't designed to do that, so there isn't anything in the documentation. SPI needs the address to be set in the firmware, unlike I2C which allows address configuration using jumpers.

In any case the extra Pi is pretty cheap. if I could use only one Pirate Audio HAT then we'd save £20.

[Penri]

Hello

My question on having a different GUI / Webserver was because I don't want personnel accessing the Minster Bell / Music getting at the River System.


Penri