Treffpunkt DIY Multiplex Sensor-Entwickler (und die es werden wollen)
- Ersteller ingo_s
- Erstellt am
Reinhardt Werbik
User
Hallo Heinz,
Danke für den Tipp, Du hast recht, 2 oder 3 Zellen kann man problemlos an der Spannung unterscheiden.
Wenn man mit 2,8 V pro Zelle startet, das merkt man ziemlich schnell.
Der Jumper hat den Vorteil, dass ich ihn einfach nach jeder Messung abfragen und dann die Alarmschwelle berechnen kann.
Sprich es funktioniert auch dann, wenn ich den Messeingang bei schon eingeschaltetem Sensor anstecke.
Mal sehen, man müsste halt den Fall des späteren Ansteckens des Messeingangs in der SW abfangen, sollte kein Problem sein.
Den einen freien I/O Pin des ATtiny könnte man dann für eine optische Rückmeldung per LED benutzen.
Ich werde das auf jeden Fall mal implementieren, schon allein zu Übungszwecken, ich programmiere nämlich meine Sensoren in Assembler.
Gruß
Reinhardt
Danke für den Tipp, Du hast recht, 2 oder 3 Zellen kann man problemlos an der Spannung unterscheiden.
Wenn man mit 2,8 V pro Zelle startet, das merkt man ziemlich schnell.
Der Jumper hat den Vorteil, dass ich ihn einfach nach jeder Messung abfragen und dann die Alarmschwelle berechnen kann.
Sprich es funktioniert auch dann, wenn ich den Messeingang bei schon eingeschaltetem Sensor anstecke.
Mal sehen, man müsste halt den Fall des späteren Ansteckens des Messeingangs in der SW abfangen, sollte kein Problem sein.
Den einen freien I/O Pin des ATtiny könnte man dann für eine optische Rückmeldung per LED benutzen.
Ich werde das auf jeden Fall mal implementieren, schon allein zu Übungszwecken, ich programmiere nämlich meine Sensoren in Assembler.
Gruß
Reinhardt
Reinhardt Werbik
User
So, ich habe es schnell programmiert, und es funktioniert einwandfrei.
Ab 8,6 V geht der Sensor von einem 3-zelligen Akku aus, das schafft ein 2-Zeller sicher nicht.
Letztlich läuft es darauf hinaus, dass der Alarm gesetzt wird, wenn die Spannung unter 7 V (bei 3,5 V/Zelle) oder zwischen 8,6 und 10,5 V liegt.
Wenn keine Spannung an den Messeingang angeschlossen ist, gibt es somit immer Alarm, wie vorher auch (macht ja auch Sinn).
Gruß
Reinhardt
Ab 8,6 V geht der Sensor von einem 3-zelligen Akku aus, das schafft ein 2-Zeller sicher nicht.
Letztlich läuft es darauf hinaus, dass der Alarm gesetzt wird, wenn die Spannung unter 7 V (bei 3,5 V/Zelle) oder zwischen 8,6 und 10,5 V liegt.
Wenn keine Spannung an den Messeingang angeschlossen ist, gibt es somit immer Alarm, wie vorher auch (macht ja auch Sinn).
Gruß
Reinhardt
Reinhardt Werbik
User
Hallo zusammen,
in der Zwischenzeit habe ich ein bisschen an dem Projekt "kleiner Spannungssensor für E-Segler" weitergemacht.
Und zwar habe ich die Ausgabe der Minimalspannung auf einer zweiten Adresse implementiert.
Allerdings habe ich da ein wenig getrickst.
Es kommt ja durchaus vor, dass man den Messeingang erst anschließt, wenn der Sensor schon läuft.
Jedenfalls dann, wenn man die Spannung zum Messen wie ich am Balanceranschluss abgreift.
Das führt dann dazu, dass als Minimalspannung 0 V herauskommen, was sich natürlich im Flug auch nicht mehr ändert.
Das macht logischerweise wenig Sinn, also habe ich im Sensor eine Initialphase implementiert,
während der keine Minimalspannung (und kein Alarm) ausgegeben wird.
Erst wenn bei 8 aufeinanderfolgenden Messungen eine vordefinierte Minimalspannung gemessen wird,
werden Umin und Alarm "scharf geschaltet", und somit wird die oben beschriebene Situation vermieden.
(8 Messungen deshalb, damit nicht beim zittrigen Zusammenstecken doch wieder das obige Phänomen auftritt.)
Das ganze funktioniert jetzt für mich praxisgerecht.
Gruß
Reinhardt
in der Zwischenzeit habe ich ein bisschen an dem Projekt "kleiner Spannungssensor für E-Segler" weitergemacht.
Und zwar habe ich die Ausgabe der Minimalspannung auf einer zweiten Adresse implementiert.
Allerdings habe ich da ein wenig getrickst.
Es kommt ja durchaus vor, dass man den Messeingang erst anschließt, wenn der Sensor schon läuft.
Jedenfalls dann, wenn man die Spannung zum Messen wie ich am Balanceranschluss abgreift.
Das führt dann dazu, dass als Minimalspannung 0 V herauskommen, was sich natürlich im Flug auch nicht mehr ändert.
Das macht logischerweise wenig Sinn, also habe ich im Sensor eine Initialphase implementiert,
während der keine Minimalspannung (und kein Alarm) ausgegeben wird.
Erst wenn bei 8 aufeinanderfolgenden Messungen eine vordefinierte Minimalspannung gemessen wird,
werden Umin und Alarm "scharf geschaltet", und somit wird die oben beschriebene Situation vermieden.
(8 Messungen deshalb, damit nicht beim zittrigen Zusammenstecken doch wieder das obige Phänomen auftritt.)
Das ganze funktioniert jetzt für mich praxisgerecht.
Gruß
Reinhardt
Reinhardt Werbik
User
Nachdem ich jetzt schon ein paar Projekte mit Assembler gemacht habe, ist der Wunsch entstanden, doch mal was in C zu versuchen.
Also habe ich zuerst mal Atmel Studio 6.2 installiert, da ist dann alles was man bracht enthalten.
(Und noch eine ganze Menge mehr.
)
Dann habe ich meinen allerersten Spannungssensor (mit ATmega 88 und HW USART) nach C übertragen.
Ich habe zwar früher schon in verschiedenen Hochsprachen progrmmiert, aber C ist dann doch nochmal etwas anders.
Aber dank Internet kann man ja Detailfragen heutzutage recht schnell klären.
Somit hat der Spannungssensor bereits nach kurzer Zeit genau das getan, was auch die Assemblerversion macht.
(BTW: Der Code ist dabei von ca. 430 auf ca. 750 Bytes angestiegen, bei exakt gleicher Programmlogik (gleiche ISRs etc.).)
Ich habe jetzt ein bisschen Blut geleckt, denn mit C kann man halt doch vieles einfacher, schneller und übersichtlicher machen.
Daher muss sich auch der etwas intelligentere Spannungssensor mit ATtiny 25 derzeit einer C Umwandlungskur unterziehen.
Dann lassen sich weitere Änderungen halt doch leichter einbauen, besonders wenn man erst nach einiger Zeit wieder daran arbeitet.
Mal schauen, ob der dadurch entstehende Code dann noch in die 2 k Flash passt.
Aber zur Not nehme ich halt den 45er, mehr wie 4 k werden es sicher nicht werden.
Und ja, Ingo, Du hast recht gehabt.
Wenn man sich mal an die Annehmlichkeiten von C gewöhnt hat, muss man sich richtiggehend motivieren,
um wieder in die Tiefen der Assemblerprogrammierung hinabzusteigen.
Gruß
Reinhardt
Also habe ich zuerst mal Atmel Studio 6.2 installiert, da ist dann alles was man bracht enthalten.
(Und noch eine ganze Menge mehr.
)Dann habe ich meinen allerersten Spannungssensor (mit ATmega 88 und HW USART) nach C übertragen.
Ich habe zwar früher schon in verschiedenen Hochsprachen progrmmiert, aber C ist dann doch nochmal etwas anders.
Aber dank Internet kann man ja Detailfragen heutzutage recht schnell klären.
Somit hat der Spannungssensor bereits nach kurzer Zeit genau das getan, was auch die Assemblerversion macht.
(BTW: Der Code ist dabei von ca. 430 auf ca. 750 Bytes angestiegen, bei exakt gleicher Programmlogik (gleiche ISRs etc.).)
Ich habe jetzt ein bisschen Blut geleckt, denn mit C kann man halt doch vieles einfacher, schneller und übersichtlicher machen.
Daher muss sich auch der etwas intelligentere Spannungssensor mit ATtiny 25 derzeit einer C Umwandlungskur unterziehen.
Dann lassen sich weitere Änderungen halt doch leichter einbauen, besonders wenn man erst nach einiger Zeit wieder daran arbeitet.
Mal schauen, ob der dadurch entstehende Code dann noch in die 2 k Flash passt.
Aber zur Not nehme ich halt den 45er, mehr wie 4 k werden es sicher nicht werden.
Und ja, Ingo, Du hast recht gehabt.
Wenn man sich mal an die Annehmlichkeiten von C gewöhnt hat, muss man sich richtiggehend motivieren,
um wieder in die Tiefen der Assemblerprogrammierung hinabzusteigen.
Gruß
Reinhardt
Hallo Reinhardt,
wie ich sehe bist Du nun auf dem richtigen Weg ;-)
Es lohnt sich am Anfang, auch mal in das List-File zu schauen, um zu sehen wie der Compiler C nach Assembler umsetzt.
Wenn Du dich mit "C" etwas warm gelaufen hast, könnte mein universelles Sensor Parametrie Verfahren für Dich von Interesse sein.
Grüße Ingo
wie ich sehe bist Du nun auf dem richtigen Weg ;-)
Es lohnt sich am Anfang, auch mal in das List-File zu schauen, um zu sehen wie der Compiler C nach Assembler umsetzt.
Wenn Du dich mit "C" etwas warm gelaufen hast, könnte mein universelles Sensor Parametrie Verfahren für Dich von Interesse sein.
Grüße Ingo
Reinhardt Werbik
User
Hallo Ingo,
das habe ich natürlich schon getan, und zwar aus einem naheliegenden Grund.
Der 2s/3s Spannungssensor ist nämlich mittlerweile auch nach C migriert, aber natürlich funktioniert erst mal nichts.
Das hatte ich auch so erwartet, denn da der Tiny 25 keinen HW USART hat, ist ein SW UART implementiert,
dessen Timing angepasst werden muss, um wieder genau die Bitmitte beim Einlesen der Daten zu treffen.
(Das Senden müsste eigentlich passen, aber wird man zu gegebener Zeit sehen.)
Dazu habe ich mir die Assembler Files angeschaut und festgestellt, dass die ISRs vom Compiler durch Prolog und Epilog teilweise ziemlich aufgeblasen wurden.
Ob man das alles sichern muss, was der Compiler da an Push und Pop eingebaut hat, sei mal dahingestellt.
Ich werde da aber nicht mit NAKED rumfummeln, sondern muss halt mit dem Oszi ran, um das Einlesen der Bits wieder genau hinzupfriemeln.
Ich habe witzigerweise auch gleich eine Vereinfachung für die Assemblerversion entdeckt.
Ich hatte das Setzen des ADC Start Flags per Read/Modify/Write gemacht.
Beim Atmega 88 ist das notwendig, da die Adresse des ADC Kontroll-Registers jenseits der Grenze für den SBI Befehl ist.
Beim Tiny 25 ist das aber nicht so, so dass man hier das Startbit mit einem statt drei Assemblerbefehlen setzen kann.
Genau so hat der Compiler das auch umgesetzt.
Ich werde mir die Listings des vom Compiler erzeugten Assembler Codes sicher noch öfter anschauen, ist nämlich sehr interessant.
Gruß
Reinhardt
das habe ich natürlich schon getan, und zwar aus einem naheliegenden Grund.
Der 2s/3s Spannungssensor ist nämlich mittlerweile auch nach C migriert, aber natürlich funktioniert erst mal nichts.
Das hatte ich auch so erwartet, denn da der Tiny 25 keinen HW USART hat, ist ein SW UART implementiert,
dessen Timing angepasst werden muss, um wieder genau die Bitmitte beim Einlesen der Daten zu treffen.
(Das Senden müsste eigentlich passen, aber wird man zu gegebener Zeit sehen.)
Dazu habe ich mir die Assembler Files angeschaut und festgestellt, dass die ISRs vom Compiler durch Prolog und Epilog teilweise ziemlich aufgeblasen wurden.
Ob man das alles sichern muss, was der Compiler da an Push und Pop eingebaut hat, sei mal dahingestellt.
Ich werde da aber nicht mit NAKED rumfummeln, sondern muss halt mit dem Oszi ran, um das Einlesen der Bits wieder genau hinzupfriemeln.
Ich habe witzigerweise auch gleich eine Vereinfachung für die Assemblerversion entdeckt.
Ich hatte das Setzen des ADC Start Flags per Read/Modify/Write gemacht.
Beim Atmega 88 ist das notwendig, da die Adresse des ADC Kontroll-Registers jenseits der Grenze für den SBI Befehl ist.
Beim Tiny 25 ist das aber nicht so, so dass man hier das Startbit mit einem statt drei Assemblerbefehlen setzen kann.
Genau so hat der Compiler das auch umgesetzt.
Ich werde mir die Listings des vom Compiler erzeugten Assembler Codes sicher noch öfter anschauen, ist nämlich sehr interessant.
Gruß
Reinhardt
Reinhardt Werbik
User
Genauso war es, und jetzt läuft der Sensor.
Ich habe den SW UART zum Empfangen ein wenig modifiziert.
Der erste Interrupt während des Start-Bits wurde eliminiert und jetzt wird gleich in die Mitte des ersten Daten-Bits gesprungen.
Macht eigentlich eh mehr Sinn, da das Start-Bit ja bereits detektiert wurde, wenn der Bit-Takt gestartet wird.
Ich werde mir gelegentlich Deine universelle Parametrierung nochmal anschauen, Ingo.
Gruß
Reinhardt
Komme nicht weiter
Komme nicht weiter
Hallo zusammen,
ich habe auch nach längerem mal wieder meine Micrcontroller ausgegraben. Momentan arbeite ich mit einem ATmega8A auf einem STK500 mit Atmel Studio 7. Zum Senden und Empfangen nutze ich den HW UART des ATmega8. Insgesamt klappt alles auch schon besser als ich es erwartet hatte. Im Grunde genommen, kann ich dem Bus zuhören und wenn ein Byte reinkommt was ein Masterbyte sein muss darauf reagieren. Prüfen ob das empfangene Byte ein Master Byte ist wird ja mit dem Idle Line Timeout realisiert. Ich benutze dazu zwei Interrupts. Der eine wird immer dann ausgelöst, wenn ein Byte empfangen wurde und startet den Idle Line Timer immer wieder von 0. Zusätzlich zählt dieser einen Counter um eins hoch. Der zweite Interrupt wird ausgelöst, wenn der Timer 300us erreicht. Hier wird nun der Timer angehalten und geprüft, ob der Counter = 1 ist. Wenn dies der Fall ist habe ich ein Byte von einem Master empfangen.
Dieses Byte gebe ich dann an eine Funktion weiter die entscheidet ob es sich um ein Adressbyte handelt (Byte <=15) oder ein Command vom Master war (momentan noch Byte <15).
Nun zu meinem Problem. Starte ich meinen Sensor zeigt dieser kurz einen richtigen Wert an. Das heißt, ein Masterbyte wurde empfangen, als Adressbyte erkannt und ich sende meine Konstanten Sensorwerte. Immer mal wieder kommt es jedoch vor, dass der Sensor mal ein Masterbyte erkennt, dieses jedoch nicht als Adressbyte empfängt, sondern als Commandbyte. Visualisiert habe ich mir das über eine LED, die dann blinkt.
Ich komme einfach nicht dahinter was da verkehrt läuft. Eigentlich dürfte ich ha garkeine anderen Masterbytes als Adressbytes Empfangen, das der Master ausschließlich Adressbytes senden. Das habe ich auch schon über eine USB-UART-Bridge und Hterm mitgeloggt. Irgendwo muss also ein Fehler meiner Masterbyte Erkennung sein (denke ich). Jedenfalls ist meine einzige Erklährung, dass der Sensor ein Sensorbyte als Masterbyte interpretiert.
Alles schwierig zu erklären. Hier mal noch der Code von meinen Interrups. Vielleicht sieht einer von euch auf anhieb den Fehler.
Wichtig ist vlt noch zu sagen, dass ich momentan noch den RX und TX Pin des Sensors direkt miteinander verbunden habe. Um zu verhindern, dass der TX Pin den Bus auf high zieht, wenn keine Daten im gesendet werden sollen, wird dieser nur aktiviert, wenn auch wirklich gesendet werden soll. Mein Timer Interrupt wird durch einen Compare Match ausgelöst. Mein uC taktet mit 8Mhz, der Prescaler des 16-bit Timers steht auf 1. Demnach löst der Interrupt aus, wenn der Timerstand etwa 2400 erreicht hat. (8MHz^-1 = 0,125us zwischen jedem Timer Count. 300us/0.125us=2400) Evtl. stimmt meine Rechnung auch nicht. Wenn ich den Compare Interrupt Wert auf z.B. 5000 erhöhe, kommt es im übrigen seltener dazu, dass ein falschen Masterbyte erkannt wird.
So viel unverständlicher Text. Würde mich trotzdem freuen, wenn jemand durchsteigt und mir helfen kann
. Versuche auch gerne nochmal mich klarer auszudrücken.
Liebe Grüße
Fabian
Komme nicht weiter
Hallo zusammen,
ich habe auch nach längerem mal wieder meine Micrcontroller ausgegraben. Momentan arbeite ich mit einem ATmega8A auf einem STK500 mit Atmel Studio 7. Zum Senden und Empfangen nutze ich den HW UART des ATmega8. Insgesamt klappt alles auch schon besser als ich es erwartet hatte. Im Grunde genommen, kann ich dem Bus zuhören und wenn ein Byte reinkommt was ein Masterbyte sein muss darauf reagieren. Prüfen ob das empfangene Byte ein Master Byte ist wird ja mit dem Idle Line Timeout realisiert. Ich benutze dazu zwei Interrupts. Der eine wird immer dann ausgelöst, wenn ein Byte empfangen wurde und startet den Idle Line Timer immer wieder von 0. Zusätzlich zählt dieser einen Counter um eins hoch. Der zweite Interrupt wird ausgelöst, wenn der Timer 300us erreicht. Hier wird nun der Timer angehalten und geprüft, ob der Counter = 1 ist. Wenn dies der Fall ist habe ich ein Byte von einem Master empfangen.
Dieses Byte gebe ich dann an eine Funktion weiter die entscheidet ob es sich um ein Adressbyte handelt (Byte <=15) oder ein Command vom Master war (momentan noch Byte <15).
Nun zu meinem Problem. Starte ich meinen Sensor zeigt dieser kurz einen richtigen Wert an. Das heißt, ein Masterbyte wurde empfangen, als Adressbyte erkannt und ich sende meine Konstanten Sensorwerte. Immer mal wieder kommt es jedoch vor, dass der Sensor mal ein Masterbyte erkennt, dieses jedoch nicht als Adressbyte empfängt, sondern als Commandbyte. Visualisiert habe ich mir das über eine LED, die dann blinkt.
Ich komme einfach nicht dahinter was da verkehrt läuft. Eigentlich dürfte ich ha garkeine anderen Masterbytes als Adressbytes Empfangen, das der Master ausschließlich Adressbytes senden. Das habe ich auch schon über eine USB-UART-Bridge und Hterm mitgeloggt. Irgendwo muss also ein Fehler meiner Masterbyte Erkennung sein (denke ich). Jedenfalls ist meine einzige Erklährung, dass der Sensor ein Sensorbyte als Masterbyte interpretiert.
Alles schwierig zu erklären. Hier mal noch der Code von meinen Interrups. Vielleicht sieht einer von euch auf anhieb den Fehler.
Wichtig ist vlt noch zu sagen, dass ich momentan noch den RX und TX Pin des Sensors direkt miteinander verbunden habe. Um zu verhindern, dass der TX Pin den Bus auf high zieht, wenn keine Daten im gesendet werden sollen, wird dieser nur aktiviert, wenn auch wirklich gesendet werden soll. Mein Timer Interrupt wird durch einen Compare Match ausgelöst. Mein uC taktet mit 8Mhz, der Prescaler des 16-bit Timers steht auf 1. Demnach löst der Interrupt aus, wenn der Timerstand etwa 2400 erreicht hat. (8MHz^-1 = 0,125us zwischen jedem Timer Count. 300us/0.125us=2400) Evtl. stimmt meine Rechnung auch nicht. Wenn ich den Compare Interrupt Wert auf z.B. 5000 erhöhe, kommt es im übrigen seltener dazu, dass ein falschen Masterbyte erkannt wird.
Code:
ISR(USART_RXC_vect){
last_byte = UDR;
Timer_reset(); // Timer auf 0 setzten
Timer_start(); // Timer starten
received_bytes_counter ++; // zählt mit wie viele Bytes seit dem letzte Idle Line Timeout empfangen wurden // speichert das letzte empfangene Byte
}
ISR(TIMER1_COMPA_vect){
UCSRB &= ~(1 << RXEN); // RX deaktivieren
UCSRB |= (1 << TXEN); // TX aktivieren
Timer_stop();
if(received_bytes_counter == 1){
mb_last_Byte_of_Master(last_byte); // Diese Funktion entscheidet ob es sich um ein Adressbyte oder Commandbyte handelt
received_bytes_counter = 0;
}
else{ // Wenn received_bytes_counter != 1 wurde das Byte nicht vom Master gesendet
received_bytes_counter = 0;
}
UCSRB &= ~(1 << TXEN); // TX deaktivieren um zu verhindern, dass er den Bus auf high zieht
UCSRB |= (1 << RXEN); // RX aktivieren
}So viel unverständlicher Text. Würde mich trotzdem freuen, wenn jemand durchsteigt und mir helfen kann
. Versuche auch gerne nochmal mich klarer auszudrücken.Liebe Grüße
Fabian
Externer Quarz
Externer Quarz
Hi,
ich habe heute noch ein wenig rumprobiert und mal einen externen 8Mhz Quarz verwendet. Bis jetzt hatte ich immer den internen des ATmega8 benutzt. Mit dem externen Quarz habe ich bis jetzt noch nicht ein falsches Bit empfangen. Anscheinend war das also das Problem. Ich werde die Tage mal noch etwas weiter basteln und dann evtl. berichten, wenn ich was vorzuzeigen habe. Mein Ziel ist es im übrigen einen Staudruck Sensor zur Geschwindigkeitsmessung zu bauen. Bis dahin ist es aber noch ein langer Weg.
LG
Externer Quarz
Hi,
ich habe heute noch ein wenig rumprobiert und mal einen externen 8Mhz Quarz verwendet. Bis jetzt hatte ich immer den internen des ATmega8 benutzt. Mit dem externen Quarz habe ich bis jetzt noch nicht ein falsches Bit empfangen. Anscheinend war das also das Problem. Ich werde die Tage mal noch etwas weiter basteln und dann evtl. berichten, wenn ich was vorzuzeigen habe. Mein Ziel ist es im übrigen einen Staudruck Sensor zur Geschwindigkeitsmessung zu bauen. Bis dahin ist es aber noch ein langer Weg.
LG
k_wimmer
User
Kleiner Exkurs ins Datenblatt
Kleiner Exkurs ins Datenblatt
Hallo Fabian,
da ich nun auch offiziell zu diesen Controllern etwas sagen darf, möchte ich dir nahelegen dass du dir mal das Datenblatt des ATMega8 mal genauer anschaust.
Da findest du dann auf Seite 270 folgenden Graph:
Da siehst du dann, dass je nach Spannung und Temperatur du weit über die max. Toleranz einer RS232 mit +/-2% rausläufst.
Da ist es nicht verwunderlich, dass du keine Übertragung hin bekommst.
Kleiner Exkurs ins Datenblatt
Hallo Fabian,
da ich nun auch offiziell zu diesen Controllern etwas sagen darf, möchte ich dir nahelegen dass du dir mal das Datenblatt des ATMega8 mal genauer anschaust.
Da findest du dann auf Seite 270 folgenden Graph:
Da siehst du dann, dass je nach Spannung und Temperatur du weit über die max. Toleranz einer RS232 mit +/-2% rausläufst.
Da ist es nicht verwunderlich, dass du keine Übertragung hin bekommst.
Reinhardt Werbik
User
Hallo Fabian,
auf Anhieb sind mir folgende Dinge aufgefallen, die ich vielleicht ändern würde.
Ich würde für den Idle Line Timeout nicht den 16-Bit Timer "vergeuden".
Vielleicht brauchst Du den mal für eine Sensor-Applikation (z.B. um Zeiten zu messen).
Ein 8-Bit Timer mit entsprechend eingestelltem Vorteiler tut es auch.
300 µs sind an der unteren Grenze für den Timeout, nimm 400 bis 600 als Timeout.
Die echten Sensoren warten glaube ich sogar noch wesentlich länger, bevor sie antworten.
Unterprogrammaufrufe in ISRs sind eher sub-optimal, da sie einen signifikanten Overhead an zusätzlichen Befehlen erzeugen,
den man sich in einer ISR nicht immer leisten kannn, nur mal so als Anregung.
Ich werde mal gelegentlich meine MSB C-Module anschauen, ob da signifikante Unterschiede zu Deinem Code sind.
Gruß
Reinhardt
auf Anhieb sind mir folgende Dinge aufgefallen, die ich vielleicht ändern würde.
Ich würde für den Idle Line Timeout nicht den 16-Bit Timer "vergeuden".
Vielleicht brauchst Du den mal für eine Sensor-Applikation (z.B. um Zeiten zu messen).
Ein 8-Bit Timer mit entsprechend eingestelltem Vorteiler tut es auch.
300 µs sind an der unteren Grenze für den Timeout, nimm 400 bis 600 als Timeout.
Die echten Sensoren warten glaube ich sogar noch wesentlich länger, bevor sie antworten.
Unterprogrammaufrufe in ISRs sind eher sub-optimal, da sie einen signifikanten Overhead an zusätzlichen Befehlen erzeugen,
den man sich in einer ISR nicht immer leisten kannn, nur mal so als Anregung.
Ich werde mal gelegentlich meine MSB C-Module anschauen, ob da signifikante Unterschiede zu Deinem Code sind.
Gruß
Reinhardt
Stefan Kähne
User
Hallo zusammen,
ich hatte gerade eine Idee für einen DIY Sensor als ich mich mit meinem Segler beschäftigt habe. Ich benutze derzeit immer mein Unilog2 als Variometer. Allerdings gibt es hierbei keine TEK (Totalenergiekompensation), was die Nutzung in der Thermik nicht so ganz einfach macht. Der Einbau einer TEK-Lösung ist recht aufwendig. Man benötigt eine gute Düse, Schläuche und eine sinnvolle Einbauposition. Das ganze muss dann auch gut kalibriert sein.
Folgende Idee hätte ich:
-Arduino (Nano) Board (so klein und günstig wie möglich)
-Drucksensor (statischer Druck, möglichst direkt am Board wie auch beim Unilog)
-Beschleunigungssensor (eine Richtung würde reichen)
Für die Totalenergiekompensation ist immer die Kentniss über Höhenänderung und Geschwindigkeitsänderung notwendig. Beides könnte man nun mit den Sensoren errechnen. Der Rest müsste Mathematik sein.
Nachdem ich schon mit meinem Arduino problemlos Sensordaten für die MPX-Schnittstelle gernerieren konnte, müsste ich nun nur brauchbare Sensoren finden. Hat jemand eine solche Lösung schonmal irgendwo gesehen?
Am Ende hätte man einen TEK-Kleinstsensor, der relativ unabhängig im Flieger verbaut werden kann. Ledigleich die Beschleuningungsachse muss in Flugrichtung zeigen. Keine Schläuche, keine verstopften Düsen die bei Unachtsamkeit abbrechen können.
ich hatte gerade eine Idee für einen DIY Sensor als ich mich mit meinem Segler beschäftigt habe. Ich benutze derzeit immer mein Unilog2 als Variometer. Allerdings gibt es hierbei keine TEK (Totalenergiekompensation), was die Nutzung in der Thermik nicht so ganz einfach macht. Der Einbau einer TEK-Lösung ist recht aufwendig. Man benötigt eine gute Düse, Schläuche und eine sinnvolle Einbauposition. Das ganze muss dann auch gut kalibriert sein.
Folgende Idee hätte ich:
-Arduino (Nano) Board (so klein und günstig wie möglich)
-Drucksensor (statischer Druck, möglichst direkt am Board wie auch beim Unilog)
-Beschleunigungssensor (eine Richtung würde reichen)
Für die Totalenergiekompensation ist immer die Kentniss über Höhenänderung und Geschwindigkeitsänderung notwendig. Beides könnte man nun mit den Sensoren errechnen. Der Rest müsste Mathematik sein.
Nachdem ich schon mit meinem Arduino problemlos Sensordaten für die MPX-Schnittstelle gernerieren konnte, müsste ich nun nur brauchbare Sensoren finden. Hat jemand eine solche Lösung schonmal irgendwo gesehen?
Am Ende hätte man einen TEK-Kleinstsensor, der relativ unabhängig im Flieger verbaut werden kann. Ledigleich die Beschleuningungsachse muss in Flugrichtung zeigen. Keine Schläuche, keine verstopften Düsen die bei Unachtsamkeit abbrechen können.
tembaine
User
M-Link Vario Selbstbau
M-Link Vario Selbstbau
Hallo
Mit Interesse habe ich eure Beiträge gelesen, da sind richtige Profis am Werk.
Ich suche ein Vario für M-Link, das ich nachbauen könnte. Platinen ätzen und SMD löten sind für mich kein Problem.
Hat jemand von euch so ein Projekt, das ich verwenden dürfte?
Gruss
René
M-Link Vario Selbstbau
Hallo
Mit Interesse habe ich eure Beiträge gelesen, da sind richtige Profis am Werk.
Ich suche ein Vario für M-Link, das ich nachbauen könnte. Platinen ätzen und SMD löten sind für mich kein Problem.
Hat jemand von euch so ein Projekt, das ich verwenden dürfte?
Gruss
René
kalle123
User
Hallo René.
Schau einfach mal hier http://www.rclineforum.de/forum/boa...teuerungen-und-telemetrie/311808-openxsensor/ rein.
Code findet sich hier https://github.com/openXsensor/openXsensor Einfach "Branch master" runter laden und entpacken. Die ganze notwendige Doku findet sich eigentlich in der Datei oXs_config_description.h
Der eigentliche thread zum Thema oXs findet sich -> http://openrcforums.com/forum/viewforum.php?f=86
Lohnt sich ...
Gruß KH
Schau einfach mal hier http://www.rclineforum.de/forum/boa...teuerungen-und-telemetrie/311808-openxsensor/ rein.
Code findet sich hier https://github.com/openXsensor/openXsensor Einfach "Branch master" runter laden und entpacken. Die ganze notwendige Doku findet sich eigentlich in der Datei oXs_config_description.h
Der eigentliche thread zum Thema oXs findet sich -> http://openrcforums.com/forum/viewforum.php?f=86
Lohnt sich ...
Gruß KH
PalmZ
User
Tanksensor
Hallo,
ich muß dieses Thema noch einmal aufgreifen. Ich habe noch einige Methanoler u. hätte gerne einen Füllstandssensor.
Kennt jemand eine Möglichkeit den Hitec HTS-Fuel Fuel Level Sensor (55835) an das M-link System anzuschließen?
Gibt es eine Möglichkeit über SM-Modellbau ?
Vielen Dank
Helmut
Hallo,
ich muß dieses Thema noch einmal aufgreifen. Ich habe noch einige Methanoler u. hätte gerne einen Füllstandssensor.
Kennt jemand eine Möglichkeit den Hitec HTS-Fuel Fuel Level Sensor (55835) an das M-link System anzuschließen?
Gibt es eine Möglichkeit über SM-Modellbau ?
Vielen Dank
Helmut
Hallo René
Habe schon vor einiger Zeit einen Vario gebaut und ihne in diversen Modellen eingesetzt,
funktioniert soweit auch zu meiner Zufriedenheit.
Er besteht aus:
- BMP280 Sensor
- ARM STM32G031J6
- Platine 18x25 mm
Gibt folgende Werte via MSB-Telemetrie aus:
- Höhe über Startpunkt
- Vario
- max. Höhe
- max. Vario
- min. Vario
- Temperatur
Das Binary bzw. den Code (Forth) könnte ich bereitstellen
anbei das Layout im Anhang
Gruss Ralph
