I am using dragino’s lora bee with an Atmega1284 IC at 3.3V.
I have just realized that the chronic restarts of the Atmega that I was experiencing were just happening during Lora module’s transmit mode. It seems neither the USB port of my computer nor the LiPO battery I use instead of the USB, cannot just supply the current fast enough to the Lora module during transmit. The microcontroller is not doing any other work during this except for holding up a pull-up pin, and turning a mosfet switch on. I am using a Lmic library for Lora
Can this diagnosis be correct?
It seems that your MCU BOD is hit and restarts the processor.
You can try
- mount a big capacitor (buffer)
- disable BOD
- lower Tx power
as we don’t know what LIPO you have connected this remark is not relevant
I have tried 0.1 uF ceramic capacitors together with a bunch of 4.7 uF, 100 uF, 300 uF capacitors, in vain.
I haven’t yet tried disabling BOD however.
obvious question… how much current does your setup use in sleep, Rx an Tx (and at what Tx setting)
how much of a voltage drop do you experience
* maybe any sensors connected to ?
Never had that problem before, and I often use LoRa devices on 17dBm @ 3.3V.
The default BOD voltage is 2.7V which is a bit high, I would reset it to 1.8v.
However, something is dodgy, I would be looking at the supply rails on a scope.
I’m sure you have a 3.3V regulator somewhere. What is the part number and the voltage input?
1 Like
I don’t sleep the transceiver, (I shut it up directly), and I don’t have RX, I have only TX (highest spread factor). Unfortunately I don’t have the devices to measure currents or voltages exactly, I just read instantaneous values on the meter like 0.2 volts drop, and 150 mA during transmission.
I am using 1.8 for BOD, and I have two setups, one on a breadboard, the other on a veroboard, and I am experiencing the same problem.
I have tried with two versions : one with a FTDI programmer directly from the computer’s USB, unfortunately I don’t know the regulator on the FTDI.
The second was with a LIFEPO4 battery directly, without any regulator. (It supposedly supplies more or less stable current at 3.2 Volts.)
ok start looking like a quiz 
I would take it apart now and test that dragino board seperately (with another 328p based arduino)
That is what I am going to do, thanks!
Usually FTDI cable are able to churn out only 50mA from the internal regulator built into the chip. The LiFePO4 should work theoretically. Unless you post more details about your setup like wiring, boards, etc. I don’t think we would be able to help.
I think you’re right! That makes alI the FTDI experiments meaningless.
I am now going to repeat the experiments with the LifePO4, and send photos of the setup.
I repeated the tests (with the lifepo4), and got the same results (restart problem), until I figured out removing the battery low voltage protection circuit which I had applied with two mosfets. (as shown here)
The problem seems with this circuit which is realized by one NDP6020P and one IRLZ34.
Maybe the P mosfet cannot open the circuit completely, I don’t know, but it is the only P channel mosfet I could find in this voltage range.
I also tried TP4056 with battery protection. This is normally a charger, I used only the battery protection circuit. Same result unfortunately.
So at this point it seems I am stuck with having to use a LiFe battery with no protection.
so it seems that your dragino board + code is working (with a normal power supply)
So when the MOSFET is supposed to be on, what was the voltage measured across it ?
Vgs you mean? Measured just now, 3V.
Yes, exactly, it seems there is no problem with those.
No , drain to source.
When the MOSFET is on, drain to source ought to be low resistance and hence the voltage across it ought to be very low.
Interestingly, 0 Volts.
I also wanted to see how much current this MOSFET would conduct, so I connected a resistor, and got 185 mA (with a 10 Ohm resistor.) Doing that, the voltage dropped considerably (as I could see on the LED connected to the main rail of the breadboard), but the system DID NOT RESTART.