ES9018 I2C controller

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Member
Joined 2006
Paid Member
That is exactly what i want :D



If there is enough interrest I might do so or sell it through my website. First priority is to finish the design and make a prototype.

I could do with some input for the design. I'm thinking of adding some function to put the entire DAC into standby, except for the control unit. When it's in standby it could show the day time, month and year with the backlight turned off. This could be achieved with a little add-on board that houses a logic controlled relais that switches the power to the transformers.
 
I went through some ideas with you earlier. From what I understand now you will link several atmei chips together if there is need for more programming space?

Anyways, each add on board could possibly have its own Atmega328?

Here are some of the things I am thinking of:

1. Networking in order to control the dac from a iphone / android possibly with the same gui as on the 20x4 display but with buttons along the edges to select inputs and the side-buttons on the android/iphone controls volume.

2. IR-learn and blast ability. In order to just use the apple remote for every component on a secondary function on the remote (f. ins pressing center + menu to control the source for the selected input).

3. I2c extender in order to link with other components? (i2c to cat5).

4. 20x4 LCD size PCB with screw holes so that it can be mounted to the rear of the LCD.

5. 12V trigger functionality. I am running the surround reciever through the dac and switch with relays. If the dac had a 12V trigger functionality this could be automated so that when the surround reciever is turned on the relays switch to the reciever.

The functionality you have listed is very good, I can see this being the controller in all my Buffalo/Opus builds.

Edit: more ideas
 
Last edited:
isolator is only required between I2C bus and dac.

not required for other I2C devices.
I can understand that it is not needed for the display and the other ICs that are going to be used within the controller, but using it for the outbreaks seems a good idea to me. Maybe you have a good reason to disagree. If so than please share it with me. :)
 
I went through some ideas with you earlier. From what I understand now you will link several atmei chips together if there is need for more programming space?

Anyways, each add on board could possibly have its own Atmega328?

Here are some of the things I am thinking of:

1. Networking in order to control the dac from a iphone / android possibly with the same gui as on the 20x4 display but with buttons along the edges to select inputs and the side-buttons on the android/iphone controls volume.

2. IR-learn and blast ability. In order to just use the apple remote for every component on a secondary function on the remote (f. ins pressing center + menu to control the source for the selected input).

3. I2c extender in order to link with other components? (i2c to cat5).

4. 20x4 LCD size PCB with screw holes so that it can be mounted to the rear of the LCD.

5. 12V trigger functionality. I am running the surround reciever through the dac and switch with relays. If the dac had a 12V trigger functionality this could be automated so that when the surround reciever is turned on the relays switch to the reciever.

The functionality you have listed is very good, I can see this being the controller in all my Buffalo/Opus builds.

Edit: more ideas
1. We have discussed this before and it is also high on my whish list. There is a W5100 Ethernet module on its way to me. I`m not sure if it will make it into my first prototype. I have still not found any time yet to learn how to write an app for Android. I do not own a Iphone.
2. In my opinion way to complicated to control all sources. I`d rather use a logitech harmony or similar. I have thought of using such a remote for easy access to all functions I`m planning to add, but now I`m using the apple remote and still manage to access all functions. A IR learn function to teach the control how to use any remote would be nice. No idea how difficult this is. When in teaching mode the IR codes could be written to the EEPROM so the controller would reconise them again. I`ll try to find some info on this. :rolleyes:
3. Would you like to control anything outside the chassis with it? There is no real need for an extender as long as all slaves are inside the chassis.
4. The holes already correspond with the ones of the 20x4 LCD :)
5. Isn`t this normally used to switch on a power amp?
 
If there is enough interrest I might do so or sell it through my website. First priority is to finish the design and make a prototype.

I could do with some input for the design. I'm thinking of adding some function to put the entire DAC into standby, except for the control unit. When it's in standby it could show the day time, month and year with the backlight turned off. This could be achieved with a little add-on board that houses a logic controlled relais that switches the power to the transformers.

That is mostly s/w. You could have two cases in the main loop: Active case and Standby case: Active case: power the transformers, program and monitor the DAC; Standby: power off the transformers, skip the DAC code and do the RTC stuff.
 
1. We have discussed this before and it is also high on my whish list. There is a W5100 Ethernet module on its way to me. I`m not sure if it will make it into my first prototype. I have still not found any time yet to learn how to write an app for Android. I do not own a Iphone.
2. In my opinion way to complicated to control all sources. I`d rather use a logitech harmony or similar. I have thought of using such a remote for easy access to all functions I`m planning to add, but now I`m using the apple remote and still manage to access all functions. A IR learn function to teach the control how to use any remote would be nice. No idea how difficult this is. When in teaching mode the IR codes could be written to the EEPROM so the controller would reconise them again. I`ll try to find some info on this. :rolleyes:
3. Would you like to control anything outside the chassis with it? There is no real need for an extender as long as all slaves are inside the chassis.
4. The holes already correspond with the ones of the 20x4 LCD :)
5. Isn`t this normally used to switch on a power amp?

1. Yes I know, I am hoping that others may be interrested in this as well and possibly someone with the knowledge to make apps and what would be nessesary in the dac for it to work. I have seen an app for iphone that control the pins on an arduino controller. Very basic control but perhaps it could be used as a starting point for a more elaborate control system.

2. AMB audio`s lcduino system has this function so perhaps we could use that code as a start point for the ir learn function. Then it would be a matter of adding the ir blast code to each input. But I also use a universal remote atm and it works flawlessly. The only thing is that it is a little complicated for some users. A simpler remote is requested from others here in the household ;)

3. It would be nice to be able to only use one display in the dac chassis and still have a Beta22headphone amp + Alpha20 linestage with delta1+2 input/volume system in a second chassis. It would proborably be easier to have a second controller (LCDuino) to control this, but it would be cool to control both from the same controller. Other uses might be f.ins. light control, doorbell control (when the doorbell rings the dac is muted) etc. Many things you can do with an arduino.

4. Great :D
5. Yes, power amps can be switched on/off by that sort of system. But also other uses like turning on a projector and lowering a motorized projection screen.
 
I
That is mostly s/w. You could have two cases in the main loop: Active case and Standby case: Active case: power the transformers, program and monitor the DAC; Standby: power off the transformers, skip the DAC code and do the RTC stuff.
That is indeed the easiest way to accomplish it. There will also be access to the RTC stuff while the DAC is active.


EDIT:
@ gwikse:
Thanks for pointing me to the lcduino. Perhaps I will add some function to control your curtains too :D
 
Last edited:
...

2. AMB audio`s lcduino system has this function so perhaps we could use that code as a start point for the ir learn function. Then it would be a matter of adding the ir blast code to each input. But I also use a universal remote atm and it works flawlessly. The only thing is that it is a little complicated for some users. A simpler remote is requested from others here in the household ;)

...

Do you have a link to the code?
 
gwikse, thanks!

Other comments:

There is a limit on the size of the code, so not everything can be implemented. I think network takes up a lot of code.

i2c address extender is useful for people that may have more than 2 Sabre, more than 2 OPUS, etc.

That is why I was hoping that it would be possible to link several 328 chips so that some of the code is located on the extention module (network module, external i2c module etc). I have no idea if this is possible but it would be nice if it was possible. Otherwise a different chip (with more memory) would be the way to go imo.
 
How funny is that. I also forgot to add the PCF8574 to the list as well. It is already incorporated, but thanks!

I planned to use the I2C LCD extra IO in combination with the library you mentioned. I am currently using it with my Arduino as well. It doesn't feel slow to me. According to the webpage you where referring to, the library should be almost 5 times faster than the original LCD library.

I have been busy with the design today. It is not final, but this is what I have for so far. The PCF8574 needs to be positioned to a better location and all connections to it are also still not drawn.

Looks very nice. Perhaps an idea to have an adress jumper possibility for the i2c extender?
 
I can understand that it is not needed for the display and the other ICs that are going to be used within the controller, but using it for the outbreaks seems a good idea to me. Maybe you have a good reason to disagree. If so than please share it with me. :)


Galvanic isolation is OK for the digital signal path so you don't want to polute the dac through the I2C connection from a MC. Who cares about noise for the other I2C devices on the bus. Unless I misunderstood what the other devices would be used for. Also, these components tend to be expensive .

regards.
 
Galvanic isolation is OK for the digital signal path so you don't want to polute the dac through the I2C connection from a MC. Who cares about noise for the other I2C devices on the bus. Unless I misunderstood what the other devices would be used for. Also, these components tend to be expensive .

regards.

Also is it not possible to connect more than one slave to the same isolated i2c connection?
 
gwikse, thanks!

Other comments:

There is a limit on the size of the code, so not everything can be implemented. I think network takes up a lot of code.

i2c address extender is useful for people that may have more than 2 Sabre, more than 2 OPUS, etc.
There are ways of dealing with the limited size of the code, but like I wrote I will only use it when I'm able to use it.
I will have a better look at the i2c extender, but there is also limited space on the design :) . I do not want to end up with a very large controller.

That is why I was hoping that it would be possible to link several 328 chips so that some of the code is located on the extention module (network module, external i2c module etc). I have no idea if this is possible but it would be nice if it was possible. Otherwise a different chip (with more memory) would be the way to go imo.
These are indeed some possibilities.

Looks very nice. Perhaps an idea to have an adress jumper possibility for the i2c extender?
Good idea, I'll add it to the list

good point. I don't see any problems as long as the isolated devices share the same grounds.
That is a good and cheap solution. I'll add some extra connectors on the "slave" side of the isolator.
 
Perhaps the code could be altered in order to use the LCDuino system?

A motorized pot driver could perhaps also be an idea to have in this design (thereby having the option to have a pure analog part in the same unit, like f.inst the Alpha20 linestages) or have a proper pot with level indicator on the knob that will turn with the volume?

Edit: also I take it that it is an advantage to use the same port expanders in all the roles you need one in order to save on space in the controller since they will then use the same library?
 
Last edited:
I wonder how this differs from the lcduino.

the lcduino has been out for over a year now, we put a LOT of work into it and its suitable for your project pretty much as-is. why re-invent the hardware?

fwiw, the lcduino can drive 4x20 displays no problem. mounting is a bit tricky as the board is not a 4x20 sized backpack but it can be done if you really want to.

code size is a major problem with 328 arduino. the code in the lcduino1 is pretty much taking up all there is except for the bootloader ;)

at this point, if you plan to do extensive UI stuff, I strongly suggest you go with an arduino mega. I'm considering that, myself, for 'fancy client work'.

back-end work, I still think arduinos are great and I'm now doing a 2cpu system for my cirrus vol control. by taking a lot of the device specific stuff out of the single cpu and moving into a more 'embedded' one, you free up a lot more space in the main 'ui' one.

4x20 displays also are getting closer and closer to small touch screens or even the mini composite vga displays (backup camera displays for cars). a rasp pi and one of those would make a SUPER user interface. and then a back-end arduino can do most of the very low level work that you may not want to do at the linux side.

anyway, what you describe as your project is already done and essentially the lcduino. I think it makes sense not to redo the hardware but to update the firmware and leverage the hardware design that is already deployed, debugged and available for easy purchase.

what I'm saying is that amb and I put a HUGE amount of effort into this with the assumption that the DIY community would be able to just use it and not have to keep re-inventing it. I'd really like to see people use what we put SO much of our spare time into, rather than see yet another controller project (that is nearly identical) fragment the market even more.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.