I’ve been testing the Dash Pro by uploading a 0 or 1 result from a digital IO pin every minute, using a project created in the Arduino IDE.
The data using is significantly higher than I expected at around 500kb in 12 hours. In the loop I am using SerialCloud.begin and SerialCloud.print to upload the data at set intervals. Is there a more lightweight method for doing this?
Thanks
Hello Michael,
Would you be able to share your code with us? Even an abstracted sample will help.
That being said, there is transport overhead. If you don’t need real-time updates, an interesting test would be to switch your reporting to once an hour. If you do need real-time updates, let’s see what we can do with your sample code.
Sure - test case is below. Somehow I need near real-time updates but without the overhead. I guess the other option is to write up and host a bunch of udp listeners and send data from the Dash that way, but I need help/pointers on how to give commands to the modem via the Arduino IDE.
int currState;
const long keepAliveInterval = 60000;
unsigned long keepAliveMillis = 0;
void setup() {
pinMode(D01, INPUT);
}
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - keepAliveMillis >= keepAliveInterval) {
keepAliveMillis = currentMillis;
currState = digitalRead(D01);
SerialCloud.begin(115200);
SerialCloud.println(currState);
}
}Sorry to dig up an old thread but does anyone have an answer to @michael’s question? I’ve used 0.5MB of data in the last day on a similar application, and 98% of that appears to be overhead. I’d love to know if there are any ways to reduce that even slightly.
Another ‘bump’ to this old thread. I’m seeing results similar to @James. I’m sending data every 2 minutes, and the reported payload size is 35 bytes, but I’ve used 1.8 mb in approximately 10 days.
If I do a character count (not necessarily bytes) on the message details from the hologram dashboard, I get 477, of that, 48 characters are my payload. If I assume 1 byte per character, the 477 bytes per messages seems to more closely align with the data usage I’m seeing.
Is there any way to reduce the overhead?
Thanks
I’ll chime in here too as I am interested in an answer. I’ve tested Particle Electrons too and confirmed their overhead with UDP is about 65 bytes (plus 61 bytes for an ACK, which can be disabled). Their doc: https://docs.particle.io/guide/getting-started/data/electron/ Dash apparently does not use UDP: How do you compare vs the Particle Electron? - #8 by benstr. I’m still looking for similar documentation for Dash. @ryanHologram? @benstr? Thx.
I’m also interested in an answer for this or at least hear about how it might improve in the near-future? As we’re very interested in moving some more “data-intensive” sensor probes onto Hologram.io, but as long as the larger data usage is a “hidden cost”, we can’t justify it just yet - hopefully a official answer could clear things up a bit.
Thanks!
Hey folks, wanted to chime in and offer my two cents (Hologram has not released any official documentation on this subject). From my preliminary research I’ve found TCP offers an overhead savings over UDP if you publish data in 50 minute or greater intervals. We’ve found it typical for cellular IoT solutions to broadcast less frequently.
If you need to report in intervals less than ~30 minutes then you are getting into territory where UDP would offer savings. But to that developer I would probably see if they could log data on the edge and transmit less frequently or move to a wifi solution as that might be a better fit.
I’m curious to hear what you think. If more people ask for UDP then we can add it to our roadmap.
I’ll chime in with my two cents as well.
Totally depends on your application - how often you send data back, how often you need to sleep the modem, how often you expect to lost connectivity, etc.
Major factors in overhead are that Particle’s protocol requires 6KB each time the modem connects to the cell network, as well as a 122 byte ping packet every 23min. This is not part of the UDP standard, but seems to be something custom that they’ve implemented on top of UDP to establish and maintain a session that guarantees delivery, reliability, and security (all of which UDP inherently lacks). Like @benstr mentioned above - if you plan on sending lots of tiny messages over short intervals, and don’t plan on losing your cellular connection very often, this is probably the solution for you.
Our own Hologrammer @ross wrote up a little article that touches on our TCP overhead here: Hologram.io Data Usage Breakdown. In the IoT space, every byte counts —… | by Ross Hettel | Hologram.io | Medium
Basically, you can expect around 500 bytes of TCP overhead per message, and that’s it, because the session is reestablished each time you send. This is optimal for applications that don’t send data back as often, or are unable to maintain a consistent cellular connection for whatever reason (need to sleep the modem, cell carrier connection resets, lose cellular service, etc.)
In regards to strategies for lessening the amount of data used - we basically have a lot of the same suggestions as in Particle’s documentation:
If none of these work for you, we happily offer our Ublox passthrough firmware so that you can mess around with AT commands on the Ublox yourself and develop your own optimized protocol. Ways to send AT commands to Ublox! - #7 by Reuben
We realize that raw AT commands are a bit of a burden to work with though, so within the next month or so, we will be open sourcing our Dash firmware so that people can more easily develop solutions for their more targeted use cases. Stay tuned!
I hope I was able to answer your questions - if not, feel free to reach out!
Thank you for the explanation! We’re expecting each probe to send approximately 300 bytes of data every 2-3 minutes depending on activity. WiFi is sadly not an option and Sigfox/LoRa is only capable of around 12-17 bytes of data every 10 minutes or so. I’ll try to do some testing when I get to it and see what is best for our application