Hologram does not modify the data payload used by the device. We report full network activity from your device, which includes additional payload data such as TCP/IP headers. Furthermore, Hologram only has access to a device's metadata which is posted on your dashboard.

When the data being reported is unexpected, it is best to check your device logs. Device logs will provide more specific information about the data that was transmitted.

We have found a few common issues that can cause odd amounts of data:

Multiple data streams/sessions within a PDP context

Hologram reports usage based on the PDP context records. A PDP context is created whenever a modem registers and activates on our network, and it can hold multiple data streams until either:

1. The modem disconnects gracefully.
2. The connection times out (usually because of a power loss or device failure).

Given this scenario, debugging per "message" usage may not be accurately reported given that multiple messages could be sent per PDP context.

To debug this scenario:

1. Monitor usage logs on your server to measure the actual data transferred per session (and not per PDP context).
2. Create a test where you disconnect from the tower after each message to close the PDP session and record the log.
3. Use the device's "Inspect" tool to view the PDP context logs to identify usage patterns.

Missing IP traffic overhead in data calculation

Although your device send only a few Bytes of usable data, the overall payload being transferred on the network is larger because additional data is added to your message to route it correctly.

For example, you can read more about how our message system compares to HTTP here:
https://medium.com/hologram-io/hologram-io-data-usage-breakdown-3fc48f7a24c8

To debug this scenario:

1. Understand your overhead based on the communication protocol being implemented.
2. Explore lighter weight protocols such as MQTT to reduce additional overhead compared to HTTPS.

Background activity / chatty devices

It is not uncommon for devices to misuse their data communication. For example on embedded linux devices, background activity can consume extra bandwidth. For other devices, sometimes triggering can generate extra message events that consume bandwidth. We often observe that most data budgets are conservative and underestimate the actual data consumption when deployed.

To debug this scenario:

1. Try to isolate the conditions under which the usage occurs.
2. Check any device log activity to identify anomalous behavior (or perhaps this is regular behavior).
3. Use the PDP contexts to plot and correlate device activity with network activity to see if the behavior is consistent.