Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Addressable speaker system

Status
Not open for further replies.

vigyanabikshu

Member level 1
Joined
Oct 2, 2008
Messages
32
Helped
5
Reputation
10
Reaction score
5
Trophy points
1,288
Location
KERALA, INDIA
Activity points
1,528
Addressable speaker system 1 wire long distance PWM like communication

Hello Folks,

I am working on an addressable speaker system project on which some 25 speakers are connected, each with a PIC MCU inside and want to select one at a time. CAT6(8 wires) cables are connected. two pair for power 24VDC and 1 wire for communication. Maximum length around some 200mtrs. I am planning to send a unique PWM signal to select a specific speaker from master MCU. The PIC MCU inside, receive PWM and detect duty cycle, and turn it and turn relay ON relay, if a dutycycle match occurs. Will this system work fine?
 

Attachments

  • Untitled.png
    Untitled.png
    205.8 KB · Views: 98

If you design it properly, “it will work fine”. Long duration pulses? Low noise environment?

But why PWM, Why not a single pulse of a specific duration? Why a whole microcontroller when you could do this with an RC circuit and a comparator?

And how do you turn a speaker off?
 
If you design it properly, “it will work fine”. Long duration pulses? Low noise environment?

But why PWM, Why not a single pulse of a specific duration? Why a whole microcontroller when you could do this with an RC circuit and a comparator?

And how do you turn a speaker off?

Thanks for your prompt reply.
I just tested now with a point to point 300mtrs long cat6 cable, works fine while applying a toggling pulse every 1ms for speaker 1, 2ms for speaker 2 and a 100ms for 100th speaker and vise versa. Have to connect and test with more

Low noise environment
No idea on RC circuit and comparator based system
I have connected speaker over a relay's N.C, whenever relay closed, speaker will be disconnected

- - - Updated - - -

Do I need some kind of protection for the input pin?, it will damage all the MCUs in the line if some accidental over voltage or something happened and how to protect MCU input pin
 
Last edited:

So you have to continuously send a pulse train of 1ms /2ms etc. period to keep the speaker enabled? First of all, that's not PWM, that's simply a train of pulses. If it works, I can't argue with it, but it seems like a lot of overhead just to implement a very infrequent event (enabling the speaker).

Your statement "I have connected speaker over a relay's N.C, whenever relay closed, speaker will be disconnected" makes no sense. Do you mean when the relay is ENERGIZED the speaker will be disconnected? So, you have to energize the relay (using power) to turn the speaker off? That sounds backwards and wasteful to me.

Knowing nothing about your circuit I can't say what kind of protection you need, but it's probably a good idea to put something there. Transorb; diode protection, etc.
 
I would suggest a far similar system: Keep the wiring as it is but instead of using PWM, use a simple two byte serial stream. Byte one to identify loudspeaker 0 through loudspeaker 255 and byte two to select or deselect it. The advantage is it is easier to send serial data than PWM over long lengths, the data only needs to be sent when selecting or deselecting a loudspeaker and it allows for multiple selections at once. Most MCUs already have UARTs in them so you probably don't need any additional hardware. You also get some spare bits of data to use for other purposes, maybe to flash an alert light on the selected loudspeaker or set volume level.

With care you can even use the same wires for audio as for control!

Brian.
 
Hi,

Yes, I aslo vote for UART.
The PWM needs to be continuos ... maybe causing annoying crosstalk to audio...and for sure more difficult to decode.

Klaus
 
Three votes for UART. If you're going to use a microcontroller, you might as well use a UART. It will be a lot more reliable.
 

I would suggest a far similar system: Keep the wiring as it is but instead of using PWM, use a simple two byte serial stream. Byte one to identify loudspeaker 0 through loudspeaker 255 and byte two to select or deselect it. The advantage is it is easier to send serial data than PWM over long lengths, the data only needs to be sent when selecting or deselecting a loudspeaker and it allows for multiple selections at once. Most MCUs already have UARTs in them so you probably don't need any additional hardware. You also get some spare bits of data to use for other purposes, maybe to flash an alert light on the selected loudspeaker or set volume level.

With care you can even use the same wires for audio as for control!

Brian.

Thank you very much for your valuable suggestion. But I am confused with UART will reliably work over some 200mtrs and for some 25 MCU slaves simultaneously. Any way, I will try it and reply on some ultra low baud rate.
 

Hi,

Thank you very much for your valuable suggestion. But I am confused with UART will reliably work over some 200mtrs and for some 25 MCU slaves simultaneously.

UART is just a name for the interface, but it does tell nothing about
* signals (optical, voltage, frequency modulation, single ended, differential, RS232, RS422)
* wiring (single wire, coax, twisted pair, optical fiber ...)
* baud rate

Useful for your application may be:
* 9600 Baud via RS422, 120 Ohms twisted pair, correctly terminated, plus GND
* optical fiber
* or 9600 baud via frequency modulation added to the audio signal. Frequency above your audio range. Benefit: no extra wiring necessary)

Some additional ideas you may find useful or not:
* you also could consider to transmit the audio digitally (maybe AES/EBU style) .... and insert the address information in the digital stream.
(There are ready to buy ICs for this .... many years ago I used such a part with I2S for audio data and I2C interface to a microcontroller for the adress information)

(True audio over ethernet is an option, too. With POE as supply. The benefit is that there are cables, POE injectors, ETH switches ... available. = most compatible with existing hardware.
The developing effort depends on how much ready to buy solutions you use / how much you want to develop on your own. Maybe start with a raspberry)

Klaus
 
Even with cheap RS422 drivers/receivers (8-pin ICs) you can reach distances of Kilometers quite easily, even at high data speeds.

For almost unlimited distances, use a RS422 transceiver (I use ADM488 for this kind of application) in repeater configuration, just link the output of the receiver to the input of the transmitter and continue the link to the next device. It is an almost zero component solution: one IC, one decoupling capacitor and if necessary (probably not) a line terminating resistor. Any MCU with a UART can be used at each loudspeaker to recognize it's address and turn the sound on or off as desired. For absolute lowest cost, you can 'bit bang' a software UART as there will be no other timing demands to comply with, something like a PIC10F202 would do nicely as long as you keep the data rate sensibly low.

Brian.
 
I agree about using RS-422 or RS-485. It can work over many km in a party line topology with correct end termination.

I'm however surprised that you are planning 200 m regular speaker cable, apparently with low ohmic speakers. Most people would use constant voltage over this distance, 200 m low impedance cabling gives considerable power and particularly high frequency loss. See https://en.wikipedia.org/wiki/Constant-voltage_speaker_system

Sending the data over the audio cable is an interesting idea, but would require modulation to avoid audible interferences. A power line modem chipset is an obvious option. Effort is of course considerably higher than separate data line, could make sense if you are working in an existing public address infrastructure.
 
I agree about using RS-422 or RS-485. It can work over many km in a party line topology with correct end termination.

I'm however surprised that you are planning 200 m regular speaker cable, apparently with low ohmic speakers. Most people would used constant voltage over this distance, 200 m low impedance cabling gives considerable power and particularly high frequency loss. See https://en.wikipedia.org/wiki/Constant-voltage_speaker_system

Sending the data over the audio cable is an interesting idea, but would require modulation to avoid audible interferences. A power line modem chipset is an obvious option. Effort is of course considerably higher than separate data line, could make sense if you are working in an existing public address infrastructure.

I am working on an existing public address infrastructure in an school. I have already done wiring, CAT6 in addition to the traditional 100V line matching speaker lines. Some 80 speakers are there in 4 independent groups. ie 20 to 25 in a line, having a length below 200mtrs.

- - - Updated - - -

I tried RS485 initially with max485, but unfortunately were not worked properly. So I decided to avoid complication, reduce cost and power consumption as it is powered on the twisted pair bus. I simply want to choose a speaker out from a 25. Now I decided to send a single pulse periodically for example 1ms pulse for select 1st speaker, 2ms pulse for 2nd speaker and vise versa. 1st MCU will repeat the signal to the second, second will forward to 3rd and vise versa like a daisy chain model. This method works for me for even at a 300 mtrs distance of CAT6 from 1 mcu to another.
 

One disadvantage of daisy chain method is, if one node failed, entire will fail after it. So I am thinking of putting a foreward diode too between incoming pin to outgoing pin, so that even if one intermediate mcu failed, it will not affect the others after. I see a clash chance on failure.
 

First of all, putting a diode from input to output will probably make the whole thing fail, and certainly won’t solve any problem. Why didn’t your multi drop configuration work? Was it terminated properly? Did you try running at slower speed? RS485 can run over 100’s of meters at slow data rates.
 
I tried max485 on 9600, but if connected more than 5, started receive failure on some MCUs. So to avoid complexity, I switch to pulse mode experiment, which can reduces complexity, cost and current consumption. Working so far fine on 300mr.
 
Last edited:

Hi,

If you need further help, please provide useful informations focussed on the problem.

RS485 is a very reliable data interface. Used million times in the industry over many hundreds of meters with much more devices on a single bus than you use.
Thus I assume you did something wrong.

How did you test your RS485 topology?
What test conditions did you use?
What did you expect?
What did you see instead?
(Even a hand drawn) schematic is very useful.

Klaus
 
successfully implemented in a 100 speaker p.a facility. 25 speakers in each 4 channels using the periodic pulse method.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top