[TriEmbed] TriEmbed Digest, Vol 44, Issue 27

Jesse Griggs jesse.griggs at outlook.com
Tue Jan 24 09:13:16 CST 2017


Chip,

I guess I should have figured you were using a reflow oven - should have been obvious with the DFN/QFN package for the switcher.  You won’t need to change the reflow profile at all whether you use thermals or not because it’s not really changing the thermal properties of the board that much in respect to heating the whole board up in an oven.  My comment for using a higher-wattage iron only applies to hand soldering if you’re having trouble because of a lot of ground pours.

I never could understand why thermals default to on in Eagle.  I seriously hate them.  They’re ugly and they probably cause more issues then they solve, especially if you can just reflow the board and not worry about hand soldering.  I’m sure there are instances where thermals *should* be used but I avoid them.

Good luck!

Jesse Griggs
jesse.griggs at outlook.com<mailto:jesse.griggs at outlook.com>



On Jan 24, 2017, at 9:54 AM, Chip McClelland <chip at mcclellands.org<mailto:chip at mcclellands.org>> wrote:

Jesse,

Wow, had not thought about the thermals as they are default behavior in EAGLE.  I have been working with Pete to make these boards using a reflow oven.  Would eliminating the thermals cause us to have to chance the reflow profile at all (reflow equivalent of a higher-wattage iron)?

Thank you for the suggestion

Chip


On Jan 24, 2017, at 9:31 AM, Jesse Griggs <jesse.griggs at outlook.com<mailto:jesse.griggs at outlook.com>> wrote:

Chip,

I took a look at your post to the E2E community and saw your layout - good post by the way.  I’d strongly suggest you eliminate the “thermals” in your converter layout.  In switching regulators the the thin copper caused by the thermals defeats the purpose of copper pours to reduce parasitic resistance and inductance.  Your new layout looks much improved but I’d still eliminate the thermals.  I understand they can make soldering easier but I’m of that opinion that the better solution is to use a higher-wattage soldering iron instead of using thermals in your copper pours.

Jesse Griggs
jesse.griggs at outlook.com<mailto:jesse.griggs at outlook.com>



On Jan 24, 2017, at 9:10 AM, Chip McClelland via TriEmbed <triembed at triembed.org<mailto:triembed at triembed.org>> wrote:

All,

Thank you for the great suggestions.  Based on your responses, here is what I am thinking:

- Given the number of “events” and days over which the counter runs, the issue is likely hardware not software
- I checked the fuses on my Arduino and I do have brownout protection turned on.  I am running at 8MHz, 3.3V and brownout is set to 2.7V
- The ATMEGA 328p can run up to 10Mhz at 2.7V so should be good there
- I took two hours of measurements at 1/2 second intervals while the device was under test out of the 14400 test points - average 3.282V and lowest was 3.279
- I have taken a screen shot of the test here<https://dl.dropboxusercontent.com/u/21074878/Vcc%20Log%20over%20two%20hours.png> I think that this looks fairly clean but please let me know if you see anything that needs more exploration here.

I did find more noise and voltage sag under load in my Solar power converter than I expected.  I contacted TI support and they suggested I change my layout.  You can see the exchange and how I have improved the layout here<https://e2e.ti.com/support/power_management/non-isolated_dcdc/f/196/t/569106>.

I am now wondering if there is some dynamic between the Solar Panel board and the LDO converter on my trail counter.  I plan to start testing this once I figure out how to do so.  It may be there are some transients when the Solar Board changes to Solar charging, LiPo battery or Solar batter charged.

Again, thank you all for your suggestions, I will let you know what I figure out.  I am also going to respin the boards to improve the power supply layouts.

Chip




On Jan 23, 2017, at 1:00 PM, triembed-request at triembed.org<mailto:triembed-request at triembed.org> wrote:

Send TriEmbed mailing list submissions to
triembed at triembed.org<mailto:triembed at triembed.org>

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
or, via email, send a message with subject or body 'help' to
triembed-request at triembed.org<mailto:triembed-request at triembed.org>

You can reach the person managing the list at
triembed-owner at triembed.org<mailto:triembed-owner at triembed.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TriEmbed digest..."


Today's Topics:

  1. Re: Suggestions Needed to Improve Quality / Reliability
     (Pete Soper)
  2. Re: Suggestions Needed to Improve Quality / Reliability (Brian)
  3. Re: Suggestions Needed to Improve Quality / Reliability
     (Craig Cook)
  4. Arrow offering 12% discount for one week (Pete Soper)
  5. Re: Suggestions Needed to Improve Quality / Reliability
     (Pete Soper)


----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Jan 2017 10:03:05 -0500
From: Pete Soper <pete at soper.us>
To: triembed at triembed.org
Subject: Re: [TriEmbed] Suggestions Needed to Improve Quality /
Reliability
Message-ID: <9f4f1f8a-0130-38a3-e52a-dc2167afbb45 at soper.us>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 01/22/2017 03:37 PM, Chip McClelland via TriEmbed wrote:

- When I do get the system to lock up, his is what I see:
- The Arduino is the one that is locked up not the Simblee
- When the Arduino locks up, the Simblee is unable to take control of
the i2c bus
- The Arduino is in the ?sleep? state and will not wake up - with the
pin change interrupt set and _even if I manually bring the interrupt
pin low_
- The Arduino will not reset _even if I manually bring the reset pin
low_ - this is odd and what I have come to call the "fugue state".
- The Simblee will be visible on Bluetooth LE but will lock up when I
attempt to connect and it tries to read the i2c bus (I do not have a
timeout on taking the bus)
- The only way to recover is to power cycle the device

(Since your board is full custom and doesn't look like an Arduino, I'm
going to just refer to the IC.)

Well, the Atmega not doing the right thing in response to the reset pin
being pulled down seems like the smoking gun. This is of course
"impossible", so the question is how this could be happening. The only
two things I can think of are a too short reset sequence and an
intermittent power supply problem. Is the Simblee holding the reset line
low for at least 2.5 microseconds? The rest of this assumes "yes".

What's the clock speed of the Atmega? What's the Atmega's supply voltage
when it won't respond to reset? Will the Simblee run with a lower supply
voltage than the Atmega? I wonder if the fugue state is to do with the
onboard DC to DC converter vs the Atmega. If you could watch and record
the Atmega's VCC pin while trying to reset it out of the fugue state you
might see it sagging as the Atmega tries to start up: the Simblee is
able to keep running (or the sag might be causing the Simblee to stop
and restart. Can you detect that?). Is there any correlation with
temperature or battery state? Can the Atmega get it's work done at a
lower clock speed? Purely as an experiment you might lower the speed to
reduce its power requirement. If it rides through and "outlasts" all the
other units in the park, then it might suggest a power supply stability
issue. Systematically testing the power supply might be in order.

-Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20170123/f274ffc7/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 23 Jan 2017 10:06:12 -0500
From: Brian <triembed at undecidedgames.net>
To: triembed at triembed.org
Subject: Re: [TriEmbed] Suggestions Needed to Improve Quality /
Reliability
Message-ID: <58861BE4.8030708 at undecidedgames.net>
Content-Type: text/plain; charset=windows-1252; format=flowed

I was thinking a power issue might be the culprit as well.  Is there any
difference in power supply between your test fixture and the real world?
 Presumably batteries are involved in the real installation, and
batteries are not very clean power supplies; be sure you have plenty of
filtering capacitance at the input.  I'd recommend two or three decades
(10 uF, 1 uF, .1 uF e.g.) of capacitors in parallel on the supply; each
represents a low-impedance path for different bands of high-frequency
energy.

The mention of memory management is worth investigating, though if that
were the cause I'd expect there to be a stronger correlation to number
of events.  The Arduino software won't tell you if you're exceeding the
available RAM.  Stack overflows can easily sneak up and bite you.

Good luck!
-B



On 01/23/2017 09:41 AM, Shane Trent via TriEmbed wrote:
Chip,

Forgive me but I do not recall if you have the Brown-out detector
enabled on the Arduino. It is common to disable the brown-out detector
to save power but these are the kind of symptoms the brown-out detector
is designed to prevent. Odd lockup can frequently (but not always) come
from voltage excursions out of spec. Basically the brown-out detector
resets the microcontroller if the voltage drops below the brown-out
level. Worth testing it is not currently enabled. No pun intended.

Shane

On Mon, Jan 23, 2017 at 9:23 AM John Vaughters via TriEmbed
<triembed at triembed.org <mailto:triembed at triembed.org>> wrote:

   Chip,

   If the symptom is at regular intervals, whether they are regular
   events, or regular in time, I would consider a memory leak. I do not
   no have recommendations on how to check that, but I did a quick
   search and it appears there are some suggestions. I have never
   search for a memory leak in an Arduino before, but I am just
   throwing out an idea based on what appears to be regular intervals
   and a lock up condition.

   If you want to create a cheap reboot device, consider an ATTINY to
   wake up the device and look for a Digital IO to come on and off
   during a certain period of time, and if not cycle power. I know this
   just more power to Engineer which is a major negative for your
   product. Another option is a low cost, low power 555 timer set to
   trigger every so many hours or days, whatever you need. I am not
   sure which idea would give you the best power solution.

   Just throwing out ideas.

   Good Luck,

   John Vaughters






   On Sunday, January 22, 2017 3:37 PM, Chip McClelland via TriEmbed
   <triembed at triembed.org <mailto:triembed at triembed.org>> wrote:


   All,

   I have been installing trail counters at Umstead park for some
   time.  This has been an ideal situation as I often run or ride in
   the park and it allows me to keep an eye on things.  For some time
   now, I have been working to improve the reliability of my counters
   and I feel like I have hit a wall.  I am writing you all not in the
   hope that you can find the source of my issue but to offer
   suggestions on approaches I could use to better isolate what the
   root cause might be.

   Background and what I know thus far:
   - My sensor has two micro controllers (Arduino and Simblee) that
   share an i2c bus.  As they are both masters, I have a scheme to
   allow one or the other to take control.  I mention this because it
   may be the source of my issue.  More on how I architected this here
   <https://www.hackster.io/chipmc/arduino-i2c-multi-master-approach-why-and-how-93f638?ref=user&ref_id=6903&offset=0>

   - The Arduino manages the sensor and the Simblee manages
   communications using Bluetooth LE.
   - I have tested the software extensively and have a test rig that
   can test the full functionality of the system to randomly timed
   ?events?.  I can only occasionally get the error condition with this
   approach typically requiring over 100,000 ?events? before it
   happens.  Because of the timing in the system, this requires testing
   the systems continuously for days on end.  In the parks, the sensors
   typically run 25-30 days before they lock up during which time they
   will log around 30,000 ?events?.
   - When I do get the system to lock up, his is what I see:
   - The Arduino is the one that is locked up not the Simblee
   - When the Arduino locks up, the Simblee is unable to take control
   of the i2c bus
   - The Arduino is in the ?sleep? state and will not wake up - with
   the pin change interrupt set and _even if I manually bring the
   interrupt pin low_
   - The Arduino will not reset _even if I manually bring the reset pin
   low_ - this is odd and what I have come to call the "fugue state".
   - The Simblee will be visible on Bluetooth LE but will lock up when
   I attempt to connect and it tries to read the i2c bus (I do not have
   a timeout on taking the bus)
   - The only way to recover is to power cycle the device

   I am not sure how to best proceed.  I could spend more time / effort
   trying to figure out what the root cause is OR I could design an
   external watchdog that would simply recognize a lock up and reset
   the power.  In my application, the cost of a reset every 20-30 days
   is acceptable but, part of me says that is the easy way out.

   So, I am open to any suggestions you might have even if they are the
   ?have you checked to see if it is plugged in? variety.  If you want
   to see the code, it is in two parts: Arduino
   <https://github.com/chipmc/Connected-Logger-Arduino> and Simblee
   <https://github.com/chipmc/Trail-Counter-Simblee>   Any input is
   appreciated.

   Thanks,

   Chip

   _______________________________________________
   Triangle, NC Embedded Computing mailing list
   TriEmbed at triembed.org <mailto:TriEmbed at triembed.org>
   http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
   TriEmbed web site: http://TriEmbed.org <http://triembed.org/>


   _______________________________________________
   Triangle, NC Embedded Computing mailing list
   TriEmbed at triembed.org <mailto:TriEmbed at triembed.org>
   http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
   TriEmbed web site: http://TriEmbed.org



_______________________________________________
Triangle, NC Embedded Computing mailing list
TriEmbed at triembed.org
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org





------------------------------

Message: 3
Date: Mon, 23 Jan 2017 15:09:19 +0000 (UTC)
From: Craig Cook <cncook001 at yahoo.com>
To: "triembed at triembed.org" <triembed at triembed.org>
Subject: Re: [TriEmbed] Suggestions Needed to Improve Quality /
Reliability
Message-ID: <263538251.1930074.1485184159176 at mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

How many trail counters are in operation?


Do they all show the same lockup behavior?
The 30,000 number sounds suspicious.? Close to 32k.? Do you have some sort of integer or number issue going on?? i.e. you ran out of space to hold numbers?
Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20170123/2b5868c6/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 23 Jan 2017 11:45:28 -0500
From: Pete Soper <pete at soper.us>
To: Triangle Embedded Computing Discussion <TriEmbed at triembed.org>
Subject: [TriEmbed] Arrow offering 12% discount for one week
Message-ID: <d289e963-7940-ac9d-100d-53706652fafe at soper.us>
Content-Type: text/plain; charset=utf-8; format=flowed

Arrow kicks the stuffings out of other distributors for some components,
and a 12% discount can take the sting out of shipping costs. They just
announced this discount for one week with promo code "ROOSTER17". (I
only occasionally buy from them and there's nothing in this for me.)

-Pete





------------------------------

Message: 5
Date: Mon, 23 Jan 2017 12:07:56 -0500
From: Pete Soper <pete at soper.us>
To: triembed at triembed.org
Subject: Re: [TriEmbed] Suggestions Needed to Improve Quality /
Reliability
Message-ID: <0c7f5451-9bef-9fee-05dd-2756b7abb7e7 at soper.us>
Content-Type: text/plain; charset=windows-1252; format=flowed

Also, is it a sure thing that the Simblee is pulling the Atmega reset
line low enough? How much current is the Simblee having to sink to do
the reset? It might require cutting/repairing a trace, but if the
current necessary to reset the Atmega could be measured it might show
this is only working part of the time by serendipity because of a
problem with the board. We need to be careful to get any regular flux
off the boards and moisture might create a situation where the Simblee
hasn't got the grunt to reset the Atmega. If they don't already have
them your boards may need unique IDs (e.g. a few bytes of the 328's
EEPROM) to allow for tracking what's going on with them.

There seem to be one or two things that need their root causes found:
  1) Failure to reset ("fugue state")
  2) Atmega "lock up" if it's the cause and not the side effect of (1)

Could the Simblee detect the I2C bus "release" by the Atmega failing and
tell you exactly when that happens? This might be correlated with
voltage measurement logs (but you're only logging battery voltage, not
the IC's VCC, right?) Tacking on a tiny daughterboard to detect and
signal something to the Simblee would would not be too terrible. In my
opinion having two processors the way you do is a terrific demonstration
of the value of postponing optimization. :-)

-Pete





------------------------------

Subject: Digest Footer

_______________________________________________
TriEmbed mailing list
TriEmbed at triembed.org
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org


------------------------------

End of TriEmbed Digest, Vol 44, Issue 27
****************************************

_______________________________________________
Triangle, NC Embedded Computing mailing list
TriEmbed at triembed.org<mailto:TriEmbed at triembed.org>
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org<http://triembed.org/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20170124/74495038/attachment.htm>


More information about the TriEmbed mailing list