uNav AHRS

Status
Not open for further replies.
Don Kelly said:
Tim,
I can move GPS to Serial2 if preferred. Easy to do if that syncs with you all better.
Click to expand...

Your system will run better under stress. Serial3 has 1 byte hardware FIFO so each byte triggers an interrupt to unload it. #1 and #2 have 8 byte FIFO and interrupt only fires after ~4+ bytes to transfer to buffer. And that leaves 'slop' room on the processor if the interrupt is delayed to prevent Rx data loss.

If you move - make sure to bump the right core: #define SERIAL2_RX_BUFFER_SIZE 128
 
" Works with F_BUS at 60 MHz" = ok where do I find more info of F_BUS.. Never touched that one before.

"This is still required at the end of initIMU.ino :: Imu.setSrd(IMU_SRD);" - I can edit Brian's library so its doesn't change SRD's and a couple of other parameters for calibration of the gyro and accel. Easy change. Maybe that will fix the problem.

So its sounds like IMU_SPD is doable - oh boy....

Glad to hear that the i2c_t3 changes work.

I will go ahead continuing cleaning the code and fixing getQ in other filters = mostly its a copy and paste now.

Mike
 
mjs513 said:
" Works with F_BUS at 60 MHz" = ok where do I find more info of F_BUS.. Never touched that one before.

"This is still required at the end of initIMU.ino :: Imu.setSrd(IMU_SRD);" - I can edit Brian's library so its doesn't change SRD's and a couple of other parameters for calibration of the gyro and accel. Easy change. Maybe that will fix the problem.

So its sounds like IMU_SPD is doable - oh boy....

Glad to hear that the i2c_t3 changes work.

I will go ahead continuing cleaning the code and fixing getQ in other filters = mostly its a copy and paste now.

Mike
Click to expand...

F_BUS related to T_3.6 usage at F_CPU 240 MHz - posted some time back. With Wire.h I had to bump that to get i2c to work as it failed at default F_BUS=60. Not an issue on T_3.5. The setting is in core: ...\hardware\teensy\avr\cores\teensy3\kinetis.h about line 770 for T_3.6.

Yes, i2c_t3 posted code working here. And it allows noted speed bump.

tonton81 posted updated SPI_MSTransfer code. Doesn't add anything required for use here - may have added a param and perhaps error check - but I'll grab it and check it ... soon.
 
Attached is version 10. A couple of major changes, well actually probably a few:
  1. All kfINS9State related code is in one .h file in the filters directory.
  2. There is now a ifdef for using kfINS9State just in case you don't want to run the INS9State code and just want to use the MARG IMU filter, nice to have the ability just to test the IMU and selected filter.
  3. There is also and ifdef for the GPS again if you don't want to use the GPS or one is not attached for any reason
  4. GPS and kfINS9State is on by default.
  5. GPS is defined in setup in the A_configDefines.h tab and kfINS9State in the global portion of the main ino.
I tested it and it seems to work. Doesn't appear to be any impact. Eventually, if we continue with the kfINS9State it probably should be changed to a library format. Did it this way just to clean up all the ino's.

Mike
 

Attachments

  • MPU9250_INS9State_V10_SPI.zip
    40.4 KB · Views: 74
Made a copy here, will look at it and try to integrate the updated SPI_MSTransfer unless you want to do it first. Seems to just add a param to callback().

Mike: Wonder what difference TViewerSPI with and without makes on your T_3.5 in the IMU/sec counts with the IMU set at 1Khz? Wondering if it goes up over 10% getting that recurring time consuming formatting code removed from the IMU loop.
And yes - with ESP8266 or something ... "At some point will probably have to get it running wirelessly way down the line...."
 
I'll go ahead and give it a try. tonton pretty much laid it out in the other thread.

I will give it a try later on (1Khz). Getting tired of looking at the code - was at it all day.
 
Tim
Downloaded the latest SPI_MSTransfer and made the call back changes in Slave like so:
Code: 
void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {
	if ( 55 == info.packetID ) {
		if ( 48 != length ) {
			Serial.print("Bad Length: "); Serial.println(length);
		}
		else {

Made a similar change to the our ins sketch:
Code: 
void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {
  Serial.print("PacketID: "); Serial.println(info.packetID);
  Serial.print("Length: "); Serial.println(length);
  for ( uint16_t i = 0; i < length; i++ ) {
    Serial.print(buffer[i], HEX); Serial.print(" ");
  }

Wound up with packet resends constantly but still sent data to the slave but the imu/sec went down to 11 from 34. On't know if its me or MSTransfer> probably me.
 
Got it. I am uploading the new SPI_MSTransfer lib with the example Slave and Master I updated. They exhibit the same thing as our INS sketch.

thanks
Mike

EDIT: Decided to attach the modified v10 as well if you want to give that a go.
 

Attachments

  • SPI_MSTransfer.zip
    9.1 KB · Views: 74
  • MPU9250_INS9State_V10_SPI.zip
    40.4 KB · Views: 77
Last edited:
Just to note:

the slave end can run events in tight loop it's fine
for the master, run it by millis instead, otherwise blasting the ISR wont let the slave get chance to run it's own loop code
 
Using the above tested Example Master & Slave from provided SPI_MSTranfer they work - With a TWO **** Packet resent *** in 14 minutes.

Maybe the SPI wires are long or 'iffy'? T_3.6 compiled at default 180 MHZ and T_3.5 at 120 MHz and SPI is 30M >> SPISettings(30000000

Leaving that SLAVE running against the provided p#734 : MPU9250_INS9State_V10_SPI.zip - It is working on both the V10_SPI(Master) and the Slave?

Just to confirm I find this line in the code [ MPU9250_INS9State_V10_SPI\MPU9250_INS9State_V10_SPI.ino ] being compiled:
void myCallback(uint16_t *buffer, uint16_t length, AsyncMST info) {

NOTE: in A_ConfigDefines.h for defragster :: I had to change to this to run :: #define IMU_SPD 1000000
 
Tried it again - reloaded master and slave. On the master I get:
Code: 
returned value micros() _time==51
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************

On the slave:
Code: 
840.000000,    0.0008,    0.0008,48300.339844,48357.636719,  845.0000,   29.0861,   29.1033,   29.1204,  849.0000,  850.0000,  851.0000
852.000000,    0.0009,    0.0009,48987.890625,49045.183594,  857.0000,   29.2916,   29.3087,   29.3258,  861.0000,  862.0000,  863.0000

Long time between packets. Something with T3.5 vs T3.6?
 
Ok - typing together again..

<Just to confirm I find this line in the code....> yep - that's the line in the call back I changed. Think that was about all that was required. Reloading the MPU9250_INS9State_V10_SPI now with IMU_SPD at 1000000. Will let you know with an edit.

EDIT: No good. This is what I getting on the master with v10 loaded and slave that I sent you:
Code: 
-----	22  ------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX--------	 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
	 #18 (!22)  @3:10.46_800069047 [fix:0 #:0 >> 1==	 ms_37341
 IMU/sec=13

-----	26  ------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX--------	 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
	 #19 (!26)  @3:10.47_68791 [fix:0 #:0 >> 1==	 ms_38160

-----	30  ------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX--------	 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
 ************** Packet resent ****************
	 #20 (!30)  @3:10.48_600066749 [fix:0 #:0 >> 1==	 ms_39141
 
To answer your other questions:
< SPI wires are long SPI wires are long?> wasn't a problem before. so I doubt it - they are pretty short.
<T_3.5 at 120 MHz> using 2 T3.5 at 120, recompiled and reloaded a few times with same results.
<SPISettings(30000000 > that's what I am currently using - believe a bunch of posts you said to update the settings to 30 which I did and it worked before the current set of changes.

So at this point, haven't a clue - may just go back to previous version.
 
I have 87 instances in ~2.5 hours.

Maybe Set the SPI speed back down as one quick test.

<edit>: Just bumped mine to 60 MHz SPI and seeing mostly errors (requires F_BUS==120 and F_CPU=240). Example Slave time is 24 when it works versus 39 at 30 MHz 240 MHz. I am seeing some error clumps go by now.

That does seem like something changed in the code?
 
Last edited:
Took your suggestion and changed the SPI Settings to 20MHz and it started working again, both for the examples and the INS code. Seems a little slower.
 
The transfer time is 100 uS at 10 MHz - up from 39 at 30 MHz. So if it hits 20 as valid that will be in the middle {just tested and see 52 uS at 20 MHz on T_3.6, and 45 at 24 MHz} - still much faster than the Float Formatting and USB over head that is ~250 us on the T_3.6. And the SPI code will not change as much between T_3.5 & 3.6 as it is the SPI clock rate that determines transmission time - where the Float Formatting on the T_3.5 will be over 500 uS on a T_3.5 at 120 MHz {reported by Dtime( 4, 10, "dtos_OutKF" ); (make the 10 a 1 to see time when Dtime enabled if under 750)}. BTW: in was 24 MHz in prior version 0.0.4.

I posted on the SPI_MST thread in case Tony can see an issue - he noted he removed loops and made changes - perhaps one is triggering the failure? I was thinking of doing a CodeCompare diff to see if anything jumped out - but no promises there.

The Master uses SPI Library command support - the Slave uses a more manual approach AFAIK - it may have trouble keeping up with the Master driven clock? Perhaps Compile the SLAVE T_3.5 at 168 MHZ? I was using 120 when the 60 MHz T_3.6 was failing. ... No help at 60 MHz with T_3.5 slave compiled at 168 MHz. And I put FASTRUN on the spi0_isr() and it didn't help either.
 
Hi Tim.

Wasn't complaining just on observation on watching the data stream from the slave :) I agree wholeheartedly that it is a whole lot better than streaming all that data over usb using just one T3.5 or T3.6

<it may have trouble keeping up with the Master driven clock? > That may go along with tonton's p#735 in this thread. Will have to give it a try. Was curious so I did it tonight. Have to get some sleep sometime:) I did see the post on the SPI_MST thread.

At least we got it working on my T3.5 with the latest changes.

Don... if you give the new SPI_MST version a try don't forget to comment out FastLED and Wire from the .h and .cpp.

Mike
 
Does fastled still complain - I saw some 'q' get renamed - maybe that wasn't all of the conflict.

Didn't see it as a complaint - just measuring your hypersensitive ability to see it being slower :) - and making sure there wasn't a CUSP of slowness in there.

The SLAVE is showing error SPEW in it's output - that needs to be hidden from TViewer. It can be sent back to Master is desired to print if it adds up. Going to post a sample to Tony.

BTW: The Master<>Slave is bidirectional - the Master can issue .print() to the Slave - have to check if the Slave can issue that back to the Master.

I never tried or looked .... but does TViewer safely ignore messages that are not of the expected format?
 
<Does fastled still complain > I commented FastLED out for now. When I checked in the last revision it didn't complain when I left FastLED in. Any time I use q its as a local variable and that seems to make fastled happy :)

<your hypersensitive ability to see it being slower > Arrgh! Going to keep my mouth closed from now on........:(

<Master<>Slave is bidirectional > thought so - saw you ask in the other thread - been trying to keep up with both....

<does TViewer safely ignore messages that are not of the expected format> Pretty sure it does - I had some messages printed out to while Tviewer was on and it ignored them if it wasn't the right format.

Going to try and boost up spi settings to 24 MHz and see what happens.
 
Just by way of an update on SPI_Settings:
  1. Using 168MHz for slave and 120MHz for Master did not work
  2. Using 30MHz for slave and 24Mhz for master did work.
  3. Using 24MHz for master and slave worked.

Just by way of reference my printRate is 25ms between prints.

Mike
 
Don-Tim
Since we keep talking about Tviewer. Here is a Tviewer layout you can play with for the INS9State.
 

Attachments

  • INS9State.txt
    3.9 KB · Views: 87
Tim, Mike,
Just got my new board calibrated, and finally got version 9a up and running. Whew, that's fast!!! Running both T36 at the standard 180MHz.

Taking a break for a bit, but will come back and switch to your new V10 and TViewer files. Looks like I'll need to do the following too to catch up:
1) switch to Serial2 and modify buffer size (per Tim)
2) switch to new SPI_MST version and comment out FastLED and Wire from h and cpp files
 
Status
Not open for further replies.
Back
Top