Thanks @bko, some more things to try. I’m not spiking the ball on the WiFi ‘solution’ I sort of need WiFi, hence buying the Spark Cores!
I have tried most of what you suggested, including:
Caps on Power Supply
Other power supplies
Moving display around… though I kind of need to fit this all into a box eventually!
with and without the DHT sensor
I am still going at the rest of the recommendations from the forum tonight.
@BulldogLowell, this issue is chewing at me! I believe I have a 16x2 display with the same backpack so I will be doing some tests. @bko’s recommendations are spot on. I also want to look at the I2C code for any interrupt issues. So many folks have used I2C without problems, it makes finding the issue that much more difficult. Stay tuned. 
not to make you feel worse, but I own three Spark Cores and can get none of them to consistently update either I2C display without eventual errors.
one is early, with a round (really groovy) shaped RGB led. Two are newer and each sporting a square led.
'square'... get it?
Please keep in mind: I2C is primarily an Chip to Chip interface. It was not defined to “put it on the wire”. (No checksums, no retry).
If you want components connected by wires, I2C is not the correct Protocoll.
Not simply to contradict you, but the tens (perhaps hundreds) of thousands of Arduino (et al) implementations of I2C displays tends to a "preponderance of the evidence to the contrary"
at the end of the day, if it doesn't work on a Spark, well it just doesn't work on a Spark and that won't make me 
I'm just curious to find out why. Maybe its a simple thing to fix and it opens up a universe of low-cost displays being used by hackers everywhere.
Yes. I'm sure, that's a small problem within the wiring or power (High Level/ LowLevel / Noise Ratio).
The Noise from the wireless modul is definitely a source for problems which simply doesn't exist on the Arduino ( spark and arduino are not comparable from my point of view!)
In our own project we have used AnalogInput form the spark and the signal is (during wifi und especially during login) unusable.
So we decided to switch off wifi during this operations (signal frequency detection). But this is much more problematic to noise compared to I2C.
I fly multirotors and some controllers use i2c for compass/gps (for example http://copter.ardupilot.com/wiki/common-installing-3dr-ublox-gps-compass-module/ ) . 15cm wires, noise from motors/ESC’s, 2,4Ghz transmitter noise + 5,8Ghz (or some other freq) FPV signal from 600mW transmitter and it works like a charm.
Folks, the argument on the merits of I2C are somewhat moot as the OP is looking for help with his display corruption. As such, it would seem more constructive to analyze what is known to try and identify where the problem originates. I am Looking at the odd pulse on the data and its proximity to the START pulse. It is too short to be properly clocked as data but is aligned to the last clock pulse prior to the START. So is it a product of a STOP or data that was cut-off somehow? One odd thing in the first traces shown (Spark vs Arduino) is the frequency reading of the scope. For the Arduino, it shows 555.772HZ but on the Core, it shows 17.7358KHz!
Just an update, turning off the WiFi radio, same old problem.
I am sure that is just a result of the wave sampling at the moment, I was not measuring that. I'll try to get more/better numbers tonight.
@BulldogLowell, I’ll try and get my 16x2 display going using some elements of your code to exercise it to see if it fails as well. Can you please measure the clock speed of the Arduino (full cycle) just to be sure it is as expected.
Spark Core:
Have we figured out why the data line on channel 1 in yellow has one tenth the amplitude it should have? If it is really 568mV peak-to-peak that is not going to work!
Well, that's cuz I'm a big dummy... probe was set to 10X... scope was set to 1X
The Real Spark...
and the Arduino Uno:
(the timing is different so I had to sample over a different period to get the right frequency)
So, you can now see the correct frequency and voltages. I am testing with this simple program on a 16X2 display:
#include "application.h"
#include "LiquidCrystal_I2C.h"
unsigned long updateInterval;
byte state = 0;
LiquidCrystal_I2C *lcd;
void setup()
{
lcd = new LiquidCrystal_I2C(0x27, 20, 4); // set the LCD address to 0x20 for a 16x2 //SparkCore bug, address is actually 27 but shifted (0x27*2)
lcd->init(); // initialize the lcd
lcd->backlight();
lcd->clear();
lcd->setCursor(0,0);
lcd->print("---Spark*Core---");
lcd->setCursor(0,1);
}
void loop()
{
if (millis() - updateInterval >= 4000UL)
{
lcd->print(state == 0? "ABCDEFGHIJKLMNOP" : "1234567890123456");
state = !state;
updateInterval = millis();
lcd->setCursor(0,1);
delay(2000);
}
}
Just in case you want to use the same to test...
Again, I appreciate your help investigating this.
@harrisonhjones (or anyone from Spark) is Two Wire communication handled by a TWI module (hardware) or is the I2C code in the firmware?
I'm also trying adding this to the library and running my original code on a 4X20 display:
Wire.setSpeed(CLOCK_SPEED_100KHZ); // yeah, I know that's the default
Wire.stretchClock(true); // << this is the bit I want to try
Wire.begin();
Spark has hardware i2c built-in to the STMicro ARM chip. I have used it with a few LED modules that use the MAXIM chips and it works fine with them. Lots of other folks have used lots of other modules successfully too. There have been a few problems, mostly with i2c devices that themselves use "soft" i2c like a PIC micro or similar. At least one person reported success using the series resistors I mentioned above.
I still think you have an electrical problem and I would work to rule that out.
I'm past the point where I think it is electrical.
I have a 1200mA power supply
I am only connecting displays
wires are very short
my complete electronic summary: 2 resistors and four wires.
bear in mind... I find it difficult for this to not work on other MCU's!
this didn't help (as I was typing)
Wire.stretchClock(true);
@BulldogLowell, as Murphy’s law would have it, I could not get my LCD to work last night, as in work at all! I’ll be trying again tonight with your library and app.
Very wild guess here = on photos, corruptions happen around time values. Which are generated using similar code:
lcd->print(Time.day() < 10 ? "/0" : "/");
Which calls Time.XXX and immediatelly lcd->print(). What does Time library do on low level? Can’t it corrupt signals on i2c somehow? It matches theory the problem is not electrical level.
I would try to compose whole display message into a string, then send it to the display. Maybe with a tiny delay before lcd commands. Careful with buffer reallocating though.
yeah, I'm testing that, if you look up the code a few posts above, which is just printing string constants. Yeah, I still get corrupted displays.
The classic HelloWorld example causes corruption. I need to try another type of I2C device and see what happens. The several displays I tried all didn't work on any of my three Spark Cores.
I haven't ruled out the Northern Lights or Solar Activity, but pretty much everything else electronic at this point. I recently had the basement checked for Radon, so I'm OK there too.
I'm going to hire a medium... Albert Einstein used to live close to where I live, maybe his ghost is radiating onto my Spark Core. But that wouldn't explain why other folks have a problem (unless the departed is particularly well travelled) so I'll strike the seance.