The device we are building the electric imp into, for a commercial product, is comprised of plastic and metal pieces.
Does anyone have guidelines for best engineering practices for the placement of the wifi module to achieve reliable connection? Are there any big constraints that may inhibit the connection of the device when surrounded by metal and/or plastic enclosures?
As an electric imp commercial customer, I can say that we’ve been very pleased by the performance of the modules. Our devices are housed in compact plastic cases, which in turn are housed in larger plastic or metal enclosures. The metal enclosures definitely attenuate the signal, but not as much as we expected. We have only recently moved from the imp002 to the imp003 on our designs (following electric imp’s recommended PCB antenna design) and we are seeing even better range and connectivity. I can’t give you so much empirical data on that. It does highlight that it would be useful for electric imp to provide more diagnostics on connection performance above rssi values alone.
Generally, keep metal as far away from the antenna as possible. If you do have metal, ensure it is well grounded (low inductance ground). Floating metal is the worst. The higher the density of the material, the worse it is for antenna detuning.
However… there’s no substitute for testing. It’s very hard to predict how antennas behave, so just try things. If you need professional advice, we can provide some contacts of people who can help/do lab testing/etc.
@coverdriven We don’t actually get a lot more information than RSSI; the wifi chip itself deals with retransmits etc transparently. I’m not sure if retry counters are available in non-diagnostic versions of the wifi firmware but we could take a look.
@Hugo
Even retry count would be massively helpful. We have a few marginal sites at the moment, even though the rssi is quite reasonable (eg -74dB). If retry count is not available, an asynchronous callback for agent.send() would be great. Measuring the time between invoking it and the callback executing would be a good proxy for retries. WAIT_TIL_ACK is not feasible for a real time device with plenty to do.