Author Topic: tiny OLED 128x64 calendar display (arduino) (Read 105901 times)

zapta · « **Reply #25 on:** May 31, 2015, 12:44:05 am »

I just posted on thingieverse a model of mounting posts for these OLED displays. I made them from PLA and 'riveted' using the side of a hot iron. It's easier that my previous method of using header pin and soldering a small wire ring at the top.

http://www.thingiverse.com/thing:856970

Yansi · « **Reply #26 on:** May 31, 2015, 01:44:44 am »

Wouldn't it be better to source somewhere bare displays, find suitable FPC connectors and mount it right on your PCB? If it is ever possible to source these displays as a bare parts for a reasonable price, without those silly shields... I've already encountered a situation where some part soldered on a shield witch a bunch of other stuff there was surprisingly cheaper, than bare chips...

zapta · « **Reply #27 on:** May 31, 2015, 02:00:08 am »

Quote from: Yansi on May 31, 2015, 01:44:44 am

Wouldn't it be better to source somewhere bare displays, find suitable FPC connectors and mount it right on your PCB? If it is ever possible to source these displays as a bare parts for a reasonable price, without those silly shields... I've already encountered a situation where some part soldered on a shield witch a bunch of other stuff there was surprisingly cheaper, than bare chips...

I think it's possible to source the 'glass' but it will not save you much. BTW, it doesn't use a connector, just flex that is soldered to the board. I de/soldered a few of those, very doable. And the glad is attached with a thin double take. I saw once a data sheet of the glass, don't remember where though.

linux-works · « **Reply #28 on:** May 31, 2015, 03:27:32 am »

plastic welded legs. like it!

better: some kind of rubber that takes a bit of shock and makes the module more user-proof (install/removals, etc).

maybe the right density of foam, like weatherstripping. should be strong enough to hold but removable without too much force.

I want to be able to raise, lower mine, though. I can see value in being able to match height of buttons and displays with front panels. so, longer male headers from the module, and some kind of pass-thru female sockets that would solder on the pcb below but let pins pass thru if you really needed that level of adjustment. that way, you can commit to cutting pins to length much later in the project.

otoh, you could adjust height by laying this module on a small 'bed' pcb that has outside holes on the corners that are bigger, robust and not too close to any glass. if you secure the module to the bed, the bed could be lowered or raised to-height, as desired, and it can be treated a lot more like a strong part than the pcb carrier that the oled is currently mounted to.

it almost argues for not using their carrier and doing you own, but I don't love having to get into -that- kind of distraction. I just want to use the darned thing. but it does have to be strong enough to be in the real world and a good mounting story is needed, at least for me.

linux-works · « **Reply #29 on:** June 13, 2015, 12:38:44 am »

now, I'm using this display for a small handheld RF remote control:

arduino, xbee, oled and eventually some battery and box. looking into lipo batteries and maybe a Qi coil charging system.

this remote does work right now, too. controls the volume on my DIY preamp

this is with the smaller .96" oled, not the bigger 1.3" one. also I rotated the display 180 since it was the only way I could fit all this on that small board. when I used u8glib to rotate the display, some pixes were shifted and so the same code did NOT run perfectly; I had to add 3px to the x-axis to make this work (not sure if a bug in the module or the u8glib). at any rate, it works after adding 3pixels to the x values where you draw, when upside down.

I do really like those industrial angle buttons. they should last a nice long time and be relatively trouble free.

MLXXXp · « **Reply #30 on:** June 13, 2015, 02:08:43 am »

Quote from: Yansi on May 31, 2015, 01:44:44 am

If it is ever possible to source these displays as a bare parts for a reasonable price, without those silly shields...

http://www.buydisplay.com/default/oled-display

linux-works · « **Reply #31 on:** June 14, 2015, 07:37:26 pm »

and more progress again today:

I'm playing with the idea of talking to multiple boxes by directing the commands to the right 'box address' (using a user-defined protocol I threw together).

its hard-coded right now but I'd like it do be very dynamic and have it learn the kinds of boxes out there (on my net), learn what each box has controls for and then it can display the edit-page for the control types that box supports. ideally, no new code should have to be written if some new box appears that supports the control prims that the remote understands.

and at this point, I'm already 95% full for the 30k arduino chips. I may have to look into the next bigger cpu, real soon.

linux-works · « **Reply #32 on:** June 19, 2015, 04:33:23 pm »

stepwise refinement: now added a LiPo battery and recharger circuit (adafruit, taking the easy way out on this one, lol):

its still hack-mounted and does not have a case, but its enough to use and develop software on.

I also bought a Qi charging coil and board kit; so that will probably be the next upgrade before I can start to think about a box for the remote.

kind of funny how I bought this display, toyed around with it, made a calendar and now I'm off on some totally unrelated tangent, just because I saw a neat use for this little display

zapta · « **Reply #33 on:** June 21, 2015, 02:50:01 pm »

Quote from: linux-works on June 19, 2015, 04:33:23 pm

I also bought a Qi charging coil and board kit; so that will probably be the next upgrade before I can start to think about a box for the remote.

You can also use conductive wire free charging base. They may be cheaper and more efficient. one simple contact geometry is used by those restaurant pager/coaster and it even allows to stack multiple units on the same charger.

There are also contact geometries that allow free rotation and free position but they are more involved.

BTW, what battery life time do you get?

Edit: this stack charger design fit well the Sick Of Baige case design if the make the top and bottom screws at the right shape and have the spacers pressed against power pads on the PCB.

linux-works · « **Reply #34 on:** June 21, 2015, 05:50:41 pm »

stacked charging; interesting!

I will play with Qi since I'm fascinated by the inductive power transfer concept. it may not be the best thing but I'm gonig to live with it for a while and see what its like. if the execution is poor, then I'll abandon it but I want to experience it first-hand before I judge it.

I don't know what the battery life is yet. I do have a dc load and I'll try to do some current analysis in its present form (which is not at all structured to be battery efficient, in the code) but when I do that update pass, I'll see how long it can run with display, with display timing out, with xbee on and with xbee put to sleep.

btw, I cased it up last nite (late nite at Tech Shop; what a way to spend saturday night, lol):

yes, its thick as a brick (hahaha)

but I don't feel bad, its using all off the shelf parts, no major size reduction was attempted and lots of thick 1/8" plastic layers were needed to hold it the way its currently built. otoh, its hard to lose a thick brick like this. jethro tull might be proud

this is the first time I'm seeing the white display with an orange 'nixie' window over it. I like it. wish I could buy a true yellow/amber oled display instead of blue and white.

zapta · « **Reply #35 on:** June 21, 2015, 06:42:37 pm »

It looks better and better ;-)

Do you turn off the display when not in use to save battery? Does the inductive charge receiver provides you with battery fuel guage?

BTW, you can control the intensity/current of the display. It has a reference resistor that controls that current. IIRC it is discussed in the SSD1306 datasheet.

I had to do in the past battery optimization for mobile devices. Background radio activity is one of the things you want to look for. I used this Arduino based PowerPlay device, it outputs regulated 1 cell voltage and tracks the consumed charge over time. It performs basic analysis itself (average current, number of wakes, etc) and also provides raw data to an optional computer for additional analysis.

https://github.com/zapta/power-monitors#power-play-38v

linux-works · « **Reply #36 on:** June 21, 2015, 07:10:52 pm »

thanks man!

I do have a screen timeout function. for now, I press the green button on the right to toggle screen-on and screen-auto-timeout. will probably think of a better function for that green button later on.

I have not tried varying the intensity. hmmm, new idea: photocell controlled intensity. damn, have to stop adding feature creep to it

I do plan to add a battery gauge. definitely needed. I wonder if the a/d on the arduino may be enough to self-read the voltage? if not, what would be a good way for the system to measure its remaining run-time?

oh, I see that there is a power play thing. I'll read up on that.

the xbee is not put into hiber mode yet but its planned, for sure. right now, the xbee in the remote is the initiator, so it can power itself down when the user has nothing to 'say'. but later, I intend this to also receive datagrams, so not sure yet how to structure the current consumption.

I'm using the adafruit charge coil and circuit so I'll ask them if there are management metrics that can be gotton from it. I suspect not, since they'd probably list it if it was there, but I'll find out.

zapta · « **Reply #37 on:** June 21, 2015, 07:40:11 pm »

Regarding fuel guage, the power play uses the LTC2943 fuel gauge which uses a continuous bidirectional coulomb counter (better for long term integration) and has a I2C interface. I am sure there are many other fuel gauges, possibly even with charger function integrated.

http://www.linear.com/product/LTC2943

Possibly cutting the power to the OLED display will result in lower standby current that just turning all the pixels off. It has for example an internal capacitor based DC/DC that will keep working and consume current.

Regarding the yellow color you mentioned, I saw similar OLED display where the top portion of the display is yellow, to distinguish the status line from the rest of the display.

http://www.aliexpress.com/item/Yellow-Blue-0-96-SPI-Serial-128X64-OLED-LCD-LED-Display-Module-for-Arduino-51-Series/1669384921.html

linux-works · « **Reply #38 on:** June 21, 2015, 08:05:35 pm »

I have seen those top-band oleds and some buyers got them thinking they were settable but were upset to find the 2 colors are fixed. if you can structure your UI to that, it might be ok. I do like amber on black (like old vt220's) and I run my xterms that way, too

I'll look into that fuel gauge chip. that's new stuff to me, but if its i2c, that's ideal. I will look into removing power from the display - but - isn't there some init that has to happen (at the app or library side) if the display is off? that's time overhead if the screen has to come on and something has to be written to it, yes?

I'm currently erasing the screen after a timeout and its a funny effect, since I have the screen 180 mounted (leads are at the bottom) and the u8glib lets me do that 'rotate' once and all output is all in that mode, after that. I turned that on, but the screen clearing and painting now comes from the bottom up

its kind of funny since we're mostly used to seeing draws happen from top-down. the erase if semi-fast and the draw is just barely acceptable (when there are bitmaps on the screen). the i2c 'simple' displays are actually not very fast. I will try the spi version and if I can afford the pins, maybe convert over to it.

re: battery gauge; I wonder if its even worth the screen space, cpu time and chip space, given how this thing is designed to be used. its not like a phone that will be out with you and needs to have a good 'away' run time. a remote control for a home audio/video system would rarely leave the home and would be used in very short bursts or short durations. when not being used, it sits on the charging pad, so its almost never going to even get close to wearing down the battery in real use. IF you use a charging pad or cradle, and I'm trying to see if that's a real workable solution.

zapta · « **Reply #39 on:** June 21, 2015, 09:16:36 pm »

The SPI will be much faster with no noticeable refresh 'wave'. You right about the initialization, it may be required after reapplying power.

If you don't need an accurate fuel accurate, giving a rough estimation based on the battery voltage should be fine, and if it's only for you, you can show in it volts ;-)

You may need also to have low voltage cutoff somehow to you don't over drain the battery.

linux-works · « **Reply #40 on:** June 21, 2015, 09:43:18 pm »

I'm not sure yet what to do about the battery running down. the adafruit circuit is supposed to fully manage things on charging and the battery should auto-off itself once it gets below its cutoff. the arduino will just lose power and black out (not brown out since I think the lipoly battery is auto-off). but I have not used lipoly before and this is my first time with incircuit rechargeables.

I don't know if I have to do anything special on the arduino side. its not like I have to sync a database as I see power about to fail. and since my data packets are checksummed, even a power loss during an xbee transmit won't ever cause any mistaken command or badness to happen.

putting the xbee into hiber mode (taking a digital pin) is my next move and that should reduce power quite a bit, from what I've read.

I like the idea of a battery meter, but on the other hand, screen real estate is precious and technically there is no need for a gauge, here. but I'll see. the point of a beta (or alpha) is to try out various concepts, throw it against the wall and see what sticks

not literally of course - unless it truly is spaghetti. and my code is NOT spaghetti, lol

ataradov · « **Reply #41 on:** June 21, 2015, 10:04:36 pm »

Quote from: linux-works on June 13, 2015, 12:38:44 am

I do really like those industrial angle buttons. they should last a nice long time and be relatively trouble free.

Do you have a link or a part number for those buttons?

linux-works · « **Reply #42 on:** June 21, 2015, 10:52:47 pm »

angle switches at mouser:

320.22E11BLK

picture shows brown but they are black ('blk').

you like the idea, too, huh?

they feel great. they are not as strong as the usual square style but they are still pretty touch friendly.

ataradov · « **Reply #43 on:** June 21, 2015, 10:56:24 pm »

Thanks.

Mouser shows Customers Also Bought "XB24-AWI-001 Zigbee / 802.15.4 Modules". Did you also buy XBee from them at the same time? Because how many people will buy this button and XBee module?

ralphd · « **Reply #44 on:** June 21, 2015, 10:57:16 pm »

Many of the pro minis have the 2K Arduino bootloader on them. Flashing optiboot or picoboot-arduino will save you 1.5K.
If you enable lto for gcc you'll probably save another couple KB.

linux-works · « **Reply #45 on:** June 22, 2015, 12:16:13 am »

Quote from: ataradov on June 21, 2015, 10:56:24 pm

Thanks.

Mouser shows Customers Also Bought "XB24-AWI-001 Zigbee / 802.15.4 Modules". Did you also buy XBee from them at the same time? Because how many people will buy this button and XBee module?

first, 'doh!'

second, 'lol'.

third, 'fixed'.

linux-works · « **Reply #46 on:** June 23, 2015, 03:45:23 pm »

got a new Qi charging base that tilts and has 3 coils:

also replaced the front with a smoked/bronze plastic panel, which is partially see-thru. has more geek-appeal

zapta · « **Reply #47 on:** June 23, 2015, 03:49:27 pm »

This deserves to show up on hackaday. You can send a short description to tips@hackaday.com

linux-works · « **Reply #48 on:** June 23, 2015, 04:00:57 pm »

thanks, man

I do intend to submit it. I guess I have 'never quite done' symdrome, which many of us can relate to. I can'te quite submit some partial stuff until I see enough end-to-end control working, and with enough variety of target boxes. but you are right, I should define an end point for when its good enough and then submit it. probably should put the code on github first, which I do plan to get to very shortly.

linux-works · « **Reply #49 on:** June 28, 2015, 05:31:43 pm »

this display is now my go-to display of choice for small jobs. here, I'm using it to display the DAC sample rate (word clock from the spdif receiver in the DAC):

there is a freq-counter software library and I'm using that to get the SR freq.

the front panel will have to be redone to allow for the green board, now

lol, just realized I left the little screen protector plastic on. that's what the green 'flag' in the photo is.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: tiny OLED 128x64 calendar display (arduino) (Read 105901 times)

Share me