Reboot after switching on Sim800l via mosfet on custom pcb with atmega328p

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

 

I am a little bit lost and was hoping somebody could help me figuring out what is going on.

My issue is that I use a sim800l module and when I switch it on via a mosfet, my code reboots. I don't really know why and more importantly I don't know how to fix it.

 

In the attachments I have the pcb layout and a screenshot of the sim800l module I use.

 

Here is the code that I am running (stripped everything so to just get the bug isolated)

 

Code:

#include <avr/io.h>
#include <util/delay.h>
#include <stdio.h>
#include "../../library/uart/atmega328p.h"

int main() {
  uint8_t status = MCUSR;
  MCUSR = 0;

  if (status & WDRF) {
    uart_send("RESET: Watchdog\r\n");
  }
  if (status & BORF) {
    uart_send("RESET: Brownout\r\n");
  }
  if (status & EXTRF) {
    uart_send("RESET: External\r\n");
  }
  if (status & PORF) {
    uart_send("RESET: Power on\r\n");
  }

  uart_send("Init\r\n");
  DDRC |= (1 << PC0);
  PORTC |= (1 << PC5) | (1 << PC4); // Set to pull up i2c

  while(1) {
    uart_send("On\r\n");
    PORTC |= (1 << PC0); // Switch on mosfet
    _delay_ms(8000);

    uart_send("Off\r\n");
    PORTC &= ~(1 << PC0); // Switch off mosfet
    _delay_ms(8000);
  }
  return 0;
}

 

So when I run this code what I will see is that the "Init" statement gets debugged every time it switches on the mosfet. Obviously I want the "Init" only once and subsequently a alternation of "on" and "off". After the reboot the Sim800l starts to work as it supposes to work, I can send data back to the cloud/internet, it just always comes with an additional reboot. I suspected that it is a voltage drop that caused the reset, but I don't understand why that wouldn't show up in the MCUSR register. The register only shows the reset on powering on the device and afterwards it is completely silent. Is this code correct to look at the MCUSR status?

 

Ouput debug:

RESET: Watchdog
RESET: Brownout
RESET: External
Init
On
Init
On
Off
On
Init
On
Off
On
Init
On
Off

 

What I have done so far and didn't work:

- Tried all the fuse settings for the brown out detection 0xFF, 0xFE, 0xFC and 0xF8, doesn't make a difference.

- Added a catch all interrupt vector to see if I got some unhandled interrupt by adding ISR(BADISR_vect), but this doesn't get triggered.

- Soldered a cap over the VCC and GND pin of the Sim800l module, didn't work (10uF and 220uF, didn't have anything else laying around) 

- Moved the Sim800l to another output on the pcb, P3 (which also uses a mosfet to switch it on), still reboots.

 

What I have done so far and did work:

- Put the Sim800l on a breadboard, added wiring and the same caps. Each of the caps, 10uF and 220uF work and it shows "Init" only once. 

 

My thoughts:

 

- It is not a capacitor or voltage drop issue, otherwise I would have seen a brown out in the MCUSR. I also think that there is already a cap on the Sim800l module (can someone please confirm this)

- Not a code related issue, when I remove the SIm800l and let the code run it works as expected.

- I suspect some issues with the traces on the board that are for P2. But they are almost identical to the ones for P3, only thing I can think of is that VCC for P2 goes under the mosfet body of Q3, which could cause some issues. Mind you Q3 isn't used for the switching process at all, it is a mosfet to switch on my ADC.

 

Any help in solving this issue would be greatly appreciated.

 

Regards,

 

Roy

 

Update:

 

- Turns out that the Sim800l has the same issues when moved between P2 and P3, in contrast to what I earlier stated.

- Adding a 220uf Cap to P1 accross VCC and GND doesn't make a difference

- Setting the TWI/I2C inputs to pull ups doesn't change anything

Attachment(s): 

Last Edited: Wed. Oct 4, 2017 - 04:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Roy,  Welcome to the Forum.

 

Nice write up.

 

Can you add a schematic for your project?

 

You can insert photos into the post by using the "mountain range" icon, two to the left of the smilie face icon.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey JC,

 

Thanks for the quick response, added the schematics to the post, will move the pictures when I make a new post, leaving it for now.

 

Cheers,

 

Roy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is a bad idea to switch the 0V. When the mosfet is turned off, you get sneak circuits via the protection diodes inherent in most cmos devices. Always switch the supply.
The mosfet is probably not suitable for switching the umts module - it will probably get too hot when transmitting.
The cause of your problem is most likely having to charge the input capacitor on the sim800 module and the regulator gets overloaded.

Last Edited: Wed. Oct 4, 2017 - 03:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman,

 

thanks you for your reply, these are the mosfets I use on my PCB, all are the same

 

https://datasheet.lcsc.com/szlcsc/CJ2310_C75882.pdf

 

So you are saying that it would be better to use P-Channel mosfet so instead of switching GND I should switch VCC? Do I understand correctly?

What I don't get though is that when I attach the sim module to P3 instead of P2, which uses the same mosfet, everything seems to work a-ok. Which lets me believe that the mosfet in this situation is not really the issue.

Secondly after the reset has been taken place, the code executes as expected and I can use the sim module to send data to the internet, easily keeping it up for a complete minute. It just has an initial reboot that is the problem.

 

PS. I tried multiple PCBs, they all have the same issue, so it is not a broken component on a specific PCB

 

Cheers,

 

Roy

Last Edited: Wed. Oct 4, 2017 - 03:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not enough bypass capacitors for my liking. My rule is for at least one 0.1ufd near every major power-supply-pin, per chip and some bulk capacitance at the main-supply input.
I would also add a few nfd on the RESET line.


Since it works when you put the Sim800l on an external board I think that the extra inductance in the wires is reducing the dI/dt spike in the VCC trace.
I'd move the 220ufd to be across VCC & GND at P1.

Last Edited: Wed. Oct 4, 2017 - 03:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As i said, the root problem is most likely the initial charge current. Your ground path on your pcb is rather torturous and somewhat different depending on what connector you use. You don’t want ground currents flowing across your AVR.

Yes, use p channel fets. Switching the ground is causing a problem you haven’t identified yet. No pullups on the i2c bus?

For more evidence, have your code read the reset cause and output it. If it is the BOD causing it, then this suggests a pcb and/or power supply issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update:

 

- Turns out that the Sim800l has the same issues when moved between P2 and P3, in contrast to what I earlier stated.

- Adding a 220uf Cap to P1 accross VCC and GND doesn't make a difference, same issue.

- Setting the TWI/I2C inputs to pull ups doesn't change anything (Added that to the code)

 

For obvious reasons I can't test the p-channel mosfets to see if that fixes the problem, the board is the way it is now. But are there way to test my ground plane issues, measuring with the multimeter for example? How would I go about to do that @Kartman.

 

@Kartman: I don't get any messages in the MCUSR register concerning the BOD, actually I don't get any messages from the MCUSR on the reset, only at boot. Please see my code if this is the correct way to check the register.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please see my code if this is the correct way to check the register.

It is not.  WDRF, BORF, EXTRF, and PORT are bit numbers, not bit masks, so you need to handle them the same way you would PC0, PC5, etc. i.e. turn them into masks with  1<< :

  if (status & (1 << WDRF)) {
    uart_send("RESET: Watchdog\r\n");
  }
  if (status & (1 << BORF)) {
    uart_send("RESET: Brownout\r\n");
  }
  if (status & (1 << EXTRF)) {
    uart_send("RESET: External\r\n");
  }
  if (status & (1 << PORF)) {
    uart_send("RESET: Power on\r\n");
  }

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as I can interpret it looks like your supply is not stable enough hence the moment you turn on the SIm800 module the Mega supply voltage drops to below the reset threshold and resets the processor.

 

If you want to be sure, it is time to get the old trusted scope and see what happens to the supplies the moment you turn on the SIm800 module.

 

Then again if your processor would really re-start you would see the reset reasons (brown out/externall....) every time the init comes by.

wonder what messages you get when you corrected your code as per Joey's remarks. that should make a lot of things clear.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jeezz, what a nooby mistake about the bit numbers... Updated the code to what joey mentioned. Here are the results I have found with various fuse settings for the Brownout detection:

 

// Fuse setting: 0xFC (Brown out 4.3V)

RESET: Brownout
RESET: External
RESET: Power on
Init
OnRESET: Brownout
Init
OnRESET: Brownout
Init
OnRESET: Brownout
Init
OnRESET: Brownout
Init
OnRESET: Brownout
// ... Keeps going like this

// Fuse setting: 0xFD (Brown out 2.7V)

RESET: Brownout
RESET: External
RESET: Power on
Init
On
// Stops here and never reaches off, sim stays on

// Fuse setting: 0xFE (Brown out 1.8V)

RESET: Brownout
RESET: External
RESET: Power on
Init
On
// Stops here and never reaches off, sim stays on

// Fuse setting: 0xFF (No brownout detection)

RESET: External
RESET: Power on
Init
On
Init
On
Off
On
Init
On
// This was the original reset in my first post

Unfortunately I don't have a scope here, which is kind of a pity, need to put that on my shopping list (Any recommendations?).

So from this I gather it drops below 4.3V but stays above 2.7V, otherwise I would have seen brownout detection there as well. Why would the fuse settings for 0xFD and 0xFE stop code execution all together? I guess it still has to do with the brown out because otherwise I would have the same freezing when I turn off the brownout all together (0xFF).

 

What I haven't mentioned yet my input power is either the usb input from my programmer (isp cable) or two Lifepo4 batteries in series with a buck converter to 5V. Whichever power source I use, the results remain the same.

 

Last Edited: Wed. Oct 4, 2017 - 06:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Power sagging causing a BOD reset isn't the only problem.  Rapid changes to VCC, high frequency noise (on VCC and elsewhere), and the ground currents already mentioned can wreak havoc and cause an mcu to malfunction at the hardware level, including (but not limited to) SRAM and register corruption, incorrect instruction decoding and execution, etc.

 

Have you added bypass caps as recommended in #6?

 

You say it 'reboots', but is that accurate?  Seems like that only happens with BOD at 4.3V, and that it just wedges for other BOD.   Curiously, with no BOD, it looks like it is making it through sometimes, but most of the time is exhibits a software reset.  My guess is that this is the manifestation of register or SRAM corruption.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Current flows in a loop. Seek to minimise the loop, especially when high currents are involved. The placement of capacitors are critical.
Just for giggles, pulse the power to the sim800 - using a pwm channel would be better and gently power up the sim800.

Internal pullups aren’t to i2c spec. Use real resistors of around 2k2.

A multimeter is no good for measuring low Ohms. You’d be better off redesigning the pcb.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks everybody for the great help so far, learning a lot.

 

Before I go and redesign the board and add extra caps, resistors for I2C and switch my current n-mosfets with p-mosfets I would like to make sure I have tested everything else.

 

Whenever I turn off the brownout 0xFF. It always goes through. I don't have any erratic behavior in the program at all. It is just this initial reset (software I presume, since I don't see any reset status coming out of the MCUSR). 

Any code that runs on this module works without any quirks, I have ran different things and tested all the elements on my board, it is just the SIM800L that gives me headaches.

TWI works, UART works, ADS1115 works, DS3231 works, external sensors work, all the mosfet switches work. SIM800L works after it has rebooted.

 

- So if my SRAM or register gets corrupted, how does one check this. Are there ways to do this?

- I still don't understand why it completely freezes with the brown out fuses set to 2.7V and 1.8V. I either would have expected the same behavior as no brown out, or a reset if it dropped below...

- I have added a cap to the main power supply which was 220uF. This didn't change anything. Might it by the capacity of the cap that is not high enough?

 

Are there any other things that I can/should check before redesigning a new pcb to make sure I eliminate all other possible causes?

 

Cheers,

 

Roy

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So you turn off the brownout and the system ‘works’. Turn it on and it reboots when you power the sim800. Consider the problem when you turn on the mosfet for the sim800 - its input capacitor will appear as a dead short circuit until it charges up. How long will this take? Depends of your psu impedance, the on resistance of the mosfet, assorted other impedances like your pcb and the capacitor itself. During this time your AVR maybe running out of spec.

Have you scoped the i2c bus when you have one or more devices turned off? I think you’ll find the bus powers them. This may/may not be an issue - it depends on what you expect. We’ve had at least three people in the last week reporting weirdness that can be caused by the cmos protection diodes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whenever I turn off the brownout 0xFF. It always goes through

Really?:

// Fuse setting: 0xFF (No brownout detection)

RESET: External
RESET: Power on
Init
On
Init
On
Off
On
Init
On

Looks to me like it made it through only once, and the other two times it mysteriously restarted with out a reset source in MCUSR.

 

It is just this initial reset (software I presume,

Unless there is a flaw in your code, then this points to a malfunctioning mcu due to serious power/layout problems.  Were it a software issue, I'd expect it to 'reset' in a loop forever, not just once after power-up.

 

 

- I have added a cap to the main power supply which was 220uF. This didn't change anything. Might it by the capacity of the cap that is not high enough?

You've missed the advice to add small (100 nF, ceramic) bypass caps right next to the mcu, as close as possible to the pins, between VCC and GND, and AVCC and GND.  The larger caps are for the rail, not the mcu.

 

- I still don't understand why it completely freezes with the brown out fuses set to 2.7V and 1.8V. I either would have expected the same behavior as no brown out, or a reset if it dropped below...

And you likely won't until you put a scope on your board.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you guys, I think it is pretty inevitable to start redesigning and add some capacitors where needed. Unless I do that I don't think I will get any further.

Pardon my ignorance to these things that might be very obvious to most, I started out with electronics 4 months ago...

Here is what I am planning to do after what you guys advised:

 

- Add 100nF bypass caps close to MCU (U1). VCC-GND and AVVC-GND.

- Add 100nF bypass caps close to MCU (U1). RESET-GND

- Add 100nF bypass cap close to RTC (U2) VCC-GND

- Add 100nF bypass cap close to ADC (U3) VCC-GND

- Add 220uF bypass cap close to P1 VCC-GND (Main power supply, would this be a correct value?)

- Add 100nF bypass cap close to P2 VCC-GND

- Add 100nF bypass cap close to P3 VCC-GND

- Change all my current n-channel fets with p-channel fets to change VCC instead of GND

- Add 2K2 pull-up resistors for the I2C instead of using the internal MCU ones

 

Is there anything else that might by good advice to create a more stable pcb circuit?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One more potential "gotcha", some PFets switch well at logic levels, some don't.

 

I hate P-channel calculations, my brain doesn't work with backwards, upside down voltage levels very well.

 

Anyway, you probably want to breadboard and test your high side power switch circuitry.

 

I used a DMC2038LVT recently, (NFet and PFet within one package), as a high side switch, but the circuit was running on 3V, (Xmega), so you might get away with just the PFet, instead of using the NFet driving the PFet.

 

Others might have further suggestions in this regard.

 

JC

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The sim800 wants over 3.4V to operate. So you need a separate supply for it and something more like 4V. It needs to supply over 2A of current. Your mosfet needs to be able to switch that current. Mosfet specs can be deceptive if you’re not familiar with them- eg the spec might say 3A, but the reality might be that it will melt down as you violate the thermal spec. You need to calculate the amount of energy lost as heat then translate that to temperature rise.

Why do you want to switch the power to the i2c devices? That is going to cause problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Kartman, thanks for your input, again.

 

Let me just clarify some things for you guys. I have this in my head which makes it trivial for me to talk about, but obviously you hear about it for the first time, so some proper explanation is in place. Come to think of it I should have done this in my first post.

 

I might come accross as a stubborn **** but it is just because I want to fully understand why it is failing and have answered all the questions I have got so far before I go and spent costly time and money on the remake of a PCB and then finding out I haven't solved the actual issue. Which needles to say would be a real shame.

 

So let me give you an overview of what I am trying to achieve and what I have on my pcb:

 

Power Suppy

 

- Power supply is 5.1V, either my ISP programmer (USB via laptop) or 2x LifePO4 3.2V (In series so ~6.4V) with a buck converter to ~5.1V

 

Components

 

P1 = Programmer (ISP) connector for loading software to MCU and powering the module 5V

P2 = Connector for the SIM800 module

P3 = Connector for any type of sensor, for now this is a time of flight sensor (VL53L0X) and eventually a PM2 particle sensor. I will change this connector to fit the needs of the actual sensor because it turns out it is easier and cleaner then some kind of general purpose connector. So currently it is a general purpose connector hence all the different connections (RX, TX, SCL, SDA, INT, SWI and VCC/GND). So this will be adjusted for the sensor that I will use.

 

U1 = Just a good ol' Atmega328P MCU

U2 = DS3231 RTC, this module uses its alarm to trigger an interrupt on U1 to let it do a periodical measurement. more about the software flow in a minute.

U3 = ADS1115 16-bit ADC converter, just because the 10 bit ADC on the MCU has a to low of a resolution for my taste.

 

I currently have 3 n-channel mosfets on the board that switch the following things

 

Q1 Switch off P2 (The sensor) if not in use

Q2 Switch off P3 (SIM800) if not in use

Q3 Switch off U3 (ADC) if not in use

 

Although the ADC, SIM800 and most sensors have sleep modes which let the run on very low currents, I preferred to completely switch them off with a mosfet to save even more.

 

Program flow (from power on)

 

INIT

- ...some general purpose init

- Switch off Q1, Q2, Q2

- Enable interrupt for U2

 

INTERRUPT - ALARM WENT OFF (whatever the interval rate, can be changed via the cloud)

- Switch off alarm 

- Switch on Q1, Q2

- Initialize the sensor via TWI/I2C (Some sensors need some init code to run before you can do a measurement)

- Get a measurement (Some need the ADC some don't whatever the sensor or protocol, TWI/I2C or UART, get a raw value)

- Get the battery level (Via TWI/I2C on the ADC, I have connected VCC to an input on U3)

- Switch off Q1, Q2

- Switch on Q3 (Here is where the reboot happens, or my weird behavior)

- Send the measurement to the cloud

- Switch off Q3

- Turn alarm back on again

- ... and repeat the whole interrupt cycle

 

Which brings me to Kartman's latest comment:

 

Kartman wrote:
The sim800 wants over 3.4V to operate. So you need a separate supply for it and something more like 4V. It needs to supply over 2A of current. Your mosfet needs to be able to switch that current. Mosfet specs can be deceptive if you’re not familiar with them- eg the spec might say 3A, but the reality might be that it will melt down as you violate the thermal spec. You need to calculate the amount of energy lost as heat then translate that to temperature rise. Why do you want to switch the power to the i2c devices? That is going to cause problems.

 

- Why would it be bad to turn off I2C devices?

- Why do I need a separate power supply I have something that can deliver 5V (This SIM800 module can handle that) and only needs a peak of 2A. My findings is that if you're close to a tower it actually doesn't need that much current. But that being said, yes I need a mosfet that should be able to handle a max current of 2A as peak current. This isn't continues! I have succesfully send messages with SIM800 in P2 via the mosfet to the cloud, non stop for over an hour. dropped only one because of a connection error no resets as long as I didn't switch off the mosfet and turn it on again after each send.

 

@DOCJS

 

Thanks, will have a look into that, but yes I am running 5V and need to switch 5V I need to check if I need a package like you have or being able just to use a simpler type of p-mosfet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why is it bad to switch off i2c devices? Just because you disconnect the power doesn’t mean they stop existing! There are intrinsic diodes that come into play.

If your sim800 board has a mic29302 regulator on it, then that chip has a shutdown pin- no mosfet needed.
That won’t solve your startup issue, but it might make things a bit easier.
Whilst things may have worked thus far, relying on factors you have no control over is rather risky. What works today, may not work tomorrow. I’ve got many stories to tell!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why is it bad to switch off i2c devices? Just because you disconnect the power doesn’t mean they stop existing! There are intrinsic diodes that come into play.

​Could you elaborate on this? I don't understand the intrinsic diodes part. You mean the module gets powered by the I2C bus or what?

 

Not sure about the regulator being on board on the SIM800 module. But you gave me a great insight for a temporary fix. Why not just use the sleep mode of the SIM800. It uses 1mA in sleep mode, which isn't that much, need to do some custom wiring but then at least I should be able to make my custom prototype board work. I switch the mosfet on at the beginning, it will reboot once, and then I just keep it on and use the sleep mode the save on power in between measurements.

 

Doesn't mean the other improvements don't need to be done, but it would be a shame if I have to wait weeks for a new version of the board, while I can macgyver something together now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

​Could you elaborate on this? I don't understand the intrinsic diodes part. You mean the module gets powered by the I2C bus or what?

Take the humble AVR, for instance:

 

 

Every pin has a pair of diodes.  One reverse biased between the pin and GND, the other reverse biased between the pin and VCC.  Their purpose is to protect against over- and under-voltages present on the pin, including (but not limited to) some measure of protection against ESD.

 

When the device is powered off i.e. VCC is disconnected, the tendency is for the pin to be dragged down to GND, or at least about one diode drop (0.7V) above ground.  If you do this to an I2C pin, it kills the bus.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

People getting trapped by these diodes is popular at the moment!

The sim800 module itself does not like 5V! You can buy it on a board with a regulator and level shifting that allows it to run with 5V supply and 5V comms.
[edit] seems you got the one without the regulator. This board uses a diode to drop 0.6V.

Last Edited: Thu. Oct 5, 2017 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have done some more research on my current prototype and it seems that I have some more issues. My interrupt for my alarm fires erratic, which I guess is also caused by noise on the line, since it is a PCINT it just needs a change to fire. Would an external pull-up or pull-down resistor fix issues? What would be better pull up or down, or doesn't really matter, another 2K2 would be ok? The actual interrupt trigger is a pulse so it is both up and down.

 

  // Disable interrupt
  PCMSK2 &= ~(1 << PCINT20); // Set right pin for interrupt
  PCICR  &= ~(1 << PCIE2);   // Write to interrupt reg
  cli();

  // Enable interrupt
  PORTD  |= (1 << PCINT20); // Enable pull up
  PCMSK2 |= (1 << PCINT20); // Set right pin for interrupt
  PCICR  |= (1 << PCIE2);   // Write to interrupt reg
  sei();

 

When it comes to the I2C, what would be a good approach if I want to turn of a component completely, add diodes (like you describe @joeymorin) close to each component that is connected via I2C? Just like it is happening in the AVR, so the bus stays alive for all the other connected components when I switch one off?

 

LONG STORY SHORT, I'VE GOT MORE READING TO DO, THANKS FOR ALL YOUR HELP GUYS, I NEED TO GET A BETTER UNDERSTANDING OF INTERFERENCE AND ELECTRONICS TO PROPERLY OPERATE MICRO-CONTROLLERS. THANK YOU ALL FOR YOUR HELP SO FAR IT HAS BEEN GREATLY APPRECIATED! IF ANYBODY IS WILLING TO HAVE A SKYPE CALL SO I COULD CLEAR UP SOME MORE STUFF, PLEASE LET ME KNOW!

 

THANKS A MILLION GUYS!

 

Cheers,

 

Roy

 

 

Last Edited: Thu. Oct 5, 2017 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The diodes joey showed in #23 exist both in the AVR and your i2c devices. They are 'intrinsic'. To turn an i2c device off completely, you need to isolate the bus. This simplest way would be to bit bash a i2c bus for each device. Thus you could power down a device completely and not bother the other devices.

Why do you have a rtc chip if you don't battery back it up? It would've been easier methinks to just use a timer in the AVR and use a crystal.
For the ds3231, the interrupt output is open drain - you can only use a pullup resistor on it. As for your 'noise', this might be easily generated by the phone module.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have sensors that need to measure maybe as little as once a month, but accurate, hence the external clock for accuracy. The reason that there is no external battery for it is because when I cannot send any data back I have no use for a running clock. So I just power it from the same power supply. I set the time initially from the cloud and maybe update it once in a while if it gets to much out of wack.

 

When you say bit bashing, you mean a separate line for each component that uses I2C instead of a bus and just do the timing and stuff myself for each module individually on a dedicated pin on the MCU?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AVR most likely would've been able to give adequate timing especially since you have the phone module. Also you need to be wary of where your ds3231 comes from - there are inferior clones from china.

Yes, bit bashing is using code to toggle port pins in the right sequence to perform i2c. Just like we did in the 1980's. Each device sits on it's own dedicated port pins. Thus can can power up/down the device without worrying about annoying the others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

braadworst wrote:

When it comes to the I2C, what would be a good approach if I want to turn of a component completely, add diodes (like you describe @joeymorin) close to each component that is connected via I2C? Just like it is happening in the AVR, so the bus stays alive for all the other connected components when I switch one off?

just to clarify, the diodes don't >>fix<< the problem.  They >>are<< the problem.

 

In truth, they are an important part of the solution to another problem (susceptibility to over/under-voltage and ESD). It's just that they create a problem in your case.  As Kartman says, they are in the chip, not external discrete components.  You cannot remove them.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys, have been doing some reading, simplifying and redesigning. I am currently creating my new PCB schematics. I was just wondering, would it be a good idea in lieu of what mikech said about caps to add a cap close to the SIM800 module. Seeing that on that breakout board are already some caps installed? Could it do any harm, by having to many caps?

 

Furthermore, if I run my pcb on a 5V battery pack that already has a voltage regulator and/or is using a buck converter do I need a bulk decoupling cap at the main power supply, how do I go about figuring out the value of the cap.

 

Any thoughts on pull up resistors foro uart? A good idea to reduce noise?

Last Edited: Fri. Oct 6, 2017 - 02:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are talking about the micro's USART, then the signal is driven high and low, and no pull-up resistors are required for those signals.

 

The data sheet for the regulator you are using likely has a comment or two about the output capacitor ( s ) for the regulator.

 

The output capacitors can be a rather critical component, then can impact the regulator's feedback loop and stability, hence the need to look closely for any specific requirements in that regard.

 

There is a wide range in reasonable values, for Cout, after taking the above comments into consideration.  Seeing a (new) full schematic would help.

 

You want enough capacitance to help the power hunger devices through brown-out periods.

You also don't want too much, if you keep switching the power to them off, as it is energy wasteful in a battery operated circuit to keep charging them up and then having them bleed off over time.

 

The RF module's data sheet might also have a recommendation for the cap at its input, look to see if one is there.

It might suggest 22 uf in parallel with 0.1 uF for example.

 

It is wise, if you are not building 1000's of PCBs, to put a decoupling cap, (0.1 uF), across each chip and device/module/RF mini-board, etc.

 

For the AVR remember that EACH Vcc/Ground pair of pins, and the AVcc/Ground pair of pins, NEEDS a 0.1 uF by-pass cap, mounted as close to the uC's pins as possible.

Also, one generally puts a 0.1 uF cap from ARef to ground.

 

If you are using the ADC within the micro, then instead of just the cap on ARef one might elect to use an LC filter feeding the pin. 

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah I figured a new schematic might be handy :-) I will finish that tomorrow and upload it after. Thanks already JC, great input. 

 

PS. I found that AVR doc "Hardware considerations" I think it is called, exactly like you say, a cap for each (A)Vcc lines.

 

Will get back to you tomorrow,

 

Cheers,

 

Roy

 

PS. for powersupply I just want to use of the shelve usb powerbanks. 5V 5000mAh-10500mAh, something along those lines. But I will do a bit more research about what caps would be good for that. Likely already has been a question by someone, somewhere...

Last Edited: Fri. Oct 6, 2017 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everybody,

 

I've created a new design for my module. I was planning to do a couple of minor changes but ended up by making a new board all together. Let me just summarize what I've done so far.

 

Put the SIM800L module on a separate power supply

As Kartman already mentioned, it would be better to supply heavy duty on a separate power supply. So I will do that with the sim module. This will limit the current draw on the main board, so preventing any drops. Furthermore do I want to incorporate LoRa in the near future for power consumption reasons so heaving a separate module seems like a good plan.

 

Removed all the mosfets from the board. 

There where two major reasons for doing this. As Kartman mentioned, turning off I2C devices isn't a good idea to start with. Further analysis also made me realize that all the devices that I was switching of actually heavy sleep modes or something along those lines. They often draw low in the microAmps or even less. So turning them off seems trivial. Also it saves on costs.

 

Removed the ADC

Don't really need 16bit adc converter for the module, the VL53L0X time of flight sensor doesn't need it, so only to measure the battery level seems overkill. I am actually planning to do the battery status in the cloud not based on the module but on calculations. So no more extra hardware or software for the battery status.

 

Changed the RTC module

Kartman also mentioned that the internal clock of the AVR would be a solution for periodically waking up the device. But I wanted a bit more accuracy then that. But for whoever is using a RTC. I came accross the PCF2129(A)T. Which is maybe not as accurate as the DS3231, but way cheaper.

 

Changing the planned 5V to ~3.0V

I am gonna run the module on 3.0V, because for starters not everything runs on 5V, which would mean extra circuitry. But by putting the SIM800L on its separate power supply I am able to run the board on 2 AA batteries without any dc-dc converter. Here are the parts that are on the board. Running without a converter should be fine right?

 

Running on 2x AA without DC-DC converter

 

PART Supply voltage Sleep current Active current
VL53L0X 2.6V - 3.5V 5uA 19 - 40mA
ATMEGA328P 1.8V - 5.5V 0.2uA - 0.6uA 3mA
PCF2129AT 1.8V - 4.2V 0.5uA - 0.8uA 17mA

 

 

 

 

 

My module we be in sleep mode for most of the time

 

Added decoupling caps according to the datasheets

As Mikech mentioned, not enough caps in my previous design. I've added those now. This was pretty straight forward. I just should have read the datasheet better before... Two questions I still have. 

 

- I am using a 10uF decoupling cap on the the power source, is that a correct value?

- Traces between the capacitor's ground and the MCU ground (or any other component that needs a decoupling cap) is now not a dedicated trace, it goes via the ground plane. Is this problematic? Should this be a dedicated trace? I haven't been able to do that in Upverter because each net automatically gets named ground which is connected to ground. As a result if you create a ground plane the dedicated trace get converted into the ground plane. 

 

Added proper pull up resistors to according to specs

Not much to add to this one

 

 

I hope somebody could answer some of my questions and have a look through the schematics/pcb layout if I have not made a grave mistake.

 

Thanks,

 

Roy  

 

Attachment Screenshot from 2017-10-09 15-36-56.png : PCB back

Attachment Screenshot from 2017-10-09 15-36-34.png : PCB front

Attachment Watertable-base-V11.png : Schematics

 

 

Attachment(s): 

Last Edited: Mon. Oct 9, 2017 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't suggest using the internal clock - my suggestion was to use the timer. With that, use an external crystal should provide similar accuracy to the RTC.  Good luck trying to estimate battery life - there's way too many variables and ones you can't control. The AVR has an ADC - use it to measure the battery.

There's no protection on your board. Is it expected to live on your desktop or be deployed into a somewhat more hostile environment? Lightning,ESD and EMI are common issues that arise.

With the pcb, don't do a ground fill on the top side - there's too many islands that aren't tied down, so they act as antennas. Better to concentrate on the bottom layer being the ground plane and having that unbroken as possible. The pcb is not just an interconnect - but a vital component of your circuit. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My bad Kartman, must have miss understood your comment about timers. Understood about the ground plane on the top. Although I don't really have any islands there right now. I am more concerned about this:

Traces between the capacitor's ground and the MCU ground (or any other component that needs a decoupling cap) is now not a dedicated trace, it goes via the ground plane. Is this problematic? Should this be a dedicated trace? I haven't been able to do that in Upverter because each net automatically gets named ground which is connected to ground. As a result if you create a ground plane the dedicated trace get converted into the ground plane. 

Could you tell me if that is an issue? Should the connection to an components VCC and GND and to the caps VCC and GND be a closed loop, or can you use the ground plane in there? and have only direct connections between VCC's.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've yet to get some experience with upverter. I signed up this week and am already frustrated with it. Seems Altium has got its hands on it. Doesn't bode well methinks - they can't even get their flagship product stable.

If the groundplane is on the bottom, does it stop you having a ground trace on top? How else do you tie pads to the bottom ground plane? I'd normally have a stub track on top then a via to the groundplane.

No islands? I spotted two on your board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes upverter == quite a bite of cursing, but beats easyeda. If you have linux and a hdpi screen your life isn't any easier with whatever standalone tool you download. But anyway, good eye about those two islands. Thought you wouldn't spot those :-) I've removed the top ground plane. What you are explaining wasn't my question. I was talking about the trace between a decoupling caps GND and the GND of a component, lets say the Atmega, can that be the ground plane or should that be a dedicated trace.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ground plane is on the bottom, so you need to use a via from the pin to plane and from bypass cap to plane and a short stub of track. It would seem unreasonable for the pcb software to not allow you to do this.