I'm currently designing a sensor network that will have small ATtiny85 probes that each have a temperature sensor, a barometer, and a humidity sensor. I think I will use these (http://goo.gl/TqaDjl) to communicate as they are low cost and don't need much range. Im not sure though how I will get the probes to communicate with the main control, as the transmitter transmits digitally and I will have +20 probes that all need to send data without signals overlapping or getting messed up every minute. I think the easiest way would be to time the probes so that they don't overlap in transmission but I'm not sure.
Questions:
-Is using RF the cheapest and best option for this system?
-How can I prevent communication overlapping?
-What is the easiest way to send data digitally from an arduino (or ATtiny85)?
I guess I'm late to the party, but I'll offer some insight into collision control with a ton of chattering transmitters on one link, a la 802.11. This is somewhat packetized.
If two transmitters try to transmit at the same time, you're bound to get a mangled mess of rotten bacon at the receivers.
A simplified version of WiFi-style collisions would be good. Basically, it uses preambles that can be detected, and for longer transmissions that have a higher chance of conflicting, it can use shorter request/clear to send packets.
While this is likely overkill, I'd go for preambles. Start by transmitting a steady stream of something recognizable, like in hex, 555533330f0f00ff which is basically alternating 1s and 0s but with changing frequency(0101, then 0011, then 00001111, and so on), a readily recognizable pattern that is unlikely to be given off by stray radiation or noise.
This pattern could undergo a shift so there's a finite set of other preambles that should be bitwise-shifted relative to the original.
If a transmitter detects this preamble, it should STOP and wait. If you limit all packets to a certain temporal length, collisions should not occur if you wait sufficient time between packets. If during the time of one packet, a preamble is heard, then your station should wait for the full length of the transmission(listening to its length and other header fields so it knows how long to wait). Once the packet is done, your station can transmit its preamble.
This is where the WiFi resemblance stops and simpler protocols take over.
Note that if 2 stations are waiting on a packet they can start their preambles almost simultaneously. To resolve this, each station should have a different zero bit flipped in its preamble. If it detects a 1 for that bit, it sees that there's another station preambling, and should back off.
Each station should wait a certain delay(up to you) after each packet so other stations can start their transmissions.
A few sketches of the communication patterns show that this is sufficient for your needs.
Now if it's a master-slave-style system as long as you only have one network it should be easier since there should only be one outstanding request that would involve a slave transmitting.
Those will be by far the cheapest method. As for the best method, there are a variety of choices much better, but more expensive. A network of Xbee modules comes to mind, but those are much more expensive than $1.25 a pair.
Using the RF modules is very do-able however. To prevent communication overlapping, put a RF transmitter and receiver on each sensor node and the main hub. The main hub can send "hey sensor1 give me your data", which gets broadcasted to all of the sensors. However, only sensor1 will realize "hey I am sensor 1, here is my data" which the hub will listen for. Then, the hub will go on and say "hey sensor2 send me your data" and so on and so forth.
I think your original approach may be best. The approach of putting a Tx and Rx on every device may be affordable, but I question if it will work. With 20 devices transmitting on the same frequency, which one will the receiver "hear". Most important, how will a device receive any remote transmitter's signal when its own transmitter is very close? Keep in mind: these are AM radios and will "send" a carrier even if not sending any data. Get a small number of transmitters before trying to go full scale.
To avoid the problem of receiving the one active transmitter among the soup of inactive transmitters, you want only 1 transmitter powered at 1 time. You would control Vcc to one transmitter, turn it on, send the burst of data, and then power it off.
-How can I prevent communication overlapping?
You can't -- you have to accept that there will be occasional overlaps. Add a CRC to the transmitted data so that the receiver can detect garbage.
The timing of the multiple transmitters is surely a project in itself. You surely don't want to run them all at the same transmission period. They may not collide at the beginning, but when two devices did drift together and start colliding, they would stay together and collide for a long time, until the clocks drifted apart.
I would start with something simple. For example with three devices, run the transmissions at 2000 ms, 2200 ms, 2400 ms period (use EEPROM to configure). That way, if a pair happens to collide at one data point, then next transmissions that pair will be 200 ms apart.
Related
For a project I need to make communicate in a CANBus network, ethernet network and with RS-232. I want to use one single MCU that will act as the main unit of CANBus start topology, Ethernet start topology and that MCU also will be transfering the RS232 data that comes to it to another device. Now I want to use high speed CAN which can be up to 1 Mbits per second. However,RS-232 is max 20 k baud. I wonder if it is doable with 1 MCU to handle 3 different communications ( CANBus, ethernet and RS-232). I am afraid of to get overrun with data at some point. I can buffer data short term if data comes in bursts that can be averaged out. For continuous data where I'll never be able to keep up, I'll need to discard messages, perhaps in a managed way. But I do not want to discard any data. So my question is: Would using 1 MCU for this case work? And are there any software tricks that would help me with this case? (Like giving CANBus a higher priority etc.)
Yes, this can be done with a single MCU. Even a simple MCU should easily be able to handle data rates of 1 Mbps. Most likely you want to use DMA enabled transfer so the CPU core will only need to act when the transmission of a chunk of data has completed.
The problem of being overrun by data due to the mismatch in data rate is a separate topic:
If the mismatch persists, no system can handle it, no matter how capable.
If the mismatch is temporary, it's just a function of the available buffer size.
So if the worst case you want to handle is 10s of incoming data at 1 Mbps (with an outgoing rate of 20kbps), then you will need 10s x (1Mbps - 20kps) = 9.8 Mbit = 1.225 MByte of buffer memory.
I am studying about wireless networks and specifically about the IEEE 802.11. I cannot understand whether two users in the different BSSs that work at the same frequency and the same location can interfere with each other or not. I know that a BSS is formed from users that use the same frequency but i cannot figure out if a nearby BSS can use the same frequency as one of its neighbours.
Thank you for your time!
802.11 WiFi uses CSMA/CA or "Carrier-Sense Multiple Access with Collision Avoidance" to ensure all stations using the same or similar frequency can co-operate.
Before sending onto the network, a station will listen to the medium to see if something else is using it, this is called "Clear Channel Assessment (CCA)".
If the station detects energy on the medium, it assumes it is being used and will backoff for a random (very short, in the order of microseconds) time and then try again. Eventually it should see the medium is clear and be able to proceed with its transmit.
Every unicast frame sent on a WiFi network is ACKnowledged as soon as it is received by the destination, with an ACK frame. If a station transmits and doesn't receive an ACK, it will retransmit. This avoids problems where something has decided to use the medium mid-way through a station transmitting a packet, causing corruption.
All this operates outside of the concept of a BSS, as regardless of which BSS a station is in, it still needs to play fair with all the other stations on the frequency in the same or other BSSes.
The net effect is you can have many stations in many BSSs all on the same channel happily co-habiting, the downside is performance degradation as it gets harder to get a clear channel, and the likelihood of corrupt frames and retransmits increases.
Context
We have got un unsteady transmission channel. Some packets may be lost.
Sending a single network packet in any direction (from A to B or from B to A) takes 3 seconds.
We allow a signal delay of 5 seconds, no more. So we have a 5-second buffer. We can use those 5 seconds however we want.
Currently we use only 80% of the transmission channel, so we have 1/4 more room to utilize.
The quality of the video cannot be worsened.
We need to use UDP.
Problem
We need to make the quality better. How to handle lost packets? We need to use UDP and handle those errors ourselves. How to do it then? How to make sure that not so many packets will be lost as currently (we can't guarantee 100%, so we only want it better), without retransmitting them? We can do everything, this is theory.
There are different logic's to handle these things.It depends on what application you are using. Are you doing real time video streaming? stringent requirements?
As you said you have a buffer, you can actually maintain a buffer for the packets and then send an acknowledgement for the lost packets (if you feel you can wait).
As this is video application, send acknowledgements only to the key frames. make sure that you have a key or I frame and then do interpolation at the rx side.
Look into something called forward error correction, fountain codes, luby codes. Here, you will encode the packets 1 and 2 and produce packet 3. If packet1 is lost, use packet3 and packet2 to get the packet1 back at the rx side. Basically you send redundant packets. Its little harsh on network but you get most of the data.
I am reading a book about networking, and it says that, in a circuit switching environment, the number of links and switches a signal has to go through before getting to destination does not affect the overall time it takes for all the signal to be received. On the other hand, in a packet switching scenario the number of links and switches does make a difference. I spent quite a bit of time trying to figure it out, but I can't seem to get it. Why is that?
To drastically over-simplify, effectively a circuit-switched environment has a direct line from the transmitter to the transmitted once a connection has been established; imagine an old-fashioned phone-call going through switchboards. Therefore the transmission time is the same regardless of hops (well, ignoring the physical time it takes the signal to move over the wire, which very small since it's moving at the speed of light).
In a packet-switched environment, there is no direct connection. A packet of data is sent from the transmitter to the first hop, which tries to calculate an open route to the destination. It then passes its data onto the next hop, which again has to calculate the next available hop, and so on. This takes time that linearly increases with the number of hops. Think sending a letter through the US postal system. It has to go from your house to a post office, then the post office to a local distribution center, then from the local distribution center to the national one, then from that to the recipient's local distribution center, then to the recipient's post office, then finally to their house.
The difference is that only one connection at a time per circuit can exist on a circuit-switched network; again, think phone line with someone using it to make a call. Whereas in a packet switched network many transmitters and receivers can be sending data at the same time; again, think many people sending/recieving letters.
I'm currently developing a small application for monitoring the power / current our solar collector is generating.
The array is connected to 3 inverters. Every inverter has a RS232 interface, transmitting one Line of information(its current status) every 10 seconds.
Since I want to do the monitoring using a device only having one serial port, I need to come up with a way to be able to read the data from all of the inverters in parallel.
I don't need to send anything to one of the inverters!
Is it possible to just connect 3 RS232 wires in parallel to one serial port? Collisions will be pretty unlikely since every inverter is transmitting only 64Byte / 10seconds ending with a newline, so I could check for variable line lengths to detect collisions.
I'm sort of chuckling at doomsday and wacky answers that so often pop up on stackoverflow...
But anyway, in years gone buy I have used paralleled RS-232 transmit lines using diodes and it can work fine for situations where collisions are unlikely. In one particular application I used this technique there were two input terminals where a user could key in simple commands to control the system (a specialized security system) and it was very unlikely that two people would be trying to control it at the same time from the two different terminals. Amazingly enough there are no problems with voltage levels with most RS-232A receivers I tested at the time and they tolerated the signal characteristics (no negative voltage) that result from the simple use of the diodes in series with the TXD signals. However, if I had to do this again I would likely add a simple pull-down resister and capacitor to ground with a diode between RXD and the cap in a sort of charge pump configuration or a pull-down to negative going handshake signal to ensure the "OR'd" input signal goes truly negative since the RS-232 spec defines +3 to -3v as invalid.
In any case, I would recommend not using this technique except in very specific, limited, and non-mission critical cases and would not use it in the case where you have multiple devices sending information at a programmed interval as in the case of the OP or where there is a software handshake.
In can be a simple solution to the problem of not enough serial input ports but only in a very limited set of environments.
No, you should NOT connect 3 serial output port in parallel. If you do that you are probably going to broke the RS232 output circuitry of your inverters.
You have 3 RS232 outputs, so you need 3 RS232 input, then you can manage these 3 input the way you like: maybe you can buffer the data from each input, and reoutput the data on a single RS232 output, to be connected to your monitoring device.... but you should add some code in the data flow to differentiate the data coming from the 3 inverters.
Maybe you can use some kind of IC that do the job for you, I'm not sure, but maybe that some IC that multiplex multiple RS232 input on a single RS232 output already exist.
Try this search: rs232 port input multiplexer on Google
Or, if the monitoring device is a Window computer, you can use 3 serial-to-usb converter: that will create 3 virtual COM port on your computer and you can read data from them with any software.
Update
About the hypothesis of securing the output circuitry using diods to block reentering current, I don't think it's going to work...
Many year have passed by since last time I've used an RS232 link at low level (so maybe I'm wrong) but I think that there is some kind of handshake going on between RS232 input and output port (speed to use, parity, stop bit...).
Each RS232 port have inputs and outputs signal, both for data and for transmission control, so your multiple RS232 outputs does have some input signals, and your single RS232 input does have some outputs.
This mean that your input monitoring RS323 port is going to try to make a handshake with 3 RS323 ports at the same time... and the 3 RS232 ports are probably going to respond at the same time... so I think it's not going to work.
Other than that if you place diodes on your output, you are going to loose 0.7v, I don't remember the tolerance on signal level of RS232, but maybe that 0.7v can be relevant.