Hallo,

da ich seit vielen Jahren Multiplex-Komponenten verwende und die Unterstützung für dieses System hier bislang nicht so toll war, habe ich selber angefangen etwas zu bauen. Die Anbindung der M-Link EMpfänger per digitalem Servo-Signal existiert schon seit ein paar Wochen: http://forum.mikrokopter.de/topic-28019.html

Jetzt habe ich auch die Anbindung an den Multiplex Sensor Bus MSB und damit die Telemetriedaten zurück im Sender. Da ich den einzigen freien USART in der FC schon für den Anschluß des Empfängers verwendet habe, ging es nicht ohne zusätzliche Hardware. Ich verwende ein kleines AVR-Board, das am Debug-Port hängt. Das hat allerdings auch zwei positive Seiteneffekte: Ich musste nicht in die FC oder NC-Software eingreifen und man kann die Funktionalität auch ohne das digitale Servosignal nutzen z.B. mit einem Summensignal-Konverter.

Das ist der Prototyp auf Basis eines Arduino Mini Pro



Wer Interesse hat, kann die Software gerne bekommen.

Stephan

Hoi Stefan!

Ich hab ebenfalls M-Bus Support gebaut, fuer ACT Empfaenger und das UAVP-NG.

Funktioniert praechtig, solange ich nen Multiplex Sensor zwischen UART und Empfaenger habe. Leider hab ich noch Probleme wenn ich den Sensor zwischen UART und Empfaenger weglasse. Dann werden die virtuellen Sensoren zwar weiter kontinuierlich abgefragt (scheint also, dass der M-Bus am Empfaenger gluecklich ist), aber unten am Sender kriege ich nur noch Teile der Daten.

Hast du eventuell auch festgestellt, dass unterschiedliche M-Bus Devices sich unterschiedlich verhalten koennen?
Ich vermute ein Timing-Problem, hab's aber bis jetzt noch nicht finden koennen.

Gruss!
- Amir

Hallo Amir,

das Problem kenne ich nicht. Bislang war das Timing auf dem MSB bei mir relativ problemlos. Hab sogar mal in nem Forum gelesen, dass jemand die Daten auf den Bus schickt, ohne überhaupt auf die Anfrage vom Empfänger zu warten.

Ich habe mein MSB-Interface zum MK aber auch noch nicht in Kombination mit einem MPX-Sensor getestet. Alle Daten die spannend sind, krieg ich aus dem Debug-Port heraus ( Strom, Spannung, Höhe, Geschwindigkeit... )

Gruss

Stephan

Hoi Stefan,

Hast du auf deinem Arduino den M-Bus an ne UART rangemacht, oder machst du dort Bit-Banging mit nem GPIO?
Falls du das auch per UART machst, waer ich interessiert daran mal unseren Code zu vergleichen, wenn dir das recht waere.

Wartest du die im M-Bus Protokoll (Idle Line Multiprocessor Protocol) vorgesehene Wartepause ab, bevor du Antworten auf ne Anfrage rausschreibst?

Liebe Gruesse!
- Amir

ich hab den MSB nicht am USART sondern an PIN 2 und 3 über die NewSoftSerial Bibliothek. Eine Wartepause habe ich nicht eingebaut:

im Prinzip ist das der Code:

// data on MSB ?
if (mySerial.available() > 0) {
 inByte = mySerial.read();
 if ( inByte == 2 )
 {
 mySerial.print( ( 2 << 4 ) + 2 , BYTE );
 mySerial.print( NaviData.Current << 1, BYTE );
 mySerial.print( NaviData.Current >> 7, BYTE );
 }
}

Ich hab auch noch Code für nen UART ohne die Arduino Libs. Der ist aber nicht von mir sondern von ingo_s.

War gerade mal auf Deiner NG-UAVP Seite. Willst Du dort den MSB integrieren ? In die FC oder das Sensor Board ?

Grüsse


Stephan

Hoi Stefan,

Zitat

War gerade mal auf Deiner NG-UAVP Seite. Willst Du dort den MSB integrieren ? In die FC oder das Sensor Board ?

Ich hab's im NGOS eingebaut das auf dem LPC2148 auf der FC laeuft. Ist auch schon funktionsfaehig.

Das sieht bei mir aehnlich wie bei dir aus:

 // check if it's one of our sensor addresses
 if ((b > (global.hw_mlink_sensor_offset - 1)) && (b < (MAX_MLINK_SENSOR_CHANNELS + global.hw_mlink_sensor_offset)))
 {
 packet_byte1 = mlink_sensor_table[b - global.hw_mlink_sensor_offset].mlink_value_class | (b << 4);
 packet_byte23 = (int)channel_value * 2;
 packet_byte2 = (int8_t) packet_byte23;
 packet_byte3 = (int8_t) (packet_byte23 >> 8);

 switch (monitor)
 {
 case MONITOR_UART0:
 uart0_putch((int)packet_byte1);
 uart0_putch((int)packet_byte2);
 uart0_putch((int)packet_byte3);
 break;

 case MONITOR_UART1:
 uart1_putch((int)packet_byte1);
 uart1_putch((int)packet_byte2);
 uart1_putch((int)packet_byte3);
 break;
 }
 }

Ich glaube wir machen da ziemlich das selbe. Es scheint so, dass mein ACT Empfaenger (ohne Multiplex M-Bus Sensor zwischen Empfaenger und UART) das nicht ganz so cool findet. Lustigerweise hat er, wenn der Multiplex Sensor dazwischen ist, keinerlei Probleme das ganze zu verstehen. Scheint mir fast so, als wenn der Multiplex-Sensor das Signal verbessert...

Ich werd wohl nicht drum rum kommen, das mal mit nem Oszi oder LA genauer unter die Lupe zu nehmen. Irgendwas ist anders. Und das sollte eigentlich dann sichtbar werden...

Danke trotzdem fuer dein Beispiel!

Liebe Gruesse!
- Amir

Hallo,

was für einen MPX-Sensor hast Du denn dazwischen ? Ich hab hier nen Stromsensor von MPX liegen, da ist der MSB einfach nur durchgeschleift. Der kann so nichts "verbessern".

Allerdings nutze ich auch den Multiplex Empfänger, evtl. ist der etwas toleranter als Dein ACT.

Gruss

Stephan

Hoi Stefan,

Ist ein Spannungs-Sensor von Multiplex. Ich hatte ja auch gedacht, dass man sowas durchschleift, aber ich kanns reproduzieren: Ohne Sensor gehts nicht, mit Sensor im Bus gehts. Irgendwas MUSS anders sein, sonst versteh ich die Welt nicht mehr... Die Kabellaenge ist natuerlich anders, aber obs das ist wage ich zu bezweifeln. Der ACT Empfaenger ist intern fast sicher anders aufgebaut als der Multiplex Empfaenger, von daher sind Unterschiede zwischen ACT und Multiplex Empfaengern zu erwarten.

Gruss!
- Amir

Hallo,
leider bin ich technisch nicht auf eurem Niveau.
Ich fliege MK mit ACT S3D ohne telemetrie.
Für den ACT Empfänger gibt es Ja eine spezielle MK Firmware, So das die MK das spezielle Summensignal des ACT´s versteht.
Nun möchte ich gerne auf einen ACT S3D Telemetrie Empfänger umrüsten.
Dazu bräuchte ich für den Rückkanal die Anbindung an den Multiplex Sensorbus des ACT´s

Da mir die Zeit und auch etwas KnoHow fehlt würde ich gerne einen fertiges Mudul für die Debug Schnittstelle kaufen. Ob dies dann mit meiner Konfiguration und mit oder ohne zusätzlichen Sensor funktioniert, würde ich dann gerne austesten.

Gruss

Uli

Hi,

wenn es ohne MPX Sensor nicht geht, versucht mal einen 10k - 22k PullUp Widerstand.

Der MSB hat keinen PullUp bzw. die MPX Sensoren verhalten sich wie ein sehr hochohmiger PullUp und ist auf die aktive High-Flanke des Sensor TX angewiesen ohne PullUp.

Mit einer Diode am TX Ausgang hat man es zwar einfach, das man den TX nicht deaktiveren muss, wenn das Stopbit raus ist, aber die High-Flanken sehen meistens nicht gut aus.

Zusätzlich sollte jeder Sensor auch die idle line timeout einhalten, je nach RX Software und anderen Sensoren oder z.B. Loggern kann sonst die 4 Byte Reihenfolge falsch interpretiert werden.

Gruß Ingo

Hallo Ingo!

Danke fuer den Tip! Ich werde da genauer reinschauen... Macht Sinn, was du oben schreibst!

Gruss!
- Amir

Re Ingo,

Mit nem 10kOhm gegen 5V laeuft das ganze perfekt. Keinerlei Probleme mehr. Danke fuer den Hint!

Hier sieht man den Code am Laufen:

# ps

 PID TTY STATE DESC
 0 /dev/usb ready Terminal Task
 1 /dev/uart0 running Terminal Task
 2 /dev/uart1 waiting Terminal Task
 3 /dev/uart1 ready M-Link/MSB/M-Bus Parser

# show devices

Detected devices: 

 Addr Bus Description

 0x16 I2C0 Atmel 644P RC/Comm Controller
 0x18 I2C0 Atmel 328P SB Controller
 0x02 ADC12 ADXR/MLX MEMS Gyroscope 12bit (nick)
 0x01 ADC12 ADXR/MLX MEMS Gyroscope 12bit (roll)
 0x00 ADC12 ADXR/MLX MEMS Gyroscope 12bit (yaw)
 0x00 SPI0 LIS3LV02DQ 3-Axis Accelerometer
 0x03 SPI0 AD7924 12bit Analog Digital Converter
 0x02 UART1 M-Link/MSB/M-Bus Telemetry
 0x00 SBCTRL MicroMag 3 Magnetic Compass (calibrated)

Gruss!
- Amir