Last year I was playing with larger thread networks of 50+ devices on a single network. With Apple just releasing the Homepod with Thread, it has me thinking on the protocol again.
Apple will have a Thread network inside your home for Apple devices to communicate with each other.
If you bring another Thread network into the home, could the Homepod relay messages between your Thread devices?
My device #1 -> Apple Homepod -> My device #2
This would let you expand the range of your thread network.
Thread devices in one Thread network cannot communicate directly using IEEE 802.15.4 to devices in another Thread network. Each Thread network has its own security credentials that intentionally prevents devices outside the Thread network from participating.
That said, devices in different Thread networks can communicate using IPv6 via one or more Thread border routers. For example, it is possible to connect two different Thread networks to the same Wi-Fi network and have devices in each Thread network communicate end-to-end using IPv6.
In your example, you would need to add another Thread border router on the path.
Related
I do not understand the "RESUME" and "SUSPENDED" modes in the USB protocol (USB 2.0).
The USB 2.0 specification states:
All devices must suspend if bus activity has not been observed for the length of time specified in
Chapter 7. Attached devices must be prepared to suspend at any time they are powered, whether they have
been assigned a non-default address or are configured. Bus activity may cease due to the host entering a
suspend mode of its own.
The length of time specified in Chapter 7 is 3 frames. I don't understand what does mean "no bus activity": does it means no packets at all? does it means no packets sent to this device (and so if the device detects SOF packets then it should not enter SUSPENDED mode?)
In addition, a USB device shall also enter the Suspended state when the hub port
it is attached to is disabled. This is referred to as selective suspend.
How can a hub port be disabled? Is it the hub port itself that decides to do so (under which condition?) or is it the host that sends a command to the hub to do so (what is this command?)?
Is it correct to assume that for the device point of view, suspend and selective suspend are the same because in both cases the device only sees no bus activity?
A USB device exits suspend mode when there is bus activity. A USB device may also request the host to
exit suspend mode or selective suspend by using electrical signaling to indicate remote wakeup.
I do not understand this part. Why would a USB device requests the host to exit suspend mode or selective suspend because this is always the host that initiates transactions?
Thank you for your help.
Bus activity refers to any packet seen by the device.
I don't know all the details about selective suspend, but I believe that the operating system can tell when nothing is trying to use a USB device, and then tell the USB port to suspend the device to save power.
As for why a USB device would request for the host to exit suspend mode: have you ever noticed that you can wake up your computer from sleep by pressing a key on its keyboard or clicking a button on its mouse?
I would like to work on Weave but I noticed that Nest has open sourced Openthread instead. I would like to get my hands dirty with Openthread but if someone can answer these questions for me I would really appreciate that.
Is one preferred over the other for certain applications. If so, what are they?
Will devices running Openthread be directly compatible with ones running Weave?
Will these devices be able to communicate with Android devices as is or is future support in Android being planned?
What soc's or emulators can I test Openthread on?
Thanks in advance!
First Question
Succinctly, in terms of the OSI model:
Thread is a network technology that defines layer 2 (link-layer) and layer 3 (network-layer). Thread gives your embedded device IPv6 interface with some nifty capabilities, such as fault-tolerance, mesh networking, and low power consumption.
Weave is (for the most part) a layer 6 protocol, like CoAP or HTTP. It is a protocol that applications running on embedded devices can use to communicate with each other. It requires an IPv6 network interface, which could be provided by ethernet, Wi-Fi, or Thread.
It is important to differentiate OpenThread and Thread. OpenThread is an open-source implementation of the Thread standard.
Both technologies are designed to be used (albeit in different ways) in residential settings on the following loose categories of embedded devices:
Embedded devices that need to be able to reliably communicate with each other under adverse conditions, like a power outage or a fire.
Battery-operated embedded devices that need to be able to last for many years without changing or recharging the battery.
Sensor networks for monitoring things like temperature, motion, humidity, etc.
Second Question
The implication of your question is that the two technologies are mutually exclusive, or that they somehow solve similar problems. As the cute naming implies, Thread and Weave are complementary technologies. Weave needs a network interface to communicate with other devices, and Thread provides one.
Thread is like Wi-Fi in this way. Wi-Fi doesn't define the protocols that run over it. For example, just because a smart thermostat and a smart light switch have Wi-Fi radios doesn't mean that they can communicate with each other. It will be a similar situation with devices that have Thread-compatible radios.
Third Question
While there is no particular reason why you would not be able to use Thread or Weave (or both!) to communicate with devices running Android (or any other operating system), the the devil is in the details: there is no one-size-fits-all solution.
That being said, one way is to use IPv6 routing: Thread is based on IPv6, so if you have a Thread border router, you can allow devices on a Wi-Fi network to directly communicate (via IPv6) with devices on the Thread network.
Fourth Question
In addition to the POSIX simulator, the CC2538 is now an officially supported hardware platform. Support for Dialog's SmartBond™ SoC family of chips is currently provided directly by Dialog.
it might help to first better understand Thread and what it is trying to solve. Designed for the home, Thread is an IPv6 networking protocol built on open standards for low-power 802.15.4 mesh networks that can easily and securely connect hundreds of devices to each other and the cloud. This is different than Weave, which is an application protocol. Multiple application protocols can be developed on top of Thread, including Nest Weave. The Thread Group has a nice technical overview of Thread on their site.
Now to your specific questions:
You should use OpenThread if you're looking for an open source low-power, ipv6-based mesh networking protocol to build upon for your home connectivity application protocol
That really depends on what you mean. Any application protocol built on Thread should be compatible at the network layer with OpenThread, assuming they are targeting compatible versions of Thread.
One of the key design goals of Thread is being able to allow the Home Area Network to reliably communicate to the cloud through Border Routers. We demonstrated an Android app controlling a Thread end device from a Android. Here is a video.
You can find a CLI simulator in the /examples folder. At the time of this writing, OpenThread is still rather new - however we expect to see various SoCs officially supported from our silicon launch partners. Watch the repo for more updates.
I am working on indoor gps tracking and for this I need a wifi signal logger which can receive the signals from different smartphone(whose wifi is turned on) an send it to a remote server. I wanted to know, where I can get this kind of hardware, having capability to receive signals from different smartphones and log its signal strength and mac address in a remote server.
Please let me know the details.
Thank you in advance.
Pravin Prasad
In simple terms, Wifi clients(smartphones, notebooks etc.) send periodic Probe Request packets to actively seek wifi access points and Wifi APs(routers, gateways etc.) send periodic Beacon packets to advertise the presence of WLAN network.
You can use any wifi capable device like a smartphone or notebook to log the above packets.
Configure your wireless card in monitor mode.
Use a packet sniffer(for example, wireshark) to capture the traffic on the wireless interface or write your own with libpcap. You may filter on the packet type, source, destination etc.
A device has USB OTG support. Following are scenarios:
When a device is connected to a PC, the device acts as slave. (How does the device know it has to act as slave?)
When a device is connected to a printer, the device acts as master.
(How does the device know it has to act as master?)
What are the steps executed when a device is connected to OTG?
How to implement this mechanism (in brief)?
The exact behavior of USB OTG devices is described in the specification you can find at usb.org. There is a PDF inside the zip called USB_OTG.
The Host Negotiation Protocol in section 6 covers how two OTG devices decide which one is getting the embedded host. Basically this is archived by driving pull-up and pull-down resistors on the D+ line.
Note: When talking about USB the terms master/slave are not used. The master is called host and powers the bus whereas the slave is called device. In the case of OTG (in general, see specification for exceptions) both parts have the capability to be host or device. When the host was figured out by the Host Negotiation Protocol, this part becomes the so called embedded host.
In the two scenarios you mentioned the USB device is able to know whether to be a host or device by the cable. USB cables (non type-C) are not symmetrical. One side is host and the other is device. There is a pin on the connector called the ID pin which is floated on the device side and grounded on the host side. This allows the USB controller on each side to know which side of the cable it is connected to and thus which role (host or device) it should be when connected. These types of devices are called dual-role devices.
If you have a such a device, then you can plug it into a regular host (like your laptop) and it will act as a device. And you can plug it into a regular device (like a printer) and it will act as a host. This is all based on the cable.
If you plug two dual-role OTG devices to each other. Their initial roles are determined by the cable in the same way.
After the initial roles are determined, they can then swap roles from their initial cable-determined roles via the Host-Negotiation Protocol (HNP).
As far as implementing this. There is no brief way to explain it. Every controller is different and you would have to read the controller databook and programming model to implement all these procedures. As well as having a good understanding of the USB and OTG specs themselves.
A good place to start is http://usb.org where you can find all the specs.
my problem is to connect two identical devices with OTG-capable USB interfaces. Is this a simple giveaway or do I have to start and stop host- and device-mode manually with an arbitrary timing pattern so that eventually one is hit in device mode when the other one is an OTG host? From skimming over the APIs of several USB-stack producers it is unclear to me if symmetrical connections are possible at all.
regards,
slarti
PS: the device is an AVR32
The official cable has a "jumper" in the A end that tells the device it is plugged into to be the host. The OTG Supplement also includes a Host Negotiation Protocol which allows the two dual-role devices to interchange roles.