uNav INS

I wonder what causes this? { This was with TViewer ... went to !TViewer - will see if it shows again }
2299.2041,NAN ,NAN ,NAN ,NAN , NAN ,NAN ,NAN ,NAN ,NAN , NAN ,NAN ,NAN ,NAN ,NAN , NAN ,NAN NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,NAN ,

Also saw this with TViewer: #64 @22:18.48_800080792 [fix:3 #:6
Recompile !TViewer and a 1:29 later: #293 @22:20.17_111146 [fix:3 #:13
 
Hi Tim
I can confirm. With Tviewer running was getting 7-8 sats, with out it running was getting 11-12-13 sats.

My guess is you lost your IMU.
 
Tim - just thought of something - the buffer's max size is 150, we are already using 144 bytes.
 
Mike,
The minimum 5 sats is from the original uNavINS code. I'll revise that when I can get back to coding. It'd be nice if the prop occurs even if numSV is less than 5. Another interesting twist is there are actually 9 measurements now (GLS LLA, GPS VelNED, and the three mag-error calculations). So it might get to where we add smarts to do either (GPS, mag) or both. Something else to ponder anyway.

Have a small data analytics study that kicks off in the morning that I've been gearing up for, but things will be back to normal after the kickoff.

I downloaded the code from your post. Are there any recent edits I need to insert in it? Guess I'll need to track down tonton's latest SPI library as well.

Thx!
Don
 
Thanks Don. Good luck tomorrow.

EDIT. Can't seem to get Tviewer to read all 36 values...... Not sure what the problem is.
 
Tim - just thought of something - the buffer's max size is 150, we are already using 144 bytes.

You mean this: "Circular_Buffer<uint16_t, 32, 150> mtsca;" in SPI_MSTransfer?

Do we really need #32 of them? How many are active at one time?

I get #288? Double is 8 bytes>> double MST_PrintVals[36]; from 8*36? Maybe that led to the NAN's I saw twice?

FIVE should be enough right? So 12 * 400 is the same 4800 bytes.
 
"Do we really need #32 of them? How many are active at one time? " - Think I came up with 32 a while back. Seemed to work best for the T3.5/T3.2 combo.

"I get #288? Double is 8 bytes>> double MST_PrintVals[36]; from 8*36? " - thought it was 4bytes (32 bits) * 36 which would be 144 for the length which was in agreement with the length from the slave - for 12 you had 48 for length which would be 4*12?

Since I changed the i2c rate. I haven't seen any NaN's. Only time that happened besides loosing the IMU was when I had something off in the code.

BTW tried 3.4M for the I2C - got all kind of errors on startup from the 9250, on check wiring.. with different error codes.

EDIT> Forgot to mention I just upped the 150 to 200. Haven't checked if that made a difference to the GPS or not yet.
 
Almost got me there ... if ( 48 != length ) { ... units for SPI_MSTransfer are 16 bit words so 48 is 96 bytes [12*8]. A float is a 32 bit value ( with native T_3.5/3.6 support ) a double is 64 bit floating point.

DOH! ... same with those :: Circular_Buffer<uint16_t, 32, 150> SPI_MSTransfer::mtsca;

So those are safe for 37 Doubles - if the extra 0.5 (4 bytes) covers any system overhead.

#32 CB's seems large - IN and OUT are separate buffers? The Slave for TViewer IN should not need more than 3? if Working #1 when #2 arrives and a #3 pinToggle? Any more than that is eventual overflow if not handled 1 for 1 ( with some slop for USB catchup ) - which is where I got 5.

Bummer your i2c is spotty at 400 and 3.4. Perhaps that is F_CPU related? I'm at 240 MHz with no (apparent) problem ...
 
"Perhaps that is F_CPU related?" = could be, probably, not sure why. Would like to stick with the T3.5. This is where we are finding the issues for SPI_MSTransfer. For a library to work is should work with all T3.x series boards otherwise we are going to limit the usefulness of the library. I would think.

"#32 CB's seems large" - pretty sure tonton81 did a bunch of testing when he put the whole thing together maybe should him email or post in the other thread. You don't think - spi is interfering with I2C and Serial ports?
 
you dont need 32, its been stuck there since testing stages, even 3 should suffice as you want it processed as soon as possible, if you queue more than 3 your basically overriding oldest queue, at which point you should give slave more processing time (5ms loops, 10ms etc, but yeah, 32 is too large for MST, for other libraries they can benefit from a bigger queue tho.. teensy has enough ram to not care anyways
 
Pretty sure that Serial is immune to the SPI. Transmitted messages appear to come through as expected with no corruption - no longer time counted in gpsDebug - but they are grouped right showing 5/sec.

My i2c stays running - but it is soldered to the T_3.6 underside.

As noted my wonderment is if the SPI NOISE is impacting the GPS processing or reception?
Just looking and my Slave and FIX is ZERO SATS .... GONE - for many pages of gpsDebug. Unplugged Slave and it came back, replugged Slave and it is staying active.
not yet done - but I need to think of a good way to remount/connect the Master&Slave - better wires routed away from GPS isolated more from the Teensy units to see if that helps.
 
spi interfering with i2c? on master no, but on slave i would imagine a priority spi has is higher than the ports, you might want to adjust their NVIC priorities as well
 
spi interfering with i2c? on master no, but on slave i would imagine a priority spi has is higher than the ports, you might want to adjust their NVIC priorities as well

Slave only reads SPI and Talks USB - no Serial or i2c on Slave. That is on Master.

As noted 3 Seemed good - with room for breathing. Indeed 32 seemed extreme. T_3.2 only has 64 KB so we don't want to waste it with unneeded buffers it might use otherwise.
 
if the timing is right processing > is faster than < receiving, a queue of 1 is enough :p
the idea of it originally was to fire the data from outside the ISR, thats where the queue shines
 
GPS dropped FIX again w/TViewer - unplug Slave 12 seconds and fix==2 w/SATS==3 returns and lasts 6 seconds as plugged back in - then lost - repeat - fix blink - replug and gets no fix

Decided to add delay(4000) where I speed the heartbeat when SATS !>5 - it fires once or twice and then FIX is restored!

Something on Master causing trouble - for GPS?

Turned off the pinToggle and let it run - when GPS is gone there is no F&F of the data - and when it goes to FIX==0 it stays that way. That didn't change anything - so it isn't the pinToggle ACK alone. Turning off the F&F's from serialPrint()? Still not holding FIX for long. Now I can pull Slave power with no SPI_MST loss or errors - opps aHRS.events(); causes RETRY errs. Taking that out.

That does it - something in aHRS.events(); is killing the GPS from activity - never looked - I suppose it is polling the Slave for return msgs?

GPS quickly goes and stays HEALTHY :: #326 @2:41.42_599898924 [fix:3 #:15

EDIT>> GPS FIX staying alive - 40 minutes ( nice having GPS timestamped messages )::
>> #1 @2:40.25_399870155 [fix:3 #:12
>> #11863 @3:20.10_-237073 [fix:3 #:13
 
Last edited:
Updated uNavINS_MPU9250_I2C_MAGV1.ino

I've restored the F&F's and pintoggle() and removed the loop() call to aHRS.events(). System running as desired for some few++ minutes with 11 to 17 SATS!

Here is my main.ino with changes as noted ( including new counters detailed in edit below):

This just removes the Slave's talkback ability. It was being called on EACH LOOP pass without a limiter << with limiter it would likely be fine! >> - Now Avg over 552,000/second !!! from 549K to 556K - only way I can see it as a problem was bad digital noise to the GPS.

Reminder Note: Add " void yield() {} " to sketch! Adding that increased loop counts to 891K to 901K! // unless sketch uses serialEvent()

@tonton81 - might want to add an optional .events( param MinTime=100 ) and return immediately on calls made in less than MinTime - at least for MASTER? Though the caller could regulate that as well?

Mike: Puzzled: Why is this 'TEENSYDUINO' in the main INO? :: #if defined(TEENSYDUINO) status = Imu.begin();

Also the 30000000 is hard coded in :: SPI_MSTransfer aHRS = SPI_MSTransfer() - might be nice in config defines if that ends up personally adjusted?


<edit> NOTE:: My GPS has not lost FIX in all this testing since .events() went away! Seeing 10 to 13 SATS. After posting this I see SATS==16 !!!! { with 500 Hz IMU to TViewer }

My MPU9250 doesn't work with restore of setSrd() as done in calibrateGyro - have to add this line in ...\B_loadCalValues.ino
Imu.calibrateGyro();
cout.println("Gyro Calibration Complete"); cout.println(" ");
Imu.setSrd(IMU_SRD);

Doing SPEED test with Master:T_3.6@ F_CPU=240 and F_BUS=120 with Slave::T_3.5 @120 MHz
Code:
      Imu.readSensor();
      Filter.update(uBloxData.iTOW, // ...
      serialPrint();

>> This shows passes through loop() as Loop#:__ and processed Imu.readSensor group as IMU#:__

With TViewerSPI and :: #define IMU_SRD 1
-----Loop#:442K IMU#:502

Without TViewerSPI - it still does 500 IMU updated/sec - but spare loop() passes drop way more from 890K above.
-----Loop#:102K IMU#:501
-----Loop#:45K IMU#:500

With TViewerSPI and :: #define IMU_SRD 0 { I see some Bad CRC: detects on SLAVE }
-----Loop#:0K IMU#:936

Without TViewerSPI -
-----Loop#:0K IMU#:560
-----Loop#:0K IMU#:561

So my system as configured can complete 500 [IMU updates&Filters&Prints]/sec with Srd=1 with plenty of spare on Master time using TViewer, without TViewer it is getting close to MAX it can do of 560.

Or using above numbers at 500 Hz:: No TViewerSPI is hitting 89% MAX capacity, and with TViewerSPI it is hitting 54% capacity.
>> SOMEHOW this is over 2X faster than last time I tested with more math and more big numbers?

Loops goes to 0K because it is barely/NOT finishing one update when the next arrives, and the Slave - even bumped to 168 MHz is catching Bad_CRC's. Infact dropping Slave T_3.5 back to 120 MHz it is the same or better.
{ 144 on T_3.5 may be worse and dropping MASTER SPI from 30 MHz to 24 MHz did no BIG help (some?) and that drops TViewer loop count 10K to 433 }
{ I did not instrument the Slave to count the Bad_CRC's - but it is ~1/1000+ lost messages to TVIewer. }

I had to repower after the last reprogram with Srd==0 is throttling the MASTER it seems - as it printed ONLY "Serial Initialized" and STOPPED.
Dropped back to 500 Hz IMU and I still see Bad_CRC scroll by - one or two every few seconds.

Above code updated with the LOOP&IMU counters so Mike can see where the T_3.5 safe zone is. The prints are from the gpsDebug() added when the second changes.
 
Last edited:
Ok. Looks like I have to stop sleeping at nights just to keep up you guys.

Will give the new sketch a try and let you know
 
"Puzzled: Why is this 'TEENSYDUINO' in the main INO?" - originally was intended to be general to use Wire or I2C_T3. Don't really need since all we are using are Teensies.

Also going to change SPI_MSTransfer to 5,200 just to be safe - in case we need to add anything else

EDIT: Not sure whats going on now - but while I am getting the gps prints on the master and the led is blinking on the slave nothing is being printed on the slave. The other thing that might effect is the slave buffer, which I put to 5,200?

EDIT1: ok that wasn't it. Can not get a consistent lock between the 2 t3.5s again. More matching speeds.
 
Last edited:
Tim, did you try running events() instead of a tight loop, every lets say 100ms, events is only for capturing data from slave so speed isnt an issue unless you want data captured from slave if its sending at higher speeds than 100ms

example, if your slave is queueing every 1000ms data to master, you can run events() on master in 950ms intervals or so

all your f&fs can run full speed

in any case, the circular_buffer library is being tested currently in another library being hit at 0ms rates locally while it handles uart traffic, so its a pretty rock solid library for circular arrays and ring buffering
 
Last edited:
Tim
I seem to back on line again with the 2T3.5s (168 on both). I am seeing the same number of satellites with and without SPI transfers. So that works.

As for my other problem I plug the master in and then the slave and data transfers on connection.

Mike
 
Tony - yes I understand that - and 100 ms is what I was suggesting in this note
@tonton81 - might want to add an optional .events( param MinTime=100 ) and return immediately on calls made in less than MinTime - at least for MASTER? Though the caller could regulate that as well?

Mike - I got used to starting my Slave first so it was ready and the DEBUGHACK code would not OT the Master - either should work

When the SLAVE doesn't get TViewer I saw that as a lack on data from the IMU. You might get away with higher speed now. I should enable the events again to see how many were pushing with .events() in loop() now that it is counted.

Mine ran fine overnight for 129993 fifth of seconds GPS updates and all is well:: #129993 @15:19.59_400185904 [fix:3 #:15 ... except the whole SerMon window shows "NAN" again! I reset the slave and it is not that. If it was no IMU the Slave would be quiet - the number went WONKY - we should put in some ASSERTS for that to find out when and where they start???
 
Mike: How many Loop# does T_3.5 setup give?

Before putting uncontrolled .events() back in shows #loop() was -----Loop#:487607 IMU#:502 with uncontrolled .events() it drops to 20K:: -----Loop#:20435 IMU#:501 and SATS quickly drops.
Which is impressive that it can do that with return ACK 20K times/sec!

SATS improves and it goes to this : -----Loop#:366209 IMU#:501 with : virtual uint16_t events( uint32_t MinTime = 100 );

and:
Code:
uint16_t SPI_MSTransfer::events( uint32_t MinTime ) {
  if ( _master_access ) {
[B]    static uint32_t LastTime = 0;
    if ( millis()-LastTime > MinTime ) return 0;
    LastTime = millis();
[/B]  // ...

So that eats some free loop() passes we can skip if the Slave doesn't need to send messages to Master. It would be a bit more efficient to do the same check before calling - but not as pretty in 'user' code?
 
Mike,
Got your version uploaded to my pair of T3.6s, thx. I'm seeing data in the Master serial terminal side, but not in the Slave serial terminal side. My pin connections are

MasterT3.6 - SlaveT3.6
11 - 12
12 - 11
15 - 2
14 - 14

Any hints on what I'm doing wrong? Thx!
Don
 
Don: Switch in the posted #92 uNavINS_MPU9250_I2C_MAGV1.ino - it might offer some clue with the added info and counts and some cleanup.

No TViewer output got me as noted when GPS SATS<6. And over calling .events in early code caused my GPS to UN-FIX with 20K Hz calls of 30 MHz digital Noise.

Have you got the critical GND==GND between M&S?
 
Last edited:
Back
Top