Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Fewer ducks than estimates indicate.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                       

bistable display calendar/poster

  (+3)
(+3)
  [vote for,
against]

A large black and white display made of a electronic paper surface, and a low powered micro controller server.

Normally it is on 'sleep mode', waking up only on certain 'interrupts' such as light turning on, or timed alarms, or button presses, to update the screen.

Using a low powered communication chip, such as wifi, or bluetooth, it should automagically connect and sync to your laptop, phone or a external web server.

To be future proofed, it should read data only in XML format, and it shouldn't be smarter than a semi dumb terminal (give just enough intelligence to do simple no syncing screen updates like updating clocks, or image changing).

To save power, it should be in sleep mode most of the time, and only update every time the lights is on, or a sound is made. (Perhaps as a courtesy, a small LCD screen should blink to indicate if the device is updating the time or not.)

This will be useful for students, businessmen, and cubical workers.

mofosyne, Jan 03 2011

http://blog.jclark....10/12/microxml.html [Ian Tindale, Jan 03 2011]

How do you like them apples ? http://en.wikipedia...ou_like_them_apples
Well, not much, actually ... [8th of 7, Jan 03 2011]

[link]






       Don’t restrict it to XML if you intend to future proof it. It’s highly likely that the dominant use of XML won’t stay as recognisable XML 1.0 in the future. At the moment, there are many viable alternatives that skirt round the inefficiency and high overhead of present XML, such as JSON (which is the most prevalent alternative to survive), but even that has trended toward specialisation to hold object hierarchies and away from document engineering.   

       One of the things that annoy me about people on the halfbakery trying to use their fake XML markup is that they get it utterly wrong (and invalid). However, the way in which they get it wrong is interestingly consistent in two main ways. First, they seem unaware that the first token after the < is the identifier of the element (in other words, the “tag” name) but after the first space, the tag name ends, and the parser is now looking for attribute identifiers. If it finds an attribute, it expects an equals sign, then a value to be present inside a pair of quotes. For example:   

       <made up fake xml tag to indicate a mode of delivery>Hello, I’m speaking in some other voice right now, so leave a message and when I return to normal I’ll ignore it</mufxttiamod>   

       The <made> is the element name, which contains a few invalid badly written attributes, such as up, fake, xml, tag, etc and none of them have their equals sign and none of them have their values, and none of those values are in quotes, so it’s all invalid. Then there’s a missing closing tag to the element (there should be a </made> at the end). But there is this weird </mufxttiamod> instead, which never had an opening tag to it.   

       So you can see, XML is not intuitively the way people expect it to be designed. The closing tag design choice could have (apparently) easily gone the other way, and at one point they were considering having it just close with a </>. I think this would have been far better. But one of the fundamental problems with it, in my opinion, is that it is inherently and invariably a container format, and there’s no way round that (if you disclude empty elements). Sometimes, outside of object serialisation and hierarchy wrapping, we need it to not contain, and for ease of use, I think most people don’t think that way so easily as we’d like to think, in a document engineering context.
Ian Tindale, Jan 03 2011
  

       Why would you want to bist a dispay?
MaxwellBuchanan, Jan 03 2011
  

       Well, you wouldn’t want to ast it, or monost it.
Ian Tindale, Jan 03 2011
  

       [+] but rather complicated for an e-paper calendar. Those cheap little LCD clocks back in the '70s ran for years without changing the battery and that included the electronic timekeeping circuitry. You'd probably use more energy if you use a motion sensor to determine updates than you would simply updating the portion of the e-paper devoted to clockiness every minute.
FlyingToaster, Jan 03 2011
  

       FlyingToaster, - I seriously doubt we really did have LCD clocks back in the ’70s which ran for years. I mean, look — we’ve only just got to the stage now where we have a phone that has a full-front LCD that can tell the time, most of the time, and even that is at the technological leading edge of technology, so much so that it finds it impossible to even wake people up on New Year’s day until the 3rd.
Ian Tindale, Jan 03 2011
  

       Hah ! How'd ya like THEM apples ... ?   

       <link>
8th of 7, Jan 03 2011
  

       I used to have a fridge-magnet LCD clock (tiny thing cost less than a dollar) that ran for well over a year. The main point though was that running a motion sensor would probably use more energy than just updating the clock part of the poster.
FlyingToaster, Jan 04 2011
  

       okay, so i shall modify that to point out its a bad idea to have active motion sensing.   

       What about just light sensing, or sound sensing?
mofosyne, Jan 04 2011
  

       //light sensing// Well, you could make it powered by piezo crystals connected to tympani: just yell at it until the time changes.
FlyingToaster, Jan 04 2011
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle