[amb]

I plan to do that with my future desktop DAC.

 

[linuxworks]

 
Quote:

I would like to see someone integrate this into a DAC and have the display show S/PDIF info like bit rate, sample rate, bit depth, number of channels, etc.

this isn't typical dac info, though.  I've looked into this and you either have to talk to the dac chip at a very low level (most don't even give you this info via its 'mgmt interface') OR you have to spy on the bits, directly, and glean it from the spdif stream (a circuit I used to build about 15 yrs ago had a hardware GAL chip that would pick out the subcode bits and show things that dacs, today, still don't show).
 
samplerate is not too hard and its even possible to hack it based on a freq-to-voltage conversion (roughly).  bit depth is often just 'said' to be 24 from the dac even if the native stream is not 24.  channels is not directly viewable via dacs (especially multichannel things like dd5.1 and dts).  dacs tend to say its PCM or perhaps DD or DTS but it won't go deeper than that (2ch stereo dacs, that is).  multichannel home theater dacs tend not to be diy friendly (at all).
 
one idea is to have a pc side 'beside' the dac and listen in on the stream and then have IT break out the spdif protocol.  not a very clean solution though.
 
I do want to have at least a samplerate display so I can see when 44.1 comes out vs 48.  that much I plan to do via the frequency measure hack.  the rest is not so easily do-able with standard dac chips.

 

[dgbiker1]

Very cool! I used an Arduino w/ LCD a couple years ago when I built my Opus DAC for switching inputs/outputs and controlling the lighting. Used a blackberry trackball for navigation.

 

[TheShaman]

[Removed - cross-posted accidentaly]

 

[particleman14]

Hey guys check this out...
 
The alpha-10 is getting close to completion.  it has been a long time coming.. These are going to be available soon...

 

[ujamerstand]

I like how there is just one random tube lying around with all the digital electronics. 

 

[chryses]

Has anyone used one of the 2x16 Newhaven OLED character displays (e.g., Mouser Part No: 763-NHD-0216KZW-AY5)?  Anyone know if these are "plug-and-play" compatible with the LCDuino?

 

[ShinyFalcon]

Looks good. The OLED displays has some unused pins (contrast, backlight), and uses about 10mA more current. I might try one out...

 

[linuxworks]

there does not seem to be any contrast adjustment (that won't hurt and actually its a good thing you don't need it anymore). there is not any pin 15,16 which is used for backlight (brightness) control. but unlike the vfd compatible displays, there does not seem to be a message-type you can send the display to vary its brightness.
 
vfd's have 4 levels of brightness and you vary them via a message you send to the vfd. lcd's vary their brightness via analog voltage on the 15,16 pins. but the oled module *seems* like it has a fixed brightness. and even worse, the spec sheet talks about burn-in and so you have to be careful you don't leave the pattern on the screen!
 
the current shipping lcduino code is 'vfd-friendly' in that if you select auto-off display mode, it will completely darken the display after inactivity; not just turn the backlight off but literally erasing the screen after the delay. if you used this mode, you could avoid the burn-in problem. I might order one of these to try it, but not real happy about the price premium they charge.
 
also, there are r/g/b lcd displays that use rgb leds with 4 wires as the backlight. with those, you can choose your exact color. I've played with those and it can be fun to pick your exact foreground color that way. the lcduino only has support for 1 pwm line (stock) but you could tap into 2 more on the board and write custom firmware to vary the r/g/b values on their own and color-mix your own display. even change colors based on some state or mode that the device is in.

 

[chryses]

Yeah, I'm not terribly excited about the price either.  But the display does look extremely crisp, so I probably will give it try.  Have to build my LCDuino first, but will report back.

 

[ShinyFalcon]

If the OLED is similar to the ones used in the Sansa clip, the background will be pitch black. All you'll see in the dark is the colored text, hopefully no light bleeding. Should be a joy to use, but the firmware will need to be updated to include code to blank out the screen.

 

[linuxworks]

Quote:

Yeah, I'm not terribly excited about the price either.  But the display does look extremely crisp, so I probably will give it try.  Have to build my LCDuino first, but will report back.

make sure it has the same hole pattern size (75mm or something like that) and that the 14 or so pins at the top are the same spacing as normal 16x2 lcd's.  there is at least 1 model that looks like a perfect drop-in.
 
I will probably try one to see what its all about.  I have some VFD's that work pretty well (high current though; need a separate 5v for them) and of course most lcd's work just fine.
 

 

[linuxworks]

Quote:

If the OLED is similar to the ones used in the Sansa clip, the background will be pitch black. All you'll see in the dark is the colored text, hopefully no light bleeding. Should be a joy to use, but the firmware will need to be updated to include code to blank out the screen.

no, that code is there fine in the shipping v1.0 lcduinos.  there are 3 modes of backlight: full-on, auto-fade from hi to low; auto-shutoff.
 
in auto-shutoff, it turns the backlight off (which does nothing to this oled) but it also DOES erase every char on the display (writes space chars out to whole display).  when a user event happens and if its in this black-out mode, it repaints the whole screen and resets the timer for screen blanking.  it all works fine.  it was added to support VFD's and so the same thing is here for OLEDs, too.  think of it as an anti-screen burn setting.
 
note that if you picked that middle mode (auto-fade) it won't appear to do anything on vfd's or oled's.  you'll get full brightness no matter what.