4 ms·

From our research, it seems that a lot more of the hardware is running linux than we would've expected [1]. This makes linux a great starting point - but you ar

From our research, it seems that a lot more of the hardware is running linux than we would've expected [1]. This makes linux a great starting point - but you are right there's other platforms to look at too. Regarding data use - you're completely right. In previous production IoT projects we've worked on we've had in excess of 10X more debug data than actual useful information coming out, lest we're not able to debug problems! We've got a few tricks up our sleeve, the main one being that this only sends data when there is an exception. [1]: https://ianskerrett.wordpress.com/2017/04/19/iot-developer-trends-2017-edition/ https://ianskerrett.wordpress.com/2017/04/19/iot-developer-t... (Point 4)

TickleSteve 9y ago
In my experience, the Linux-based devices tend to be low-unit-number type devices such as gateways (or prototypes). Also, that point 4 in the link does not have the most common type of embedded OS... i.e. "None". Bare metal is very common. Another point here is that (according to that link), Raspbian is the most common. That indicates the data is coming from the "Maker" community, not the professional embedded developers... we don't tend to use RPi's for much. Anything that will be remotely cost-sensitive (as anything produced in large numbers will be) will tend to be microcontroller-based. Like you say, part of the solution is only sending the data that is needed. I would imagine another part of the solution that you could implement is some sort of shared string-table and hence transmitting only event-codes.
- bitdivision 9y ago
  We're really targeting gateways at the moment. Obviously, having overlock running on end devices would be ideal, and is certainly a future goal. For the moment though, running on the gateway seems to provide the most utility and is easily acheivable given the proliferation of linux based gateways. Compression is also certainly on the cards, but really comes in to its own once we have the clients running on resource-constrained devices.

TickleSteve 9y ago

In my experience, the Linux-based devices tend to be low-unit-number type devices such as gateways (or prototypes). Also, that point 4 in the link does not have the most common type of embedded OS... i.e. "None". Bare metal is very common. Another point here is that (according to that link), Raspbian is the most common. That indicates the data is coming from the "Maker" community, not the professional embedded developers... we don't tend to use RPi's for much. Anything that will be remotely cost-sensitive (as anything produced in large numbers will be) will tend to be microcontroller-based. Like you say, part of the solution is only sending the data that is needed. I would imagine another part of the solution that you could implement is some sort of shared string-table and hence transmitting only event-codes.

bitdivision 9y ago
We're really targeting gateways at the moment. Obviously, having overlock running on end devices would be ideal, and is certainly a future goal. For the moment though, running on the gateway seems to provide the most utility and is easily acheivable given the proliferation of linux based gateways. Compression is also certainly on the cards, but really comes in to its own once we have the clients running on resource-constrained devices.