Feeding external power to a pysense board

[John Baird]

Hi All,
Since we can't seem to get the schematics for the boards, I'm looking for some advice. I have a monitoring application up and running on a GPy+Pysense. The system is normally in deepsleep, waking periodically to take measurements, or in response to an external wake signal, then reporting via LTE CAT-M1. The system works well, getting a couple of weeks out of the batteries. When the unit requires recharging it is placed onto a stand and an induction charger supplies power to recharge the battery (monitoring and reporting are suspended when charging).

My problem is that the only way to connect the power from the charging circuits to the board is via the USB connector. For one or two this is fine, but we plan to build around a thousand of these critters and I don't want to have to create a thousand dodgy power leads (not to mention the cost). We will make our own boards but for this first batch, I'm wondering how other people feed power to their projects? Does everyone use a USB cable, or has someone figured out the test connection points to use on the back of the board? If I inject 5v into the Vin pin can the board pick it up from there, or is that the wrong side of the charging/protection devices?

Dear Pycom folk - any chance of adding a second JST style connector in the future for power in? It would make things much easier, even on the lab bench.

Thx

[jcaron]

@john-baird Do you mean the I/O header (the 2 x 5 connectors), or the various test connection points? I don't think any of the former are suitable for this use, and I'm not quite sure how you could easily use the test connection points for your purposes (if any are actually usable for this, of course)?

[John Baird]

@jcaron either I suppose. The I/O header doesn't make Vin available, so there is no way to feed it in there. I looked at the PCB test points on the back of the board, but that would be messy and require manual work. I guess I'm stuck having to have a lot of micro USB cables created that can be fed from the induction charger, but I thought I'd ask...

Thx

[jcaron]

@john-baird Note that the USB connector is not really the sturdiest part on the board.

Depending on your setup, you may be better off charging the batteries using a separate device, and just switch the batteries rather than plugging and unplugging the USB connector.

Also sometimes minor tweaks can radically change the battery lifetime. A couple of weeks seems quite short to me, but it really depends on your use case (how often you need to wake up, how long you need to be awake during each cycle, and what you do during that cycle). What battery capacity are you using?

[John Baird]

@jcaron Thanks for the feedback.

Agreed. I've managed to "accidentally remove" a few PCB mounted micro connectors before and they are a pain to replace. That's part of why I am looking for an alternate power feed. Using the pysense board is an interim measure while we get to develop our own. It lets us test ideas quickly, but I fear the power feed may cause more issues than that is worth.

Unfortunately, these devices need to be sealed with minimum user interaction. That's why we are going with wireless charging, so there are no cables to plug in. A given location could end up with several hundred devices, so charge cables alone would be a pain and swapping batteries a non-starter I'm afraid. This does help with the power feed issue as no one will be poking around in there.

Total battery capacity can be altered, within limits, but that estimate was based upon the performance of a single cell LiPo rated at 2400mAh. In production, the first batch will have close to a total of 5500mAh. I'll keep working to extend the battery life, but these units will get charged every weekend and will alter the operator if they start running down so he can charge them that night. Right now attaching to the LTE network is taking to bulk of the battery. This needs to be done every 10 minutes, but I'm finding attach time varies from a few seconds to over 90 seconds.

Thx

[Martinnn]

@john-baird Coming from the micro USB connector, the +5V line seems to go through a chip ferrite and then a diode. Between those two there's a plated hole which looks like a good place soldering in a +5V wire.
Also look a the BQ24040 charger schematic http://www.ti.com/lit/ds/symlink/bq24040.pdf
Switching transistors are probably TT8J13, LDO is TPS78233.

Of course this is reverse engineering, let's hope we get a schematic... or maybe just design your own board.

[jcaron]

@john-baird If you have several hundred devices in a single location, does it really make sense to use LTE on each of them? Wouldn't you be better off using some other type of network locally and then have another device relay over LTE?

[John Baird]

@jcaron The devices are only all together at the end of the day. During the day they spend their life roaming around cities in trucks providing real-time information to a company and the drivers. Unfortunately the devices they are monitoring don't draw power from the truck, so permanent power isn't available (though we are looking at options). When plugged in at night to recharge they stop using LTE and switch to wifi where they share a single gateway.

[John Baird]

@martinnn Thanks for the information, it's very helpful. Given the quantity we require we will be designing our own board, but it would have been very handy to use the pysense for the first batch while we better understand the customers' requirements.

[SiMoS-IoT]

@John-Baird This might be a bit late but what about connecting the wireless charger receiver module through a TP4056 direct to the battery...that is how I solar charge my remote IoT sensors. I'm looking at using this approach for a FiPy/Pysense application.

[John Baird]

@SiMoS-IoT Thanks. Given the state of Pycom documentation and the large quantities we are going to need we have decided to build our own solution, so the power feed issue will go away. I really like the approach to power Pycom have, but the fact we can't get any documentation on how it functions, other than a few system calls, means we can't take it into production. I'll probably still keep using it, but only for interests sake.