[HN Gopher] Show HN: LTE-connected IoT module with remote progra...
___________________________________________________________________
Show HN: LTE-connected IoT module with remote programming and NL
data analysis
Hi HN! I've been working on this IoT platform that aims to simplify
deploying remote sensor networks by combining pre-configured LTE
hardware with a cloud platform for remote programming and AI-based
analysis. The main challenges I'm trying to solve are: 1.
Eliminating infrastructure setup headaches for IoT deployments 2.
Making remote programming and debugging practical for devices that
might be difficult to access physically 3. Using natural language
for analyzing sensor data, and possibly taking actions based on the
analysis I'd really appreciate feedback on: 1. Is this approach
to IoT development interesting to you? 2. What use cases would you
want to explore with this kind of platform? 3. What concerns would
you have about adopting something like this? 4. Could anyone
recommend workflows or tools for making the AI agent more reliable?
Currently using LLMs to generate isolated SQL queries to extract
data, but ensuring consistent responses has been challenging.
Thanks for any thoughts, and feel free to ask any questions about
how the hardware or platform works. Happy to dive into the details!
Author : siliconwitch
Score : 22 points
Date : 2025-04-17 13:35 UTC (1 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| usg7 wrote:
| As this is going to be best use case for remote devices without
| human intervention, battery life or power source will play
| significant role in this. so as it's using LTE how power
| consumption is going to be (for places with less availability of
| electricity) any future plans for solar integration?
| klinquist wrote:
| They mention it is battery ready, small solar panels w/ battery
| charge controllers are very plentiful in the market today. If
| this is anything like competitors (Particle), you can put the
| devices in a very low power sleep state and have them wake up
| on event or on a time schedule to connect to LTE and send data.
| siliconwitch wrote:
| We're actually looking at a few energy harvesting ICs designed
| for solar. They usually charge up an onboard super capacitor
| that can be used for infrequent transmissions. If it works out,
| we might add it into a future version of the board, or as an
| add on board
| klinquist wrote:
| An add-on GPS would be helpful for all sorts of remote telemetry
| applications.
| siliconwitch wrote:
| Yep! GPS is already built in
| hakaneskici wrote:
| This looks very interesting, thanks for sharing. Have you started
| delivering any developer kits?
| siliconwitch wrote:
| Not yet, but next week we should be getting a batch of PCBs
| with better tuned antennas. Fingers crossed if the performance
| is good, we will send them out to test in different regions.
|
| If you have an nRF9151-DK though, we could provide a firmware
| image and SIM for you to try it out. Once you flash your board,
| you can use it with the platform just like I did in the video
|
| Let me know if you're up for trying it!
| brk wrote:
| Along the same lines, I've been working with a few of these
| modules and they are nicely engineered overall:
| https://quickspot.io/
| h1t35h wrote:
| What do you mean when you say consistent response is a problem ?
| Is it that each time the response varies or that the response
| cannot be relied upon.
|
| Have you tried fiddling around with temperature or SQL specific
| finetuned models?
| flyingcircus3 wrote:
| The remote programming seems like a novelty aimed at hobbyists.
| If I have a deployment of remote devices, large or small,
| iterating on code on a device in the field is a recipe for
| disaster. How will you track the different versions of code on
| the various devices you have changed individually? If you need to
| directly change the code on a field device, doesn't that imply
| that you are unsure that the changes will work?
|
| If the code needs to change, that is much safer to do in a
| controlled, low risk, nonproduction environment, where you will
| very likely have development hardware that has been optimized for
| ease of development/debugging. Once changes are tested and
| otherwise validated, an over the air update process would be used
| to send that new firmware image to the device. This way, your
| devices all can be on a single version of the firmware, meaning
| you can scale the deployment of that update to 10, then 100, then
| 1000 devices, etc.
| siliconwitch wrote:
| The way the scripting engine is designed is such that it's not
| really a problem to iterate in the field. If your code has an
| error, simply adjust and restart the script. Sure if you have
| the device hooked up to motors which could break things then of
| course you might want to do that in a controlled environment,
| but for applications like sensing that's seldom a problem. The
| benefit you gain here is a very fast iteration cycle where you
| can easily test against real conditions, rather than in a lab
| where it might be hard to validate things. No need for heavy
| firmware testing, rolling out OTA updates, or worrying about
| bricking devices
|
| In general I agree with you for complex projects, but these are
| typically where you can afford to have 2-3 engineers spend a
| year developing a specialised solution. Building infrastructure
| to safely roll out updates, managing data plans, handling
| compromised devices. All of this becomes a massive amount of
| work before you're actually solving a problem for your business
|
| The target audience isn't necessarily engineering companies,
| but rather those that might have a few tech generalists. Their
| goal simply being to add some kind of sensing that might
| transform their product or service
| 999900000999 wrote:
| I was trying to build an LTE solar powered phone of last resort.
|
| After looking into it, LTE makes this nearly impossible to do
| economically.( Plus there's like 4 different types of LTE
| depending on county.)
|
| I really want energy coms devices!
| siliconwitch wrote:
| It's a massive rabbit hole! Thankfully LTE Cat-M1 that we use
| is much simpler than full blown LTE, but even still, the most
| iteration we've had to do is around the antenna system. Huge
| number of frequencies and bandwidths to support and much of the
| information is quite difficult to track down. Thankfully with
| the help of the SoC maker, antenna maker and SIM provider,
| we've just about managed to figure it all out
| dogma1138 wrote:
| How is it better than having any phone + a backpack solar
| charger?
|
| If you are looking for a doomsday scenario then LTE isn't the
| way to go, handheld radios is the way to go.
|
| In virtually any large scale disaster scenario cell networks
| are one of the first things to go, they get overwhelmed and if
| there is a power loss then cell towers go down.
| 999900000999 wrote:
| It's more like if I get lost in my main phone battery dies or
| something or gets broken, I want a way to call for help.
___________________________________________________________________
(page generated 2025-04-18 23:01 UTC)