Hi,
Bei dieser Aktion, das Ziel war ein Payload über ATmega328 über
Transmitter Antenna zu schicken wenn ein Taster gedruckt wird, Payload
wird von Receiver Antenna empfangen zurück an ATmega gegeben, und LED
leuchtet so lange der Taster gedruckt ist.
Wichtige HW Details:
Fosc : 16MHz
Tx Antenna : C218D001C chip (315MHz)
Rx Antenna : C218D001C chip (315MHz)
USART mode : Asynchron,4800bps,8bit,No parity,1 stop
bit
Power Supply : 5V
ein ATMega für Tx Steuerung, und ein für Rx Steuerung.
Das funktioniert schon wenn beide Antennas so nah zueinander sind (setup
wie im Bild), wenn ich den Abstand zwischen Antenna vergrößere (bei 2m),
dann funktioniert es nicht mehr so richtig. Ich habe so ein paar
Debug-Ausgaben geschrieben in mein Application SW für Receiver, damit
beim Empfang eine gültige Payload, was ausgegeben werden kann.und das
kommt mal und mal nicht.
Ich habe ein bisschen recherchiert, und die Antennas haben schon ein
große Range von 500ft(ca. 150m). Ich habe versucht mit reduzierte baud
rates 2400bps aber das hat gar nicht funktioniert bei ATmega schon.
vielleicht hat einer oder der andere von euch damit beschäftigt der ein
Tipp geben konnte.
Aa B. schrieb:> Tx Antenna : C218D001C chip (315MHz)> Rx Antenna : C218D001C chip (315MHz)
Hoffentlich willst du deine Schaltung nicht in Deutschland betreiben ...
exRegTP schrieb:> Hoffentlich willst du deine Schaltung nicht in Deutschland betreiben ...
Oh nein! Warum ? Die sind doch Low Power. Ist das verboten? ich habe den
Ausgang gar nicht verstärkt oder so!
exRegTP schrieb:> Weil das Frequenzband bei 315MHz in Deutschland nicht für SRD> freigegeben ist.> https://www.bundesnetzagentur.de/SharedDocs/Downlo...
Okay, das wusste ich nicht, habe die Teile aber von Deutschland gekauft,
dürfen die auch nicht verkauft werden oder?
> Zu deinem Problem:> Wie sieht dein Übertragungsrahmen aus, insbesondere die Präambel? Du> kannst nicht direkt deinen Datenstrom über UART auf das Sendemodul geben> und hoffen, dass das beim Empfänger wieder genauso am Digitalausgang> raus kommt.
Ich hoffe ich habe Dich richtig verstanden, ich sende zuerst ein SYNC
byte, dann setze ein delay von 5ms, und erst dann schicke ich die
Adresse+Daten.
Aa B. schrieb:> Tx Antenna : C218D001C chip (315MHz)
Das ist keine "Antenna"
Aa B. schrieb:> Rx Antenna : C218D001C chip (315MHz)
Das ist auch keine "Antenna"
Sender und Empfänger können nicht die gleiche Schaltung sein.
Sender und Empfänger brauchen eine dezidierte Lambda/4 Antenne
um "auf Reichweite" funktionieren zu können. Ausserdem
brauchen die Antennen je eine Masse als Gegengewicht. Suche
Antenne Gegengewicht.
Sender und Empfänger brauchen keramische Abblock-Kondensatoren
und Elkos damit sie möglichst störungsfrei arbeiten können.
Aa B. schrieb:> Ich hoffe ich habe Dich richtig verstanden, ich sende zuerst ein SYNC> byte, dann setze ein delay von 5ms, und erst dann schicke ich die> Adresse+Daten.
Das ist ein Witz. Das wird nie zuverlässig funktionieren.
Du brauchst die sogenannte Radio Library, auch VirtualWire
genannt. Schau sie dir an dann wirst du sehen warum es nicht
so einfacht funktioniert.
Aa B. schrieb:> Ich hoffe ich habe Dich richtig verstanden, ich sende zuerst ein SYNC> byte, dann setze ein delay von 5ms, und erst dann schicke ich die> Adresse+Daten.
Gib dem Empfänger etwas mehr Zeit zum Einpegeln, i.e. sende
versuchsweise mal mehrere Sync Zeichen (0x55 o.ä., ohne Pausen
dazwischen). Danach muss eine Pause kommen, die etwas länger als ein
Zeichen (incl. Start/Parity/Stop) ist, also bei dir (10Bit) z.B. für
4800Bd >2,1ms und für 2400Bd >4,2ms.
Wozu soll die Pause zwischen Adresse und Daten gut sein?
Arduinoquäler schrieb:> Das ist ein Witz. Das wird nie zuverlässig funktionieren.> Du brauchst die sogenannte Radio Library, auch VirtualWire> genannt. Schau sie dir an dann wirst du sehen warum es nicht> so einfacht funktioniert.
Meinst Du damit dass die Payload erweitert werden muss oder? Wenn ja,
dass ist mir klar, mit Checksumme usw. Aber das war jetzt um überhaupt
erstmal zum Testen.
Ich habe die Arduino libraries gar nicht benutzt sondern C. beigefügt
ist mein Code für Transmission.
Aa B. schrieb:> Meinst Du damit dass die Payload erweitert werden muss oder?
Das klingt nach Starrsinn, sorry .... Ich habe VirtualWire Lib
gesagt und das meine ich auch.
Das läuft etwa so:
- Synchronfeld senden
- einsynchronisieren
- ID Übertragen
- Längeninformation übertragen
- Nutzdaten übertragen
- Checksumme übertragen
Mit einer UART Verbindung wirst du das nie erreichen da du die
Synchronisation zwischen den Bytes verlierst. Die ganze
Übertragung muss aber in einem synchron gesendeten Bitfeld
passieren da das Ganze sonst äusserst unzuverlässig wird.
exRegTP schrieb:> Gib dem Empfänger etwas mehr Zeit zum Einpegeln
Schöne Grüsse an Witzemacher. Du hast es auch nicht verstanden,
willst aber unbedingt mitreden.
Aa B. schrieb:> Okay, das wusste ich nicht, habe die Teile aber von Deutschland gekauft,> dürfen die auch nicht verkauft werden oder?
Verkauft werden darf es, aber benutzt werden nicht. Der Frequenzbereich
wird bei uns militärisch genutzt - also obacht.
Arduinoquäler schrieb:> Das ist ein Witz. ... Du brauchst die sogenannte Radio Library, ...
Dann erzähle mal. Eine Radio Library fällt nicht vom Himmel. Da haben
auch mal Leute drüber nachgedacht und verstanden, wie es funktioniert.
Ok, du vielleicht nicht, aber deshalb darf doch jeder mal selber
verstehen, wie das abläuft.
Der Empfänger sammelt erstmal nur das Rauschen der Welt auf und gibt
irgendwelchen Unfug aus. Dann fängt der Sender an, etwas zu übertragen
und der Empfänger pendelt sich mit seiner AGC usw. auf das empfangene
Sendesignal ein. Sobald das passiert ist, kommen saubere Bits aus dem
Empfänger, so wie sie der Sender rausschickt (solange keiner stört ;-)
Jetzt braut der Empfänger-UART eine Pause im Bitstrom, damit er mal ein
Startbit richtig als solches erkennen und sich damit synchronisieren
kann. Erst wenn das passiert ist, kommen aus dem Empfänger die Bytes so
raus, wie sie gesendet wurden. Und erst jetzt muss die Empfängersoftware
in den Bytes den Anfang eines Datentelegramms erkennen - vorher kann
beliebiger Unfug aus dem UART raus kommen. Es ist also nicht klug,
gleich nach dem Synch mit der Adresse zu kommen, weil der Empfänger dann
noch nicht wissen kann, dass dieses Byte die Adresse ist. Man braucht
zwischen Sync und Adresse noch eine Sequenz/Zeichen, dass dem Empfänger
den Anfang des Datentelegramms verkündet. Und erst dann geht es richtig
los.
Arduinoquäler schrieb:> Das klingt nach Starrsinn, sorry .... Ich habe VirtualWire Lib> gesagt und das meine ich auch.
Ich habe es so verstanden dass Du VirtualWire.h erwähnt hast weil Du
vielleicht angenommen hast dass die Code in Arduino Sprache geschrieben
ist. Wollte nicht stur sein oder sonst was, bin hier zum lernen. ;)
> Das läuft etwa so:>> - Synchronfeld senden> - einsynchronisieren> - ID Übertragen> - Längeninformation übertragen> - Nutzdaten übertragen> - Checksumme übertragen>> Mit einer UART Verbindung wirst du das nie erreichen da du die> Synchronisation zwischen den Bytes verlierst. Die ganze> Übertragung muss aber in einem synchron gesendeten Bitfeld> passieren da das Ganze sonst äusserst unzuverlässig wird.
Danke für den Tipp, würde ich mir die VirtualWire Lib anschauen.
Arduinoquäler schrieb:> Mit einer UART Verbindung wirst du das nie erreichen
Es gibt noch einen weiteren wichtigen Grund. Auf dem modulierten
HF-Signal sind alle Bytes redundand codiert (es sollte jedenfalls
so sein) sodass im Datenstrom nie mehr als 2 Nullen oder 2 Einsen
aufeinander folgen. Das geht mit UART und seinen Pausen zwischen-
drin auch nicht.
exRegTP schrieb:> Man braucht> zwischen Sync und Adresse noch eine Sequenz/Zeichen, dass dem Empfänger> den Anfang des Datentelegramms verkündet.
Du bist sehr klug.
Und was habe ich (auch dir) geschrieben?
Arduinoquäler schrieb:> Auf dem modulierten HF-Signal sind alle Bytes redundand codiert
Sagt wer?
Da bringst du wohl irgendwelche Protokollschichten übel durcheinander.
Redundanz zur Korrektur von Fehlern in einem Datenblock brauchst du für
FEC. Um Fehler zu erkennen, tuts eine geeignete Prüfsumme.
> (es sollte jedenfalls so sein) sodass im Datenstrom nie mehr als> 2 Nullen oder 2 Einsen aufeinander folgen.
Das ist in dieser Allgemeinheit UNFUG oder was meinst du, warum i.A.
Bitstuffing-Algorithmen nicht schon nach zwei gleichen Bits zuschlagen.
exRegTP schrieb:> Sagt wer?
Die VirtualWire Implementierung.
Das muss nicht so sein, aber die Erfahrung zeigt das dies
ein vernünftiger Ansatz ist um eine gesicherte Übertragung
für diese Funkmodule zu gewährleisten.
Die Komparatorschaltung des Empfängers wird es danken.
Arduinoquäler schrieb:> Das muss nicht so sein, aber die Erfahrung zeigt das dies> ein vernünftiger Ansatz ist um eine gesicherte Übertragung> für diese Funkmodule zu gewährleisten.
Bspw. beim Manchester-Code ist das so, wobei man damit auf der
Empfängerseite den Takt sehr gut rekonstruieren kann.
Der Preis ist eine Verdoppelung der erforderlichen Bandbreite.
Wie die Realität zeigt, geht es durchaus auch mit etwas längeren Folgen
von Nullen bzw. Einsen.
exRegTP schrieb:> Hoffentlich willst du deine Schaltung nicht in Deutschland betreiben ...
Man muss erst 1/3 aller Kommis lesen, bevor der vorauseilende Bremsklotz
von der Straße weg ist. Und immer wieder legt ihn jemand hin!! Leute,
macht euch doch mal frei im Kopf. Entspannt euch. Onk onk onk ...
exRegTP schrieb:> Gib dem Empfänger etwas mehr Zeit zum Einpegeln, i.e. sende> versuchsweise mal mehrere Sync Zeichen (0x55 o.ä., ohne Pausen> dazwischen). Danach muss eine Pause kommen, die etwas länger als ein> Zeichen (incl. Start/Parity/Stop) ist, also bei dir (10Bit) z.B. für> 4800Bd >2,1ms und für 2400Bd >4,2ms.
Okay, also mit ein SYNC hat es schon funktioniert aber wenn die beide
(Rx und Tx)Schaltungen auf dem selben Breadboard rein gesteckt sind. Ich
schicke jetzt mehr SYNCs, funktioniert beim größerem Abstand trotzdem
nicht.
> Wozu soll die Pause zwischen Adresse und Daten gut sein?
Ich habe in mein RxReceiver code einige Debug ausgaben, damit ich die
lesen kann beim Empfang, kann nicht schnell lesen. ;)
beigefügt ist ein Screenshot mit Debug ausgaben,wo Receiver Atmega
angeschlossen ist, ADDR_OK und LED_OFF werden ausgegeben solange der
Taster nicht gedruckt ist, ansonsten LED_ON.
Ich hätte gesagt eher ein HW problem weil es nicht für größere Abstände
klappt! nicht?
TorbenK schrieb:> exRegTP schrieb:>> Hoffentlich willst du deine Schaltung nicht in Deutschland betreiben ...>> Man muss erst 1/3 aller Kommis lesen, bevor der vorauseilende Bremsklotz> von der Straße weg ist. Und immer wieder legt ihn jemand hin!! Leute,> macht euch doch mal frei im Kopf. Entspannt euch. Onk onk onk ...
muss ich jetzt aufhören mit basteln wegen dieser Funk Schaltung? möchte
kein ärger haben.
Aa B. schrieb:> muss ich jetzt aufhören mit basteln wegen dieser Funk Schaltung? möchte> kein ärger haben.
Nein, erstmal nicht! Lass es mit diesen Modulen einfach sein und kauf
dir welche im 868MHz-Band.
Aa B. schrieb:> muss ich jetzt aufhören mit basteln wegen dieser Funk Schaltung? möchte> kein ärger haben.
Glaube nicht. Die Regierung hat doch keine Zeit. Muss sich um die 79
Millionen Nazis kümmern, die Autos mit Verbrennungsmotoren abschaffen
und Parkverbotsdelikte ahnden. Glaube nicht, dass da noch Platz für
Unwichtiges ist. Bastel ruhig weiter.
TorbenK schrieb:>> Glaube nicht. Die Regierung hat doch keine Zeit. Muss sich um die 79> Millionen Nazis kümmern, die Autos mit Verbrennungsmotoren abschaffen> und Parkverbotsdelikte ahnden. Glaube nicht, dass da noch Platz für> Unwichtiges ist. Bastel ruhig weiter.
Hahaa. :) warum 79 Millionen Nazis? Lol.... ich habe sowieso die 5V
Versorgung-Leitung weg genommen, von daher glaube ich auch nicht was
schlimmeres passieren wird.
Aa B. schrieb:> Okay, also mit ein SYNC hat es schon funktioniert aber wenn die beide> (Rx und Tx)Schaltungen auf dem selben Breadboard rein gesteckt sind.
Wenn man sieht wieviel Aufand der Erfinder der Vitualwire Lib
da hineingesteckt hat damit etwas vernüfntig funktioniert kann
man über diese hemdsärmeligen Versuche wirklich nur müde lächeln.
Und es bestätigt sich mein Verdacht des Starrsinns.
Arduinoquäler schrieb:> Das klingt nach Starrsinn, sorry ....
Auch andere ernstgemeinte Hinweise von jemand der sich
tatsächlich mit der Materie ausführlich befasst hat scheinen
nicht gelesen oder nicht verstanden oder ignoriert zu werden,
oder alles drei zusammen.
Arduinoquäler schrieb:> Sender und Empfänger brauchen eine dezidierte Lambda/4 Antenne> um "auf Reichweite" funktionieren zu können. Ausserdem> brauchen die Antennen je eine Masse als Gegengewicht. Suche> Antenne Gegengewicht.>> Sender und Empfänger brauchen keramische Abblock-Kondensatoren> und Elkos damit sie möglichst störungsfrei arbeiten können.
Aber bei soviel Starrsinn bleib ich wohl lieber draussen.
Arduinoquäler schrieb:> Auch andere ernstgemeinte Hinweise von jemand der sich> tatsächlich mit der Materie ausführlich befasst hat scheinen> nicht gelesen oder nicht verstanden oder ignoriert zu werden,> oder alles drei zusammen.>> Aber bei soviel Starrsinn bleib ich wohl lieber draussen.
Hey Buddy! Bleib dochmal locker. Ich muss sowieso erstmal abwarten weil
ich ein Antenna (Draht) auf Sender und Empfänger löten muss. Ich habe
mir die VirtualWire Protocol angeschaut, aber es gibt andere Wege auch
die nach Rome führen, VirtualWire ist sicherlich einer davon.
Du kannst auch theoretisch dein eigenen Protocol definieren und die
QuälerWire oder sonst was nennen. :) Ich wollte mit mein Tx-Program
erstmal schauen ob überhaupt was beim Empfänger ankommt. Das passiert
auch, allerdings nur für sehr kleine Abstände. Wenn dass für größere
abstände auch klappt, dann die nächste schritt wäre ein sinnvolle
Protocol zu definieren.
Klappt es viel besser mit Antenne auf der Sender und Empfänger Platine,
Tx Program habe ich auch bisschen erweitert, klappt jetzt mit 2-3m
Abstände. Also, delays muss man vorsichtig auswählen, ich habe jetzt bei
"Trial and Error" die delay Zahlen da programmiert, aber gibt es
bestimmt ein bessere Weg, die delays da rein zu programmieren. ;)
IMG_20170611_073357386.jpg
(200 KB)
