I am putting my Photon into a box along with other components on a PCB. I am placing the Photon so that its USB connector is accessible from the side of the box. I wished to leave the USB available for diagnostic purposes. The unit will be powered by batteries inside the box.
If someone wished to use the diagnostic port and plugs in a PC to the Photon USB connector, will I need to disconnect the internal battery that is normally powering the Photon or can both the battery and power from the PC via the USB operate at the same time?
You really need to put in some kind of battery management circuit, specially if you are using a âdangerousâ battery such as a LiPo.
There is a diode in the USB-in leg of the circuit, but that is there to protect your USB port, not your alternate power source.
If you apply a voltage to a battery that is higher than the battery output voltage, you are effectively trying to charge it. So if your battery is putting out 3.7V, but your USB is supplying 4.4V, you are charging the battery, and that needs to be managed.
The solution can be as simple as a Schottky diode protecting the battery from being charged, or you could just build a circuit that allows the internal battery to be charged by the USB port.
But yes, any time that you are applying a voltage to a battery driven circuit, you need the appropriate circuitry to manage that correctly.
Thank you âAwakeâ. So the cost of deploying a product Photon-based application that does not require a PC USB port to keep it powered, will go up considerably from the cost of a Photon alone. The Particle power shield is $25 and the adafruit one is $20. Then add perhaps a LI battery and now weâre at a baseline of $50. Reduces margins considerably if you are interested in a production product coming in at under $100.
@jmosk - So at a minimum you need to add a Schottky diode to the positive battery lead in order to protect the battery from the USB voltage.
How long does your current prototype run on battery power alone?
Right now we have been running strictly from the USB connector to a PC while so we can check our diagnostic messages. But the application is a portable one so it will need to operate under battery power. I understand from threads on power consumption that I should turn to a lithium battery as its been reported that AA or AAAâs will only last a few days if the WiFi is operating continually as we expect. We just wish to leave the USB connector accessible by consumers so they can also plug into a PC and provide us with the diagnostic information we generate.
@jmosk May I suggest that you run some tests to see if your battery based design is usable. Continuous WiFi is very power hungry, and with AA or AAA batteries you may only have a few hours of operation. Even LiPoâs may only give you a day or two at best unless you manage connectivity and sleep cycles very carefully.
I guess I am going to need to take a close look at the power consumption of the Photon during WiFi operations. Unfortunately in this mobile application the Photon will be recording data nearly continually. So I donât expect it to be sleeping at all. It will be collecting information at least every second. Only after a data gathering cycle of several hours at a time, would it be potentially connected to a PC via its USB to dump its accumulated data via the Particle cloud. Perhaps, like a smartphone, I will just need to be sure to have the consumer plug the unit into a charger to replenish the power every day or two. So it is sounding like the integration of a power management shield is really essential for the application.
For gathering data, do you need the WiFi? If not, you could turn the WiFi off, and only enable it when it's being connected to a power supply, other than the battery. So when you put it in the charging station, it will upload its data.
You don't need a USB connection to send stuff over the cloud, that's what the WiFi is for(?)
Power management sounds essential for pretty much every battery-powered device.
No this application must keep the WiFi operating while mobile. It is actually in WiFi communications with a server/access point that will be transmitting data to the Photon while in motion. The Photon will be assigned a static IP initially so it can communicate with the server that has a fixed IP itself and does not support DHCP or Internet connectivity. Only after the Photon is done accumulating data that it then connected to an access point from which it can reach the Internet and Particle cloud.
If a power management shield is integrated in order to operate using LiPo or USB power, does such a shield provide any type of interface which would allow it to determine the level of battery power that might still remain in the battery? Or will some other circuitry need to be attached to measure remaining power. It would be best to display to the consumer how much battery power still remains in the device.
You can monitor the battery voltage to get an idea of remaining charge. If you feed the battery voltage to an ADC pin (with proper voltage limiting), you can read the voltage directly with the Photon, and then display it somehow.
I would just make the voltage monitoring part of the battery management system; many of the chips available specifically for LiPo charging have the status circuitry built-in.
Only after the Photon is done accumulating data that it then connected to an access point from which it can reach the Internet and Particle cloud.
It sounds to me like you can just turn off WiFi on the Photon while you are collecting data, and then just turn it back on when you are ready to upload to the server. The will save you a lot of battery.
Thank is good if you have access to the LEDs on the shield, but if the device is enclosed in a larger enclosure it may not be viewable. What would be best is to have the battery gauge readable by the software so it can be displayed to the end user in any of several forms, including perhaps on an LCD display.
The data being collected by the Photon is coming from a mobile access point/server which the Photon is connected to via WiFi. So it must operate WiFi during both the collection phase as well as the upload phase when it connects to a different access point to send its data to the cloud. So we donât have the option of turning off the WiFi to save energy during this application.