Scout v1.1 hardware revision

[amcjen]

• Add 10k pull-up to reset line (Missing pullup on the RESET pin #7)
• Add diode in parallel to 10k pull-up reset resistor (Voltage spike on RESET when Serial port is closed #6)
• Tie second pad on 16U2 crystal to ground (was not connected before)
• Replace LDO with lower-ripple alternative (LDO 3.3V unstable output #8) (STLQ015XX33)
• Add ground tie (0Ω) to pin 2 of balun
• Add 1MΩ pull-down to RX0/TX0 (reference to No way to tell if USB serial port is openend from 256rfr2 #3, 16u2 wastes power when USB disconnected #4, and Pinoccio resets when unplugging USB #5) <- Matthijs to review
• Change all caps in RF signal path to RF-rated C0G/NPO (Murata GRM series)
• Reduce C7 and C8 to 100nF, and make C0G/NPO or X7R (<-Atmel engineer, could be 1.0µF instead)
• Consider adding the SE2438T Front-end module (FEM) amplifier
• Change crystal caps to C0G/NPO rated
• Ensure all VDD high-current loops are not part of power or ground planes (when moving to 4 layer)
• Consider ferrite bead between digital and analog VDD lines
• Ensure AREF is decoupled with 0.1µF cap
• Consider adding voltage dividers for A* pins
• Consider decoupling of 0.1µF on all VDD/GND pin pairs
• Move to a four layer board (GND/VDD in the middle two layers, signals on outer two)
• Add VBUS voltage check (with voltage divider to kick 5v -> 3.3v) into RFR2 and 16U2 input
• Change 16U2 to be powered via VBAT always, instead of off of VUSB
• Tie 16U2 pin to RFR2 pin, to notify RFR2 when serial port is opened
• Add series resistor to 16U2->RST line, removing existing reset circuit
• Remove load switch from VUSB, as it's now unneeded

[jingman]

If there's a way to make it so that the scout does not reset when connected/disconnected from USB power, that would be awesome.

[eeintech]

@jingman: see #5

@erictj
What is U2 load-switch function? It seems like it is use in a diode fashion and add some redundancy to D3. I have removed it to from one my scout after I shorted U2 out to Ground (don't ask me how...) and just have the diode now, the circuit and scout performs similarly.

[matthijskooijman]

Eric and I just had a long talk over hardware issues, and a new proposal is to let the 16u2 be powered off regular VCC instead of VUSB, preventing it from powering down (instead, it will sleep when USB is not connected). This prevents issues with draining power (#4) but also allows fixing #5 and #6 by doing the reset pulse in software instead of hardware.

For detecting VUSB, this needs a voltage divider (5V -> 3.3V) connected to a pin on both the 16u2 and the rfr2 (it seems the 16u2 does not have any internal way to tell wether VBUS is applied).

[eeintech]

Has anyone investigated the oscillations on the output of the MCP73832 battery IC charger when battery is disconnected and USB power plugged in? It also makes the yellow charging LED to flash.

[amcjen]

What is U2 load-switch function? It seems like it is use in a diode fashion and add some redundancy to D3. I have removed it to from one my scout after I shorted U2 out to Ground (don't ask me how...) and just have the diode now, the circuit and scout performs similarly.

This load-switch was required to solve this issue. The load switch is there to minimize leakage between VBAT and VUSB when no USB power is plugged in. The diode was required because of the strange issue with the blog post above.

When you sizzled your load switch, did you just connect the in and out of the load switch to power the scout while USB is plugged in? Looks like it wouldn't power up otherwise b/c the PFET will disconnect upon USB power?

[amcjen]

Has anyone investigated the oscillations on the output of the MCP73832 battery IC charger when battery is disconnected and USB power plugged in? It also makes the yellow charging LED to flash.

I did during the initial board design. I believe a 100µF cap minimum is required across VBAT/GND (or the +/- through-holes underneath the battery JST jack) of the battery when running without any battery attached. I think this is in the 73832 datasheet, but decided to leave it off b/c 100µF caps are big, and we weren't going to sell Scouts w/o a battery. A cap should solve it though!

[amcjen]

@blathijs @cisco25 Here is a first pass at the next revision of the board. It covers most (but not all) of the changes listed above. Mind having a quick review to see if it's close? (Still need to add the bias connection for the RF FEM.)

[eeintech]

Few questions:

• 16u2 power: I believe UCAP is the output of the 16U2 internal regulator that you use to supply VCC/AVCC, so it's seems weird to me that UVCC is not connected to VBAT instead, could you explain how does that work?
• 16u2 reset: did you remove the 2k resistor to rely just on the internal pull-up?
• ADC-IN to Ax: it seems like you'r counting on users to input 0-3.3V signals on the ADCs, which ends up with 0-1.5V on the RFR2 pin, I remember being able to measure as high as ~1.7V until it reached 1023 but the current circuit would not let you do this, correct? I would also advise for a small cap (10nF) in parallel with the 100k resistors to stabilize the input signal.

I noticed that SEROPN (= Serial open signal?) is present on the RFR2 PG5 pin but the signal does not show on any of the 16U2 pin, you might want to make sure it connects.

This load-switch was required to solve this issue. The load switch is there to minimize leakage between VBAT and VUSB when no USB power is plugged in. The diode was required because of the strange issue with the blog post above.

When you sizzled your load switch, did you just connect the in and out of the load switch to power the scout while USB is plugged in? Looks like it wouldn't power up otherwise b/c the PFET will disconnect upon USB power?

Now I remember reading about that load-switch issue. On my board I completely removed the switch and actually even replaced the schottky with my "own" 1A schottky diode. I don't remember having any issue to switch between USB and Battery power but I will double check if the PFET issue happens and doesn't allow full battery voltage on the LDO input.

I did during the initial board design. I believe a 100µF cap minimum is required across VBAT/GND (or the +/- through-holes underneath the battery JST jack) of the battery when running without any battery attached. I think this is in the 73832 datasheet, but decided to leave it off b/c 100µF caps are big, and we weren't going to sell Scouts w/o a battery. A cap should solve it though!

Understood, just making sure that item was known.

[matthijskooijman]

16u2 power: I believe UCAP is the output of the 16U2 internal regulator that you use to supply VCC/AVCC, so it's seems weird to me that UVCC is not connected to VBAT instead, could you explain how does that work?

The power connections are made according to the 16u2 datasheet. See "USB Module Powering Options" under "USB Controller". This is the "Typical Self powered application with 3.0V to 3.6 I/O" on page 188.

AFAICS the internal regulator needs 4V+ to operate, so instead of using the regulator, we just supply a regulated 3.3V directly. Not sure why UVCC is still connected though, but the datasheet also says the internal regulator should be disabled in software.

It does seem that the VCC ->16u2's VCC is missing, or at least not clear from the schematic. I guess renaming the UCAP net to 16U2_VCC, or perhaps just merge it with the existing VCC net also makes sense?

16u2 reset: did you remove the 2k resistor to rely just on the internal pull-up?

Good point, I think the pullup should stay, there's no reason to remove it (perhaps you confused it with the rfr2 pullup in your notes, Eric?).

ADC-IN to Ax: it seems like you'r counting on users to input 0-3.3V signals on the ADCs, which ends up with 0-1.5V on the RFR2 pin, I remember being able to measure as high as ~1.7V until it reached 1023 but the current circuit would not let you do this, correct? I would also advise for a small cap (10nF) in parallel with the 100k resistors to stabilize the input signal.

Hm, doesn't the rfr2 offer an 1.5V reference voltage as well? It would be best if could cleanly map 3.3V onto one of the available AREFS.

I noticed that SEROPN (= Serial open signal?) is present on the RFR2 PG5 pin but the signal does not show on any of the 16U2 pin, you might want to make sure it connects.

I suspect it's connected to pin 12, but the label is hidden on the 16u2 side.

Some remarks of my own:

I just realized a big downside of these voltage dividers: They'll mess up the input voltage when using the pins as digital pins, making these pins effectively analog-only. I think this is a show-stopper - as someone on the forums pointed out, a lead scout would only be left with two digital pins if you cannot use the analog pins for digital I/O as well.

Having toggle-able resistor dividers would solve this, but then we'd need to have one extra I/O pin for each analog input (or an SPI-controlled expander / shift register), so I'm not sure how we can make that work...

So, perhaps somehow add a 1.8V source or something like that?

It seems that the yellow led is supposed to indicate USB power. It is connected to UCAP before, but that doesn't work anymore now. I guess it should just connect to VUSB directly (and have its resistor modified)? Or, looking more closely, it seems it indicates "charging", not "usb connected". Does the charger IC drive its STAT pin high when no VUSB is present? If so, the led can probably stay as-is.

You should probably rename the RESET_EN net (perhaps to RST, to match the label on the pin header?). The name seems to originate from the Uno design, which actually has a solder bridge to enable/disable auto-reset (hence "reset enable"), but I've found it confusing when looking at the schematic.

I think the VUSB_IN resistor divider is connected wrongly? It will put 5V on the IO pin now?

[eeintech]

It does seem that the VCC ->16u2's VCC is missing, or at least not clear from the schematic. I guess renaming the UCAP net to 16U2_VCC, or perhaps just merge it with the existing VCC net also makes sense?

This is what's missing in this schematic, there is currently no input power source. VCC power should be tied to 16u2 U/Vcc/Vcc/AVcc pins else 16U2 would not get power.

I just realized a big downside of these voltage dividers: They'll mess up the input voltage when using the pins as digital pins, making these pins effectively analog-only. I think this is a show-stopper - as someone on the forums pointed out, a lead scout would only be left with two digital pins if you cannot use the analog pins for digital I/O as well.

Just throwing that idea out: using a dedicated ADC chip like the ADS7828 (in smaller form factor maybe) that can give you a full range between 0 and 3.3V. That way you free up 8 digital pins... but not sure where you could map those extra pins to.

[matthijskooijman]

Eric and I just had another meeting. Eric just made a few more changes:

• Connected 16u2 power by merging the UCAP and VCC nets
• Renamed VUSB to VBUS and VUSB-IN to VBUS-SENSE for clarity
• Fixed the VUSB-SENSE divider
• Re-added the 16u2 reset pullup
• Added the SEROPN label at 16u2 pin 12

I think that was all the clear-cut comments, or are you missing anything @cisco25?

Regarding the ADC - adding an extra ADC doesn't really solve the problem, then you still can't use the pins as digital (unless you connect them to both the rfr2 and the ADC perhaps, but still). Putting dividers on half the analog pins could work, but would probably be very much confusing.

For now, we thought to just keep the analog pins as-is and leave it to the user to connect the voltage divider if needed...

Regarding the load switch, we thought that perhaps the switch stayed open because current flowed through the 16u2 VCC pins, If so, the diode might not be needed. Later, I realized that the most obvious explanation is that, when USB is unplugged, the VBAT FET switches (partly) on before the switch switches off, and then VBAT, through the switch, keeps the FET from completely switching on? If so, we'd need to keep the diode.

However I was thinking - why not ditch the load switch entirely and just wire VBUS to the charger and VBAT to the regulator? Then you'd just power through the charger always. It seems this is also how you'd wire things with this sparkfun charger module. Or are there any downsides to this? Current limits?

[matthijskooijman]

For the load switch, apparently another simple solution is to add a diode in each power input to isolate them from each other. I think that, because VUSB is always bigger than VBAT (and the difference is more than diode dropout voltage), we only need the diode on the VBAT side, not VUSB. However, I guess we can't afford to have a diode on the VBAT line, since then we get below the regulator's dropout voltage?

This post suggests some "ORing mosfet controllers" to switch between to power sources, but they might be too big or expensive?

Finally, I'm thinking that we might be able to completely remove the load switch and diode? If there is VBUS, the FET will switch off and the circuit is powered from VBAT. If there is no VBUS, the FET switches on and power comes from the battery - everyone happy? I think this is also what @cisco25 was saying he is using?

[matthijskooijman]

After reading @cisco25's post again, it seems he removed the switch but not the diode. That makes sense, since without the switch and the diode, VBAT would always turn the MOSFET (partly) off and we'd always have the low voltage condition when USB is not plugged in. Keeping the diode should be enough to prevent this, and we can suffer the voltage drop on VUSB.

[amcjen]

Finally, I'm thinking that we might be able to completely remove the load switch and diode? If there is VBUS, the FET will switch off and the circuit is powered from VBAT. If there is no VBUS, the FET switches on and power comes from the battery - everyone happy? I think this is also what @cisco25 was saying he is using?

Yep, I think this is correct that we can remove the load switch now. This wouldn't have worked if we were powering the 16U2 via VBUS, because when VBUS was unpowered, the diode reverse current is 100µA, and would have still leaked through the diode into the 16U2, affecting battery life.

Now that we're not powering the 16U2 via VBUS, when VBUS is disconnected, there is nothing on that net (unless something's plugged into the VUSB pin), so there should be no more leakage.

@cisco25 would you concur?

[eeintech]

Yes I agree, it should work, and I have simulated it to make sure: PowerInput

There is no reverse leakage into D1 (obviously, as not connected to anything when USB is pulled out) and the PFET turns on only when VBAT is connected with no USB. The rest of the time VUSB takes over.

There is some leakage of VUSB into VBAT for a short period of time when VUSB is plugged-in or removed (time for the PFET to turn off), but I don't think this is a big deal.

Note that it is still a better option to keep the PFET as it has a lower Rdson therefore less conduction losses than a diode.

[eeintech]

@erictj Where do you keep the updated schematics? I cannot seem to find them anywhere.

[amcjen]

Thanks @cisco25! I removed the load switch (and thank you for running it through spice!)

I just pushed the new schematics up to a v1.1 branch here. They're only in eagle files right now, but this will let you have a look.

I'd like to get this board layout completed very soon, at which point we'll make an order for a few new boards to test. Do you mind having a once-over to look for any other issues?

[eeintech]

It looks good overall but two points that would need a second pass is the front-end module and the uC decoupling.

Take a look at the front-end module reference design schematics (page 9) and note the 0.1uF/10pF per each power pin (VCC/VCC1/VCC2):

• 0.1uF to reduce inrush current loop
• 10pF to create low impedance path to ground at RF frequencies and avoid RF disturbances to be injected back in your power supply.

Note that they also recommend having a small inductor on VCC2, which makes a nice low pass filter out of this pin (this one must be really noisy). Depending on your choice of ferrite bead on the AVCC rail, it could also be used for that purpose, make sure the real impedance gets high in the RF frequency range and place this PI filter as close as possible from VCC2 pin to avoid any noise coming out further than this filter.

As for the decoupling of the two uC, I would recommend to switch to 0.1uF capacitor for each pin and make sure those are place as close as possible from the pin. The 1.0uF "bulk" capacitor can be use in complement to reduce the longest current loop, especially if the power pin is located on the other side on the board compared to the power source.

[amcjen]

Take a look at the front-end module reference design schematics (page 9) and note the 0.1uF/10pF per each power pin (VCC/VCC1/VCC2):

ah yeah, they do have two caps per pin there.

Note that they also recommend having a small inductor on VCC2, which makes a nice low pass filter out of this pin (this one must be really noisy). Depending on your choice of ferrite bead on the AVCC rail, it could also be used for that purpose, make sure the real impedance gets high in the RF frequency range and place this PI filter as close as possible from VCC2 pin to avoid any noise coming out further than this filter.

I think I'll add this one as well. Since we're moving to four layer, we'll have room down there. I want to get this one right.

As for the decoupling of the two uC, I would recommend to switch to 0.1uF capacitor for each pin and make sure those are place as close as possible from the pin. The 1.0uF "bulk" capacitor can be use in complement to reduce the longest current loop, especially if the power pin is located on the other side on the board compared to the power source.

Ok, will add. The Atmel reference design doc talks about adding 1.0µF per VCC pin, but the 100nF certainly can't hurt. There isn't a lot of room, but I'll add them and see what you think

[amcjen]

Hi @cisco25. Just pushed the changes up to the v1.1 branch. Three comments:

One, I added the additional caps to the FEM. I did not add the caps or inductor to the antenna trace, since that looks like the pi network they use to tune the RF trace to 50Ω. We already have a pi network on our antenna trace.

Two, the FEM's VB_IN pin is an input bias pin. The datasheet recommends feeding 1.8V into this pin, but we don't have a 1.8V regulator on our board. So I tied it to the 1.8V analog VCC (AVDD pin) regulator output from the 256RFR2 to this pin. I'm not sure this is a good idea yet, thoughts?

Lastly, I changed the 256RFR2 decoupling caps to 0.1µF, and added a single 1.0µF cap for the 256RFR2. However, this appnote on page 6 and 7 recommends 1.0µF for all *VCC pins on the 256RFR2 (though recommends 0.1µF for transceiver-only chips like the 233.)

[matthijskooijman]

Regarding the ADC inputs:

17:44 <+blathijs> Also, I think that using differential ADC measurements, we could perhaps get a 3.6V range on the ADC. DIfferential measurement can measure -VREF to +VREF, so if we'd fix one of the ADC pins to 1.8V, we could measure up to 3.6 V (the differential amp would do 3.6V - 1.8V, feeding only 1.8V into the actual ADC)
17:47 <+blathijs> Unfortunately, the ADMUX options don't allow internally select VREF as the negative end on the differential measurement, so it should be applied to ADC1 externally
17:48 <+blathijs> But I think this could be a matter of connecting the AREF and A1 pins on the header and then setting up the AD
17:48 <+blathijs> MUX register appropriately, so this could be made to work without hardware changes (except for wiring up AREF to A1, which can be done by the user with a jumper wire)
17:55 <+blathijs> Not sure if it's ok to use AREF like this, though
17:56 <+blathijs> I was trying to find out what the max load of the internal 1.8V regulators is (e.g. if we can load it externally), but it seems the datasheet doesn't say anything about this at all...
18:02 <+blathijs> eric: Oh, just noticed "IL,AREF", which says "Loading AREF is not recommended", but also says the max load is 0.1mA
18:05 <+blathijs> Nothing about the regulator, though

So, I think with the current design we can effectively double each
reference voltage by jumpering AREF to A1 and doing some ADC magic.

For rev1.1 we could consider making this connection internal, and
remove the A1 pin (replace it with something else?). However, I'm not
convinced if this is a good idea... Any thoughts?

(Note that it can only be A1/ADC1 here, because that's the only pin that
can be used as the negative end on a differential ADC reading with 1x
gain together with all other pins).

[eeintech]

@erictj

I'm sorry but I just realized that C8 (DVDD) and C19 (AVDD) are bypass caps for the internal regulators outputs (and not input power decoupling caps) so I think they should still be 1.0uF (instead of 0.1uF)... my bad! Other than that it looks good :)

Another question: are C29/C30 (on CRX/CTX lines) recommended by the dual-inverter vendor? What's their reason, stabilize the output?
I noticed that you added 100k pull-down resistors on the Front-end amp control lines (and I think that is a good idea) and it should probably be enough.
Also make sure R1 (2k resistor on RX/TX line) does not affect the inverter input drive, this value seem a bit high to me.

Connecting VB_IN to AVDD should work fine as it should not source much.
During my analog read investigation, I have looked the AVDD power rail and it is very clean.

[matthijskooijman]

On more idea: If the 16u2 stays on always, we could again connect I2C pins together. This could potentially replace the SEROPN and/or VBUS sense line if we'd need an extra pin (though perhaps keeping 1 line as a "something changed, please read status through I2C"-flag from 16u2 to rfr2 is probably useful to prevent needing to poll).

Anyway, I thought of this because I was thinking it would be good to have flow control between the 16u2 and the rfr2. If the rfr2 could set a flag when its buffer was full, or even when it goes to sleep, you would prevent dropping bytes. In the sleep case, it's even easy to pull a scout out of a sleep loop as well, which is currently pretty much impossible.

[matthijskooijman]

Hm, 16u2 doesn't have i2c hardware, so that won't work :-(

[dvanduzer]

@ChuckM Mind taking a look at this one?