6 Sinuskurven mit 400Hz - welcher DDS?

[Martin S. (morton)]

Hallo zusammen,

ich muss mit einem ATmega32 (AVR-NET-IO) 6 einzelne Sinus-Kurven von 0-5 
Volt und einer Frequenz von 400 Hz erzeugen.

Ich denke DDS ist hier das Mittel der Wahl (!?).

Ich habe jetzt einige Zeit nach DDS-Bauelementen gesucht, aber nicht's 
passendes gefunden... welchen DDS könnt ihr mir empfehlen? Gibt es sowas 
wie den AD9833 nur als Mehrkanal-Version?


Vielen Dank im Voraus!


Schöne Grüße,
Morton

[A. D. (egsler)]

Wie sauber / mit welcher Auflösung willst du die Spannungen denn 
erzeugen?
Ggf. reicht es ja, 6 Soft-PWM-Kanäle mit bsp. 8kHz zu erzeugen? Sollte 
mit dem Atmega kein Problem sein.

[H.Joachim S. (crazyhorse)]

Bei fester Frequenz vielleicht auch die analoge Lösung mit einstellbaren 
Phasenschiebern?

[Falk B. (falk)]

@Martin S. (morton)

>ich muss mit einem ATmega32 (AVR-NET-IO) 6 einzelne Sinus-Kurven von 0-5
>Volt und einer Frequenz von 400 Hz erzeugen.

Der hat keine 6 PWM Ausgänge in Hardware. Das wird ungünstig.
6x 400 Hz klingt nach Drehstrom im Flugzeug.

>Ich denke DDS ist hier das Mittel der Wahl (!?).

Ja.

>Ich habe jetzt einige Zeit nach DDS-Bauelementen gesucht, aber nicht's
>passendes gefunden...

Die gibt's wie Sand am Meer, wenn gleich nicht mit 6 Ausgängen. Das ist 
eine klassische Funktion für uCs mit ausreichend PWMs.

Versuch einen pinkompatiblen uC zu deinem AVR zu finden der genügend 
PWMs hat.

[A. D. (egsler)]

Falk B. schrieb:
> Der hat keine 6 PWM Ausgänge in Hardware.

Aber ist das für 400Hz unbedingt notwendig? Ich würde mal behaupten, man 
bekommt 6 Soft-PWM-Kanäle locker ausreichend schnell realisiert.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Falk B. schrieb:
> Versuch einen pinkompatiblen uC zu deinem AVR zu finden der genügend
> PWMs hat.

Das sollte der ATMega644 sein. Der hat auch andere nette Sachen, wie PC 
Interrupts.

[Axel S. (a-za-z0-9)]

Martin S. schrieb:
> ich muss mit einem ATmega32 (AVR-NET-IO) 6 einzelne Sinus-Kurven von 0-5
> Volt und einer Frequenz von 400 Hz erzeugen.
>
> Ich denke DDS ist hier das Mittel der Wahl (!?).

Kommt drauf an. Worin sollen sich die 6 Signale denn unterscheiden? Nur 
in der Amplitude? Oder auch in Frequenz/Phase? Wenn nur in der 
Amplitude, dann brauchst du ja nur 6 Abschwächer und irgendwas, das dir 
deine 400Hz erzeugt.

Bei lediglich 400Hz kann man DDS aber auch problemlos in Software 
machen. Stichwort: Jesper-DDS.

[Falk B. (falk)]

@A. D. (egsler)

>> Der hat keine 6 PWM Ausgänge in Hardware.

>Aber ist das für 400Hz unbedingt notwendig?

Es ist überaus sinnvoll, wenn der AVR noch andere Sachen machen soll.

> Ich würde mal behaupten, man
>bekommt 6 Soft-PWM-Kanäle locker ausreichend schnell realisiert.

Wirklich? Wenn er 400 Hz Sinus haben will, braucht er MINDESTENS 4 kHz 
PWM-Frequenz und gute Ausgangsfilter. 6 Kanal Soft-PWM mit 4 kHz 
frißt verdammt viel CPU-Leistung.

[Falk B. (falk)]

@Axel Schwenke (a-za-z0-9)

>Bei lediglich 400Hz kann man DDS aber auch problemlos in Software
>machen. Stichwort: Jesper-DDS.

Nur daß dann die CPU zu 99% ausgelastet ist . . .

[Martin S. (morton)]

A. D. schrieb:
> Wie sauber / mit welcher Auflösung willst du die Spannungen denn
> erzeugen?

Ehrlich gesagt ist die letztendlich benötigte Auflösung noch nicht 
eindeutig bzw. definiert, sorry.


H.Joachim S. schrieb:
> Bei fester Frequenz vielleicht auch die analoge Lösung mit
> einstellbaren
> Phasenschiebern?

Das muss ich mir anschauen, einstellbare Phasenschieber kenne ich (noch) 
nicht.


Falk B. schrieb:
> @Martin S. (morton)
>
>>ich muss mit einem ATmega32 (AVR-NET-IO) 6 einzelne Sinus-Kurven von 0-5
>>Volt und einer Frequenz von 400 Hz erzeugen.
>
> Der hat keine 6 PWM Ausgänge in Hardware. Das wird ungünstig.
> 6x 400 Hz klingt nach Drehstrom im Flugzeug.

Ja, gut erkannt. Der Synchro/Kreisel wird ersetzt und der künstliche 
Horizont im Cockpit direkt vom Mikrocontroller mittels 3x Sinus für 
jeweils Roll- und Pitch-Achse angesteuert. So zumindest der Plan.


>>Ich denke DDS ist hier das Mittel der Wahl (!?).
>
> Ja.
>
>>Ich habe jetzt einige Zeit nach DDS-Bauelementen gesucht, aber nicht's
>>passendes gefunden...
>
> Die gibt's wie Sand am Meer, wenn gleich nicht mit 6 Ausgängen. Das ist
> eine klassische Funktion für uCs mit ausreichend PWMs.
>
> Versuch einen pinkompatiblen uC zu deinem AVR zu finden der genügend
> PWMs hat.

Das Problem ist, dass netto noch zweieinhalb Wochen bleiben um das 
Projekt umzusetzen. Noch einen zusätzlichen µC einzubinden wirkt für 
mich gerade als ziemlich aufwändig, zumal ich mich in jegliche Themen 
(DDS-Ansteuerung, PWM-Umsetzung, kombinieren von µC's) einlesen muss, da 
ich hier nicht viel Erfahrung habe. Aber Tutorials und Forenthemen gibt 
es ja zu den meisten Themen zu genüge.


Axel S. schrieb:
> Kommt drauf an. Worin sollen sich die 6 Signale denn unterscheiden? Nur
> in der Amplitude? Oder auch in Frequenz/Phase? Wenn nur in der
> Amplitude, dann brauchst du ja nur 6 Abschwächer und irgendwas, das dir
> deine 400Hz erzeugt.
>
> Bei lediglich 400Hz kann man DDS aber auch problemlos in Software
> machen. Stichwort: Jesper-DDS.

Die Unterschiede liegen in den Amplituden und in der Phasenverschiebung 
um jeweils 120°

Bezüglich CPU-Auslastung: Der µC muss noch den Datentransfer über UDP 
handeln können, da über UDP Winkel-Angaben (Roll/Pitch) empfangen und 
als dazugehörige Sinus-Kurven ausgegeben werden sollen.

Also lieber DDS oder PWM? Die DDS werden aber nicht mit PWM angesteuert, 
oder? Werden diese nicht über Bit-Reihenfolgen konfiguriert und 
angesteuert?


Vielen Dank schon einmal für eure Hilfe!!!

[Blackbird (Gast)]

Martin S. schrieb:
> Das Problem ist, dass netto noch zweieinhalb Wochen bleiben um das
> Projekt umzusetzen.

Martin S. schrieb:
> Die Unterschiede liegen in den Amplituden und in der Phasenverschiebung
> um jeweils 120°

Da fehlen immer noch ein paar relevante Infos.

3 x 120° sind 360°
Und wozu die anderen 3 Phasen? Jedes "triple" hat die gleiche Amplitude?

Analog einen (zwei) 3-Phasen-Generator bauen und den Start vom µC 
erledigen lassen. Die Amplituden-Steuerung über 3 (6) digitale Potis 
oder über CMOS-Schalter mit Widerständen.

Das könnte in 2 Wochen, Software (getestet) und Hardware (aufgebaut und 
getestet), zu schaffen sein.

Wenn es erst einmal läuft, kann man immer noch über eine voll digitale 
Lösung nachdenken.


Blackbird

[Peter R. (pnu)]

Falk B. schrieb:
> Nur daß dann die CPU zu 99% ausgelastet ist . . .

man kann intern EIN 400-Hz erzeugen und und durch Konstantenaddition 
daraus 3 Phasenverschobene Sinuse, die auf drei ports als 8-bit-Worte 
ausgegeben werden.. Dazu noch Invertierung. und fertig ist das 
sechs-Phasen-System.

das kostet einen atmga nur ein müdes Stirnrunzeln.

[Michael F. (sharpals)]

Bleiben die phasenbeziehungen eigentlich konstant ?

Dann würde sogar ein normaler oszillator gehen und daran koppelst du 
dann die phasienschieber.

Die amplituden regelst du mit PWMs.

Die ander möglichkeit ist, du nimmst zwei µC.

Der eine rechnet alles, wa gebraucht wird und der zweite erzeugt per DDS 
den sinus (bei 400Hz , kein problem ) und die amplitude kannst du ja 
dann auch über einen multiplikator einstellen.

Die information gibts du vom master an DDS , über den Uart weiter.

In dem angefängten code ist die schleife als ASM eingebaut, weil ich 
über 100Khz will.

Bei dir könntes du die schleife aber in einer hochsprache machen ( ist 
auch im asmcode vermerkt)


du könntest den das umbauen :

CR1AL:=sinus[(w shr 16) and $FF];

und das für 6 phasenbeziehungen umbauen.

Nur würde ich dann nicht bis 255 zählen, sondern bis 360 und die tabelle 
dementsprechend erweitern.

program soft_dds;

const sinus:array[0..255] of byte =
(
0x80,0x83,0x86,0x89,0x8c,0x8f,0x92,0x95,0x98,0x9c,0x9f,0xa2,0xa5,0xa8,0xab,0xae,
0xb0,0xb3,0xb6,0xb9,0xbc,0xbf,0xc1,0xc4,0xc7,0xc9,0xcc,0xce,0xd1,0xd3,0xd5,0xd8,
0xda,0xdc,0xde,0xe0,0xe2,0xe4,0xe6,0xe8,0xea,0xec,0xed,0xef,0xf0,0xf2,0xf3,0xf5,
0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfc,0xfd,0xfe,0xfe,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xfe,0xfe,0xfd,0xfc,0xfc,0xfb,0xfa,0xf9,0xf8,0xf7,
0xf6,0xf5,0xf3,0xf2,0xf0,0xef,0xed,0xec,0xea,0xe8,0xe6,0xe4,0xe2,0xe0,0xde,0xdc,
0xda,0xd8,0xd5,0xd3,0xd1,0xce,0xcc,0xc9,0xc7,0xc4,0xc1,0xbf,0xbc,0xb9,0xb6,0xb3,
0xb0,0xae,0xab,0xa8,0xa5,0xa2,0x9f,0x9c,0x98,0x95,0x92,0x8f,0x8c,0x89,0x86,0x83,
0x80,0x7c,0x79,0x76,0x73,0x70,0x6d,0x6a,0x67,0x63,0x60,0x5d,0x5a,0x57,0x54,0x51,
0x4f,0x4c,0x49,0x46,0x43,0x40,0x3e,0x3b,0x38,0x36,0x33,0x31,0x2e,0x2c,0x2a,0x27,
0x25,0x23,0x21,0x1f,0x1d,0x1b,0x19,0x17,0x15,0x13,0x12,0x10,0x0f,0x0d,0x0c,0x0a,
0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x03,0x02,0x01,0x01,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x01,0x02,0x03,0x03,0x04,0x05,0x06,0x07,0x08,
0x09,0x0a,0x0c,0x0d,0x0f,0x10,0x12,0x13,0x15,0x17,0x19,0x1b,0x1d,0x1f,0x21,0x23,
0x25,0x27,0x2a,0x2c,0x2e,0x31,0x33,0x36,0x38,0x3b,0x3e,0x40,0x43,0x46,0x49,0x4c,
0x4f,0x51,0x54,0x57,0x5a,0x5d,0x60,0x63,0x67,0x6a,0x6d,0x70,0x73,0x76,0x79,0x7c
);

faktor = 0.001 * 0.304 * $FFFF;

var t:byte;
    max,
    phase:dword;
    delta:dword;
    w:byte;
    frequenz:integer;

    kette:array[0..7] of char;
    l:byte;

procedure send_byte(eing:byte);
begin
   while ((UCSRA and (1 shl UDRE) ) = 0) do;
   UDR :=eing;
end;
procedure eukl(eing:dword);
var e,r:dword;
    c:byte;
begin
           e:=100000;
           for c:=1 to 6
           do
           begin
             r:=(eing div e);
             send_byte('0'+r);
             eing:=eing - r*e;
             e:=e div 10;
           end;
      send_byte(' ');
end;

procedure set_delta;
begin
     eukl(frequenz);
     delta:=dword( frequenz * faktor);
end;
procedure gen_val;
var j:byte;
    c:integer;
begin

 c:=1;
 frequenz:=0;
 for j:=(l-1) downto 0
  do
     begin
        frequenz:=frequenz+(kette[j]-48)*c;
        c:=c*10;
     end;
  set_delta;
l:=0;

end;

procedure USART__RX();  org IVT_ADDR_USART__RX;
var val:byte;
    df:short;
begin
     val:= UDR; //UART1_Read();            // read the received data,

     if val <> ' '
       then
         begin
          if (val >= '0') and (val <= '9')
          then
           begin
                kette[l]:=val;
                inc(l);
           end
           else
            begin
                 case val
                 of
                  '+':df:= +1;
                  '-':df:= -1;
                  'u':df:= +10;
                  'd':df:= -10;
                  'U':df:=+100;
                  'D':df:=-100;
                 end;
                 frequenz:=frequenz + df;
                 set_delta;
            end;
         end
            else if l > 0 then gen_val;

asm   // wieso geht das nicht ???
       LDS        R16, _delta+0
       LDS        R17, _delta+1
       LDS        R18, _delta+2
end;
end;
const takt = 16000000; // 16 MHZ
      baud = 9600;
      ubrr_val = ((takt+baud*8)/(baud*16)-1);
label loop,test;

begin
   t:=0;
   DDRB:=$FF; // alle im port B  auf ausgang
   // ---------------------------------------------------------------

   TCCR1A:= $81;  // non-inverted PWM on OC1A, 8 Bit Fast PWM // timmer 1 !!
   //TCCR1B:= $08;
   TCCR1B:=$08 or TCCR1B and not $7 or 1;  // clear clk setting
   //TCCR1B:=TCCR1B or 1;  // precaler 1 -> ~122*256 Hz PWM frequency
   OCR1AH:=0;
   // ----------------------------------------------------------------
   ubrrh:=hi(ubrr_val);
   ubrrl:=ubrr_val and $FF;

   UCSRB:= (1 shl RXEN) or (1 shl TXEN) or 128;// empfangen , senden und IRQ wenn Zeichen empfangen wird.
   // ucsrb:=ucsrb or 128;                     // UART interrupt wenn zeichen gelesen ...
  // 8 data bits, 1 stop bit
   UCSRC:= (1 shl UCSZ1) or (1 shl UCSZ0);

   Delay_ms(100);                            // Wait for UART module to stabilize

   SREG_I_bit := 1;

   frequenz:=1000;
   set_delta;

   asm
       LDI        R26, lo_addr(_sinus)
       LDI        R27, hi_addr(_sinus)
   end;

   while TRUE do  // danach assm !!     // Endless loop
      begin

       //  phase:=phase+delta;
       asm
       loop:

       LDS        R16, _delta+0
       LDS        R17, _delta+1
       LDS        R18, _delta+2

        ADD        R20, R16        // 1 addiere wert, auf
        ADC        R21, R17        // 1
        ADC        R22, R18        // 1

        //OCR1AL:=sinus[(w shr 16) and $FF];

        MOV        R30, R22  // 1   3 byte von der
        LDI        R31, 0    // 1
        ADD        R30, R26  // 1
        ADC        R31, R27  // 1
        LPM                  // 3   // lädt aus dem flash an der addresse Z (r30,r1);
        OUT        OCR1AL, R0// 1

        rjmp       loop;     // 2
     end;
   end;
end.

[Tom (Gast)]

Martin S. schrieb:
> ATmega32 (AVR-NET-IO)

1. Da kannst Du ganz einfach einen 644 oder 1284p reinstecken, und hast 
mehr PWMs. Und mehr Ram und mehr UARTS zum debuggen und und und.

   Achtung:
Beim orginal AVR-NET-IO bleibt ab und zu mal das Ethernet stehen!!
   Hoffentlich nicht wenn gerade geflogen wird.
   Nachbesserung (Block-Cs am ENC) müsste hier stehen:
   https://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin

[Falk B. (falk)]

@Martin S. (morton)

>Ja, gut erkannt. Der Synchro/Kreisel wird ersetzt und der künstliche
>Horizont im Cockpit direkt vom Mikrocontroller mittels 3x Sinus für
>jeweils Roll- und Pitch-Achse angesteuert. So zumindest der Plan.

>> Versuch einen pinkompatiblen uC zu deinem AVR zu finden der genügend
>> PWMs hat.

>Das Problem ist, dass netto noch zweieinhalb Wochen bleiben um das
>Projekt umzusetzen. Noch einen zusätzlichen µC einzubinden wirkt für

Ich meinte, daß du einen pinkompatiblen AVR nehmen sollst. Dazu gab es 
ja schon mehrere Vorschläge.

>Die Unterschiede liegen in den Amplituden und in der Phasenverschiebung
>um jeweils 120°

Also 6 Sinussignale mit 6 verschiedenen Amplituden.

>Bezüglich CPU-Auslastung: Der µC muss noch den Datentransfer über UDP
>handeln können, da über UDP Winkel-Angaben (Roll/Pitch) empfangen und
>als dazugehörige Sinus-Kurven ausgegeben werden sollen.

>Also lieber DDS oder PWM?

Beides ist möglich. Die PWM sollte man in Hardware machen.

> Die DDS werden aber nicht mit PWM angesteuert,

Nein.

>oder? Werden diese nicht über Bit-Reihenfolgen konfiguriert und
>angesteuert?

Ja.

[Joachim B. (jar)]

mein Netio hat auch einen m1284p bekommen arbeitet sich definitv besser,

-> mehr SRAM
-> 2x Rx Tx

aber trotz jede Menge Abblock C am ENC bleibt Netzwerk trotzdem ab und 
an stehen, juckt mich aber noch wenig, sonst müsste ich den ganze Code 
überarbeiten mit 16KB SRAM könnte ich die ganze Webseite vorrätig halten 
ohne sie on the fly zu erzeugen.

[Martin S. (morton)]

Blackbird schrieb:
> Da fehlen immer noch ein paar relevante Infos.
>
> 3 x 120° sind 360°
> Und wozu die anderen 3 Phasen? Jedes "triple" hat die gleiche Amplitude?

Roll(X, Y, Z) und Pitch(X, Y, Z), alle 6 Signale mit unterschiedlichen 
Amplituden und zwischen X, Y, Z eigentlich jeweils um 120° 
phasenverschoben ("eigentlich": Die gemessenen Ist-Werte waren teilweise 
nicht phasenverschoben). Siehe auch Antwort weiter unten auf den Beitrag 
von Michael F.



Peter R. schrieb:
> Falk B. schrieb:
>> Nur daß dann die CPU zu 99% ausgelastet ist . . .
>
> man kann intern EIN 400-Hz erzeugen und und durch Konstantenaddition
> daraus 3 Phasenverschobene Sinuse, die auf drei ports als 8-bit-Worte
> ausgegeben werden.. Dazu noch Invertierung. und fertig ist das
> sechs-Phasen-System.
>
> das kostet einen atmga nur ein müdes Stirnrunzeln.

Klingt interessant, auch wenn ich da jetzt erst mal schauen muss, wie 
man das Ganze anpacken kann.



Michael F. schrieb:
> Bleiben die phasenbeziehungen eigentlich konstant ?

Das ist ehrlich gesagt nicht zu 1000% eindeutig. Die per Oszilloskop 
gemessenen Signale am Synchro/Kreisel (--> soll hier durch die 
µC-Steuerung ersetzt werden) waren nicht immer 120° phasenverschoben, 
was aber nach meinem Kenntnisstand ein wenig gegen die Funktionsweise 
eines Synchros spricht. Der Synchro ist aus den 70ern und macht im 
Betrieb akkustisch auch nicht mehr den fittesten Eindruck, eventuell ist 
dieser nicht mehr einwandfrei und hat die Messergebnisse beeinflusst. 
Aber das muss letztendlich, wenn die Ersatz-Steuerung steht, ausprobiert 
werden. Daher müsste hier die Option bleiben, dass man die 
Phasenverschiebung ändern könnte.



Tom schrieb:
> Martin S. schrieb:
>> ATmega32 (AVR-NET-IO)
>
> 1. Da kannst Du ganz einfach einen 644 oder 1284p reinstecken, und hast
> mehr PWMs. Und mehr Ram und mehr UARTS zum debuggen und und und.
>
>    Achtung:
> Beim orginal AVR-NET-IO bleibt ab und zu mal das Ethernet stehen!!
>    Hoffentlich nicht wenn gerade geflogen wird.
>    Nachbesserung (Block-Cs am ENC) müsste hier stehen:
>    https://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin

Danke, den 1284p habe ich vorhin geordert (bietet 6 PWM's). Der Flieger 
ist mittlerweile ein Flugsimulator und steht glücklicherweise fest am 
Boden, Gefahr für Leib und Leben besteht da nicht :)



Falk B. schrieb:
>>> Versuch einen pinkompatiblen uC zu deinem AVR zu finden der genügend
>>> PWMs hat.
>
>>Das Problem ist, dass netto noch zweieinhalb Wochen bleiben um das
>>Projekt umzusetzen. Noch einen zusätzlichen µC einzubinden wirkt für
>
> Ich meinte, daß du einen pinkompatiblen AVR nehmen sollst. Dazu gab es
> ja schon mehrere Vorschläge.

Danke, ATmega1284p ist als Ersatz geordert (bietet 6 PWM's).


Falk B. schrieb:
>>Die Unterschiede liegen in den Amplituden und in der Phasenverschiebung
>>um jeweils 120°
>
> Also 6 Sinussignale mit 6 verschiedenen Amplituden.

Ja, siehe auch obersten Teil meiner Antwort.


Falk B. schrieb:
>>Bezüglich CPU-Auslastung: Der µC muss noch den Datentransfer über UDP
>>handeln können, da über UDP Winkel-Angaben (Roll/Pitch) empfangen und
>>als dazugehörige Sinus-Kurven ausgegeben werden sollen.
>
>>Also lieber DDS oder PWM?
>
> Beides ist möglich. Die PWM sollte man in Hardware machen.

Hardware-PWM gemäß https://www.mikrocontroller.net/articles/AVR_PWM mit 
Tiefpassfilter der noch hinzukommt?


Kurz als Zwischen-Zusammenfassung: Hier wurden nun mehrere Lösungen 
vorgeschlagen, aber die wahrscheinlich zielführendsten scheinen mir hier 
PWM oder DDS zu sein. Eigentlich erscheint mir persönlich DDS am 
Saubersten/Angenehmsten, da diese als Komplett-Bausteine erhältlich sind 
und mehr oder weniger "nur" vernünftig verbunden und angesteuert werden 
müssen - Problem ist die Anzahl der Ausgänge, bei analog.com im 
Produkt-Filter finde ich DDS mit max. 4 Channels, welche dann jedoch 
auch 32 Pins haben - klingt für das AVR-NET-IO nach zu vielen Pins, die 
angesteuert werden müssen. Dann wohl doch lieber PWM. Die Umsetzung von 
A bis Z der PWM als analoge Signale habe ich noch nicht zu 100% 
verstanden, aber da werde ich mich noch reinarbeiten, Anleitungen gibt 
es ja zu Genüge.

Ich habe nun den ATmega1284p geordert. Dann müsste, so wie ich das 
verstanden habe, noch ein Tiefpass-Filter dimensioniert und umgesetzt 
werden und der Rest ist dann die Software-Umsetzung, womit letztendlich 
6 Sinussignale realisiert werden können?



Bzgl der Alternativen:
- Einstellbare Phasenverschieber = Neuland, werde ich mir aber trotzdem 
mal anschauen
Jesper-DDS: zu CPU-lastig lt. Kommentar?!
- 3-Phasen-Generator: Klingt mir spontan nach zu viel Aufwand, zumal 
hier leider keine Vorab-Lösung in Frage kommt, welche für die spätere 
Verwendung hardwareseitige Änderungen benötigt
- Oszillator + Phasenschieber: Gilt nur, wenn die Phasen letztendlich 
wirklich alle zu 120° verschoben sind? Könnte problematisch sein, die 
Phasenverschiebung sollte zur Not anpassbar sein

Trotzdem vielen Dank für die Alternativ-Vorschläge!

[Falk B. (falk)]

@Martin S. (morton)

>> das kostet einen atmga nur ein müdes Stirnrunzeln.

>Klingt interessant, auch wenn ich da jetzt erst mal schauen muss, wie
>man das Ganze anpacken kann.

Vergiss PWM in Software, du hast ja jetzt genug PWMs.

>Danke, den 1284p habe ich vorhin geordert (bietet 6 PWM's). Der Flieger
>ist mittlerweile ein Flugsimulator und steht glücklicherweise fest am
>Boden, Gefahr für Leib und Leben besteht da nicht :)

Na dann ist da ja alles OK. Es hätte mich auch schon gewundert, wenn man 
Hobbybastler an Flugzeugen rumschrauben lassen würde.

>Hardware-PWM gemäß https://www.mikrocontroller.net/articles/AVR_PWM mit
>Tiefpassfilter der noch hinzukommt?

Ja.

https://www.mikrocontroller.net/articles/Pulsweitenmodulation#RC-Filter_dimensionieren

>Produkt-Filter finde ich DDS mit max. 4 Channels, welche dann jedoch
>auch 32 Pins haben - klingt für das AVR-NET-IO nach zu vielen Pins, die
>angesteuert werden müssen.

Nö. Die meisten DDS-ICs werden per SPI angesteuert, da braucht man 
gerade mal 3 + N Pins, um N ICs anzusteuern.

>Dann wohl doch lieber PWM.

Das ist schon OK und vor allem hast du mehr Kontrolle über die 
Signalgenerierung. Denn Wenn deine DDS-ICs von außen nicht 
synchronisiert werden können, wird es mit den 6 synchronen Signalen 
schwierig.

>werden und der Rest ist dann die Software-Umsetzung, womit letztendlich
>6 Sinussignale realisiert werden können?

Ja

http://www.mikrocontroller.net/topic/goto_post/3098563

Siehe auch DDS.

>- Einstellbare Phasenverschieber = Neuland, werde ich mir aber trotzdem
>mal anschauen

Vergiss es, das macht man heute so weit wie möglich digital!

>Jesper-DDS: zu CPU-lastig lt. Kommentar?!

Vergiss es, dann dann kannst du deine Ethernetverbindung vergessen.

>- Oszillator + Phasenschieber: Gilt nur, wenn die Phasen letztendlich
>wirklich alle zu 120° verschoben sind? Könnte problematisch sein, die
>Phasenverschiebung sollte zur Not anpassbar sein

Dito. Mit 6xPWM im AVR bist du Up to date, alles anderes ist mehr oder 
minder Schnee von gestern.

[Rudolph (Gast)]

Martin S. schrieb:
> Die per Oszilloskop
> gemessenen Signale am Synchro/Kreisel (--> soll hier durch die
> µC-Steuerung ersetzt werden) waren nicht immer 120° phasenverschoben,
> was aber nach meinem Kenntnisstand ein wenig gegen die Funktionsweise
> eines Synchros spricht.

Die Signale eines Synchros sind auch nicht um 120° verschoben. Bei einer 
Drehung von 360° ergibt sich sozusagen für jedes Synchrosignal eine 
Amplitudenmodulation des Trägersignals mit 400 Hz, wobei dabei die 
Hüllkurven der drei Synchrosignale drei um 120° verschobene Sinussignale 
darstellen.

Vgl. https://de.wikipedia.org/wiki/Datei:Drehmelderspannungen.png

[c-hater (Gast)]

Martin S. schrieb:

> Danke, den 1284p habe ich vorhin geordert (bietet 6 PWM's).

Der bietet sogar 8, er hat nämlich 4 PWM-fähige Timmer mit je zwei 
Kanälen. Naja, sicher nicht schlimm, einen Extra-Timer kann man immer 
gebrauchen...

[Martin S. (morton)]

Falk B. schrieb:
> @Martin S. (morton)
>>Hardware-PWM gemäß https://www.mikrocontroller.net/articles/AVR_PWM mit
>>Tiefpassfilter der noch hinzukommt?
>
> Ja.
>
> 
https://www.mikrocontroller.net/articles/Pulsweitenmodulation#RC-Filter_dimensionieren

Macht es hier ggf. Sinn, einen Mehrkanal-LTC einzusetzen um sich aus 
Zeitgründen das Dimensionieren und Realisieren der Filter zu ersparen? 
Und ggf. auch um eine Fehlerquelle auszuschließen/zu minimieren?

z.B. 2x LTC2645 (4-Kanal) in 10-Bit Auflösung? Vielleicht habe ich 
gerade ein Brett vorm Kopp, aber hat man an den Ausgängen vom LTC dann 
direkt ein analoges Signal?


c-hater schrieb:
> Martin S. schrieb:
>
>> Danke, den 1284p habe ich vorhin geordert (bietet 6 PWM's).
>
> Der bietet sogar 8, er hat nämlich 4 PWM-fähige Timmer mit je zwei
> Kanälen. Naja, sicher nicht schlimm, einen Extra-Timer kann man immer
> gebrauchen...

Tatsache, da war die Beschreibung bei microchip.com fehlerhaft. Im 
Datenblatt sind auch von 8 PWMs die Rede.


Rudolph schrieb:
> Martin S. schrieb:
>> Die per Oszilloskop
>> gemessenen Signale am Synchro/Kreisel (--> soll hier durch die
>> µC-Steuerung ersetzt werden) waren nicht immer 120° phasenverschoben,
>> was aber nach meinem Kenntnisstand ein wenig gegen die Funktionsweise
>> eines Synchros spricht.
>
> Die Signale eines Synchros sind auch nicht um 120° verschoben. Bei einer
> Drehung von 360° ergibt sich sozusagen für jedes Synchrosignal eine
> Amplitudenmodulation des Trägersignals mit 400 Hz, wobei dabei die
> Hüllkurven der drei Synchrosignale drei um 120° verschobene Sinussignale
> darstellen.
>
> Vgl. https://de.wikipedia.org/wiki/Datei:Drehmelderspannungen.png

Okay... da fehlt mir dann das tatsächliche Hintergrundwissen zum Genauen 
Funktionsprinzip. Ehrlich gesagt tue ich mich da etwas schwer, das zu 
durchblicken. Ist aber vermutlich im aktuellen Projektstatus nicht mehr 
essentiell, da wir die hardware- und softwareseitige Basis kreieren - 
wie letztendlich die Sinussignale exakt aussehen werden müssen, damit 
die Anzeige im Cockpit sich richtig positioniert, müssen wir zur Not an 
eine nächste Projektgruppe übergeben, auch wenn das nicht Ziel der 
ganzen Sache war.

[MaWin (Gast)]

Martin S. schrieb:
> Ich denke DDS ist hier das Mittel der Wahl

Suche magic sinewaves, genau dafür gemacht
http://www.mdr.de/thueringen/sued-thueringen/suhl-bungalow-steinsfelder-abrissgebiet-baugenehmigung-100.html

[MaWin (Gast)]

Blöderweise war der Link falsch
http://www.tinaja.com/glib/msintro1.pdf

[Gerald M. (gerald_m17)]

So etwas einfaches würde ich mit einem aktiven Allpass aufbauen. Das ist 
ein OpAmp mit 3 Widerständen und 1 Kondensator. Für 400Hz Sinus entweder 
digital per PWM und Filter l oder als Wien Robinson Oszillator. Daran 
einen Allpass der 120° schiebt, und daran wieder einen.
Schon hast du 3x 400Hz mit je 120° Phasenverschiebung. Für die 
einstellbaren Amplituden einfach noch 6 OpAmps mit Poti.
Das brutzelt man in weniger als einem Tag auf Lochraster (inkl. 
Widerstände matchen)

[Falk B. (falk)]

@ Martin S. (morton)

>https://www.mikrocontroller.net/articles/Pulsweite...

>Macht es hier ggf. Sinn, einen Mehrkanal-LTC einzusetzen um sich aus
>Zeitgründen das Dimensionieren und Realisieren der Filter zu ersparen?
>Und ggf. auch um eine Fehlerquelle auszuschließen/zu minimieren?

Bleib cool! So eine Filterdimensionierung ist kein Hexenwerk.

>z.B. 2x LTC2645 (4-Kanal) in 10-Bit Auflösung? Vielleicht habe ich
>gerade ein Brett vorm Kopp, aber hat man an den Ausgängen vom LTC dann
>direkt ein analoges Signal?

Ja, hat man. Ist aber was für Weicheier, die Angst vor einem einfachen 
Tiefpaß haben.

Einfache Rechnung.

AVR @ 16 MHz mit 10 Bit PWM macht ~ 16kHz PWM Frequenz. Die höchste und 
hier einzige Ausgangsfrequenz ist 400 Hz, dazwischen liegt der Faktor 
40, das sind 1,6 Dekaden. Bei 10 Bit braucht man aber einen 
Dämpfungsfaktor von ca. 1000, wenn man die Rauschgrenze auf die 
Auflösungsgrenze drücken will. Braucht man hier wahrscheinlich nicht, 
denn die Anzeigeeinheit des künstlichen Horizonts ist wahrscheinlich 
nicht sooo sensibel bezüglich Rauschen.

Ein einfacher Tiefpaß 2. Ordung mit 400 Hz Grenzfrequenz baut man mit 
einem OPV und der Sallen-Key Schaltung auf, der macht 40 db/Dekade bzw. 
ca. 50db/ 1,6 Dekaden, das ist schon Faktor ~300. Das sollte praktisch 
reichen.