YAP 2.1 supervisor system video

[syn08]

I have uploaded a YAP supervisor system video on YouTube: http://www.youtube.com/watch?v=PsuasufGyVc


A few system design details:

- Atmega1280 @ 16MHz CPU. Binary code uses 50k Flash and 0.5k RAM. An Atmega640 would work fine as well, but this chip requires a different (and special) dev extension board. The Atmega1280 is a centipede, a 64pin Atmega1281 is fine as well, but is tight. The system requires 6 ports: display data, display control, DAC (8 channels), Inputs, Outputs. Add the required JTAG interface and it's at the very limit...

- Display is 240x128 pixels, T6963C Toshiba chipset.

- 6 absolute values circuits, opamp based, to convert and scale the bipolar voltages to positive values only.

- 2 RMS detectors, for the left/right bar graph. The integration constant was chosen 200mS, I haven't decided for the final value yet.

- Temperature detectors based on the Dallas DS18S20 in parasite power mode. Software interface/driver is built according to the Dallas 1-wire interface spec.

- The whole system is interrupt driven, controlled by a 5mS software master clock.

- Non-critical parameters (like the temperature updates) are handled synchronously with the master clock, critical errors (like the overload conditions, triggered by the left/right channels via optocouplers) are handled by asynchronous interrupts.


The sequence shown in the video is:

- System boot, activated by the backpanel power switch. The system enters the Ready state loop. Not shown: Display dims out after a configurable amount of time (currently 3 min.)

- User presses the front panel momentary switch. Not shown: during the normal operation, pressing the front panel momentary switch shuts down the amp and brings back the "Ready" screen.

- The supervisor powers up both channels.

- The supervisor monitors the power supplies (+/-, left/right), the left/right output offset and the left/right temperature. Shown are arbitrary units, power supplies will be in [%] and offset in [mV].

- If everything is ok (power supplies: +-10%, offset < 100mV both configurable) the supervisor connects the speakers after 4 seconds. The right icon changes accordingly.

- As soon as the speakers are connected, the supervisor displays the logarithmic bar graph. Current sampling rate is 20mS, it is configurable.

- The supervisor monitors all the above variables and updates the display. I messed up a little with the voltages to show how the display is changing.

- The temperature displayed is the ambient. For the purpose of this demo, I have configured the temperature limits as follows: left/right fans are starting at 28 deg C and stopping at 26 deg C (hysteresis behaviour). The system shuts down at 30 deg C, disconnects the load and the power supplies, reports a list of errors (total of 12 possible consecutive messages, shown is only the overheating message) and requires a power recycling. The Temperature icon is real time updated with the fans status (on/off).


I need some feedback regarding the display layout. My UI/graphics skills suck big times, so I am pretty sure better screens (main, error report) layouts can be implemented. The software is built in layers, so changing the screens layout is pretty simple, I just need some fresh ideas. Of course, any other ideas (new functionality and/or features) are welcomed. The project will be available (hardware (SMD PCB layout Gerbers) and software source code) on my side as soon as the YAP amp will be integrated and tested with the supervisor, likely by the end of the year.

[GK]

Don’t know how you managed to use up a massive 50k for that. I’ve got a complete (Altera CPLD) 8X8pixel/64rowX32line character-based Visual Display Unit (incorporating the complete extended graphics character set of a Commodore64 in an external ROM) up and running for my preamplifier project that will use a 8.4” TFT SVGA display module (when I can get my hands on one for an affordable price). The display is a lot more complex than that and the whole thing is controlled by a PIC16F874 @ 20MHz, with memory to spare.

Anyway, as far as display ascetics go, the level bars would look 500&#37; better in operation if they had a linear decay of 1 or 2 seconds.

[syn08]

Originally Posted by G.K.

Don’t know how you managed to use up a massive 50k for that. I’ve got a complete (Altera CPLD) 8X8pixel/64rowX32line character-based Visual Display Unit (incorporating the complete extended graphics character set of a Commodore64) up and running for my preamplifier project that will use a 8.4” TFT SVGA display module (when I can get my hands on one for an affordable price). The display is a lot more complex than that and the whole thing is controlled by a PIC16F874 @ 20MHz, with memory to spare.

Anyway, as far as display ascetics go, the level bars would look 500&#37; better in operation if they had a linear decay of 1 or 2 seconds.

Because I don't write spaghetti code.

Monobloc code may be cheap in terms of flash, but it's a living nightmare to debug, improve and add new feature. Structuring the code in low level drivers/high level interface/high level logic/user interface with clear defined interfaces between layers is more expensive in terms of flash, but these micros are dirt cheap anyway.

This thing has also a bootloader that is used to upgrade the code through a serial interface. The bootloader takes 4k.

And finally, this thing is written in C and uses the WinAVR libraries. I'll let the delights of writing in assembler to those that enjoy it, I don't.

One more thing: the system handles inrush current protection as well. At mains power on, there's a 200mS delay (configurable) before an output pin is activated to handle a relay or whatever (haven't decided yet).

I'll think about the bars, actually increasing the time constants may help as well. The bars resolution is 1 pixel. Another idea is to use a 1 pixel width vertical bar to hold the last level on each channel.

Funny enough, I concluded that the popular Toshiba T6963C display controller sucks big time in terms of graphics. Samsung's KS108 is much better (faster, flexible, etc...), but I was unable to find any display larger than 128x64


P.S. How much are you expecting to pay for a TFT module? I see on EBay a brand new 7" 800x480 pixel for $60. That's already dirt cheap... It's from China, but that's pretty much the only place you can get one today, if you want to avoid distributors.

[GK]

I gave up on assembler a long time ago - I program with CCS's PIC-C complier.
50k still boggles my mind (must be an Atmel thing).

For the level bar display;
If the instantaneous input signal sample (i) is > than the current level bar amplitude (a) [a being the variable indicating the length of the bar in pixels] then a=i; UpdateDisplay(); else a--; UpdateDisplay();

If your level bar has a max length of 100pixels, then a 20mS sample/update interval will give you a decay time (for the full bar) of 2s. Easy.

SVGA TFT/LCD gets gives you 800X600 pixels.........

Edit: I'm off to Ebay.......

[syn08]

Originally Posted by G.K.

I gave up on assembler a long time ago - I program with CCS's PIC-C complier.
50k still boggles my mind (must be an Atmel thing).

Another thing, I was lazy enough to implement a lookup table for the log function, so I chosed to link the double precision liba. That library also takes a lot of flash space.

Otherwise, I never tried the PICs, the lack of native C support was always a major turnoff.

[Iain McNeill]

Nice idea, I like it. I think the fan status indicators could be clearer, maybe some display real estate of their own with speed indication?

When it comes to meters you need it all; instantaneous, ppm, fast rms, slow rms.

The temperature sensors are effective for CPU IO but you must have thought of using the temp diodes on ThermalTrack type output devices to sense temperature on a LSAD. How about even bringing bias control under this controller?

[Bonsai]

Are you guys putting your uControllers into power down mode when the y finish a task - i.e. clock stopped? I guess if you are driving a VU meter or something like that it may not be possible. What about noise.

I do power on-off, in-rush current limmiting, clip left and right, over temp and DC offset. Written in C (Keil demo version) and all fits in 700 bytes. Controller is put into full power down mode once a task is completed. I'm using an LPC922 from Philips.

[GK]

Originally Posted by G.K.

Anyway, as far as display ascetics go, the

LOL. That should be asthetics. Geez I hate the MS Word spell checker.

I use this PIC C compiler (employer payed for it):
http://www.ccsinfo.com/product_info....ts_id=PCW_full

[syn08]

Originally Posted by Bonsai

Are you guys putting your uControllers into power down mode when the y finish a task - i.e. clock stopped? I guess if you are driving a VU meter or something like that it may not be possible. What about noise.

I do power on-off, in-rush current limmiting, clip left and right, over temp and DC offset. Written in C (Keil demo version) and all fits in 700 bytes. Controller is put into full power down mode once a task is completed. I'm using an LPC922 from Philips.

I don't power down the CPU. Noise impact is zero - the whole controller board is powered from a separate power supply, no ground loops.

700bytes?? It's my turn to be surprised. I don't know anything about the Philips CPU's, though.

AVR cores are RISC, hence they tend to have larger code sizes. A zero code lines program (only the stub and libc libraries) takes, if memory serves, about 6k of flash.

I'm using only free tools, AVR Studio and WinAVR.

[syn08]

Originally Posted by Iain McNeill

Nice idea, I like it. I think the fan status indicators could be clearer, maybe some display real estate of their own with speed indication?

When it comes to meters you need it all; instantaneous, ppm, fast rms, slow rms.

The temperature sensors are effective for CPU IO but you must have thought of using the temp diodes on ThermalTrack type output devices to sense temperature on a LSAD. How about even bringing bias control under this controller?

I have considered using the thermal track diodes as temperature sensors. That would work great, however I am to lazy to linearize and calibrate a diode temperature response, either in hardware or software. The DS18S20 is so much easy to use! Also, YAP 2.1 is a MOSFET project, so no thermal track diodes around...

A bias controller is something that's really worth considering, as a separate project, on a little board with an ATTiny controller. Time permitting, I'll look into that. My guts are telling me it's not as simple as it looks at the first glance, in particular if no other hardware beyond the micro is involved.