Twos compliment in Oshonsoft and Compass calibration

[Pommie]

The floating point numbers CANNOT come from a 16 bit number. 502.50 (line D) and 299.23 are far too big and with greater accuracy (2 decimal places) than is possible from a 16 bit number. What module is this compass? Is it a HMC5883 based design? Where does the attachment above come from?

Mike.

 

[jjw]

I think these floating point values are the calibrated values calculated from the raw values with the correction matrix, which has floating point coefficients, see picture 9 from the link msg# 52 and are for watching live 3D data on the screen.
The real accuracy of the values can't be two decimals.
When calculating the angles from calibrated magnetic field data even values rounded to integer are good enough.

 

[camerart]

The floating point numbers CANNOT come from a 16 bit number. 502.50 (line D) and 299.23 are far too big and with greater accuracy (2 decimal places) than is possible from a 16 bit number. What module is this compass? Is it a HMC5883 based design? Where does the attachment above come from?

Mike.

Hi M,
I'm using the AK8963C compass only chip from iphone 5.
This can be directly accessed via SPI, unlike the HMC5883 'acc/compass' modules which use I2C to access SPI.
https://www.datasheetq.com/view.jsp?pn=AK8963C&fac=AKM

Note Little endian, and set to 16BIT.

NOTE: clarification in #59
C.

 

[Pommie]

None of this is in the datasheet. Where is this coming from? What is Magmaster?

Mike.

 

[camerart]

None of this is in the datasheet. Where is this coming from? What is Magmaster?

Mike.

Hi M,
The data sheet is for the AK8963C compass module.

Magmaster and Magviewer are prgrams that visualise the XYZ compass DATA, to assit with calibration : https://diydrones.com/profiles/blogs/advanced-hard-and-soft-iron-magnetometer-calibration-for-dummies?id=705844:BlogPost:1676387&page=4

C.

 

[jjw]

Hi,
J and P,
Yes, a bit confusing!
It needs the 6x measurement register READings, in this format. ( I added the - to the HSEROUT, so not real, but it worked)
255,255,255
78,-230,138
255,255,255
89,-225,137
255,255,255
84,-230,146
255,255,255
84,-228,150
255,255,255
87,-231,149
255,255,255
81,-231,143

They are as the image in #52.
Once these are running, they show in the top bar.
Move the compass module around in these 12 orientations, (see image), while pressing the nearby button to enter each READing into Magmaster.

The Magviewer only needs the DATA as #52.
C

Are these real values from the sensor?
255,255,255 looks suspicious.
Can you show how you get these numbers from Xlowbyte, Xhighbyte, Ylow, Yhigh....

 

[Pommie]

What are the raw values for XL, XH, YL, YH, ZL & ZH? In hex or decimal.

Mike.

 

[camerart]

Are these real values from the sensor?
255,255,255 looks suspicious.
Can you show how you get these numbers from Xlowbyte, Xhighbyte, Ylow, Yhigh....

Hi J,
Yes, the READings are from the sensor, and seen in a terminal (Teraterm). Once I see the outputs, I switch over to Magviewer.

I've puzzled myself about the 255s. I get the impression that the sensor needs 9x BITs to get 360DEG, but simply fills up the BYTE, giving 255. This also give the twos compliment BIT.

Here is the program I used to get those figures on that date:

I am pretty sure there are errors in the program (I do get a bit mixed up), but I think the HSEROUT gives the correct order for Magviewer. I also 'stuck in' a comma into HSEROUT to see if any DOTs in Magviewer crossed any line, DOTs did cross the line.

 

[camerart]

What are the raw values for XL, XH, YL, YH, ZL & ZH? In hex or decimal.

Mike.

Hi M,
I think the HSEROUT as #55 is the RAW data, converted to STRINGs. I thought that Magmaster needed the RAW DATA?
C.

 

[jjw]

Hi M,
I think the HSEROUT as #55 is the RAW data, converted to STRINGs. I thought that Magmaster needed the RAW DATA?
C.

I think it needs data converted to strings.

 

[jjw]

Hi J,
Yes, the READings are from the sensor, and seen in a terminal (Teraterm). Once I see the outputs, I switch over to Magviewer.

I've puzzled myself about the 255s. I get the impression that the sensor needs 9x BITs to get 360DEG, but simply fills up the BYTE, giving 255. This also give the twos compliment BIT.

Here is the program I used to get those figures on that date:

I am pretty sure there are errors in the program (I do get a bit mixed up), but I think the HSEROUT gives the correct order for Magviewer. I also 'stuck in' a comma into HSEROUT to see if any DOTs in Magviewer crossed any line, DOTs did cross the line.

You are sending 0x83-0x88 to the sensor.
What is the 8 before dataregisters, slave address? Is it right address?
All the data is in wrong order, address 03 is Xl, 04 is Xh,...
You use only the low byte for X, Y, Z, should combine Xl, Xh, Yl, Yh... to 16bit.

 

[camerart]

I think it needs data converted to strings.

Hi J,
I READ 0x03-0x38 (Each address BYTE--BIT7 = 1 READ)
Convert the 2x BYTEs to a WORD then to a STRING. (I'll re-check)
When I said there are errors, this is what I meant, but I think HSEROUT has them in the correct order (I'll re-check)

You use only the low byte for X, Y, Z, should combine Xl, Xh, Yl, Yh... to 16bit. Do you mean, combine X1 and X2...... to 16BIT then convert each to a STRING then send each to Magviewer with no twos compliment calculation?
C.

 

[camerart]

HI J,
I've re-written the program:
Here is a more interesting Magview, but still no line crossing.
There needs to be a way of programming 'negative sign'
C.

 

[jjw]

Twos complements should be:
If X_sing > 32767 then // negative?
X_sing = 65536 - X_sing // now the string #X_sing is "-ddddd" d is 0 to 9
Endif
same for Y_sing, Z_sing

 

[camerart]

Twos complements should be:
If X_sing > 32767 then // negative?
X_sing = 65536 - X_sing // now the string #X_sing is "-ddddd" d is 0 to 9
Endif
same for Y_sing, Z_sing

Hi J,
I changed the program but the Magviewer shape is the same?
I think the problem still revolves around the lack of negatives. I'm pretty sure Oshonsoft can't produce them.
C.

 

[jjw]

Of course Oshonsoft can produce negative values if the word in twos complement is negative.
This means that the sensor doesn't produce negative values or you are not using the sensor in 16bit mode.
Did you rotate the sensor when getting these values?
Can you show Xlow, Xhigh, Ylow, Yhigh, Zlow, Zhigh bytes and the code again.

 

[Pommie]

Hi M,
I think the HSEROUT as #55 is the RAW data, converted to STRINGs. I thought that Magmaster needed the RAW DATA?
C.

#55 contains 12 numbers with with numbers thar can't fit in a byte. What are the 6 byte values you get from the compass?

Mike.

 

[camerart]

#55 contains 12 numbers with with numbers thar can't fit in a byte. What are the 6 byte values you get from the compass?

Mike.

Hi M,
I've edited #55 to clarify 6x batches of 6x numbers all within BYTE size.
Previously, I said I had physically added the negative sign, to see DOTs cross lens in Magmaster. They did. In the edit, I removed the negative signs, so this is what the is outputting.

J, Yesterday some incorrect programming outputted negative values, so you are correct that Oshonsoft is capable. (I wonder where I got 'it can't' from?) I'll try again and post it.
C.

 

[Pommie]

There are now 36 values and no indication of which is which. Just post the values here. I will not go back again to look at another futile edit.

Mike.

 

[camerart]

Hi J and M,
Here is the latest program:

360 CW + CNTL1 shows:
BYTES = 3x Outputs after twos compliment calc inside [ ], then the CNTL1 BYTE=18 shows the compass is in CONTINUOUS MODE and 16BIT.

DATA = 6x RAW BYTEs

All from a Terminal while rotating 360 CW.
C.