What is typical delay time from say in a simple web switch application (turn a led on/off from web page), from activation in the web page (with value=0/1) to the led reacting. It seems to vary a lot for me, from couple of seconds to some times several seconds, making toggle switching un practical. I know it depends on the network connections etc, and in New Zealand, the broadband speed is not the greatest, just want to know what is the typical time experienced out there, or maybe it is my code.

I never experienced more than half a second of round-trip latency. For me it’s typically about 200 ms, and I’m in China. From within the USA it’s probably even less, since the servers are in California.

Actually one of my first programs for the imp was my so-called ‘remote feedback oscillator’, which measures round-trip latency by feeding an output port back to an input port (in the planner), and hooking up a LED for visualization. This is the code:
// remote-feedback-oscillator
// send inverted input back to output and pin9


local out = OutputPort(“out”)
local t = hardware.millis()

class In extends InputPort {
type = "bool"
name = “in”

function set(value) {
    local now = hardware.millis()
    out.set(1 - value)"f = %.1f Hz", 500.0/(now - t)))
    t = now


imp.configure(“remote-feedback-oscillator”, [In()], [out])


It’s consistently 100ms round trip to server from the East Coast USA.
Specifically 100-120ms 99% of the time.

I have exactly the same concerns, I’m from New Zealand too. A ping to Seattle is around 250mS. It only 50 to Sydney so a AWS imp cloud setup there would work well from this part of the world. Chatty systems need low latency to work well.

I’m very surprised that people in NZ are seeing such long latencies; in general it shouldn’t be a long way above a ping time to the US west coast. As we scale we will be seamlessly adding more servers in other areas, including Europe and Asia, which will reduce latencies for many users.

@kenkoknz you’re not using a 3G link at any point, are you? If those are idle for a small number of seconds then they drop back to a paging channel, and it takes a few seconds for data to start flowing over them again.

Hi Hugo,

  1. You are spot on, I am using 3G so i can use it on my yacht. Is there any way to fix this (now that I know that it is not a Imp issue)?

  2. Is there any future plans to include more that one wifi networks with just one flash? I have flash the Imp with the 3g network modem so I can use the imp anywhere. I never bother to use
    my home wired network as that would meant flashing the Imp every time i change network. So all this time I was thinking that few seconds latency was normal and putting up with it!

  1. The only way to “fix” this is to keep traffic going over the link. Usually a ping every 5 seconds will do. Obviously, this may cost on your data plan.

  2. There are plans, and you can do it programmatically in release23.

I recently also got some extremely long latencies (several seconds) from my location in Xiamen, China, so I decided to create a latency logger, using xively to publish latency statistics every minute. I will keep it running for as long as possible.

The public feed is here:

The code is here:

The code is based on my remote-feedback-oscillator which I published earlier in this thread.

Yours is simple. Mine is even more simpler. Let me know if you want the code.

It would be interesting to compare your latency measurements with mine, and with other users in other regions. Do you also publish on, or another public channel?

Hi Hugo,
can you suggest a low overhead code snippet to “ping” the modem? At the moment i just decrease the watchdog to 10s and works good, however it may not be the most efficient way to ping the modem & it is clogging the syslog.

My latency logger unexpectedly stopped working overnight. After initially reporting every minute to and to the server log for a couple of hours, as programmed to do, the server log and xively do not report any activity after 0:36, and then only at 10:22 (almost 10 hours later), the server log reports a online -> offline event. Very strange.
What’s more, I was not able to restart the imp using the Run button. Only the agent restarted (as shown in the log). I had to power cycle the imp to get it restarted as well.

It happened again today: my logger stopped working after about two hours of sending data to xively (I changed the interval from 1 minute to 10 seconds, just to see if it makes a difference).
Again, the agent could be restarted but not the imp. Had to power cycle the imp to get it up and running again. Serious reliability issue, if you ask me. I hope this will be resolved in the next release.

function fup(value){

local ms;
function fdn(value){
function myloop(){

@marcboon the agent bits are still in beta, so there will be interruptions and inconsistencies. The current imp release also has known reconnect issues which are addressed in the upcoming release.

I’ve been seeing identical behavior off & on for the last couple of months. My imp is programmed to log data to a server every 10 minutes. Not using agents. It has been randomly losing connection with rssi = -80 or better for the last few days. All will go well for perhaps a week or 2, then it starts the online–>offline thing intermittently. At times I will lose hours of data. This is the lifeblood of the imp’s functionality. I cannot begin to entertain the idea of demoing my system to a prospective customer at this point. Very frustrating. I don’t even want to think of its future if the problem is not fully resolved, and quickly. Especially with competition knocking real hard in a few months.

You only got it to work a week or 2 in a row consistently? Some popular brand Routers don’t last that long without a reboot. Come on. Hugo, any ideas why it would go offline after a week of running the same code?

@jpepe @sbright33 as I said, there are known wifi issues with the current driver, besides the known issues solved by putting a watchdog in your user code (which are related to the squirrel VM, not wifi).

We have imps that have been up for months (as they should be!) without issues on the new code. As for competition - it’s very hard to test their uptime when they’re not actually available yet :slight_smile:

I have the same problem, in 2 months of logging in an unmanned and remote location the imp has stopped logging to xively twice. The first time I was able to get a neighbour to power cycle and logging re-commenced. This time it will get a visit (4 hour ferry trip and 3 hours on motorway). My fix will be to put the imp on a time switch so that it power cycles once every 24 hours. Lets hope the reconnect is fixed soon.