The P channel MOSFET solution would look like in this image:
For details of how to connect the MOSFET itself, I can attach another diagram/schematic.
I hope this helps.
WiFi LoRa 32 V3: Send sensor data via LoRa, then go back to deep sleep
1 Like
Thank you! Yes, Iād appreciate it a lot if you could attach a diagram for the MOSFET itself.
The schematic could look like this:
Since the AO3401 is tiny, you need to solder it to a PCB of some kind. A perfboard would be enough. Or you could create a custom PCB. The connections on the board would then look like this:
Here again with pads with labels:
J1 (GPIO) would be connected to an ESP32 GPIO pin, J2 (In) to the positive 3.7 V from the Sunny Buddy, J3 (Out) would be the output you could connect to the voltage regulator or boost converter. This output pin is switched on when you set the GPIO pin you connect to J1 to LOW.
Another version of the PCB shows the connections to the MOSFET and the resistors more clearly, the components themself are not shown in this version:
1 Like
Thank you so much, I will ask tomorrow at work if we have any MOSFET or controller like this.
You would do yourself & the university a favour to limit the amount of ātestingā aka bludgeoning the heck out of the free community TTN servers you are doing - if the TTI Boyz see a spike in the server loads, they usually just reach for the off switch. So reading about the FUP would be a very good idea plus looking at the duty cycle limitations before the federal authorities turn up with their radio tracker to find out whoās breaching EU transmission regulations!
So if it cycles more than a couple of times on startup, perhaps just turn it off and make adjustments. Leaving it running isnāt a good thing and it wonāt fix itself.
Iām not sure where the idea about having to send more often than not came up, devices can be configured to not send for months and months, indeed some are buried in fault zones and only send when exposed to the light - good for monitoring massive land slip. Whereas sending too often ā¦
In the meanwhile the MOSFET switching the VReg diagram looks good - there may be easier to obtain parts in the EU than the one suggested which is a good buy on AliExpress but they come on the slow boat from China. I use the BSS84.
You may also be confusing your colleagues with this - assuming mass = minus, then the Heltec board isnāt either - it can produce a + signal or a Gnd signal on its digital IO. If you connect a N channel MOSFET it is turned on when it is a + signal and if you connect a P channel it is turned on when it is - aka minus which is actually ground aka 0v.
Hello Nick,
itās testing, without the quotation marks. One of your prior recommendations was
In addition, I did not ābludgeon the heck out of the free community TTN serversā; the re-join issues occurred sometimes, and sometimes not, so I had to wait and see what happens ā I canāt fix what I canāt see. I would appreciate it if you didnāt accuse me of willfully trying to break the FUP.
Some project partners would like for the node to sense and transmit data every hour, at lowest sending data once per day or twice per week ā which is what weāll be working on with another research group. However, right now, I canāt go too high with the duty cycles, simply because I canāt wait days just to figure out if something I did (hardware or software related) is working or not. Now that the part of seeing whether data is sensed and sent correctly is done, I can go with longer DutyCycles as e.g. the changes when employing the MOSFET or the regulator that Steven recommended apply to power consumption and only truly show their effect when running for long times at long intervals.
I totally agree that other suitable P-channel MOSFETs are available. The advantage of a modern one like the AO3401A is the low R_DS(on) and the low V_GS(th) while allowing for I_D = -4 A in SOT-23. It is in stock, for example, at Reichelt in Germany. No slow boat needed.
If you prefer a more traditional āwesternā manufacturer, I would propose something like the Infineon IRLML5203 if you want to switch high-ish loads with a high-side switch.
But you are, not in a malicious way, but you left it running for over 20 minutes - a normal device joins and stays joined, sometimes for years, not once every minute, thatās double the FUP downlinks in one go. A couple of join loops is more than sufficient to show that there is something wrong and to turn it off.
The 60000 was related to brief periods of testing of uplinks - not joins which require an uplink, processing & a downlink.
What Iām trying to draw to your attention that you highlighted this issue 11d ago in post #26 and is still continuing and that it runs the risk of causing you complications. As such you need to find another mode of testing (outlined below) because itās not good for the free community servers that are being slowly restricted due to FUP issues or the radio spectrum which comes with legal obligations with your local judiciary.
The wording may be unfortunate, but the content was aiming to save you from unintended consequences.
There are more efficient ways to test:
There is no need to run the radio to test your external power switch - you can do it with a very simple sketch that just pauses, turns on the power and prints to the serial log - if it loops, you know there is still more to fix.
There is no need to run the radio to test your sensors. Or your payload construction. Or low power mode. Or pretty much anything. You can use the serial debug to show what is happening.
Once sensors, power control, sleep etc are working, they can be bought together for final testing with a push to send so you can trigger an uplink, examine the results, make adjustments and repeat. Or without a push button, just one send in the setup function and nothing in the main loop.
Once your device behaves normally, then you can set it to a reasonably short uplink period - 11 bytes at SF7 would be uplinks a minimum of 177.7 seconds apart - this would be appropriate for an overnight bench test to make sure itās all stable.
1 Like
Old habits and we still have a few thousand to use up on legacy boards!
Production manager says that TME carry AO3401A as well, some of the Far East parts, once theyāve been out in the wild for a while and are fully understood are pretty handy but then someone puts them on a board and makes them look bad - like the TP4056 charger boards with the borked implementation of the DW01A protection.
Amazon can sell me ā10 Pcs AO3401A 100pcs SMD P-Channel 30V 4A (Ta) 1.4W (Ta) mosfet transistor SOT-23 AO3401ā for Ā£12.68 which looks like a fair price - just not sure if I get 10, 100 or 1,000!
Well, actually, I just suggested this easy circuit for beginners, since it will work good enough in practice. But keep in mind that the 3.7 V rail is sometimes 4.2 V when the battery is full.
- At 4.2 V, I am slightly misusing the clamping diodes in the ESP32 GPIO ports. The current is limited by the relatively high value resistors, though.
- Switching the whole contraption off is best done by setting the GPIO pins to HiZ, since setting it to a 3.3 V level would result in a V_GS of -0.9 V, which is dangerously close to where the MOSFET would start conducting. The peril of those modern MOSFETsā¦ Also, there would be a small current flow through R2 when the GPIO is set to HIGH. Even in HiZ, these pesky little clamping diodes will need to conduct a little bit of current.
- So, if you want even lower standby power in practice, perhaps increase R2 to even higher values. Or do it right and use a better circuit, e.g., by simply using an additional N-channel MOSFET to pull the gate of the P-channel to GND.
1 Like
Did some tests today. With the MOSFET, it has not worked yet. When I tell the GPIO 37 (ADC Control) to go HIGH just after waking up, then print data to the serial monitor, and then tell GPIO 37 to go back to sleep shortly before the deep sleep function, the voltage somehow always reminds at 3.3V instead of ever going to 0V.
Then I tried the VEXT pin again. Looks almost good. I have a sleep time of 60s, and during that time the sensors are nicely turned off (works for both USB and battery power). Most of the values, with the exception of TDS and turbidity look correct as well. My issues right now are (1) TDS and turbidity values being measured wrong, and (2) the serial monitor telling me that the wake up was not caused by the time. Please see the attached images for a better understanding of what I mean.
Please find the code Iām using here:
Do you have an idea what could be causing this behavior?
Thank you already in advance for your replies and help.
EDIT: I measured how much voltage the TDS and turbidity sensors get when powered on. The turbidity sensor gets like 1.4V while the TDS sensor gets 0V ā both should get 5V.
@jsteiwer I cannot really help here, because I do not understand what you are doing. Are all power supply pins of all sensors connected in parallel? Do you want every sensor supply to get the same supply voltage? If so, should it be 5 V or 3.3 V? When all sensor supplies are connected in parallel, all should get the same supply voltage. I see no possible secenario where one sensor would get 0 V, while the other one gets 1.4 V. Even when looking at the diagrams you drew, I do not get any idea about the setup. What is going on on the breadboard? What is the expected supply voltage for each of the sensors?
I suggest to do the following experiments, once you know which voltage is needed for which sensor and how to properly connect them:
- Create a new sketch for the ESP32 that does nothing but reading the sensor values in regular intervals (using
delay()in the main loop) and printing the values to the serial port. No LoRaWAN communication in this sketch. - Modilfy the sketch to switch the external supply off, wait a few seconds, switch the external supply on again and read the sensor values in the loop. Do NOT send the ESP32 into deep sleep in this sketch. Still no LoRaWAN communication in this sktech.
Let us know what happens in these experiments.
I read on your github page that you are working towards your PhD. The advantage of working in such a position at a university is that you do not need to do everything on your own. Some tasks could be done in studentsā theses/projects. Perhaps you can find some students who are into Electrical Engineering and/or Computer Science, either as a hobby or as a minor field of study (I know nothing about the structure of your study program, not sure if a āNebenfachā exists there).
Another thing: If you want to include the current setup as one part in your PhD thesis, you need to document the setup in more detail anyway. For example, I would expect that you need to explain the power saving mechanism and the power supply of the sensors. So why not do it now, in a systematic way? Once you have written down what the requirements are, it would be much easier for us to help you implementing the solutions you came up with.
Agree with @ksjh as anything academic / not just a hobby does need proper documentation and explanation.
But it also feels like weāre repeating earlier tries by rebuilding from the ground up. I still think that a voltage converter like the one I linked earlier is a simple and clean solution. Iāve been on the same path as you powering a GPS and a GNSS module on 5V from a 3V3 bus which was (and still is at times) causing a lot of trouble when using all sorts MOSFETs and transistors.
Hello @ksjh,
all my sensors need a DC voltage supply of 5V; right now, they are all in parallel and receive 5V each. It appears that when I was measuring the voltage, I was in contact with not only the metal but also some plastic, which caused false measurements. I have also managed to fix the readings for TDS and turbidity.
Right now, I am using a code that just prints out the values and then goes back to deep sleep powering off the sensors, that works quite well, the calculations for the TDS and turbidity just had to be matched better to the data Iām getting from the sensors (e.g. the manufacturerās code assumed 0-1023 analog output for 0-5V, but for me at 3.7V I got an analog output of 4095, so I had to fix that).
The current setup is for experimental purposes; our work group designed a new PCB (with LoRa, mosfets, voltage controllers, etc.) which should arrive in one or two weeks, which will be the backbone of my setup.
@bns the converter you had recommended arrived today; I will try that one next.
Yes, @bns, you are right. I also fear we are going in circles.
But the goal of the experiments would be to explore how to switch the external power on and off and avoid the deep sleep and LoRaWAN.
And: Please, please, please to not power your boost converter from the 3.3 V rail. The 3.3 V LDO is tiny. Always use a connection to the Li-Ion cell (or Sunny Buddy) as an input to your boost converter, no matter if you use the MOSFET or the enable pin.
Another tip: There are numerous different cheap buck-boost converters with an ENABLE pin specifically designed to be used with one single Li-Ion cell on AliExpress, e.g., https://www.aliexpress.com/item/1005004622491894.html
One word of caution before ordering a random converter with enable pin: make very very sure that theyāre off-by-default. Iāve spent hours and hours and tears trying to get a converter from Polulu (renowned!) to work with deepsleep code but that was hell as it is enabled by default causing all sorts of troubles. Holding pins during deepsleep should be avoided at all costs if thereās hardware available that does the job. The Tindie one (curious for your results!) is one of the good ones.
Well, the one I linked is not, it is enabled by default. You would need a resistor to pull the ENABLE pin to GND.
I remember a post here saying I should try again from the ground up because the one code deep sleep code I was using was not working right, so I wanted to try again step-by-step to not make the same mistakes again. My apologies if it seems like Iām just dumbly repeating things and going in circles. I do not wish to waste your time.
With the controller you recommended, I will try to replicate this solution that @ksjh had recommended:
I would connect the load+ from the Sunny Buddy to the Vin pin, connect the load- from the Sunny Buddy to GND, connect the 5V pin on the controller directly to the breadboard, and connect the En pin to a GPIO on the main board.
Recently, I had tried using GPIO37, which has ADC_Ctrl and Pull Up, for enabling the MOSFET, but it did not work. In the code, I set that pin to OUTPUT, then defined it as HIGH with digitalWrite, then printed data to the Serial Monitor, and put the pin back to LOW after printing. It was supposed to stay low for 60sec, however, the pin continuously remained at high, giving 3.3V. I used the deep sleep code (sleepTest_.ino), added the command to set the pin to HIGH before printing the wakeup reason, and then the command to set it back to LOW right after the line Serial.println("Going to sleep now"); ā however, as described, it remained HIGH. I didnāt check online yet if thereās a specific code for setting up the GPIO pins as enable pins, but I would look for that.
Again, sorry for wasting your time by trying some things again. That was not my intention.
But then likely pulled up by a resistor internally, then you pull it down hoping to get it below the cut-off voltage, then you hope that the drive on the pin is strong enough to enable it againā¦ and then without wasting too much energy through the resistors. Please, off-by-default 
No worries, I was saying it before you restart with the recommendations from ksjh - while a valid technique, youāve done it before and at some point you might give up before getting there!