SunLeaf

Hope everyone's holiday season is off to a good start despite the pandemic still in full swing. As some of you may know SunLeaf has been continued as part of a bigger project on here called Agricoltura IO. 

At this time I am working on the project again and focusing on making it more appealing as a product or commercial application. I would like to hear from folks that are interested in this and what sort of applications they would want to use SunLeaf for and what sort of feature's they would like to see. Feel free to comment on this project log or message me directly with your thoughts and concerns. Things are about to get more exciting this winter. 

Thank your for your continued support of all my projects over the years on this platform!

Happy Hacking!

Hey folks just an update saying this project is not dead, its in the process of being refreshed as part of my latest agriculture sensing platform Agricoltura IO you can learn more about it here: https://hackaday.io/project/173362-agricoltura-io

Agricoltura IO Is a agriculture sensing and control platform relying on a RS485 sensing and control nodes that are controlled by a gateway control that links RS485 and wireless networks together pushing their data into a cloud database and browser control panel. SunLeaf has now evolved into a family of 4 wireless devices and will be part of the new Agricoltura IO system. So again please head over to the new page to learn about the new family of hardware and the new Sunleaf modules. This page will be updated further down the line when I start working on the new Sunleaf boards, right now the priority of Agricoltura IO is the RS485 based Vine and Ivy modules. 

https://hackaday.io/project/173362-agricoltura-io

Stay tuned for more updates

So the competition is over but that just means we are getting started!! Given that SunLEaf is a continuation and spiritual successor to the electronics and sensing package of last years hydroPWNics it only makes sense to keep going and iterating the system until its solid and flawless. Anyhoo we got the SunLeaf rev 1 PCB posting to thingspeak shortly after the final submissions. This was achieved by grafting an ESP-12E module dedbug style to the pads meant for the ESP-02 module that was originally chosen for the SunLeaf PCB rev 1.

Not my proudest moment or cleanest assembly/build but the damn thing works! And it even works well off battery power (battery not pictured). What is next is to create a version of the PCB that works flawlessly. I have already teased and shared the nearly solidified SunLeaf V2 design a few times arleady. The reason why it has yet to be fabricated is because the WiFi module needs to be tested separately. On the open web there are not many people using the ESP-09 module, I am using it since its very barebones and allows for a smaller PCB layout allowing my to mount it top side on the rev2. So in order to confirm this module before running another 4 layer PCB through the fab process, I made a small two layer PCB that will allow me to test the ESP-09 module and our software for the ESP8266.

Here it is :

https://github.com/adamjvr/ESP-09-Test

Its on its way to the fab already, when the boards come in should take me a day to complete my evaluations. If everything works the way I hope then SunLeaf rev2 will be a go and be 99% likely to be fully functional! Stay tuned as the open source sensing revolution continues to unfold on Hackaday!!!!!!

So with the Hackaday Prize coming to a close we present our working prototype video

This our working prototype posting sensor data to thingspeak. The SunLeaf prototype is sampling from DHT and light sensor then posting the data. The end of the competition is not the end for SunLeaf, we will continue to work to get our PCB-prototype to the same level of functionality as our working prototype, stay tuned for more updates to this post and future project logs, we are just getting started ;)

So we got another update on the hardware revision today. Two logs back I mentioned that some of the further tweaks to the 0.2a design would be test points. Since the last log I have been working on just that. Test points are very important when designing mixed signal circuit boards with lots of stuff packed on to them. Test points are typically used for debugging problems with the circuit that the designer didn't expect , they are handy for development software debugging, and lastly they are import for confirming desired function of hardware after being assembled in the factory.

The first version of the Sunleaf version 0.1a had test points but not enough of them, there were a few signals here and there that we wanted to be able to probe more easily. Also version 0.1a did not have nearly all the signals for testing complete function since we are looking at mass production we need to have all the important signals available as test points so we can ship working boards. So here is a quick look of the SunLeaf with the newly added test points:

You can see that many test points were crammed onto the PCB without altering its size further. This should make testing and development a lot easier, as we move forward. The signals that now have test points indlude:

- UART_S_TX - UART TX for sensors, runs to the multiplexer/demultiplexer

- UART_S_RX - UART RX for sensors, runs to the multiplexer/demultiplexer

- USW_S1 - UART multiplexer toggle

- USW_EN - UART multiplexer enable

- USW_S0 - UART multiplexer toggle

- BAT_VOLT - Battery voltage sense signal. right off the voltage divider

- I2C_SCL - I2C SCL running from MCU to multiplexer

- I2C_SDA - I2C SDA running from the MCU to multiplexer

- EN1_IMUX - I2C multiplexer toggle 1

- EN3_IMUX - I2C multiplexer toggle 3

- EN2_IMUX - I2C multiplexer toggle 2

- EN4_IMUX - I2C multiplexer toggle 4

- ESPTOST_BOOT1 - ESP to STM32 BOOT1 Pin

- ESPTOST_BOOT0 - ESP to STM32 BOOT0 pin

- ESP_ST_RST - ESP to STM32 reset toggle

- USB: D+, D-, VBUS - USB signals

- ESP_PGM_MODE - ESP program mode signal coming off the STM32

- ESP_URX - UART RX running to ESP

- ESP_UTX - UART TX Running to ESP

- STM_ESP_RST - STM32 toggle ESP reset

- Solar input

- BAT - battery signal

- THERM - battery thermistor signal

- Power Good on charge controller

- Charge good signal on charge controller

- LDO regulator input and output.

Now there are not test points on 100% of the pins/signals. The sensor connectors have been left out, only because they will either be met with connectors or pogo pins on the factor test jig PCB. So that concludes our test points. Stay tuned as we get closer to the next build!

So for the prototype run, we are currently evaluating fab house for quickturn manufacturing. I typically use OSHPark for all prototypes but as time keeps going by it might be cutting it close with their services. Either way I created renders of the new board with there fab:

Top View:

Bottom View:

The board is only about 2 dollars more expensive than the last revisions with an order total of around 47 dollars for a round of 3 from OSHPark. The necessary adjustments in size didn't hurt us on cost very much wihich is great.

Moving onto the bill of materials, everything for the prototype BOM comes from Digikey with the expception of the ESP-09 module that is ordered from a user on Tindie who imports them to the US. The BOM is simple it just explains the parts used, how much one costs in qty of one and the overall cost to build one SunLeaf. If you are feeling ambitious have at it, order some parts and boards and solder them up we'd love to hear about it. Anyways here is the BOM:

If you wish to view it as a google spreadsheet the following link will do just that: https://docs.google.com/spreadsheets/d/1kv7WRCuP9jof3ieIvjWm7yBUWpwseHQou-YMSgxwjEM/edit?usp=sharing

So there we are, we have a new board a BOM, and prepping to order, just some more final checks. That's all for now, but expect more posts this week!

So its been a short while since we discussed SunLeaf hardware. there's actually be a lot done since the last update readying the PCB ready for fabrication. In the last few weeks I have been slowly cleaning up the PCB routing, eliminating design rule errors, and making sure all reference schematics were followed.

Most of the work though was spent getting the board ready to fab with KiCAD and its built in plotting tools. I wanted to put the board through serious design rule checks to ensure that it fabricates without any issues that could cause problems down the line. Also while retooling the boeard and squashing DRC violations, I added three M2.5 mounting holes, so that a new 3D case can be easily designed and 3D printed.

Another I updated was labeling, and fiducials. The board feature a lot more labeling of pins and and connectors. Everything from the sensor inputs, battery, solar, USB. JTAG is labeled, bottom side of board features labeling of each pin. The fiducials are for automated assembly, so pick and place machines know the orientation of the board when placing components as sometimes the board can be rotated by the machine during assembly etc. Another fix was adjusting all copper pours that re nearby each other to not overlap and to pour with the right amount of clearance so as to not violate the design rules. This sort of function is typically handled automatically in a professional design tool like Altium, not to say that KiCAD is not capable of professional work you just need to know what you are doing and do a lot of things manually, not that much of a problem, those of use that use a lot of open source software are used to these sort of things. More of the fixes include cleaning up of ESP-09 module, adding a larger ground pour beneath it and adequately stitching to the internal ground layer. The internal plane for power has also been cut beneath the antenna connector to cut down on interference with RF transmissions. Another update include a header to connect to UART6 on the STM32 for debugging over a USB serial converter. The JTAG connection was also cleaned up and a pullup resistor added to the JTAG reset signal, in the original SunLeaf the button reset pin was used for both JTAG and user reset, while it worked it was not the correct implementation and has been since corrected. BOOT1 pin has been pulled high with a 10K pullup and is now driveable by the ESP this correction is for the OTA programming functionality. On the ESP-09 CH_PD has been pulled high for ensure proper operation, deciding whether or not to have this controlled by the STM32 yet.

Electrical things where not the only part of the work done on SunLeaf 0.2a. 3D models were added to more components for proper 3D rendering of the board. This is important for designing a new 3D printed case for the 0.2a revision. KiCAD does a great job at rendering and showing the board, its super smooth and very fast. Here are some pictures of the render:

Top:

Bottom:

With that there are only a few more tweaks to do before fab, mostly adding test points. For testing this board the plan is to make two layer board with pogo pins tapping the connectors from the bottom. This method should eliminated the need for most test points, either that way ore the board will sit upside down in the test jig. More on that stuff in the next update!!

So it has been too long since our last update on the hardware. The last thing I mentioned related to the hardware was that rev2 of the SunLeaf was already underway in KiCAD, well its nearly done and here's what I did with it:

- Implemented OTA (over the air) programming signal connections between the ESP8266 and STM32

- Changed the ESP8266 module from the ESP-02 to the ESP-09, more pins needed for OTA.

- Implemented battery monitoring with a simple voltage divider, allowing battery voltage to be monitored.

- Moved the ESP module and supporting components from the bottom to the top of the PCB

- ESP module no longer has UART between STM32 as jumpers, they are directly wired with a throughhole connector for ESP code flashing inlined with the signals

- Sensing conenctors changed to all 4 pin based ones.

- Chaned the position of the power and ground on Grove connectors to be correct, they were swapped in version 1.

- Overall PCB size has been slightly increased to move ESP to the top and accommodate changing the 3 pin JST connectors to 4 pin ones for the analog and expansion connectors.

- Battery controller circuit has been revised to more efficiently dissipate heat.

- LDO switched to a smaller package to save board realestate.

- TVS diodes on sensor inputs rotated 180 degrees to keep them far away from the board edge.

Now the PCB isn't 100% finalized but its about all but done having implemented the above, I might be forgetting some things but that's the jist of it, I'll have more updates on that next post. So without further do, SunLeaf Alpha 0.2 :

The schematic has also been drawn to be more readable in this revision.

Schematic Renders:

So that's where we are at with SunLeaf rev 2, next I think I'm going to add mounting holes and some logos and thats about it, so its done for the most part. There is also tad bit more testing with the solar charging section we want to do before fabricating the board, that will be touched upon in the next post on hardware.

So OTA programming, I mentioned in the title, so yeah we are going to implement over the air programming of STM32F446RET6 our main processor over UART with the ESP-09 ESP8266 module. The STM32 has a bootloader that supports loading of firmware over any of its UART ports, this functionaility is toggled via the processor reset pin and toggling the two BOOT pins on the processor, this allows the ESP to restart the STM32 into bootloader mode and load the firmware over UART. All this has been set up in this design revision, we consider it a major feature upgrade over the rev 1.

We got a few more updates on firmware, functionality, and application from my great teammate Shane so stay tuned for that. As for this post that's all folks!

So its been a while since we talked about the SunLeaf hardware. There has been quite a bit done since the last post. In the last update I showed what I had populated so far on the SunLeaf 0.1a PCB. The populated sections included, USB connector and suppression, STM32 circuitry, sensor muxing circuitry, ESP-02 module, programming headers, and transient suppression circuitry. With all that populated the SunLeaf was ready for testing but I realized that I didn't have a way to connect the ST Nucleo board to the SunLeaf to program it.

My solution was to make a small adapter PCB that lets you hook up the STLinkV2 integrated into the ST Nucleo board to any target board over the ARM Cortex M debug port (10 pin 1.27mm pitch header ). The adapter took 10 days to make at OSHPark which delayed testing. After assembly I was able to put it on my ST Nucleo, pull the jumpers and presto STLinkV2 for cheap:

Moving on, last update I mentioned that the footprint to the solar battery charge controller IC was flipped making it not possible to populate and function. Well I made a mistake in my analysis turns out that the footprint was just fine, I only labeled pin 10 as pin 1 with the dot marker on the PCB which made me think I got it wrong during assembly. So I decided to populate the remainder of the PCB and start testing it. The fully assembled SunLeaf 0.1a :

So with the fully populated SunLeaf I started testing things down at the basics. First I tested power, I plugged it in via USB, and checked it with a volt meter. The MOSFET for switching from battery to USB power for feeding the 3V3 regulator worked successfully. The LDO was also pumping out the correct 3.3V as expected.

Next I decided to test programmability of the two systems on board the SunLeaf. The SunLeaf is effectively a dual processor board with the STM32F446RET6 and the ESP8266 (ESP-02 Module) linked over UART serial. Their link is jumperable on this revision, so the ESP8266 can be programmed over its UART port. So to begin I wired up the ES8266 to my Adafruit FT232H breakout, wired up the SunLeaf to the Nucleo :

Next off was to test the STM32F446RET6, the main processor. ST Microelectronics makes this sort of stuff incredibly easy. They have a awesome STLink utility program that lets you flash code, verify, and do lots of testing stuff with your STM32 target projects. You can find it here if you want: http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link004.html . So with the Nucleo hooked to the SunLeaf I used the utility's connect to target function and it successfully connected. So the STM32 started up fine, indicating that the reference design with my adjustments worked out ok. Next I wanted to test the serial, so I wrote a simple program in mBed to just print back whatever is typed into the PuTTY terminal, I also wrote a shrot program that just looped and printed back. Next test was to test the UART muxing , this was tested with a simple mbed program to just toggle IO to select channels and output PWM signals, I used my oscillscope to test the UART sensor ports. I also had some crosstalk issues on the UART muxing lines to the ports, I suspect solder bridging with the network resistors or crosstalk, I'm thinking about omitting thos resistor networks in rev 2 but I need to do more digging on the problem.I2C and the solar section still need to be tested, I am waiting on parts and a trip to Microcenter to complete testing.

Another smaller update is that the ST-Client software that runs on the STM32F446RET6 is now available on our github as a ARM GNU Toolchain project. Currently built successfully under Debian stretch, any POSIX style system should suffice. Here is the repo: https://github.com/HydroPWNics/SunLeaf-STM32 you can get the ARM GNU Toolchain here: https://launchpad.net/gcc-arm-embedded . Eventually we will have a combined repository that compiles and builds code for both the ST and ESP together. This is just a start of moving towards an entirely make syntax buildable project.

So In Summary:

1. The STM32F446RET6 programs and talks to the programmer (ST Nucleo + my adapter)
2. UART peripherals on the ST are functional, tested by printing back to a com port via FTDI board
3. Control UART multiplexer with GPIO
4. ESP8266 as setup is not responding to a programming routine
5. I got the mbed project for STM-Client building with the ARM GNU Toolchain under debian

6. USB power switching works, I can run the board off bus power just fine, the VBUS signal successfully drives the MOSFET switching from solar panel to VBUS to the regulator and charging circuit

Moving forward a new version of the SunLealf PCB is being worked on right now, development has been switched to KiCAD, the next post on hardware will be covering that. While developing the new PCB, solar battery charging and I2C function and muxing will be tested and any other issues will be mitigated in the 2nd revision of the PCB. Stay tuned for more hardware fun !!!!

Introduction

One of the goals behind SunLeaf is to enable it run without external charge for at least 2 years. This means that power is a huge factor in making this successful. We think this is possible because both chips: the STM and the ESP both have low power modes. This is not the only consideration. We also need to consider the power source. The battery we will use is here: <insert link> and the solar panel is here <insert link>. The solar panel is small, however we will rely on an adaptive the sleep mode controller to regulate the power and the best times to take a measurement. Now that we have identified the major components we can start the beginning of a power budget to show this capability.

Power budget

Power management in software

The STM32F446RE can be put into a sleep mode and then woken up using an internal interrupt in the programming:

Ticker post_data;
.
.
.
//lots of code here...
.
.
int main(){
.
.
//lots of code here...
.
.
post_data.attach(&post, 60.0); // the address of the function to be attached (post) and the interval (2 seconds)...this will wake up the STM
 
while(true){      
      if(posted)
      {
        debugSerial.printf("sleeping...\n\r");
        posted = false;
        esp.Sleep();  //put the esp to sleep
        ESPisAsleep = true;
        led2 = 0; //turn off all other power and sensors
        
        sleep();       //then sleep
      }else{
        LCD_D7 = 1;
        led2 = !led2;     
        wait(0.5); // give everything a half-second to wake up
      }
  } 

}

So basically we always keep the STM32F446RE in sleep mode unless there is an interrupt. The frequency of the interrupt is given in the second argument. This value can be adapted to optimally send environmental data while preserving the battery life. Details on this will be given in another log on complex power management. You can also see that we send the esp.Sleep() command to the ESP. esp.Sleep() did not originally come with the STM-Client so we had to add it. Here's how we did this. I'll review what was done on the STM32 then I'll review the ESP-Link Code changes. First we added to the STMClient.cpp file the following code at the bottom:

 //look in cmd.c for this. Puts ESP to sleep until a fall edge triggers on RST for it to reset.
 
void STMClient::Sleep(void){
  Request(CMD_SLEEP, 0, 0);
  Request();
}

// Enumeration of commands supported by esp-link, this needs to match the definition in
// esp-link!
typedef enum {
  CMD_NULL = 0,     // null, mainly to prevent 0 from doing something bad
  CMD_SYNC,         // synchronize, starts the protocol
  CMD_RESP_V,       // response with a value
  CMD_RESP_CB,      // response with a callback
  CMD_WIFI_STATUS,  // get the wifi status
  CMD_SLEEP,        // Go to sleep
  CMD_CB_ADD,       // add a custom callback
  CMD_CB_EVENTS,    // ???
  CMD_GET_TIME,     // get current time in seconds since the unix epoch
  //CMD_GET_INFO,

  CMD_MQTT_SETUP = 10,
  CMD_MQTT_PUBLISH,
  CMD_MQTT_SUBSCRIBE,
  CMD_MQTT_LWT,
  CMD_MQTT_EVENTS,

  CMD_REST_SETUP = 20,
  CMD_REST_REQUEST,
  CMD_REST_SETHEADER,
  CMD_REST_EVENTS
} CmdName;

The ESP-LINK required a few more additions as well. All of these additions occur in the /cmd/ directory of the ESP-LINK Code.

First we had to add the CMD_SLEEP handler in handlers.c:

// Command dispatch table for serial -> ESP commands
const CmdList commands[] = {
  {CMD_NULL,            "NULL",           cmdNull},        // no-op
  {CMD_SYNC,            "SYNC",           cmdSync},        // synchronize
  {CMD_WIFI_STATUS,     "WIFI_STATUS",    cmdWifiStatus},
  {CMD_SLEEP,           "SLEEP",          cmdSleep}, //SLEEP
  {CMD_CB_ADD,          "ADD_CB",         cmdAddCallback},
#ifdef MQTT
  {CMD_MQTT_SETUP,      "MQTT_SETUP",     MQTTCMD_Setup},
  {CMD_MQTT_PUBLISH,    "MQTT_PUB",       MQTTCMD_Publish},
  {CMD_MQTT_SUBSCRIBE , "MQTT_SUB",       MQTTCMD_Subscribe},
  {CMD_MQTT_LWT,        "MQTT_LWT",       MQTTCMD_Lwt},
#endif
#ifdef REST
  {CMD_REST_SETUP,      "REST_SETUP",     REST_Setup},
  {CMD_REST_REQUEST,    "REST_REQ",       REST_Request},
  {CMD_REST_SETHEADER,  "REST_SETHDR",    REST_SetHeader},
#endif
};

//puts the ESP to sleep
static void ICACHE_FLASH_ATTR 
cmdSleep(CmdPacket *cmd) {
//  uint32_t sleepTime = 30000000;
  cmdResponseStart(CMD_RESP_V,espSleep(42),42); //should put this to sleep for 30s attach gpio16 to RST
  cmdResponseEnd();	
  return;
}

This basically tells the ESP to go find the espSleep() command and execute it. But we had to build a commands.c file for the espSleep() function to live in.This file is where all STM-ESP commands can live as well. Here is the entire file for now.

#include "esp8266.h"
#include "commands.h"
#include "cmd.h"

#ifdef CMD_DBG
#define DBG(format, ...) do { os_printf(format, ## __VA_ARGS__); } while(0)
#else
#define DBG(format, ...) do { } while(0)
#endif

int espSleep(uint16_t sleepTime){
  system_deep_sleep(0); 
  return 42; // rule 42, you know...this will probably never get returned because the system starts over after this...
}

  system_deep_sleep(0);

That concluded the necessary software changes for sleep modes but it also shows how to implement other commands using ESP-LINk.

Required hardware connections

There are two types of commands to be sent to the ESP from the STM. The first is sleep and the second is "wake up!". The ESP can be put into deep sleep in software as shown above. But it needs the RST pin pulled high to wake up. We do this by connecting a GPIO pin and setting it to "high" during the interrupt as shown below in the schematic.

See it in action

Below is a video of the system posting data to thingspeak.com and then going to sleep. You can see the LEDs turn off when it is asleep and they are on and flickering when it is posting data....enjoy.