Fatal Flaw

[frakman]

Correct me if I am wrong but it seems to me that the problem with this device is that you can't get it online without a phone nearby. The whole idea was to have it in a remote location (like at home) and posting information to the cloud that I can access remotely (like from work). It should really have  WiFi or Ethernet jack to facilitate getting online.

I saw that there was a clickboard with WiFi support but it wasn't ready yet. I didn't see one with Ethernet.

Also, does anyone know if they hackster contest prize kits come with anything besides the unit and a USB cable? It seems like a docking station is really needed to do any serious work/connectivity.

[yoursunny]

I have been spoiled by WiFi-enabled devices (namely, the mighty ESP8266) for several years. Using BLE instead of WiFi allows the Rapid IoT kit to consume less power, so that the battery would last longer. Therefore, I would not call it a "fatal flaw".

Regarding the gateway: phones aren't the only devices with BLE. Raspberry Pi 3 and many newer Windows laptops have built-in BLE, and I plan to use those as a gateway.

[frakman]

It's a prototyping board which means it will be plugged in to power almost always while a project is under development. It will also be plugged in to power during operation while performing its project's main task. Therefore, I don't care about battery longevity. I suspect most people don't either.

As for the Pi and Windows having BLE. Can you share how to make a WiFi to BLE adapter with the Pi or Windows? What additional hardware is needed? I haven't found any documentation on this. I don't think that just having BLE is enough without additional support. The NXP phone app is what makes the bridging work. What is the equivalent app on the Pi or Windows? 

[yoursunny]

Raspberry Pi has a BLE chip, so there's no additional hardware.

BLE is very different from WiFi. You can't create a socket on BLE. Therefore, it would be difficult to develop a generic purpose BLE-to-WiFi gateway.

Instead, you publish sensed values as BLE attributes, and the Raspberry Pi side can read these attributes, and publish them in a different format (e.g. JSON) to the Internet.

Adafruit has a nice BLE tutorial that explains the concepts.

[estephania_mart]

Hello, 

Please consider that when using Bluetooth LE most of the times you will be sensing something and then it will go to sleep to save low power as you might not need to have the antenna powered on all the time.

Currently, we do not have any examples with neither WIFI nor Ethernet.  By any chance, have you checked the new examples available in the community? 

Rapid-IoT examples demos for mcuxpresso IDE 

I believe the cloud one will be of your interest. 

Regards, 

Estephania

[mrharmonsr]

Iot using BLE, ZigBee, Thread or other personal area networks rely on a "gateway" to pass data to a Wide Area Network.  NXP sells its SLN-IOT-GPI reference design for this purpose.

I previously asked about the software running on this device...

IoT using Wi-Fi is easier to use as it does not require a special gateway.  However its power usage is greater than BLE.

Hence, small battery powered devices tend to use BLE.

I have been trying to figure out just how proprietary the SLN-IOT-GPI software is.  Can I build my own?

The 6LowPan protocol was designed specifically to translate from an IP 6 address to a BLE or 802.15.4 address.

Is this all that is needed for a functional gateway?

[estephania_mart]

Hello, 

There is some information about it when using the Thread functionality and the IoT Gateway Solution|NXP  , it has an i.MX 6 on it and some other NXP solutions for ZigBee, Thread, NFC, etc.

It can work not only with Bluetooth, so it is not linked directly to phone usage, you can also use Thread on it which it's an IPv6-based mesh networking protocol. You can check more regarding this topic. 

You can check this series of videos for more information about the usage and possibilities with the usage of Thread and Bluetooth LE. https://www.nxp.com/pages/kinetis-kw41z-ble-plus-thread-introduction-to-the-course-part-0:TIP-LESSON...

Regards ,

Estephania 

[mrharmonsr]

I see mention of an Iot Border router built with a FRDM_k64 and Frdm-CR20a in NXP's Iot roadmap literature.

ARM mbed has a project for it on Github.  https://github.com/ARMmbed/k64f-border-router

Has anyone tested this with the RapidIoT ?

[frakman]

Thank you Estephania for the links. 

How do I advance to the next video in the series? The link doesn't have any other videos listed or a way to go to the next one.

Also, what exactly do I need in terms of physical devices in order to start using Thread? Do I have to buy this `Modular Gateway' in order to get WiFi connectivity to the cloud?  Can you provide a link to where I can buy this from? The only thing I found on NXP's website is the $500 kit that includes this gateway.

[estephania_mart]

Hello, 

You can check the Training & Events|NXP  page, I believe the link should work and search for all the available Thread training, but in case it does not, you only need to look up in the training search engine for the word Thread and you will find 10 of them. 

That it's not the only device that can work with Thread, if possible could you please check the Kinetis Thread Stack Demo Applications User's Guide? It is available in the MCUXpresso SDK Builder in the documentation of the KW41Z. The chapter that you need to check the most it's the Chapter 11 Running Border Router Application Scenarios. 

Regards,

Estephania 

[frakman]

Thank you for the links.

1- Regarding Thread.

Thank you for the links to the training videos. I don't want to re-invent the wheel. Please answer the following simple question:

What is the minimal Hardware and Software I need to get this so-called "Rapid" IoT to ping an IP address on my LAN without a mobile phone with BLE? If the answer is a dedicated Thread Border Router gateway running AllJoyn application and another device with 802.15.4 etc, then this is a non-starter and there is nothing Rapid about this. I want to focus on board logic and algorithms and not have to write a connectivity protocol.I have local WiFi devices that I want to send HTTP API requests to. I will not be using the cloud for that.

2- Regarding the document "Kinetis Thread Stack Demo Applications User's Guide".
Can you please be more specific? I tried the  MCUXpresso SDK Builder link but there is no such document there. I also tried the search engine for all combinations of that title with no luck. Kindly provide a direct link to the Kinetis Thread Stack Demo Applications User's Guide document.

[ishotjr]

Got mine yesterday - it just comes with the cable.  I have the dock however from an earlier contest for the prior generation Hexiwear device.  The device has a lot of built-in functionality though - I'm not sure if I'll end up needing the dock for my current project, since it's a wearable.

[rgrokett]

Just got mine.  The kit comes with only the device and cable.  

And nope, doesn't look like it supports WiFi.  Only other wireless option is a Sigfox (905mhz USA) transceiver which needs a dock ($25 + $25)...

All the built-in sensors are nice, but missing WiFi makes it not very useful for anything remote except to possibly a Smart Home hub that supports BLE. 

It is pretty obvious that the unit is really just for prototyping only and not specifically for long term use. I suspect the idea is to port completed designs over to the other NXP boards, using only the sensors needed for the particular function, for actual production products.