Close
0%
0%

SAGES

What is the best way to ensure the progress of humanity 10,000 years in the future?

LazyHDLazyHD
Following
Liked Like project

Become a Hackaday.io member

Similar projects worth following
2.6k views
10 comments
35 followers
likes
View Gallery
Winter is coming...

How the past and future can be tied together? One of the most unfortunate events that can happen is the loss of information after a long period of time. Taking inspiration from the Voyager crafts, we're looking into long-term information storage and retrieval solutions that can be communicated even to non-Earthlings. This project aims to engineer a low-cost, extremely hardy platform for creating miniature 'message in a bottle's which could be buried, passed down through generations, or even shot into space!

  • Solar charging circuit prototype in production

    jareklupinski • 09/30/2016 at 17:39 • 0 comments

    currently out being fabricated by Macrofab, should be back in my hands for testing in a couple weeks, will update with full schematics/code after I validate the design works :)

  • Version Three

    jareklupinski • 09/18/2016 at 03:57 • 0 comments

    Solar charging circuit is now tuned to the voltage requirements of a typical Lipo battery. I also added a system load cutoff switch to safely disconnect the battery from the circuit completely until it is recharged.

    Sending it off to Macrofab for production and testing!

  • Solar Powered and Ready To Last Forever

    jareklupinski • 08/12/2016 at 13:38 • 0 comments

    After a few weeks of testing, I can confirm that my solar charger circuit is working and keeping the esp8266 and epaper display alive despite minimal power-saving techniques.

    For demonstration purposes, I programmed the board to fetch the weather forecast, update the epaper screen, then sleep for an hour.

    I pretty much just cribbed the reference design for BQ25504, and I should probably learn how it sets the reference voltage for the battery as currently it doesn't charge past 3.8V, but that's not a big deal for my application.

    Epaper!

    I hooked the prototype up to an xbox chat pad for testing too...

  • Ultra Simple Character Driver

    jareklupinski • 05/29/2016 at 19:19 • 0 comments

    After trying to write my own 8x8 font, I gave up and grabbed https://github.com/dhepper/font8x8 . Had to grab a byte reversing routine from the Arduino forums to make it work with my buffer.

    #define D0_PIN 0  //SPI Clock
#define D1_PIN 1  //SPI Data
#define CS_PIN 2  //Chip Select, Low to select chip
#define DC_PIN 3  //When Sending Index set to Low, When sending Data set to High
#define RS_PIN 4  //Reset pin, hold High
#define BS_PIN 5  //Busy Pin, Low is busy
#define VC_PIN 6  //Power pin to display, make sure chip can source 10mA or use a mosfet switch

static byte screen[2912];

char font8x8_basic[128][8] = {
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0000 (nul)
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0001
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0002
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0003
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0004
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0005
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0006
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0007
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0008
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0009
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000A
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000B
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000C
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000D
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000E
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+000F
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0010
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0011
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0012
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0013
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0014
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0015
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0016
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0017
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0018
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0019
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001A
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001B
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001C
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001D
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001E
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+001F
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0020 (space)
  { 0x18, 0x3C, 0x3C, 0x18, 0x18, 0x00, 0x18, 0x00},   // U+0021 (!)
  { 0x36, 0x36, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0022 (")
  { 0x36, 0x36, 0x7F, 0x36, 0x7F, 0x36, 0x36, 0x00},   // U+0023 (#)
  { 0x0C, 0x3E, 0x03, 0x1E, 0x30, 0x1F, 0x0C, 0x00},   // U+0024 ($)
  { 0x00, 0x63, 0x33, 0x18, 0x0C, 0x66, 0x63, 0x00},   // U+0025 (%)
  { 0x1C, 0x36, 0x1C, 0x6E, 0x3B, 0x33, 0x6E, 0x00},   // U+0026 (&)
  { 0x06, 0x06, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00},   // U+0027 (')
  { 0x18, 0x0C, 0x06, 0x06, 0x06, 0x0C, 0x18, 0x00},   // U+0028 (()
  { 0x06, 0x0C, 0x18, 0x18, 0x18, 0x0C, 0x06, 0x00},   // U+0029 ())
  { 0x00, 0x66, 0x3C, 0xFF, 0x3C, 0x66, 0x00, 0x00},   // U+002A (*)
  { 0x00, 0x0C, 0x0C, 0x3F, 0x0C, 0x0C, 0x00, 0x00},   // U+002B (+)
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x0C, 0x0C, 0x06},   // U+002C (,)
  { 0x00, 0x00, 0x00, 0x3F, 0x00, 0x00, 0x00, 0x00},   // U+002D (-)
  { 0x00, 0x00, 0x00, 0x00, 0x00, 0x0C, 0x0C, 0x00},   // U+002E (.)
  { 0x60, 0x30, 0x18, 0x0C, 0x06, 0x03, 0x01, 0x00},   // U+002F (/)
  { 0x3E, 0x63, 0x73, 0x7B, 0x6F, 0x67, 0x3E, 0x00},   // U+0030 (0)
  { 0x0C, 0x0E, 0x0C, 0x0C, 0x0C, 0x0C, 0x3F, 0x00},   // U+0031 (1)
  { 0x1E, 0x33, 0x30, 0x1C, 0x06, 0x33, 0x3F, 0x00},   // U+0032 (2)
  { 0x1E, 0x33, 0x30, 0x1C, 0x30, 0x33, 0x1E, 0x00},   // U+0033 (3)
  { 0x38, 0x3C, 0x36, 0x33, 0x7F, 0x30, 0x78, 0x00},   // U+0034 (4)
  { 0x3F...
    Read more »

  • An Easy-to-source Epaper Breakout Board

    jareklupinski • 05/28/2016 at 19:02 • 0 comments

    One of the biggest difficulties I've faced in finding a good E-paper solution was trying to create a driver board going off the manufacturer's reference circuits for their displays. Often these schematic contain components that are either non-stocked in the US or local to their geographic area. After chatting with a few people in the Hacker Channel and reaching out to the manufacturer, I finished a tiny breakout board that should make it easy to communicate with an epaper display, using only parts that are easily sourceable from digikey/mouser/etc in the USA.

    For testing I was using a Teensy LC as I already had one connected to my PC. The simple SPI bitbanger function in the demo code should be easy enough to port to the esp8266, before optimizing using its hardware SPI.

    #define D0_PIN 0  //SPI Clock
#define D1_PIN 1  //SPI Data
#define CS_PIN 2  //Chip Select, Low to select chip
#define DC_PIN 3  //When Sending Index set to Low, When sending Data set to High
#define RS_PIN 4  //Reset pin, hold High
#define BS_PIN 5  //Busy Pin, Low is busy

void softwareSpi( byte data ) {
  for ( int i = 0; i < 8; i++ ) {
    if ((( data >> (7-i) ) & 0x01 ) == 1 ) digitalWrite( D1_PIN, HIGH );
    else digitalWrite( D1_PIN, LOW );
    digitalWrite( D0_PIN, HIGH );
    digitalWrite( D0_PIN, LOW );
  }
}

void sendIndexData( byte index, byte *data, int len ) {
  digitalWrite( CS_PIN, LOW );
  digitalWrite( DC_PIN, LOW );
  softwareSpi( index );
  digitalWrite( DC_PIN, HIGH );
  for ( int i = 0; i < len; i++ ) softwareSpi( data[ i ] );
  digitalWrite( CS_PIN, HIGH );
}

void setup() {
  //set I/O registers for pin functions
  pinMode( D0_PIN, OUTPUT );
  pinMode( D1_PIN, OUTPUT );
  pinMode( CS_PIN, OUTPUT );
  pinMode( DC_PIN, OUTPUT );
  pinMode( RS_PIN, OUTPUT );
  pinMode( BS_PIN, INPUT_PULLUP );
  //set pins to initial states
  digitalWrite( RS_PIN, LOW );
  digitalWrite( CS_PIN, LOW );
  digitalWrite( D1_PIN, LOW );
  digitalWrite( D0_PIN, LOW );

  //Power on COG - VCC/VDD already connected
  delay( 50 );                         //Delay 50ms
  digitalWrite( RS_PIN, HIGH );        //RES# = 1
  delay( 1 );                          //Delay 1ms
  digitalWrite( CS_PIN, HIGH );        //CS# = 1

  //Initialize COG Driver              
  while( digitalRead( BS_PIN ) == HIGH ); //Make sure BUSY = LOW
  
  byte data1[] = { 0xCF, 0x00 };
  sendIndexData( 0x01, data1, 2 );     //Driver output control setting
  byte data2[] = { 0x00 };
  sendIndexData( 0x0F, data2, 1 );     //Gate scan start setting
  byte data3[] = { 0x03 };
  sendIndexData( 0x11, data3, 1 );     //Data entry mode setting
  byte data4[] = { 0x00, 0x0D };  
  sendIndexData( 0x44, data4, 2 );     //Set RAM X - Start-End position
  byte data5[] = { 0x00, 0xCF };  
  sendIndexData( 0x45, data5, 2 );     //Set RAM Y - Start-End position
  byte data6[] = { 0x00 };
  sendIndexData( 0x4E, data6, 1 );     //Set RAM X address counter
  byte data7[] = { 0x00 };
  sendIndexData( 0x4F, data7, 1 );     //Set RAM Y address counter

  //Send Image to Cog
  byte data8[2912];
  for ( int i = 0; i < 2912; i++ ) data8[ i ] = (i/8)%255;
  sendIndexData( 0x24, data8, 2912 );

  //Update command sequence
  byte data9[] = { 0x80 };
  sendIndexData( 0x3C, data9, 1 );     //Select border waveform
  byte data10[] = { 0x10, 0x0A };  
  sendIndexData( 0x03, data10, 2 );    //Set gate driving voltage
  byte data11[] = { 0x00 };
  sendIndexData( 0x05, data11, 1 );    //Normal analog mode
  byte data12[] = { 0x00, 0x00, 0x00 }; 
  sendIndexData( 0x75, data12, 3 );    //Normal analog mode
  byte data13[] = { 0x19, 0x00 };  
  sendIndexData( 0x1A, data13, 2 );    //Send the temperature value
  byte data14[] = { 0xF7 };
  sendIndexData( 0x22, data14, 1 );    //Set update sequence
  byte data15[] = { 0x00 };
  sendIndexData( 0x20, data15, 1 );    //Active display update sequence
}

void loop() {

}

  • New Circular Epaper Display Proto Board

    jareklupinski • 03/11/2016 at 01:29 • 0 comments

    just ordered, will update when the board is in and populated :)

  • Prototyping

    jareklupinski • 03/04/2016 at 14:56 • 0 comments

    After receiving a starter kit from Adafruit, I started playing with the easily available displays to make sure e-ink performs the way it advertises. Sure enough, removing the panel from the circuit does not clear the screen! It's a little surreal...

    The panel is being driven by an Esp8266. Now to concentrate on trying to minimize the driver circuitry necessary to bring the cost down and portability up...

View all 7 project logs

Enjoy this project?

Share

Discussions

Ron wrote 12/28/2016 at 04:40 • point

Any update on this? :)

  Are you sure? yes | no

AVR wrote 09/30/2016 at 23:09 • point

care to share design files? I'm curious about your solar charging section

  Are you sure? yes | no

jareklupinski wrote 10/01/2016 at 16:23 • point

I have sent the latest design out to Macrofab and will publish them after it comes in if the board works :) I don't want to fill the internet with unvalidated designs haha

basically it's http://www.ti.com/lit/ds/symlink/bq25504.pdf the reference design here with the reference resistors specced for lipo batteries

  Are you sure? yes | no

Audrey Robinel wrote 09/18/2016 at 22:06 • point

Hi, for long run, you might want to keep the battery max voltage at 3.8V.

Indeed, lithium batteries ages faster when approaching to 3V, and also when approaching to 4V. Indeed, you may double the amount of cycles a battery can provide by lowering the max charge from 0.1. I can't cite the source of this without searching it again, but you should be able to find it in batteries datasheets (for lithium ones).

In my "long run applications", my method is having batteries that are way larger than required, so that i reduce the amount of cycles (let's say that i'd need 1000mAh for 24h, including solar charging, then i use multiple times this amount, so that i stress the battery less), and thus i'll charge up to a lower voltage than 4.2V, and make it so that i never go below let's say 3.4-3.5V.

That way, the battery is always near the half charged mark, which is the less stressful to the battery chemistry, and thus enables it to withstand more cycles.

  Are you sure? yes | no

jareklupinski wrote 10/01/2016 at 16:22 • point

I'll be doing a lot of experiments with battery longevity when I get the demo boards in, and I'll be sure to run a trial with your suggestion :) is there any way to test these solutions without waiting years and years?

  Are you sure? yes | no

Audrey Robinel wrote 10/03/2016 at 06:50 • point

I don't think we can have a completely accurate test, but at least an estimation, perhaps whith this methodology :

1     - Measure the actual capacitiy of 2 batteries
2A - Test battery A for multiple charge/discharge cycles, using a V1 and V2 as high and low treshold for the max and min tension.
2B - Test battery B  with the same methodology, but with V3 and V4, different values, more conservative.

3    - Then after say 100 cycles, measure the capacity of the batteries with a discharge test.  By comparing the capacity lost, you can evaluate the amount of capacity lost per cycle, and thus estimate the amount of cycles before the battery is rendered useless.

If doing those test with an high current enough (not super high current, but 0.5 to 1C) should speed it up, and also wear the batteries faster. Thus, when running a real application at  lower currents, we should obtain AT LEAST the predicted results (with lower current, the batteries wears slower)

  Are you sure? yes | no

Leonard wrote 08/15/2016 at 19:41 • point

Engraving into stone is a good option. [ least constructive comment to date]

  Are you sure? yes | no

jareklupinski wrote 08/16/2016 at 01:30 • point

the egyptians tried that, and now we can't even tell if they're trying to foretell our demise or pass down a really bangin fig pie recipe

the world may never know :(

  Are you sure? yes | no

Sequoia wrote 03/04/2016 at 17:45 • point

What's the deal with those beautiful purple PCBs? Are they for sale? Does it have 8266 onboard? Available in kit with battery & e-ink display??? :)

  Are you sure? yes | no

jareklupinski wrote 03/04/2016 at 17:52 • point

Purple PCBs courtesy of OSHPark, still tweaking the e-ink driving portion since I'm having trouble at anything less than an absolutely full battery...

8266 is on the back, will be available as a kit when it's done :D

  Are you sure? yes | no

Similar Projects

352
5
9
OSCUS, a hackable OS for hardware hobbyists, is COMING. iTardis, an IrDA transmitter with touch pads.
Project Owner Contributor

OSCUS - A HACKABLE OS

glensonggglensongg

3.9k
47
22
A TRS-80 using more modern parts
Project Owner Contributor

TRS-80 Compatible Clone

Hacker404Hacker404

21.2k
729
49
My project goal is to make internet access for micro controllers dirt cheap and dead simple to implement in your own projects.
Project Owner Contributor

$0.87 WiFi for Raspberry Pi and Arduino Projects

surfingstevesurfingsteve

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2018 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "SAGES", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.