Steve's Build Log

Steve_Mayze · October 15, 2017, 12:19pm

Remote Sensing with XBee

Another project I have been chipping away on is a remote sensor for say a solar charger. I don’t actually have the proper solar gear it is intended for, but I do have a rather crude arrangement for a 6V sealed, lead acid battery being tickle charged from a 9V solar panel. This arrangement has worked without any issues for the last four years. I decided to use this for my first “integration test” of the sensor.

The sensor itself, is simply a voltage divider to monitor the battery as well as an on-board temperature sensor. The whole thing connects to a Teensy 3.2 using the CE_Header. The Teensy is powered by the battery under charge via a 5V LDO that I had created a while back to help out with another project.

The test code that I have so far, has the Teensy transmitting the battery voltage and temperature every 5 seconds.

The messages are being received by another XBee attached to a Raspberry Pi -using a small adapter I created for the purpose. On the Raspberry Pi, I have a small Python program to simply print out the message it receives.

This setup is obviously far from optimal in terms of the drain on the battery under charge. At this stage my focus is seeing if these pieces will work together. There is still a lot of work to do along the chain of data creation, transmission and consumption. One of the next steps is to sort out a proper power system for the Teensy and sensor. From the initial tests, the battery readings started at 6.53V and after about 10 minutes dropped to 6.48V and remained there even after one hour (so far). These initial results are encouraging, it needs to be said, we have a sunny day here today and so to better understand the impact of the setup I have for this test case, I should be measuring and comparing the current through the system.

jonthomasson · October 15, 2017, 3:24pm

Nice project! Do you know what the range is on those little XBee transmitters? I have a project where I need to sense the water level on a storage tank and transmit it back to the house and these may fit the bill. I really like the design of that solar charger. It looks like it could handle the elements and it’s perfect for these type of applications.

Steve_Mayze · October 15, 2017, 4:01pm

Thanks @jonthomasson, The range of the XBee depends on the model and the antenna it uses. The model shown has the antenna built onto the PCB and is supposed to have a reach of about 30m indoors and 90m outdoors. For today’s test, the sensor unit is on the back terrace and the Raspberry Pi is in the cellar. There is a window nearby so the reach would be about 6m and is working very will for this test.
I did a small write up about working with these for the first time.

The case is IP65 compliant. So it would be suitable for your project. I actually have it as a TODO to change the enclosure for the charger. The problem I have is heat building up when it is left in the full sun in Summer. In that case I usually leave the lid ajar.

jonthomasson · October 15, 2017, 4:24pm

Very cool, Thank you for the link to those enclosures and the blog post. I may need to end up getting an XBee with an external antenna to get the distance I need. I look forward to seeing how these sensors work out in your project.

ChrisGammell · October 15, 2017, 9:26pm

A low cost way to excite the electrons in the battery

Teehee!

Steve_Mayze · October 19, 2017, 9:18pm

Getting LEDs to blink in indicate state is fine and does works well when nothing else is available. However, I have been curious to add a display to a project to start to better understand what is required. Not being too adventurous, I decided to start simple. I had mentioned before about some displays I came across at the Nuremberg Embedded World from Electronic Assembly. The project that I want to try them out on is the remote battery checker. The idea being that pressing a button on the checker could show the voltage rather than only going via the Raspberry Pi.

These displays come in many configurations and communication options. The one I picked for a first attempt is the DOGM081-A. I intend to use it in SPI mode. I wrote about this previously and mentioned I had created an adapter that reduces my pin count for attaching the display from 24 pins down to 6.

On the latest version of the battery monitor, I added provision for a one-way SPI connector explicitly to couple with the DOGM081 adapter.

It took a little while to get the display to work. Electrically, everything was fine and I am pleased to say I did not have to add any bodge. The problem came with configuration of SPI. With the help of my USB-SPI tool and Saleae, I could confirm the setup. I then had to translate that configuration to the code. When things were still not working I went through the setup instructions for the display one byte at a time to see if I was missing something. While going through the table of instructions in the datasheet for the display’s driver, I noticed it stated the expected execution time required to complete the instructions. i.e. Clearing the display and returning Home taking just over 1ms each. The rest of the instructions take around 26.3μ seconds - So there was the last piece to the puzzle! I added a delayMicroseconds(50) between each byte sent and suddenly the display started to work!

void initDisplay(){
      unsigned int init[9] = {0x31, 0x14, 0x55, 0x6d, 0x74, 0x30, 0x0c, 0x01, 0x06};
      SPI.beginTransaction(SPISettings(2000000, MSBFIRST, SPI_MODE3));
      // select the chip and set to command mode:
      digitalWrite(register_select,LOW);
      digitalWrite(display_select,LOW);
      for( int i=0; i<9; i++){
         SPI.transfer( init[i] );
         delayMicroseconds(50);
      }
      // Deselect the chip and leave in 'Data' Mode:
      digitalWrite(display_select,HIGH);
      digitalWrite(register_select,HIGH);
      SPI.endTransaction();
    }

So the pieces are coming together:

Measuring voltage and temperature
Being able to send this information to a Raspberry Pi
Displaying the information locally

There is still a lot more to sort out with this project. The code is very much test code and I need to get some more formal conversations happening between the Raspberry Pi and the sensor. The other issue is the power consumption. According to my Lab supply, the whole device is drawing around 80mA. I am hopeful I can reduce this a bit. i.e. Using the display on demand, optimising the voltage sensing and even better utilise sleep modes on the micro.

jonthomasson · October 19, 2017, 10:19pm

Looks good! Nice detective work with the timing on the display driver. That would have had me stumped for a while.

mikef · October 20, 2017, 1:39am

Nice work Steve, the timing would have stopped me.

Steve_Mayze · October 20, 2017, 9:01am

Thanks guys. The motivating force was that the display worked fine with the USB-SPI tool and I could see the messages being transmitted seemingly correctly from my board. I was doubting it was the setup string as this was the same being transmitted by the USB-SPI tool.

The lesson I have learned on this one is not to take it for granted the information presented on the logic analyser. All the timing information is all laid out. I was focusing on the bytes begin sent. The screen shots show what was staring me in the face. The USB-SPI tool places a 0.7731ms delay between the bytes sent. Without any delay, the Teensy will have a 0.6667μs gap - and the data sheet is indicating a 26.3μs execution time. No wonder it was having trouble.

ChrisGammell · October 22, 2017, 2:47am

Boy have I learned that one the hard way many times in the past. Almost out of habit now, I swap over to a scope pretty quickly to “sanity check” my setup.

Steve_Mayze · October 22, 2017, 7:43am

@ChrisGammell, I really need more practice with the scope to know how to read it properly. I did try using the scope first, since I have worked out how to get the decoding working on the scope. But it was not telling me what I was wanting to see. Where as the Saleae will annotate the actual trace (not that I was taking any notice at first ;)).

Thinking about it again, I was probably missing something on the scope setup. The additional issue I had, that the logic analyser quickly pointed out, was that my code was assuming Mode0 SPI configuration. The USB-SPI seems to be using Mode3.

Steve_Mayze · November 4, 2017, 3:49pm

Still thinking about the remote battery checker, I have started looking to how this could be powered more efficiently. A reasonable starting point seemed to be based on the Power Swap project in CE. My requirements have different specs i.e 1 cell supplying 5V for my current setup. I figured a reasonable place to start was the TI Webench®. Restricting the search down to only one manufacturer was not such a big deal for me at the moment. I just wanted to try this out to understand better what I will get.
From my input parameters - input of around 3V7 and out put of 5V, a set of candidate designs were shown and I picked a design containing the LM2621.
The provided design was not far off the one specified in the data sheet for the typical application. Just the values for a couple of the feedback parts differed. I have read through the datasheet, but it is not clear to me why these parts would differ and what effect they will have on the final implementation. To this end, I will see if I can allow for both variations of parts on the board. In the design, I have broken out some pin-headers to simplify the attaching of an amp and voltage meters.

Conveniently the datasheet contains a suggested layout, which I have tried to follow. Since I am trying to follow the suggested design, this means large areas of copper zones and also, for the first time, the usage of 0402 parts. I have already ordered the stencils. I think I will be doing this one in oven.

Steve_Mayze · November 4, 2017, 4:35pm

I have started another project. This time I have decided to join the NeoPixel crowd. Though I doubt it will be ready for this Christmas.
Rather than taking what is out there or using an Arduino, I have opted to try this from scratch. In my designs I am leaving it open as to what MCU I will use for further projects but I at least want to give the ATTiny1614 a go in this version. My current understanding is that it is supposed to support 20Mhz without an external Crystal. The small number of GPIO and 2K of RAM makes this attractive for my intended use. I am just not sure if there will be any timing issues by not having a crystal while it is said that the NeoPixels protocol is timing sensitive.

An interesting outcome of starting to look at the protocol for the NeoPixel and the MCU I have chosen, programming of this little fella is different again to the others I have been exposed to. This is using what Ateml refer to as UPDI … it is basically a single wire protocol as well so the program header only needs three connections - data, V+ and GND. With this programming protocol it is supposed to also support debugging. I will be curious to see how this all comes together.

I want to keep this as compact as possible, which is another reason for going with a smaller MCU. Even so, I have broken out what few GPIO it has incase I find another use for the board as well as for testing.
The documentation for the NeoPixel says to use a 1000μF capacitor at the supply end if powering from a power adapter. In keeping with a compact design, I am going to try mount this under the board.

ChrisGammell · November 4, 2017, 6:17pm

Wowsa, that capacitor is huuuuge!

The schematic you linked has “3V7 in (Nominal)” and the LM2621 (and that configuration) makes me think it’s a boost. So is there a disconnect somewhere? Is it going to be a step down or a step up?

Steve_Mayze · November 4, 2017, 7:52pm

Thanks for the proof read I was mixing it with a battery charger stage that I still need to think through. I have corrected my post.

Steve_Mayze · November 22, 2017, 9:49pm

3V7 to 5V Boost Regulator Prototype
The boards for the prototype boost supply arrived yesterday and the parts I needed arrived today. I could not wait and had to put this together. The BOM for this sample had suggested a couple of 0402 resistors. I deliberately left these to try them out. This was my first time with such a small size. I had decided on the out-set that I would not be soldering these by hand and ordered a stencil. I was just unsure how the polymide stencil would work the 0402 size, so I decided to use a stainless steel stencil - also for the first time. I was not disappointed! The application of the solder went on easy. Though it did look a little thick.

After the re-flow, I am very pleased with the result. Only one resistor, an 0805 went walkabouts on the board but that was easy to put back in place. There was no other movements and no bridging on the Boost regulator. This would have to be one of my best efforts.
I was also delighted to find that there were no problems in bringing the board up. It powered up nicely and the initial wave forms look OK. The sample shown below is a 3.7V 500mAh LiPo (I used my lab supply on the initial power up, just in case there were any issues).

This is not the end of the testing. When I get a bit more time, I will be brushing the dust off the Current Sink or Swim and putting both the regulator and the battery through some further tests - this should also test my memory in the use of the CSOS!

The end result is that I am very pleased with the stainless steel stencil and for the price, I will definitely consider them for future, but not all, projects. As for 0402. I don’t know if I would be using them more often. In the end, they were not a problem but placement was a little cumbersome. Luckily for this board, I only had three to worry about.

jonthomasson · November 23, 2017, 2:37pm

That board came out beautiful, great job! For the stencil, did you have to setup a jig to get it positioned precisely where you needed it? Or is it just a matter of taping things down?

Steve_Mayze · November 23, 2017, 3:12pm

Thanks Jon. I just use the jig that OSH Stencil can provide and tape things together on the the back. I then taped the stencil down onto the jig. This board is really small so I did not experience any issues with that setup. I must say, though, the stainless steel seemed to align much easier than the polymide. maybe it is because the polymide is transparent and that make it a little harder to identify that the smaller pads are lined up correctly.

I would really recommend to anyone attempting to use the stencils for the first time (or the nth time) is to listen to episode #320 of the Amp Hour - “An Interview with Brent of OSH Stensils”. This has been a huge help in understanding how to use stencils better.

ChrisGammell · November 24, 2017, 3:59am

I found this as well. They aren’t markedly different from their larger brothers, but they just seem to require a lot more concentration when using tweezers. And since they still seem to be the line of demarkation between DIY/low cost pick and place and the mid-range pick and place I think it’s still a better bet to go with larger sizes if possible.

Me as well. I find I likely won’t go back to polyamide unless truly cost constrained. The price keeps dropping on the SS ones and I’m sure that they could be used for 10s of iterations instead of the 5 or so the plastic ones allow.

jonthomasson · November 24, 2017, 4:00pm

That’s so neat that they even provide a jig with the purchase. I have at least one board in mind where this would really save a lot of time. Which oven are you using for the re-flow?