MultiWii

Hi
Could we have a file with protocol decryption which will be updated when there are the changes in MSP protocol ? (something like this https://www.dropbox.com/s/m1ssij26q61cp94/protocol.ods )

Or could we have a descryption in the Protocol.cpp ?
it is frustrating to find what the values means if they labeled like this:

come on, can't you use normal names ?
Bart

Having descriptive variable names will increase code size.

Ok, I will try to complete your doc and put it on the wiki.

Alexinparis wrote:Ok, I will try to complete your doc and put it on the wiki.

Or maybe we can create a new topic where we can put the protocol changes?
like EOSBandi has done here:http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989

timecop wrote:Having descriptive variable names will increase code size.

Only source code size. Not onboard code size.

Self-descriptive code is very usefully then comments.

Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?

Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?

In my opinion, that MPS code will become very useful in the future. I hope one day that the WMC is ported to the Raspberry and DUE.

No, copterrichie that is covered by MSP_IDENT alone. Transmitting serial numbers is a different story it is more in the direction of personalization and the beginning of what DJI does in (much, much) greater extend (and working..). And I remember that Kraut bitching something like that .. too bad that tc didn't write down the serial numbers of his sold cpus.. .

Sorry, you can direct all whining about MSP_ID or whatever to cGiessen. Not my problem/concern.
Maybe if I used git, you'd notice that wasn't committed by me.

Crashpilot1000 wrote:No, copterrichie that is covered by MSP_IDENT alone. Transmitting serial numbers is a different story it is more in the direction of personalization and the beginning of what DJI does in (much, much) greater extend (and working..). And I remember that Kraut bitching something like that .. too bad that tc didn't write down the serial numbers of his sold cpus.. .

Sorry, I stand corrected.

@TC: I see, you are not responsible for stuff in your repo. And you have absolutely no clue what spirit is behind that. And of course you didn't say on IRC that you are planning to crash other hardware than yours.

Crashpilot1000 wrote:@TC: I see, you are not responsible for stuff in your repo. And you have absolutely no clue what spirit is behind that. And of course you didn't say on IRC that you are planning to crash other hardware than yours.

Get a fucking clue and a sense of humor.

If you can come up with a way to keep 1000s of stm32's identifed as "my hardware" in under 4k of flash, I'll give you 1 internet cookie. Maybe next I'll add a hashing function and some license codes, in opensores software.

And stop crapping up every fucking thread with your garbage. The man asked about MSP docs, you're bitching about non-standard MSP that doesn't even have any relation to multiwii. Good job, now these posts will have to be deleted again.

I bet you would, if you could.

fryefryefrye wrote:

timecop wrote:Having descriptive variable names will increase code size.

Only source code size. Not onboard code size.

Self-descriptive code is very usefully then comments.

Yes i fully agree. Properly named variables, functions, files and classes all increase code readability.

I recommend everyone watch this episode of Clean Coders: http://www.cleancoders.com/codecast/cle ... ode-2/show

Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?

ups - got a head Crash recently?
imagine you have a mesh Network.
how to address the correct node?
the unique id is extremely helpfull in doing so.

i have a few boards behind me to create a mesh Network.
the unique id is very helpfull to create the correct short address for communicating.

timecop wrote:Having descriptive variable names will increase code size.

bad Compiler - use a better one.

brm wrote:

Crashpilot1000 wrote:Alexinparis:
Did you agree to that: http://code.google.com/p/afrodevices/so ... erial.c#53 ?
It's sole purpose is to send a CPU ID to make it possible to exclude unwanted hardware. Is that in the spirit of multiwii or just born in 2 sick brains?

ups - got a head Crash recently?
imagine you have a mesh Network.
how to address the correct node?
the unique id is extremely helpfull in doing so.

i have a few boards behind me to create a mesh Network.
the unique id is very helpfull to create the correct short address for communicating.

Oh, yes the stacked multiwii controllers communicating whith each other to guide the Marsmission. Sorry I forgot about that. ESA and NASA are already testing multiwii code for that and pixhawk.ethz.ch is planning their next realtime multicopterproject based on mwii.

I think crashpilot1000 do his name exact like the number in his nick.

I fact. The idea behind MSP_UID is to link the backup of settings with the board.
I case you use a wrong file during restore you get a warning.

No, that not the true.
In the firmware there is a hidden function to link the UID to the owner of the copter.
In case of the situation that someone do some bad thing with the copter, NSA now who is the terrorist.

Can not be that bad
https://github.com/Crashpilot1000/Summe ... rial.c#L49

Oh, yes shure.

Thats why it reads here http://code.google.com/p/afrodevices/so ... board.h#37:

// Chip Unique ID on F103
#define U_ID_0 (*(uint32_t*)0x1FFFF7E8)
#define U_ID_1 (*(uint32_t*)0x1FFFF7EC)
#define U_ID_2 (*(uint32_t*)0x1FFFF7F0)

Even the comment shows Its intend: Identify the CPU and not for some softwareversion. MSP_IDENT would have been sufficient for versioning.
I already removed that stuff for the next version, once I understood the real intend. Anyway I keep my source public at known places, others burn everything (docu&code) and wait for someone to ask for it.

Crashpilot1000 wrote:Oh, yes shure.

Thats why it reads here http://code.google.com/p/afrodevices/so ... board.h#37:

// Chip Unique ID on F103
#define U_ID_0 (*(uint32_t*)0x1FFFF7E8)
#define U_ID_1 (*(uint32_t*)0x1FFFF7EC)
#define U_ID_2 (*(uint32_t*)0x1FFFF7F0)

Even the comment shows Its intend: Identify the CPU and not for some softwareversion. MSP_IDENT would have been sufficient for versioning.
I already removed that stuff for the next version, once I understood the real intend. Anyway I keep my source public at known places, others burn everything (docu&code) and wait for someone to ask for it.

you are too fucking paranoid.. okay now let's think about a scenario where a unique device ID might be useful..
what about if you have more than one naze32/multiwii board or whatever.. and you have different settings on each board/copter. With a unique ID you could tie every setting to a copter and possibly restore stuff if it gets lost and/or reduce errors on the user side. This is one thing I could think of. Use your imagination. There are quite a few other use-cases for sure.
I mean it really makes zero sense using that stuff for some kind of copy protection of OPENSOURCE-SOFTWARE.
Additionally TC doesn't even have his own GUI and cGießens stuff is just a copy of MultiWiiWingui.
Seriously I don't get why you have to SPAM the forums with such fucking nonsense...
Oh i forgot there is going to be a naze64ultrapro for 1000$ which will make use of this and will crush DJI

Could you guys focus on the TOPIC ?

ezio wrote:Hi
Could we have a file with protocol decryption which will be updated when there are the changes in MSP protocol ? (something like this https://www.dropbox.com/s/m1ssij26q61cp94/protocol.ods )

Or could we have a descryption in the Protocol.cpp ?
it is frustrating to find what the values means if they labeled like this:

Code: Select all

struct {
       uint16_t a,b,c,d,e,f;
       uint32_t g;
       uint16_t h;
       uint8_t  i,j,k,l;
     } misc;

come on, can't you use normal names ?
Bart

Hi,

Here is a first draft based on your doc.

That is perfect!
Thank you very much Alex!
Could we, from this point, put the changes in the protocol in this thread with some decryption ?

How about discussion here and final documentation in the wiki?

I found a bug in a documentation

should be

MSP_STATUS
global_conf.currentSet - > UINT8

I found a bug in documentation (and most of the settings)
Their range of values is not documented.
Things that come to mind:
conf.mag_declination (what is its value in processing? why is it /10 there? what?)
various vbat*scale/min/max related shit. they seem to be getting * 10 / 10 stuff in various places. why.

ezio wrote:That is perfect!
Thank you very much Alex!
Could we, from this point, put the changes in the protocol in this thread with some decryption ?

Hi,
I added a page here:
http://www.multiwii.com/wiki/index.php? ... l_Protocol

I hope it will be a better basis to discuss&correct things

timecop wrote:Things that come to mind:
conf.mag_declination (what is its value in processing? why is it /10 there? what?)
various vbat*scale/min/max related shit. they seem to be getting * 10 / 10 stuff in various places. why.

mag_declination is in 1/10 degree. /10 is used because heading is in degree after IMU computation
vbat /10 and * 10 is used only in GUI, no ? It's just to display something in volt with its fraction

I like to see a command like
MSP_FIRMWARE

Today there is no way, to see witch firmware is used on the board.

I suggested extension to return firmware version/build/something months asgo, and it was ignored.

I know. I hope they forgot that and put it in now

I really don't know how this project work.
What is needed to got things like this?

I suspect you will need to make a patch to 8bit trash + multiwiiconf to make use of new extension/MSP
and wait for it to be either applied or ignored.


EDIT:
Looks like ignoring version / firmware request has been going on for a while, i just found this old post
viewtopic.php?f=8&t=2145&p=19775&hilit=firmware+version#p19775
requesting same thing...