uNav INS

Will switch to posted #92 and look...

I have the Gnd-Gnd hooked up. Not thinking it's the numSV<6 issue 'cuz I see output on the master serial terminal...
 
Still getting good data to Master serial terminal (com14 for me), nothing to slave terminal (com4 for me). Got to go run some errands, but when I get back I think I'll fall back and make sure I can get the SPI_Transfer sample example running...
 
Don Kelly said:
Still getting good data to Master serial terminal (com14 for me), nothing to slave terminal (com4 for me). Got to go run some errands, but when I get back I think I'll fall back and make sure I can get the SPI_Transfer sample example running...
Click to expand...

Sounds like this "#define TViewerSPI 1 " is commented out in A_configDefines.h for (DK). When that is defined then Master Serial is free of TViewer output - only debug SPEW.


I'm testing a " if ( std::isnan( MST_PrintVals[jj] ) ) { " in serialPrint before passing to Slave. Will have to wait some hours perhaps to see if that catches on Master or still shows on Slave ...
 
Tim

"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." - that I think was causing the problem - had i2c set at 1Mhz. Put it back and it worked.

"How many Loop# does T_3.5 setup give?" - don't know. went back to rerun to let you know. Now having problems with IMU and getting enough satellites. Arrg I will update when I get something.
 
Yes, it is required and it is present:
TVslaveDK.ino:
Code: 
void loop() {
	slave.events();
}

Mike - would be nice if you can get the 3.4 MHz i2c working to minimize wasted time on T_3.5.

BTW: i2c_t3 has a CALLBACK option - though I've not tested or seen it work - that would be cool, though MPU messages are short it does take time ...
 
Re. That's what I thought on the slave.events, I confuse easy :)

Part of the problem was the aHRS.events. I put it back but wrapped it in a 100ms timer, and it was causing havoc. Removed it and it started working. Syptoms - too much data.

Tim, as to your question, here is what I get right after startup:
Code: 
Loop#:26698 IMU#:0
	 #1  @18:15.4_306320 [fix:3 #:7
 WARNING: Apparent loss of IMU data !!
	 #2  @18:15.4_200306451 [fix:3 #:7
	 #3  @18:15.4_400306582 [fix:3 #:7
	 #4  @18:15.4_600306713 [fix:3 #:7
	 #5  @18:15.4_800306844 [fix:3 #:7
-----Loop#:287732 IMU#:51
	 #6  @18:15.5_306974 [fix:3 #:7
	 #7  @18:15.5_200307105 [fix:3 #:7
	 #8  @18:15.5_400307236 [fix:3 #:7
	 #9  @18:15.5_600307367 [fix:3 #:7
	 #10  @18:15.5_800307498 [fix:3 #:7
-----Loop#:300557 IMU#:51
	 #11  @18:15.6_307628 [fix:3 #:7
	 #12  @18:15.6_200307759 [fix:3 #:7
	 #13  @18:15.6_400307890 [fix:3 #:7
	 #14  @18:15.6_600308021 [fix:3 #:7
	 #15  @18:15.6_800308151 [fix:3 #:7
-----Loop#:288906 IMU#:49
	 #16  @18:15.7_308282 [fix:3 #:7
	 #17  @18:15.7_200308413 [fix:3 #:7

"would be nice if you can get the 3.4 MHz i2c working" - have new MPU-9250's coming in today, I hope. Will use a new one, just in case.
 
if you put the slave.events in a 100 timer and your hammering f&f’s at ~49uS i can see why youd have a problem :)
 
mjs513 said:
Re. That's what I thought on the slave.events, I confuse easy :)

Part of the problem was the aHRS.events. I put it back but wrapped it in a 100ms timer, and it was causing havoc. Removed it and it started working. Syptoms - too much data.

Tim, as to your question, here is what I get right after startup:
Code: 
Loop#:26698 IMU#:0
	 #1  @18:15.4_306320 [fix:3 #:7
 WARNING: Apparent loss of IMU data !!
	 #2  @18:15.4_200306451 [fix:3 #:7

"would be nice if you can get the 3.4 MHz i2c working" - have new MPU-9250's coming in today, I hope. Will use a new one, just in case.
Click to expand...

Yes, the .events is not used so not needed - I left it out. Even calling 10 Hz adds overhead to time test and then complete a transaction - as noted dropped free loop() calls 100,000 on my T_3.6 - perhaps more significant on T_3.5 - though that slowed rate should not KILL GPS with 'radio' noise.

Your startup SPEW looks as expected. The IMU loss is from that 'absolute' test - when the IMU was not called for some time prior to the GPS data allowing entry. It could he hidden perhaps with:
an appropriate line like : newIMUDataTimer = (float) micros() / 1000000.0f - rtcOffset;

At the end of setup() and also the 'else' case for 'if (uBloxData.numSV > 5) {'
 
tonton81 said:
if you put the slave.events in a 100 timer and your hammering f&f’s at ~49uS i can see why youd have a problem :)
Click to expand...

Before I discovered it - noted above - the .events() was SUCCESFULLY being called 10,000 to 20,000 times per second! The only problem was that that apparently creates radio noise on the independent GPS unit Antenna/Processor causing it to not see the satellites.

That is why the .events() should have a call limiter built in to make it user friendly on Master with code like posted hours back - same post .
 
" 'else' case for 'if (uBloxData.numSV > 5) {" - waiting for Don to get back on KF not updating for no GPS available - it should as was mentioned in a bunch of posts ago. Yep - not so much worried about the imu data. More concerned on GPS data not available. Think I am going to go back and change to test fix >=3. As long as you have a fix proceed).

BTW. running i2c at 1Mhz, all proceeding normally so far. Already tested at 3.4M using just a simple sketch to access the IMU and was getting a check wiring errors - 3 one time 5 another time. 400k is giving me a problem for some reason.
 
Tony: Verbose compile of SPI_MSTransfer shows a lot of NOISE warnings - 'no value returned' - cleaning those up would make it more friendly.

While in there you might add that limiter code? :: uint16_t SPI_MSTransfer::events( uint32_t MinTime )

Also a reasonable 'non-debug' setting for :: Circular_Buffer<uint16_t, 12, 200> mtsca; and Circular_Buffer<uint16_t, 12, 200> stmca;
>> Is there a way the user could pass in CA's mtsca and stmca?
 
yup, prolly do events as an overloaded method with a default time so events() or events(val) could be called

for a user to pass in yeah but if the pattern of the protocol is not in the array dataset, it wont be known to the library and a crash would probably occur

non-debug output?
 
mjs513 said:
" 'else' case for 'if (uBloxData.numSV > 5) {" - waiting for Don to get back on KF not updating for no GPS available - it should as was mentioned in a bunch of posts ago. Yep - not so much worried about the imu data. More concerned on GPS data not available. Think I am going to go back and change to test fix >=3. As long as you have a fix proceed).

BTW. running i2c at 1Mhz, all proceeding normally so far. Already tested at 3.4M using just a simple sketch to access the IMU and was getting a check wiring errors - 3 one time 5 another time. 400k is giving me a problem for some reason.
Click to expand...

re: BTW - 'check wiring errors' - that sounds like what 'wire.h' gave me at some slower i2c speed on 240 MHz T_3.6 before I did the F_BUS to 120 MHz - but i2c_t3 doesn't need that IIRC. Does your MPU9250 use WIRE or i2c_t3?

If that were added to that 'else' case - it would be there whenever it was the reason IMU was not updated? And if the GPS_FIX stops gating the IMU print - then it won't matter except to fool that timer?

I notice the SerialRx isr() code is missing? And this doesn't record the time of IMU data ready on the interrupt?
Code: 
void runFilter() {
  newIMUData = 1;
}
 
tonton81 said:
yup, prolly do events as an overloaded method with a default time so events() or events(val) could be called

for a user to pass in yeah but if the pattern of the protocol is not in the array dataset, it wont be known to the library and a crash would probably occur

non-debug output?
Click to expand...

"reasonable 'non-debug' setting for :: Circular_Buffer<uint16_t, 12, 200>" - the github version has a set of 32 arrays of 150 words. You posted that 32 was for debug testing and a smaller number would be okay so changing that to a reasonable value - perhaps larger entry space of 200 as shown. As shown I am using 12 sets of 200 and it is working and would accommodate a large message.
 
done, i will add the events and CB mods now, for Mintime, if the user doesnt specify, what default would you prefer?

events(100) == 100ms rates

events() == what you want as default?
 
also for:

Code: 
    static uint32_t LastTime = 0;
    if ( millis()-LastTime [COLOR="#FF0000"]> [/COLOR]MinTime ) return 0;
    LastTime = millis(); // [COLOR="#FF0000"]<-- this never runs?[/COLOR]

shouldnt it be:

Code: 
    static uint32_t LastTime = 0;
    if ( millis()-LastTime [COLOR="#FF0000"]<[/COLOR] MinTime ) return 0;
    LastTime = millis();
 
"Does your MPU9250 use WIRE or i2c_t3?" - i2c_t3. The errors I mention, weren't really Wire errors. If you remember on 9250 startup Brian inits the 9250 an if anything fails it returns an error message. "Check wiring" - comes from the 9250 init routine not wire.

"Circular_Buffer<uint16_t, 12, 200>" - I agree 200 is better, I already changed that. Put the 32 back from 5 but that was the cause of my problem. Otherwise it probably would have been fine.

Tony, in regards to events in master is there a way to do something like available instead of events. Why, you might ask - if I wanted to hang a radio off the slave and send control messages I could with having to worry about running events at all? Is it more trouble than its worth?

Tim. Awhile ago we were talking about data. I keep meaning to ask if we are sending floats with "dtostrf", why are we even dealing with doubles? Remember, TViewer wants floats so they are using the c++ function to convert floats to strings. EDIT2: Guess the question is do we really need doubles to be sent back to the slave? Think you asked this before.

EDIT: " SerialRx isr() code is missing? " - noticed that. Also you GPS interrupt is missing as well. To be honest wasn't worried about that right now since we were still debugging the new KF and MSTranser with all that data to worry about it. At some point some of the stuff we had in the other version of the KF should be moved over.
 
You must log in or register to reply here.
Back
Top