Speaker 1: Imagine stepping into a world where well almost everything around
Speaker 1: you is talking, not just your phone, but like the
Speaker 1: smart meter outside, maybe a sensor on a bridge miles away.
Speaker 1: They're not just sitting there, they're active, sharing data, making
Speaker 1: things smarter, our cities, our homes. There's this whole Internet
Speaker 1: of Things or IoT explosion, and the growth is just
Speaker 1: an incredible billions of devices already more coming online constantly.
Speaker 1: Today we're doing a deep dive into a technology that's,
Speaker 1: you know, quietly making a lot of this happen. NBIOT.
Speaker 1: That's narrowband Internet of Things. We've pulled together insights mainly
Speaker 1: from a great source LTE cellular narrow band Internet of
Speaker 1: Things and BIOT practical projects for the cloud and data
Speaker 1: visualization by doctor Hassum Fata. So our mission today it's
Speaker 1: really to unpack what nbiot actually is and maybe more importantly,
Speaker 1: why it's such a big deal. We'll look at where
Speaker 1: it came from, the actual hardware involved, how these devices
Speaker 1: talk to the cloud, where the data lands, and crucially,
Speaker 1: how we make sense of it all visually. The goal
Speaker 1: is for you to get a really clear picture, no
Speaker 1: confusing jargon, just why this tech is so vital for well,
Speaker 1: our increasingly connected world. Okay, let's get into it. When
Speaker 1: we think cellular, yeah, we usually jump to smartphones, but
Speaker 1: the tech behind it all has come such a long way, right, Oh, absolutely,
Speaker 1: it's night and day from those early like two G,
Speaker 1: three G systems GSM gprs, which were mostly just for
Speaker 1: calls maybe basic data, to today's four GLTE and now
Speaker 1: five G, which are these data powerhouses. They handle streaming, video, AI,
Speaker 1: cloud stuff. It's a huge shift, it really is.
Speaker 2: And what's fascinating I think is that NBIOT isn't just
Speaker 2: another step in that phone focused evolution. It's a specific
Speaker 2: branch purpose built, you know, for the IoT. It wasn't
Speaker 2: an afterthought. Its roots are in three GPP release thirteen
Speaker 2: that was sort of pre five G tech, and then
Speaker 2: it got extended and released fifteen, which is more aligned
Speaker 2: with five glt E specs.
Speaker 1: Ye.
Speaker 2: Now, release fifteen did bring in slightly higher speeds cat
Speaker 2: NB two they call it, but the core idea of
Speaker 2: the fundamental operation stayed the same. It's really designed for
Speaker 2: what we call machine type communication MTC and these low
Speaker 2: power wide area LPWA scenarios. The whole point is connecting
Speaker 2: tons and tons of devices very efficiently, often need them
Speaker 2: to last years on a single battery charge.
Speaker 1: And when you say tons of devices, the scales almost
Speaker 1: hard to grasp, isn't it. It is the source mentioned
Speaker 1: projections of over five billion devices connected via nbiot by
Speaker 1: twenty twenty five. That's yea yeah. They call it massive IoT,
Speaker 1: massive IoT exactly, So what does this actually mean for
Speaker 1: you listening? Why should you care? Will? Nbiot isn't just
Speaker 1: about faster downloads on your phone. It's enabling completely new things.
Speaker 1: Think smart homes, maybe controlling lights or heating super efficiently.
Speaker 2: Or security systems that don't need constant battery swaps.
Speaker 1: Right, and smart cities managing traffic better, monitoring air quality
Speaker 1: with sensor scattered everywhere.
Speaker 2: At grids, smart water meters, utilities.
Speaker 1: Yeah, wearables too, for health tracking, remote sensors out in fields,
Speaker 1: for farming.
Speaker 2: Object tracking, for logistics, even critical control systems.
Speaker 1: The key insight really is that nbiot makes it cheaper
Speaker 1: and more power to connect these devices, so we can
Speaker 1: put them in places and use them in ways we
Speaker 1: just couldn't before. It expands where we get data from Exactly.
Speaker 2: It's getting into those challenging environments, places where power or
Speaker 2: cost was a barrier. That's the game changer. We're getting
Speaker 2: granular data we never had before.
Speaker 1: Okay, so we see the potential, huge potential, But how
Speaker 1: do we actually build this? It starts with the hardware, right,
Speaker 1: the actual boards it does.
Speaker 2: The practical starting point is often an NBIOT hardware board.
Speaker 1: And what's cool the Source highlights is that these boards
Speaker 1: are often compatible with things like our adrenal software and tools.
Speaker 1: That makes it way more.
Speaker 2: Accessible, yeah, hugely accessible. It brings it within reach for hobbyists, students,
Speaker 2: not just you know, big engineering teams. It lowers that
Speaker 2: barrier to entry.
Speaker 1: So what's actually on these boards? What makes them tick?
Speaker 2: Okay, diving in, You've got a couple of key players.
Speaker 2: First is the micro controller unit, the MCU. The source
Speaker 2: mentions the microchip sam D twenty one G eighteen chipset.
Speaker 2: And the key thing here isn't just any chip. It's
Speaker 2: a low power but still high performance ARM Cortex M
Speaker 2: zero plus based microcontroller. It's got decent specs forty eight
Speaker 2: never herds, two hundred fifty six KB flash, thirty two KBSRAM.
Speaker 2: But the real emphasis is low power, engineered for efficiency
Speaker 2: for longevity.
Speaker 1: Right, Because these devices might sit out in a field
Speaker 1: for what ten years exactly.
Speaker 2: Battery changes are often just not feasible at that scale.
Speaker 2: Then you have the cellular modem itself. The Quicktail BG
Speaker 2: ninety six is a really common one. Mentioned its strengths well.
Speaker 2: It supports global frequency bands, which is crucial if you
Speaker 2: want to deploy worldwide ultralow power consumption. Again, vital data
Speaker 2: rates are up to three hundred and seventy five kilobits
Speaker 2: per second, both down and up. Now, it does operate
Speaker 2: in half duplex on LTE networks.
Speaker 1: Half duplex like a walkie talkie you talk where you listen,
Speaker 1: but not both at once.
Speaker 2: Precisely, it sounds like a limitation, but it's actually a
Speaker 2: deliberate choice to save even more power. Perfect for devices
Speaker 2: that mostly just send small bits of data occasionally, and
Speaker 2: a really important feature for many uses. Built in GNSS
Speaker 2: Global Navigation Satellite System, so you high precision location data
Speaker 2: right from the device.
Speaker 1: Turns a sensor into a tracker basically exactly. Okay, so
Speaker 1: besides the brain and the communicator, what other physical bits
Speaker 1: are on the board, the nuts and bolts.
Speaker 2: You'll typically find a nano USIM card slot, just like
Speaker 2: your phone You need a SIM card, usually two USB ports,
Speaker 2: one for programming the MCU, one for interacting directly with
Speaker 2: the modem, which is handy for testing and configuration. And importantly,
Speaker 2: separate antenna connectors, one for the LTE cellular signal and
Speaker 2: one for the GNSS signal to make sure you get
Speaker 2: the best possible reception for both.
Speaker 1: Got it. So you've got this specialized efficient hardware. How
Speaker 1: do you actually command it? How do you tell the
Speaker 1: modem connect to this network or send this data.
Speaker 2: That's where AT commands come in. They're essentially the language
Speaker 2: you use to talk to the modem. Think of them
Speaker 2: like text based instructions. You send a command, the modem
Speaker 2: responds or performs an action. For instance, you might use
Speaker 2: at plus q ECFG and news can't say ten three
Speaker 2: zero two zero one to tell it hey prioritize searching
Speaker 2: for the LTE cast NB one network first. It gives
Speaker 2: you fine grain control. You can do security things like
Speaker 2: at plus c K to manage locks on the simcard
Speaker 2: or query information. At plus GSN gets you the device's
Speaker 2: unique IMEI number, at plus QCCID gets the simcards ID,
Speaker 2: and a really critical one is activating the data connection
Speaker 2: the PDP context like AT plus C G D C
Speaker 2: E C O, N T one I, P M two,
Speaker 2: M N B sixteen, dot Com, dot T That tells
Speaker 2: it how to connect to the Internet via in this
Speaker 2: case AT and T's network. It shows you the level
Speaker 2: of control you have to optimize things, which is super
Speaker 2: important for large deployments.
Speaker 1: So it's not just theoretical. Then you actually need a
Speaker 1: physical simcard and a plan from a mobile operator.
Speaker 2: Absolutely just like your phone operators like AT and T,
Speaker 2: T Mobile, Verizon, and even specialized IoT virtual operators like Hologram.
Speaker 2: They provide the actual nbiot network coverage Without that network,
Speaker 2: the hardware, however, smart is just well disconnected.
Speaker 1: Right, Okay, this is where it gets really interesting for me.
Speaker 1: The devices collect the data, then what where does it
Speaker 1: all go?
Speaker 2: Straight to the cloud that's the central hub.
Speaker 1: The digital brain.
Speaker 2: Yeah.
Speaker 1: The source material leans heavily on Amazon Web Services IoT
Speaker 1: aws IoT right.
Speaker 2: And setting that up involves a few key steps. Make
Speaker 2: sure everything talks securely and efficiently. First, you have device management.
Speaker 2: You actually register your device in AWSIOT as a thing.
Speaker 2: You give it a unique name, maybe like nbiot temp
Speaker 2: Sensor one twenty three, at attributes like its location. Then
Speaker 2: security certificates. This is non negotiable. You generate a unique
Speaker 2: certificate for the device or private key keep secret, and
Speaker 2: you need a root certificate to verify aws's identity.
Speaker 1: That's the digital handshake, basically, to make sure everyone is
Speaker 1: who they say they are exactly.
Speaker 2: It prevents eavedropping, ensures data integrity. Without it, it's not secure.
Speaker 1: And you need rules. Right, you can't just let any
Speaker 1: device do anything it wants connected precisely.
Speaker 2: That's where policies come in. You define exactly what that
Speaker 2: specific device is allowed to do. Can it publish data
Speaker 2: to which specific topics? Can it subscribe to receive data about?
Speaker 2: Granular control for security. And finally you set up rules
Speaker 2: for data processing. These are like automated actions. An incoming
Speaker 2: message comes in, say matching a pattern like select from
Speaker 2: sensors building a floor three, and the rule triggers in action.
Speaker 2: That action could be storing the data, sending an alert,
Speaker 2: maybe triggering another cloud function. It's how raw data starts
Speaker 2: becoming useful.
Speaker 1: Okay, storing the data where does it typically land? In
Speaker 1: this AWS setup?
Speaker 2: The source points to Dynamo dB. It's a no SQL
Speaker 2: key value.
Speaker 1: Database, no SQL, so not like traditional databases with rigid tables.
Speaker 2: Exactly. It's big advantage heirs being schemeless. You don't have
Speaker 2: to define the exact structure of your data upfront. If
Speaker 2: one sensor sends temperature and humidity and another sends GPS
Speaker 2: and battery level, Dynamo dB handles it.
Speaker 1: Easily ah flexible. That makes sense for IoT with all
Speaker 1: its different device types, huge advantage.
Speaker 2: Typically you'd use the device's IMEI as the main identifier,
Speaker 2: the partition key, then maybe a timestamp is the sort keys.
Speaker 2: You can easily query data by time time all the
Speaker 2: actual sensor readings get bundled into a payload attribute.
Speaker 1: Gotcha. Okay, so we have the path device like secure
Speaker 1: connection IRAQ flateral's database. What are the actual languages the
Speaker 1: protocols making that connection happen efficiently?
Speaker 2: The big one the workhorse for the application layer in
Speaker 2: nbiots MQTT message q telemetry transport. Its superpower is being
Speaker 2: incredibly lightweight, perfect for these constrained devices, small memory, low
Speaker 2: processing power and crucially saving battery.
Speaker 1: Lightweight is key.
Speaker 2: Absolutely. It uses that published subscribe model we touched.
Speaker 1: On the Digital Noticeboard idea.
Speaker 2: Exactly, devices published messages to a topic could be city
Speaker 2: traffic sensor, main street and anything interested maybe a dashboard
Speaker 2: or another system subscribes to that topic to get the
Speaker 2: messages super efficient. That also has useful features like retained messages.
Speaker 2: The last message on a topic can be saved for
Speaker 2: new subscribers, and something called a WILL message.
Speaker 1: A will message right, a last will and testament kind of.
Speaker 2: If a device disconnects on and expectedly maybe it loses
Speaker 2: power or crashes, the MQTT broker can automatically send out
Speaker 2: a pre defined WILL message on its behalf maybe sensor
Speaker 2: one twenty three offline. Really useful for alerts clever.
Speaker 1: Okay, so m QTT handles the messaging. What about keeping
Speaker 1: it secure?
Speaker 2: That's where SSLTLS comes in secure socket layer or transport
Speaker 2: layer security. It encrypts the communication between the modem and
Speaker 2: the cloud. Absolutely essential. You can figure this using those
Speaker 2: AT commands. Again, things like at plus qstl CFG and
Speaker 2: at plus qs will open to set up the secure tunnel.
Speaker 2: And while QTT is common the modems built in tcpip
Speaker 2: stack means it can also do standard Internet stuff like
Speaker 2: HTTP requests if needed, using commands like at plus coo,
Speaker 2: at plus coys end at plus QHTTPG E t OH
Speaker 2: and one more crucial thing firmware updates over the air
Speaker 2: or DFOTA. These modems can receive updates remotely, usually small
Speaker 2: delta updates, just the changes to fix bugs or add
Speaker 2: features without having to physically touch thousands of devices DFTA.
Speaker 1: Yeah, that's huge for maintenance, especially for devices way out
Speaker 1: in the middle of nowhere.
Speaker 2: Absolutely essential for managing large fleets long term.
Speaker 1: You know, collecting all this data, sending it securely, storing it,
Speaker 1: that's amazing engineering. But raw data is just well raw
Speaker 1: data isn't it numbers in a database. It only really
Speaker 1: comes alive when we can see it, visualize it. That
Speaker 1: old saying a picture is worth a thousand words. It's
Speaker 1: especially true here trying to spot trends or problems in
Speaker 1: all that IoT data.
Speaker 2: Could agree more. Visualization turns that flood of information into
Speaker 2: something understandable, actionable.
Speaker 1: So how does the data get formatted for this? What's
Speaker 1: the common language for the data itself?
Speaker 2: The dominant format discussed in the source and really industry
Speaker 2: wide for this kind of thing is Jason JavaScript Object notation.
Speaker 2: If big advantages are that it's human readable, which is
Speaker 2: great for debugging, it's mature and basically every tool and
Speaker 2: cloud platform under the sun understands it. So a temperature
Speaker 2: sensor might send something simple like device IIDE sensor forty
Speaker 2: five timestamp one six seven eight eight eight eight six
Speaker 2: four hundred do temp twenty two point five unit c
Speaker 2: easy to read, easy for software.
Speaker 1: To parse, makes sense. Are there alternatives?
Speaker 2: There is CBR Concise Binary object representation. It's a binary format,
Speaker 2: so it's generally more compact than Jason. Uses less data
Speaker 2: on the.
Speaker 1: Wire, smaller data size. That sounds good for nbiot.
Speaker 2: It can be, yeah, especially if bandwidth is really tighter.
Speaker 2: Every byte of battery matters, But the trade off is
Speaker 2: it's not human readable and you need specific libraries to
Speaker 2: encode and decode it. So while CBR exists and has
Speaker 2: its uses, Jason's ease of use and wider support often
Speaker 2: make it the more practical choice.
Speaker 1: Right now, okay, Jason? It is mostly so, how do
Speaker 1: we turn that Jason data into say, dots on a
Speaker 1: map or charts showing temperature changes for location data?
Speaker 2: The Google Maps JavaScript APIs are a very common choice.
Speaker 2: You can easily plot the GPS coordinate's coming from your
Speaker 2: MBIOT devices right onto a familiar Google map embedded in
Speaker 2: a web page or application.
Speaker 1: Right so for tracking trucks or finding lost equipment.
Speaker 2: Exactly, asset tracking, fleet management, navigation, tons of applications. The
Speaker 2: process is straightforward. Get a Google Maps apikey, use some
Speaker 2: JavaScript to initialize a map, read the latest latitude and
Speaker 2: longitude from your database for a device, and plank a
Speaker 2: marker on the map. You see your stuff moving in
Speaker 2: near real time.
Speaker 1: And for other sensor data like that temperature reading.
Speaker 2: For that, libraries like chart dot js are really popular.
Speaker 2: It's an open source JavaScript library that makes it easy
Speaker 2: to create nice looking interactive charts, bar charts, line charts, etc.
Speaker 2: Write in a web browser using HTML five canvas. So
Speaker 2: you could easily pull temperature readings from Dynamo dB and
Speaker 2: plot them on a line chart against time instantly see
Speaker 2: the daily temperature cycle, spot unusual spikes or dips. It
Speaker 2: makes patterns jump out.
Speaker 1: Yeah, much better than staring at a spreadsheet full of numbers.
Speaker 2: Definitely. It brings the data to life.
Speaker 1: This is where it all comes together, isn't it. This
Speaker 1: isn't just theory or textbecs anymore. Nbiot is actually out
Speaker 1: there making real changes. That's the exciting part.
Speaker 2: It really is seeing the applications make the underlying tech meaningful.
Speaker 1: Like in the smart home we mentioned lighting, heating, security,
Speaker 1: but also things like elder care sensors detecting falls maybe
Speaker 1: or tracking devices for kids or pets that can last
Speaker 1: ages on one.
Speaker 2: Charge bis peace of mind.
Speaker 1: Totally, and smart transportation traffic control that adapts, smart parking
Speaker 1: telling you where spots are, smooth toll collection, logistics tracking
Speaker 1: for delivery companies.
Speaker 2: Even vehicle safety systems talking to each other.
Speaker 1: Are the infrastructure and smart farming measuring soil conditions, humidity, rainfall,
Speaker 1: detecting pests, automating irrigation, helping farmers grow more with less waste.
Speaker 1: It's pretty amazing. The breath of it.
Speaker 2: It truly is diverse, and it raises the question how
Speaker 2: does this look when a whole city embraces it? How
Speaker 2: does it scale up? The city of Coral Gables, Florida
Speaker 2: is a really interesting case study here. They're often cited
Speaker 2: as a leader in building a comprehensive smart city ecosystem.
Speaker 1: Oh yeah, what are they doing? Specifically?
Speaker 2: They've deployed a really wide array of sensors and actuators.
Speaker 2: Environment sensors monitoring everything from temperature and humidity to water levels,
Speaker 2: air quality, even noise pollution. They have smart parking, smart
Speaker 2: street lighting. They use drones, GPS for managing city vehicles,
Speaker 2: RF sensors to understand traffic flow.
Speaker 1: Wow, okay, so data on everything pretty much.
Speaker 2: Public safety uses CCTV and smart policing tools connected to
Speaker 2: the network. They have digital kiosks. They monitor the structural
Speaker 2: health of bridges and buildings, and they're integrating connected vehicles.
Speaker 2: It's a whole interconnected web that sounds like.
Speaker 1: An ocean of data. How do they possibly manage that
Speaker 1: and make sense of it?
Speaker 2: They have what they call a smart city hub. The
Speaker 2: source calls it a digital supermarket, which I quite like.
Speaker 2: It's a central platform that gathers all this diverse data,
Speaker 2: standardizes it and analyzes it. And this provides actionable insights.
Speaker 2: It's not just data for data's sake. Traffic engineers use
Speaker 2: it to design safer roads or tweak signal timings. Urgan
Speaker 2: planners can see the actual impact of new developments. Businesses
Speaker 2: can even look at anonymaled foot traffic data. Public safety
Speaker 2: gets better situational awareness for emergencies.
Speaker 1: So it actually helps them run the city better.
Speaker 2: That's the goal. They use a horizontal integration model, basically
Speaker 2: a central cloud platform where everything connects and shares data
Speaker 2: feeding into city dashboards. And what's really cool is that
Speaker 2: a lot of this is public. You can actually go
Speaker 2: to www. Dot Coral Gables dot com, forward slash smart
Speaker 2: City and see some of the data and platforms. It
Speaker 2: shows how this tech can create more responsive, transparent communities.
Speaker 1: That's fantastic, a real world example of it all working together. Okay,
Speaker 1: So that brings us towards the end of our deep dive. Today.
Speaker 1: We've gone from the basics of nbiot why it's different,
Speaker 1: looked at the hardware, the journey to the cloud, the protocol, storage,
Speaker 1: the visualization right, making sense of it all visually, and
Speaker 1: finally seeing how it's making a real impact in everything
Speaker 1: from our homes to entire cities like Coral Gables. It
Speaker 1: leaves you thinking, though, as nbiot keeps connecting billions more devices,
Speaker 1: bringing in this constant stream of real time data from
Speaker 1: well everywhere, what new questions does That raise questions about
Speaker 1: how much we rely on this data, about the ethics
Speaker 1: of managing all this information, maybe even what it means
Speaker 1: to be informed when literally everything around US is generating data,
Speaker 1: something to ponder,