How can I create groups in a ZigBee PRO network to multicast these groups from the coordinator?
I am using XBee s2 modules in API mode.
I want send only one multicast message that has multiple nodes as the destination; some kind of broadcast message but not for all devices.
I think that the 16-bit address is for this propose, but I can't change the 16-bit address.
Is there any functionality to create groups in ZigBee pro?
Using c# I was able to create a datagridview table with multiple xbee modules in it. Using their 64bit addresses and a column that I could use to group specific modules together (ie. group A, B, C, etc) I was able to loop through the table and communicate to a specific group.
From experience and based on the XBee ZB documentation, I would say that those modules do not currently support ZigBee Multicast Addressing. I searched that PDF for "multicast" and had zero matches (but 159 matches for broadcast).
Related
I have a raspberry pi connected with multiple i2c devices and want to be able to programmatically work out the type, manufacturer name, device name and/or description for each device on the i2c bus.
Is there any way to do this? Can it be done in python?
I can already get the ID numbers with python code the does essentially the same as i2cdetect, but it doesn't give any information that tells what each device is.
That means I have to manually dig through data sheets and then still have to disassemble the hardware and test with each individual device as the only one connected, to identify which device is at which ID, since some devices can be customized by altering their factory ID.
Putting it together in the first place was a huge job that I don't want to repeat, so I would rather have a way to identify each device programmatically.
Does anyone know how or if this can be done? Does i2c protocol lend any support for that?
Could it be done indirectly, ie. is it possible to power down or otherwise temporarily mute or disable an i2c compatible HAT while the Raspberry Pi is running and then rescan the i2c bus and identify which ID no longer shows up?
No, the I2C bus is not designed for this.
The only way to do something like this is to have the knowledge of the possible addresses for each type of device stored somewhere, together with a way of detecting whether it's really that particular device. Some devices (such as the BMP/BME sensor family) have a ID register that can be used for this, but others don't have that. There are even devices (such as displays) that don't even support reading any data from them.
I am still trying to understand DDS and its concepts.
I have a configuration where 2 laptops run dds based application. My environment does not permit multicast so I decided to go for peer to peer connection(unicast). To bring both the laptops in the same network, I connected them using ethernet cable (Not sure if it was necessary or not).
Now I did not change anything in the QoS i.e. i did not do any settings for unicasting. But now my applications are communicating with each other.
Question :
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
EDIT :
Configuration is as follows :
First laptop : Windows OS : Native DDS based application : Publisher : Multicast not allowed.
Second Laptop : Linux : ROS2 based subscriber : Multicast no problem
Out of the box, DDS is required to support Multicast and Unicast Discovery. Anonymous connections are handled through multicast. If you know the IP address of the recipient, you can manually configure those addresses into the unicast discovery list (each vendor will have their own way to name/process this list).
"Multicast is not permitted on our network", in most cases, means that your IT department has turned off multicast packet forwarding at the switch (or the switches) that define the fabric that is your network.
The as-shipped, standard-compliant DDS configuration, however, has no knowledge of this local policy (how could it?). If you haven't changed the configuration in line with your local policies, the DDS Participants are still going to try to connect via Multicast, because you haven't turned it off.
If the DDS-using machines are connected to the same hub, or to an unmanaged switch (defined here as one that your IT department doesn't care about, or is misconfigured), and the network topology does not cross a managed switch, and they are using the default configuration, and they find each other, then they are using Multicast anonymous discovery.
Figure out how to configure your DDS implementation, to add the unicast ip addresses of the machines that need to communicate. Because discovery is usually only needed in one direction (if A discovers B, then it is true that B has discovered A, assuming neither A nor B are configured to ignore the other[1]).
Once you have configured for unicast discovery, you can configure for no-multicast. If the machines are on IP hopping networks (WiFi, etc) it will be difficult unless the DDS implementation understands multipathing. Talk to the vendor to see if this is the case.
[1] DDS is nothing if not overly configurable.
How are the participants being discovered ? Multicasting ? as I did not do any settings for unicasting.
It is not possible for me to answer this question with complete certainty since you are using DDS as part of the ROS2 framework and I am not familiar with the exact details of how the two are set up to interact together. Having said that, from your description it does seem that the participants are indeed using multicast to discover each other.
The best way to get a conclusive answer is by sniffing the network -- assuming that you have the required privileges to do so. For example you can use Wireshark , which comes with an RTPS dissector that allows you to filter on RTPS messages. (RTPS is the name of the standardized DDS wire protocol.) Check out the destination address and see if you detect any addresses in the multicast range. You can do this while firing up a single DDS-based application. It will start announcing itself over the network immediately.
Was it necessary to bring them under one network i.e. connect with ethernet cable if I wanted to use unicasting ?
If you want to use unicasting, you will need to know IP addresses or host names of all peer nodes. As long as those peer nodes can reach each other over UDP, you are good to go. Often, but not always, ping will let you know whether this is the case. Firewalls are a typical cause of problems.
However, be aware that different types of network have their own specific properties that you might have to adjust your configuration to. Over WiFi for example, the likelihood of packets being dropped (especially with bursts of data) is much larger than when connecting nodes directly with a wire. DDS allows for tuning its protocol to deal with that.
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.
In Bluetooth, specifically 4.0 LE (if this changes anything), what is the way to send data both ways, from master to slave and from slave to master?
What kind of protocol is it better to design? Can you please provide an example of an application level protocol that is typically used in this scenario?
In this case, should the peripheral run two services, one used for sending data to the device and another to receive data from the device? (The "device" is the peripheral/slave).
The most forward way of doing this would be to define a custom service which defines the data types and fields and access you need as characteristics, and implement this on both the peripheral and central. If you are looking for a symmetric system, you can implement the same service on both sides. If there is differences in how the two devices access/send data, you can implement two different services, suiting your needs. Either way, you will need both the slave and master peripherals to support both GATT server and GATT client.
Depending on what you want to do, you could either push data using notifications (unconfirmed, you may miss updates on the receiving side) or indications (confirmed, the receiving side will have to acknowledge the push), or you could pull the data using read commands. You could also combine these in various ways, and you could implement access to different data in different ways in your service(s).
I recommend taking a look at the different Bluetooth Low Energy vendors' dev kits and APIs, as well as the different phone/tablet APIs and examples, depending on which platform you aim to develop on/ are familiar with.
I am writing a Linux device driver which supports multiple devices. I have a x8 PCIe card with 4 of these devices on it. Each runs through a PCIe switch and gets 2 PCIe lanes. Is there a way to have the driver write to multiple lanes at the same time? If so, how would I do this? I would think it should be possible since it is all on one PCIe slot, but I have no idea how this would be done from the driver.
PCIe doesn't work quite the way you think it does. The switch is not partitioning up the upstream x8 link into multiple x2 links -- it simply forwards traffic from one link to another. So what you will see is a x8 link to the switch, and then 4 x2 links from the switch to the downstream devices. However with a different switch and different downstream devices, it would be equally possible to (for example) have x8 links everywhere, ie a x8 link from the root port to the switch and x8 links from the switch to the downstream devices.
However, in your case you have a matched amount of bandwidth on both sides of the switch, so there should be no issue with devices competing for a limited amount of bandwidth. Your driver can talk to all the devices simultaneously as efficiently as if there were independent links.
It sounds like you're looking for PCIe multicast. This has no connection to the number of lanes, but would simply be a function of delivering a single write to multiple destinations as efficiently as possible. There is a standard for this, mostly intended for backplane uses, see: http://www.pcisig.com/developers/main/training_materials/get_document?doc_id=12f5c260ccf5e054366d4c96ee655fa6827db5b3
It looks like this is supported with a new PCI BAR type, where multiple devices would have the same mapped physical address range, and the switch would also be configured to know about this multicast range. But this all needs OS support, and I haven't found anything on the web to suggest that Linux has the pieces necessary to configure the devices to do all this.
Since your parent link has enough bandwidth to saturate all four child links, you don't have a throughput problem. The only thing you'd save with multicast is bandwidth from the memory subsystem. If you have a modern architecture, the amount you'd save would be in the noise.
In other words, don't worry about it. Treat your devices as independent (this will make for a cleaner driver, anyway) and get on with your project.