search

christianrauch / msp

Implementation of the MultiWii Serial Protocol (MSP) for MultiWii and Cleanflight flight controller
http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol
GNU Lesser General Public License v3.0
73 stars 26 forks source link

running example programs against INAV 2.0.1 firmware on Revo #26

Closed humanoid2050 closed 5 years ago

humanoid2050 commented 5 years ago

All tests run in Linux environment using the /dev/ttyACM0 device (direct USB connection to FC board)

./msp_connection_test /dev/ttyACM0

Connected to: /dev/ttyACM0
Waiting for flight controller to become ready...
MSP version 231 ready after: 20 ms
<hangs after this, FC LEDs stop flashing>

Unknown reason for failure.

=========================================================

./msp_read_test /dev/ttyACM0

Connected to: /dev/ttyACM0
Connecting FCU...
MSP version 231 ready
ready
#Ident:
MultiWii Version: 231
MSP Version: 0
Type: Quadrocopter X
Capabilities:
    Bind:   OFF
    DynBal: ON
    Flap:   ON
#Status:
Cycle time: 1003 us
I2C errors: 0
Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: ON
    GPS: OFF
    Sonar: OFF
Active Boxes (by ID): 20
#Imu:
Linear acceleration: -0.0383072, 0.0957681, 9.61511 m/s²
Angular velocity: 0, 0, -0.244141 deg/s
Magnetometer: -10.58, -54.74, -21.804 uT
#Servo:
1500 1500 1500 1500
1500 1500 1500 1500
#Motor:
1000 1000 1000 1000
0 0 0 0
#Rc channels (18) :
1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 
<hangs after this, FC LEDs stop flashing>

This fails on the msp::msg::Attitude, which has had a change to the data structure.

=========================================================

./cleanflight_read_test /dev/ttyACM0

Connected to: /dev/ttyACM0
MSP ready...
#Api Version:
API: 2.2
Protocol: 0

#FC variant:
Identifier: INAV

#FC version:
Version: 2.0.1

#Board Info:
Identifier: REVO
Version: 0
Type: 0

#Build Info:
Date: Oct 31 2018
Time: 18:34:53
Git revision: a04e68a
<hangs after this, FC LEDs stop flashing>

Crashes on msp::msg::RxConfig message, which has more data in INAV.

=========================================================

./client_read_test /dev/ttyACM0

#Ident:
MultiWii Version: 231
MSP Version: 0
Type: Quadrocopter X
Capabilities:
    Bind:   OFF
    DynBal: ON
    Flap:   ON
#Status:
Cycle time: 1002 us
I2C errors: 0
Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: ON
    GPS: OFF
    Sonar: OFF
Active Boxes (by ID): 20
#Imu:
Linear acceleration: 0, 0.0957681, 9.71088 m/s²
Angular velocity: 0.244141, 0, -0.244141 deg/s
Magnetometer: -10.672, -54.74, -21.804 uT
#Servo:
1500 1500 1500 1500
1500 1500 1500 1500
#Motor:
1000 1000 1000 1000
0 0 0 0
#Rc channels (18) :
1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 
#Attitude:
Ang : 0.5, 0.1 deg
Heading: 259 deg
#Altitude:
Altitude: -0.11 m, var: -0.03 m/s
#Analog:
Battery Voltage: 0 V
Current: 0 A
Power consumption: 0 Ah
RSSI: 0
#Rc Tuning:
Rc Rate: 1
Rc Expo: 0.7
Roll/Pitch Rate: 0.5
Yaw Rate: 0.5
Dynamic Throttle PID: 0.45
Throttle MID: 0
Throttle Expo: 0.5
#PID:
Name      P     | I     | D     |
----------------|-------|-------|
Roll:      4.3  | 4 | 2
Pitch:     5.8  | 5 | 2.2
Yaw:       7    | 4.5   | 0
Altitude:  5    | 0 | 0
Position:  6.5  | 12    | 1
PositionR: 4    | 1.5   | 10
NavR:      0    | 0 | 0
Level:     2    | 1.5   | 7.5
Magn:      6    | 0 | 0
Vel:       10   | 5 | 1
#Box:
0 aux1: ___, aux2: ___, aux3: ___, aux4: ___, 
1 aux1: ___, aux2: _M_, aux3: ___, aux4: ___, 
2 aux1: ___, aux2: ___, aux3: ___, aux4: ___, 
3 aux1: ___, aux2: ___, aux3: ___, aux4: ___, 
#Miscellaneous:
Power Trigger: 1500
Min Throttle: 1150
Max Throttle: 1850
Failsafe Throttle: 1000
Arm Counter: 0
Lifetime: 5
Magnetic Declination: 0 deg
Battery Voltage Scale: 11 V
Battery Warning Level 1: 3.3 V
Battery Warning Level 2: 4.2 V
Battery Critical Level: 3.5 V
#Motor pins:
Motor 0: pin 1
Motor 1: pin 2
Motor 2: pin 3
Motor 3: pin 4
Motor 4: pin 5
Motor 5: pin 6
Motor 6: pin 7
Motor 7: pin 8
#Box names:
0: ARM
1: ANGLE
2: HORIZON
3: TURN ASSIST
4: AIR MODE
5: HEADING HOLD
6: HEADFREE
7: HEADADJ
8: CAMSTAB
9: NAV ALTHOLD
10: SURFACE
11: NAV POSHOLD
12: NAV RTH
13: NAV WP
14: HOME RESET
15: GCS NAV
16: BEEPER
17: OSD SW
18: BLACKBOX
19: KILLSWITCH
20: FAILSAFE
21: CAMERA CONTROL 1
22: CAMERA CONTROL 2
23: CAMERA CONTROL 3
#PID names:
0: ROLL
1: PITCH
2: YAW
3: ALT
4: Pos
5: PosR
6: NavR
7: LEVEL
8: MAG
9: VEL
#Box IDs:
0: 0
1: 1
2: 2
3: 35
4: 29
5: 5
6: 6
7: 7
8: 8
9: 3
10: 33
11: 11
12: 10
13: 28
14: 30
15: 31
16: 13
17: 19
18: 26
19: 38
20: 27
21: 39
22: 40
23: 41
#Servo conf:
Nr. | [min | middle | max] (rate)
0:  | [1000 | 1500 | 2000] (100)
1:  | [0 | 0 | 255] (0)
2:  | [1000 | 1500 | 2000] (100)
3:  | [0 | 0 | 255] (0)
4:  | [1000 | 1500 | 2000] (100)
5:  | [0 | 0 | 255] (0)
6:  | [1000 | 1500 | 2000] (100)
7:  | [0 | 0 | 255] (0)
Message with ID 253 is not recognised!
unsupported: 253
#Debug:
debug1: 0
debug2: 0
debug3: 0
debug4: 0
<hangs after this, FC LEDs still flashing>

Unclear why Client::close() does not return. might be hanging because there is no data on the serial bus?

=========================================================

./client_async_test /dev/ttyACM0 <success>

=========================================================

./fcu_test /dev/ttyACM0 <success>

=========================================================

./fcu_arm /dev/ttyACM0

Cleanflight API 2.2.0 ready
ready after: 87 ms
RX_MSP enabled, restart
terminate called after throwing an instance of 'std::system_error'
  what():  read: Bad file descriptor
Aborted (core dumped)

This is a know issue due to the /dev/ttyACM0 device disappearing when the FC reboots itself. INAV doesn't treat MSP control as a feature, it's just another control source like SERIAL, PWM, or PPM.

=========================================================

./fcu_custom_type /dev/ttyACM0 <success>

=========================================================

./fcu_motors /dev/ttyACM0 

Cleanflight API 2.2.0 ready
terminate called after throwing an instance of 'std::system_error'
  what():  read: Bad file descriptor
Aborted (core dumped)

No idea whats going on here.

christianrauch commented 5 years ago

I tested with the latest betaflight:

$ ./msp_connection_test /dev/ttyUSB0 
Connected to: /dev/ttyUSB0
Waiting for flight controller to become ready...
Unknown MSP id! FC refused to process message with id: 100
error getting MSP version
$ ./msp_read_test /dev/ttyUSB0 
Connected to: /dev/ttyUSB0
Connecting FCU...
Unknown MSP id! FC refused to process message with id: 100
ready
Unknown MSP id! FC refused to process message with id: 100
unsupported: 100
#Status:
Cycle time: 1036 us
I2C errors: 0
Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: ON
    GPS: OFF
    Sonar: OFF
Active Boxes (by ID):
#Imu:
Linear acceleration: 9.38527, -0.0574608, 2.87304 m/s²
Angular velocity: -0.244141, -0.732422, -0.244141 deg/s
Magnetometer: -52.348, -3.496, 3.404 uT
#Servo:
1500 1500 1500 1500
1500 1500 1500 1500
#Motor:
1000 1000 1000 1000
0 0 0 0
#Rc channels (12) :
1500 1500 1500 885 747 747 747 747 747 747 1500 1500 
#Attitude:
Ang : -1.1, -73 deg
Heading: 250 deg
#Altitude:
Altitude: 0.01 m, var: 0 m/s
#Analog:
Battery Voltage: 4.2 V
Current: 0 A
Power consumption: 0 Ah
RSSI: 0
#Rc Tuning:
Rc Rate: 1
Rc Expo: 0
Roll/Pitch Rate: 0.7
Yaw Rate: 0.7
Dynamic Throttle PID: 0.7
Throttle MID: 0.1
Throttle Expo: 0.5
#PID:
Name      P     | I     | D     |
----------------|-------|-------|
Roll:      4.6  | 4.5   | 2.5
Pitch:     5    | 5 | 2.7
Yaw:       6.5  | 4.5   | 0
Altitude:  5    | 5 | 7.5
Position:  4    | 0 | 0
PositionR: 0.2  | 23.5  | 0.2
NavR:      23.5 | 0.2   | 22
Level:     0.5  | 22    | 0.5
Magn:      3.3  | 0 | 0
Vel:       0    | 0 | 0
Unknown MSP id! FC refused to process message with id: 113
unsupported: 113
Unknown MSP id! FC refused to process message with id: 114
unsupported: 114
Unknown MSP id! FC refused to process message with id: 115
unsupported: 115
#Box names:
0: ARM
1: ANGLE
2: HORIZON
3: MAG
4: HEADFREE
5: FAILSAFE
6: HEADADJ
7: BEEPER
8: OSD DISABLE SW
9: BLACKBOX
10: AIR MODE
11: FPV ANGLE MIX
12: BLACKBOX ERASE (>30s)
13: PREARM
14: PARALYZE
15: ACRO TRAINER
#PID names:
0: ROLL
1: PITCH
2: YAW
3: LEVEL
4: MAG
#Box IDs:
0: 0
1: 1
2: 2
3: 5
4: 6
5: 27
6: 7
7: 13
8: 19
9: 26
10: 28
11: 30
12: 31
13: 36
14: 45
15: 47
#Servo conf:
Nr. | [min | middle | max] (rate)
0:  | [1000 | 1500 | 2000] (100)
1:  | [255 | 59392 | 0] (3)
2:  | [2000 | 65380 | 1500] (0)
3:  | [0 | 53251 | 59392] (7)
4:  | [1500 | 0 | 65380] (0)
5:  | [59392 | 56327 | 53251] (5)
6:  | [65380 | 0 | 0] (232)
7:  | [53251 | 25605 | 56327] (255)
Unknown MSP id! FC refused to process message with id: 253
unsupported: 253
#Debug:
debug1: 0
debug2: 0
debug3: 0
debug4: 0
$ ./cleanflight_read_test /dev/ttyUSB0 Connected to: /dev/ttyUSB0
Unknown MSP id! FC refused to process message with id: 100
MSP ready...
#Api Version:
API: 1.40
Protocol: 0

#FC variant:
Identifier: BTFL

#FC version:
Version: 3.5.4

#Board Info:
Identifier: AFNA
Version: 2
Type: 0

#Build Info:
Date: Dec 19 2018
Time: 00:17:12
Git revision: 2eb09fe

#Features:
RX_PPM

#Channel mapping:
0: 0
1: 1
2: 3
3: 2
4: 4
5: 5
6: 6
7: 7
$ ./client_read_test /dev/ttyUSB0 
Message with ID 100 is not recognised!
unsupported: 100
#Status:
Cycle time: 1209 us
I2C errors: 0
Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: ON
    GPS: OFF
    Sonar: OFF
Active Boxes (by ID):
#Imu:
Linear acceleration: 9.40442, -0.0574608, 2.87304 m/s²
Angular velocity: 0.244141, 0.244141, -0.244141 deg/s
Magnetometer: -52.072, -3.496, 3.036 uT
#Servo:
1500 1500 1500 1500
1500 1500 1500 1500
#Motor:
1000 1000 1000 1000
0 0 0 0
#Rc channels (12) :
1500 1500 1500 885 747 747 747 747 747 747 1500 1500 
#Attitude:
Ang : -1.1, -73 deg
Heading: 190 deg
#Altitude:
Altitude: 1.53 m, var: 0 m/s
#Analog:
Battery Voltage: 4.1 V
Current: 0 A
Power consumption: 0 Ah
RSSI: 0
#Rc Tuning:
Rc Rate: 1
Rc Expo: 0
Roll/Pitch Rate: 0.7
Yaw Rate: 0.7
Dynamic Throttle PID: 0.7
Throttle MID: 0.1
Throttle Expo: 0.5
#PID:
Name      P     | I     | D     |
----------------|-------|-------|
Roll:      4.6  | 4.5   | 2.5
Pitch:     5    | 5 | 2.7
Yaw:       6.5  | 4.5   | 0
Altitude:  5    | 5 | 7.5
Position:  4    | 0 | 0
PositionR: 0.2  | 23.5  | 0.2
NavR:      23.5 | 0.2   | 22
Level:     0.5  | 22    | 0.5
Magn:      24.1 | 0.2   | 0
Vel:       0    | 0 | 0
Message with ID 113 is not recognised!
unsupported: 113
Message with ID 114 is not recognised!
unsupported: 114
Message with ID 115 is not recognised!
unsupported: 115
#Box names:
0: ARM
1: ANGLE
2: HORIZON
3: MAG
4: HEADFREE
5: FAILSAFE
6: HEADADJ
7: BEEPER
8: OSD DISABLE SW
9: BLACKBOX
10: AIR MODE
11: FPV ANGLE MIX
12: BLACKBOX ERASE (>30s)
13: PREARM
14: PARALYZE
15: ACRO TRAINER
#PID names:
0: ROLL
1: PITCH
2: YAW
3: LEVEL
4: MAG
#Box IDs:
0: 0
1: 1
2: 2
3: 5
4: 6
5: 27
6: 7
7: 13
8: 19
9: 26
10: 28
11: 30
12: 31
13: 36
14: 45
15: 47
#Servo conf:
Nr. | [min | middle | max] (rate)
0:  | [1000 | 1500 | 2000] (100)
1:  | [255 | 59392 | 0] (3)
2:  | [2000 | 65380 | 1500] (0)
3:  | [0 | 53251 | 59392] (7)
4:  | [1500 | 0 | 65380] (0)
5:  | [59392 | 56327 | 53251] (5)
6:  | [65380 | 0 | 0] (232)
7:  | [53251 | 25605 | 56327] (255)
Message with ID 253 is not recognised!
unsupported: 253
#Debug:
debug1: 0
debug2: 0
debug3: 0
debug4: 0

It "hangs" after client_read_test because the thread is still running but no new messages are requested. You can stop the process with Ctrl+C.

$ ./fcu_motors /dev/ttyUSB0 
Cleanflight API 1.40.0 ready
terminate called after throwing an instance of 'std::system_error'
  what():  read: Bad file descriptor
Abgebrochen (Speicherabzug geschrieben)

I will need to look into this one.

I will also need to check with iNav. From your initial thoughts, this might be related to different message data structures. There is no integrated way to detect mismatching messages since they do not have something like hash sums. The only workaround for this is to detect the firmware type after establishing the connection and using different message definitions for the same message ID. This is one of the downsides of MSP compared to e.g. MAVLink. It gives me headaches thinking about workarounds for this issue and I really do not want to get into this :-)

humanoid2050 commented 5 years ago

I think you hit the nail on the head. I solved the problem by making everything (MSP message, Client, and FlightController) all have an internal instance of an enum of the different firmware variants, and the messages encode/decode differently based on that flag at runtime. When FlightController initializes, it queries the FC for its self-reported firmware version (and MSP version) and sets the internal flag for that session. It works, but it represents a lot of work to maintain. The only other thing I can think of is to make individual MSP message libraries for each variant, and whoever cares about that variant keeps up with it. At the top of the include file, note the latest version of the firmware that it was tested with.

christianrauch commented 5 years ago

I imagine three options for this solution:

  1. Ask both projects to use different message IDs for different message definitions. This should now be feasible since MSP2 has a wider range of useable message IDs. (easiest for MSP client implementations)
  2. Maintain different sets of message definitions per firmware in the library and select at runtime which to use. This could also be done in different ways:
    1. Define messages with the superset of messages with the same ID in all firmwares and have multiple decode/encode functions that only deal with the appropriate parts of a message.
    2. Use different namespaces for all messages and switch at runtime as you described above. This will result in an ugly implementation that will be hard to maintain.
    3. Use a plugin system and load the set of messages at runtime. E.g. Compile betaflight messages into lib_msg_btfl.so and iNav messages into lib_msg_inav.so and dlopen one of them after the firmware has been determined using core messages. This seams to be the cleanest way of implementing this but it makes the library quite complex, given that the protocol is actually very simple.
  3. Enable the MAVLink telemetry protocol in betaflight/iNav and use mavlink solely for communication with the FC :-)
humanoid2050 commented 5 years ago

Are we treating this issue as a firmware variation issue? or a running of example code issue? Just want to keep the discussions organized. I actually implemented what you mentioned as 2.i. There is one more approach: make the user select which msp library to use at compile time and compile against that. It doesn't have the polished automagic feel of some of the other solutions, but it would work too. Regardless of compile time or run time selection, I do kind of think that having individual msp_msg_INAV.cpp and msp_msg_CLFL.cpp files might be the best solution, since a developer can focus on whatever version they are using, instead of having to look at all the code for all versions at once. I also made a factory class for message objects, but I haven't started using it yet. I'm not sure if that kind of design patter could be useful here.

christianrauch commented 5 years ago

It's a message definition issue. Different firmwares can still use the same message definition, e.g. cleanflight and betaflight share the same messages.

I definitely want that this works at runtime. E.g. by having messages in different namespaces (where multiple source files or message libraries make sense) or by having multiple decode/encode functions in the same message.

humanoid2050 commented 5 years ago

Ok. One more opinion oriented question. There are messages with the same ID that have different fields depending on which firmware packed it. I made fields in my version a special class that can be queried to see if a real value has been packed into it. If a firmware doesn't provide a value, the field is left in an unset state. The side effect is that the fields associated with the message are the superset of all possible fields from all firmware variants. Is that approach reasonable to you? Or do lean toward making message definitions unique to the specific firmware?

christianrauch commented 5 years ago

I cannot imagine how these special field classes look like. But in general, I think that once a message definition changes (either because of diverging firmware types or because they are just updated), a new message definition should be created. I usually just support the most recent version of betaflight, to keep this maintaining work as low as possible. I.e. I do not want to deal with different APIs and message definition because it would increase the complexity of the library.

christianrauch commented 5 years ago

Is this still an issue with the newest release that allows to encode/decode messages based on the firmware type?

wx4cb commented 5 years ago

here's what i'm getting on mine... inav 2.1.0 latest release, F722 Wing with fresh current github version.

difference is i get unrecognised markers here is i'm using a crossfire bluetooth connection which is weird, i'm using a slower baud rate. my next comment will be what I get with it directly connected to the FC

charlesb@GroundStation:~/src/msp/msp/build$ ./client_async_test /dev/rfcomm0 2>&1 |tee tmp.log
Message marker þ is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker + is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker K is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker & is not recognised!
Message marker  is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker $ is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker Š is not recognised!
Version marker þ is not recognised!
Message marker  is not recognised!
Version marker   is not recognised!
Message marker  is not recognised!
Version marker f is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
Message marker h is not recognised!
Version marker   is not recognised!
Message marker  is not recognised!
Version marker  is not recognised!
#Servo:
 1500 1500 1500 1580
 1431 1500 1500 1500
#Rc channels (17) :
1500 1484 1497 988 988 988 988 988 988 988 1500 2000 1500 1500 1500 1500 1999
#Attitude:
 Roll : -20 deg
 Pitch : -57 deg
 Heading: 48 deg
#Altitude:
 Altitude: 0.06 m, var: 0.03 m/s
 Barometer: -1.13
Print method for message ID 114 is not implemented
#Box:
0 aux1: ___, aux2: ___, aux3: ___, aux4: ___,
1 aux1: __H, aux2: ___, aux3: ___, aux4: ___,
2 aux1: ___, aux2: ___, aux3: ___, aux4: ___,
3 aux1: ___, aux2: ___, aux3: ___, aux4: ___,
Print method for message ID 254 is not implemented
#Imu:
 Linear acceleration: 99, 36, 459
 Angular velocity: -81, -68, -1
 Magnetometer: 0, 0, 0
#Imu:
 Linear acceleration: 1.89621, 0.68953, 8.79151 m/s²
 Angular velocity: -19.7754, -16.6016, -0.244141 deg/s
 Magnetometer: 0, 0, 0 uT
#Motor:
 1000 1000 0 0
 0 0 0 0
#Servo:
 1500 1500 1500 1580
 1431 1500 1500 1500

Ad nauseum with bad message markers mixed in

wx4cb commented 5 years ago 
charlesb@GroundStation:~/src/msp/msp/build$ ./fcu_test /dev/ttyACM0 115200 2>&0  |tee tmp.log
#FC variant:
 Identifier: INAV
#Api Version:
 API: 2.3
 Protocol: 0
#FC version:
 Version: 2.1.0
#Board Info:
 Identifier: MF7S
 Version: 0
 OSD support: 2
 Comms bitmask: 3
 Board Name: MATEKF722SE
#Build Info:
 Date: Feb 25 2019
 Time: 17:01:07
 Git revision: 65b0ec1
#Status:
 Cycle time: 260 us
 I2C errors: 45
 Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: OFF
    GPS: ON
    Sonar: OFF
 Active Boxes (by ID): 18
#Ident:
 MultiWii Version: 231
 MSP Version: 0
 Type: Quadrocopter X
 Capabilities:
    Bind:   OFF
    DynBal: ON
    Flap:   ON
# Box names:
 0: ARM
 1: ANGLE
 2: HORIZON
 3: TURN ASSIST
 4: HEADING HOLD
 5: HEADFREE
 6: HEADADJ
 7: FPV ANGLE MIX
 8: CAMSTAB
 9: NAV ALTHOLD
 10: SURFACE
 11: NAV POSHOLD
 12: LOITER CHANGE
 13: NAV RTH
 14: NAV WP
 15: HOME RESET
 16: GCS NAV
 17: NAV CRUISE
 18: MANUAL
 19: NAV LAUNCH
 20: SERVO AUTOTRIM
 21: AUTO TUNE
 22: BEEPER
 23: LEDLOW
 24: OSD SW
 25: BLACKBOX
 26: KILLSWITCH
 27: FAILSAFE
 28: CAMERA CONTROL 1
 29: CAMERA CONTROL 2
 30: CAMERA CONTROL 3
 31: USER1
 32: USER2
 33: OSD ALT 1
 34: OSD ALT 2
 35: OSD ALT 3

#Box IDs:
 0: 0
 1: 1
 2: 2
 3: 35
 4: 5
 5: 6
 6: 7
 7: 32
 8: 8
 9: 3
 10: 33
 11: 11
 12: 49
 13: 10
 14: 28
 15: 30
 16: 31
 17: 45
 18: 12
 19: 36
 20: 37
 21: 21
 22: 13
 23: 15
 24: 19
 25: 26
 26: 38
 27: 27
 28: 39
 29: 40
 30: 41
 31: 47
 32: 48
 33: 42
 34: 43
 35: 44

#Channel mapping:
 0: 1
 1: 2
 2: 3
 3: 0
SUBSCRIBING TO 102
SUBSCRIBING TO 100
SUBSCRIBING TO 101
SUBSCRIBING TO 103
SUBSCRIBING TO 104
SUBSCRIBING TO 105
SUBSCRIBING TO 108
SUBSCRIBING TO 109
SUBSCRIBING TO 110
SUBSCRIBING TO 111
SUBSCRIBING TO 112
SUBSCRIBING TO 113
SUBSCRIBING TO 114
SUBSCRIBING TO 115
SUBSCRIBING TO 116
SUBSCRIBING TO 117
SUBSCRIBING TO 119
SUBSCRIBING TO 120
SUBSCRIBING TO 253
SUBSCRIBING TO 254
#Imu:
 Linear acceleration: 0.881066, -1.37906, 8.96389 m/s²
 Angular velocity: -1.2207, 0.976562, -0.244141 deg/s
 Magnetometer: 0, 0, 0 uT
#Ident:
 MultiWii Version: 231
 MSP Version: 0
 Type: Quadrocopter X
 Capabilities:
    Bind:   OFF
    DynBal: ON
    Flap:   ON
#Status:
 Cycle time: 258 us
 I2C errors: 45
 Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: OFF
    GPS: ON
    Sonar: OFF
 Active Boxes (by ID): 18
Print method for message ID 114 is not implemented
Message v2 with ID 253 is not recognised!
Print method for message ID 254 is not implemented

Plus a whole bunch of other params as well

christianrauch commented 5 years ago

@wx4cb So in summary, you are saying that it works correctly when using the wired serial connection but it does not work entirely over bluetooth? For your bluetooth connection, it appears as if the connection is out of sync and it is searching for the message header. But it's not clear to me if this is because it is out of sync or because the bluetooth connection sends other bytes that are unrelated to the MSP protocol.

wx4cb commented 5 years ago

@christianrauch that what it appears to me. a direct serial connect seems fine.

the crossfire bluetooth is a weird one as i've never got it to work correctly, even with mavlink - although it appears to be better behaved with that. I beleive this is a crossfire issue - what, I don't know

christianrauch commented 5 years ago

I pushed a fix to the master branch to print the byte values instead of their (possible white space) character to the terminal output. You can have a look if the values are familiar to you. You can also try to create a raw dump of the serial communication and see if there are multiple streams interleaved, i.e. if all the data comes from MSP communication or if there is a second stream of non-MSP data.

christianrauch commented 5 years ago

I am closing this as this seems to be an issue with the low-level hardware communication and not the library. Just reopen this, if the library fails to encode/decode valid MSP messages.