uNav INS

I'll probably convert over to the new library right after you all update to v7 for the 20hz loop.

How's lat and long holding up - if I remember right I was seeing large variations in latitude as well altitude. :)

Bout ready to start getting altitude from the pressure sensor that I have.

Mike
 
Here's some interesting behavior. The filter will be doing fine, like in this Master output:

86.992508, -8.2226, -5.6769, 0.1556, 354.5765, 29.610157,-95.109581, -1.2201
87.216446, -8.3127, -5.1982, -0.1595, 354.2614, 29.610157,-95.109581, -1.2389
87.392509, -8.6786, -4.8427, -0.4386, 353.9823, 29.610157,-95.109581, -1.2551
87.592499, -8.5985, -8.2565, 2.1249, 356.5457, 29.610157,-95.109581, -1.2703
87.792496, -9.0626, -5.6826, 0.4392, 354.8600, 29.610157,-95.109581, -1.2861
87.987335, -7.0255, -5.4566, 0.0111, 354.4320, 29.610157,-95.109581, -1.3015
88.193581, -8.1502, -6.7407, 1.1042, 355.5251, 29.610157,-95.109581, -1.3158
88.392487, -8.3801, -5.3827, 0.2496, 354.6705, 29.610157,-95.109581, -1.3294
88.592476, -9.5051, -6.5686, 1.2317, 355.6526, 29.610157,-95.109581, -1.3435


And then it does these noisy jumps

152.202393, -7.9618, -6.1706, -0.5059, 353.9149, 29.610157,-95.109543, 0.6866
152.391220, -8.8614, -5.0395, -1.2492, 353.1717, 29.610157,-95.109543, 0.7024
152.591217, -9.6295, -5.3810, -0.8758, 353.5450, 29.610157,-95.109543, 0.7195
152.791214, -7.8709, -5.5333, -1.0505, 353.3704, 29.610157,-95.109543, 0.7360
152.991211, -7.3053, -32.0068, 18.0232, 12.4441, 29.610157,-95.109543, 0.7535
153.214523, -8.1565, -14.3986, 5.6065, 0.0274, 29.610159,-95.109543, 0.7695
153.384552, -9.2509, -8.3133, 1.1732, 355.5941, 29.610159,-95.109543, 0.7863
153.591400, -9.3088, -6.7883, 0.0943, 354.5152, 29.610159,-95.109543, 0.8059
153.796005, -8.4873, -5.4114, -0.9557, 353.4652, 29.610159,-95.109543, 0.8267
153.995071, -8.8793, -4.8146, -1.3476, 353.0733, 29.610159,-95.109543, 0.8485

And on the Slave side, the residuals seem to show noise spikes in the gyro and accel that look like they might coincide.

I wasn't seeing this when board was inside, so guessing it may be outside temp (it's 80 in the shade today here). I have a small piece of cloth over the board to keep out the direct sun, but it seems to be related to the hotter part of the day outside.

Don
 
for higher speeds UART, when I worked on porting ESP8266 core methods to teensy 3.6, I was able to achieve 3Megabaud easily without CTS/RTS. The loop alone can’t do this, you NEED to use SerialEvent(), this solved all issues with high speed uart communication

it was as simple as putting ESP.events() in both main loop() and SerialEvent function, no other code required

The GPS has limited speed options . . . that is the question here. And we know Teensy can do it - just have to take what the GPS can support reliably. It comes factory set at 9600 baud to give an idea of expected use.

Serial event is only good because every delay hits it - and it has drawbacks too. So having an update FUNC() called often enough is all that is needed.
 
Tim,
I tried both 460800 and 230400 for GPS_BAUD, and mine only seems to work if I set it to 115200. Wonder if I need to change some other uBlox setting?

Here's another weird thing. I'm trying to run some tests outside. Normally I power my uBlox M8N with a USB cable from a USB port on either my laptop or iMac. To move outside, I thought I'd power it with a USB power supply (phone charger type). When I plug the uBlox into the USB power supply, the light comes on, but the filter stops working (i.e., stops sending data to Master terminal). When I plug it back into the computer USB, everything works again. Aaarrrrgggg. Guessing this is some sort of USB interface issue rather than power issue....

You need to move off of Serial3 and expand the RX_Buffer?
#define GPS_Start 3 // 1 // UBLOX gps(gps_Start);
#define GPS_PORT Serial3 // Serial1

That sounds like an issue with a !Serial wait - but there isn't one of those after setup() has a timed thing.

For some reason your GPS is power hungry? Your would not connect and work like mine feed from Teensy power?
 
Tim,
Are you feeding the uBlox 3.3V from Teensy? I tried doing that with the Adafruit GPS and it needed 5V for me to get it to work reliably.

I'll try moving off Serial3 and double-check the RX_Buffer. Thx!

Don
 
Hi Don. I am feeding 5v from the master to the GPS and 3.3v to the 9250 from the master as well - no issue. I agree with Tim - move the GPS off of Serial3 as a start. I did that as well at Tim's recommendation, especially since the Serial1 and 2 have a FIFO.

80degF should be fine for the 9250, think onehorse told me that it good to 80degC.

Thought the Adafruit Ultimate GPS used a MTK chip at its core so the new library won't be of much use to you since its geared to a M8N. I do know that adafruit has a similar utility to ucenter that you can test different baud rates as a check.
Mike
 
Tim,
I only see 3.3v from my T3.6, at least from the topside. I see on the diagram there's a 5V port underneath, but I don't read voltage from it so guessing it perhaps must be jumpered first, if it even can.
Don
 
Shutting down the outdoor test for a bit. It ran well for a while, maybe 30 min, but then started drifting and jumping

2669.437988, -10.9817, -14.5541, -11.5964, 342.1419, 29.610167,-95.109573, -1.2465
2669.638672, -11.7796, -13.2549, -12.3753, 341.3630, 29.610167,-95.109573, -1.2637
2669.851562, -10.7975, -13.8857, -12.2042, 341.5341, 29.610167,-95.109573, -1.2794
2670.034668, -7.7711, -40.1052, 6.2908, 0.0292, 29.610167,-95.109573, -1.2955
2670.244629, -12.0454, -23.5676, -4.9666, 348.7718, 29.610167,-95.109573, -1.3109
2670.439697, -10.9561, -17.8821, -9.0731, 344.6653, 29.610167,-95.109573, -1.3270
2670.629395, -10.9687, -14.7781, -11.2537, 342.4846, 29.610167,-95.109573, -1.3423
2670.855957, -10.2560, -14.0406, -11.9466, 341.7917, 29.610167,-95.109573, -1.3577
2671.038574, -9.6019, -14.7358, -11.6580, 342.0803, 29.610167,-95.109573, -1.3736

Also, I'm seeing big spikes every few seconds or so on the Slave plots. So something's weird still. Will run it a bit tonight when things cool down to see if that matters. Doesn't seem like it should.
 
Don
VIN is already jumpered to VIN unless you cut the trace on the underside of the board. If not, VIN will be at 5v and you can pull it off of that. Just remember that T3.6 is not 5v tolerant.

Mike
 
Tim,
Are you feeding the uBlox 3.3V from Teensy? I tried doing that with the Adafruit GPS and it needed 5V for me to get it to work reliably.

I'll try moving off Serial3 and double-check the RX_Buffer. Thx!

Don

Yes - we saw that difference some time back - something struck me as Odd. Only 5V on T_3.6 is the primary pin pulled off USB opposite side of GND.

That T_3.6 5V pin is not present to make sure the breadboard couldn't feed 5V and kill it. GPS is powered off of 3.3V pin.
 
I'll probably convert over to the new library right after you all update to v7 for the 20hz loop.

How's lat and long holding up - if I remember right I was seeing large variations in latitude as well altitude. :)

Bout ready to start getting altitude from the pressure sensor that I have.

Mike

I've noted before my GPS Alt varies quite a bit - not sure if I also added that ODDLY when I was looking at a onehorse pressure sensor - it also drifted. It took longer but change was significant over time and it would cycle day to day and never settled down.

Given that my house is above a bay ... I made a reference at the time about Hitchhiker's Guide to the Galaxy - where after using the 'infinite improbability drive' they showed up on an odd beach where the water stood still and the shore was washing up and down.

I'm about 50m over the bay - and IIRC the GPS was showing +/- 10m - even with 3D lock and good # Sats.
 
Onehorse's 9250 has a MS5937 pressure sensor, don't have much experience with this one. I usually use a MS5611 and always found the altitude be a lot more stable and accurate than the GPS altitude as long as you set the current sea level pressure sensor - since I am near LGA I use METARS/ADDS to get it. Trying to hook it in now to the sketch but its killing the transfer rate and it shouldn't - have to do some trouble shooting.

EDIT: Figured it out - have to modify the library slightly so the I2C clock rates match. But now that I changed that its running fine. I also added in a option to change sea level pressure from the default value of 1013.25mb, just checked Metars and its currently at 1018.00 - yes it does make a big difference - goes from -90 feet to +31feet.
 
Last edited:
Mike,
Where'd you get your MS5611? Looks like banggood has them, but it seems to take a fairly long time to get parts in from them. Bt at least they're cheap there...

I got my mRobotics M8N Dual running off the T36 5v, but think it's struggling. The voltage at the M8N input drops to below 4V sometimes, so I think this M8N board (with dual compasses) really pulls some current. I had similar issues with the Adafruit drawing a fair amount of current, especially if the T36 was also driving an IMU.

I'm wanting to spend some more time trying to figure out why I'm seeing this odd behavior when I run the setup outdoors. So I think I'll focus on that for the next few days vs. getting the "fixed dt" version released. But I do think a fixed dt version is a good idea, but I'm concerned that this version was not looking too stable when I moved outdoors. Will do some more testing in the morning.

Darn, I'm getting this again:

WARNING: IMU data Interrupt lost!!
WARNING: IMU data Interrupt lost!!
WARNING: IMU data Interrupt lost!!

Seems like every so often the IMU just hiccups... might need to re-look at the board wiring.

Don
 
Cool - the message works! :: "WARNING: IMU data Interrupt lost!!" ... Bummer.

You can try to set this to 2 :: if ( RTCvsIMU > 1 ) {

But if you are seeing repeats it is probably really missing and not just a fluke.

You can add qBlink here - and the Master LED will 'glow' when active or stick OFF or ON when really losing the interrupt:
Code:
void runFilter() {
  ccTimeNow_IMU = ARM_DWT_CYCCNT; // use with ccPartSec(); to get time offset
  newIMUData = 1;
  [B]qBlink();[/B]
}

LED is blinking at GPS speed now because I left a qBlink(); in debugGPS() that you can comment out.

BTW: If you look at the macro for qBlink() - you'll see it is a simple PORT instruction - that toggles LED_BUILTIN you can put about anywhere to show signs of life.

Don - you can try that in setup or after in the case where your unit is not showing signs of life?
 
Mine left running since ... GSecs:121329... 33.7025 hours ... then a single 'p' for delay(500) and it died::
-----Loop#:486176 IMU#:500 >> 1Sec:99936096 >> IMUcc:142920
#606578 @2:26.28_-61996 [fix:3 #:16 GPScc:218299 > cctAv:179999676 > GSecs:121329.140625 > IMUdt:0.19778442 > GPSdt:0.19886206
121329.335938, 52.4053, 154.8113, -136.7989, 54.8682, 48.214451,-122.450493, 44.5307
#606579 @2:26.28_199938080 [fix:3 #:16 GPScc:218307 > cctAv:179999676 > GSecs:121329.335938 > IMUdt:0.19978227 > GPSdt:0.19982873
121329.539062, 52.3650, 154.8476, -136.4150, 55.2520, 48.214451,-122.450493, 44.4993
#606580 @2:26.28_399938156 [fix:3 #:16 GPScc:218365 > cctAv:179999676 > GSecs:121329.539062 > IMUdt:0.20178007 > GPSdt:0.20027389
121329.742188, 52.5281, 154.6522, -137.1580, 54.5090, 48.214451,-122.450493, 44.4695
#606581 @2:26.28_599938233 [fix:3 #:16 GPScc:218380 > cctAv:179999676 > GSecs:121329.742188 > IMUdt:0.19978218 > GPSdt:0.20081764
121329.937500, 52.4909, 155.0718, -136.8890, 54.7781, 48.214451,-122.450493, 44.4407
#606582 @2:26.28_799938309 [fix:3 #:16 GPScc:218353 > cctAv:179999680 > GSecs:121329.937500 > IMUdt:0.19978240 > GPSdt:0.20027444
121330.140625, 52.4989, 154.8288, -137.1540, 54.5131, 48.214451,-122.450493, 44.4088
-----Loop#:486952 IMU#:501 >> 1Sec:100095416 >> IMUcc:147412
#606583 @2:26.29_-61613 [fix:3 #:16 GPScc:218361 > cctAv:179999680 > GSecs:121330.140625 > IMUdt:0.19978233 > GPSdt:0.19975880
121330.335938, 52.5977, 154.9863, -137.0603, 54.6068, 48.214451,-122.450493, 44.3756
_
#606584 @2:26.29_199938462 [fix:3 #:16 GPScc:37230660 > cctAv:179999680 > GSecs:121330.335938 > IMUdt:0.56738180 > GPSdt:0.19736306
ASSERT: NaN Fail index = 62
___ ASSERT FAILED ___ FILE, LINE#, Expression
T:\tCode\_GPSimuDK\9Apr18\uNavINS_CB_Ver6\C_slaveSerialPrint.ino

going to restart with the dt set to : 1/ ( 1+ IMU_SRD) - to see if it still NaN's on 'p' pause.

Indeed with #include "A_configDefines.h" in uNavINS_CB_Ver6\uNavINS.cpp and this line changed::
>> dt = (float)(1/ ( 1+ IMU_SRD)); // _t /1000000.0;

The running code is IMPERVIOUS to 'p' - pause command!
 
To get back to a true dt I changed to this - and it runs fine - maybe better if we want a true variable dt:

Code:
// get the change in time
    //dt = (float)(1/ ( 1+ IMU_SRD)); // _t /1000000.0;
    dt = FccPartSec( cctLast_IMU, ccTimeNow_IMU );
    cctLast_IMU = ccTimeNow_IMU;

Needs this in the init section: cctLast_IMU = ccTimeNow_IMU;

And these for compiling at the top:
Code:
static uint32_t cctLast_IMU = 0;
extern volatile uint32_t ccTimeNow_IMU;
float FccPartSec( uint32_t CntPri1, uint32_t CntPri2 );

Sure enough a 'p' Pause - NaN kills this too - apparently the calc blows up when the dt gets too large?

The risk of that and the programmed regularity of the incoming IMU data at [ (1/ ( 1+ IMU_SRD)) millis ] says that going with a fixed dt based math array - would that be done once in setup()? - would keep it from unnecessary processing overhead and the risk of a missed IMU update catastrophe.
 
Hi Tim. Instead of using the dt with the pause delay included did you try setting it up so at start of pause it saves the lastDt = dt and end of pause reset dt to lastDt seen?
 
Mike,
Thx for the MS5611 link, I got one ordered...

The Drotek GPS looks nice. Wish it had PPS out though. Looks nice quality.

Don
 
Don,

The drotek is nice. I picked it up after doing some research and reading a few articles on DIYdrones. Haven't really found too many GPS's with PPS broken out. Really only found the one on ebay which is 8030 ublox. Slight differences but works the same way as a M8N.

Mike
 
Tim,
You suggested:
"You need to move off of Serial3 and expand the RX_Buffer"

I moved to Serial2 and made sure the buffer in SPI_MSTransfer.h was set to DATA_BUFFER_MAX 400. Is that the buffer you were referring to? I'm still only able to set GPS_BAUD to 115200.
Don
 
Hi Don

Don't know if Tim is online yet but he is referring to changing the Serial2 rx/tx buffer size. To do that you have to modify the serial2.c file. Should be in the Arduino teensy hardware folder:
Code:
C:\.......\hardware\teensy\avr\cores\teensy3

The lines you need to modify are:
Code:
#ifndef SERIAL2_TX_BUFFER_SIZE
#define SERIAL2_TX_BUFFER_SIZE     40 // number of outgoing bytes to buffer
#endif
#ifndef SERIAL2_RX_BUFFER_SIZE
#define SERIAL2_RX_BUFFER_SIZE     64 // number of incoming bytes to buffer
#endif

My serial1.c file I have the rx and tx buffer size set to 64. You can try those numbers to start. Forgot which post Tim recommend the change or thread :) I will see if I can find it.

Mike

UPDATE: Found it. The post is in the other thread but change it to 128
"Should be line #43 :: #define SERIAL3_RX_BUFFER_SIZE 128 // 64 // number of incoming bytes to buffer"

Mine is still at 64 and have not had any trouble. Think if you stayed on Serial3 you would definitely need the change. Tim, what do you think?
 
Back
Top