Am 18.01.2017 um 10:10 schrieb Tom Parker:
AT+CIPSEND=?
...which will normally be around 1460. You need to add base64 encoding and line termination overhead, but that still allows for multiple data rows to be added to one send.
I'm not checking the size, can it ever be very low?
Not sure about that, haven't found any clear info on this. Technically it may get low, but I don't think that really happens on current networks anywhere. I've seen no problems with my largest packet, which is around 1100 bytes (encoded).
By sending all the messages in one packet I'm now reliably sending 5 reasonably short messages.
That looks very good now, no more garbage chars and "unable to decode" errors in the log. Also no broken pipes.
I did uncover a bug in the server, I'm sending 4 NL-COM-CAN messages and a NL-COM-HIS message in one packet, I can see all of them arrive in the server logs:
2017-01-13 02:35:09,28654,'#22 C rx msg H NL-COM-CAN,3,86400,054A120070072600003F' 2017-01-13 02:35:09,28655,'#22 C rx msg H NL-COM-CAN,3,86400,054B0078880924000001' 2017-01-13 02:35:09,28656,'#22 C rx msg H NL-COM-CAN,3,86400,054C6566C00000807E00' 2017-01-13 02:35:09,28657,'#22 C rx msg H NL-COM-CAN,3,86400,054F4801090007808836' 2017-01-13 02:35:09,28658,'#22 C rx msg H NL-COM-HIS,0,86400,003F0305001F00B000E000D9'
But only the first NL-COM-CAN and the NL-COM-HIS show up in the separate .csv files for the message types. It looks like it's only taking the first message per packet or per second and recording that?
Works as designed ;) -- a history entry needs to be unique for ( type, number, timestamp ). Maybe you can just use the loop index as the record number? Regards Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26