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.
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
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?
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
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.
Not a hobbyist in this area yet, but I’m curious. Hehe. The use cases I’m interested in are weather and water monitoring for fresh water fisheries. And in a completely different domain, I’m interested in noise analysis overnight. My neighbors are super noisy, and it’s difficult to demonstrate the breadth and depth of the disturbance to neutral parties.
I started out very interested. I tried the particle photon when it first came out years ago, and this feels like a spiritual successor, somewhat. Good demo video.
Various thoughts:
1. Consider defining best practices for solar and selling harder around that. I've got enough use for the board in hardwired environments, and can otherwise solve outdoor power issues, but having a recommended solution that I can trust to be solid would go a long way. "Using panel of X strength and battery of X capacity, get performance Y in Z conditions", etc.
2. I would probably preorder some of these, except the pricing is omitted. I have no idea how much these would cost. If they're 5 bucks, I buy a bucket. If they're 30, I buy a handful. If they're 100, I probably skip it. Etc. Withholding the price is a red flag, and I wouldn't share my email with an org that saw fit to withhold this info as the opening act. (edit: looks like the S1 is $55, so presumably this is more)
3. The LLM/agent aspect has no appeal. Assuming those costs are passed on to me / baked into every unit, the inclusion of AI is strictly downside.
4. It's not clear whether there are ongoing SaaS/storage/subscription costs associated with this, or what they would be. The FAQ suggests that forwarding data outside of the cloud will be restricted to enterprise-scale customers. This is also a red flag.
I think this can be successful in spite of all that. Particle definitely leaned away from hobbyists and into the larger ag-IOT market early on, presumably following money and stability. Totally understandable.
I guess my overall feedback is this: be upfront about the pricing and restrictions in a way that lets guys like me filter ourselves out upfront, instead of getting our hopes up. I've got a maker-tier budget, value data freedom, and am subscription-averse. It took me quite a bit of time and digging to uncover all the details in this comment, and I wish I hadn't spent the time. There are a ton of customers who are going to be totally cool with a $60+ board and a *0,000/mo contract for data forwarding. Court them directly.
Of course, I'd love to be wrong. If this is a $30 board with nearly-at-cost cloud storage and no REST data forwarding but yes bulk JSON download, then whoa, fuck yeah. Shout that from the rooftops too.
Completely understand. This is really good feedback. I can start off by saying that there will absolutely be a free tier within the platform where you can buy a board and that’ll include some amount of data allowance per month. It’ll also include some amount of AI usage too (even if that’s not so relevant for your application)
We’re modelling the hardware pricing such that the cost of the AI isn’t baked into the board cost. I understand that for some users, they might not necessarily need these features and it makes no sense for them to have to pay for it.
I’m expecting that we can have the boards competitively priced around the ~$70 mark, but often the distributors will try to price it in line with similar products they carry. I didn’t want to mention it in the video as we’re still negotiating this with them.
Going up from there, the subscription pricing will be split into several tiers that allow for higher data usage, AI usage and the ability to connect higher numbers of boards to one deployment.
It’s interesting that you mentioned that you’d like the data forwarding as a base feature. Our initial thoughts around that was to fulfil the requirement for companies who need to own their data. Ie we can’t store it for them. To be clear, you’ll still have access to the data via an API even in the free tier, and you’ll also be able to send data to devices via a REST API. It was just the live data forwarding from devices to your server that was intended to be limited to companies
I don’t see any mention of what LTE SoC is used anywhere? Even if you’re abstracting away the hardware in this application, isn’t it relevant for many potential users what the chip is?
It’s the nRF9151 from Nordic. We’ll include a detailed section on the SoC and a full schematic once the documentation is up
The platform as you said aims to abstract away a lot of these details (though they’ll still be available if needed). Each of the IO ports will be configurable as GPIO/Analog/SPI/I2C, etc. Since these are all accessed via the Lua API anyway, we expect folks to not have to dig through the SoC documentation in order to figure things out. All the relevant settings for each mode will be available through the API. But yes, if you need more info, then it’ll be available in the docs
We haven’t tried SQL specific models actually. That’s quite a good idea. Will try it out.
Yeah it mostly seems to be inconsistent at generating the SQL queries themselves. I guess my question was if this is even a good way to do it in the first place, or if we’re better off trying to analyse the data in a different way
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
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.
The SoC we use will also be gaining support for non-terrestrial networks soon. It’s the same feature that new iPhones have for Satellite based SOS when you’re outside of cell range. We’re not sure when it’ll be ready yet, or what the power consumption will be, but perhaps that could be something useful for this sort of use case. As far as I know it’ll support regular data traffic too, not just for emergencies.
Voice is possible over LTE-M but it’s sort of the wrong technology for it. It’s designed for low power so the data rate is quite slow and the latency won’t work for two people trying to talk to each other.
It’s a similar speed to Bluetooth LE (not Bluetooth audio which headphones use). Sub 100kBps
NTN will be even slower. Few kBps. Really intended for sensor data or machine related actions
As long as it can signal emergency services it'll be fine for what I'm thinking of.
Texting emergency services a preset message like "Paramedic requested, at GPS cords..."
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
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.
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
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?
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
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.
Not a hobbyist in this area yet, but I’m curious. Hehe. The use cases I’m interested in are weather and water monitoring for fresh water fisheries. And in a completely different domain, I’m interested in noise analysis overnight. My neighbors are super noisy, and it’s difficult to demonstrate the breadth and depth of the disturbance to neutral parties.
I started out very interested. I tried the particle photon when it first came out years ago, and this feels like a spiritual successor, somewhat. Good demo video.
Various thoughts:
1. Consider defining best practices for solar and selling harder around that. I've got enough use for the board in hardwired environments, and can otherwise solve outdoor power issues, but having a recommended solution that I can trust to be solid would go a long way. "Using panel of X strength and battery of X capacity, get performance Y in Z conditions", etc.
2. I would probably preorder some of these, except the pricing is omitted. I have no idea how much these would cost. If they're 5 bucks, I buy a bucket. If they're 30, I buy a handful. If they're 100, I probably skip it. Etc. Withholding the price is a red flag, and I wouldn't share my email with an org that saw fit to withhold this info as the opening act. (edit: looks like the S1 is $55, so presumably this is more)
3. The LLM/agent aspect has no appeal. Assuming those costs are passed on to me / baked into every unit, the inclusion of AI is strictly downside.
4. It's not clear whether there are ongoing SaaS/storage/subscription costs associated with this, or what they would be. The FAQ suggests that forwarding data outside of the cloud will be restricted to enterprise-scale customers. This is also a red flag.
I think this can be successful in spite of all that. Particle definitely leaned away from hobbyists and into the larger ag-IOT market early on, presumably following money and stability. Totally understandable.
I guess my overall feedback is this: be upfront about the pricing and restrictions in a way that lets guys like me filter ourselves out upfront, instead of getting our hopes up. I've got a maker-tier budget, value data freedom, and am subscription-averse. It took me quite a bit of time and digging to uncover all the details in this comment, and I wish I hadn't spent the time. There are a ton of customers who are going to be totally cool with a $60+ board and a *0,000/mo contract for data forwarding. Court them directly.
Of course, I'd love to be wrong. If this is a $30 board with nearly-at-cost cloud storage and no REST data forwarding but yes bulk JSON download, then whoa, fuck yeah. Shout that from the rooftops too.
Either way, disambiguation would help.
Completely understand. This is really good feedback. I can start off by saying that there will absolutely be a free tier within the platform where you can buy a board and that’ll include some amount of data allowance per month. It’ll also include some amount of AI usage too (even if that’s not so relevant for your application)
We’re modelling the hardware pricing such that the cost of the AI isn’t baked into the board cost. I understand that for some users, they might not necessarily need these features and it makes no sense for them to have to pay for it.
I’m expecting that we can have the boards competitively priced around the ~$70 mark, but often the distributors will try to price it in line with similar products they carry. I didn’t want to mention it in the video as we’re still negotiating this with them.
Going up from there, the subscription pricing will be split into several tiers that allow for higher data usage, AI usage and the ability to connect higher numbers of boards to one deployment.
It’s interesting that you mentioned that you’d like the data forwarding as a base feature. Our initial thoughts around that was to fulfil the requirement for companies who need to own their data. Ie we can’t store it for them. To be clear, you’ll still have access to the data via an API even in the free tier, and you’ll also be able to send data to devices via a REST API. It was just the live data forwarding from devices to your server that was intended to be limited to companies
I don’t see any mention of what LTE SoC is used anywhere? Even if you’re abstracting away the hardware in this application, isn’t it relevant for many potential users what the chip is?
It’s the nRF9151 from Nordic. We’ll include a detailed section on the SoC and a full schematic once the documentation is up
The platform as you said aims to abstract away a lot of these details (though they’ll still be available if needed). Each of the IO ports will be configurable as GPIO/Analog/SPI/I2C, etc. Since these are all accessed via the Lua API anyway, we expect folks to not have to dig through the SoC documentation in order to figure things out. All the relevant settings for each mode will be available through the API. But yes, if you need more info, then it’ll be available in the docs
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?
We haven’t tried SQL specific models actually. That’s quite a good idea. Will try it out.
Yeah it mostly seems to be inconsistent at generating the SQL queries themselves. I guess my question was if this is even a good way to do it in the first place, or if we’re better off trying to analyse the data in a different way
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!
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
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.
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.
The SoC we use will also be gaining support for non-terrestrial networks soon. It’s the same feature that new iPhones have for Satellite based SOS when you’re outside of cell range. We’re not sure when it’ll be ready yet, or what the power consumption will be, but perhaps that could be something useful for this sort of use case. As far as I know it’ll support regular data traffic too, not just for emergencies.
Anyway to make a solid voice call?
I know you probably have better things to do, but I have mockups and some rough designs if you’d like to talk
Voice is possible over LTE-M but it’s sort of the wrong technology for it. It’s designed for low power so the data rate is quite slow and the latency won’t work for two people trying to talk to each other.
It’s a similar speed to Bluetooth LE (not Bluetooth audio which headphones use). Sub 100kBps
NTN will be even slower. Few kBps. Really intended for sensor data or machine related actions
Hmm.
As long as it can signal emergency services it'll be fine for what I'm thinking of. Texting emergency services a preset message like "Paramedic requested, at GPS cords..."
Along the same lines, I've been working with a few of these modules and they are nicely engineered overall: https://quickspot.io/
This looks very interesting, thanks for sharing. Have you started delivering any developer kits?
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!
An add-on GPS would be helpful for all sorts of remote telemetry applications.
Yep! GPS is already built in