Spektrum Telemetrie und alternative Sensoren/Eigenbau

[mukenukem]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Ich weiss auch nicht wie, da kannst noch so rumspielen
Du kannst es dir per Tastendruck oder in Intervallen ansagen lassen. Meiner Meinung nach je weniger Information, desto besser. Lenkt weniger ab

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

@Christian
Hi, habe gerade mal bei github mir die Rev_B Schaltung angesehen. Dabei fällt mir in Verbindung mit dem Datenblatt auf, das beim 32E5 VCC nicht als VRef verwendet werden kann.
Leider hat das den Nachteil, das das ratiometrische Verhalten des ACS7xx damit nicht zum tragen kommt. Es sei denn man erzeugt die VRef in einem ratiometrischen Verhältnis zu VCC.

Gruß Ingo

[csc13]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Hallo Ingo,
ich denke ich habe eine grobe Vorstellung was "ratiometrisch" ist, kann es aber nicht anwenden. In der aktuellen Schaltung verwende ich VCC/1.6. Da komme ich auf ca. 3% Genauigkeit bei 3000mAh. Da der Allegro ja bis zur Eingangsspannung auf Vout rausgibt, mit 3.3V läuft (besser 5V) brauche ich eh einen Spannungsteiler. Ein zusätzlicher ADC mit 5V, etc. war mir zu aufwändig.
Jetzt war die Idee AREFA mit 2024mV zu versorgen. Viel mehr geht ja auch nicht. Und dann eine Messung dagegen zu machen. Dann kann ich nur 11 Bit Auflösung verwenden, aber das geht beim glätten des aktuellen Signals eh mehr als verloren.

Kann ich den Weg so gehen oder habe ich eine groben Schnitzer drin? Und ist die "ratiometrische Messung" noch eins draufgesetzt?

Ich habe einen kleinen Blog zum Projekt aufgesetzt um andere an meinen Erfahrungen teilhaben zu lassen. Ich profitiere so viel von anderen, da möchte ich auch was beisteuern Findet sich unter spektel.cescholz.de

Gruß
Christian

[csc13]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Hallo Ingo,
ich glaube jetzt habe ich es geschnallt. Du meinst, die Spannung des Allegro, die ja auch den Output bestimmt, kann sich gegen die Referenzspannung verschieben!? Damit wäre die Messung dann natürlich um die Differenz falsch!?

War es das was Du meintest? Das mit dem 32E5 ist mir natürlich nicht aufgefallen, weil es der erste µC ist, mit dem ich mich so intensiv beschäftigt habe.

Gruß
Christian

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Mit ratiometrisch ist hier gemeint, das die Ausgangsspannung des Allegro sich im festen Verhältnis zu der Betriebsspannung verhält.
Das hat den Vorteil, das bei Z.B. 10% weniger VCC sich auch die Ausgangsspannung des Allegro um 10% verringert und damit der ADC immer noch richtig misst, wenn die V-Ref sich auch um 10% verringert.

Bisher habe ich bei den AVR's und den STM32Fxxx immer V-Ref == VCC einsetzen können. Das geht aber mit dem 32E5 nicht mehr, wie ich im Datenblatt sehen konnte.
Wenn ich das richtig in Erinnerung habe, geht intern VCC/2 als V-Ref, das wäre eine Lösung mit einem 1:2 Spannungsteiler am Allegro.

Was noch fehlt ist ein par. Kondensator am unteren Widerstand des Spannungsteilers um das Rauschen des Allegro in Hardware zu filtern.

Gruß Ingo

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Nachtrag:
Wenn du nicht nur Höhe messen, sondern auch ein vernünftig arbeitendes Vario haben willst, dann vergess den BMP180 und nimm den MS5611. Das Rauschen des BMP180 ist einfach zu hoch um mit akzeptablen Filterzeiten ein brauchbares Vario Signal zu bekommen.

Gruß Ingo

[csc13]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Hallo Ingo,
vielen Dank für die Zeit das Design zu checken. Das mit dem Tiefpass hatte ich auch schon mal angedacht. Was wäre den eine passende Kapazität? Ich sample aktuell mit 25-50Hz.
Bezüglich BMP180 habe ich noch keine Erfahrung. Wäre natürlich schön, wenn er als Vario auch mal im Segler funktioniert. Da schaue ich mir den MS5611 mal genauer an.

Viele Grüße
Christian

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Ich nehme da immer 100nF, weniger wegen speziellen Tiefpass Werten, sondern um die Anzahl der unterschiedlichen Bauteile klein zu halten. Ich sample typisch mit 100Hz.

Gruß Ingo

[McMorton]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

...
Ich messe im 10ms Raster mit 1kOhm/100nF R/C Tiefpass am ACSxxx Ausgang. Stromspitzen werden ungefiltert und der Stromwert Tiefpass gefiltert ausgegeben.

Der spezielle Tiefpass mit nur wenigen Zeilen und nur Shift Operationen stammt von einem Ing. "Dorr" und wurde vor viele Jahren mal in der "edn" veröffentlicht.

Gruß Ingo

Hallo,

ich bin gerade dabei einen PIC Controller für eine Kapazitätsmessung zu programmieren. Ich habe gerade einen Verständnissfrage (oder ein Brett vorm Kopf):
Ich gebe die aufgenommenen Stromwerte durch den Software-Tiefpass.
Aus den Ergebnissen bilde ich dann den Mittelwert.
Aus dem Mittelwert des Stroms weißt ich dann den Strom pro Stunde --> mAh

Oder ahbe ich einen Denkfehler?

Gruß

McMorton

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

So geht es nicht.
Einfach in einem festen Raster von z.B. 10ms den Strom messen. Von diesem Messwerte dann 1/3600tel auf addieren bzw. diesen Strom integrieren.

Gruß Ingo

[McMorton]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

War wohl zu spät gestern...

Danke.

Nur nochmal zu Sicherheit:
Ich messe also alle 10ms. Den Stromwert filtere ich mit einem Tiefpass um Spitzen (Rauschen) zu unterdrücken.
Aufintegrieren tue ich dann den Mittelwert von 1er Sekunde (1/3600)?
Oder denke ich einfach zu kompliziert?

P.S.
zum setzen/programmieren der Warnschwelle werde ich einen Dig_in mit einem freien Aux Kanal am Empfänger verbinden. Dann kann ich die Kapazitätsgrenze über die Funke neu programmieren (EEPROM) ohne einen PC anzuschließen.
(z.B. AUX 10-100% = 1000-3000mAh)

[ingo_s]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Habe noch mal in meine Sourcen geschaut, ist noch einfacher und Laufzeit minimiert.
Bis auf die Hardware Filterung mit R/C Glied wird nicht gefiltert, sondern der alle 10ms gemessene ADC Wert genommen.

----
#define kReSumAh 0x0e10 // 3600 fuer mAh
volatile int16_t raw_Amph __attribute__ ((section (".noinit"))); // mAh
// in Funktion:
static int16_t subAh; // fuer Ah, laufender Strom wird aufaddiert bis Grenzwert

// --- zuerst den Stromverbrauch aufsummieren ---
subAh += adc_Val;
if (subAh > kReSumAh){ // wenn > Schwellwert
raw_Amph++; // dann [0,1Ah] + 1digit
subAh -= kReSumAh; // neuer Startwert
}
---
Dieser Code stimmt bei 100mA/digit, ansonsten einfach den Grenzwert oder die Bewertung des Wertes in raw_Amph anpassen.

Gruß Ingo

[McMorton]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Hallo,
ich habe jetzt mal eine Frage zum I2C:
Irgendwo im Programm habe ich noch einen Fehler. Das TM1000 fragt am Anfang 2x die Adressen ab und mein Pgrogramm sollte auch darauf antworten. Leider stiopt das TM1000 aber dannach. Also ist es mit irgendwas noch nicht zufrieden.
Welche Daten übertrage ich als Antwort beim start? Ist es richtig das alle Nutzdaten 0 sein müssen?
Also z.B. die PowerBox:
unsigned char writeData[16] = {0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

[csc13]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

Hallo McMorton,
was in den Nutzdaten steht ist m. E. egal. Wichtig ist, dass ein Datensatz mit der entsprechenden Adresse geschickt wird. Also kannst Du Messwerte, sofern schon vorhanden mitschicken. Das TM1000 fragt ja alle Adressen an, man muss nicht genau auf die angefragte Adresse antworten. Ich schicke auf eine Anfrage rollierend eine der Adressen, auf die ich antworten möchte zurück.

Man kann den Atmel Microcontrollern nun sagen, für welche Slave Adresse (das ist die Sensor Adresse) sie antworten sollen. Das geht für alle Adressen oder genau für eine oder zwei. Darüberhinaus kann man noch Adressbereiche einschränken, aber da unterscheiden sich die Atmel Chips schon untereinander. Wie die PICs arbeiten kann ich nicht sagen.

Für die Filterung und das Integral kannst Du gerne mal in meinen Sourcen (csc13/spektel-sensor · GitHub) nachschauen. Das sollte sich für den PIC übertragen lassen. Ich habe aber bestimmte Sachen im Excel vor berechnet und auf eine Festkommarechnung übertragen. Ich erhöhe die Werte also soweit, das ich bei 32 Bit Zahlen gerade keinen ßberlauf bekomme. Am Ende schneide ich dann auf 16 Bit Genauigkeit ab.

Ich berechne die verbrauchte Kapazität wie folgt.

• Ma ist die aktuelle Messung
• Mb ist die Messung davor
• Tab ist die Zeit zwischen den beiden Messungen in Millisekunden

So kann man rechnen:
(Ma * 2 + Mb * 2) / 2 * Tab = mA/ms
Die *2 und /2 kann man effizient durch Shiftoperationen ersetzen
Angenommen man hat die mV vom ADC schon in mA umgerechnet, was ja vom verwendeten Sensor und dem weiteren Hardwareaufbau abhängt muss man das Ergebnis nur noch durch 3600.000 teilen und erhält mA/h die man ausgeben möchte.
Hier ist es eher eine Frage des ßberlaufens und Rundens. Wenn man z. B. alle 10ms eine Messung macht und die in mA/h umrechnet wirds immer 0 sein.
Ich nutze eine Variable mit mA/ms und prüfe diese zu jeder Messung ob 3600.000 mA/ms überschritten wurden. Dann ziehe ich 3600.000 ab und rechne 1 auf die Variable mit den mA/h drauf. Diese ändert dann den Wert, der für das TM1000 benutzt wird.


Die Berechnungen finden sich in src/conf/conf_board.h da sie massgeblich von dem Board und Komponenten abhängen
Die Filter werden in der main.c eingebunden und finden sich in eigenen .h .c Files. Dort wird auch von mA/ms auf mA/h umgerechnet.

In spektel.c und .h findest Du den I2C Code.

Gruß
Christian

[csc13]

AW: Spektrum Telemetrie und alternative Sensoren/Eigenbau

FEHLER:
Es muss heissen:

(Ma + Mb) / 2 * Tab = mA/ms

Sorry, schon spät