Show by Label

Showing posts with label ESP8266. Show all posts
Showing posts with label ESP8266. Show all posts

Thursday, December 19, 2024

LoRa Mail Letterbox Notification


For quite some time, my wife had asked me to "produce something useful" instead of the projects I have been busy spending time and money on.

We live in an apartment building on the 3rd floor (4 for Americans) and our mailbox is next to the entrance together with the other 39 inhabitants. It's a full metal construction with an aluminum lid.

The distance is far exceeding a WiFi connection, so a LoRa connection should solve the distance issue.

Proof of Concept

I experimented with two of the E32 433MHz boards and quickly got that up and running using Arduino Nano boards, with two simple sketches. One acting as the sender and one acting as the receiver with an acknowledgement going back to the sender to turn on an LED. Powering the sender one with a Powerbrick, I ventured a few times up and down the stairs to the mailbox to see if I could get a reliable connection from within the metal enclosure, which I did.

Extending the Proof of Concept

In order to make this more reliable and practical, I wanted to put the sender contraption into deep sleep to conserve power, and waking it up somehow when mail got delivered.

I first tried to use an LDR that would function as a wake-up for the system. Unfortunately, my first attempts failed. I think this is because the mailbox itself it dark, and opening the lid and shoving mail through the opening did not provide enough of a light differential to use it as the trigger. This is unreliable because the postman or woman stands in front of the mailbox, blocking light and that in the winter period is another obstacle.

Besides, the circuit to recognize the opening of the lid by means of an LDR would have to be powered 24x7 and that would drain the battery cell.

It would have been nice nonetheless, because all the parts could be in one enclosure.

Alas, I had to find a different method, preferably one that did not use any power but would be reliable. So, the next thing I wanted to try was to use a magnetic reed switch, typically used for signaling doors opening. I ordered one, but it turned out to be too bulky for this application. The magnet piece would have to be connected to the lid by either glue or double sided tape because I can't drill holes anywhere. This bulky magnet part would be exposed to the outside when the lid opens, and it's too easy to get nocked off with bulky packages.

The next step was to try a smaller motion activated switch by a mercury droplet, which I found after some searching on Aliexpress. I knew about the existence, but looked for a really tiny one.



The glass bulb is 11mm long and has a diameter of only 4mm.

Using a different lid opening sensor

I have been notified by a viewer of this Blog that the mercury sensor I'm using can break the glass and the very toxic Mercury can leak out. He mentioned an alternative solution by using a vibration sensor. 

Vibration sensor

I didn't know about them so I ordered a few and will try them out. I ordered the normal sensitivity one and also the sensitive version.

This is how they look on the inside: (I borrowed the picture below from Adafruit: https://www.adafruit.com/product/2384


I got the vibration sensor with the normal sensitivity, the SW18020P and it is not really working well in this application. It needs quite a violent jolt to make contact, making it unreliable for the detection of the lid opening and closing. Maybe the more sensitive one works better?

I got the sensitive version, the SW18010P and tried that out. It indeed works a lot better, have a look:


It produces a large number of these very fast pulses when you tilt it or tap it. For this project, that would still work, but it seems not any more reliable or different enough to change it for the other vibration sensor. Al lot depends on the motion the lid will produce when it falls back down from opening it. It's also very appropriate for a door or window sensor, registering a break-in attempt as an example.


Optical light sensor

I also got delivery of another optical sensor, the OPT101. Using a sensor that does not have to be fixed to the lid is a major improvement, because everything can then be built in one box, and there are no wires going to the sensor mounted on the lid.

I built a little prototype with it, and initially, it seemed to work very well, just waving my hand above it would activate it. However, when I put it in the carton shoebox that would mimic the letterbox, I did not get enough light on the sensor to make it work. It's not sensitive enough for this application, even though I increased the gain.



Optical PIR sensor

I also ordered a small IR motion detector, I saw it was used in a mailbox alarm project where the designer sold his result. It uses one of these small sensors.

When I tried it, it worked very well, even within the concocted shoebox replacement, but as I already feared, it only reacts on Infra-Red generated from warm bodies. In other words, it will only work when the postman puts a bare hand for the opening, but it does not react on any light. This will be a very unreliable detector for my particular mailbox. It may be better suited for the US mailboxes that have a much larger opening. I had high hopes for this sensor, but alas...


Tilt switch

The tilt switch I also found while searching for alternatives is so far the best replacement for the mercury switch I'm currently using. As you can see in the picture that I borrowed from Adafuit (https://learn.adafruit.com/tilt-sensor/overview), it uses two balls that roll around and make contact when the device is up-right. Same as the mercury switch.


The ones I ordered arrived and seem to work fine. 


Changing the processor

I had a few issues with putting the Nano to sleep, and waking it up. Also these boards are a tad too large to my liking as well, so I switched to the ESP8266 based WEMOS D1 boards. I use a number of them in my home, measuring many environmental "things" and I always have a number in spare to play with. They have enough available pins to interface to the LoRa board and they can be put into a deep sleep mode with one instruction, while they wake-up when the RST pin is momentarily pulled low.

I'm using a clone of the WEMOS D1 Mini, the GY-D1MINI. The major difference is that it uses a SCP2104 USB to UART bridge, instead of the CH340C, which calls for another USB driver on your PC.

Unfortunately, although there are many variations and models, I have not been able to find a schematic for this particular board.





The proof of concept prototype

To try out the concept, I put together the following circuit diagram, build that on protoboard, mounted it into a small plastic enclosure and mounted the contraption with double sided tape inside the letterbox.


To keep an eye on the Lipo cell voltage, I use the on-board ADC to measure the cell voltage. I used a 120K resistor that works together with the on-board attenuator to keep the voltage within the ADC range. 

To get a more reliable communication, the sender sends a text message that it has detected mail. This message gets verified by the receiver after it than sends an acknowledgement. The sender waits for the acknowledgement, but if not received after a short period, it sends the "I got mail" message again, up to 5 times. After receiving the acknowledgement from the receiver, it would also measure and send the cell voltage to the receiver. On the receiver side, I use an LED to signal a low voltage, set at 3.4V. Reading the cell voltage just after activating the LoRa board, which uses about 100mA while transmitting, ensures that the cell is at the lowest level when I measure it, although the voltage will creep back up a bit when the circuit is put to sleep again.

This worked really well until I did not get any alarms anymore. It turned out that the so called 500mAh Lipo cell drained before mail arrived so I did not get the low battery warning. Bummer! At that time, I set the cell voltage warning at 3.4V, but later I figured out that this was way too low. Due to the voltage drop over the 3V3 regulator, an ME6211 with 260mV dropout, it very well could have resulted in a voltage for the ESP8266 and the LoRa board that was below 3V, at which level they stop working reliably or at all.

First of all, the 500mAh cell capacity was inadequate to begin with, but it is what I had. I had measured the two cells I have several years ago and they showed to have a capacity of only 274mAh and 260mAh.

Because I used the on-board 3V3 regulator  on the WEMOS D1 mini, by the time the cell produced less than 4V, the 3V3 voltage regulator started to drop the voltage, so I did not get much of a useful capacity to start with. I knew that, so I ordered two new LiPo cells with 2000mAh capacity. When they arrived I put one into the letterbox.

Here is a discharging curve for the 2000mAh LiPo cells I'm now using:


This graph was generated by my DC Dynamic Load in the Battery Test mode. That recent design is described elsewhere on my Blog. It shows a couple of things. First of all the discharge curve was made with a constant 200mA (1/10th) of the rated 2000mAh for the cell. The measurement shows that it's not quite up to the specification at 1889mAh, but close enough. It took 9 1/2 hrs to discharge it from fully charged to the 3.0V cutoff setting. The sender circuit should draw about 20uA when in deep sleep, and about 100-150mA when the LoRa module is transmitting for a few seconds. 

When you look at the discharge curve, you see some hash that goes away after 210 minutes. This is only the second time I'm discharging the cell, and from other tests, I'm assuming that the hash can be attributed to the chemical reaction within the cell. This is why I use a 220uF capacitor to smoothen that.

More about the cell voltage later on.

I installed the prototype board into a small enclosure and taped it to the inside of the letterbox with double sided foam tape and used two thin wires that went to the mercury switch that I taped to the lid. I also mounted a small connector to be used for the LiPo cell such that I can replace it without opening the enclosure. The cell is also taped to the side of the letterbox.

This prototype is working really well for a few weeks now. They major issue is that normally, I do not get a lot of mail. There may be days without any. The cell voltage only gets send to the receiver when there is mail, so there is too much of an opportunity that the cell gets depleted before I get mail and I'm unaware of this. I need to find a way to avoid that.


The receiver

The receiver basically has the same ESP8266 and LoRa module, but the circuit is enhanced to give audible and visual information. The receiver is located in the apartment where we can hear it beep, see the LED's and reset the alarm.



This circuit is powered by a 5V USB wall wart connected to the WEMOS D1 mini micro USB input connector. There is a beeper/buzzer that will activate when mail is received and it will beep 5 times. An LED is turned on so you also have a visual indication that mail is received.

You can reset the alarm by a push button. 

Another LED will be turned on when the receiver is notified that the LiPo cell in the receiver module is below the cut-off voltage, I currently have that set at 4V or below.

I'm actually actually using the ADC input to measure the activity of the reset switch, because I can out of digital inputs. The D4 pin is connected to the on-board LED, so I don't want to use that.

At this moment, I'm programming the LoRa module with the standard configuration parameters at boot-up, because I have no other LoRa transmitters nearby. 

The parameters that I currently use for both devices are: 

    Adrs=0, Ser=8N1, 9600bd, Air=2.4Kbps, chan=23 and pwr=20dbm.



Enhancing the sender prototype

I needed a low voltage alarm for the LiPo cell that would wake-up the system and send a distress signal apart from the mail alarms. That took a bit more time to design, because the RST wake-up signal must be a momentary low, not a permanent one. So although I started out with a very simple low voltage indicator, testing showed that I needed a bit more logic to create a more reliable and correct wake-up signal to kiss it out of the deep sleep.

Below is the updated but still evolving schematic.




From left to right...
The LiPo voltage warning is generated by the comparator through the sense circuit R1, RV1 and R2 for a trigger at 3.2V. The output is going through a capacitor to create a negative going pulse that triggers the CMOS 555 timer. R11 and C5 create a pulse output of about 50mS, that needs to be inverted by an N-FET to drive the RST input momentarily low to wake-up the ESP. (I first used a transistor pair but was not happy about it and it also used quite a bit of power) I also have a voltage supervisor on order and may add that to the layout as an option. The comparator is one that I had left from another project, but you can use anything that fits the SOT 23-5 foot print.

So whenever the LiPo cell voltage is getting below 3.2V, a distress signal will be transmitted to the receiver, which in turn will switch on an LED so I can see that the LiPo needs to be swapped-out.

A cell voltage of 3V2 has enough head room for the voltage regulator to provide 3V1 to the circuits.

This section of the circuit is not yet implemented in the circuit that is now in the letterbox. It is still in prototype form on my desk (see below) because it's too finicky to implement that on protoboard. That will have to wait when I have fully tested the LiPo supply circuit and a PCB designed. More about that later.



The activation sensor that is fixed to the lid of the mailbox, should send a low pulse when the lid is opened. The position of a tilt sensor should be such that the contact is open when the lid is down, but shorts when the lid is opened. A vibration sensor will have a much less critical position on the lid, as it reacts on any movement of the lid. After quite some consideration and testing, the sensitive SW-18010P is the sensor that I decided to use. 

The sensor creates a momentary negative going level on the RST input, waking it up for an "I got mail" message. This can be important when you use a tilt sensor and a larger package is stuffed in the mailbox that keeps the lid open. This 555 circuit will still produce a wakeup call. Without it, the ESP would be held in a permanent reset, and I would not get the "I have mail" message.

The LoRa board is connected to the ESP such that the ESP can initialize the LoRa board, and send or receive messages by using a software serial interface. That means that I can still use the Micro-USB or USB-C port to upload new firmware and monitor what it is doing by using the hardware serial port.

I added a reverse polarity protection and a fuse for the Lipo connection to prevent a possible to short of the LiPo cell or destroying the components on the board when the wires to the LiPo connector are swapped. I'm using a key'd connector, but not all cells have the same pin-out.

Whenever there is a mail alert, I also measure and send the LiPo cell voltage to the receiver. The receiver will react on a cell voltage that is deemed to be too low, so we don't need to wait for the distress alert alone. The combination will ensure that I detect the low cell voltage even when I don't receive mail for several days.  If I get the alarm and both LED's are on, I need to swap out the LiPo cell.

Right now, for the prototype that is in the mailbox, I first used the LiPo cell directly to feed the 5V input of the WEMOS. That worked well for quite some time, but to get more mileage out of the cell, I temporarily installed a little boost convertor module that uses the LiPo cell as the input, and I adjusted the output for a 5V1 voltage, and that goes to the 5V input of the WEMOS so there is a reliable 3V3 to power everything. I did find that the Lipo discharged after about 2 weeks already, partially due to the cold weather, but I need to investigate that further.

I added the components for the receiver to this schematic, so I can create one PCB that can be used for both, to save cost.

Using a LiPo cell to supply power

It took me a while to figure out how to do it, because it's not so obvious. Let me explain.

Supplying the +5V input?

The ME6211C33M5G on-board voltage regulator on the WEMOS D1 (and the clones) that creates the 3V3 rail, feeds the ESP8266 module itself and in this design, also the LoRa module. This is a voltage regulator that, according to the datasheet, should have a 120mV drop-out voltage at 100mA and 260mV at 200mA. I measured that the 3V3 output starts to drop at an input voltage of 3V4, which confirms that. When the LoRa is transmitting however, the current will go up, and the drop out voltage will raise with it.

This limit of at best 3V4 by directly feeding the LiPo cell into the 5V input is reducing the usable capacity of the cell to about half, see the discharge graph above. I want to try to wring some more life out of it, thereby extending the time I need to swap it out.
Technically it works, but for this application it is a no for me.

Supplying the 3V3 input?

Can I use the LiPo cell to directly feed the 3V3 voltage inputs to the ESP and the LoRa module?
The ESP-12F module which is on the ESP8266 WEMOS D1 mini, has a voltage rating of 3.0-3.6V. The E32-433T20D LoRa chip has a voltage rating of 3.0-5.5V. It seems the LiPo cell voltage can drop all the way to 3.1V to have a bit of a safety margin. 

Fully charged, the cell has a voltage of around 4V, which is too high for the ESP module. 
So I can't use the cell directly. 

Using the LiPo with a different supply option

Using an "external" very low-drop voltage regulator will be the answer. 

This seems simple enough, but wait...
The problem to watch out for is going to be back-feeding from the 3V3 regulator on the WEMOS board when I connect the USB cable for debugging or uploading because there is no series diode or diode across the 3V3 regulator as protection on the WEMOS board. The USB 5V has a series diode to prevent back feeding to the connected PC, see below. I need to make sure that the regulator I'm going to use to power everything never exceeds the 3V3 of the WEMOS regulator. That should not be a major issue because my plan is to use a 3V1 supply rail to get more mileage out of the LiPo cell.

Eliminating the USB 5V back feeding into to the circuit

This is only an issue when you connect the circuit to the PC through a USB cable for testing or uploading new firmware. It does no harm, but will mess with the voltages on the receiver board, in essence lifting them up to 3V3. If you want to prevent that from happening, there is a fix. Here is the relevant portion of the schematic that fits most WEMOS variants. There could also be a 100K resistor from the EN pin to GND on some boards.


The 5V comes in through the USB connector and is fed through a Schottky diode (D2) to prevent back-powering the PC when you apply 5V directly to the WEMOS board. (BTW, I have never seen the 500mA fuse used on all the different boards I have).

In any case, the +5V goes to the 3V3 voltage regulator U1 and also to the USB to UART chips.

The three WEMOS variants I have use the CP2104 or the CH340C USB to UART chip. Even though the 5V is going to these chips, they function without it. I tried.

So the most simple solution for the USB power back-feeding into our circuit is to remove the series diode on the WEMOS board, which will prevent the USB supply to feed the 3V3 regulator. This Schottky diode is D2 on the schematic and can be easily removed. I removed it and applied 3V3 to 3V0 to the 3V3 pin on the board to power it and everything, including the USB serial monitor still works on both of these boards.

The location of the diode is pointed to by the arrow for one of my clones.



On the other clone with the CP2104, the diode was located to the right of the 5V pin and is already removed.



With the diode removed, there is no +5V going to the 3V3 regulator on the WEMOS board anymore, so a further refinement could be to also pull the +5V pin on the connector for the WEMOS board to GND, because that will also pull the EN(able) input from the 3V3 regulator down, and disable it. I tried it and it worked, although I did not test the back-feeding by applying a voltage higher than 3V3 and see if the regulator survived.

If you want to go really go fool-proof, you could also remove the ME6211 from the WEMOS board.

Using an external voltage regulator

While searching for a variable voltage regulator with a very low drop-out voltage, I found the TPS73101. The dropout voltage for this regulator is typically 30mV to a max of 100mV at 150mA, and only has 1uA current consumption which is all great. LCSC carries the part so I ordered a few of them which will arrive soon.

The output voltage of the regulator can be set by two resistors. I was planning to use 50K (2 x 100K parallel) and two resistors in series (27K+4K7) for a 31K7 value to set the output voltage to 3.10V, which is sufficient to power the critical components. The parallel resistance is 19K4 and very close to the recommended 19K. Due to the very low drop-out voltage, I'm planning for a 3V2 alarm, so I know it's time to swap out the LiPo cell for a fully charged one.

This also means that I can draw on the LiPo cell for just about the maximum 2000mAh capacity.

The voltage regulators arrived and to try it out in the prototype, I soldered one of them on a DIP carrier board. I then found out that the adjustment to get a precise 3V10 output with fixed resistors is too finicky. You would have to use three in series to get a precise output value so I'm now using a trimmer instead. That, plus some other minor value changes resulted in an updated version of the schematic above.

I took out the sender prototype contraption from the mailbox so I can test a few more things, especially to have a more detailed look at the current consumption. When I'm satisfied, I can start to create a PCB. The current plan is to create one PCB that will accommodate both the sender and the receiver to cut cost.

Change the on-board regulator

One alternative is to replace the on-board 3V3 regulator with a low drop 3V3 version. This will limit the available capacity of the LiPo cell to about 3.35V, but may be a viable alternative. The PCB that I am designing will support that option, you can just leave out the 3V1 circuit components and modify the software.


Current consumption analysis

Analysis may be a big word, but I tried 4 different ESP8266 board after I noticed that the current consumption in deep-sleep was much higher than I expected. I tried all four versions that I have with my prototype. It currently, does not have the LoRa module installed. That will be next.

Here is what I found, while powering the board with 3V2 applied to the 3V3 "output".

GY-D1MINI
This board uses the SIL2104 UART and consumed around 26mA when running in setup and 6.4mA in deep sleep. This is the one that I used on the prototype on my desk and the amount of current in deep sleep got me confused. It has the ESP-12F metal can module mounted on the bottom. It also has an LED installed that is connected to the UART, that cannot be turned off in software, at least I could not find how. There is a D2 on this board that can be removed.

With 6.4mA, this board has the highest deep-sleep current consumption.




D1 Mini clone
This board uses the KH340G UART. It is what I had in the letterbox. This board has the ESP8266MOD metal can module mounted on the bottom. It consumed 20mA in setup and 195uA in deep sleep. There is an unmarked D2 on this board that can be removed.

Apart from the WEMOS D1 Mini V4 below, with 195uA, it has the lowest current consumption in deep-sleep, about double the V4 board below, but that has another significant problem.




Unmarked D1 mini clone
It looks like this board uses the KH340G UART, but the markings are removed. It consumed 19mA during setup and 250uA in deep sleep. It has the ESP8266MOD metal can module mounted on the bottom. There is a D2 on this board that can be removed. Unfortunately, I can't find a schematic for this board. I wonder where the two large diodes just above the USB micro adapter are for.




WEMOS D1 mini V4
This board uses the KH340C UART. This board has a connector for an i2c interface and a USB-C adapter. It does not have the ESP8266 metal can on the bottom but uses the ESP8266EX chip. The board also has a 32Mb SPI flash chip and an ME6211C33 voltage regulator. According to the datasheet, it has a 100mV drop-out at 100mA. 

The board consumed 19mA during setup and just below 100uA in deep sleep. This board has no "D2" installed, so the USB 5V always feeds the on-board 3V3 regulator when connected to a PC. 

With 100uA, it has the lowest current consumption in deep-sleep, about half of the best of the rest.

A real gotcha with this board!

The major draw-back for this board is that it has a different pin-out. The pinout is actually flipped upside down compared to the all the other boards I have, making it somewhat of a tricky layout decision because you can only use the other boards mounted upside down. Compare the bottom markings with the boards above. All the other boards I have were always mounted with the USB connector on top. To do that with this board, you would have to mount it horizontally flipped to keep the RST pin in the upper right-hand corner, and adhere to the same layout. Strange, and a serious cause for a bad layout.





I also have an Adafruit HUZZAH but that does not have a USB connector and AI-THINKER modules which are larger, so are not candidates.


Removing D2, do or don't?
While trying all these boards, I found that there is no urgent need to remove the D2 diode, as long as the voltage rail of the letterbox sender is below 3V3, which it should. Just be careful when you are fiddling with this supply voltage and keep it below 3V3. What does happen when you leave D2 in the circuit and have the USB cable connected to your PC is that the WEMOS board will supply current from the 3V3 regulator to the receiver, and lift the voltage to 3V3. In that situation, you can't test the battery cut-out circuit or accurately measure the current consumption. Keep that in mind.

The overall current consumption of the circuit without the ESP or LoRa is 550uA at a cell voltage above 3.2V, and then goes up to 835uA when triggered. With the ESP at deep-sleep, the total consumption, still without the LoRa is below 1mA.

Just measuring the LoRa board by itself shows that when there is no activity, with the ESP in deep sleep, the LoRa board only draws 1.8 uA. When sending, it consumes at least 110mA in bursts for a very short time.  

The screen shot below was taken through a 10R resistor in series with the VCC of the LoRa board, which is fed directly from the LIPO cell, to not produce voltage sags in the 3V1 rail, which could trigger a premature low batt alarm.



Luckily, I don't need to turn the LoRa board power off in the sleep mode.

Protection fuse

I initially added a 100mA PTC fuse in series with the LiPo cell, with an attempt to avoid serious issues that can be caused by connecting a LiPo cell. What you have to take into account however is the voltage drop over the fuse, the tripping voltage and the time before it trips. I'm not an expert at all, but it looks like a 100mA PTC will trip at 200mA and will take about 2.2 seconds before it trips. (this is the part I have and looked at: a radial RXEF020 from Littlefuse) It has a resistance of 1.8Ohm at room temperature.

In deep-sleep mode, the drop is only 1.3mV, but increases to almost 150mV during the LoRa transmissions. 

That's quite a lot for this application, and I don't like the long tripping time, so I'm changing the fuse type to a fast THT Pico fuse of 250mA. Because I'll rather be safe than sorry.

Reverse Polarity Protection

The other safety measure I took was to add protection for a reverse polarity connection with the LiPo cell. I'm using a connector with a key, but not all LiPo cells come with the proper orientation of the wires. That can easily be fixed by swapping the leads in the connector, but you really don't want to have it wrong, hence the addition of a P-FET. The AO3401 has an RDSON of  60mOhm at 4.5V and 85mOhm at 2.5V, so it will be somewhere in the middle. The voltage drop of that device is not a concern.

Rail buffering

With everything connected and working, I looked at the power rails in more detail, because I noticed a sagging when transmitting.
It turned out that I had to use a 1000uF capacitor on the 3V1 rail, and another one on the LiPo rail that supplies the LoRa board, to reduce it considerably.

This is the 3V1 rail without any electrolytes:


One 1000uF added to the 3V1 rail:


Another 1000uF added to the LiPo rail:


This was taken with my Lab Supply with 2ft leads powering the prototype with 3V3.
When I switched to the LiPo that had 4V with very short leads, this was the result:


Obviously, this is with the prototype on proto-board, which is notorious for poor connections, but still...
Something to keep an eye out for. As a result of this observation, I've added a capacitor to the base of the voltage trigger transistor, with an attempt to not let it trigger on a sagging of the rail during transmission.

There may be a potential issue with the power-up of the ESP due to this added capacitance. The chip will go through a voltage ramp-up that may cause instability. I will look at that later in more detail, but right now it does not seem to be an issue.

Update: When I looked at the rails again with the PCB version, there is no more sagging. There is still a lot of hash just about everywhere when the LoRa module transmits, but that seems to cause no harm.




Next step

With the design pretty much done and functioning pretty well in both hardware and software, I started to design a PCB, and I used a board outline based on the Hammond 1593L enclosure I want to use.

However, while thinking some more about the consequence of adding the large electrolytes (or a super cap) on the power rails, and the potential start-up issues for the ESP (it spends some time in the unstable zone due to the slower voltage ramping up), I considered using a voltage supervisor. This chip would keep the ESP in reset until the voltage is stable. While looking into possible candidate solutions, it dawned on me that I could use one as a cell voltage alarm, and eliminate the two transistor voltage sense circuit. Alas, I did not find any with a trigger voltage of 3.2V, and only a single one with an adjustable input that is more or less commonly available, the NCV308MTADJT1G or the equivalent NCP model. I ordered two NCP versions and will try them soon. This chip draws only 1.8uA, so is a significant enough improvement on the power budget as well. Because I was not happy with the two transistor trigger circuit, I redesigned it using a comparator. I will try to add the layout for the voltage supervisor for the trigger so it can be used as an option. When I have the PCB, I can better determine if I need the extra electrolytes and also if the ESP will experience power-up issues.

Initially, I was planning to set the 3V2 trigger level with resistors, but after I changed the resistors to much higher values, I did some calculations for the proper values and decided to make it easier, albeit with the expense of another trimmer. 



The above schematic is what I used to the create a PCB. It has the optional MCP308 voltage supervisor chip that can be used instead of the TS881. Note that I'm now using the WEMOS D1 mini V4 that KiCad supports but with the flipped pinout, because it has the lowest current consumption. Other WEMOS D1 boards can still be used when they are mounted upside down.

The same board can be used for both the sender and the receiver. Several parts can be omitted or added to suit either version.

When I received the boards from PCBWay, they looked perfect as usual. The position of the drilled holes is exactly where they need to be, I always look for that as a quality indicator, and the silkscreen is crisp.

Spoiler alert: I successfully reflow soldered the boards on my new hot plate prototype. That is a project that has been under development for a while, in parallel, and I will start a Blog post as soon as I finish this project.

I build the sender version and started to test it out. The 3V1 adjustment is a little sensitive but easy to do. After having done that, I could now also adjust the 3V2 cell voltage alarm setting. I used a power supply instead of the LiPo cell, so I could finely adjust the voltage and set RV1 to a 3V2 trigger point.

When I then tried the sensor to activate the mail alarm, I noticed a goof in the schematic and subsequent layout. The sensor input is going to the wrong end of C2, meaning that a tilt sensor would continue to keep the 555 timer and the RST signal for the ESP low, not allowing it to boot if the mailbox lid stayed opened due to a large package. I cut the trace and used a small wire to attach the signal to the "right" side of C2, and that worked well. Of course. But that also got me thinking. A tilt sensor has to be positioned a little slanted to make the contacts short when the lid is opened. The lid opens just above 90 degrees in a normal opening position, and about 160-170 degrees when fully open. I was envisioning a 45 degree angle, with the sensor upside down in the open position, which is what I used with the mercury switch as well. 

However, when you use a vibration switch, this all does not matter. So after quite a bit of testing and contemplating, I decided to use the sensitive SW-18010P sensor. I modified the layout to accommodate this change so that will be on the GithHub, making the board more universal.

Below is version 2.3b that incorporates this minor change.


When I tried to activate the LoRa module, I was seeing weird behaviors. It turned out that I made another layout mistake and swapped the board connector 180 degrees. I fixed that for my two modules by removing the connector from the boards, and soldering a new connector to the other side so I could mount the boards upside down. The layout error also has been fixed and is below with version 2.3b. 



With this board, I used the TS881 comparator, not the MCP308 voltage supervisor.

When you think you are done...

When I further started to test everything, I ran into a few more issues. First of all, the comparator worked really well detecting a low cell voltage, but caused an oscillation during the low bat condition. When I applied 3.2V, it triggered but also resulted in a continuous reset of the ESP at this voltage. The rail goes up and down a fraction when the ESP is awoken and the LoRa module transmits. I hoped that the disabling of the 555 timer by software would prevent this, but it didn't. The normal practice is to add some feed-back to the comparator to create a hysteresis, but with the high value resistor values I selected to cut down on the current consumption, this would need to be in the 100M+ range. I don't have these values, and it also really messes with the resistor selection.

So, it was time to activate the optional voltage supervisor and see if that would improve matters. The NCV308 has an internal hysteresis, so that should help.  I calculated a workable set of resistor values and changed the circuit on the PCB and gave that a try. Presto, problem solved! This is a much better solution.

Next I also experienced strange reset issues with the ESP modules. Some of them need a very long reset time, at least 5 seconds. At first I didn't know this, but after some Googling I found that this is normal. This reset issue is unrelated to the voltage rail capacitors on the board. It's just the way it reacts to pressing the on-board reset button. This was kind of strange and unexpected for me, because the other ESP modules I tried earlier had an instantaneous reaction to the button, or shorting the RST pin to ground to wake it up from deep sleep. 

The result of a too short reset pulse was that although a mail or low cell voltage was detected, the WEMOS D1 mini V4 did not fully reset and restart. It did something, because I got some weird characters on the serial monitor (due to the used Baud rate by the kernel). That problem was solved by changing the 555 timer setting to produce a more than 5 second reset pulse. 

And then, I suddenly, out of the blue ran into a myriad of issues (error messages) when I was trying to upload new firmware to the ESP boards. After a lot of searching and head scratching, I figured out that the CH340 driver that is needed for most ESP boards has to be an older version than what I had installed. The latest driver will not work properly with these cloned versions of the CH340, and will give all kinds of communication errors. I had fixed that issue a very long time ago, which is why I couldn't figure it out at first. It turned out that the older driver that I installed a long time ago and worked, got automatically(?) updated to a newer version. Be aware of this issue, it cost me several hours chasing it down. The older version number for the driver that works for me is 3.4.2014.8 and has a date of 8 Aug 2014. Here is a site with a description of the issue and where you can get working drivers: older CH340 drivers.

Because the WEMOS D1 mini V4 had more serious issues with the reset duration, and I also was struggling with the serial port, I tested some of the other ESP boards that I have. Eventually I picked one that did not have the pins soldered in yet, so I could mounted it upside down in the circuit. It worked well, so I just left it there.

To accommodate boards that have this 5s reset issue, I selected the timing components for the 555 timer to have at least a more than 5 sec reset time, using worst-case component tolerances.

Finally, I ran into mysterious reboots when I thought everything was working. It turned out that the sensitive vibration sensor version (SW-18010P) is so sensitive that it continuously activated the trigger circuit and restarted the ESP. It was just lying still and untouched on my desk and still produced random triggers. The very fast needles it produces are very hard to see on the DSO, and I simply missed them for quite some time. Replacing the sensor to the less sensitive version (SW-18020P) solved that issue as well.

So finally I got a functioning receiver and a sender.



To the left is the sender that will go into the mailbox. The lower right white connector is for the sensor, and the upper right one is for the LiPo cell. This board has the WEMOS D1 mini clone installed in the upside down position.

The receiver is on the right, and only has three resistors soldered on the board for the LED's and the reset switch. They connect to the bottom three connectors. Two polarized white ones for the LED's and the middle one for the reset switch. The black round device is the beeper. This board currently has the WEMOS D1 mini V4 installed. 


Final current consumption

With everything working and populated, it was time to do another power consumption analysis.
I applied 3.6V to the sender board with my power supply and measured the current with my DMM.

With both the WEMOS D1 mini clone and the LoRa module added, the total consumption is 1.07mA with both modules in deep sleep mode. With the WEMOS D1 mini V4, the total consumption dropped to 940uA. This is higher than I hoped for, but the best I can do. I'm going to keep the clone installed for a longer testing period.

My assumption is that with a 2000mAh LiPo cell, I would get enough time in-between charges. Time will tell.

The sender is installed in the mailbox and the receiver is on my desk so I can try it out for a few days.


Fitting it in mail box

The mailbox lid sensor types you can use can be two-fold, depending on your mail box and more importantly, the lid. 

Below is a picture of my mail box. The lid is positioned at the top and swings outside to just below 90 degrees. This is a problem for most switches because they may not react well, so you need to position them at an angle. I experimented a lot, even tried the tilt switch with zirconium magnets that would lift the luckily magnetic balls inside the switch free of making contact. However, I did not like that construction at all. I needed several magnets, and they were glued to the lid. They stuck-out too much, and could be broken off when the mail is inserted.

The challenge I have is that I don't have much room, and the construction is severely limiting my activities. Just below the lid is a ledge of about 2 cm, so I can't really position anything below the lid. That would be too easy.

After many attempts, I decided to go back to using a vibration sensor, that is attached to the lid. When the lids drops down into the closing position, it should jolt the vibration switch enough to give me a reliable signal. I contemplated using the sensitive version, and I tried it, but that one is really too sensitive. I suspected that a neighbor ledge dropping down could already trigger mine.

The actual sender enclosure is taped with double sided foam tape to the top of the mail box, close to the door, so it's out of the way. The LiPo battery holder is mounted on the left side in the very front near the door, and raised from the bottom so it won't get bumped by large packages.



Another (last?) improvement

Depending on the sensor type, you need to connect them on either side of C2. A switch, because it can stay open with large packages, needs to go through C2. Vibration switches on the other hand produces pulses, not a level, and they can be connected either way of C2. I modified the schematic and now include a solder bridge so you can select either one.


The updated schematic and layout







When I have successfully tested this setup for a while, I will publish all the information on my GitHub.
Stay tuned...!

A real gotcha!

While I was testing, I ran into all kinds of seemingly spontaneous triggers, and worse of all, the system would get into a reboot cycle and never went to sleep. So I did not get the mail message, and the cell was draining fast. After a lot of trying and testing on my bench, it would 99% of the time work fine, but as soon as I travelled the 3 flights of stairs down and installed in the letterbox, it would 100% fail and reboot all the time. I traveled up and down the stairs a lot trying to figure it out. 

Because the sensor is mounted on the lid and the leads are going through a small plastic conduct, I would leave that in the mailbox and just took the enclosure and the LiPo cell with me. When I was testing it on my bench, I would simply short the input connector the simulate a trigger. It always worked so I could not find the root cause of the error.

Eventually I got so frustrated that I ripped the sensor with the wire out as well, and put that on my desk. Then I had a hunch that the transmission signal could enter the sensor leads, and indeed, as soon as I wrapped the leads around the antenna a few times, I could verify the reboot problem. The solution of course is to use shielded cable so close to the antenna. When I did that, the problems went away. Keep that in mind.

I will continue to test for a few more days.

Stay tuned...

Conclusion

We normally don't get a lot of mail, sometimes days without anything, but in the current busy Christmas period we get mail all the time, and the prototype was functioning very well. When I took it out of the mailbox and started to work on the PCB's, we really missed getting the "I have mail" message, that we so quickly got used to it. This is a keeper!



Friday, April 5, 2024

Designing a DIY DC Dynamic Load Instrument

 





The Design Process of Building a DIY DC Dynamic Load

The conclusion of a very long time investigating the building of a combined AC-DC Dynamic Load (DL) led me to the realization that this is not really possible. At least not without making drastic compromises about accuracy and precision. The AC measurements do not need to be very precise and are, in my case, only occasionally needed, but DC measurements typically need to have the highest precision, stability and accuracy.

The attempts for this combined AC-DC DL are described in another Blog post. There is a lot of information there, so get some fresh Java and have a look. https://www.paulvdiyblogs.net/2022/08/dynamic-acdc-load-cc-cv-cw-batt.html

The above picture shows a stage in the development with the new DC DL prototype as the basis.

To help design this new version of the instrument, I asked for the help of my friend Bud. He is a real designer, and we've done a number of projects together, like the high current RPi UPS, the VBA Curve Tracer and the 100MHz Differential Probe all described on this Blog in different posts.

Bud started a Blog post on Hackaday mostly for the hardware design aspects that can be found here: Dynamic Electronic Load | Hackaday.io I have added that same information in a section below here, so it's all together in one place.

At this moment, we have finished the design of the new version and the final board V5.1 has been produced by my sponsor PCBWay.

Although we have a stable fully working system, I'm still tweaking the software side a bit, because this instrument will do some things a bit different, compared to many other DIY DL designs.

I'll explain that later in more details but here are some pictures to hopefully wet your appetite from the previous prototype V5: (this is almost the final version, read on...)



Specifications:

  • Input voltage: 1..100VDC.
  • Reverse polarity protection to -100V and a 10A fuse.
  • DUT is disconnected by a relays for invalid inputs like reverse polarity.
  • Maximum current of 10A @ 40V
  • Maximum power 180W @25 degrees ambient temperature (heatsink temp 85C)
  • Off state DUT current 1.9uA at 2V, 57.7uA at 60V.
  • Volt Accuracy: 0.4%
  • Current Accuracy: 0.4%
  • Power input: 12VDC Wall-wart 0.5A with reverse polarity protection to -24V and PTC fuse
  • CC, BT & CV modes with real-time operation in hardware.
  • CP and CR modes have active regulation supported in software (resolution +/-156uA).
  • Pulse/transient mode supported by an external Function Generator. 5V=10A
  • Current monitoring with a DSO. 1V=10A
  • GUI: 128x128 OLED 1.5' color display and a rotary encoder with dual button functions.
  • Two temperature controlled fans.
  • Protection for over voltage, over current, over power and over temperature limits
  • Overall dimensions: 21cm long, 18cm wide and a height of 118cm.
  • Weight: approx. 1110 grams


Testing the V4 prototype

This earlier version for the AC-DC attempt is still using the Arduino Nano as the processor. It also had provisions for an on-board transformer, but that got too hot so I took it off.


The Nano is not fast enough to process the CP and CR modes, which are regulated in software. At this time, I was planning on implementing the CV mode in software as well, but that did not work at all with this prototype. While looking for a faster processor, I eventually settled on the ESP32. It has all that we need, even though we won't be using the BLE and WIFI capabilities.

This was the first time I really started to work with the ESP32 so I started to experiment with it. This processor is not only much faster than the Arduino Nano, it has a dual core and it has a native RTOS. (real-time operating system) I was hoping that these major features would overcome the Nano limitations.

In the picture below you can see how I tested the ESP32 in-place of the Nano. I simply took the Nano out of it's socket, and used jumper leads to connect to the ESP32.


The next step was to test the ADC that we were planning to use, the 16-bit ADC1115 instead of the on-board 8-bit ADC from the Nano. The on-board ADC for the ESP32 has too many issues, so we can't use it with this application. The ADC1115 has double the resolution, the down side is that the communication with the chip through i2c is very slow.


In the above picture you can see that I wired-up the ADS1115 ADC on a break-out board. With this prototype, I still used the 16-bit PWM functionality, but we were already planning to use a hardware 16-bit DAC.

So after checking and verifying the changes, this resulted in a new prototype, that we called V5.


Testing the V5 prototype

Version 5 incorporated the ESP32, the 16-bit ADS1115 ADC, the REF5040 4.096 Voltage reference for the DAC, the 16-bit DAC8571, test hardware for the CV mode and Bud's vastly improved circuitry to drive the MOSFET's.

Unfortunately, we discovered a few layout issues that we needed to fix by jumper wires and Manhattan style additions. We also found that the ADS1115 was happy with 3V3 i2c voltage levels, but the DAC, that we could not test earlier because of its tiny package, did not. That called for two bi-directional 3V3 to 5V level convertors, and I used a 4-channel circuit board connecting it Manhattan style to test that. To be able to increase the i2c clock speed, I changed the 10K pull-ups to 2K2.

We then figured out a slightly different circuit for the CV mode, eliminating an extra DAC that we were planning to use. Using that earlier method would actually be cumbersome to drive with the planned user interface so the new method uses two CMOS switches to automatically change the configuration to use the DAC for the CC mode and also for the CV mode.



Unfortunately, we also found out that the heatsink I was planning to use, that would fit nicely in the enclosure I also wanted to use, could not handle the heat transfer. Not even close. Not only did things got really hot, we were far away from the specifications! I measured the NFET package temperature at well over 160 degrees C, and the heatsink temperature rose to almost 100 degrees, and that at a mere 90W for only a few minutes. Bummer!

The obvious solution is to use a different heatsink with a significantly larger surface. 

Unfortunately, larger heatsinks are very hard to find, unless you go for the typical PC CPU coolers. The ones that are available literally tower above the NFET, and it's not easy to use them for two NFET's or find an enclosure for this construction. 

We found two heatsinks that looked promising and I ordered both of them. Luckily, the most promising arrived early, so we could start to test with it. This is the one on the left. It has the largest amount of contact surface. 

The one on the right relies on a fan at the end (or even both ends) to blow the air through. Unfortunately, that calls for a small diameter fan and they have difficulty getting enough air displacement, unless they rotate faster, making a lot more of a whining noise. Which is another reason why it is not my favorite.


The one on the bottom is the one I had been using. I purchased a number of them for other projects many years ago. I did an extensive search, but I could not find anybody offering them anymore. 

The different heatsink called for drastically different construction because the length of the leads to the NFET's and the critical components on the PCB are very critical. We did not want to split the NFET's and give them each their own heatsink, or mount them on either side of the heatsink.

This is why we ended-up with the contraption below to just try it out. It did not need many PCB changes, so was relatively easy to setup and test. The original fan is now moved from the top to the bottom, getting its air from the bottom of the enclosure. The fan is blowing directly to the fins of the heatsink. We will need to use a second fan to suck the hot air out of the enclosure, which has some ventilation slots.

 

The first test already showed that we could now easily handle 90W for quite some time, which was not possible with the previous setup. The enclosure we selected later required us to rotate the heatsink 90 degrees horizontally, so a fan mounted on the back panel can suck the hot air out.



A longer-term test at 150W showed that we were on the right track. Everything stayed at manageable temperatures.


At this moment, let me explain what you see on the above OLED display.

On the top, you see the actual DUT (Device Under Test) voltage in blue and below it, the actual DUT current value in green.

Below that is a line that shows the mode (CC = Constant Current) the NFET's are driving the DUT (ON)  and the actually calculated DUT power in Watt. The display is in red because the power approaches the maximum value and is there to warn the user.

Underneath the horizontal line is the parameter you set with the rotary encoder. The mA suffix changes with every mode. The last line shows the actual 16-bit DAC value (while testing) and the heatsink temperature in degrees Celsius. The color is orange to warn the user that the temperature is above 60, it turns to red above 90 degrees.

The colors are used to warn the user for conditions like over temperature (90), over-power (150), low (<1V) or negative DUT (wrong polarity), Voltage too high (>100V), over current (>10A), etc.

The discrepancies in the display values for set/actual current are caused by the fact that I for this test I didn't use the sense inputs yet so the drop in resistance due to the high power and long leads is not accounted for. Yet.

The User Interface to drive the instrument is kept as simple as possible, and I let the software do most of the setup underneath the hood.

The rotary encoder that you see mounted on the PCB is there so I can more easily test the setup with this prototype. It will later be placed on the front panel. In the CC mode, as you see above, you set the current by turning the knob. The knob currently has two speeds. If you turn it fast, the resolution goes to 10x so you get to your destination rather quickly. Short pressing the rotary encode button switches the DUT output to on and off, by turning off the drive to the NFET's. A long press switches to the next mode. You simply cycle through the modes in a loop, so from CC to CV, to CP, to CR and from the BT mode back to CC. When you switch to another mode, the output is automatically disconnected, and the instrument is prepared for the next measurement. The mA suffix you see in the Set line, changes with the modes, so from mA, to V, to W, to R and in the BT mode back to mA. There is no separate transient or "pulse" mode, because this feature can be used in all modes. That may not be very practical in all modes but the pulse functionality is as versatile as your function generator supports. (amplitude, frequency, pulse form, pulse width, rise/fall times and offset)

On the front panel, in addition to the rotary encoder and the OLED display, there will be two toggle switches, one for selecting the sense input terminals, and one to select power. There are two BNC connectors, one for the transient/pulse input and one for the DUT current output to a DSO. There will be an USB-C connector to the ESP32 that is required in the Battery Mode and also allows for updating of the firmware. And finally, two 4mm Banana connectors for the power connections and two 4mm Banana connectors for the sense inputs. Simple and efficient. And no, there is no keypad. It is not needed. I dislike keypads so did my best to design around it.


A suitable enclosure

The heatsink has been tested and verified that we can now easily get to 150W, but that is still outside of the enclosure. Because of the height of the contraption, we also had to find another enclosure that would accommodate this construction. Unfortunately, there are not many compact enclosures that answered our requirements.

We prefer a plastic enclosure, because the heatsink is connected to the DUT through the non-isolated NFET's and that can get up to 100V DC.

We also need to modify the enclosure to get enough air in and out. That's a lot easier to do with a plastic enclosure. And we want to be able to make a PCB-based front and back panel.

The height of at least 9cm dictates that you will get (instrument) enclosures that are very wide, and not very deep. They are unsuitable for our requirements, but it's up to the other makers to select what they want.

The enclosure we selected is from the company TEKO. They have many enclosure types, but we selected the AUS series that is pictured below. The top one in the picture below is the one I already used for several of my designs, and was planning to use. With the new hardware construction, it is not deep and high enough. The middle one is wider, but has the same height. We settled on the bottom one, the  TEKO AUS33.5.  TEKO is a German manufacturer but with a little Google-action, you can find them all over the world, and there are suppliers that send them all over the place. I use www.tme.eu a lot for my purchases, and they carry these enclosures.

So with this version of the prototype, I have been very busy with the testing, implementing and again testing the changes we needed/wanted to make, and all the while further developing the software.


Final Version 5.1 PCB

Based on the now fully working V5 prototype, we have redesigned the board for the new heatsink configuration and made several other changes and corrections. The PCB has been produced again by my sponsor PCBWAY. They financially sponsor this project by producing the boards and sending them to me for free. The turn-around is mostly within a week, and the quality is excellent.



The small TO220 heatsinks you see on top of the NFET's help to disperse their heat better, because they are in the forced airflow. Instead of one 4-pin fan, we now have two connectors (the white ones top left) so the first fan sucks fresh air to the heatsink and the second fan that sucks the hot air out of the enclosure. Both fans are temperature PWM speed regulated by the sensor on the heatsink.

We also switched to another OLED display source, because the one I purchased many years ago was no longer available. We selected a good quality and commonly available version but that has a different pin-out so we fixed that on the PCB as well.

Here is a quick sneak preview of the completed instrument . Note that I switched to even larger TO220 heatsinks on top of the NFET's to get rid of even more heat now that these fins are in the airflow of the second fan.

Here is an overview of the construction.



The unit has been stress tested with a 180W 15 minute test while using an IR-camera to keep an eye on the temperatures. I believe we can support 200W, but I don't have a large enough current source to test it out. 


Above is a picture of the completed instrument. The sheet metal front panel that came with the enclosure was used to experiment and try out the connections. It will eventually be replaced with a PCB that will have the silkscreen indicating the functions and connections.

Top left is the 12V DC power switch. The larger empty hole to the lower right of the power switch was a mistake. The power switch was in that position earlier, but it was too close to the ESP32 board so I had to moved it away.

The black oval next to it is the USB-C to USB-micro adapter providing access to the ESP32. The USB connection to a PC is required in the Battery Mode, and can also be used to debug the firmware or upload newer versions.

The four empty holes around the OLED display stem from an earlier attempt to fasten it to the front panel. At this moment, I use sticky tape to mount it. I have an idea that I will try when I design a PCB as the front panel that will not show any holes or screws.

To the right with the large knob is the rotary encoder that controls the setup of the instrument and the measurements.

Lower left is the pulse/transient input BNC connector. It can connect to a Function Generator. The input voltage is 5V for a DUT current of 10A.

Below it are the two 4mm Banana jack sense input connectors.

To the right is the sense toggle switch, switching the voltage measurement to the sense inputs or to the main inputs. Using the sense inputs is really needed with high currents, due to the voltage drop over the main DUT leads.

To the right are the main 4mm Banana jack DUT power connections.

Slightly above that is the DUT current monitor BNC connector. The output is 1V for 10A of the DUT current.

The back panel has the second 90mm fan mounted and also the 12V DC input connector.


Battery Test Mode

The Battery Mode application that runs on a PC, communicates with the Dynamic Load, sets-up the instrument and does the graphing during the run is available on the GitHub site. It's a single executable that you can install on your PC wherever you like, and you can run it from there.

There is a separate Blog post that has more information about the project here: 
https://www.paulvdiyblogs.net/2019/03/a-pretty-universal-battery-cell-tester.html
My project was based on the work from John Lowen and his details can be found here:

I modified the original code that was running on the Arduino, made it work in the ESP32 environment of the DL and integrated it into the main menu structure.

Below is an example of the Battery Test mode. I'm using a Lithium 3.7V 14500 cell. The cell is several years old and had not been used. The specification is 650mAh and I tested it with a discharge current of 2500mA. The cut-off voltage was set to 3V.

These values are entered into the Battery Test PC program below on the bottom left hand side.
The test is started from this program, and it sends the parameters to the Dynamic Load and starts the measurement. 

During the measurement, the display is refreshed with the parameters coming from the Dynamic Load, such as the voltage, the current, the time and the calculated mAh value, shown on the bottom right. The graph is dynamically updated during the measurement.




As soon as the Dynamic Load measures that the cell voltage has dropped below the cutoff voltage of 3V, the measurement stops and removes the load. 

Just above the green Test Ended message, the Controller Message shows a Serial Time-out, instead of the Cutoff Voltage, because it was waiting for another measurement that took too long to send the data. The DL terminates the waiting loop and restarts the reception of the setup parameters or a mode change automatically.

This was a test of an EFEST 14500 IMR cell of 650mAh. These IMR cells can deliver up to 9.75A for short periods, or up to 6.5A continuous. Bud and I used these cells in the Raspberry Pi 3 UPS, to supply enough voltage to let the RPi ride out a power glitch or let it power down safely. I had not used these cells for many years and just charged them again for a few times to run this test. 

With just over 550mAh, the test shows that the cell is no longer meeting the specifications of 650mAh, but is still usable.  

In order to test at higher currents, you really need to use the sense inputs, which I did. I also used a metal battery holder, plastic ones would melt with these high currents.
 
Note that I faked the Rated Capacity of the cell in mAh from 650mAh to to 2000, to overcome the calculated  time limitation in the software (rated mAh/current), which would terminate the measurement prematurely. You can save the details including the graph, and when you do, you can enter more information about the cell and also add the weight of the cell, which is a good give-away indication for poorly "specified" or plane fake cells.

When the measurement is terminated or ended, you can restart the measurement in the PC software and test another cell. Long-pressing the rotary encoder switch on the DL brings you back to the CC mode. The original hardware that was intended for this PC program would also re-start the Arduino Nano controller. We don't need to do that, the DL software automatically takes care of all that.