1x Receiver 2x Transmitter 433 MHz übertragen

Hallo,

Ich würde gerne Temperaturwerte von 2 Transmittern an einen Receiver senden und per Knopfdruck( 2 Knöpfe) zwischen den Werten von Transmitter 1 und Transmitter 2 wechseln.

Ich habe mir soweit ein bisschen Code zusammen gebastelt und es funktioniert alles mit einem Transmitter.
Der Empfänger funktioniert auch wunderbar. Nur weiss ich einfach nicht wie ich das mit 2 Transmittern anstellen soll.

Vielleicht könnte mir ja jemand helfen oder ein paar Ideen geben.

hier der Code vom Sender:

#include <DHT.h>
#include <VirtualWire.h>
#include <Adafruit_BMP085.h>

#define DHTPIN 2
#define DHTTYPE DHT22 
DHT dht(DHTPIN, DHTTYPE);
Adafruit_BMP085 bmp;


const char msg0[] = {","};
char msg1[10];
char msg2[10];
char msg3[10];

int tem = 0;
int hum = 0;
int druck = 0;

void setup() {
  Serial.begin(9600);
  dht.begin();
  bmp.begin();
  vw_setup(2000);
  vw_set_tx_pin(12);
}

void loop() {
  Read_Sensor1();
  Read_Sensor2();
  Read_Sensor3();
  Send_Data();
  delay(1000);
}

void Read_Sensor1() {
  tem = dht.readTemperature();
  itoa(tem, msg1, 10);
}

void Read_Sensor2() {
  hum = dht.readHumidity();                        
  itoa(hum, msg2, 10);                   
}

void Read_Sensor3() {
  druck = bmp.readPressure()/100;
  itoa(druck, msg3, 10);
}

void Send_Data() {

  strcat(msg1, msg0);
  strcat(msg1, msg2);
  strcat(msg1, msg0);
  strcat(msg1, msg3);
 
  Serial.println(msg1);
  vw_send((uint8_t *)msg1, strlen(msg1));
  vw_wait_tx();

  delay(5000);
}

und Empfänger:

#include <LiquidCrystal.h>

#include <VirtualWire.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

byte degreesymbol[8] = {
  B01100,
  B10010,
  B10010,
  B01100,
  B00000,
  B00000,
  B00000,
  B00000  
};


void setup()
{
 Serial.begin(9600);
 lcd.begin(16,2);                   
  lcd.createChar(1, degreesymbol);   

 vw_set_rx_pin(13);
 vw_setup(2000); 
 vw_rx_start();
 lcd.clear();      
}

void loop()
{
uint8_t buf[VW_MAX_MESSAGE_LEN];
uint8_t buflen = VW_MAX_MESSAGE_LEN;

 buflen = VW_MAX_MESSAGE_LEN;  
  lcd.setCursor(0,0);  
  
if (vw_get_message(buf, &buflen)) 
  {
    int i;
    lcd.print("Garten: ");
       for (i=0;i<2;i++)              
       {
        
         lcd.write(buf[i]);                   
       }  

         lcd.write(1);                       
        lcd.print("C"); 
         lcd.setCursor(0,1);
         
     for (i=2;i<3;i++){}          
    for (i=3;i<5;i++)             
    {
      lcd.write(buf[i]);                    
    }  
     lcd.print("% rF  ");      
   for (i=5;i<6;i++){ 
   }
   for (i=6;i<9;i++)
     {
      lcd.write(buf[i]);                   
   }
    lcd.print(" hPa");

  }
}

Ich habe mir überlegt diese Stelle zu ändern, zu msg2

  Serial.println(msg1);
  vw_send((uint8_t *)msg1, strlen(msg1));
  vw_wait_tx();

Jedoch habe ich momentan keinen Platz mehr auf meiner Platine um dies zu testen.

Das kannst du mit dem 2. Sender (Transmitter) genau so machen, nur du musst unbedingt darauf achten, dass diese Sender zu unterschiedlichen Zeiten senden. Sobald diese zu selben zeit senden, hast du ein Problem.

Die Unterscheidung der beiden Sender machst du über eine vorangestellte Nummer (ID), die im Empfänger zur Auswahl dient und wieder entfernt wird.

Vielleicht könnte mir ja jemand helfen oder ein paar Ideen geben.

[/quote]

Ein DHT22 liefert "Temperaturen in Zehntelgrad" und "Luftfeuchte in Zehntelprozent".
Aber diese Daten möchtest Du NICHT senden, oder?

Sondern Du möchtest nur "Temperatur in ganzen Grad" und "Luftfeuchte in ganzen Prozent" senden?

Warum willst Du zwischen der Messung und dem Anzeigen auf dem LCD die Zehntel wegrasieren?

A den 16 Stellen auf dem LCD kann das ja wohl nicht liegen.
Mit zwei Zeilen könntest Du ja im Endeffekt sogar zwei Datensätze auf Zehntel genau anzeigen:

Erste Zeile
"9.5°C 55.5%rF

Zweite Zeile:
"9.8°C 54.3%rF

Und wenn Du eine -Zwei-Sekunden-Wechselanzeige machst, dann könntet Du noch viel mehr anzeigen.

Zum Beispiel alle zwei Sekunden automatisch wechselnd Temperatur und relative Feuchte rF im Welchsel mit Luftdruck.
Wobei Du den Luftdrucl hoffentlich NUR in einem Innenraum mißt.
Ich habe hier im Forum auch schon Idiotenkram gesehen, ass Leute ihre Luftdrucksensoren im Außenbereich erfassen und ins Haus senden wollten, was zu katastrophalen Messergebnissen führt, da Luftdrucksensoren in erheblichem Maße auf Temperaturänderungen reagieren, und das wird durch Berücksichtigung von Kalibrierwerten beim Messvorgang nur zum Teil ausgeglichen und herausgerechnet.

Also Luftdruckwerte IMMER nur in halbwegs gleichmäßig temperierten Innenräumen erfassen, und NIMALS den Luftdrucl bei stark schwankenden Temperaturen im Außenbereich erfassen, sonst ist jede Genauigkeit dahin und Du kannst genau so gut raten, dass der Luftdruck 1013.25 hPa beträgt (langfristiger Durchschnitts-Mittelwert bei 15°C auf Meereshöhe.

jurs:
Vielleicht könnte mir ja jemand helfen oder ein paar Ideen geben.

Ein DHT22 liefert "Temperaturen in Zehntelgrad" und "Luftfeuchte in Zehntelprozent".
Aber diese Daten möchtest Du NICHT senden, oder?

Sondern Du möchtest nur "Temperatur in ganzen Grad" und "Luftfeuchte in ganzen Prozent" senden?

Warum willst Du zwischen der Messung und dem Anzeigen auf dem LCD die Zehntel wegrasieren?

A den 16 Stellen auf dem LCD kann das ja wohl nicht liegen.
Mit zwei Zeilen könntest Du ja im Endeffekt sogar zwei Datensätze auf Zehntel genau anzeigen:

Erste Zeile
"9.5°C 55.5%rF

Zweite Zeile:
"9.8°C 54.3%rF

Und wenn Du eine -Zwei-Sekunden-Wechselanzeige machst, dann könntet Du noch viel mehr anzeigen.

Zum Beispiel alle zwei Sekunden automatisch wechselnd Temperatur und relative Feuchte rF im Welchsel mit Luftdruck.
Wobei Du den Luftdrucl hoffentlich NUR in einem Innenraum mißt.
Ich habe hier im Forum auch schon Idiotenkram gesehen, ass Leute ihre Luftdrucksensoren im Außenbereich erfassen und ins Haus senden wollten, was zu katastrophalen Messergebnissen führt, da Luftdrucksensoren in erheblichem Maße auf Temperaturänderungen reagieren, und das wird durch Berücksichtigung von Kalibrierwerten beim Messvorgang nur zum Teil ausgeglichen und herausgerechnet.

Also Luftdruckwerte IMMER nur in halbwegs gleichmäßig temperierten Innenräumen erfassen, und NIMALS den Luftdrucl bei stark schwankenden Temperaturen im Außenbereich erfassen, sonst ist jede Genauigkeit dahin und Du kannst genau so gut raten, dass der Luftdruck 1013.25 hPa beträgt (langfristiger Durchschnitts-Mittelwert bei 15°C auf Meereshöhe.

Danke mit der 2 reihigen Wechselanzeige, da würde ich mir auf jeden Fall die Knöpfe ersparen. Ja der Druck wird auch nur in einem Raum gemessen, ob dies wirklich nötig ist, sei dahin gestellt.

Das mit float Werten hatte ich auch schon probiert, nur wird dann ab und zu, aus irgendeinem Grund, die erste Zahl vom Druck mit einem ":" ersetzt. Auch wenn ich den Druck als int stehen lasse, passiert das.
Der Druck

void Read_Sensor1() {
  tem = dht.readTemperature();
  dtostrf(tem,3,1, msg1);
}

void Read_Sensor2() {
  hum = dht.readHumidity();                        
  dtostrf(hum,3,1, msg2);                   
}

void Read_Sensor3() {
  druck = bmp.readPressure()/100;
  itoa(druck,msg3,10);
}

wenn ich den Druck auch mit dtostrf sende, kommen dort auch ":" und "P2" weiss ich nicht raus.

Dennoch ist dein Problem mit dem gleichzeitigen Senden.
Da solltest du über eine Art Synchronisation nachdenken.

Oder evtl. vom Empfänger ein Signal senden, wenn der Sensor seine Daten senden soll.
So löse ich ähnliche Probleme.

HotSystems:
Dennoch ist dein Problem mit dem gleichzeitigen Senden.
Da solltest du über eine Art Synchronisation nachdenken.

Man könnte unterschiedliche Senderhythmen nutzen. Wenn der eine Sender alle 20s. sendet und der andere alle 21s., dann kommt es höchstens alle 420s. zu einer Kollision. Da sich Druck und Temperatur nicht so wahnsinnig schnell ändern, kann man damit leben, dass man alle 7min mal auf den Wert warten muss.

Theseus:
Man könnte unterschiedliche Senderhythmen nutzen. Wenn der eine Sender alle 20s. sendet und der andere alle 21s., dann kommt es höchstens alle 420s. zu einer Kollision. Da sich Druck und Temperatur nicht so wahnsinnig schnell ändern, kann man damit leben, dass man alle 7min mal auf den Wert warten muss.

Genau das ist auch mein Gedanke gewesen, nur leider wurde bisher nichts über die Sendehäufigkeit bzw. deren Pausen gesagt.

Die Zeiten waren nur Beispiele.

mauer:
Das mit float Werten hatte ich auch schon probiert, nur wird dann ab und zu, aus irgendeinem Grund, die erste Zahl vom Druck mit einem ":" ersetzt. Auch wenn ich den Druck als int stehen lasse, passiert das.
Der Druck

Du sendest viel zu kompliziert, mit Deinen romanartigen Messages.

Lasse einfach jeden Deiner Sender ein Array von vier int Werten senden:

int message[4];

dabei sendest Du als message[0] die Kanal-ID, also entweder 1 oder 2, je nach Sender
als message[1] die Temperatur in Zehntelgrad als Integer , z.B. 203 ür 20.3°C
als message[2] die Luftfeuche in Zehntelprozent(als Integer,z..B. 543 für 54.3%rF
als message[3] den Luftdruck in Zehntel Hektopascal als Integer, z.b. 10158 für 1015.8 hPa
Und fertig ist die Laube.

Und der Empfänger kann beim Empfangen der Message direkt sehen, von welchem Sender ein Funktelegramm empfangen wurde, einfach indem er in message[0] reinschaut und dort entwede eine 1(von Sender-1) oder 2)vonSender-2) findet.

Und die einzige Stelle im Programm, an der die Werte formatiert weden bauchen, ist vor der LCD-Ausgabe.

Hast du mal drüber nachgedacht, in den gesendeten Daten am Anfang eine eindeutige ID wie z.b. "1" für Sender1 oder "2" für Sender2 mit zu senden, und das im Receiver mit einer if z.b. abzufragen?

So habe ich das bei meinen 433MHz, und 2,4GHz Projekten realisiert.

Das beide in der Absolut selben Millisekunde senden, und dass beide Daten absolut auf die ms gleichzeitig ankommen, ist absolut unrealistisch.

PS: Neuer account, der alte "meisterq" ist nicht mehr nutzbar. Support meldet sich auch nicht seit des Forumupdates.

meister_q:
Das beide in der Absolut selben Millisekunde senden, und dass beide Daten absolut auf die ms gleichzeitig ankommen, ist absolut unrealistisch.

Man soll niemals nie sagen. :wink:

PS: Neuer account, der alte "meisterq" ist nicht mehr nutzbar. Support meldet sich auch nicht seit des Forumupdates.

Den "meisterQ" gibt es aber noch. Hättest dir nur ein neues Passwort zusenden lassen sollen.

HotSystems:
Man soll niemals nie sagen. :wink:

Den "meisterQ" gibt es aber noch. Hättest dir nur ein neues Passwort zusenden lassen sollen.

Nun, wie oft wird es vorkommen, dass im selben Programmcycle die Daten von beiden Sendern ankommen?

Hab schon mehrfach neue Passwörter zusenden lassen, sobald ich mich dann einlogge und mein Passwort ändere, kommt Passwort/Username invalid, selbst wenn ich das Passwort was ich zugesendet bekomme benutze, sagt er invalid. Es funktioniert immer nur bis zum link in der Email, alles darüber hinnaus sagt er invalid.

meister_q:
Nun, wie oft wird es vorkommen, dass im selben Programmcycle die Daten von beiden Sendern ankommen?

Brauchen wir nicht drüber diskutieren, im Hobbybereich eher selten.
Da wir den kompletten Sketch und das gewünschte Verhalten nicht kennen, macht es auch keinen Sinn.

Dennoch gehe ich bei meinen Projekten auf die sichere Seite und empfehle es auch so.
Was jeweils draus gemacht wird, steht auf einem anderen Blatt.

Da es hier eh nicht "sicherheitsrelevant" ist, sollte es auch nicht kritisch sein.

meister_q:
Das beide in der Absolut selben Millisekunde senden, und dass beide Daten absolut auf die ms gleichzeitig ankommen, ist absolut unrealistisch.

Wenn beide gleichzeitig senden, kommen die Daten gleichzeitig an. Damit das nicht passiert müssten die Sender einige 100km auseinander sein.

Laufen beide Sender mit minimal unterschiedlichem Takt, kommt es irgendwann zu Kollisionen, die länger anhalten können, bis der Drift wieder so groß ist, dass sich die Sendezeitpunkte ausreichend unterscheiden.
Angenommen eine Nachricht dauert 50ms. Beide Sender laufen pro Tag 1s auseinander und wir senden alle 10s., dann haben wir im Schnitt alle 10Tage eine Kollision, die über ca. 140min anhält. Sendet ein Sender alle 10s und einer alle 11s, dann geht während dieser 140min nur alle rund 2min eine Nachricht durch die Kollision verloren.

Werden die Controller den auch zur Exakt selben Millisekunde gestartet?

Werden die Transmitter via Atomuhr auf die letzte Millisekunde genau synchronisiert?

Hab ich im Thread jetzt nich raus lesen können.

@Hotsystem: Haste recht.

@Theseus: Laufen also beide Controller auf den Cycle genau?

meister_q:
@Theseus: Laufen also beide Controller auf den Cycle genau?

Eben nicht. Durch Bauteiltoleranzen laufen die Sender garantiert minimal unterschiedlich schnell. Dadurch laufen die beiden Sender in meinem Beispiel pro Stunde um ca. 41ms auseinander. Dadurch kommt es bei einem System, was längere Zeit läuft, zwangsläufig irgendwann zu Kollisionen. Bei dem minimalen Drift dauert es über zwei Stunden, bis wieder beide wieder ausreichend Zeitabstand haben.

Die Frage ist dann noch, wie relevant ist das den?

Wie oft kommt das den am Tag / in der Woche / im Monat vor?

Ist es den Lebenswichtig, dass beide Daten keinesfalls zur selben Zeit ankommen dürfen, oder handelt es sich einfach um 2 Temperatursensoren die "zum spass" senden?

Theseus:
Wenn beide gleichzeitig senden, kommen die Daten gleichzeitig an. Damit das nicht passiert müssten die Sender einige 100km auseinander sein.

@Theseus

Ich bin ganz deiner Meinung, nur warum zitierst du mich ?
Der Text stammt nicht von mir.
Allerdings reichen in dem Fall einige 100 Meter.

HotSystems:
Ich bin ganz deiner Meinung, nur warum zitierst du mich ?

Da ist was beim zitieren schiefgelaufen. Ich habe es korrigiert.

Das Licht legt in einer Millisekunde 300km zurück. Also braucht es mehrere 100km, damit die zeitgleich abgesendeten Signale nicht in der selben Millisekunde ankommen.

Es wäre schön, wenn sich der Threadersteller mit Angaben zu Senderhythmen und Laufzeiten der Schaltung meldet, damit wir nicht nur herum spekulieren können und wir produktiv weiter diskutieren können.

Theseus:
Das Licht legt in einer Millisekunde 300km zurück. Also braucht es mehrere 100km, damit die zeitgleich abgesendeten Signale nicht in der selben Millisekunde ankommen.

Ok, so hatte ich das nicht verstanden.
Ich habe es nur auf die gegenseitige Störung bezogen.