Hello everybody,
I have a sensor which should be connected from Tx to the Arduino's Rx. The output is something like this: @P;26.6;F;037.2;52 . I will receive the output every 3.5 seconds. The problem is that I need 9 sensors, but I obviously don't have 9 Rx ports, so I need a multiplexer. But what is the best way to make a multiplexer or is it a better solution to make 9 software serial ports?
Thanks for answering
Kind Regards
You can make SoftwareSerials but you can only listen to a single port at a time.
What is the sensor EXACTLY? And how is the sensor triggered to output something in the first place?
It's a temperature + relative humidity sensor. The sensor will automatically send it every 3.5 seconds, i think it's pre-programmed, because i don't need to request the datastring
oliviervl123:
It's a temperature + relative humidity sensor. The sensor will automatically send it every 3.5 seconds, i think it's pre-programmed, because i don't need to request the datastring
Then you have a big problem because multiplexer or not ( - a multiplexer is nothing more than a switch), you can only listen to one thing at a time with one serial input. 
Paul__B:
Then you have a big problem because multiplexer or not ( - a multiplexer is nothing more than a switch), you can only listen to one thing at a time with one serial input.
So it's not possible to make a multiplexer in any possible way? Which means I can't finish my project?
But isn't it possible to listen to one thing at the time and then switch to the other input? I don't need all the information at once...
oliviervl123:
But isn't it possible to listen to one thing at the time and then switch to the other input? I don't need all the information at once...
Certainly you can listen to one thing at the time and then switch to the other input with a digital or analog (74HC4051) multiplexer, but
Paul__B:
Certainly you can listen to one thing at the time and then switch to the other input with a digital or analog (74HC4051) multiplexer, but
- You will completely miss all the information the other inputs are supplying, which likely does not matter but
- You will frequently switch to a given source part-way through its transmission and must realise this and ignore the partial information. Then wait for the next packet.
Hmmm, does a Raspberry Pi have the same problem? Never worked with a Raspberry before, but I want it to work
oliviervl123:
Hmmm, does a Raspberry Pi have the same problem? Never worked with a Raspberry before, but I want it to work
This has nothing to do with a Raspberry Pi or an Arduino, or a PC, iPhone or Cray.
It is just a statement about serial communication.
Paul__B:
This has nothing to do with a Raspberry Pi or an Arduino, or a PC, iPhone or Cray.It is just a statement about serial communication.
So this theoretically means that it won't work, no matter how?
oliviervl123:
So this theoretically means that it won't work, no matter how?
Correct.
Unless you get some I2C serial port expanders, you get two per chip with a 64 byte buffer in each port. These are only surface mount devices.
Grumpy_Mike:
Correct.
Unless you get some I2C serial port expanders, you get two per chip with a 64 byte buffer in each port. These are only surface mount devices.
I never worked with I2C, could you provide me with some more information about that?
But do you have more specification about that sensor? Maybe you can control it...
For I2C, see the Wire examples in the IDE.
septillion:
But do you have more specification about that sensor? Maybe you can control it...For I2C, see the Wire examples in the IDE.
I have some specifications, but they only contain information about the deviation and stuff like that and I took a closer look, but I can't find any information about controlling the times etc.
But you have 9 of them but no type or buyers link...
What is the serial baud rate?
What are they measuring the temp/humidity of? Air in a room or outdoors? If so, that does not change very quickly, so it's probably not important to catch every message. Even if you use a multiplexer, you can probably still catch two readings per minute from each sensor. For sensing temp/humidity in a room, one reading every 5 to 15 mins is normally fast enough.
As it seems you can’t use google, the chip you want is the SC16IS752 for the I2C bus or the SC16IS762 for an SPI interface, each chip will give you two UARTs.
But I think using such a chip is beyond your skill level at the moment, and you should take the advice here of sticking to a small number of samples with a multiplexed input. Even so that seems to be pushing the sort of thing you are capable of.
Here's another potential idea.
The message you described in the OP appears to be around 200 bits long (18 characters X 11 or 12 bits, assuming some start/stop/parity bits). At 9,600 baud, that will take approximately 20ms to transmit.
9 devices transmitting for 20ms every 30s means only a small chance of the messages overlapping. So perhaps you could feed all 9 signals into the RX pin at the same time, using a 9-input OR gate. Occasionally they will overlap and you will get a corrupted message that must be discarded. But most of the time they will not overlap and be received correctly.
The trick then would be how to figure out which of the 9 sensors sent the message. Is there some part of the message which identifies which sensor it came from? If not, 9 Arduino pins could perhaps be used to sense which line the incoming message came from.
Or switch the power to the sensor on one at a time, get the data and then turn it off and get the next one. Best use a multiplexer as well so an unpowered sensor does not get a signal from the active sensor.
septillion:
But you have 9 of them but no type or buyers link...
I'll send a datasheet tomorrow
PaulRB:
What is the serial baud rate?What are they measuring the temp/humidity of? Air in a room or outdoors? If so, that does not change very quickly, so it's probably not important to catch every message. Even if you use a multiplexer, you can probably still catch two readings per minute from each sensor. For sensing temp/humidity in a room, one reading every 5 to 15 mins is normally fast enough.
The baudrate is 9600
PaulRB:
Here's another potential idea.The message you described in the OP appears to be around 200 bits long (18 characters X 11 or 12 bits, assuming some start/stop/parity bits). At 9,600 baud, that will take approximately 20ms to transmit.
9 devices transmitting for 20ms every 30s means only a small chance of the messages overlapping. So perhaps you could feed all 9 signals into the RX pin at the same time, using a 9-input OR gate. Occasionally they will overlap and you will get a corrupted message that must be discarded. But most of the time they will not overlap and be received correctly.
The trick then would be how to figure out which of the 9 sensors sent the message. Is there some part of the message which identifies which sensor it came from? If not, 9 Arduino pins could perhaps be used to sense which line the incoming message came from.
I can identify from which sensor the message came from
oliviervl123:
I can identify from which sensor the message came from
PaulRB:
9 Arduino pins could perhaps be used to sense which line the incoming message came from.
That seemed at first like a strange question. But perhaps I can guess what confused you about my previous answer. The 9 Arduino pins would be connected to the 9 lines from the 9 sensors, before they go into the 9 input OR gate. So just before the data was received on the RX line, the Arduino could detect some activity on one of the 9 lines and know which of the 9 sensors it came from. Hopefully that makes things clearer.