I want wireless data transmission between microcontrollers. Of the three microcontrollers A,B and C , i need one to many connection in such a way that A have bidirectional communication with B and C but B and C need not communicate with each other. Will RF transcievers be helpful??
Yes, RF transceivers will be helpful implementing a wireless communications link. (I suppose you could use IR transceivers if your devices will have line of sight to each other.)
Are you asking how to direct the messages to the proper destination? If your data can be packetized then the answer is the same as for any other multi-drop network media. You add a header to the packet and put a destination address in the header. Nodes B and C may receive each other's transmissions but they will check the destination address, see that the message is addressed to A, and they will ignore those messages. Another possibility is that B and C could use different radio frequencies. Then they won't receive each other's transmissions. But in this case A will have to receive on two frequencies. Perhaps A could retune in order to communicate to the other node.
Update: If two of your devices transmit at the same time the transmissions may interfere and the receiver may not be able to receive either transmission. This issue is addressed with a channel access strategy. Here again, techniques used on wired networks also apply to wireless networks. One way to avoid collisions is for the transceiver to listen for a carrier signal or existing transmission before transmitting itself. This technique is called Carrier Sense Multiple Access (CSMA). If there is no signal then it is OK to transmit. But if their is an existing signal on the channel then the transceiver will hold off on its own transmission until the channel is clear. I'm familiar with the CC1101 transceiver and this functionality is built into the transceiver (although it may need to be enabled via configuration). Another way you could avoid collisions is with a master/slave or client/server communication strategy. For example, if B and C only transmit in response to requests from A then A can manage when each node transmits and ensure that two nodes don't transmit simultaneously. Other ways to avoid collisions include Time Division Multiple Access (TDMA) or Frequency Division Multiple Access (FDMA).
Related
I have some nodes with installed Xbee s2 on them. the zigbee modules configured as routers and coordinator, in zigbee mesh topology. I want to send data from each node to some other nodes.
question:
how I have to send data? here is a pseudo code that I have in mind. I want to know if there is any API in zigbee stack that I can use for this, and if I miss anything:
init_network;
fragment_data_to_frames;
fork();
if(process_is_parent)
for(i=0;iMbum_frames;i++){
send_frame(i);
wait(x miliseconds)// how much do I have to wait? or do I have to wait upon receiving ack,i.e. wait(ack(i));
}
}
if(process_is_child){
check_acknowledgment_packets();//does zigbee notify me that the frame is lost? or I have handle it by myself, e.g. by assuming frame is lost after specific time.
}
resend_lost_frames;
in the destination node, how I can retrieve the data? Do I have to handle it by myself by checking the sequence number and profile, and concatenating the packets? or Zigbee stack will do it for me.
XBee radio modules in API mode will generate a "Transmit Status" frame to indicate that a frame number was received by the remote module. There's no guarantee that the host on the other side successfully processed it, since it's a network-layer acknowledgement and not application-layer.
How much data are you planning to send? ZigBee was designed for low-speed, low-volume data transmission. If you're just using XBee modules, you can make use of their proprietary protocols (like transparent serial). For interoperability, you'll need to read up on the ZigBee Cluster Library and how it uses general commands and attributes to transfer information between nodes.
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
I have a simple xbee network operating where there are a bunch of slaves operating remotely and all talking to one master, who is connected to the server computer. That works no problem.
The slaves all send their ID as part of the packet and I'd like to have the master deliberately send an Ack after a delay. I'm trying to figure out how to do this efficiently and it seems that the only plausible way that doesn't involve reprogramming the master before each Ack is to send the Ack to all slaves and have them ignore the packet if it's not meant for them.
That solution is ok - I just can't figure out the command to use to do this. Is there some sort of Serial sendAll command? All of the devices are on the same ATID.
Typically in this situation, you would configure the master in API mode so you would get "Receive Explicit" frames with source addressing information, and could send with the "Transmit Explicit" frame type, and include addressing information in your frames.
If you use AT mode (transparent serial mode), then you're stuck having to change the DH and DL parameters on your coordinator every time you want to change who you send to. You should avoid using broadcast packets, since each one results in lots of network traffic (IIRC, each router will send the broadcast packet three times).
I do not know of a good XBee library on the Arduino, but it might be possible to port Digi's Open Source ANSI C XBee Host Library to that platform.
Does anyone know of a scheme whereby MODBUS addresses can be automatically set? In my situation I'll have a number of slaves power up and need some automatic way of assigning them addresses.
I know this is an old post, but I just came across this and thought I would give my answer just in case someone is attempting to do this now or in the future. If the goal is to assign a slave ID to a new slave (and you are developing the firmware for the slave devices), you can have the ID stored in a holding register that you can write a new ID to. This does require that:
You know the ID already. Maybe have all new slaves have a default ID, say ID = 1, so you know the ID beforehand.
You can only add one slave at a time and must change the ID before adding another slave to the network.
For example: Connect and power up the first slave device, which has a default ID of 1. Send a write command that will change the ID to 2 and send the master a response (using the slave ID of 1 in the response so it doesn’t timeout). Now the slave ID is 2. Next, add the next slave to the network, which it’s ID is 1. Now you have two slaves on the network with unique IDs. Just repeat as many of times that you need to.
Are you talking about SLAVE ID's? If so, that's just not going to happen... The SlaveID is vitally important for the Client to be able to address said slaves on the serial network. (RS485 serial network, presumably...).
So, there is no way to even send out a Modbus message and address it to SlaveID 1, and then somehow get that device to be SlaveID 1, because ALL of the devices would attempt to respond, in that case. Not to mention, there is NO method in Modbus to ASSIGN a Slave an ID... On the flip side of this...
Are you talking about performing some type of query to ask the slave devices which Modbus REGISTERS they have? Again, there is no Modbus way to do this, but with some code, you COULD query 40001, and if you get an error 2 back, then you know that register is not available. If you then loop through all of the registers, keeping track of which ones returned non-error, well--then you COULD do a form of "auto-configure", but... In all honesty? I would NOT recommend this, and I don't see a lot of value to even DOING this, because you not only have to know the REGISTER numbers, you have to know WHAT THE DATA IN THE REGISTER ACTUALLY MEANS!
What exactly are you trying to do anyway? Perhaps there is another way to accomplish this goal?
What you think you want: automatic Slave ID assignment in Modbus RTU.
What you actually want: constant, common Slave ID with Modbus TCP.
In a nutshell, all your Modbus Slave ID's get set to a fixed, common value and then you bridge them with a TCP stack that supports things like link-local addressing or DHCP. Then the TCP address assignment can be dynamically handled while preserving a constant SlaveID for each unit.
There are three broad options here depending on what hardware you already have:
There are commercial off-the-shelf devices (such as this) that can emulate TCP over RTU. I've not delved too deep into what they support and how well they work.
You could also add a whole ton of TCP to RTU bridges which will have built-in management for the TCP/IP layer and then use real Ethernet cabling. For a lot of devices, this could get expensive fast, but with Ethernet you have all sorts of bonus features like basically unlimited distance and improved CRCs. If you're looking to do this on the cheap, grab a dual-port Linux SBC (such as this or this) and throw mbusd (from here) on it.
If you have access to or are developing the firmware yourself, you could adapt something like uIP (simpler) or lwIP (faster) to communicate over RS-485 (UART). This would certainly be the cheapest option. Note that you should also have the ability to detect collisions on RS-485 to implement an IP stack correctly -- this involves echoing the receiver at all times and checking that the data-in and data-out match.
Can a machine send n network messages/packets (to n destinations), simultaneously? Is there a upper bound on level of parallelism and what affects network's parallelism.
More specific, say there are 2 packets and four event, s1, r1 and s2, r2 denotes send/receive packet 1 and send/receive packet 2. When we send asynchronously (like s1, s2...r1,r2) and synchronously (s1...r1,s2...,r2), does it matter? Could total latency be shorten in the case of asynchronous send.
Yes, they can. A NIC just transmits the frames the driver tells it to, and does it as soon as it can. NICs don't care about destinations.
Higher layers (e.g: TCP) are responsible for retransmissions, and have their own buffering. NICs usually can have several frames ready to be sent, but they stay little time in the NIC, as soon as the medium is free, and the NIC has transmitted a frame without collisions, it can take another frame ready for transmission.
You basically have three choices:
Point to point
Multicast
Broadcast
A point to point message goes from one source to one destination.
A multicast message goes from the source, to the router, and from there gets distributed to the multiple recipients. There are some relatively intelligent switches (usually called "layer 2+" or something on that order) that can handle multicasting as well, but your average "garden variety" switch usually can't/won't handle it.
A broadcast goes from the source to everything else on the local subnet. There are a cople of ways this can be done. Probably the most common is to send to the address 255.255.255.255. Broadcasting is supported directly by Ethernet, which has a "broadcast" MAC address of FF:FF:FF:FF:FF:FF.
Note that IPv6 no longer supports broadcasting, but does have an "all hosts" multicast group that's vaguely similar.