I'm just in the middle of launching an LTE-M based device that contains a primary power source (a 12v vehicle battery) with a supercap for backup power when the battery dies.
Average power at the moment is around ~3mA to keep an LTE-M module (using a QCOM chipset) connected to the network in DRX mode. Bandwidth wise, LTE-M gives us between 500bytes and 3.5KBs per second on the AT&T network - its not terrible and the byte cost is also "low" from AT&T.
LTE-M network coverage is good - same as AT&T LTE as far as we can tell (as LTE-M is just an extension to the basestation feature set and doesn't need new infrastructure).
Only when AT&T starts to support eDRX and PSM will "a month long" battery be realizable for portable products like this.
The thing is that LTE-M allows you to have real IP connectivity in contrast to other true LPWAN technologies built on datagrams that are sufficiently small that any real cryptography is non-trivial challenge and can be transmited once each minute/hour/day. If there is any unserviced niche it is in duplex bursts of realtime traffic (ie. what you usually get for satellite telematics, but for IoT it has to be few orders…
A few things. (1) If the payload is shorter than the key length (e.g. 128 bits) then crypto is actually really strong (and easy). For long payloads, you need to work a lot harder. (2) For doing a public key handshake, you can do it without a huge packet using one of the elliptical curve algos, but for any public key handshake you need a reasonably short duration of the handshake in order for it to be adequately secure. That's a bigger challenge than the data size. Low power LTE Cat M1 or NB-IoT systems aren't any better at practically serving low latency sessions than most LPWANs are. (3) "secure elements" should be called "insecure elements" when the items they are installed in are remotely operated in public environments. (4) Carriers tend to use TCP/IP with LTE, which is more of a limitation than a benefit, because it prevents any manner of broadcasting. There are a lot of applications that can be low power if they are broadcasted, but will never be low power (or easy) via TCP. (5) The direction LTE has gone, in my opinion, makes it undesirable for a lot of applications. It is nice for low-volume monitoring applications. So in a sense I think LTE as a LPWAN is really the great solution for niche use-cases.
I would love to see an actual low power, long range system: a cross between Bluetooth low energy and LTE. Allow devices to transmit at a higher power than Bluetooth and with much smaller receiver on time than LTE.
That's a really hard problem to solve, which is why you don't see lots of solutions. DASH7 has been around for a few years, and it addresses the technical aspects of this problem, although it still probably needs another year to mature to the point where it's easy to integrate. But if you have a high volume application, it's an option.
Intel pulling out is far from a canary in the coal mine. The rest of your post is fairly accurate though! Background: Intel has serious production issues with their latest 10nm process, meaning their x86 chips and LTE modems for Apple are filling most of their capacity to manufacture chips on the existing 14nm process. I doubt Intel has LTE modem designs that work on older processes, and NB-IOT being unproven, low vo…
Actually, ultra-low power devices (ie months-/years-long battery life) are probably better suited for older technology nodes, say 40+ nm for bulk, or 22+ nm for SoI. Standby leakage power is going to be too high on the lower nodes. Lasting months/years on a coin cell means sub-1 uA standby combined with infrequent, short-lived wake cycles. There's no real way around this until you go to energy harvesting, and right n…
Excellent post -- a rarely understood truth. For low power wireless systems, still, though, the bulk of the energy is spent in TX and RX. But realistically the quiescent power drain still needs to be in the sub 5uW range to deliver long life on a small battery. A lot of GNSS and LTE SoC's standby in the 50uW range, which is just too much. Most of the LTE devices I've surveyed (M1, NB-IoT) are expected to be attached to MCUs, but they implement internally a small linux platform. Obviously, that makes it hard to get down to 5 uW.
On another note, GPS tracker is probably wrong application for this assesment as I would believe that GPS receiver has significantly larger power consumption than LTE-M radio.
No, it's usually much less for GNSS. The secret to low power GNSS is to find a way not to have the receiver on much of the time, but that's very possible. LTE has less flexibility in overhead energy, because there's overhead enforced by the network.
Let's be honest, LTE was always oversold in terms of its technical limitations. The first reference to it that I can recall seeing (years ago) actually was describing LTE Advanced (~150 Mb/s), but conveniently left out that information. I know that it had been shown in testing to reach 200 Mb/s - call me when real world usage data can show that kind of result. In reality, the kind of progress that @barbegal mentions…
LTE Advanced with carrier aggregation can certainly deliver on speeds. Here is a fresh speedtest taken just now, were I'm getting 185Mbps down. I'm inside a building but only 1 block from the cell site and I'm getting 3x Carrier Aggregation on 2.5GHz (band 41) on Sprint. I'll admit these are pretty ideal circumstances for a speed test but I just opened the app an ran it to show the speeds are possible.
I've often found the most limiting factor (beside RF interference) is not LTE directly but the backhaul connections at cell sites. If you only have a 1 gig ethernet link, that limits your speeds when you get a handful of active users.
Let's be honest, LTE was always oversold in terms of its technical limitations. The first reference to it that I can recall seeing (years ago) actually was describing LTE Advanced (~150 Mb/s), but conveniently left out that information. I know that it had been shown in testing to reach 200 Mb/s - call me when real world usage data can show that kind of result. In reality, the kind of progress that @barbegal mentions…
I’ve gotten 150 mbps down using the Ookla Speedtest app on my iPhone 6s at the strip mall nearest to me. (Nowhere special, suburban Annapolis.)
Tried it just now at my house on my iPhone SE: 29 mbps down, 28 msec ping. One floor right above my Wifi router, I’m getting just 30 mbps (7 msec ping however) over Wifi, so the LTE performance isn’t too shabby.
Let's be honest, LTE was always oversold in terms of its technical limitations. The first reference to it that I can recall seeing (years ago) actually was describing LTE Advanced (~150 Mb/s), but conveniently left out that information. I know that it had been shown in testing to reach 200 Mb/s - call me when real world usage data can show that kind of result. In reality, the kind of progress that @barbegal mentions…
I have never been unimpressed by LTE. It's reliably fast, even if it's not blowing records. I know that if I have good-full LTE signal that if my shoddy 1Gb Spectrum connection or my wireless has issues I can just disable my phones wireless and get a great stable connection. Yeah, it's not going to replace my home internet but it is incredibly better than 3g. I know if my phones on 3g it's not even worth using for anything other than phone/sms. Definitely not MMS.
Let's be honest, LTE was always oversold in terms of its technical limitations. The first reference to it that I can recall seeing (years ago) actually was describing LTE Advanced (~150 Mb/s), but conveniently left out that information. I know that it had been shown in testing to reach 200 Mb/s - call me when real world usage data can show that kind of result. In reality, the kind of progress that @barbegal mentions…
I’ve gotten 150 mbps down using the Ookla Speedtest app on my iPhone 6s at the strip mall nearest to me. (Nowhere special, suburban Annapolis.) Tried it just now at my house on my iPhone SE: 29 mbps down, 28 msec ping. One floor right above my Wifi router, I’m getting just 30 mbps (7 msec ping however) over Wifi, so the LTE performance isn’t too shabby.
That's fair, although I suspect the infrastructure is more developed in certain areas because the Naval Academy is there. The SE result is pretty typical from what I've seen. When I only had 25/5, I'd be really excited by such a thing, but 100/35 has ruined me.
We would like to evaluate this. Currently looking at Sigfox, space.fleet and others. I sent a message via the Hiber contact page.
If you want to experiment with LoRaWAN, we open sourced our Network Service: https://github.com/exploratoryengineering/congress We also open sourced our module design (EE-02) that uses nRF52 as the MCU: https://github.com/ExploratoryEngineering/ee0x-hardware You can buy the modules here, but I think stocks might be running low. (However, if anyone needs larger numbers of modules we can put you into contact with the f…
Can you recommend a good write up on LoraWan architecture? (Curious about the need for a network service). Cheers!