Gast_74695
User gesperrt
Tadangos SPort Library ist vielleicht ganz hilfreich. Unter /sensors gibt es einige Beispiele.
Im OpenTX Quelltext findet man die Sensor- und Hardware-IDs.
Software und Hardware für Solarflieger
- Ersteller Holger Lambertus
- Erstellt am
Im OpenTX Quelltext findet man die Sensor- und Hardware-IDs.
merijnwijnen
User
Hallo Holger,
Das sieht alles schon gut aus. Woher hast du die Namen und was rechts vom = Zeichen steht? Ich weiss, das steht alles im Datenblatt, ist aber ziemlich unübersichtlich, hast du etwas besseres?
Zum FrSky protokol: Ich habe im Wochenende mal Vario am Empfänger gesteckt und Logic analyser angelötet. Was da passiert ist ziemlich einfach:
Ich kann also ein leeres Sensor HW ID benutzen, und bekannte Signaltypen verwenden.
Am schoensten wäre:
Gruss,
Merijn
Das sieht alles schon gut aus. Woher hast du die Namen und was rechts vom = Zeichen steht? Ich weiss, das steht alles im Datenblatt, ist aber ziemlich unübersichtlich, hast du etwas besseres?
Zum FrSky protokol: Ich habe im Wochenende mal Vario am Empfänger gesteckt und Logic analyser angelötet. Was da passiert ist ziemlich einfach:
- 57600 baud one-wire invertiertes serial, 8 bit LSB first, 1 stop bit, no parity
- Es gibt, 28 unterschiedliche Sensor HW IDs, jeder hat ein eigenes ID byte (char), wenige werden von FrSky benutzt, viele noch nicht
- Es gibt eine menge von Signal IDs, zum beispiel Vario, Höhe, Geschwindigkeit etc., jeder hat ein eigenes 2-Byte signal ID (short)
- Empfänger ruft an mit: 0x7E, HW ID
- Wenn innerhalb 11 ms nichts komt, ist die nächste Sensor dran
- Sensor reagiert innerhalb von 11 ms (normalerweise viel schneller) mit das senden vom immer nur 1 Signal:
- Type ID vom Sensor (immer 0x10, char)
- Signal ID (short)
- Daten (4 bytes, long, was da drin ist hängt vom Signal ab)
- CRC (1 byte, char)
- Alles laenger als 1 byte wird LSByte first gesendet
- Wenn 1 sensor gefunden ist (z.b. Vario), wird er zwischen zwei Polls abgefragt, also
- Sensor 1 poll
- Vario poll
- Sensor 2 poll
- Vario poll
- Wenn der sensor keine neue daten hat, sind Signal und Daten null, CRC = 0xFF. Dan weiss der Empfänger das der Sensor noch da ist aber nichts neues hat.
- Wenn ein Sensor mehrere Signale hat werden die in separate Antworten gesendet, jedesmal mit ein anderes Signal ID
- Wass passiert wenn 2 sensoren da sind weiss ich nicht, sollte aber kein wichtiger Unterschied sein vom Sensor her.
- Alle daten für 1 Signaltype aufbereiten und in ein uint_64 schieben
- Zuhören
- Auf RX Interrupt auslesen ob's eine abfrage ist und ob es den richtige Sensor ID ist
- wenn ja, uint_64 im TX schieben und ab damit
Ich kann also ein leeres Sensor HW ID benutzen, und bekannte Signaltypen verwenden.
Am schoensten wäre:
- Strom (mittels shunt und OpAmp)
- Spannung
- Zellentemperatur (LM35 in TO-92 Gehäuse, analog, unten auf eine Zelle kleben)
- Und vielleicht auch Regler daten, da weiss ich aber noch nichts davon. Kommt vielleicht später
Gruss,
Merijn
Holger Lambertus
User
Hallo Merijn
Evtl. wäre es eine Option direkt die FrSky Telemetrie am BLHeli_32 Regler zu nutzen ?
Rest schaue ich morgen mal in Ruhe. Hört alles sich nicht wild an, darf am Ende nur der MPP nicht drunter leiden.
LM35 habe ich auch in der Fläche :-) (ich glaube -"LM35D")
Evtl. wäre es eine Option direkt die FrSky Telemetrie am BLHeli_32 Regler zu nutzen ?
Rest schaue ich morgen mal in Ruhe. Hört alles sich nicht wild an, darf am Ende nur der MPP nicht drunter leiden.
LM35 habe ich auch in der Fläche :-) (ich glaube -"LM35D")
merijnwijnen
User
Hallo Holger,
Ich hatte mich noch gar nicht mit die Regler Telemetrie beschäftigt, aber du hast recht. Im Prinzip geht das Direkt. Wenn meine Regler da sind werde ich das mal versuchen. Ich habe noch nicht gefunden welche Signal ID vom ESC benutzt werden, den ich habe mehr interesse im MPP Spannung und Strom als am Regler Spannung und Strom. Mal sehen ob das ohne weiteres zusammen geht.
Dan haben wir aber für Hott noch keine Lösung. Alternative wäre um im MPP Tracker ein FrSky hub zu programmieren, und die daten dan entweder zu FrSky oder zu Hott weiter zu geben. Dan brauchen wir aber dringend den zweiten UART und dan passts nich mehr im 412. SW UART zusammen mit MPP wird schwierig, kostet zu viel Prozessorzeit.
Um MPP stabil laufen zu lassen können wir den dazu gehörigen Interupt Priorität geben (level 1). Dan kann es mal schief gehen im UART, aber wenns nur ein verlorenes packet kostet wäre das nicht so schlimm. Da hilft nur versuchen.
Gruss,
Merijn
Ich hatte mich noch gar nicht mit die Regler Telemetrie beschäftigt, aber du hast recht. Im Prinzip geht das Direkt. Wenn meine Regler da sind werde ich das mal versuchen. Ich habe noch nicht gefunden welche Signal ID vom ESC benutzt werden, den ich habe mehr interesse im MPP Spannung und Strom als am Regler Spannung und Strom. Mal sehen ob das ohne weiteres zusammen geht.
Dan haben wir aber für Hott noch keine Lösung. Alternative wäre um im MPP Tracker ein FrSky hub zu programmieren, und die daten dan entweder zu FrSky oder zu Hott weiter zu geben. Dan brauchen wir aber dringend den zweiten UART und dan passts nich mehr im 412. SW UART zusammen mit MPP wird schwierig, kostet zu viel Prozessorzeit.
Um MPP stabil laufen zu lassen können wir den dazu gehörigen Interupt Priorität geben (level 1). Dan kann es mal schief gehen im UART, aber wenns nur ein verlorenes packet kostet wäre das nicht so schlimm. Da hilft nur versuchen.
Gruss,
Merijn
Holger Lambertus
User
Hallo Merijn
Der Attiny 1624 hätte 2xUART
BLHeli "Auslesecode" dafür habe ich fertig hier liegen.
Normal liefert der Regler das Kiss-Protokoll (pdf im Anhang), 115200 Baud 70Hz - das beschäftigt den Prozessor schon mit einiges an Arbeit.
Ich hatte letztes Jahr mal Spaßeshalber einen MPP mit direkt über die ausgelesenen Daten aufgebaut, aber 70Hz war mir dann doch zu langsam (grenzwertig, bei normalen fliegen würde es reichen).
Aufgebaut war das mit einem "altem" Attiny 841, den habe ich per Osccal auf 7,372MHz runtergeregelt, so das er die 115200Baud fehlerfrei geschafft hat. Der 841 ist wunderbar, kann nur leider kein One-Wire-Update, aber Arduino-Optiboot am "dritten" (=gemappten) UART.
Man kann den UART auch bei dem 412 mappen, Ein Frame vom Regler abholen, auf Telemtrie ummappen, Telemetrie versenden, und wieder von vorne.
Bei den BLHeli32 Reglern muss man aufpassen, die kleinen haben kein Lötpad für Telemetrie (man kann direkt am Prozessor anlöten, ist aber sehr fummelig) nicht alle haben eine Stromsensor, und die meisten mit Stromsensor funktionieren erst ab 3S Lipo.
Für Telemetrie muss man ja aber auch nicht alle 70Frames abholen, da würden ja erheblich weniger reichen. Egal wie, bevor ich mir einen externen Stromsensor legen würde, dann besser das Gewicht in einen größeren Regler, der zugleich niederohmiger ist.
Der MPP ist eigentlich garnicht so anfällig, der regelt 500x die Sekunde, alle 2mS, parallel weil auch das Signal in 500Hz zu,, Regler geht. Wenn der mal etwas verzögert ist das nicht schlimm. Schlimm wäre wenn ein anderer Code kommplett blockt, so einige Arduino-Befehle schaffes es ja gut den Prozessor erheblich lange zu blockieren (darum schreibe ich das lieber in C).
- Stromsensor auslesen, auch den LM35.... Der 1624 hätte auch einen zweiten ADC-CHannel (muss ich nochmal guggen, bin nicht 100% sicher)
Der 1624 hat zusätzlich einen 12Bit ADC, der 412 hat einen 10Bit ADC.
Bei den neuen Attinys war mein Plan, den ADC Accumulator zu nutzen, der soll im Hintergrund den ADC 2mS lang lesen, Werte addieren, und sich dann per ISR melden. In der ISR nachregeln.
Der ADC der neuen Attiny hat auch eine Compare Funktion inkl eine programmierbaren Hysterese, dann müsste der RC-Wert in das Compare-Register, es würde stetig im Hintergrund verglichen, und die ISR würde dann nur auftauchen wenn tatsächlich nachgeregelt werden muss. Aber soweit bin ich im Prozessor noch nicht vorgedrungen, es ist aber beeindruckend was die kleinen Dinger können.
-----
Eine tatsächliche Alternative wäre der winzige Seeduino XIAO, die Dinger sind verfügbar, da werkelt ein leistungsfähiger 32Bit AVR SAMD21G18 drauf, 3,3V-Level, hat auch die Funktionen wir RC im Hintergrund lesen, ADC Accumulator u.s.w. 2xUart, aber einer halt nur für den USB, und einfach in der Arduino programmierbar.
Da denke ich schon länger drüber nach, was besser ist, früher war das einfacher, da gab es nicht so viel ;-)
eckstein-shop.de
Der Attiny 1624 hätte 2xUART
BLHeli "Auslesecode" dafür habe ich fertig hier liegen.
Normal liefert der Regler das Kiss-Protokoll (pdf im Anhang), 115200 Baud 70Hz - das beschäftigt den Prozessor schon mit einiges an Arbeit.
Ich hatte letztes Jahr mal Spaßeshalber einen MPP mit direkt über die ausgelesenen Daten aufgebaut, aber 70Hz war mir dann doch zu langsam (grenzwertig, bei normalen fliegen würde es reichen).
Aufgebaut war das mit einem "altem" Attiny 841, den habe ich per Osccal auf 7,372MHz runtergeregelt, so das er die 115200Baud fehlerfrei geschafft hat. Der 841 ist wunderbar, kann nur leider kein One-Wire-Update, aber Arduino-Optiboot am "dritten" (=gemappten) UART.
Man kann den UART auch bei dem 412 mappen, Ein Frame vom Regler abholen, auf Telemtrie ummappen, Telemetrie versenden, und wieder von vorne.
Bei den BLHeli32 Reglern muss man aufpassen, die kleinen haben kein Lötpad für Telemetrie (man kann direkt am Prozessor anlöten, ist aber sehr fummelig) nicht alle haben eine Stromsensor, und die meisten mit Stromsensor funktionieren erst ab 3S Lipo.
Für Telemetrie muss man ja aber auch nicht alle 70Frames abholen, da würden ja erheblich weniger reichen. Egal wie, bevor ich mir einen externen Stromsensor legen würde, dann besser das Gewicht in einen größeren Regler, der zugleich niederohmiger ist.
Der MPP ist eigentlich garnicht so anfällig, der regelt 500x die Sekunde, alle 2mS, parallel weil auch das Signal in 500Hz zu,, Regler geht. Wenn der mal etwas verzögert ist das nicht schlimm. Schlimm wäre wenn ein anderer Code kommplett blockt, so einige Arduino-Befehle schaffes es ja gut den Prozessor erheblich lange zu blockieren (darum schreibe ich das lieber in C).
- Stromsensor auslesen, auch den LM35.... Der 1624 hätte auch einen zweiten ADC-CHannel (muss ich nochmal guggen, bin nicht 100% sicher)
Der 1624 hat zusätzlich einen 12Bit ADC, der 412 hat einen 10Bit ADC.
Bei den neuen Attinys war mein Plan, den ADC Accumulator zu nutzen, der soll im Hintergrund den ADC 2mS lang lesen, Werte addieren, und sich dann per ISR melden. In der ISR nachregeln.
Der ADC der neuen Attiny hat auch eine Compare Funktion inkl eine programmierbaren Hysterese, dann müsste der RC-Wert in das Compare-Register, es würde stetig im Hintergrund verglichen, und die ISR würde dann nur auftauchen wenn tatsächlich nachgeregelt werden muss. Aber soweit bin ich im Prozessor noch nicht vorgedrungen, es ist aber beeindruckend was die kleinen Dinger können.
-----
Eine tatsächliche Alternative wäre der winzige Seeduino XIAO, die Dinger sind verfügbar, da werkelt ein leistungsfähiger 32Bit AVR SAMD21G18 drauf, 3,3V-Level, hat auch die Funktionen wir RC im Hintergrund lesen, ADC Accumulator u.s.w. 2xUart, aber einer halt nur für den USB, und einfach in der Arduino programmierbar.
Da denke ich schon länger drüber nach, was besser ist, früher war das einfacher, da gab es nicht so viel ;-)
Seeed Studio Seeeduino XIAO (Pre-Soldered) Vorgelötet - Eckstein Shop, 9,95 €
Entdecken Sie bei Eckstein Komponente eine Vielzahl an Elektronikprodukten – von epaper eink displays bis hin zu Entwicklungsbrettern wie Raspberry Pi und A
eckstein-shop.de
Zuletzt bearbeitet:
Holger Lambertus
User
Jetzt noch die Unterlagen, und der Frage zu der Schreibweise.
Die neuen Attinys haben auch eine "neue" Schreibweise, es ist ein Xmega-Kern, ich mag die Schreibweise auch nicht, und stolper da öfter, ich setze an sich immer lieber die Bits im Register direkt (XXX = 0b10101010
, aber wenn ich das teile, heißt es meist es wäre zu "kryptisch"
Beschrieben ist sie hier: AVR1000: Getting Started Writing C-code for XMEGA
One-Wire
ApplikationNote AN2658 USART in One-Wire Mode
https://www.microchip.com/content/d...s/AN2658-USART-In-One-Wire-Mode-00002658C.pdf
Vorsicht Fieße Stolperfalle, es gibt einen Fehler, der uns bei der Telemetrie voll trifft, hatte da ewig gesessen bis ich das gefunden hatte:
https://www.avrfreaks.net/forum/attiny1614-one-wire-errata-datasheet-errors
Also auch immer die Errata lesen (dazu gelernt ;-))
Ich schreibe mal die Tage meinen Hott Code mal grob Richtung FrSky um.
Und die Prozessoren muss ich Dir noch schicken :-)
Die neuen Attinys haben auch eine "neue" Schreibweise, es ist ein Xmega-Kern, ich mag die Schreibweise auch nicht, und stolper da öfter, ich setze an sich immer lieber die Bits im Register direkt (XXX = 0b10101010
, aber wenn ich das teile, heißt es meist es wäre zu "kryptisch"Beschrieben ist sie hier: AVR1000: Getting Started Writing C-code for XMEGA
One-Wire
ApplikationNote AN2658 USART in One-Wire Mode
https://www.microchip.com/content/d...s/AN2658-USART-In-One-Wire-Mode-00002658C.pdf
Vorsicht Fieße Stolperfalle, es gibt einen Fehler, der uns bei der Telemetrie voll trifft, hatte da ewig gesessen bis ich das gefunden hatte:
https://www.avrfreaks.net/forum/attiny1614-one-wire-errata-datasheet-errors
Also auch immer die Errata lesen (dazu gelernt ;-))
Ich schreibe mal die Tage meinen Hott Code mal grob Richtung FrSky um.
Und die Prozessoren muss ich Dir noch schicken :-)
