Both serial and tcp works on Photon.
On Boron LTE the serial works, but the tcp doesn’t. It does send the first ~2.5Kb of the image, but then stops and refuses to proceed past Package 11 (once it got to Package 13) - see logs below.
I have seen several topics about Boron connectivity issues, but I thought those got fixed with the newer firmwares.
I am running the latest firmware, v1.4.2, being connected to the AT&T network in the US.
The problem is fully reproducible, it happens every single time and I have tried it over a dozen times at least.
It sounds like there might be some more unresolved Boron connectivity issues!?
Once I add a 400ms delay between the writing of each packet, then it works, it doesn’t stall after Package #11.
Interestingly if I try to send the second time without hard reset (eg reboot), the second time it goes a lot slower. I am not yet sure whether this is caused by the delay() function behaving differently the second time or something else.
The uCamIII library features a TCPClientX class that takes a flushDelay parameter that is defaults to 100 milliseconds whenever a potential buffer overflow is detected.
You could try setting that to a higher value and see if that helps.
This would only insert the delay when an overflow was detected and not between every write.
Thanks.
Unfortunately setting a higher flushDelay did not help.
Even after setting the flushDelay to 5000 (eg 5s), the sending stalls after Package 11.
Adding a 300-500ms delay after each packet sent works (when the network is busy, it needs a 500ms delay to complete and not to start stalling at some point).
Settings 5000ms directly in the write function:
size_t TCPClientX::write(const uint8_t *buffer, size_t size)
{
size_t pos;
for (pos = 0; pos < size;)
{
if (size - pos < chunkSize) chunkSize = size - pos;
int sent = TCPClient::write(&buffer[pos], chunkSize);
// 300ms delay added after writing each packet due to the issue explained at https://community.particle.io/t/maximising-cellular-data-streaming-rates-on-boron/46325/6
//delay(300);
if (sent == chunkSize)
pos += chunkSize;
else if (sent == -16)
for (uint32_t ms = millis(); millis() - ms < 5000; Particle.process());
}
return pos;
}
No problem, thanks.
At least it (mostly) works with the delay(500) after each packet.
The only issue is, that the required delay depends on how busy the network is and if I set it to too low then the sending and the whole device stalls, requiring a physical reset, which means bad enough network conditions can potentially stall the device with whatever delay I set requiring a physical visit to restart… not very good.
Hi @evk02! I’m currently working with another customer to resolve a TCP streaming issue. Sorry to place some investigative burden on you, but are you able to produce an application with which I can reproduce this issue? As small as possible, please! Feel free to DM me, or (better) to open a ticket here (so I can track it over time - I’ll keep this post up to date).
Tonight I can write a simplified example of his, so it would work without a uCamIII - as any large amount of data sent through TCP should trigger this issue, it doesn’t need to be an image from uCamIII.
The question whether can you run the NodeJS socket server or a Python one on a public server so the Boron can connect to it?
If not, I will setup a public TCP socket server for you to hit.
Let me know.