Operating Temperature of IMP001

I have not gotten to the bottom of this issue yet but I am having some issues with keeping my IMP001 up and running in a sealed enclosure located outside. It is starting to get a little chilly, last night at around 10pm it was 4 deg C out side and my Imp disconnected. I can’t say for 100% sure that I did not loose power however I’ve had similar experiences in the past.

I guess my question is the IMP001 datasheet says -20 deg C operation, is this tested and what is the acceptance criteria for this test?

Also sometimes I notice that the UART on my board stops working, again I have not fully tracked down the root cause but I did notice that I can extend its operation by adding this code to my device:

function hb(){
hardware.uart57.configure(38400, 8, PARITY_NONE, 1, NO_CTSRTS, serialRx);
imp.wakeup(300, hb);
}

hb();

Again I’m not sure if it is temp related. The micro that I am communicating with is operating from a internal oscillator so it is very prone to drift. I do know that when I used a FTDI cable to my laptop instead of the IMP UART, I receive data more reliably.

You could log wakereason to see whether the imp disconnected due to a power interruption.

Can you try the UART with hardware flow control? There’s also a new CALLBACK_WITH_FLAGS option in release 30 to notify you of hardware errors.

http://electricimp.com/docs/api/hardware/uart/configure/

ok sorry for the long hiatus but I found the solution.

First, it is NOT related to temperature or hardware, sorry for the false accusation there!

What I found was that I found that there is not a 1:1 relationship between the number of times that the callback is called and the number of bytes entering the uart. Here is my original code:

// A function that is called everytime that the UART receives a byte
function serialRx() {
//Pull a byte from the UART FIFO
local c = hardware.uart57.read();
// Do byte processing here
}
function hb(){
hardware.uart57.configure(38400, 8, PARITY_NONE, 1, NO_CTSRTS, serialRx);
reconfigs++
server.log(“reconfigs=”+reconfigs)
imp.wakeup(300, hb);
}

// Setup hardware UART with serialRx event to receive bytes
hb();

I’m guessing that it is an issue with the queueing mechanism in the imp OS. This means that the UART FIFO was eventually over flowing. Hence why I would no longer get new UART callbacks and why re-configuring the UART fixed the issue (because it must flush the FIFO).

So anyway, I changed the code to the following and it has been running continuously for a week without issue :slight_smile: For reference, the old code crashed after 4 min.

// A function that is called every time that the UART receives data
function serialRx() {
local i = 0
local c = 0

//Pull all data from the UART FIFO
local uart_blob = hardware.uart57.readblob()

for (i=0;i<uart_blob.len();i++)
{
// Do byte processing here
}
}

// Setup hardware UART with serialRx event to receive bytes
hardware.uart57.configure(38400, 8, PARITY_NONE, 1, NO_CTSRTS, serialRx);

Ah, I see your problem. The callback is not called when there is just 1 byte in the buffer. The callback is called when there is one or more bytes in the buffer.

Your previous code did not appear to loop to empty the buffer before leaving the callback, hence if during the processing of a byte more data arrived, this would tend to “silt up” the buffer.

On temperature range individual devices are not tested but during approvals testing RF performance was indeed checked down to -20C. The MCU spec is down to -40C, but wifi frequency accuracy may suffer beyond -20C (likely to still work fine, though).

Exactly, so lets rephrase, it’s user error :slight_smile:

But for clarity, you might want to consider reviewing this document:
http://electricimp.com/docs/api/hardware/uart/configure/

Temperature performance has been good so far, I’ve taken it down to -6.8F which is -21C, works great. See attached plot.

Processing more than one byte in the callback should only ever be a performance benefit, not a correctness benefit. That is, if a fresh byte comes in during processing, the callback should immediately re-fire once it exits. (If it doesn’t, then that’s a bug, so apologies.) The FIFO should only “silt up” or overflow if your code can’t process the bytes fast enough.

Peter