MSBPackage Software Library für Multiplex Sensor Bus an Arduino Plattform

Hallo zusammen,

im Thread http://www.rc-network.de/forum/showthread.php/281006-M-Link-Sensor-mit-Arduino?p=2717156#post2717156 habe ich ja erwähnt das ich meine MSB Library für die Arduino Plattform http://www.arduino.cc/ unter der GPL für öffentlich verfügbar machen möchte. Mittlerweile habe ich die Testversion der Library an die ersten Interessenten verschickt.

Dieser Thread soll als Feedback- und Diskussionplattform für die Library dienen. Hier eine Übersicht über die Funktionalität:


Einführung

MSBPackage ist Arduino Library für die Kommunikation mit dem Multiplex Service Bus (MSB). Sie implementiert das Protokoll in Software – es wird also nicht der Hardware UART des ATmega Prozessor benutzt – und benötigt auch nur einen einzigen Digital-Pin, auf dem das MSB-Halbduplex Protokoll realisiert wird.
Die Software Realisierung hat gegenüber der Nutzung des UART mehrere Vorteile:
  • Der Hardware-UART bleibt für die Kommunikation mit dem Entwicklungsrechner frei – dies erhöht den Komfort bei der Entwicklung ungemein.
  • Die Open-Collector „Wired-AND“ Logik des MSB lässt sich ohne zusätzliche Hardware realisieren. Bei Nutzung des Hardware UART müsste man dem TX Ausgang über eine entsprechende Hardwareschaltung (Open Collector Treiber) kompatibel zum MSB machen.
Features
  • Direkte Anschluss an den MSB ohne Zusatzhardware
  • MSB Monitor Funktionen (z.B. für Datenlogging, Diagnose)
  • Komfortable Implementierung des MSB „ldle Line Multiprocessor Protocols“ um Werte auf den MSB auszugeben. Dabei muss der Anwender der Library sich nicht mit den Details des MSB auseinandersetzen. Das richtige Timing wird automatisch eingehalten.
  • Multi-Adressen Unterstützung – die Library kann automatisch Werte für mehrere MSB Adressen auf den Bus geben

Voraussetzungen für die Library

  • Die Library wird zur Zeit nur noch mit Ardunio 1.0 weiterentwickelt und getestet. Ältere Ardunio Versionen sollten evtl. auch funktionieren (der Code enthält an einigen Stellen entsprechende „#ifdef“ Direktiven).
  • Getestet ist sie mit dem Arduino Uno Board, dem Ardunio Pro Mini 5V/16Mhz sowie Pro Mini 3,3V / 8Mhz von Sparkfun
  • Die Unterstützung von 3,3V/ 8Mhz ist wichtig, da sich diese Komponenten besser mit modellflugüblichen Stromversorgungen (z.B. 4 Zeller NiXX Akkus) vertragen.
 

Volker Cseke

Moderator
Teammitglied
Hallo Thomas,

ich mache meine Versuche eigentlich immer mit einem Nano V3 328. Spricht was dagegen, mit dem mal die deine LIB zu probieren?


Viele Grüße

Volker
 
Hallo Thomas,

ich mache meine Versuche eigentlich immer mit einem Nano V3 328. Spricht was dagegen, mit dem mal die deine LIB zu probieren?

Sollte auch gehen - des Pro Mini ist dem Nano sehr ähnlich (nur einfach viel billiger - kostet nur ca. 15 EUR :) )
Schick mir Deine EMail Adresse per PN - dann sende ich Dir heute abend die Files.

Gruß
Thomas
 
MSBPackage Beispielprogramme

MSBPackage Beispielprogramme

Hallo zusammen,

ich habe gerade wg. der Problemmeldung eines Benutzers festgestellt, dass die beiden Beispielprogramme in der ausgelieferten Version verschiedene Pins für den MSB Datenanschluss verwenden.
Die MSBLibMonitorDemo verwendet Pin 4, das MSBLibTest Programm Pin 2.

Wenn man beides ausprobiert muss man das beachten, also am besten eines der Programme an den bevorzugten Pin anpassen.

Das Statement

Code:
MSBProcess myMSB(2);  // New Single Pin Mode

in den Sketches definiert jeweils den verwendeten Pin (in diesem Fall also Digital Pin 2).

Gruß
Thomas
 
Hallo! Gibt's schon was neues von der Library?

In der Flugsaison habe ich nicht viel gemacht - aber dafür wurden ein paar damit gebaute Sensoren dem Praxistest unterzogen. Ein Vereinskollege hat z.B. einen Drehzahlsensor gebaut, der direkt den Zündimpulsgeber vom DLE55 ausliest. Funktioniert sehr gut. Die Schaltung kann als "Abfallprodukt" auch Spannung und Temparatur messen - und dient damit als "Motor-Monitor".

Gruß
Thomas
 
MSBPackage Beispielprogramme

MSBPackage Beispielprogramme

Hallo Thomas,

ich möchte mit dem arduino nano einen Sensor für den MSB bauen/entwicklen. Da wäre Deine MSBPackage bzw. Beispielprogramme sehr hilfreich.
Kannst Du mir diese zusenden?

Viele Grüße

Reinhold
 
MSBPackage Beispielprogramme

MSBPackage Beispielprogramme

Hallo Thomas,
vielen Dank für den link auf die lib und die Beispielprogramme.
Compilieren klappt.
ich werde erst mal einen Pegelwandler für den nano besorgen.
Ich gehe davon aus, dass zumindest das Monitoring des MSB ohne weitere Modifikation auf dem nano funktionieren sollte.
Gruß
rimsail
 
MSBPackage Beispielprogramme

MSBPackage Beispielprogramme

Hallo Thomas,

Ich habe Deine Beispielprogramme ausprobiert. Sowohl Monitoring als auch senden von Spannungswerten wird an der seriellen Schnittstelle bzw. am Senderdisplay angezeigt.
Eigenen Code habe ich noch nicht erstellt, aber ich wollte wenigtsens mal ein Echo geben und mich bedanken.
Ich habe auch versucht auf deine PN zu antworten, das scheint aber nicht zu klappen. Die Antwort ist nach Absenden "verschwunden".
Gruß
Reinhold
 
MSB Arduino

MSB Arduino

hallo, ich bin zwar kein hobbypilot,aber stark an Telemetrie und Sensorik interessiert. Mein Ziel besteht darin, verschiedene Sensoren in einen Rasentraktor einzubauen. Mit rpm M-link und Spannungssensoren in Verbindung mit einem Simprop Gigalogger funktioniert das schon. Für andere Messaufgaben (Fahrstrecke, Benzinverbrauch) habe ich zwar Sensoren (Arduino) vorbereitet, weis aber nicht, wie ich diese in den MSB bekomme. Bei einigen Sketches wird eine MSB Libary eingefügt, ich finde diese aber nirgends. Da ich allerdings nicht allzu viel Ahnung von Elektronik habe :confused:und mich auch erst mit 70 mit diesen Dingen beschäftige wäre ein Beispiel für die Einbindung von Selbstbausensoren in den MSB für mich sinnvoll.

Voraus vielen Dank
fincaminor
 
MSBPackage Library bei Bitbucket verfügbar

MSBPackage Library bei Bitbucket verfügbar

Hallo zusammen,

seit ich im Jahr 2012 meine MSB Library hier im Forum erwähnt habe, habe ich ca. 50 Anfragen dazu bekommen. Bisher habe ich die Library (bzw. einen Download Link) dann immer einzeln versendet. Grund war, dass ich einfach nicht dazu kam, die Library irgendwo öffentlich abzulegen.

Nachdem ich aber in den letzten Tagen wieder mehrere Anfragen bekommen habe, habe ich die Library nun bei bitbucket.org veröffentlicht.

Der Link ist:

https://bitbucket.org/thornschuh/msbpackage-public-release/overview

Bitbucket ist, ähnlich wie GitHub, ein Cloud basierte Soruce Repository. Wer sich mit git auskennt, kann das Repo einfach auf seinen Rechner klonen.
Da ich vermute, dass viele der Interessenten sich nicht unbedingt mit git auskennen, gibt es dort auch ein ZIP-File zum Download (im Actions-Panel links unter Downloads (letzter Punkt)

Es enthält alle Dateien zum Auspacken und eine kurze Installationsanleitung.

Ich habe heute festgestellt, dass sich die Library nicht mehr mit der neusten Arduino IDE übersetzen ließ. Dieses Problem habe ich behoben.
Ich konnte die Library heute nur nicht auf die Schnelle mit einem Mutiplex Empfänger testen (meine Empfänger sind zur Zeit gerade alle irgendwo eingebaut...). Das hole ich in den nächsten Tagen nach.

Desweiteren hat sich die Arduino Library Verwaltung wohl etwas geändert - meine Library funktioniert allerdings trotzdem noch, wenn man den libararies-Ordner in dem ZIP wie in der Anleitung beschrieben auspackt.

Gruß
Thonas
 
Hallo Thomas,

danke erstmal das du dir die ganze Mühe gemacht hast und deine Library veröffentlicht hast. Ich hab jedoch noch ein paar Fragen und bin auch nicht so gut darin was das ganze Programmieren angeht.

Mein Ziel ist es mit dem GPS-Logger2 von SM-Modellbau (Telemetrieprotokoll eingestellt auf den Multiplex-Sensorbus; der Baustein ist ein Sensor) und einem Arduino ein Vario/GPS fürs Gleitschirmfliegen zu bauen. Soweit ich das Multiplexprotokoll verstanden hab, muss ein Master (Modellflug-Empfänger) einfach nur die Adresse des jeweiligen Sensors als Byte senden (z.b. 3). Der Sensor antwortet daraufhin.

Jetzt kommt deine Library ins Spiel. Kann man mit ihr auch Sensoren abfragen? D.h. eine Funktion aufrufen, die den Sensor Nr. 3 abfragt? Oder benutzt man die Library eher, um quasi als Sensor zu arbeiten? Wenn ich dein Beispielprogramm, den Monitor kompiliere, dann bekomme ich leider keine Daten.

Danke!

Viele Grüße
Sebastian
 
Jetzt kommt deine Library ins Spiel. Kann man mit ihr auch Sensoren abfragen? D.h. eine Funktion aufrufen, die den Sensor Nr. 3 abfragt? Oder benutzt man die Library eher, um quasi als Sensor zu arbeiten? Wenn ich dein Beispielprogramm, den Monitor kompiliere, dann bekomme ich leider keine Daten.
Ohne einen Multiplex Empfänger am Bus, der den "Master" darstellt funktioniert meine Library nicht. Sie ist in der Tat dafür gedacht, Sensoren zu implementieren. Die "Monitor" Funktion ermöglicht nur die Daten anderer Sensoren, die mit am Bus hängen, mitzuhören. Damit könnte man z.B. einen Datenlogger bauen.

Das MSB Protokoll funktioniert in der Form, dass der Empfänger regelmässig Abfragen für alle erlaubten 16 MSB Busadressen sendet. Ein Sensor der eine der Adressen belegt, muss dann innerhalb eine definierten Zeitspanne mit einem Sensor Paket antworten.
Das kann man auch relativ einfach bauen:
Die Abfage ist einfach ein Byte mit den Werten 0..16 für die 16 möglichen Sensoradressen. Willst Du also den Sensor 3 abfragen, musst Du nur den Wert 3 (0x03) auf den Bus senden. Danach musst Du nur warten, dass 3 Bytes zurückommen, die sind das Datenpaket des Sensors. Wie das aufgebaut ist, und wie man es dekodiert, siehst Du in der Klasse MSBPackage meiner Library.


Gruß
Thomas
 
Tank (9) Werte in Prozent .

Tank (9) Werte in Prozent .

Hallo Thomas,
ich habe jetzt die Lib mal eingebunden. Mit den beiden Demos ist das auch sehr verständlich. Dickes Lob an dieser Stelle.
Ich habe aber noch 1 kleine Fragen und ich bin evtl. auf ein Problem gestoßen:
Ich habe einen kleinen Festspannungsregler als AREF und messe über einen Spannungsteiler die gesamte Zellspannung und errechne daraus die "Füllung". Dabei ist mir aufgefallen: Wenn diese Werte irgendwo bei ca. 80% oder mehr liegen, fängt die Anzeige auf dem Sender an non stop zwichen 80% und ca. 23% zu sprigen. ich habe erst den Fehler in der Schatung oder der Messlogik gesucht. Leider ohne Erfolg. Wenn ich in dem Demo direkt 80% ( also P1.setValue(80) ) setze besteht das Phänomen weiterhin ( habe auch alle DEBUG Ausgaben aus um evtl. timing Probleme auzuschließen). Das gleiche ist mir jetzt bei der Spannung aufgefallen. Bei z.B 19.2 (192 ) springt die Anzeige immer mal wieder auf 12.8. Gehe ich mit den Werten wieder aus dem Bereich raus ist alles OK. Ich hatte bei meiner eigenen Version auch so ein Problem, habe aber das nie gerafft warum. Meine vermutung war das ich bei dem trennen und shiften inkl. Arlamflag immer wieder mal nen überlauf hatte.
Eine Frage habe ich noch. Ich habe gesehen dass das Alarmflag bei dir zwar abgearbeitet wird aber wie rufe ich das auf.

Mir ist gerage eingefallen das es reichen könnte den Wert mit &1 zu verknüpfen um den Alarm zu setzen. Das probier ich gleich mal aus.

Gruß Marco und eine schönen Sonntag wünsche ich.


NACHTRAG: Den Alarm habe ich schon mal gefunden. War natürlich in der MSBPackage.h dokumentiert.
***Für die die so blind sind wie ich: z.B. P1.setAlarm(1) oder auch P1.setAlarm(true)
 
Dabei ist mir aufgefallen: Wenn diese Werte irgendwo bei ca. 80% oder mehr liegen, fängt die Anzeige auf dem Sender an non stop zwichen 80% und ca. 23% zu sprigen. ich habe erst den Fehler in der Schatung oder der Messlogik gesucht. Leider ohne Erfolg. Wenn ich in dem Demo direkt 80% ( also P1.setValue(80) ) setze besteht das Phänomen weiterhin ( habe auch alle DEBUG Ausgaben aus um evtl. timing Probleme auzuschließen).

Hallo Marco,
werde mal versuchen, dass bei mir zu reproduzieren (heute abend - jetzt gehe ich lieber auf den Flugplatz :)).
Es sieht nach einem Bitshift Problem aus: Dezimal 80 wird auf dem MSB als 10100000 00000000 gesendet, 23 enspricht 00101110 00000000. Die Bitfolge "101" ist demnach um 2 Bits verschoben. Ich würde dann zwar eher eine Decodierung als 00101000 (würde dekodiert dezimal 20 entsprechen) erwarten, aber zumindest ist der Wert nicht ganz unplausibel.


Grundsätzlich besteht bei den Arduinos ein Problem: Die üblichen CPU Taktraten von 8 oder 16Mhz, erlauben keine exakte Abbildung der 38400Bit/sec des MSB. Es bleibt also immer ein leichter Timingfehler. Zusätzlich hängt die Softwareimplementierung auch vom generierten Code des Compilers ab - ich habe die Library seinerzeit mit avr-gcc 4.3 entwickelt, in der Arduino 1.6 IDE ist ein neuerer avr-gcc enthalten (weiß jetzt die Version gerade nicht im Kopf).
Jedenfalls musste ich schon früher mal mit dem Timing Parametern der Softserial rumspielen.
In meinen Paket ist ja eine "gepatchte" NewSoftSerial.cpp/h enthalten. Im cpp. File steht ab Zeile 81 der folgende Code:

Code:
#if F_CPU == 16000000


static const DELAY_TABLE PROGMEM table[] =
{
  //  baud    rxcenter   rxintra    rxstop    tx
  { 115200,   1,         17,        17,       12,    },
  { 57600,    10,        37,        37,       33,    },
#ifdef MSB_PATCHES
  { 38400,    25,        55,        55,       54,    },
#else
  { 38400,    25,        57,        57,       54,    },
#endif
  { 31250,    31,        70,        70,       68,    },
  { 28800,    34,        77,        77,       74,    },
  { 19200,    54,        117,       117,      114,   },
  { 14400,    74,        156,       156,      153,   },
  { 9600,     114,       236,       236,      233,   },
  { 4800,     233,       474,       474,      471,   },
  { 2400,     471,       950,       950,      947,   },
  { 1200,     947,       1902,      1902,     1899,  },
  { 300,      3804,      7617,      7617,     7614,  },
};


const int XMIT_START_ADJUSTMENT = 5;


#elif F_CPU == 8000000


static const DELAY_TABLE table[] PROGMEM =
{
  //  baud    rxcenter    rxintra    rxstop  tx
  { 115200,   1,          5,         5,      3,      },
  { 57600,    1,          15,        15,     13,     },
#ifdef MSB_PATCHES
  { 38400,    2,         25,        26,     22,    },
#else
  { 38400,    2,          25,        26,     23,     },
#endif
  { 31250,    7,          32,        33,     29,     },
  { 28800,    11,         35,        35,     32,     },
  { 19200,    20,         55,        55,     52,     },
  { 14400,    30,         75,        75,     72,     },
  { 9600,     50,         114,       114,    112,    },
  { 4800,     110,        233,       233,    230,    },
  { 2400,     229,        472,       472,    469,    },
  { 1200,     467,        948,       948,    945,    },
  { 300,      1895,       3805,      3805,   3802,   },
};

Das sind die Timingparameter für 8 und 16Mhz CPU Takt. Du kannst mal mit den Werten in den Zeilen hinter dem #ifdef MSB_PATCHES "rumspielen". In Deinem Fall mit dem TX-Parameter (dem letzten Wert der Zeile). Einfach mal um 1 rauf- und/oder runtersetzen und sehen ob es besser wird.

Gruß
Thomas
 
Hallo,

ich bin jetzt erst auf dieses Thread gestoßen und bin begeistert von den neuen Möglichkeiten. Ich versuche seit geraumer Zeit eine Möglichkeit zu finden, wie ich die Telemetriedaten aus meinem Ardupilot in den MSB speise. Bisher habe ich leider keine Möglichkeit hierzu gefunden. Soweit ich weiß ist der Ardupilot Mega 2.5 (Plane-Firmware) ziemlich vollgepackt, so dass die Entwickler sogar einige alte Features, wie z.B. die Kamerasteuerung mit der letzten Version rausnehmen mussten. Daher glaube ich nicht, dass man den Code noch mit in den Ardupilot reinpacken kann. Aber: Sollte es nicht möglich sein, die Telemetriedaten die sowieso vom Ardupilot bereitgestellt werden, auszulesen, weiterzuverarbeiten und relevanten Daten dann auf den MSB Bus zu übertragen. Bisher habe ich die Telemetrie nur über 433Mhz + Handy als Ausgabegerät realisieren können. Schöner wäre es die wichtigesten Daten zum Antrieb und z.B. die Winkeldaten des Modells direkt an der Fernsteuerung ablesen zu können. Zusätzlich wäre ein mitschreiben (loggen) aller Daten genial, denn auch hier ist der Ardupilot leider nicht gut bestückt, so dass die internen Telemetriedaten des letzten Fluges meisten schon wieder überschrieben sind bevor ich gelandet bin.

Leider bieten die kleinen Arduino Boards keine SD-Karten-Slots. Muss es dann zwingend ein großes sein?

Gruß
Stefan
 
LogAnalyzer

LogAnalyzer

Hallo Thomas,
hätte ich nicht gedacht. Es ist ja immer noch so viel Reserve da. Da hohle ich morgen mal den Log Analyser raus. Vielen Dank schon mal für den Hinweis.

Hallo Stefan,
ich habe jetzt leider keinen Plan welcher Art die Telemetrie Daten sind. Wenn die irgendwie lesbar sind, denke ich schon das das geht. Leider ( und das finde ich schade ) sind die Ausgabe-Möglichkeiten am Display des Senders begrentzt und damit meine ich nicht den Platz, sondern die Werteklassen und die Auflösung. Hier z.B. beschrieben.
http://www.mikrocontroller.net/articles/Der_Multiplex_Sensor_Bus_%28MSB%29
Ich selber würde mir wünschen das ich einige Werte genauer darstellen kann. Z.b. die Zellspannung. Aber gut ist das man den Alarm unabhängig vom Wert asulösn kann und das mache ich mir jetzt zum nutzen. Ich kann die Zellspannungen des Akkus jetzt lesen leider nur mit 0.1 Volt Genauigkeit, aber der Alarm ist auf 0.01 Volt genau.
Der Arduino ist für mich nur der erste Schritt für das Entwickeln. Wenn alles klappt dann würde ich im zweiten oder drtten schritt würde ich dann eine Platine entwerfen die dann den µC mit drauf hat. Analog zu der Idee von


Meine erster Wurf mit Temp. Sensoren, 2-6 Zellen Messung,1 PWM Ein- und 3 PWM Ausgängen sieht schon mal so aus.
PWM war gedacht für Beleuchtung etc. die ich dann via PWM Eingang in div. Modis setzen könnte. Das kann ich mir aber wahrscheinlich schencken wenn das Timing jetzt schon nicht hin haut.
IMG_6815.JPG

Gruß Marco und viel Erfolg.
 
Hallo Marco,

wenn es nur um die Anzeige einer einzelnen Zellenspannung geht, könntest Du einfach den MSB Wert für die Spannungsklasse als mV definieren.
Der auf dem Bus darstellbare Werteberech wäre dafür groß genug, bei der Anzeige über Sender oder Telemetriedisplay stimmt halt die Einheit nicht (V).

Oder Du mißbrauchts eine der anderen Werteklassen (Flüssigkeit z.B., statt mV steht dann halt mL im Display).

Die in der MSB Spezifikation definierten Werteklassen repräsentieren ja nur, wie MPX Sensoren und Sender die Buswerte interpretieren.
Bei selbst gebauten Sensoren kann man das Bussystem natürlich so nutzten wie man möchte.
Bei Benutzung von MPX Anzeigegeräten (Sender, Telemetriedisplay) muss man halt mit den angezeigten Einheiten (und Dezimalpunkt) leben.

Nur mal so als Anregung.


Gruß
Reinhardt
 
Werte und Genauigkeit & Timing

Werte und Genauigkeit & Timing

Hallo Reinhardt,
danke für den Tip. Bei der GesamtAkku Ladung habe ich z.B. den Tank Wert genommen... für den eigenen Gebrauch auch völlig ok. Ich möchte das Bord dann natürlich jedem zugänglich machen und dann ist das nicht so schön bzw. etwas unsauber.

@ Thomas,
könnte man nicht z.B. auch den Arduino Hardware Serial für die MSB Kommunikation nehmen und den Software Serial zum PC für Debug und ggf. Konfig?

Gruß Marco
 
Ansicht hell / dunkel umschalten
Oben Unten