SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By jlang
#176836
I am designing a car counter. I am using an Arduino Uno and a Wifly shield that I purchased about 4 years ago. A set of long distance photoeyes is wired to the Arduino to detect when a car passes then sends the speed and direction to my webserver (WCF Service running on IIS). It's a simple project but I cannot get the Wifly to maintain a connection with the webserver for more than a couple of hours. It works perfect during those few hours where as soon as a car passes, it sends the URI to the webserver and the webserver stores that information in a sql database. When it's working fine, the status light on the Wifly is solid green but starts to slowly blink (like it's connected to an AP) when it stops working. I don't really care if the server responds so I didn't clutter my code with response retrieval. I just want to send the /GET.

1. Does anybody have any ideas why it's disconnecting?
2. How long can I, under normal conditions, keep an active connection alive (i.e. is my approach even doable)?

Below is the Arduino Code (like I said, very simple). Any ideas would be much appreciated.

BTW...the IIS log file indicates that the GET requests stop arriving at the same time the solid green light switches to a slow blink.
Code: Select all
// (Based on Ethernet's WebClient Example)

#include "SPI.h"
#include "WiFly.h"

#include "Credentials.h"


byte server[] = { 192, 168, 1, 100 }; 
// this constant won't change:
const int  buttonPin = 2;    // the pin that the pushbutton is attached to

// Variables will change:
int buttonPushCounter = 0;   // counter for the number of button presses
int buttonState = 0;         // current state of the button
int lastButtonState = 0;     // previous state of the button

//WiFlyClient client("google.com", 80);
WiFlyClient client(server, 8083);

void setup() {
  
  Serial.begin(115200);
  Serial.println("In Setup Mode");
  //WiFly.configure(WIFLY_BAUD, 9600);
  WiFly.begin();
  Serial.println("Wifly begin");
  

  //WiFly.configure(WIFLY_BAUD, 38400);
  pinMode(13, OUTPUT);
  pinMode(buttonPin, INPUT);
  
  Serial.println("connecting...");


    if (client.connect())
    {
      Serial.println("connected");
      client.println("GET /Arduino/CarCount.svc/RoadInfo?dir=start&spd=0 HTTP/1.1");
      client.println("Host: 192.168.1.100:8083");
      client.println("Connection: keep-alive");
      client.println("Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8");
      client.println("User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36");
      client.println("Accept-Encoding: gzip,deflate,sdch");
      client.println("Accept-Language: en-US,en;q=0.8");
      client.println();
      //client.stop();
      } else {
      Serial.println("connection failed");
      Serial.println(client.connect());
      client.connect();
    } 
}


void loop() {

    // read the pushbutton input pin:
    buttonState = digitalRead(buttonPin);
    
    while (client.connected())
    {
        htmlReq();
        Serial.println("connected");
        delay(10000);
    
    }
    client.stop();
    delay(10000);
    client.connect();
    
    }

void htmlReq()
{
  client.println("GET /Arduino/CarCount.svc/RoadInfo?dir=ard1&spd=0 HTTP/1.1");
  client.println("Host: 192.168.1.100:8083");
  client.println("Connection: keep-alive");
  client.println("Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8");
  client.println("User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36");
  client.println("Accept-Encoding: gzip,deflate,sdch");
  client.println("Accept-Language: en-US,en;q=0.8");
  client.println();
}
    
    
By uChip
#176881
This is a common behavior with Wi-Fi devices. They periodically fall off the network and have to rejoin. There is actually a parameter in the WiFly setup that causes the WiFly to check the connection periodically and rejoin if necessary. I don't recall the parameter(s) off the top of my head but if you check the manual it's in there. I had this problem with my WiFly based weather station but once I set up the right parameters mine went from run a couple hours and die to completely stable indefinitely.

Good luck,
- Chip
By jlang
#176892
Thanks uChip. I flashed the firmware of the Wifly last night from 2.1 to 4.1 which appeared to provide a few more adjustable parameters. In addition, I switched it to link to my other router since it kept reconnecting whenever "set wlan linkmon" was set to anything greater than 0. Perhaps this is what you are referring to. With the other router and "set wlan linkmon" set to 30 I was able to get a few more hours out of it (about 4 hours). I will look further into your suggestion and post any results.
By daveca
#177618
The most important factor has been left out- the microwave path from the counter to whatever is receiving it,wherever it is. (two way path, of course)

Where are the Wi Fi nodes? The transmission path may be not be reliable. It makes little difference how strong the signals appear to be if theres interference.

Device/system settings mean nothing if theres another Wi Fi node colliding (interfering) or there are changes in humidity.

Wi Fi signals are 2.45 GHz ( I assume your system is 2.45 and not 5 GHz) and extremely sensitive to moisture in the air - 2.45GHz is the resonant frequency of water molecules, and water molecules absorb Wi Fi energy - thats how microwave ovens work.

The application is counting cars that drive by and spew massive quantities of water vapor into the air from the exhaust. There may be some vehicle traffic generating water vapor clouds that drift across your Wi Fi path and mess things up.

For fun, try a humidity sensor in or near the path, see if the crashes coincide with changes in RH. Ive seen a consistent pattern, especially on weak wi Fi signals, near dark when moisture settles, watching signal levels with a wardriving program. Get a war-driving program and monitor signal strengths. And realize even a relatively strong signal is meaningless if there are reflections (multi path) or other signals interfering. An otherwise perfectly good -30dB signal might be corrupted by a couple -70dB signals interfering- not just from signal strength but from timing.

There could be a metal object reflecting stray Wi Fi signals (or your own signal) and causing interference.

For any serious project using Wi Fi link, a directional antenna is a must.
By jlang
#178158
I apologize for not responding sooner. I appreciate the detailed response to a potential issue I never considered with WIFI signals.
For a status update, the most I was able to keep the Rover connected was about 12 hours, and that was indoors about 70 feet away from the router. The issue may be router related since I had far greater success on my main router than I did with my backup router. Regardless, I decided to look for a different WIFI chip and I came across the ESP8266. This small and inexpensive device had similar issues with staying connected for long duration's but its connect time was far less than the RN131 (about 1.1 seconds vs 30 seconds). This was acceptable since cars were not following too close. I deployed the project and was able to start collecting data successfully. If anybody is interested in the effort required to make this work, please let me know.
By stevech
#178174
Humidity won't significantly affect path loss for 2.4GHz WiFi.
Nor Rain, unless water gets inside the antenna.
"Dirty" ice accumulation on such antennas sometimes has an effect.

I suspect your issues with these cheap WiFi radios is that they're poorly designed to recover from intermittent path-blockages due to moving objects. Or they're deployed with too little fade margin; should be at least 20 dB.

The best way to get low volume data passed is to force the radio to use a low modulation rate, e.g., 802.11b mode, or the lowest speeds in 802.11g/n.

Lower speeds means less signal-to-noise is required and that translates to fade margin.
By Rowland49
#179166
My problem occurred while using WPA2-PSK (TKIP) encryption.

I was having the same problem of losing my connection at random time intervals with an RN-171, WiFly module, used to control a relay board. I had the security settings on my desktop's wireless router setup for WPA2-PSK (TKIP) to accommodate a few pieces of older equipment that did not have AES encryption. All my other wireless devices were working fine so I never thought to change the router and the other devices to AES, rather, I set up the RN-171 for WPA2-PSK (TKIP).

The module connected with no issues and I was able to access the command mode and the data mode so I started to work on the hookup of the relay board when I noticed it would lose the connection. As usual, the vendor helped with one email and then crickets. I was on my own.

Several days later and a helpful article on encryption, it looked as though this board may be flakey when trying to maintain a connection using TKIP. I re-configured the wireless router to WPA2-PSK (AES) and the WiFly with the following settings:

set wlan join 1
set wlan auth 4
set wlan phrase <to whatever your password is>
save
reboot

The WiFly has been online now for about 40 hours and has, as yet, not lost a connection with my wireless router located about 70 feet away in the house.