GPS FIX arrived closer to window and all is well, after Slave restart? First printed Slave #'s were : "1_good_Number, NAN's,..." . Reset Slave and got valid values with change on Motion - so my onehorse MPU9250 running fine again at 3.4 MHz i2c.
Something is way more finicky ( is it raining lightly ) - losing my RED FIX LED where it used to work? ... moved from Window and I get: " WARNING: Apparent loss of IMU data !!" - Slave output stopped - no notice of FIX LOST - that caused slowed IMU attention.
Slave pinToggle - running fine. Bad trouble holding FIX - even in Window.
Mike: You have Math [ 9 copies of "*R2D"] on Master before shipping to Slave - doing that on Slave with dtostrf()/formatting will maximize Master gain with SPI_MST.
I see that the TViewer output is now 413 characters long! That would cost even more USB time/distraction on the Master! Teensy USB should still be good to TViewer even at 1,000 Hz ( Hah! ) it is well under 50% capacity.
The millis()%100 for the SPI HeartBeat is fun - but costing up to 10 ms/sec with delay(1). Also that rate seems panicky - and some more SPI time too. This will FLICKER FAST (dim) on powerup - but then pinToggle each 200 ms. When GPS is lost it will blink 100 ms faster so slave will show PANIC then - at least in theory - I can't see FIX to test it going slow 
I added an adjustment for loss of IMU too - PinToggle will go even faster
NOTE: When I unplug my SLAVE to put MASTER in window it gets FIX until I replug Slave? Either power loss as cabled/wired or the Slave is interfering with GPS? I just put SLAVE on USB battery pack - I have Fast pinToggle and no GPS FIX yet? Unplugged Slave and got FIX - either gets lost or under 6 SATS and fast blinks - with some slow 200 ms blinks as expected. Will rewire SLAVE and reposition and report back. I never saw this before ...
NOTE2>> Dropped SPI to 24 MHz from 30 MHz and FIX comes/stays better ... trying 12 MHz ... maybe better but not good. My 'IMU_SRD 19' is low IMU updates. Reprogrammed slave T_3.5 to 120 MHz with 24 MHz SPI - still more off than on ???
Mike: Any chance this 'loss of fix' is what you saw as failure to get IMU data?
Code:
elapsedMillis HeartBeat;
void loop() {
if ( HeartBeat > 200) {
aHRS.pinToggle(LED_BUILTIN);
HeartBeat -= 200;
}
//Define RTC time for this iteration
rtcTime = (float) micros() / 1000000.0 - rtcOffset;
gps.read(&uBloxData);
//Serial.println("Read GPS");
//Serial.println(uBloxData.numSV);
// If GPS receiver is locked to at least five sats and if there is new
// IMU data, then run the EKF. This seems to run at about 50Hz (20ms samples).
if (uBloxData.numSV > 5) {
//Serial.println("numSV>5");
// Print out warning if apparent loss of IMU data
if ((rtcTime - newIMUDataTimer) > 0.150) {
Serial.println(" WARNING: Apparent loss of IMU data !!");
if ( HeartBeat < 150) {
HeartBeat += 150;
}
}
if (newIMUData == 1) {
//Serial.println("newData=1");
newIMUData = 0;
newIMUDataTimer = (float) micros() / 1000000.0f - rtcOffset;
// read the IMU sensor
Imu.readSensor();
//Serial.println("IMU sensor read");
Filter.update(uBloxData.iTOW, uBloxData.velN, uBloxData.velE, uBloxData.velD,
uBloxData.lat * D2R, uBloxData.lon * D2R, uBloxData.hMSL,
Imu.getGyroX_rads(), Imu.getGyroY_rads(), Imu.getGyroZ_rads(),
Imu.getAccelX_mss(), Imu.getAccelY_mss(), Imu.getAccelZ_mss(),
Imu.getMagX_uT(), Imu.getMagY_uT(), Imu.getMagZ_uT());
// Print values to serial
serialPrint();
}
}
else if ( HeartBeat < 100) {
HeartBeat += 100;
}
aHRS.events();
}
Reply With Quote
Originally Posted by Don Kelly
