TCP Client and Serial Begin and DHT Library

Ok, seeing some weird behavior that I am hoping someone can explain? I am using the DHT Library that @mtnscott has provided as a library and the TCP Client to send data to a java socket. Here is the twist. If I leave the “serial.begin(9600)” with a few debug statements, my little sketch works great. The temperature sensor is being read and readings are being sent properly with the TCP Client. However, if I remove the Serial.begin statements, the problem does not work. Having not really worked with Serial connections, I am wondering if the Serial Connection is providing network connectivity to the spark core? I would have not thought so but thought I would inquire? I cannot think of any other explanation.

Serial is not required for network capabilities to work, but your Serial debug statements might have some positive timing impact.

Could you post your code or a gist of it?

One other thing, since you only mentioned taking out Serial.begin(9600); - you might try to take out all your other Serial statements too.


@scottdillon1 The Serial output does change the timing of your loop. I have found using the TCP sockets layer at full speed communications unreliable. Many have to use embedded delay statements to make it reliable. Can you outline what you are experiencing with and without the Serial statements? Posting the code would also be helpful. It’s quite possible as @ScruffR mentioned the Serial debugging statements could be introducing hardware delays that make the TCP sockets layer work.

@Mtnscott @ScruffR…well, I now how the code “working”. I have to say I am finding the use of the Networking API a little “sensitive”. I removed the serial statements and added a few random delay statements and voila, it started working. I have not done any real work with these device types before but is this type of situation typical? Is there anything else I can do to avoid this type of scenario? I noticed in the docs there are different startup modes…would it be more consistent if I changed it to Manual?

Thanks folks, this is a great learning experience.

As for your other question: This could only be answered properly if we saw your code, but in general: No.
Without the cloud connected, your latency even gets less and hence your problem might even get worse, since you are too fast already and once you are connected to the cloud, it depends where and how often you call Spark.process(), which is not that much different to scattering Serial.print or delay statements wherever needed.

But for the sensitiveness of things, compromises have to be found, when you connect things via “unpredictable” infrastructure.
Either the APIs apply delays or have to block to allow for even the slowest situation, or the APIs do their job as quick as possible and only slow things down as much is absolutely necessary and leave the rest to the programmer who would now in what context the APIs are used and should know of the needs of his intended use case.