A few days ago I was demonstrating an imp based project using my iPhone as a hotspot. I had horrendous cellular coverage and the imp teetered between connected/disconnected from the server.
The goal is for the device to continue to operate when offline fairly seamlessly. I am using the Connection Management Class off Github with a server.setsendtimeoutpolicy(RETURN_ON_ERROR, WAIT_TIL_SENT, CONNECTION_TIMEOUT). I thought all of the server reconnection behavior was fully asynchronous, however, during this demo I discovered some unexpected behavior… For example, I have a buzzer set to beep at 1 Hz using imp.wakeup. The beeping rate would vary as the imp attempted to reconnect, leading me to believe I either have some blocking reconnection code or the Squirrel VM gets temporarily suspended during the reconnection process.
Does anyone have any good ways to simulate a “poor quality” internet connection (varying levels of dropped packets, slow bandwidths, etc.), intermittent WiFi connection, etc. to try to reproduce this behavior? This stack overflow article has some strategies I am likely to try, but I thought I’d turn to the experts to see if anyone has done something similar…
I am interested in that as well. For our battery powered device that is sleeping for 4 hrs and awake for a couple of seconds connecting takes a large part (>50%) of the battery capacity. I would like to learn the effects of low bandwidth, low latency, and lossy network connections on connect time and improve the battery lifetime. Maybe this leads to selecting different network equipment.
If you want your 1Hz buzzer to be more reliable, have you considered using the PWM output on the imp? It should not be held up by a busy processor when connecting/reconnecting.
All of our test devices report back rssi to the agent, every 5 minutes. We can usually see deterioration in rssi before we lose a unit completely due to loss of line-of-sight and other issues. In my house I have an imp 3 rooms away from the router. When all 3 adjoining doors are open I get reliable connections. The connection is less reliable when 1 or 2 doors are closed. When 3 doors are closed, no connection. Getting lots of diagnostic info out of your imp saves you time in the long run.
As the stackoverflow answers indicate, there are tools for macos (and linux) which allow you to simulate all sorts of nastiness - packet loss, increased latency, etc. That’s definitely the most controlled method.
@coverdriven the buzzer has to be driven with a PWM signal (in this case I’m using 4096Hz) for it to buzz at all. Unfortunately, this means I can’t use a 1 Hz PWM to do the work for me…
@Hugo - doing a little more research that was the conclusion I reached. Time to get my hands dirty…