I have developed an application which needs to send about 10KB of data to a server (as a single file). On a Photon, and using an FTP server, it took about 7 seconds which is too long for me. On the Electron, it took “for ever” and was not feasible.
On advice of @Scruffr, I rewrote the application to use a TCP server instead. The results on the Photon were extremely significant ( < 200 ms) which is of course a major improvement over 7 seconds for the FTP server.
On the Electron, the same file took TWO MINUTES!
Am I doing something wrong or is the Electron designed to just send one value at a time?
I am sending chunks less than 100 bytes each time. (TCP)
When I was doing FTP, I was sending chunks of 512 bytes each time but the file never arrived even though I could see that the Electron hooked up to the FTP server.
Side note: I am not sure the Electron is reporting correct signal strength numbers because I know that cell service in my area is weak. My phone barely gets 1 bar so I am not putting too much faith in what the Electron is reporting …
You may be missing some important points between Photon and Electron.
Apart from the inherently slower and more “vulnerable” transport via cellular compared to WiFi, the communication between the STM32 and ublox cellular modem goes via relatively slow serial interface while on the Photon the communication goes via a considerably faster bus.
Also the Electron communicates with the cellular provider on a UDP based protocol while the Photon works natively on TCP.
Also the TX buffer of the Photon can send chunks of up to 1024 byte, the Electron only 512.
Consequently the max transfer rate on the Electron will undoubtedly be slower than on the Photon, but if the difference gets that severe you need to reduce as much of the impact caused by your own code as possible since you can’t do anything about the inherent differences.
In your code I also see some problematic portions
You may also have frequently read that we keep discouraging the use of String and rather suggest to use snprintf() to create formatted strings.
However, when you are sending your data to a self-written TCP server, why not just send the raw binary data and convert it on the receiving end?
That would cut down on transfer data and time tremendously.
For your specific string you’d do it this way (assuming all your variables are int
snprintf(msg, sizeof(msg), "%d,%d,%d\r\n", i, cloudP[j][i], cloudP[j][i]);
Lets suppose - since your code snippet does not reveal the actual info - you want to send your cloudP array which is a three dimentional array of uint16_t values not exceeding a total of 512 bytes, it would just be done this way
On the receiving end you need to fill the incoming data into a struct that allows you to retrieve the respective values correctly, but that’s a VB.Net question - it’s doable there to but I do prefer C#.
I am just wondering why would sending the raw array be faster since the byte conversion is done by the main processor before sending it to the modem (as you had explained earlier, sending to the blox modem is where the bottleneck is) …?
There is no conversion taking place at all - hence “raw”.
Based on the assumption (since you still haven’t reavealed the actual declaration of cloudP) that your array is an array of a numeric datatype and as such the byte count to transfer any arbitrary number in its binary form is statistically less than what the same number would take in its “printed” form (byte x = 123 takes one byte raw but 3+1 characters to print). You also won’t add any extra bytes by injecting text or separators.
And exctly that reduction of bytes to transfer would inevitable also reduce the time to do so.
With the declaration of your array above, the max index for your third dimension would be  since you declare it to only have 1 element.
You don’t declare the max index but the number of elements per dimension and the index always starts with 0.
When saving transfer “cost” what are your expected max values for each element in your field. unsigned long takes up 32 bit, so you can store values in the range of 0 .. 4294967296. If you don’t need that large numbers you may want to consider shorter datatypes (e.g. uint16_t max 65535) which again would reduce data consumption drastically.