New Multiwii Serial Protocol

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

Hello Admins,

I would like to see this additional MSP codes:

Code: Select all

#define MSP_TEMPERATURE          119    //out message         Temperature

In mpu6050 you can get this value

Code: Select all

#define MSP_SONAR                120    //out message         Altitude Sonar

If you are using SONAR it would be nice to transmit this value to GUI

Regards
Carsten

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: New Multiwii Serial Protocol

Post by dramida »

I also want the RSSI to be used in rushduino /minim OSD :

Code: Select all

#define MSP_RSSI 121          //out message 1 byte RSSI in percent value


Here is a sample video of this OSD capabilities http://www.youtube.com/watch?v=lkAXFUaCtMc (i changed the video to a better example as some members suggested)

Thank You
Last edited by dramida on Mon Jan 28, 2013 11:50 pm, edited 1 time in total.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: New Multiwii Serial Protocol

Post by shikra »

+1 to the last requests.

Dramida - Might be better to have raw reading on the RSSI. Can then tweak ranges on OSD gui easily.

Maybe even MSP_ANAL (LOL!) to cover a few free pins for other uses.

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: New Multiwii Serial Protocol

Post by kataventos »

dramida wrote:I also want the RSSI to be used in rushduino /minim OSD :

Code: Select all

#define MSP_RSSI 121          //out message 1 byte RSSI in percent value


Here is a sample video of this OSD capabilities http://vimeo.com/52278772

Thank You


I´m trying to get it working on MWc testing with A5.
I sure use some help from a MW coder, I can take care of the remaining part on the OSD!

BTW, that video does not show this OSD capabilities at all!

Cheers,
KV

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

A5 is SCL part of the I2C bus.

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: New Multiwii Serial Protocol

Post by kataventos »

copterrichie wrote:A5 is SCL part of the I2C bus.


Wrong key on last post... I moved the vbat to A0 and using A3.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Or A6 and A7 on a Nano or one of the new ProMinis. :)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

cGiesen wrote:Hello Admins,

I would like to see this additional MSP codes:

Code: Select all

#define MSP_TEMPERATURE          119    //out message         Temperature

In mpu6050 you can get this value

Code: Select all

#define MSP_SONAR                120    //out message         Altitude Sonar

If you are using SONAR it would be nice to transmit this value to GUI

Regards
Carsten


For which purpose ?
The relevant altitude should be a mix between baro&sonar, or baro alone, or sonar alone. All computed inside the FC.
When could it be useful to transmit both sonar + baro alt ?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

dramida wrote:I also want the RSSI to be used in rushduino /minim OSD :

Code: Select all

#define MSP_RSSI 121          //out message 1 byte RSSI in percent value


Here is a sample video of this OSD capabilities http://www.youtube.com/watch?v=lkAXFUaCtMc (i changed the video to a better example as some members suggested)

Thank You


ok, I understand it's a need for OSD and it's one of the variable still not covered by other sensors we usually find in OSD

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

Alexinparis wrote:
cGiesen wrote:Hello Admins,

I would like to see this additional MSP codes:

Code: Select all

#define MSP_TEMPERATURE          119    //out message         Temperature

In mpu6050 you can get this value

Code: Select all

#define MSP_SONAR                120    //out message         Altitude Sonar

If you are using SONAR it would be nice to transmit this value to GUI

Regards
Carsten


For which purpose ?
The relevant altitude should be a mix between baro&sonar, or baro alone, or sonar alone. All computed inside the FC.
When could it be useful to transmit both sonar + baro alt ?


Why? Because you didn't see, if the result is coming from Baro or from Sonar!
And when you read here in the forum, a lot of people are testing with sonar, and I think it's help full to see the isolated result from sonar.
Temperature is a nice to have, I play with this. But I do not code any think when I not see, it's not for trashcan.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

if it is for testing purposes, then why not use any of the debug[] values?

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

Hamburger,

there are a lot of user, they only can change the config.h!
A little bit Usability could not by wrong....

Carsten

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

And by the way...
There is a different between calculated and original sensor values!
Normalay we should transmit both!

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

there are a lot of user, they only can change the config.h!
A little bit Usability could not by wrong....

There is a different between calculated and original sensor values!
Normalay we should transmit both!

not my beef but I think once the implementation works ok, then no regular user should worry about which sensor provides what raw value. All that matters to them is some (not all) data that correlates with the real world.

Now for developers I understand those have different needs. But they will know how to use debug[]. Maybe it is different with sonar, then I fail to understand how.

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

Please tell me, how the enduser can see, if the altitude is comming from baro or from sonar?
How can he see, that sonar is working? Perhaps he make an error in wirering

I only ask for two stupid numbers....

there are 60 left.....

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: New Multiwii Serial Protocol

Post by shikra »

No one else interested in MSP_ANAL ?

:)

crashlander
Posts: 506
Joined: Thu May 05, 2011 8:13 am
Location: Slovenia

Re: New Multiwii Serial Protocol

Post by crashlander »

cGiesen wrote:there are a lot of user, they only can change the config.h!
Carsten


I believe that not exposing too-much data in GUI is a good practice. There is also no special reason to invent too-many MSP commands just to read some rarely used data.
But maybe it makes sense to move some/all of debug values into config.h and to define some special debug define eg. #define DEBUG_WILL_NOT_FLY (presuming some readouts are too complex/slow/or we need precision of single measurement /... to use in real time) and under that put defines to uncomment readings from individual sensors and print them inside DEBUG1,2,3. That way user could uncomment sensor values he/she is interested in without searching all the code.

Best Regards
Andrej

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: New Multiwii Serial Protocol

Post by mbrak »

shikra wrote:No one else interested in MSP_ANAL ?

:)



STOP !!! :) bad pictures are growing in my mind :)

tamts
Posts: 2
Joined: Wed Jan 30, 2013 8:07 pm

Re: New Multiwii Serial Protocol

Post by tamts »

Hi,
I got a this Crius SE with 1.9 inside. and first thing i upgraded it to 2.1.
I built a program to work with the board by serial.
and it works but partially.
I send some commands like ACC. cal, Mag. Cal and it works fine.
also, i send some other commands like get battery status, and this is what is get:
0x24 0x4D 0x3E 0x03 0x6E 0x00 0x00 0x00 0x6D,
means, that the command was send successfully, and i got the answer:
the 3 zeros means 0 volt.
My system is:
Crius MWC 2.1, Hacker motor A1012S, ESC Flyfun-6A, bat: turnigy 0.95MAH 2S.

for now, i connected only one esc and motor.
also, my biggest problem, i cannot arm, or send any combination of RC chan (SET)
i get always the same 1000 (3E8) value to all channels.
Q:what i do wrong?
Q: when i send MSP_SET_RAW_RC do i need to receive back an answer? (now i do not get any)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

you have to define:
/******************* RC signal from the serial port via Multiwii Serial Protocol *********/
#define RCSERIAL

so that values are not overwritten with default routine.

itain
Posts: 75
Joined: Tue Aug 23, 2011 10:32 pm

Re: New Multiwii Serial Protocol

Post by itain »

Subject: add MSP_BOXIDS.

Each box would have a unique id, that should be stable across future versions of MultiWii.
The reply to MSP_BOXIDS would be a list of these ids.

I'm now deeply into development of the next software release for Rushduino and MinomOSD.
I'm looking for a good way to find the correct interpretation of mode bits (as sent with MSP_STATUS). There is 1-1 correlation with the strings sent by MSP_BOXNAMES. I have written a working parser for the boxnames and it's working well with dev_r1317.

There are some drawbacks to using MSP_BOXNAMES..
1. The code to implement this is a bit large and it may prevent addition of more features to the OSD. Also it required increase of the serial buffer size.
2. The Boxnames are just display names intended to be displayed in a table form. MultiWiiConf and other configuration software do not care what a name means. It's just displayed... In the OSD I need to know when the copter is armed and interpret other bits.
I'm afraid that these names may change between versions (just like LEVEL has changed to ANGLE).

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: New Multiwii Serial Protocol

Post by shikra »

Agree - I have just done same for mobidrone. its a pain in the ass.... Especially as" armed" status is the last one in the list. I bet you know that one !!
I was thinking maybe a MSP_Status2... but boxids is better description... quite usefull to know what function is enabled via defines...

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

I vote to have ARMED as an indepent MSP code. Just too much rides upon this code to be mixed in with MSP_STATUS. This is the same problem many of us are having with the mobiDrone OSD.

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: New Multiwii Serial Protocol

Post by shikra »

With 2.1 it was Ok because always same bit being used. With 2.1 the bit used is variable. Problem is the OSD needs to be told by a define that matches the Multiwii config - or figures it out by looking at teh boxnames being used and working out. First is rerstrictive, subject to error. The second takes a bit of effort and space.
I know understand why MichealM hasn't updated mobidromne yet. wanting to see if anything else changes.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

itain wrote:Subject: add MSP_BOXIDS.

Each box would have a unique id, that should be stable across future versions of MultiWii.
The reply to MSP_BOXIDS would be a list of these ids.

I'm now deeply into development of the next software release for Rushduino and MinomOSD.
I'm looking for a good way to find the correct interpretation of mode bits (as sent with MSP_STATUS). There is 1-1 correlation with the strings sent by MSP_BOXNAMES. I have written a working parser for the boxnames and it's working well with dev_r1317.

There are some drawbacks to using MSP_BOXNAMES..
1. The code to implement this is a bit large and it may prevent addition of more features to the OSD. Also it required increase of the serial buffer size.
2. The Boxnames are just display names intended to be displayed in a table form. MultiWiiConf and other configuration software do not care what a name means. It's just displayed... In the OSD I need to know when the copter is armed and interpret other bits.
I'm afraid that these names may change between versions (just like LEVEL has changed to ANGLE).


Hi,
In the past, there was a static ID for each box coded in 16bits, allowing a maximum of 16 item descriptions. A simple solution would have consist in increasing it to 32 or 64 bits.
With this approach, we could one day run out of indexes to describe all the boxes we imagine.
(we have already a description for 19 boxes in the current code)

So instead, we choose to decorelate the index id for each box and associate a BOXNAME as a key index.
You all encountered the main drawback : the only way to know the real function behind is to grasp each BOXNAMES item and to compare the string. You are not the first one to mention this. It’s also problematic because sending all the configured BOXNAMES in a single request could be problematic.

What we can do : add a new array of uint16_t (more than 65k possibilities, or uint8_t maybe it’s enough) is order to uniquely identify a function over the time. The index id would still be variable, but the function comparison should be much easier. This new array could be grasp via MSP_BOXIDS. Is it what you expect ?
Other suggestions are welcomed (only coding consideration)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

KIS, I thought the original intention of the new protocol was to make it backwards compatible. Way things are progressing, with each new change or modification breaks previous versions. :(

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

shikra wrote:With 2.1 it was Ok because always same bit being used. With 2.1 the bit used is variable. Problem is the OSD needs to be told by a define that matches the Multiwii config - or figures it out by looking at teh boxnames being used and working out. First is rerstrictive, subject to error. The second takes a bit of effort and space.
I know understand why MichealM hasn't updated mobidromne yet. wanting to see if anything else changes.


FYI, I have taken a very close look at Micheal's code in hopes of making the modifications myself. I clearly understand why this has not been done and reasons for waiting. :shock:

itain
Posts: 75
Joined: Tue Aug 23, 2011 10:32 pm

Re: New Multiwii Serial Protocol

Post by itain »

Alexinparis wrote:What we can do : add a new array of uint16_t (more than 65k possibilities, or uint8_t maybe it’s enough) is order to uniquely identify a function over the time. The index id would still be variable, but the function comparison should be much easier. This new array could be grasp via MSP_BOXIDS. Is it what you expect ?
Other suggestions are welcomed (only coding consideration)

Alex, that's exactly what I had in mind. IMHO an array of uint8_t would be sufficient.

In addition I would suggest to reorder the box items. As the ARM box is possibly the most important (and it always exists) I suggest to make it the first box/ Simple applications will always be able to find it without the need to interpret MSP_BOXNAMES or the suggested MSP_BOXIDS.

Since we are still in a development version towards 2.2 (or would it be 3.0?) I do not see a need to keep backwards compatibility with previous development version. I don't know if there is any demand for compatibility mode for previous stable versions (2.0 and 2.1).

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

itain wrote:
Alexinparis wrote:What we can do : add a new array of uint16_t (more than 65k possibilities, or uint8_t maybe it’s enough) is order to uniquely identify a function over the time. The index id would still be variable, but the function comparison should be much easier. This new array could be grasp via MSP_BOXIDS. Is it what you expect ?
Other suggestions are welcomed (only coding consideration)

Alex, that's exactly what I had in mind. IMHO an array of uint8_t would be sufficient.

In addition I would suggest to reorder the box items. As the ARM box is possibly the most important (and it always exists) I suggest to make it the first box/ Simple applications will always be able to find it without the need to interpret MSP_BOXNAMES or the suggested MSP_BOXIDS.

Since we are still in a development version towards 2.2 (or would it be 3.0?) I do not see a need to keep backwards compatibility with previous development version. I don't know if there is any demand for compatibility mode for previous stable versions (2.0 and 2.1).


Ok, tell me if you are ok with r1330 ;)

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

No thats really not OK! I have add 119 and 120 for my own addon's I ask for that, but get now response!
And now that?
I'm really pissed

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Why not add a user defined for people that wants to add-on?

Geebles
Posts: 24
Joined: Sat Jan 26, 2013 2:23 am

Re: New Multiwii Serial Protocol

Post by Geebles »

Hey,

I've read through this thread but I cannot seem to get to communicate with my multwii 2.1..

Does anyone have a EXACT string that I can pass in, for example getting the version? I tried using PuTTY on 115200, with $M<100 but get no response.. there doesn't seem to be an example available and the multiwiiconf code is too complicated for me at the moment, i'm just after something very simple to read data back and i'm struggling and some pointers would help.

I have seen a lot of users asking 'how to..' so is there not somewhere where its all explained simply? I understand the formatting but a working example (eg very simple java to read version) would make a world of difference.

Thanks,
Regards Giles

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: New Multiwii Serial Protocol

Post by Mis »

My 5 cents to MSP protocol.
I'm opposite to add new MSP commands for one data. E.g. MSP_RSSI... This need send one more request from OSD for getting only RSSI... Waste resource and time.
IMHO better is consolidate new datas on current MSP commands. E.g. add RSSI value to MSP_BATT (or rename MSP_BATT to MSP_Analog_Data), then in future after next "analog" data is coming (e.g themperature or some other datas) add it at end of exist packet. Software on other side can interpret this data (up to buffer capatibility) or simply trash it if can't interpret this.
Now the OSD need request about 8 packets, and when we add more, we get a lot of not needed data flow.

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: New Multiwii Serial Protocol

Post by kataventos »

Mis wrote:My 5 cents to MSP protocol.
I'm opposite to add new MSP commands for one data. E.g. MSP_RSSI... This need send one more request from OSD for getting only RSSI... Waste resource and time.


Hi Mis,

we cannot go and change everything in MWC, we need to keep compatibility with the rest of the world. MSP requests are usually grouped by function, but I do not agree that all requests that require analog input need to be on one group. Anyway, I think that the final person to decide is Alex.


KV

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Hi,

I tend to agree with MIS.

A MSP frame costs 6 octets for header+checksum.
A transmission of 2 octets (rssi) requires 8 octets on the wire (6 octets for header+checksum).
It’s not a problem for variable we don’t need to refresh at a high rate, but rssi is a kind of real time data.
Adding rssi to an existing message wouls just require 2 octets more on the wire. (6 octets saved each time this variable is requested)

I suggest to gather it with vbat :
- renaming of MSP_BAT to MSP_ANALOG, and we keep the same id
- adding 2 octets at the end : vbat(1 octet) + intPowerMeterSum (2 octets) + rssi (2 octets)

For the concern : "we need to keep compatibility with the rest of the world"
This modification would be transparent with application using the current MSP_BAT, because unknown octets at the tail of a message would just be ignored.
It's an initial feature of MSP in the first post: variable data length allows to consider only the beginning of a message, leaving the other octets at the end to extend transparently the message

The complexity is exaclty the same for OSD.
Are you ok with this KV ?

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: New Multiwii Serial Protocol

Post by shikra »

I did suggest MSP_ANAL before.

I think some people just take it the wrong way. :lol:

cGiesen
Posts: 188
Joined: Wed Jul 18, 2012 7:53 am
Location: Bochum, Germany

Re: New Multiwii Serial Protocol

Post by cGiesen »

And we should think about the raw data!!!
I learn it's important for Measurement and control technology to have this in some gui!

Otherwise you are not able to check the result. In every control technology could be an error!

And this is not time consuming because there are only transmit when a gui ask for that!

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

shikra wrote:I did suggest MSP_ANAL before.
I think some people just take it the wrong way. :lol:

you deserved that :)

When I look at messages, what matters to me is when and how often these are required. So to me the MSP messages fall into 3 categories
- single time setup request - used for initializing a GUI or other device (coptertype, sensors available...)
- repeated/continuous update - used for getting live data (sensors readings ..., both digital and analog, no difference to me)
- on demand request (get/set parameters)

Maybe we can group MSPs and data following this point of view?

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

After taking a look at the APM, maybe we need to consider a Heartbeat. Meaning a minimum data stream sent from the FC both to signal the copter is alive and critical flight information.

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: New Multiwii Serial Protocol

Post by kataventos »

Alexinparis wrote:It's an initial feature of MSP in the first post: variable data length allows to consider only the beginning of a message, leaving the other octets at the end to extend transparently the message

The complexity is exaclty the same for OSD.
Are you ok with this KV ?


Hi,

OK of course Alex, the members of this Team inclusively agree with Mis, and with what has been said here before about that matter.

Just one request... please do not call it MSP_ANAL :lol:

KV

kataventos
Posts: 702
Joined: Sun Aug 28, 2011 8:14 pm
Contact:

Re: New Multiwii Serial Protocol

Post by kataventos »

Hamburger wrote:When I look at messages, what matters to me is when and how often these are required. So to me the MSP messages fall into 3 categories
- single time setup request - used for initializing a GUI or other device (coptertype, sensors available...)
- repeated/continuous update - used for getting live data (sensors readings ..., both digital and analog, no difference to me)
- on demand request (get/set parameters)

Maybe we can group MSPs and data following this point of view?


If this goes down that road, I must say that this is an well organized way to go.

KV

itain
Posts: 75
Joined: Tue Aug 23, 2011 10:32 pm

Re: New Multiwii Serial Protocol

Post by itain »

Alexinparis wrote:Ok, tell me if you are ok with r1330 ;)

Thanks Alex. MSP_BOXIDS is working good as expected. I tested it in flight today today with r1333.

-- Itai

agama
Posts: 5
Joined: Fri Feb 22, 2013 3:23 pm
Contact:

Re: New Multiwii Serial Protocol

Post by agama »

Hi guys.
Do you think to make and publish a common protocol specification.
I looked at a number of projects based on the multiwii protocol and saw some codes intersection.

Maybe I just have not found the document.

Best regards.

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: New Multiwii Serial Protocol

Post by PatrikE »

You can find info in serial.ino what the MSP's contains for each version.
Search for MSP

User avatar
ezio
Posts: 827
Joined: Sun Apr 01, 2012 11:03 pm
Location: Paris
Contact:

Re: New Multiwii Serial Protocol

Post by ezio »

PatrikE wrote:You can find info in serial.ino what the MSP's contains for each version.
Search for MSP


exactly this is the only way right now.
Bart

Olstyle
Posts: 4
Joined: Sun Jan 13, 2013 6:29 pm

Re: New Multiwii Serial Protocol

Post by Olstyle »

I guess you were hoping for something like this:
https://github.com/Olstyle/Joystick2Mul ... rialRC.pdf

I didn't do this for any other messages, but it might help to understand the general idea of the protocol.

agama
Posts: 5
Joined: Fri Feb 22, 2013 3:23 pm
Contact:

Re: New Multiwii Serial Protocol

Post by agama »

Yes, it's good beginning. But question is when messages has variable length. Also it's will be good to describe parameters units and their purpose.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

how to deal with unused values in MSPs?
For example:

Code: Select all

   case MSP_RAW_IMU:
     headSerialReply(18);
     for(uint8_t i=0;i<3;i++) serialize16(accSmooth[i]);
     for(uint8_t i=0;i<3;i++) serialize16(gyroData[i]);
     for(uint8_t i=0;i<3;i++) serialize16(magADC[i]);
     break;

when run without a magneto sensor, the variable magADC[] never contains anything useful; so it makes no sense to transmit it. I think it should not be transmitted and the length of the MSP would need adjustment. Is that ok?

As an alternate route, it would be possible to transmit padding zeros. Kinda stupid, but it would preserve the length of the MSP.

The current implementation of such hard coded references in the MSPs to otherwise unused variables has the nasty side effect that such variables get compiled in and waste memory (and bandwidth for transmission).

So the question is:
how should MSPs handle such cases - either adjust the MSP length or use zero padding?
I prefer adjusting the length. What do you think?

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: New Multiwii Serial Protocol

Post by PatrikE »

If you adjust the MSP length you need more intelligence on the reciever side.
The gui expects a preset length and will go nuts if there's missing data.
The easiest way is to send fixed values for unused values.

A alternative is to use a MSP_INIT at the connection who informs the gui what to expect.
In same manner as the checkBoxes.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Hamburger wrote:how to deal with unused values in MSPs?
For example:

Code: Select all

   case MSP_RAW_IMU:
     headSerialReply(18);
     for(uint8_t i=0;i<3;i++) serialize16(accSmooth[i]);
     for(uint8_t i=0;i<3;i++) serialize16(gyroData[i]);
     for(uint8_t i=0;i<3;i++) serialize16(magADC[i]);
     break;

when run without a magneto sensor, the variable magADC[] never contains anything useful; so it makes no sense to transmit it. I think it should not be transmitted and the length of the MSP would need adjustment. Is that ok?

Adjusting MSP length is something reasonable for servos of motors or boxes, or for optional variables at the end of a message (like rssi)
But adjusting MSP length for every messages is not always relevant.
Typically, MSP_RAW_IMU is here to transmit a generic 9DOF IMU output.

As an alternate route, it would be possible to transmit padding zeros. Kinda stupid, but it would preserve the length of the MSP.

you have to think also to GUI or OSD coders, they expect to have a value.
magADC[x] is 0 if not used.
If you short the length of this message as the GUI is hardcoded to read 3x3 values, some tail values would be read in the inbuf buffer with maybe garbage values.

The current implementation of such hard coded references in the MSPs to otherwise unused variables has the nasty side effect that such variables get compiled in and waste memory (and bandwidth for transmission).

So the question is:
how should MSPs handle such cases - either adjust the MSP length or use zero padding?
I prefer adjusting the length. What do you think?

Explicitly use zero padding would reduce a little bit the code size.
But I'm not in favor to isolate every variable for code readability.
I have something in mind for the next step, using structs in order to avoid memory variable duplications in serial and which should optimize the flash size much more than 0 padding strategy.
But for this, we have to reorganize some parts and move .ino in .h

Post Reply