Samsung Artik IoT boards will finally start selling on February 22 via Digikey. With the many fascinating developments in the IoT space over the year, you’d be forgiven if you completely forgot about Samsung Artik boards. So let’s have a quick recap.
The Korean company previously announced three boards all supporting Bluetooth LE:
- Artik 1 – Ineda Systems Dual Core microAptiv MIPS32 processor with 1MB on-chip RAM, no GPU, and 4MB SPI flash
- Artik 5 – Dual core Exynos ARM processor @ 1GHz with ARM Mali 400 MP2 GPU, 512MB RAM and 4GB eMMC flash (both on-chip), with WiFi & Zigbee/Thread connectivity
- Artik 10 – Octa core Exynos processor with 4x ARM Cortex A15 @ 1.3GHz, 4x ARM Cortex A7 @ 1.0 GHz with ARM Mali-T628 GPU, 2GB LPDDR3 (on-chip), 16GB eMMC flash, and WiFi & Zigbee/Thread connectivity
Samsung also partnered with multiple companies working on:
- Operating Systems – Tizen, Nucleus Real Time OS (for Artik 1), Fedora Linux, and Snappy Ubuntu Core.
- Tools and Services
- Arduino web-based development environment
- Temboo for cloud connectivity and automatic code generation.
- Medium One’s workflow tools for analytics and visualization
- Sensory’s speaker-independent on-device TrulyHandsfree Voice Control technology
- Soundhound’s contextual natural language and voice recognition engine
- Vayyar’s 3D imaging sensor technology.
- Cloud – Microsoft Azure IoT Suite and IoT Hub; Samsung SAMIIO + the Open Data Exchange platform
- Security – TEE support (Trusted Execution Environment) with Trustonic
You can find the SDK, documentation, and community forum on Artik developer’s page.
Artik 1 and Artik 10 prices are not unavailable, 4 days from the launch… however Artik 5 kit is already sold for $99.99, and includes a baseboard, Artik 5 modules, three antennas for WiFi, Bluetooth and Zigbee, as well as a power supply and a USB cable.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
So $100 for the dev kit, but how much for the module on its own?
Why waste time with this until we know the price of the modules? If Artik 5 module is over $10, it is not interesting. Plus the RF is a mish-mash. Three antenna connectors? They should talk to Espressif.
Of course it will be over $10, they used a $5 EM3587 to get 802.15.4 support. It will probably be over $30 in Digikey.
https://developer.artik.io/documentation/getting-started-beta/board-reference.html
Artik 5 board also has zwave and sigfox/sub-ghz?
@Jon Smirl
Well. it’s not hard to understand why they went with Silicon Labs for ZigBee, at least not if they want to support the HA profile, as they have by far the best development tools. On the other hand, the chips are about 4x what the ought to be. And then there’s that issue of the Silcion Labs programmer that’s ~$500…
@Deets
It’s not very likely the module does, but it does indeed look like the developer board does (Sigma Designs chip clearly visible) which helps explain the $100 price point, as Z-Wave alone would add $5 in components costs. It’s interesting that they’ve done a custom board layout for Z-Wave, rather than using a module, as that simply doesn’t seem cost effective on a low volume developer board.
@TLS
I think Zigbee is a dead end and I won’t work with it anymore. If 802.15.4 is going to have any future it is with 6lowpan (ie Thread).
But.. I think BLE is going to win. BLE is dirt cheap and it can do everything 802.15.4 can. It can even mesh if you really want it to. Personally I think meshing lowpans is the wrong way to go. Better to build the backbone out of wifi and then use the lowpan for the leaf nodes. ESP32 is perfect chip for making that architecture. My favorite leaf node is the CC2640; it will run 10 years on a coin cell.
My dislike of dynamic meshes stems from trying to debug flakey ones. It is very difficult for an engineer to diagnose what is wrong, an end user is never going to figure it out. Nice hierarchical tree with fixed connections are very easy to debug. For fun – try to debug a mesh where the movement of elevators is causing it to constantly reconfigure.
It is funny that ARTIK means waste in Turkish.
@Jon Smirl
Thread is not 6LowPAN and the problem of both “standards” is that they’re not very standardised. Two 6LowPAN devices won’t talk to each other if they’re from different manufacturers, as the software end can be quite different. Thread is so far something of a joke, there were a handful of devices on display at CES, but nothing that really seemed to be working and so far it seems like unlike Z-Wave (and much in the same was as ZigBee) you only certify the radio stack, not that the devices are compatible and will work with sensors/devices/controllers/gateways from other brands, so I’d say either of those is just as bad as ZigBee.
ZigBee 3.0 might deliver, but who knows…
BLE 4.2 or 4.3 or 4.what? 4.2 looks promising, but where are the devices? So far everyone seems to be doing proprietary solutions which is just pure crap. 4.2 doesn’t have enough device type profiles, which is going to be a major obstacle in the same way as mentioned above with Thread, so we’re back to square one.
FYI, the chips are pretty much the same across all these standards and there are companies that can do Bluetooth, ZigBee, Thread or anything else 2.4GHz for less than $1 if you look around.
These guys could learn from Z-Wave when it comes to how a device presents itself, as that’s one of the least intuitive things right now and something that apparently no-one wants to enforce a “standard” way of doing and it’s a huge waste of time. If devices simply said “hey, I’m this type of device and this is what I can do” when they connect, it would be much quicker and easier to build decent HA software and gateways/controllers, but apparently that’s just a pipe dream.
I fully agree with you on the network design though, things like LoRA and SigFOX doesn’t excite me the least bit. The costs are simply too high for anything than large scale applications such as power meters or say water level measurement in remote areas, but it’s not suitable for any consumer or general IoT implementations.
And yes, you’re absolutely correct about the fault finding as well, it’s nigh on impossible today to figure out why a device dropped off the network, as this type of functionality wasn’t build in from the start and clearly still isn’t. It’s quite ridiculous that any of these things are considered retail worthy with the amount of issues that there is, without anyone even will to start working on solving them. Maybe one day…
@TLS
A core flaw in the design of all HA is to expose the lowpan at higher levels. You say you want IP everywhere, but you really don’t. IP to a temp sensor that connects for a millisecond when it decides it wants to is just pointless.
So my first rule — if it has mains power it has to talk wifi. ESP8266 enables this at very low cost. Now you can use heavy, but simple, protocols like JSON. You can even stick an ESP8266 into a light bulb, it is rated up to 120C.
Second rule — if it is on batteries use a lowpan, but proxy it at a mains wifi node. Now apps only ever interact with the always on wifi proxy. This hides the choice of lowpan from the higher level apps. My choice for this is ESP32 on mains, CC2650 for the battery powered nodes.
Espressif has two chips that could revolutionize HA if only everyone would start using them.
@Jon Smirl
Makes sense, but you’re missing one thing here, interoperability between brands.
There are as I said above, no standard device “announcements” when a device connects to a network that lets the rest of the devices know the capabilities of a new device. Z-Wave offers a fairly rudimentary way and it’s far from perfect, but it’s the only “standard” I know of that offers this and which is compatible across all brands/manufacturers.
This to me is a huge issue. Today the acceptable way to solve this is to go out of the home/office/whatever via a cloud using some kind of proprietary API or something like IFTTT to make devices talk to each other. This is simply not acceptable imho, as there are too many points that can be compromised from a security standpoint and at the same time, it’s slow, requires an always on internet connection etc. Why? Just because all of the technology companies can’t seem to agree on common standards, so now we have another one and I’m sure, tomorrow, or next week/month/year we’ll have yet another one and so on. It’s time the technology companies stop this and sit down and work out a a common way for devices to talk to each other.
@TLS
Interoperability between brands should be done at the wifi level where they can use things like http and json. You could even use UPNP at this level. Trying to make the lowpans interoperate is a giant mess that is best avoided. UPNP actually has profiles for light switches and thermostats. But it is an old protocol, JSON is a better solution.
We don’t have the model I described in the market yet because until recently it has been cost prohibitive to include wifi in things like light switches or bulbs. But that equation totally changed when the ESP8266 appeared. The ESP32 is the last missing piece, it can blanket the house with BLE to support battery based devices.
Exposing the lowpans to interoperability only results in chaos. Now that we can make wifi based light bulbs and switches just get rid of these lowpans. Work off from the assumption that the building is blanketed in wifi from routers. If it isn’t no one has a problem fixing their wifi coverage since their phones rely on it. Once you make that assumption the whole use-case for lowpan meshing collapses.
Once you are thinking in the wifi model the role of a lowpan goes back to it’s original definition as a peripheral connection scheme instead of a general purpose networking solution. The battery devices use the lowpan to connect to the nearest wifi node where they proxy. Think of them as peripheral devices connected with invisible wires, not as independent network nodes.
Artik 5 patchsets for mainline Linux kernel -> https://lkml.org/lkml/2016/3/13/215
Ubuntu core for Artik 5 & 10 -> http://insights.ubuntu.com/2016/05/05/ubuntu-core-now-available-for-samsung-artik-5-and-10/
Price and availability please
B&T. BW16 WIFI RTL8720DN ARM KM4 2.4G/5.8G/BT
FCC ID. 24AHMR-BW16
QUANTITY 100 pcs