There are 3 uarts on imp005, and each has a different clocking setup (it’s… an interesting chip!).
uart.configure() returns the actual baudrate set (vs the requested one). Generally on a UART, up to ~5% baudrate error is just fine, because the drift only happens within a single byte - everything resyncs on the next start bit.
(the reason 5% is fine is because sampling is in the middle of each bit, and there are ~10 bits, so if you’re 5% high or low, the sampling point will have moved to + or - 50% of a bit time by the time the stop bit arrives).
eg, when you request 921,600bps on an imp005:
on uart0 you get 924,855bps (+0.35%). This will work fine.
on uart1 you get 779,166bps (-15.5%). This will NOT work.
on uart2 you get 935,000bps (+1.5%). This will work fine.
All data goes via the imp cloud, but there’s no limit aside from memory for sending to the cloud; generally you’ll want to send messages less than the TCP buffer size (as larger than that will block whilst the system waits for the server to ACK packets), but the TCP buffer size can go to 64kB.
You can easily sustain hundreds of kB/second upstream on an imp005. I just ran this example:
TRANSFER_SIZE <- (1024*1024)
BLOCK_SIZE <- (16*1024)
NOOF_BLOCKS <- (TRANSFER_SIZE / BLOCK_SIZE)
// Set max TCP transmit buffer size
imp.setsendbuffersize(65536);
blocks <- 0;
buffer <- blob(BLOCK_SIZE);
function loop() {
if (blocks < NOOF_BLOCKS) {
agent.send("data", buffer);
blocks++;
imp.wakeup(0, loop);
} else {
local end = hardware.millis();
local duration = (end-start);
local rate = (TRANSFER_SIZE/1024) / ((end-start)/1000.0);
server.log(format("Transfer rate %.2fkB/s", rate));
server.log(format("Duration %dms", duration));
}
}
start <- hardware.millis();
loop();
…and I saw this (on a good internet connection obviously):
|2020-10-27T09:12:13.662 -07:00 |[Device] |Transfer rate 499.76kB/s
|2020-10-27T09:12:13.662 -07:00 |[Device] |Duration 2049ms