I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
Related
I am creating a REDHAWK device that outputs either 16 bit signed complex samples, or VITA49 packets. I want the device to be told which output type it should provide when it is allocated.
How should I go about this?
Should I just add a simple property to the front_end_tuner_allocation struct?
Some other recommended approach.
Is there an example that I might look at?
ANSWER
I was able to speak with an experienced REDHAWK developer.
Apparently in situations where the device is capable of producing different data flows then separate Device node specifications should be created. This means that the output port to be used will be dictated when the device is started and should not be configured at run time.
This actually makes sense given the life-cycle of the device and the component receiving the data.
This is how I rationalize it, the component won't be able to control the device until the allocate-capacity is performed. So there would be no way for the component/waveform to setup the device ahead of time.
As I understand it, Bluetooth Low Energy communication can be established with or without pairing. This is in the context of mobile development, Android more specifically but I believe iOS is more or less the same.
Are there instances where one would choose one over the other? And what would be the purpose? What is technically considered paired communication and what is considered unpaired communication?
I've dabbled around for a bit on the differences and have even made a few demo only apps related to BLE but I haven't found a clear explanation if what I am doing is actually considered paired or not.
Edit:
The reason I ask the question is that I believe I am looking to encrypt unpaired BLE connections. In some cases, and essentially my main use case, a mobile device may want to connect to several different peripherals randomly at different times throughout the day and the process of physically accepting a pair request seems unnecessary and quite time consuming. By 'randomly' I mean I am walking by one if I have a dozen scattered around my apartment and I personally don't know exactly which one without physically checking. I don't what to walk in the room the first time and have to manually pair each device, that would be insane if I had 100 devices. Note that these devices don't necessarily have to be connected at the same time, but could. Also note that I understand this isn't generally the main use case of the typical peripheral to mobile use case.
Here are a few differences:
If you bond the devices, the link will become encrypted, so it becomes more secure. So "paired" communication basically means the link is encrypted plus the device "knows" what it talks to.
The remote device also learns your phone's IRK (identity resolving key), which can be used to identify the phone later on. By default, the phone rotates the Bluetooth Device Address every 15 minutes or so. Without knowing the IRK, the peripheral can't identify the phone.
A good thing if the devices are bonded, is that the GATT db of the remote device gets cached, which means upon next connection, you don't have to wait a long time for service discovery to complete.
On Android, connecting by Bluetooth Device Address without first scanning is broken since the API lacks the "address type" bit (public/random address). If Android "guesses" wrong, you will connect to the wrong device and therefore fail. However if devices are bonded, the address type is stored and looked up based upon Bluetooth Device Address, which makes it work as expected. So if you plan to automatically connect to your peripherals in the background upon boot for example, it's a good idea to bond the devices.
A small detail is that Client Characteristic Configuration Descriptor values should also be stored by the GATT server and restored once the bonded device reconnects so it doesn't have to rewrite the descriptor value.
Some Bluetooth profiles needs bonding, for example HID (at least on iOS and Android).
We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "
I am working on a project where I need to attach a sensor to the computer like laser sensor or an infrared sensor, to use in a foul line detection. Basically the idea is, if someone steps on the foul line, the laser or infrared will be blocked by person's foot, and the laser/infrared won't be received by the receiver, causing the sensor to send a signal to the computer.
The problem is, I don't know where to start something like this. How would I go about attaching a sensor to a normal computer (like a normal PC that we use)? If someone could direct me into a direction or has any inputs, that would be really appreciated. Thanks a lot!
You may want to look at Arduino (http://www.arduino.cc/). It is an open-source microcontroller that can be used along with a computer and is designed to be hooked up to various types of sensors. It also has an extremely helpful, active support community.
There are several approaches to the task of bringing the sensor signal into a PC (to take advantage of PC's computing power, good user interface, connectivity to the web).
Look for integrated sensors that have an interface for attaching to a PC (RS-232, USB, Ethernet). For example, you may find something useful by googling photodetector USB.
There are I/O (input/output) devices for PC. They have analog and digital inputs and outputs. Look up LabJack, National Instruments USB-6008 and dozen other types of commercial USB I/O boxes.
Connect sensors to a microcontroller (uC), then connect uC to the PC through a USB or RS-232 or Bluetooth (the list goes on). This involves more hardware. You'll need to write firmware for the microcontroller too.
Obviously, which approach to choose depends on your skills (or willingness to acquire new ones), timing, budget, team structure (if it's a team effort).
You could use a photo-transistor and a Yocto-Knob. The Yocto-knob is an USB device able to quickly detect resistivity changes, you just have to connect the photo-transistor to it. Here is an application which looks pretty similar to yours: they use a light barrier to detect and photograph a fast object:
http://www.yoctopuce.com/EN/article/how-to-drive-a-camera-shutter-automatically