Argon and loses of connection time to time

Hello I have an Argon that from time to time loses the connection with the network, then it recovers by itself, I have attached what results in the console. I can’t understand if this error comes from the wifi network or from Argon. I have a repeater in the room where I work so it shouldn’t be a problem with the wifi signal strength. I have a doubt that it could come from the bluetooth of the keyboard or mouse but …?Can anyone see the attached file determine the origin of the problem? Thanks Valentino

Msg from console

What does that mean exactly?

From the messages above it’s not easy to guess the cause.
But in combination with seeing your code it might be possible.

However, there might be other factors that don’t show easily - e.g. radio noise like other WiFi or Bluetooth devices, badly filtered appliances, quality of your power supply, external circuitry, …

1 Like

Thanks I proceed with eliminating any sources of disturbance, bluetooth (keyboard and mouse), power supply is of a professional type and therefore I would exclude it, I also grounded the shield of the cable to which the sensors are connected and then I would observe through the console.
Good day Valentino

1 Like

Hi @Tino52

I agree with this, it could be any of a number of things. You are correct in your assessment in that, given there are no external interferences, you should not be experiencing recurring WiFi disconnects being in such close proximity.

I recall a client that caused us extreme headaches as we simply could not find the problem why his iMac was constantly disconnecting for brief periods despite the fact that he had a CISCO access point couple of meters away from his computer. By chance, during a site visit, I noticed the disconnect coinciding with a “ping” sound. Walking into his PA’s office right next door, I noticed she placed a microwave oven right next to the AP :see_no_evil:

Problem solved :slight_smile:

Good luck!!


Thanks for your answer, in fact I have eliminated an old keyboard that worked wireless (radio or Bluetooth) and since yesterday afternoon there are no more interruptions.
Have a nice day Valentino


Yup, especially older BT devices (particularly “no-name” ones) tend to be noisy neighbors in a WiFi home.
Hence, when experiencing radio issues it’s good to know which technology and what radio bands you are using (consciously or not).

1 Like

Glad to hear you resolved the problem!!

Regards, Friedl.

I come back to the problem again on this post. After several hours of good operation, the problem returned. So I eliminated everything that was wireless on my table, turned off lights that could have affected the power supplies but the error remains. I started to check and clean the code, and I realized that everything happens when it fails to get a result from the DHT22 temperature reading, (I use the Adafruit library (0.004)) in the code I use the Particle.publish function. Eliminating the lines concerning the DHT22 sensor Argon no longer performs a restart. (// Particle.publish (“TempDHT”, String (t)); //Particle.publish(“UmiDHT”,String(h));
For the sake of scruple I also used the Pittech library with the example attached to the library and inserting the Particle.publish line and from time to time gives me a reading error.
At this point I don’t know what to do. Thanks for any suggestions.

Hi @Tino52 -

I am sorry to hear. May I ask, how often are you checking the DHT22 for a reading?

Regards, Friedl.

I was thinking you might try running the example sketch from the library (dht-test.ino) and use Serial.print() instead of Particle.publish() to see reading results. If that works, then, next, we can solve the Particle.publish() issues. If you could post your code that would help.

Also, you might try a short Particle.keepAlive() statement. Like this:

void setup() {
  Particle.keepAlive(5s);     // for 5 seconds.   

thanks, now I’m checking if I increase the time in my skecht as an attachment I can remedy the error, my reasoning is that by checking the validity of the data Argon ends up resetting itself therefore if I increase the time between one reading and another if Argon is able to receive valid data. I used the KeepAlive function with long and short times but without positive results. In the Serial.print I occasionally get a Failed to Read fron DHT sensor.
For friedl_1977 initial I put 2000 msec as in the library examples. I had also tried to put a delay in the data validity check but without positive results.

// Check if any reads failed and exit early (to try again).
	if (isnan(h) || isnan(t) || isnan(f)) {
	    Serial.println("Failed to read from DHT sensor!");
		//delay(5000); //non funziona!

Now I put a 5000 msec delay in the loop and it seems to work.
Regards Valentino

My code:

// This #include statement was automatically added by the Particle IDE.
#include <Adafruit_DHT.h>

// This #include statement was automatically added by the Particle IDE.
#define DHTPIN 6     // what pin we're connected to
#define DHTTYPE DHT22		// DHT 22 (AM2302)

//***Variabili misura temperatura
float sensorT=0.0;
float voltT=0.0;
double TempV=0.0;

//***Variabili misura Umidita
float sensorU=0.0;
float voltU=0.0;
double UmiGio=0.0;

//***Variabili temp e umi DHT22
double h = 0;
double t = 0;
double f = 0;

// Orario
String ora;

void setup()

void loop()
    ora=Time.format("%H:%M:%S %d.%m.%Y");
    int tnow =;
    int thour = Time.hour(tnow);
    delay(5000); //Default 2000 msec
    /* h = floor(100*dht.getHumidity())/100;
    t = floor(100*dht.getTempCelcius())/100;
    f = floor(100*dht.getTempFarenheit())/100;*/
    h = dht.getHumidity();
    t = dht.getTempCelcius();
    f = dht.getTempFarenheit();
// Check if any reads failed and exit early (to try again).
	if (isnan(h) || isnan(t) || isnan(f)) {
	    Serial.println("Failed to read from DHT sensor!");
		//delay(5000); //non funziona
//***Calcolo Dati Umidita
    sensorU = analogRead(A1);
    voltU = (3.3 * sensorU) / 4095.0;
    UmiGio=(100/0.016)*(voltU/160-0.005); // Impostazione origine 0.004
//***Calcolo Dati Temperatura PT100
    sensorT = analogRead(A2);
    voltT = (3.3 * sensorT) / 4095.0;
    TempV=-40 + (120/0.016)*(voltT/160 - 0.0042);// Impostazione origine 0.004
    //ISNAN significa IS NOT A NUMBER Check if any reads failed and exit early (to try again).
	if (isnan(UmiGio) || isnan(TempV)) {
		Serial.println("Failed to read from Sens Gio!");

    Serial.print("Data-Ora:");Serial.print(ora);Serial.println(" ");
    Serial.print("TempGio: ");Serial.print(TempV);Serial.print(" VoltGio: " );Serial.println(voltT);
    Serial.print("UmiGio: ");Serial.print(UmiGio);Serial.print("%");Serial.print(" VoltUmiGio: ");Serial.println(voltU);
    Serial.print("TempDHT: ");Serial.print(t);Serial.print(" ");Serial.print("Humid: ");Serial.print(h);Serial.println("%");
1 Like

Having a look at the datasheet (or other sources with background info) for the sensor you use does help :wink:


1 Like

Hello everyone and thanks for the answers, ScruffR thanks for the attachment read and I will reread to understand better.
Best regards Valentino


Hi @Tino52 -

Apologies for only reading this now, please next time use @ with my handle so I get the notification :slight_smile:

I am glad you managed to solve the problem!

I don’t like reading datasheets as they can be quite hefty documents, but as @ScruffR pointed out, it does help, hehe. When choosing sensors / IC’s, I try to google as many references with regards to the specific sensor / IC as I can, as it often covers all these matters and I don’t have to read that much :rofl: There are many guys out there doing benchmark tests and all sorts of thing.

Enjoy the rest of your day.
Regards, Friedl.

Hello @friedl_1977 thanks you and @ScruffR
I chose DHT sensors for their ease of use, ready-made libraries etc … Anyway thanks to all for the support, the site indicated by @ScruffR is very interesting.
Best Regards Valentino

1 Like

Hi @Tino52

don’t get me wrong, I use DHT often as you correctly stated, they are quite easy to use. But as you probably have noticed now, the lower cost sensors have some limitations :slight_smile: If your data is not mission critical in terms of nearly 100% accuracy or need readings more rapidly (in your case less than 5s) then DHT is just fine :nerd_face:

No point in paying 100’s of dollars for expensive sensors when not needed.


Correct I don’t have great demands on accuracy.
I also use Pt100 and NTC for other measurements.
Best Regards

1 Like