Hallo, Ich habe ein DALI-Device realisiert. Nun habe ich gelesen, dass ein DALI-Device eine Baudrate von 1080 Baud bis 1320 Baud als korrekt einstufen muss. Da alle getesteten Control-Devices aber immer eine Baudrate von fast genau 1200 Baud lieferten, konnte ich diese Toleranz nicht prüfen. Da ich aber unbedingt normkonform sein will, muss ich diese Toleranz auch testen. Hat irgendwer eine Idee wie ich das bewerkstelligen könnte? mfg
Gast
#1578442
Eine 8Bit Uart kann theoretisch nur mit Signalen klarkommen, die maximal 0.5* 1/(8Bit+Spartbit+Stoppbit) = 5% Abweichung in der Baudrate haben. (0.5 deshalb, wenn man davon ausgeht, dass in der Mitte des Bits gesampelt wird. Deine Anwendung fordert 11.1% Fehler.
Andreas Posch schrieb: > Hat irgendwer eine Idee wie ich das bewerkstelligen könnte? Funktionsgenerator als Taktquelle für dein DALI-Device? Dann kannst du deine Empfangs-Baudrate relativ zur Sende-BR ändern. Nachdem der Beschreibung leider nicht zu entnehmen ist, welcher uC oder was auch immer in diesem DALI-Device verbaut ist und was das Ding tut, kann nicht mehr zum Thema gesagt werden... EDIT: > Eine 8Bit Uart kann theoretisch nur mit Signalen klarkommen, die maximal > 0.5* 1/(8Bit+Spartbit+Stoppbit) = 5% Abweichung in der Baudrate haben. Man kann die Baudrate ohne weiteres ausmessen und das Timing entsprechend anpassen. 1200, 2400, 9600 usw. sind keine Naturkonstanten... :-o
@Berner: Ich arbeite auch nicht mit der UART, sondern hab die Kommunikation selbst implementiert. Funktioniert einwandfrei! @Lothar: Ich verwende einen ATMega328p bei 20MHz. Das Ding folgt einfach den Befehlen lt. DALI DeviceType 0. lg
> Ich verwende einen ATMega328p bei 20MHz.
Also: FG als Taktquelle anschliessen und eine Frequenz von 18MHz
einstellen, dann hast du relativ die Baudrate des Control-Devices um 10%
erhöht. Das selbe mit 22MHz, dann ist dein Control-Device relativ um 10%
zu langsam (Das Übertakten dürfte der uC anstandslos mitmachen).
Man kann doch den internen R/C-Generator zur Laufzeit verändern. Da nimmste einen Uhrenquarz an TOSC1 und TOSC2 und misst über Timer2 den Controllerspeed um 8MHz herum und verstellst OSCCAL mit den Werten, die die von Dir gewünschte Abweichung ergeben. Damit kannst Du auch Sweeps programmieren.
@Travel Rec: Irgendwie hab ich das nicht ganz verstanden. Wozu brauch ich einen Uhrenquarz an den TOSC-Pins. Kannst du mir das ein bisschen genauer erklären, bitte? Das mit dem Frequenzgenerator fällt leider auch aus - meiner schafft nur max. 5MHz. Ich möchte das ganze aber gerne bei 20MHz testen, da meine ganzen Einstellungen auf dieser Frequenz basieren. lg
Andreas Posch schrieb: > Irgendwie hab ich das nicht ganz verstanden. Wozu brauch ich einen > Uhrenquarz an den TOSC-Pins. Kannst du mir das ein bisschen genauer > erklären, bitte? RC-Oszillator als Hauptoszillator verwenden. Den kannst du in einem weiten Bereich über das Kalibrierungsregister variieren. Damit du aber dabei auch weiss, was gerade als Frequenz rauskommt, kannst du den Uhrenquarz an den Timer hängen um nachzumessen. > Das mit dem Frequenzgenerator fällt leider auch aus - meiner schafft nur > max. 5MHz. Ich möchte das ganze aber gerne bei 20MHz testen, da meine > ganzen Einstellungen auf dieser Frequenz basieren. Der interne Osz geht nicht bis 20MHz und der 28pinner hat keine 2 externen Takte. Bischen flexibel muss der Mensch also sein. Teste die Kommunikation bei niedrigerer Frequenz. Oder bau dir einen externen einstellbaren RC-Oszillator für um die 20MHz - nur brauchst du dann noch was Drittes um dessen Frequenz nachzumessen.
Gast
#1578584
du schreibst doch dass du UART selbst implementiert hast, dann kannst du doch auch irgendwelche timer/schleifen anders einstellen sodass der gewünschte Fehler entstehT?
oder einen FTDI FT232 nehmen, der macht in Verbindung mit HTerm z.B. auch Krumme Baudraten. Gerade getestet.
Aber mit einem FTDI kann ich doch das DALI-Protokoll nicht mehr nutzen, oder?
Gast
#1578651
Die Konformität nach IEC 62386 kann nur durch die beschriebenen Testmethoden überprüft werden, wobei dabei alle Prüfungen eingehalten werden müssen. Das Einhalten der Baud-Rate ist meiner erfahrung nach das geringste Problem dabei.
@LeonidMüller: Ja, aber die restlichen Kriterien habe ich größtenteils erfüllt (habs prüfen lassen). Nur die Baud-Rate muss ich noch hinkriegen und t_rise/t_fall funzt noch nicht ganz.
Wie könnte ich eigentlich t_rise und t_fall beeinflussen? Einfach einen C an die Pins? Ginge das?
Gast
#1578888
@Andreas Posch Mich wundert das sehr, aus eigener Erfahrung kann ich sagen dass der "Rest" das schwierige ist. Darf man fragen um welchen Gerätetyp es sich handelt? Welche Unterstandards wurden implementiert? Andreas Posch schrieb: > Wie könnte ich eigentlich t_rise und t_fall beeinflussen? Einfach einen > > C an die Pins? Ginge das? Prinzipiell schon, nur müssen nach 101 die Eingangsparameter eingehalten werden.
Ja, den C nehm ich nach den Tests wieder raus. Dann passen die Eingangsparameter. Ich habe zunächst einmal DeviceType 0 implementiert.
Gibts sonst noch Ideen, wie ich den Baudraten-Test durchführen könnte?
Gast
#1578995
Andreas Posch schrieb: > Ja, den C nehm ich nach den Tests wieder raus. Dann passen die > > Eingangsparameter. Ich habe zunächst einmal DeviceType 0 implementiert. ... dann passt aber diene Flankensteilheit nicht, oder hab ich dich falsch verstanden? Mögliche Testquellen sind (ausser den "genormten") Funktionsgenerator, eigene Schaltung...
Naja, die Norm sieht Flanken von 10µs bis 100µs vor. Jetzt hab ich in etwa 10µs. Damit ich aber auch die 100µs testen kann, brauche ich einen C, den ich nach den Tests wieder rausnehme.