arpit1ug:
I think I am printing integers not text. I am analog reading value from a sensor and storing it in a byte. and using client.print() function to print the byte
No, you are printing text.
analogRead() returns an int (32 bits, 4 bytes, where the 22 first bits are always 0). You could write these bytes directly, meaning that you take the exact 4 bytes of this value from memory, and send them over the TCP connection, for example:
int value = analogRead(A0);
client.write((uint8_t *) &value, sizeof(value));
If 'value' equals 1023 (or 0b1111111111 in binary), it will write out 0b0000 0000 0000 0000 0000 0011 1111 1111 over the TCP connection.
This is pretty inefficient, because you're sending all those leading zeros as well. If you want 10 bits of accuracy, it's better to use 16 bits instead of 32:
uint16_t value = analogRead(A0);
client.write((uint8_t *) &value, sizeof(value));
If 'value' equals 1023, this will write out 0b0000 0011 1111 1111.
Which is twice as fast, but you're still sending 6 useless zeros every time.
You could do some fancy tricks to package 10-bit numbers in 8-bit bytes, but the easiest way is to just lower the resolution to 8 bits:
uint8_t value = analogRead(A0)>>2;
client.write(value);
If the analog reading was 1023 like before, 'value' now equals 255 (0b1111 1111 in binary).
It's only one byte long, so it will write out 0b1111 1111 over the TCP connection.
However, if you use client.print:
int value = analogRead(A0);
client.print(value);
It will convert the number to ASCII characters before writing it out:
1023 → "1023" → 0x31 0x30 0x32 0x33 (ASCII), so it will write out 0b0011 0001 0011 0000 0011 0010 0011 0011. By converting to text, you add a lot of overhead, because you're only using 10 (digits 0-9) of the 256 possible characters per byte, so you need more bytes to represent the same number.
If you use client.println, it gets even worse:
int value = analogRead(A0);
client.println(value);
println adds a carriage return ('\r' = 0x0D) and a line feed ('\n' = 0x0A) at the end of the text:
1023 → "1023\r\n" → 0x31 0x30 0x32 0x33 0x0D 0x0A, so it writes out 6 bytes, while you could represent the same number in only 2 bytes if you use the binary method.
arpit1ug:
STUFF You will want to know:
Collecting voltage reading( which is generally from 1-256 ADC reading) from a methane Gas sensor for 15 minutes @1 kHz. Then I would like to send the data to a computer by any possible means in any possible format
Does it have to be real-time? Or could you save it to a file, and then send the file to the computer after 15 minutes of measurements?
If you have at least 900,000 bytes of flash available, you can just save everything to a .hex file in the SPIFFS (using file.write(), not print()), and just use a web server to download the .hex file to the computer.
Then you can use a simple python script to convert it from a binary file to a CSV, or whatever format you want for processing.
If you need it real-time, you could try WebSockets (it supports binary data), but you won't be able to reach 1kHz, I'm afraid ... Or you could use a direct TCP connection, like you are doing now, but with or without HTTP on top of it, just a binary stream of data, if you change the Content-Type to some binary format, or an octet stream, that should work. Then just use client.write(value) as explained above.
If that's still not fast enough, you could try UDP. If you don't mind some dropped packets or some packets arriving out of order. You might want to use some kind of buffer to minimize overhead.
Pieter
Edit:
(which gives a ouptput(0-256), since my voltage is low enough )
If you are sure that you're never going to get a reading higher than 255, you can use:
uint8_t value = min(analogRead(A0), 255);
instead of:
uint8_t value = analogRead(A0)>>2;