Problem with size of WEB PAGE from SD

Hello, I need help with the following.

I'm programming a Mega + Ethernet shield with SD card + 3 x LM35 + DS3231 + 3 x HC-SR04 + triacs card for 12 outputs (home made) . It is working using AJAX communication with a Web Page mounted SD and with a simple interface. All was working fine.

The problems (that must be the same cause):

  1. To give a best view of the Web, I added 12 x 3D buttons and LEDs of different colors, using the checkbox mode. All was working fine.

Then I programmed a pair of circular gauges in the index.htm and worked, but adding 5 of them to show more analog measurements, something happen and the gauges dont work. Or the page loads without any parts. The web page Works fine offline.

  1. Eliminating the gauges, I started working to stabilize the LM35 measurements because they move a lot. I try to fix it with a a dead band and including an average of 25 readings por each of the 3 LM35. In the begining everything worked OK. The system was continuous connected overnight.

But the next day the page began to have trouble loading and sometimes when it cannot load. When the page load ok, sometimes (near 50% of the times) the checkboxes send the signal to the Arduino but it dont respond. It is the same program that worked before without touching anything.

Apparently there are some limitation on the weight of the web page or the runtime of the sketch. I have the Buffer 120 in the simple version. 150 does not fixed the problem.

The sketch is less 13% of memory and the website less than 20Kb in all cases. The 5 gauges add 53Kb.

Someone has an idea that might be happening?


I have a buffer of 256 bytes and read the file and write it to the ethernet.
The page size does not matter.
My Ethernet Shield still has the W5100 chip.

If you read a single byte, and write that single byte to the ethernet, then every single byte will become a packet over the Ethernet. I suppose you don’t do that, and the buffer you are talking about it for reading the file and writing to the ethernet ?

If you need gauges, HTML5 can make them.

I have also added the test for open and no longer used sockets :

The LM35 is always inaccurate. The DS18B20 is a digital temperature sensor, but it uses specific timing which require that interrupts are turned off, and that might slow down the web interface a little.

Thanks Koepel for your replay. I have W5100 too. The sketch is a adaptation of eth_websrv_SD_Ajax_in_out, and the a XML file is light. The gauges are HTML5 too.

Now, knowing that the size of the web page is not the problem, I will review my project in search of the cause of the problem. Thank you

If you haven't changed this, here is your problem. This is really slow.

while(webFile.available()) {
  client.write(; // send web page to client

This will increase your download speed by about 4 times.

char tBuf[64];
byte clientCount;

while(webFile.available()) {
  clientCount =,64);

I will try your sketch when return home.

Thanks for your help.

SurferTim your code work very fine!! Thanks. I continue with my fight with the gauges. They are winning, for now

I was doing some tests to see in reality what happened.
I adapted a sketch and its HTM code for two gauges with built-in script. Screenshots 1 and 2 show the debug of Chrone where you can see the page showing temperatures of 2 LM35.
There are 2 initial loading errors, one is a font (included in the script gauge) and other the favicon.ico. For now is not a problem because everything works fine.
Then I add a third reading of another LM35 and the system continue working, screenshot 3.
Again I added a fourth reading from a difference of two previous reading. With this the system failed to display the values in the 4 gauges. screenshot 5.
Then I modified in the sketch

// size of buffer used to capture HTTP requests
#define REQ_BUF_SZ 50

As follow

// size of buffer used to capture HTTP requests
#define REQ_BUF_SZ 120

The system began to read. screenshot 6.

I hit below the sketch of the latest version and the webpage.

I will add all this to my original sketch, where I have more scripts for digital inputs and outputs.

You should also must write a clean the HTM code removing the scripts of the gauges out. My first attempt did not work and I attributed it to an external file within the script. I will try again.
It would also be logical to solve the font issue and the favicon.ico for a nice proyect.

I have server code that serves ico, css and js files, along with several other file types. I don't have it set to serve font files, but it can be adapted to serve those also.

edit: Is the font file a ttf file?

Here is the Sketch

_4Temp.ino.ino (8.17 KB)

SurferTim: I have server code that serves ico, css and js files, along with several other file types. I don't have it set to serve font files, but it can be adapted to serve those also.

edit: Is the font file a ttf file?

I take a look at your code. The script font is ttf. I need include XML for AJAX commands y the correct secuency. And rebuild the sketch, but everything is for learning.

Ok. The turf file is no problem with my code. Minor mod. I'll take a look at your code in a few hours.

I took a look at your website:

  • The RX and TX are idle high. If you need to keep RX inactive, you need a pullup resistor, not a pulldown resistor.
  • The Wire.requestFrom should not be preceded by Wire.beginTransmission and not be followed by Wire.endTransmission.
  • I read somewhere that we all are connecting the contrast potentiometer of a LCD wrong. Only a potentiometer to ground is needed.

Your code won't handle js, css, ttf or ico files. It will respond with the contents of the index.htm file unless the request has ajax_inputs in it.

Ok, so I just need the proper way to load such files. Your code is too complex to try to copy something from it. I know that there aren´t issues with the size of the webage code. Thank you very much for your help.

SurferTim: clientCount =,64); client.write((byte*)tBuf,clientCount);

So from the above statement,, len) returns the length of characters returned from the buffer. I think this should be mentioned on, as it is really useful info. Currently, it only states

Returns: The next byte (or character), or -1 if none is available.