Hologram.io Offers Developers Free Cell Data

If you’ve been thinking of adding cellular connectivity to a build, here’s a way to try out a new service for free. Hologram.io has just announced a Developer Plan that will give you 1 megabyte of cellular data per month. The company also offers hardware to use with the SIM, but they bill themselves as hardware agnostic. Hologram is about providing a SIM card and the API necessary to use it with the hardware of your choice: any 2G, 3G, 4G, or LTE devices will work with the service.

At 1 MB/month it’s obvious that this is aimed at the burgeoning ranks of Internet of Things developers. If you’re sipping data from a sensor and phoning it home, this will connect you in 200 countries over about 600 networks. We tried to nail them down on exactly which networks but they didn’t take the bait. Apparently any major network in the US should be available through the plan. And they’ve assured us that since this program is aimed at developers, they’re more than happy to field your questions as to which areas you will have service for your specific application.

The catch? The first taste is always free. For additional SIM cards, you’ll have to pay their normal rates. But it’s hard to argue with one free megabyte of cell data every month.

Hologram originally started with a successful Kickstarter campaign under the name Konekt Dash but has since been rebranded while sticking to their cellular-connectivity mission. We always like getting free stuff — like the developer program announced today — but it’s also interesting to see that Hologram is keeping up with the times and has LTE networks available in their service, for which you’ll need an LTE radio of course.

68 thoughts on “Hologram.io Offers Developers Free Cell Data

    1. A megabyte of data here costs 2 cents on prepay with 1 year validity and no data plan at all. So for that price tag I can get 375 MB… :)

      I know theirs is worldwide but this’ll work EU wide which will suit me.

      1. The EU has taken measures to abolish roaming fees for calls, sms and data. So you should pay whatever you pay at home in any other EU country. In other words, there is no extra charge for data roaming added to your usual bill.

  1. One whole megabyte! Guess this is aimed at the oldschool gen that write tight protocols with very little overhead, not the current shove-an-arduino-and-esp-into-a-jiffy-box-and-call-it-a-product gen

    …What’s the size of the average size of a HTTP request header nowadays, a few hundred bytes?

    1. This (NB: not very recent) paper: http://dev.chromium.org/spdy/spdy-whitepaper says “As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common”. That’s two requests per hour.

      Of course, “oldschool” (or as I like to call them, “sane”) people might, for starters, simply opt to use no (or very short) cookies, same for the UA. Then you have language preferences (who cares?) and accepted content types (just put */* only, which is probably already in there, somewhere towards the end). And it’s still very much standards compliant. So, does that already qualify as a “tight protocol” in your opinion?

      1. It’s not a “Tight Protocol” unless you’re encoding everything you need into a UDP header!

        If my counting is correct, that’s 24 bytes per update, allowing about one per minute for 1MB/month.

        ;)

    2. MQTT, much discussed on Hackaday, is a better protocol than HTTP for these types of applications. With MQTT, an entire connect/publish/disconnect with a substantial payload would only use a few hundred bytes. A node that reported on a suite of sensors every 15 minutes would fit within the 1 MB per month.

      Additional data is $0.60 per MB, billed by the KB.

        1. yes only 600x my standard data rate, many European providers have additional data priced at roughly a dollar pr GB.

          you do pay a monthly subscription for those plans though.

          1. Well, there’s good as in compared to other offerings. $0 monthly subscription is kind of hard to find these days.

            Then there is good compared to your cell phone. I suspect that if you had to pay the monthly base fee that you pay on your cellphone for each device you build you wouldn’t build very many devices.

            Finally there is good compared to what it costs the company to provide. Sure.. they have billions spent on their infrastructure but cell phone companies make billions pretty quickly. How much does the overhead paid by my local carrier change if I use 1MB vs 2MB vs 100GB?

            Yes, we are getting hosed. But, there are plenty of fun projects you can build that need only a small amount of data. Now there is a way to do so and that is something much better than nothing!

      1. Both are still TCP protocols, it looks like, so you have to consider the handshakes too. Also the frame length may be a kilobyte and a half. So I’m guessing something like 15KB per message if you count return data in the allowance. You’d never be sure it worked, but a one-way UDP datagram would use bandwidth much more efficiently for small messages like this.

    3. A typical http 1.1 web-browser to web-server header will be quite large these days. Large enough to not measure in bytes but in kilobytes just for the header and TCP+IP headers alone, assuming no data payload.

      An http 1.0 minimal header would be 9 bytes (“GET /” + crlf crlf) plus 16 bytes of TCP header and 20 bytes of IP header.
      That’s pretty large already and includes no data payload or GET URI path to include any information in.
      The URI part of the GET request can be up to 2048 bytes (not really, there are a couple other limits), but even assuming a 2k URI and no data payload, you’ll blow through that 1mb/mo quota just by making one request per day.

      You could go with pure UDP datagrams sent directly to an IP address (IE no DNS queries) with 4 bytes of data payload which is the minimum number above zero (It’s padded to 4 byte boundaries) which will total 52 bytes per packet (4 bytes data + 28 bytes udp header + 20 bytes ip header)

      But as you say, being part of that old school gen that loves tight protocols, I would look into how badly I could abuse the IP+ICMP packet headers to squeeze in as many bits as possible where routers along the way will still pass along the packet as valid.
      This will require some sort of raw packet capture setup on the server side as most IP stacks won’t pass that data up to userspace, but this will get your data packets down to 40 bytes (36 byte header + 4 bytes data)
      You could also squeeze in another 2-3 bytes in unused header fields, such as TTL, DSCP, the fragment fields if set to not fragment the packet, and likely a few bits in the ICMP header itself depending on your type/code values.

      Assuming a 31 day month, that will give you 35 4-bytes data packets per hour and still come in under quota.
      Of course ICMP packets are not guaranteed to be delivered nor necessarily provide failure responses if not delivered, but such is the price we pay for efficiency.

  2. >1 MB/month

    AHAHAHAHA, is this an US no competition MURICA freedamn capitalism! regulation is bad mmkay thing? because from EU point of view this thing is a total joke.
    I can get a prepair card with 1-10GB of data to be used in the next 365 days at a total one time cost of ~$3 from 3 different providers here.

    1. The point is that it is for product developers who can ship the product to all the 200countries without needing the user to BYO sim and phone plan. Like the Kindle has 3G everywhere. Not everything is about your personal use mate.

      1. I live in one of the more expensive countries in Europe, and I pay ~$3 per month for an extra SIM-card with 1 GB of data, LTE/4G service, and free roaming in Europe, U.S and most of Asia.
        And I have 300 GB of data per month on my mobile phone subscription, which my extra SIM-cards will start to use if they hit the 1 GB limit.

        So, $3 for a subscription in Europe with 1-10GB of data, without free roaming, does not seem farfetched….

      2. most european?

        standard data rates in europe are around a dollar pr gb on an existing subscription, us data prices always seemed insane from our POV, i get 100/100 mbit internet with noi data limits for around 40 usd a month.

  3. With just one megabyte of data a month, one wonders whether it would actually be more sensible to use a very low power radio and recieve it directly. The current world record for QRP is 1650 miles with one microwatt, which is less than the standby power of a cellphone.

    After all, you have all the time in the world. You only need to transmit about half a byte a second, which is slow even for morse code.

    1. It does seem a little too good to be true, doesn’t it…

      I suspect they’re betting on ‘lazy developer’ syndrome to push data usage up into the chargeable range.

      Something which at least some people on here have spotted judging by the HTTP header size and TCP vs MQTT ‘discussions’ going on above :)

  4. One megabyte? For development? They should be really kidding. One message per 30 minutes wouldn’t do even for crappy weather station. My old, factory-made, battery-powered weather station sends data like once per minute. Not once per 30 minutes, lol. I could get 5 GiB of data at around $10 from my carrier, and if I manage to exceed that, speed just would drop to 128 kbps, turning into “unlimited” (but slow) plan. So I could plug whole bunch of stuff to IoT using one SIM + hub if I need that. Am I missing something? It seems to only fit for some rather exotic use cases, nowhere close to how I’m seeing IoT, no? I’m not a big fan of stale data and you have to ping your sensors from time to time to detect if they are still operational, etc.

    1. I think an important distinction is our platform (device management, security, API/SDK, data routing, heartbeat, debugging, and carrier coverage redundancy). We do not compete with consumer cellular because our offering is so different. Most HaD readers can probably build MVP tooling on top of consumer cell but why would you when the Developer Plan is now here :).

  5. For low-rate low-frequency IoT over cellular, the problem is NOT the cost of the data. The problem is the forever recurring cost of keeping a SIM card registered with your local provider. These guys do NOTHING to solve that part of the problem – certainly in the case of the claimed hundreds of countries they claim to cover. Where I live in S.E. Asia, there’s NO way I’m going to get around the monthly recurring charges associated with an active SIM card. Period.

  6. Thats interesting.. and its nice to see a limit like this that pushes data bounds for efficiency. This reminds me of the times when people actually had to care about the resource usage of their web pages too. Not all applications need regular messages 24 hours a day, that alone can cut the data usage down to a fraction of its former size without even delving into the protocols.

  7. Most assumptions here so far seem to be for recurring interval connections such as with weather stations or constantly moving GPS data updates. There could be other use cases – sending data only beyond set thresholds, alerts, etc. Or if needing recurring interval data, perhaps packaging a day or week’s worth in a single message would reduce overhead with the headers as a percentage if near real time is not necessary.

  8. Does anyone know if this cellular data transfer is measured using compressed headers? (e.g. RFC1144 compresses a 40 byte TCP/IP header to 3 bytes nominally.) For an IOT device sending 4 bytes, there is a big difference. I presume data transfer is the sum of send+receive, so a 0 byte TCP ACK packet could also be 40 bytes, or 3 compressed. There are about 45K minutes/month, so the full TCP/IP exchange of 84 bytes each minute ends up as almost 4M, but with 10 byte compressed packets (3+4 and 3 ack) that’s .5M/mo.

Leave a Reply to oodainCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.