An Unconventional Loudspeaker system                                 Latest change 2019-01-23

Software

General:
The Arduino software was developed and tested with the Arduino IDE version 1.8.8. on WXP and on Linux 18.1 / 64
The PC software was developed and tested on:
  - WXP and W7 with FPC version 2.6.2 and Lazarus version 1.0.14. and several other combinations.
  - Linux Mint 18.1 with FPC version 2.6.4 and Lazarus version 1.4.2.

To compile the ConfigTool software I had the package lnet065 installed in Lazarus. There may be a more recent version.
For serial communication with the testtools I had the 5dpo-serial package installed. (also named Sdpo)

Installing the Arduino IDE on Linux intially has a permissions problem for the (USB)serial port. In most cases it is sufficient to make the user member of the group dialout:  In a terminal window type:   sudo usermod -a -G dialout <username>   (requires logoff-logon or reboot)

Lazarus / FPC normally creates enormous executables because a lot of debug info is included.
In Project-ProjectOptions-CompilerOptions-Debugging you can check the box "Use external gdb debug symbols file"

You may download the software in source.
The Pascal Source directories contain executables for Windows and Linux.
No installation is required, just run the executable.  A settings file will be generated in the directory of the executable.

Download zip: Arduino software on the FLT board.

Download zip: Arduino software in the Control Amplifier.

Download zip: GUI_ConfigTool

Download zip: GUI_TestTool FLT 

Download zip: GUI TestTool TPA  


Operation of the firmware FW_FLT-4.
The FLT-4 firmware is used on the FLT-4 board and on the TestTool-TPA.
The firmware can run in 3 modi, Local, Remote (=!Local) and TestTool. And some Fake modes.
In normal use on the FLT board the mode is Local. The mode Local is left when the Control amplifier or the GUI_TestTool_TPA starts talking.
On every incoming message an outgoing message is sent. See the Messages Document
In Local operation a number of things are monitored: presence of mains power, presence of the CR+ signal used to switch-on the loudspeakers, the supply voltages are measured and range-checked and the status of the TPA power amplifiers is evaluated. Except for Clip conditions on a TPA board any of these error conditions lead to an immediate reset of the TPA boards. This reset clears the errors signals from the TPA-board, so if that was the cause of the error it will be cleared now and the reset is taken away. While there is an error condition the firmware spontaneously sends meesages to the Control Amplifier where an errorr led indicates that something is wrong.
If not Local the error conditions do not lead to a TPA reset, error conditions will be visible on the GUI-ConfigurationTool, which is normally the only thing which can send messages to the loudspeakers.

In case the firmware runs on the TestTool-TPA none of the above mentioned error conditions lead to a TPA reset, they will be visible on the GUI_TestTool_TPA.

About the program structure:
Most of the work is done in the interrupt handler ISR(TIMER1_COMPA_vect)  which is called at a 1 kHz rate.
In the loop() we test whether there is an incoming message, if so it is decoded, and an outgoing message is sent.
Also we test whether a spontaneous message is to be sent. (this cannot be done from within the Interrupt handler, so we use a flag)
The presence of mains voltage is detected by the pin-change interrupt ISR(PCINT2_vect) which sets a counter to 15. In the timer interrupt this counter is decremented at the 1 kHz rate, and if after 15 msec no new mains interrupt came the counter will reach zero, which is the mains-fail condition.
The Clip-OTW conditions are evaluated in the pin-change interrupt handler ISR(PCINT0_vect). Here we find out which pin did change, and accordingly a Clip-counter is incremented. A time-out of 2 seconds is set and is evaluated in the Timer handler. If after 2 seconds we still have a Clip-OTW pin low we conclude that it is an Over Temperature Warning. This will not lead to a TPA-reset, but it results in an error led indication on the Control Amplifier.

There are a few #defines in the code which relate to testing the firmware. I do not explain these options here.


Operation of the firmware FW_Control.
This is the firmware in the Control Amplifier which runs on the Arduino Mega there.

 
In the loop() we test whether there is an incoming message from the GUI, by UDP.  if so it is decoded, and an outgoing MessageToGUI is sent. The outgoing message contains the content of the latest received messages from the loudspeakers.
In the loop() also the serial ports 1 and 2 are polled for messages from the loudspeakers.

Most of the work is done in the interrupt handler ISR(TIMER1_COMPA_vect)  which is called at a 1 kHz rate.
Managed are the LedTest at startup, the PGAled = on while one of the potmeters is changing, Error leds = on when there is an error conditon in a loudspeaker,  IR remote, Chanel selection switch, the potmeters for speaker and headphone volume, and MainsOK inspection.
If MainsOK is detected false immediately the CR+ power to the loudspeakers is switched off, which causes a TPA reset. Also the settings for volume correction are stored in EEPROM. The values for Bass and Midrange matching are stored on the FLT boards.
If there is no communication with the GUI_ConfigTool no messages will be sent to the loudspeakers.


Operation of the GUI_ConfigTool.
This software runs on a PC or Laptop and is primarely used to configure the channel sensitivities in the Control Amplifier and to match the levels of the Bass and Midrange speakers to the Tweeter level. This program communicates with the Control Amplifier over the Local Area Network using UDP.
The sourcecode is t.m.h.o. quite self explaining.
Also look in the Messages page.


Operation of the GUI_TestTool_FLT.
This software is nearly a subset of the GUI_ConfigTool.


Operation of the GUI_TestTool_TPA.
This software is nearly a subset of the GUI_ConfigTool.