SD card glitch during long builds

[AlexH]

Twice now I have encountered a situation where the Rep2 stops during a large build (screwless heart) and says that it found a glitch on the SD card and cannot continue. Has anyone else encountered this? Does a simple reformat of the card fix it? I am using the card that came with the bot

[Joseph Chiu]

Grab a different card.  Electrically, some cards are either marginal or just won't work in the Makerbots.  Not exactly sure why.  I bought a batch of 6 identical cards a while back -- 2 of them won't work with my Replicator, although they are still fine on the PC.

On Tue, Jan 29, 2013 at 9:00 AM, AlexH <a.s.hu...@gmail.com> wrote:

Twice now I have encountered a situation where the Rep2 stops during a large build (screwless heart) and says that it found a glitch on the SD card and cannot continue. Has anyone else encountered this? Does a simple reformat of the card fix it? I am using the card that came with the bot

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[xenogea...@gmail.com]

Reformat is something I would try, you should be able to back up whatever you have on it do your hard drive and wipe it.  Put everything back on it and try again.  I would also try another SD card if you or someone you know have one.

[AlexH]

I have read that not all SD cards work with the Markerbot, and that only the older 2GB ones do. Is this true?

[Joseph Chiu]

Yes.

--

[Ethan Dicks]

On Tue, Jan 29, 2013 at 12:59 PM, AlexH <a.s.hu...@gmail.com> wrote:
> I have read that not all SD cards work with the Markerbot, and that only the
> older 2GB ones do. Is this true?

Mostly true... cards older and smaller than 2GB also work just fine, but they
are impossible to find at ordinary retail/computer stores.

I have a small stack of ancient HP-badged 64MB and 128MB SD cards. They
work great.

2GB SD cards are still available in the checkout lines at the Micro Center, for
something around $3 each, but who knows how much longer they will bother
to carry them.

eBay and surplus/discontinued merchandise vendors will probably be the best
source for older/smaller SD cards into the future. The problem is that it's
hard to get someone to bother to box something up and send it to you when
it has a perceived value of pennies (if a 2GB card is "worth" $3, what's a
256MB card "worth"? 35 cents?) If only someone would batch up a set
of 5 or 10 older cards for a few dollars - that would be very useful to the
MakerBot community.

-ethan

[AlexH]

Not a bad idea. I might look into what a batch of them would cost. Thanks for the help! I guess i must have just got a bum one from MBI. It seems to work on small prints just fine but large ones that take over 2 hours dont seem to work

[David Kessner]

I just ordered 4 of them from newegg.com.  They have many different brands of 2 gig cards, most US$5-6 and with free shipping.  Just for grins, I bought four different brands.

[Nagalfar]

Had the same issues and more with the original Makerbot SD card as well with a 2 year old 512 mb model. The Rep 2 card reader is a bit of a diva here and can't handle errors pretty well so you really might want to stock a few cards once you found a good quality model. I expect sd cards to start failing at some point, depending on the quality.

[Dan Newman]

Part of the issue may well be the noise (electrical) over the ribbon cable
which runs from the motherboard to the LCD interface card which also houses
the SD card slot. MBI has gone to doing each read twice from the SD card to
try to catch read errors. A better, but slightly more expensive design, would
be to put a uProcessor on the LCD interface card and have it handle the SD
card and then use a more robust comms with the mainboard. With that setup,
one could also handle firmware update via SD card. (Not enough room to do
that directly in the main uProcessor's boot loader, but can be done when you
have an independent SD card reader which handles the low level SD card
i/o. Would even have room for code for FAT-32 and thus larger cards.)

Dan

[David Kessner]

I'm an electrical engineer, and I design lots of high speed digital stuff.  One thing that I have noticed with open source hardware, and those who have an open-source mentality is that they tend to ignore issues of signal integrity, signal termination, and ESD protection.  Any of these issues will cause problems with an SD card on the end of a cable.   My GUESS is that the design could be improved without having to put an MCU right at the SD card.  Likewise, if the design doesn't have good ESD/EMI then an MCU won't fix the problem either. 

According to FedEx, my Rep2 should arrive today.  You can be that is one aspect of the design I will be looking over and potentially improving.

[Dan Newman]

On 30 Jan 2013 , at 9:03 AM, David Kessner wrote:

> I'm an electrical engineer, and I design lots of high speed digital stuff.
> One thing that I have noticed with open source hardware, and those who
> have an open-source mentality is that they tend to ignore issues of signal
> integrity, signal termination, and ESD protection.

There's plenty more things they ignore -- don't get me started. (See threads
on HBP connectors and the underguage wiring to name just one.)

> Any of these issues
> will cause problems with an SD card on the end of a cable. My GUESS is
> that the design could be improved without having to put an MCU right at the
> SD card. Likewise, if the design doesn't have good ESD/EMI then an MCU
> won't fix the problem either.

Agreed. And for all I know a very inexpensive ferrite bead or two is all
that is needed. I'm certainly not an EMF expert.

Dan

[Gary Crowell]

FWIW, I've glanced at the board, and it looks like they've made an extraordinary effort at EMC/ESD compliance.  Can't judge if it's effective, but they've made an effort.  Compared to zilch on the Replicator MightyBoard. 

Gary

--

You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
----------------------------------------------
Gary A. Crowell Sr., P.E., CID+

Linkedin  Elance  KE7FIZ

[Joseph Chiu]

That is great to hear.   At some point, someone is going to slap MBI's hand for not being FCC/UL/CE if they're still building them the way they used to.   

[Jonathan Galloway]

I have been repeatedly getting this error on any medium to large print attempt.  Using the card that came with the rep2.

Going to try the exact same file, from repG via usb.

[Dan Newman]

Which firmwares are you running? If you're using Sailfish 7.3, then you can
enable SD card error detection/correction. It will check for read errors
and attempt to re-read the data block. If, after 5 consecutive attempts to
re-read the same block, it still cannot read the data without errors, then
Sailfish cancels the print. The feature has to be enabled via Utilities > General
Settings.

If, on the other hand, you are using Sailfish then you can see if you have
that feature enabled it's normally off by default but it seems that folks
sometimes switch to Sailfish but don't reset their EEPROM to factory defaults
so it's hard to know what is or is not enabled. Anyway, if you are using
Sailfish and that feature is enabled, then you can try printing with it off
and see what happens: maybe the corrupted data is a corruption that won't
make the bot go crazy….

Dan

[Jonathan Galloway]

Should I be putting the sailfish firmware on my rep2?  I am a bit of noob at this (although I have been 3d modeling for 20 years)

I've been having some minor issues also with the extruder skipping lines ... and I just got my spring and bearings in the mail today, so I am going to go ahead and print and install the extruder block upgrade.  when I disasemble it, I can also make sure it just isn't clogged.

I am struggling a bit with my setup.  I currently have my bot attached to my tablet on my workbench (which is only 2 cores) and I want to build on my 6 core workstation (because it is SO slow to slice), so basically I was building to the sd card then printing directly from the card.  Now I have setup dropbox, and I am trying to slice on my workstation, save to dropbox, then grab it on my tablet.  But I am having trouble with the workflow, how do I save the g-code on my workstation so that I don't have to rebuild the slicing data every time I try and print?

[Darrell jan]

Last night I had an SD error after an hour of printing. So this morning I enabled SD error checking in the onboard preferences.

What happened next was that none of my 3 SD cards would work. All reported errors, including the one that came with the bot and had never errored before. So, next I tried disabling the SD error checking. I got a different error message, to reformat the card to FAT-16. Which they supposedly already are.

At this point, will reformatting help? Are the cards trashed? for Replicator use, that is--they still work fine in my computer.

Darrell

[Darrell jan]

So, do I try to shield the ribbon cable? 

On Sunday, March 17, 2013 9:17:59 AM UTC-7, Jetguy wrote:

It's not  that the card is bad, the checking is checking the read data
off the card. On the bot, there is a problem because the SD card slot
is far away from the actual mainboard where the CPU sits. That ribbon
cable that connects the LCD control panel with LCD slot acts like an
antenna and picks of all kinds of EMI/ RFI noise inside that metal
housing from the power supply, motors and all other things electrical.
Heck a fluorescent light nearby caould cause a bad read.

Enabling checking via firmware runs checkksums on each block of data
read. That means that you have an EMI/RFI problem if you enabled it
and now cannot read cards- not a card problem.

[Joseph Chiu]

Shielding might help, but as Dan reported about a week or two ago, there maybe excess loading on the SD Card line, due to the ribbon cable capacitance.

I've been pondering making a buffer board that sits between the front panel and the Mightyboard, since I have a few SD Cards that fail on my Rep 1 (pre- CRC-enabled firmware) -- I haven't done it yet because I've had enough other cards working -- but it sounds like there might be a need for this...   It shouldn't cost much -- just a few dollars using surplus parts, or about $10-$15 using stuff off Digikey...

--

[Dan Newman]

On 17 Mar 2013 , at 9:08 AM, Darrell jan wrote:

> Last night I had an SD error after an hour of printing. So this morning I
> enabled SD error checking in the onboard preferences.
>
> What happened next was that none of my 3 SD cards would work. All reported
> errors, including the one that came with the bot and had never errored
> before. So, next I tried disabling the SD error checking. I got a different
> error message, to reformat the card to FAT-16. Which they supposedly
> already are.

That "reformat to FAT-16" is a misleading error message which the
current Sailfish as well as the current MBI firmwares will tell you.
It's the code having a knee-jerk reaction to not being able to open
the FAT file system on the card. I spent some time looking into that
about two weeks ago, putting in finer grained error handling. And,
I discovered that generally, the problem is that the combination of
SD card + the bot's electronics are making it such that the card
cannot reliably be read at 4 MHz speeds. I actually had Sailfish
back down the speeds until card comms did work, but then prints
still usually failed -- things are just too borderline in those
cases.

So, likely your card is okay when used from something with
reasonable electronics (e.g., your laptop). But when used with
a Rep 1 or Rep 2 which runs the SD card comms over a 10 inch
ribbon cable and through 5 electrical terminations and with
other noisy wires nearby in both the cable and on the motherboard,
then things aren't working for you.

(Just the cable capacitance alone is right near the edge of what
the SD card elect. spec allows.)

BTW, what happens in the firmware is

1. Communicate at ~125 KHz with the SD card to initialize comms
and do initial handshakes.

2. After 1 succeeds (which it usually does), then go to high speed.
In this case that means 4 MHz.

3. Access the FAT file system on the card. If that works, then good.
If it fails, then you get the "FAT-16" error message.

It's with 3 that I was able to do some diagnosis when I found I
had an SD card which was borderline. It worked fine in my laptop,
with my thingomatic, and with an Arduino shield with SD card support.
It did not work in my Rep 1 nor Rep 2. I was then able to analyze
the problem and see exactly when 3 was failing. It was basically
all comms after increasing the comms speed to 4 MHz. I then made
that code heuristic -- it would keep on backing off the speed until
things worked. I could then get fairly far into prints, but
invariably they would fail with CRC errors. Basically, if the
card + bot system is borderline, then it's best just that you use
a different card.

> At this point, will reformatting help?

Probably not: it's an electrical problem with the card + bot combo
being just enough out of spec for things to work well.

> Are the cards trashed?

They're likely good enough to use with your computer.

> for Replicator use, that is--they still work fine in my computer.

This is why in the next Sailfish we want to have SDHC + FAT-32 support
in, (It's in for the Rep 2 and ToM in the alpha test code.) Problem
as I understand it is that no one is making 2 or 1 GB cards intentionally
any more. The new cards sold as 2 or 1GB are the cards meant to be
4, 8, 16, etc. cards which had bad sections on them or otherwise couldn't
handle the rated speeds. So, before being slabbed (put in their plastic
carrier), they were lasered by the automated machinery to be SDSC and
only 1 or 2 GB. I don't expect this to get any better and so supporting
SDHC and higher capacity cards is important IMO.

Dan

[Dan Newman]

On 17 Mar 2013 , at 9:23 AM, Darrell jan wrote:

> So, do I try to shield the ribbon cable?

EMF shielding is really tricky stuff. Especially a problem when
the underlying design is suspect. Using a long ribbon cable for
SD card comms is a bad idea in the first place: too much capacitance,
noise from other signal lines on the cable, too many terminations in the
system which cause reflections. (There's at least 9 terminations: card
contacts, sd card holder fingers, pcb header, ribbon header, ribbon
header pins crimped to ribbon wires, ribbon wires at other end again crimped,
ribbon header at other end, header on mother board), etc. The reason high
speed ethernet works with so many terminations is because there's lots
and lots of silicon in the switches & hubs to filter out the many forms
of cross talk and reflections. Not to mention using twisted pairs and
balanced signals.

Dan

[Dan Newman]

On 17 Mar 2013 , at 9:30 AM, Joseph Chiu wrote:

> Shielding might help, but as Dan reported about a week or two ago, there
> maybe excess loading on the SD Card line, due to the ribbon cable
> capacitance.
>
> I've been pondering making a buffer board that sits between the front panel
> and the Mightyboard, since I have a few SD Cards that fail on my Rep 1
> (pre- CRC-enabled firmware)

The CRC handling clearly just helps in a certain range of borderline cases.
If things are sufficiently out of spec, then there will be a higher probability
of reads which will fail to pass CRC checks more than 5 times in a row. So,
while it's helpful in some cases, it's not a universal solution.

> -- I haven't done it yet because I've had
> enough other cards working -- but it sounds like there might be a need for
> this... It shouldn't cost much -- just a few dollars using surplus parts,

> or about $10-$15 using stuff off Digikey…

Yup. I think I even ran across some documents from the SD card consortium
on how to do line drivers for longer SD card runs. But it's not rocket
science. I'll see if I can find them again: I didn't pay much attention
as it looked to be line driver 101.

Dan

[Darrell jan]

My cards seem to be readable again for the moment. Last night and early this morning, when I had failures, almost nothing in the house was on. I wonder if my neighbors were up to something. 

Darrell

[Gary Crowell]

I hadn't looked at the LCD card in quite awhile.  If we thought the MightyBoard was poorly designed - this one is worse.  As you've noted, the 3V3 regulator supplying the SD card and its level translator chip is on the MightyBoard, a cable length and 5 inches of board trace away.  And, as far as I can see, there is -zero- power capacitance on the LCD board.  None.  This is insane.  This is a miracle of the first order that it works at all.  The power rails have got to be bouncing all over the place.

I'm ordering a pcb today that moves the regulator to the LCD, and adds ESD protection to those lines as well.  Signals to the SD are effectively buffered by the translator chip, but the data line from SD to processor is not.  I'll take a look at adding a buffer to that before I send the board out.

Gary

Dan

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dan Newman]

On 17 Mar 2013 , at 11:58 AM, Gary Crowell wrote:

> I hadn't looked at the LCD card in quite awhile. If we thought the
> MightyBoard was poorly designed - this one is worse. As you've noted, the
> 3V3 regulator supplying the SD card and its level translator chip is on the
> MightyBoard, a cable length and 5 inches of board trace away. And, as far
> as I can see, there is -zero- power capacitance on the LCD board. None.

> This is insane. This is a miracle of the first order that it works at
> all. The power rails have got to be bouncing all over the place.

Oh my gosh. I never noticed that but yes that is a bit of a disaster.
And, FYA,

http://www.vagrearg.org/content/decoupling

As I commented a few weeks ago, I'm somewhat curious just what they
teach in EE classes these days. I know that H & H is still the
gold standard and it certainly covers these issues…. But this
board design isn't alone in neglecting these issues as witness the
URL I cited above.

Dan

[Joseph Chiu]

Are you sure about the translaters? My suspicion is that they aren't buffering, and that is why we are having this problem.

[Gary Crowell]

Well good grief.  I had glanced at the circuit and assumed it was a level translator.  It is a '125 buffer.  AHC flavor it runs of off 3.3 fine, supplying 3V levels to the SD,  but running it with 5V cmos inputs is outside its recommended operating range.  Maybe it works, maybe something I'd do on the bench - but I'd never put that into a shipping product.  Not much to do about except by hacking up the LCD board, but maybe... 

Gary

[Darrell jan]

Maybe I should move my wireless router?

On Sunday, March 17, 2013 10:03:05 PM UTC-7, Wingcommander whpthomas wrote:

On Monday, 18 March 2013 04:56:40 UTC+10, Darrell jan  wrote:
> My cards seem to be readable again for the moment. Last night and early this morning, when I had failures, almost nothing in the house was on. I wonder if my neighbors were up to something.

Maybe keep your mobile phone or ipad away from you printer.

[David Celento]

Which printer is under discussion? I kind of lost track somewhere.

[Joseph Chiu]

I finally got to looking at the LCD board schematics this morning.  It's at http://thingiverse-production.s3.amazonaws.com/assets/e4/7d/f2/c3/c8/MakerBot_Replicator_Interface_REVB_Schematics_and_Fab_Files.pdf

Until I saw the schematics again, I had forgotten the details of how it was made -- but now, I'm pretty sure what the problem is -- the return signal from the SD Card is unbuffered, going into the ribbon cable.  It's sending back data at 3.3V signaling levels, while everything else is at 5V swing levels.  

There are some possibilities to just "patch" the LCD board...

There might be some useful margin to get back by decoupling the supply with a 1uF and 0.1uF across +3.3/GND.

Next, it might be enough to use the existing 125AHC buffer: lift J3.7  (SDCard DO) and U5.12 (Unused buffer) off their pads, connect J3.7 to U5.12, and connect U5.11 (buffer output) to P1.20 (Ribbon cable MISO).  

Probably better is to put in a 5V buffer -- Lift J3.7 (SDCard DO), piggyback a SOT-23 buffer (U1000: SN74LVC1G126) on top of P1.1 (+5V), GND (P1.2), and then blue-wire J3.7 (DO) to U1000.2 (buffer input), 5V to U1000.1 (OE), and U1000.4 (buffer output) to P1.20 (MISO on ribbon cable).

This is all on the same side of the board, so should be easy to blue-wire.

The other possibility is to make a interstitial board that sits right behind the LCD board, so that no changes have to be made to the LCD board itself.  If there's enough interest, I could design that and upload it on Thingiverse.

[Joseph Chiu]

Replicator.  No idea what the 'tronics on the R2 or R2x looks like.

On Mon, Mar 18, 2013 at 6:30 AM, David Celento <dcel...@gmail.com> wrote:

Which printer is under discussion? I kind of lost track somewhere.

[David Kessner]

Ok, so my day job is as an Electrical Engineer.  I've been doing this for 25+ years, and have made dozens of mass-produced products.  I think I'm qualified to review the LCD board schematics.  I am going to assume that the board on the other side of the cable is similar.

Let me start by saying that the problem is not cable capacitance, lack of buffers, type of buffers, etc.

The primary problem is lack of signal termination of any kind.  This will cause lots of problems because the signal is ringing all over the place.  The severity of the ringing will vary depending on temperature, voltage, unit-to-unit variations, as well as the SD card itself.  If the ringing is close to the edge, then things like cell phones, microwave ovens, power disruptions, etc. can easily throw it over the edge and cause a failure.

A "minor" problem is that there are no EMI/ESD filtering and protection devices.  A static-zap within several feet of the Bot (and not directly on the bot itself) could cause a data error as well.

Another major problem is the lack of decoupling and signal-return-bypass caps.  

These are rookie mistakes, and should have been caught in many phases of development including:  Schematic design review, Product Qualification Testing, and EMC compliance testing.  It took me about 60 seconds to find the problem, and most of that was dealing with Acrobat Reader and not looking at the schematics themselves.  

The Head EE at MBI should be fired-- and that's not hyperbole.  Either he/she doesn't know how to properly design a circuit, or he/she doesn't know how to review a design done by others.  These are super basic things that any company should get right when making a product.  Of course, these products should go through EMC testing and I'm betting that they have not.

As a side-rant:  Arduino "people" frequently get these details wrong.  I wonder how much of this culture has rubbed off on MBI and made them think that shoddy PCB design is acceptable.

[Joseph Chiu]

Thanks David.

I thought about terminations resistors, too -- but with this running at 4 MHz and the edge rates probably not very high (I haven't scope to check), I assumed that termination was not the dominant problem with this the synchronous interface.  If it was spurious clocking from ringing, I would expect the problem to show up at the lower speeds, too.   Nevertheless, putting a TR on SCK is easy, so it should certainly should be on the list of things to do. 

[Gary Crowell]

The add-on board that I'll have ready to send out later today, plugs into the LCD board and the ribbon cable plugs into it.  It incorporates the following:

1. Bulk capacitance and a bypass cap on the 5V rail.  (yeah, the bypass cap is probably too far removed to do any good...)
2. A 3V3 linear regulator, with bulk cap and bypass on the output.
3. TVS diodes on all cable signal lines.
4. A 5V receiver/driver on the SD signal lines, and a 3-to-5V level translator on those lines to the SD.  Series terminator on the return SD data line.

That's all I can think of doing without hacking on the LCD board, or replacing it entirely.

Any other suggestions/ideas/requests?

Gary

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joseph Chiu]

Don't forget the TR on the clock line. 

[Joseph Chiu]

On Mon, Mar 18, 2013 at 10:36 AM, David Kessner <david...@gmail.com> wrote:

These are rookie mistakes, and should have been caught in many phases of development including:  Schematic design review, Product Qualification Testing, and EMC compliance testing.  It took me about 60 seconds to find the problem, and most of that was dealing with Acrobat Reader and not looking at the schematics themselves.  

The Head EE at MBI should be fired-- and that's not hyperbole.  Either he/she doesn't know how to properly design a circuit, or he/she doesn't know how to review a design done by others.  These are super basic things that any company should get right when making a product.  Of course, these products should go through EMC testing and I'm betting that they have not.

As a side-rant:  Arduino "people" frequently get these details wrong.  I wonder how much of this culture has rubbed off on MBI and made them think that shoddy PCB design is acceptable.

It's not that it "rubbed off" on MBI.  From what I understand, MBI started out with artists and software folks that self-taught themselves the electronics and hardware.  

So they had knowledge gaps about proper electronics design, fabrication, assembly, EMC, safety, vibration, reliability, serviceability, timing (hardware), timing (isr code), sourcing, machining, casting, tolerance stackups, etc., etc., etc.   It's part of how they got to be successful -- by not being weighed down by such details -- and why it's now starting to bite them...

[David Kessner]

When modifying the current design to "fix" it, the number one thing is to make sure it is done right.  (Note:  I really don't know any of you, so don't take this personally!)  The absolute worst thing that can happen is for someone to make mods to the board, run some test prints, and based on that decide if the mods worked.  That's what MBI would do, and it does not guarantee that an improvement was really made.  You have to get a good scope (100 MHz, minimum) and use proper probing techniques to validate the mods.  That is the only way to verify that an improvement to the signal integrity was actually accomplished.  Otherwise, you're basically playing resistor/cap roulette.

Honestly, the board should be redesigned.  There are so many things wrong with it from a signal integrity point of view.  Many of the issues are not fixable without redesigning the PCBs.  

But if I were going to modify the board by hand (and not modify the Mighty Board), here's what I would be doing, in order of importance:

1.  Add bulk power caps at P1.  About 100+ uF between VDD and GND, and another 100+ uF between 3.3V and GND. 

2.  Add some AC signal bypass caps at P1.  Solder some SMD 0.1 uF caps between VDD and GND, and another cap or two between 3.3V and GND.  It is important that the leads/wires for this are super short.  Ideally you'd find some vias on the back side of the PCB that you can scrape off the soldermask and solder the caps directly to the vias.  It might be easier to do this if you have a few different sizes of SMD caps to choose from.

3.  Add terminating resistors to ALL signals, not just the clock(s).  At a bare minimum to MOSI, MISO, SCLK, and CS.  Outputs from this board to the Mighty Board should have a series termination resistor near the "driver".  It is hard to know the exact value since the trace impedance of this design is all messed up, but somewhere in the 22 to 100 ohms.  50 Ohms is a good place to start.  For input signal (from the Mighty Board), you want a resistor and cap to GND (R and C in series).  Use the same 22-100 ohm range for the resistor, but the cap should be about 0.1 uF.  If you can, put series resistors on the output of the buffer (U5) as well (start with 50 Ohms).

4.  While adding ESD diodes to each signal is good, there are often better ways to deal with it.  Adding 2.7+ nF caps to the signals is really good _IF_ the signal can handle that amount of capacitance.  Some can and some can't.  Signals that can are the button signals, CARD_DETECT, WR_PROTECT (probably), RED_LED, and GREEN_LED.  For the faster signals, use low-capacitance ESD diodes.  Note:  TVS diodes are not ideal because they often do not kick in quick enough for ESD help.  They help, don't get me wrong, just some good/fast clamping diodes to the power rails works better.  ESD diodes should be put on both inputs and outputs.

Level translators are not really needed.  It is mainly only important when going from 5v to 3.3v logic, since a lot of 3.3v logic parts will blow up if you give it a 5v input signal.  This board already has a level translator for that.  When going from +3.3v logic to +5v TTL logic a level translator doesn't do much (it does if you are going to 5v CMOS inputs).  5v TTL inputs have 0.8v and 2.0v input thresholds, which are fine with a 3.3v input signal.  

[Joseph Chiu]

Hi David,

I agree in principle that the board should be redesigned - but as a practical matter, that's MBI's responsibility.  I'm hoping that we can offer at least some kind of a minimalistic but workable fix that could be used.  

100 uF sounds a bit heavy for the application - I don't think we're having bulk problems.  Especially given all the talk of R1 mightyboard board failures, I personally am reluctant to add bulk caps.  I think bypass caps are the biggest payoff, so a 0.1 and 1.0 close to the SD card makes sense. (I wrongly wrote decoupling in the earlier post.).

As you already pointed out, this board lacks impedance control -- but heck, so do pretty much all 2 layer boards -- supposedly, 50 mil ribbon cables have inter-line impedance of about 120 ohm.  So I would think something in that ball park is a good starting place.   RC termination would be better on the receiving side.

For the patch board, I'm not sure I'd bother with the ESD stuff.  I feel like putting them there is putting locks on a few barn windows, while a bunch of other windows and doors are left open.  

2.0v input threshold on a line with high capacitance and a weak driver could fail to transition.  It could go metastable.   

More importantly, the Atmega has V(IL) of 1.5V, V(IH) of 3.0V.   Yes, you read that right.  Crazy, I know. 

On Mon, Mar 18, 2013 at 12:46 PM, David Kessner <david...@gmail.com> wrote:

When modifying the current design to "fix" it, the number one thing is to make sure it is done right.  (Note:  I really don't know any of you, so don't take this personally!)  The absolute worst thing that can happen is for someone to make mods to the board, run some test prints, and based on that decide if the mods worked.  That's what MBI would do, and it does not guarantee that an improvement was really made.  You have to get a good scope (100 MHz, minimum) and use proper probing techniques to validate the mods.  That is the only way to verify that an improvement to the signal integrity was actually accomplished.  Otherwise, you're basically playing resistor/cap roulette.

Honestly, the board should be redesigned.  There are so many things wrong with it from a signal integrity point of view.  Many of the issues are not fixable without redesigning the PCBs.  

But if I were going to modify the board by hand (and not modify the Mighty Board), here's what I would be doing, in order of importance:

1.  Add bulk power caps at P1.  About 100+ uF between VDD and GND, and another 100+ uF between 3.3V and GND. 

2.  Add some AC signal bypass caps at P1.  Solder some SMD 0.1 uF caps between VDD and GND, and another cap or two between 3.3V and GND.  It is important that the leads/wires for this are super short.  Ideally you'd find some vias on the back side of the PCB that you can scrape off the soldermask and solder the caps directly to the vias.  It might be easier to do this if you have a few different sizes of SMD caps to choose from.

3.  Add terminating resistors to ALL signals, not just the clock(s).  At a bare minimum to MOSI, MISO, SCLK, and CS.  Outputs from this board to the Mighty Board should have a series termination resistor near the "driver".  It is hard to know the exact value since the trace impedance of this design is all messed up, but somewhere in the 22 to 100 ohms.  50 Ohms is a good place to start.  For input signal (from the Mighty Board), you want a resistor and cap to GND (R and C in series).  Use the same 22-100 ohm range for the resistor, but the cap should be about 0.1 uF.  If you can, put series resistors on the output of the buffer (U5) as well (start with 50 Ohms).

4.  While adding ESD diodes to each signal is good, there are often better ways to deal with it.  Adding 2.7+ nF caps to the signals is really good _IF_ the signal can handle that amount of capacitance.  Some can and some can't.  Signals that can are the button signals, CARD_DETECT, WR_PROTECT (probably), RED_LED, and GREEN_LED.  For the faster signals, use low-capacitance ESD diodes.  Note:  TVS diodes are not ideal because they often do not kick in quick enough for ESD help.  They help, don't get me wrong, just some good/fast clamping diodes to the power rails works better.  ESD diodes should be put on both inputs and outputs.

Level translators are not really needed.  It is mainly only important when going from 5v to 3.3v logic, since a lot of 3..3v logic parts will blow up if you give it a 5v input signal.  This board already has a level translator for that.  When going from +3.3v logic to +5v TTL logic a level translator doesn't do much (it does if you are going to 5v CMOS inputs).  5v TTL inputs have 0.8v and 2.0v input thresholds, which are fine with a 3.3v input signal.  

[Joseph Chiu]

BTW, the LVC1G126 turns out to be not a good part for this, either, for driving to 5V.

The LVC1T45 looks like the better choice, though it's a little more work to hook up.

[David Kessner]

100 uF sounds a bit heavy for the application - I don't think we're having bulk problems.  Especially given all the talk of R1 mightyboard board failures, I personally am reluctant to add bulk caps.  I think bypass caps are the biggest payoff, so a 0.1 and 1.0 close to the SD card makes sense. (I wrongly wrote decoupling in the earlier post.).

You are most certainly having bulk problems, the real question is if the problems are big enough to cause SD card failures.  Until somebody puts an o-scope on the power nobody will know for certain how bad it is.  I picked 100 uF as a random starting point, and admit that I did err the large side.  Usually err-ing on the large side for bulk caps is better than going low.  But if you are concerned about the MightyBoard then by all means scale this back.  I would not, however, go under 4.7 uF.  If you are concerned about inrush current then you can always put an inductor in there to slow that down (but that's overkill).

 

As you already pointed out, this board lacks impedance control -- but heck, so do pretty much all 2 layer boards -- supposedly, 50 mil ribbon cables have inter-line impedance of about 120 ohm.  So I would think something in that ball park is a good starting place.   RC termination would be better on the receiving side.

50 mil ribbon cables have somewhere in the 100-150 ohm single-ended impedance between adjacent wires.  Most cables don't bother even spec'ing impedance.  Even when they do spec it, the variations within the same cable is huge.  But the key thing is "between adjacent wires".  For this impedance to mean anything useful, one of those wires is the signal while the other wire is a power/ground.  On this cable, most of the power/grounds are lumped together at one end where it does nothing useful to control impedance or signal return paths or loop area.  For this cable and pinouts, the impedance is probably closer to 300 to 600 ohms (yuck!).

The point is, the cable impedance number doesn't mean anything useful.  The value of the terminating resistors really just ends up being picked by trial and error.  You want a value that produces a signal integrity that is "good enough", but it may not look nice.  It will never look nice with this PCB.  This is why you need to use a good o-scope and proper probing to figure out what is a good value.

You can do proper signal impedance with a 2 layer PCB, but it requires planning and actual, you know, knowledge!  :)   But it certainly isn't easy, and it is super hard to do for more than a couple of signals.  For this PCB, the proper thing to do would be to put the connector right next to the buffer/driver/receiver so that the length of trace that does not have good impedance control is super short.  Oh, and you use a cable with reasonable impedance control.  In my opinion, the cable and the pinouts of the cable are the biggest problem to terminating these signals properly.

For the patch board, I'm not sure I'd bother with the ESD stuff.  I feel like putting them there is putting locks on a few barn windows, while a bunch of other windows and doors are left open.  

It really depends on where you live, and how bad ESD is in your area.  I live in Colorado, and the air inside can be very dry in the winter.  I am more likely to care about ESD than someone who lives in a humid environment.  But, I would leave ESD protection off of a "patch board" as well, just because you want the ESD protection at all ends of the cables, and if you need to add a second cable when using a patch board then you're still not protecting the LCD board or the MightyBoard. 

I should note that I have not personally seen an ESD problem with the Rep2.  But I have it in the only room of the house that has wood floors instead of carpet.  

2.0v input threshold on a line with high capacitance and a weak driver could fail to transition.  It could go metastable.   

Yeah, don't do that!  You must use the o-scope to verify that your signals look good (which should be done anyway).  

2.7nF isn't a lot of capacitance, but it is too much for fast signals.  That threshold between "too fast" and "slow enough" depends on the source and load impedance and some other things.  But generally speaking, things that are less than 100 KHz are almost always fine with it and signals faster than about 10 MHz are not fine with it.  But as with all things, your mileage may vary.  The nice thing about using caps for ESD protection is that it also protects you from receiving and transmitting RF-- unlike protection diodes which just protect you from ESD.

More importantly, the Atmega has V(IL) of 1.5V, V(IH) of 3.0V.   Yes, you read that right.  Crazy, I know.

Ok, I take back what I said about not needing level translators when going from 3.3v to 5v.   Was the Atmega

designed by MBI?!?!?!  :)

 

[Darrell jan]

Sorry I was offline yesterday, but it's good to see all the activity. 

[Matt Minuti]

This is part of the reason I'm designing a completely new board. It's infuriating to see how many of these poorly designed boards are out there, and the frustration they've been causing people. I've been a bit swamped with other work lately, but I've gotten nearly all of the MCU pin assignments set, most of the "support" chips specced out, and I've got a few sample connectors on the way which will hopefully end all that "I unplugged my stepper driver while it was engaged and everything permanently died" stuff people are so apt to do.

I'm standing by my earlier promise: as soon as I have enough of a design drawn up in EAGLE to be worth looking at, I'll put it up on github. I've got my fingers crossed that I'll be able to do so at the end of this week. And I'm quite looking forward to people like you guys tearing it apart - the more that happens before it goes into production, the more likely we are to have a damn good board! :)

[David Kessner]

Matt,

 

I would love to review your design when you are ready.   Just let me know when/where

it is available for review.

 

-David Kessner

[Gary Crowell]

I've ordered boards for an LCD fix, and an ENDSTOP fix.  the LVC1T45's fit in great.

The ENDSTOP board adds TVS diodes to all of the data lines, series resistors in the endstop power lines, and replaces the 5V regulator with a switcher module.

Gary

[Joseph Chiu]

So I have taken another look at the Replicator Mightboard Rev E schematics today because I am working on a project where I want to use a SD card.  While cross checking various resources, I noticed two things - 1) although the Mightboard Rev E schematics labels the SD card section as "SD&MMC", the actual pinout used is the MicroSD pinout.  (The fab drawing for the Mightboard shows a MicroSD slot)    The LCD interface board, of course, shows the proper connector for a regular SD card.   2) I haven't opened the Eagle design, but given the placement of the microSD slot and the interface cable connector, there is almost certainly stubs from the ATMega to the unpopulated MicroSD card pads - that could cause the signal integrity issues that we are seeing.

[Dan Newman]

On 12 May 2013 , at 12:40 PM, Joseph Chiu wrote:

> So I have taken another look at the Replicator Mightboard Rev E schematics
> today because I am working on a project where I want to use a SD card.
> While cross checking various resources, I noticed two things - 1) although
> the Mightboard Rev E schematics labels the SD card section as "SD&MMC", the
> actual pinout used is the MicroSD pinout. (The fab drawing for the
> Mightboard shows a MicroSD slot) The LCD interface board, of course,
> shows the proper connector for a regular SD card. 2) I haven't opened the
> Eagle design, but given the placement of the microSD slot and the interface
> cable connector, there is almost certainly stubs from the ATMega to the
> unpopulated MicroSD card pads - that could cause the signal integrity
> issues that we are seeing.

Yes, there are actual traces and pads on the MightyBoard RevE for a microSD slot.
Those pads on the board are unused: no microSD holder was supplied. The
same AVR pins also have traces out to the ribbon connector for the SDSC
card slot.

Dan