4 ms·

Wifi is problematic due to price and power. Wifi embeddable modules aren't cheap, non-wifi RF are available for peanuts (RFM, Nordic, ...). But you kinda have

by jmpe 13y ago

Wifi is problematic due to price and power. Wifi embeddable modules aren't cheap, non-wifi RF are available for peanuts (RFM, Nordic, ...). But you kinda have to reinvent the wheel: the content of the packets is normally limited to 32 bytes and you have to pick/design your meshing network approach. They come in all kinds of bandwidths (normally up to order 2Mbps) and for different unlicensed frequencies which you pick depending on scenario (indoor/outdoor), range and power availability (listening 24/7 won't work on batteries). But most IoT devices with these modules will keep their protocol closed. If you need internet connectivity you normally pick cheap RF modules for the web of thing modules and a central module with wifi/Ethernet to talk to the servers. Bluetooth... I hate that stuff. Zigbee ... I dislike it because most vendors sell it in a UART/RSxxx interface mode (I prefer SPI). Non-wifi RF: incredible variety of products. Wifi: just a few. Lastly: Power. Non-wifi RF can run on a small solar cell connected to a uC with 2kb code and 128 byte RAM. Wifi will need a mid-spec uC with a few dozen kb of code to run a minimal uIP stack. Won't run on a small solar cell or battery (e.g. your phone) for long.

dclara 13y ago
Very nice thoughts. I kind of agree with you on the common standard protocols, so I didn't count non-wifi RF in. I think my 2.4G wireless handset of the home phone or wireless mouse are examples. But even printers are using wifi now. I though Nest using wifi or 4G to talk to the smart phone, is that true? We definitely want to have it cheap enough. Printers are still expensive enough to bear with the wifi cost. The rest of the devices, such as coffee machine, clock, windows, etc. everything in home and office needs certain kind of wireless enabled sensor/receiver kind of attachment, cheap but connecting to the controller (either pc or smart phone or remote control) via internet. Pure RF connection cannot be called IoT, right? And it's not flexible, intelligent enough to be recognized from device to device. You solar powered energy is also a good point.
- jmpe 13y ago
  Nest is wifi, the second generation added 802.15.4 - but I never dealt with the product. Pure RF connection cannot be called IoT, right? You're correct. You always need a bridge to fill the gap between RF modules and the net. Such a device often adds functionality like buffering, keep logs, manage updates and provide a local webserver. Which is kind of a shame. The internet got part of its breakthrough because it became tech agnostic on the low layers. Token ring? Optical? Cable? twisted pair? no worries, you can hook it up. SDR could provide a solution in that field. But there's a good chance that patents/licences will be cumbersome, just like the current situation with wifi. BTW, if you're looking for a good wifi embeddable module: Carambola 2 by 8devices is a solid product. I recently built a WEP-wardriver with one and it took just an evening of scripting and soldering.
  - dclara 13y ago
    I got your point, very constructive. Here is my thought: 1. Bridge between the RF module and the internet If all the processing is done on the host pc side, leave the device only having the sensor to detect the state and being driven by the host pc, then it will be a lot easier to build the device itself, don't need that much functionalities. This should be the direction. 2. Transmission mechanism should not be a problem except the worrying about the wifi cost since it has all the necessary functionality built in with encode/decode, security and compression/decompression which becomes a heavy burden on the device side. But it should be easy to resolve by embedding a Linux kernel with the wifi stack. 3. SDR might be a solution to deal with various RF protocols, but do you think the performance will be compromised than using the hardware components? So all of the available or to be defined protocols and mechanisms can be tested out if the platform supports simple/thin devices. Your proposed embedding wifi module is a very good solution to meet this requirement. Do these products have FPGA or SoC with UART or SPI interface? If you are interested in further discussion, maybe we can take it offline. Shoot me an email at danmark.clara _at_ yahoo dot com.

by jmpe 13y ago

dclara 13y ago

Very nice thoughts. I kind of agree with you on the common standard protocols, so I didn't count non-wifi RF in. I think my 2.4G wireless handset of the home phone or wireless mouse are examples. But even printers are using wifi now. I though Nest using wifi or 4G to talk to the smart phone, is that true? We definitely want to have it cheap enough. Printers are still expensive enough to bear with the wifi cost. The rest of the devices, such as coffee machine, clock, windows, etc. everything in home and office needs certain kind of wireless enabled sensor/receiver kind of attachment, cheap but connecting to the controller (either pc or smart phone or remote control) via internet. Pure RF connection cannot be called IoT, right? And it's not flexible, intelligent enough to be recognized from device to device. You solar powered energy is also a good point.

jmpe 13y ago
Nest is wifi, the second generation added 802.15.4 - but I never dealt with the product. Pure RF connection cannot be called IoT, right? You're correct. You always need a bridge to fill the gap between RF modules and the net. Such a device often adds functionality like buffering, keep logs, manage updates and provide a local webserver. Which is kind of a shame. The internet got part of its breakthrough because it became tech agnostic on the low layers. Token ring? Optical? Cable? twisted pair? no worries, you can hook it up. SDR could provide a solution in that field. But there's a good chance that patents/licences will be cumbersome, just like the current situation with wifi. BTW, if you're looking for a good wifi embeddable module: Carambola 2 by 8devices is a solid product. I recently built a WEP-wardriver with one and it took just an evening of scripting and soldering.
- dclara 13y ago
  I got your point, very constructive. Here is my thought: 1. Bridge between the RF module and the internet If all the processing is done on the host pc side, leave the device only having the sensor to detect the state and being driven by the host pc, then it will be a lot easier to build the device itself, don't need that much functionalities. This should be the direction. 2. Transmission mechanism should not be a problem except the worrying about the wifi cost since it has all the necessary functionality built in with encode/decode, security and compression/decompression which becomes a heavy burden on the device side. But it should be easy to resolve by embedding a Linux kernel with the wifi stack. 3. SDR might be a solution to deal with various RF protocols, but do you think the performance will be compromised than using the hardware components? So all of the available or to be defined protocols and mechanisms can be tested out if the platform supports simple/thin devices. Your proposed embedding wifi module is a very good solution to meet this requirement. Do these products have FPGA or SoC with UART or SPI interface? If you are interested in further discussion, maybe we can take it offline. Shoot me an email at danmark.clara _at_ yahoo dot com.