ES9018 I2C controller

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
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.

Do you have links to anyone using your controller with a TPA Buffalo DAC?

I did not think that this would be a problem, it never occured to me that this was anything other than fun DIY.

Could your code be used on an arduino in the background and the GUI related stuff be run on a rasp pi with a cool display?
Are you thinking of releasing a controller solution with more programming space and easy programming from a computer (usb instead of the FDTI cable)?

I must say that I dont think anyone wants to step on anyones toes. Many people like me have lots of ideas and throw them out like crazy, then someone takes the idea and makes it a reality (wich is partly the case with this project). The LCDuino was not considered by me due to it`s somewhat limited programming interface and that there are lots of other arduino incarnations out there but I still have not seen a 20x4 LCD piggyback solution.

Edit: I would love to see a open source LCDuino buffalo control solution using the standard LCDuino with a 16x2 display. That way I could keep the display on both my units (DAC and Beta22 / Alpha20 Headphone amp / Preamp) identical.
 
Last edited:
Do you have links to anyone using your controller with a TPA Buffalo DAC?

I don't.

I did not think that this would be a problem, it never occured to me that this was anything other than fun DIY.

its good karma to support the authors and it helps offset the fairly large development costs (mouser, etc) that we put into this. the code is free, the design is free (all for non-commercial use). all that we'd ask is that, if the project is close enough, that you don't reinvent the wheel and leverage an already proven and reliable product.

Could your code be used on an arduino in the background and the GUI related stuff be run on a rasp pi with a cool display?

I think that's the best way to do any 'app', these days. the argument for a rasp pi 'ingredient' (haha, sorry) is too compelling. here's a stupid little display (attached photo) that is under $20 and could possibly be made useful if the fonts and widgets are kept minimal, so that even cheap composite will render things well enough. the pi board can run x-windows and you get fonts, colors, shapes, menus, all that stuff for free. and you also get an onboard serial port for free. plus some other ports.

you get a mature networking stack, tcp/ip security, webserver, cgi, you name it.

yes, I think any serious app should be thought of as a client/server pair with a linux front end on a cheapie board and possibly a controller back-end that does timing crititical stuff AND abstracts the vendor-specific stuff to some more abstract interface (my pref is serial and even more so, typeable ascii, if possible).


Are you thinking of releasing a controller solution with more programming space and easy programming from a computer (usb instead of the FDTI cable)?

I like the arduino system for what it is. I don't like having usb onboard anymore since I've had to use the raw uart (as a serial port, with raw ttl) and having the usb ftdi stuff is not needed and might even be in the way. if the user wants to adapt ttl to usb, let that happen outside the box. you can choose that way. if you embed it, you are stuck with it. having things talk over serial is a big plus to me and I would not want to clog that port with a usb dongle. I also like xbees. but again, outside the box is best. send ttl out to the box and adapt that to the various things you might need.

Edit: I would love to see a open source LCDuino buffalo control solution using the standard LCDuino with a 16x2 display. That way I could keep the display on both my units (DAC and Beta22 / Alpha20 Headphone amp / Preamp) identical.

the direction I'm going in for the current lcduino firmware is split client/server. my new vol control stuff is not going to be onboard the display system, its going to be its own embedded arduino and it will be a slave that abstracts the vendor crap^H^H^H^Hstuff and presents a more usable and friendly interface, over serial.

my suggestion is to also follow that style. create an arduino (328 is overkill but it has a lot going for it, to keep with the 328 skinnydip28 chip) that sits on the serial port, accepts user config commands and then 'does the vendor equiv' by sending i2c or spi or whatever to the dac chip.

then, that serial interface is the way you write control/display apps on the lcduino. lcduino then becomes a fancy terminal, sort of ;) it will have some more room inside to be more of that generic control interface, and the serial thing at the other end will handle all the vendor chip programming.

what that also buys you is that you can have a 'simple' client (like lcduino) or an advanced client (rasp pi) and they would both use the same serial interface and talk to the same embedded 'proxy' arduino chip.

anyway, my 3.14 cents worth for today ;)
 

Attachments

  • 8013333386_087eb3f9e1_z.jpg
    8013333386_087eb3f9e1_z.jpg
    200 KB · Views: 512
Last edited:
So what you are saying is that you could get together and revamp lcduino maybe ?:cool:

I do plan to have the lcduino become more generalized and less of a direct device manager. but to do that, requires that another controller be there, somewhere, to handle the local board specific stuff.

in its v1.x state, its an all-in-1 system and its pretty maxed out, already, in code space. the only way forward, really, was to split out the functions and 'go distributed'.

so, if other projects adapt that client/server architecture, its very possible to plug and play various clients (lcduino can be one) and servers (an arduino translator for the buffalo style chips could be one) and be able to choose the interface that makes the most sense for the particular build (in some cases, NO display or buttons at all; as a lot of people are going 'all web' or all phone).
 
its good karma to support the authors and it helps offset the fairly large development costs (mouser, etc) that we put into this. the code is free, the design is free (all for non-commercial use). all that we'd ask is that, if the project is close enough, that you don't reinvent the wheel and leverage an already proven and reliable product.
I own an arduino and have a modified version of hifiduino for controlling my DAC, but I do not like the way that all connections to it are made. Using shields could provide some solution to it, but then it becomes to bulky for me. I have had several discusses with Gwikse about this in the past, so that's why I decided to build a solution myself and for anyone that is interested.

It's not about reinventing the wheel. Gwikse pointed out the lcduino to me, but I still have not checked it out. Besides that it is more fun for me to design it myself to suit my needs. That's the essence of an DIY project to me. I think that it is rather strange to more or less ask me not to proceed with it because it already exists. :confused: That's the same as asking anyone not to design a DAC or amplifier because there are already proven and reliable designs.
btw I did already support AMB by buying two sigma 11 PCBs. There great supplies and the lcduino is probably too, but like I said. I'd rather design it myself, because it's fun to me and it's also good for expanding my knowledge by digging into matters like AVR's, programmers, I2C, SPI etc etc. :)
 
another really big win you get by separating the device from the UI is that, last time I checked, the ESS high end stuff was still not open and the specs were not open. if you 'wrap' that vendor stuff in user friendly serial ascii, anyone is free to talk to that instead (as a proxy) and they don't have to sign any NDA or anything with ESS.

I think that was the original turn-of for me about ESS chips. you could not really release free software about their stuff.

BUT, if some chip is fully front-ending their services, I can't see how they'd be able to say no to that new ascii interface.
 
I would rather have a simple display in one unit (preforably a noritake VFD HD44780 compatible, due to poor eyesight). I love the idea of having a master unit and the others just having a controller with no display if I understand you correctly but then I dont need a LCDuino (I can just use an arduino wich has more options to link with the master controller).

The more elaborate display I would prefer to have on my smartphone (android or iphone) and use it as a remote.

Also I think you misunderstood me, I was not asking about using your entire code, only the IR learn function. So I would think that since you are so against this controller the right way to go on is to write code for that functionality over again from scratch.
And btw. the "redo" as you called it is actually a mere coinsidense, the PE chip was used due to the fact that it is in use on the lcdIOextender from elektrofunLTD and since it was in use there it became a natural choice to use in other parts of the project as well since the library could then be used for several functions.
If the LCDuino was ready to run a TPA buffalo dac I would have chosen it a long time ago. If code becomes awailable I might buy two of them, one for the Pre/head amp and one for the DAC. But as it stands now I will stay with my DACT attenuator and manual input selector on the Pre/Head amp until I see a solution that suits my needs or come up with one on my own.
 
well, again, if your goal is to help the ess chips be 'managed' and have a front end, I think there's a good solution that I outlined that uses existing technology and adds to it in a non-overlapping way. I would be willing to help and contribute to such a project.

if, however, your intent is to reimplement the stuff that amb and I already did and made available to the community, then I have no interest in helping the project or giving code or support to it.

I think there is space enough for all and that parts of the solution still exist and can be implemented in a complementary way. I'd like to suggest that way forward, if I may.
 
The more elaborate display I would prefer to have on my smartphone (android or iphone) and use it as a remote.

I think that's the direction the state of the art is going in. more and more, its mobile web as the first thought about 'remote control'. I still like IR and other methods, but any new development, imho, should include a 'web story' as well.

the trick is to plan for this from the very start, not shoe-horn it in later on.
 
if, however, your intent is to reimplement the stuff that amb and I already did and made available to the community, then I have no interest in helping the project or giving code or support to it.
Not at all, I was unaware of the most features that come with the the lcduino until today. :)

I think that's the direction the state of the art is going in. more and more, its mobile web as the first thought about 'remote control'. I still like IR and other methods, but any new development, imho, should include a 'web story' as well.

the trick is to plan for this from the very start, not shoe-horn it in later on.
I agree, but without a descent app it would be pretty useless. For the moment it's to time consuming for me to dig into the programming languages for android or iOS apps. I expect the Ethernet modules I ordered to arrive very soon, so that would be a good trigger to soon start learning how to program those apps.
 
my suggestion is to also follow that style. create an arduino (328 is overkill but it has a lot going for it, to keep with the 328 skinnydip28 chip) that sits on the serial port, accepts user config commands and then 'does the vendor equiv' by sending i2c or spi or whatever to the dac chip.

then, that serial interface is the way you write control/display apps on the lcduino. lcduino then becomes a fancy terminal, sort of ;) it will have some more room inside to be more of that generic control interface, and the serial thing at the other end will handle all the vendor chip programming.


I have implemented this approach with my hifiduino. I wrote a serial command driver in .net and used it to control volume, input selection, mute on my dcb1 buffer. I also wrote a windows app and web app that uses the command driver. I also refactored the hifiduino code to make it more object oriented and hardware independant. My next step is to include the i2c sabre commands.

My refactored code makes it easier to implement a front end. I already tested with web, windows, IR, HW etc.... Runs nicely on windows 7 but I am currently porting to windows 8 for the new windows phone & tablets coming out soon.

I will be making the project available when I am done testing.

regards.
 
fwiw, I have a cheater bit of code that runs on linux and fakes out a volume control in the mixer interface (alsa). what this buys you is standard volume control, for free, via almost any android or iphone app that talks remotely to the alsa sound system. I can run mpd on linux (for audio playback) and have it route to the 'fake' virtual volume control. that means any client that talks to mpd gets to talk to the fake volume slider.

then, you create a comm link via app code from that fake vol slider to a serial (usb) port on your pc. that's the thing that spits out vol-change commands to some real world device; in my case, the lcduino or the cirrus front-end arduino.

the result is that I get vol control (which is what you tend to use the most, in a remote, other than playback control) over 'phones' without doing much effort and without having to be in the middle of supporting THAT in addition to the various other things that make up the system.

beyond simple control of vol, the next step up that is semi easy is a webserver app (I like cgi's) and that would also speak over the serial link. that serial link really does get a lot of use, which is why I believe so strongly in this concept ;)

the ultimate is to have a set of native apps that talk across tcp sockets, that end up talking to the device over serial.

and, in case its not obvious, you could add more serial ports to a pc via usb serial dongles and the pc code would be able to 'notice' more things on the bus, query them and make use of them, possibly even together. THAT, to me, is the power of this 'audio bus' system.

you can see, the view I'm taking is anything but monolithic ;)
 
Corpius, I believe that the default ES9018 setting for "IIR Bandwidth filter" is "Normal" - which is suitable for PCM input.
But when the DAC is in DSD mode, apparently it's optimal for the IIR Bandwidth filter setting to be 50k, 60k, or 70k.

Would you possibly consider adding the feature that whenever DSD-mode is active, the IIR Bandwidth filter setting is automatically changed to one of these higher values?
Which of the 3 values? Perhaps there could be a menu item to choose - but of course, this menu item would apply only to the situation where the ES9018 is in DSD-mode.
 
Corpius, I believe that the default ES9018 setting for "IIR Bandwidth filter" is "Normal" - which is suitable for PCM input.
But when the DAC is in DSD mode, apparently it's optimal for the IIR Bandwidth filter setting to be 50k, 60k, or 70k.

Would you possibly consider adding the feature that whenever DSD-mode is active, the IIR Bandwidth filter setting is automatically changed to one of these higher values?
Which of the 3 values? Perhaps there could be a menu item to choose - but of course, this menu item would apply only to the situation where the ES9018 is in DSD-mode.

That setting is in the advanced menu. When you have set it on the correct input it will be stored to that input.
 
Member
Joined 2009
Paid Member
Corpius, I believe that the default ES9018 setting for "IIR Bandwidth filter" is "Normal" - which is suitable for PCM input.
But when the DAC is in DSD mode, apparently it's optimal for the IIR Bandwidth filter setting to be 50k, 60k, or 70k.

Would you possibly consider adding the feature that whenever DSD-mode is active, the IIR Bandwidth filter setting is automatically changed to one of these higher values?
Which of the 3 values? Perhaps there could be a menu item to choose - but of course, this menu item would apply only to the situation where the ES9018 is in DSD-mode.

+1
 
Corpius, I believe that the default ES9018 setting for "IIR Bandwidth filter" is "Normal" - which is suitable for PCM input.
But when the DAC is in DSD mode, apparently it's optimal for the IIR Bandwidth filter setting to be 50k, 60k, or 70k.

Would you possibly consider adding the feature that whenever DSD-mode is active, the IIR Bandwidth filter setting is automatically changed to one of these higher values?
Which of the 3 values? Perhaps there could be a menu item to choose - but of course, this menu item would apply only to the situation where the ES9018 is in DSD-mode.
Like gwikse said, once you have set the `IRR Bandwidth filter´ it is saved to the EEPROM and linked to the input. Every time when when the input is selected it will read all settings and set it to the last saved configuration. It could be changed that changed that only 50k, 60k, or 70k can be chooses when the DAC is in DSD mode, but I do not see any benefits to this approach.
 
The way the code is written allows selecting up to 6 different inputs.
- In can be easily changed to reduce the number of available inputs and with some additional changes, increased to more than 6.
- The base code allows changing any of the parameters for the DAC (IIR, fir, DPLL, etc) and it will remember those parameters in eeprom
- The base code does not have any code to for example actuate a relay but can be easily added (as some have already done)
- When you change a source from PCM to DSD, you typically switch the input and by switching the input, all the parameters will be changed to what you saved.
- In the case that the same source can handle both PCM and DSD, I believe the status register can tell you (don't remember 100%, have to check it out). In such case, you can automatically adjust the IIR filter (this part is not in the base code)
 
- The base code allows changing any of the parameters for the DAC (IIR, fir, DPLL, etc) and it will remember those parameters in eeprom
- The base code does not have any code to for example actuate a relay but can be easily added (as some have already done))
Like me :)

- In the case that the same source can handle both PCM and DSD, I believe the status register can tell you (don't remember 100%, have to check it out). In such case, you can automatically adjust the IIR filter (this part is not in the base code)
I do not own any DSD source that could also switch to output PCM, so I can not check it out. Curious to hear what it actually does. Adapting the base code to automatically adjust the IIR filter in such a cases can be easily be done
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.