Forum Rule: Always post complete source code & details to reproduce any issue!
Page 19 of 19 FirstFirst ... 9 17 18 19
Results 451 to 465 of 465

Thread: uNav AHRS

  1. #451
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    Ok Here is version that kinda of works same issue as before. I saw your post and looks like Chris O. has a solution. Did find a new serial command not sure it applies Serial.send_now(). Think you put it after the cout command? Never saw that one before tonight.
    Attached Files Attached Files

  2. #452
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    Indeed .send_now forces the output - and waits until it is all buffered for send. Not sure if that would help.

    DOH! - Need to go thank Chris! I needed to read my own code! I had Serial1 on the brain - the DEBUG port on mine ... where GPS is on Serial2!

    Got the V10b - will see if I can't make it go before lights out.

  3. #453
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    With Chris' tip the Error average is 8 uS off from the RX_isr() detection now and worst case error is off by all but a full character of 21 uS where the last bits not complete. I could add the 8 uS into the calculation and call that good - remove the Rx_isr() code and take some load off the system? Simpler code and should always work [-9 to +11] uS to detect GPS start message if that is acceptable accuracy?

  4. #454
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    Updated code and notes see: Serial1-available-counting-bytes-in-the-FIFO

    It looks like we can stick with the Rx isr()! It is running 100% good after 12,500 messages at 96 MHz on T_3.6! So we have a low overhead ( 5 Hz interrupt instead of hundreds or thousands of hits in <15 ms ) - that marks the GPS string start and time stamps it with less code than before.

    Mike - after that I will not get to the newest code you dropped tonight - but you can swap this 'smaller' isr() code and it should work for you on T_3.5 at 120 MHz!
    Code:
    #define RxGapTime ((F_CPU / GPS_BAUD) * 30)
    //==================================
    // FASTRUN void GPS_serialrx_isr()
    // GLOBALS :: volatile uint32_t GPS_RX_Time = 0;
    FASTRUN void GPS_serialrx_isr() {
        GPS_RX_time = tsGPS; // Start bit transition detected after 'idle' time
        detachInterrupt(digitalPinToInterrupt(GPS_SRX));
        GPS_newData=1;
        GPSrxs++;
    }
    And then when a GPS read completes positive the interrupt must be attached again!:
    Code:
    if(gps.read(&uBloxData)) {
      // ...
    
          attachInterrupt(digitalPinToInterrupt(GPS_SRX), GPS_serialrx_isr, RISING);
    
      // ...
    }
    Last edited by defragster; Yesterday at 10:40 AM.

  5. #455
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    Tim. Hope you got a good night sleep. I updated revb to revc that incorporates your changes. Like you said works like a charm Now have a better way to determine when GPS is available. Will have to get that change incorporated as well.

    There is also an improvement to the number of miss gps prints, better not perfect. Just as a side note I made the same changes in the threaded version, just for my own eddification. All these issues we are having is all related to how fast we can print - not sure when we get to final version we really need to dump all the data we are which will be even better.

    EDIT: Think you mentioned that you are able to see the params in ucenter and make changes to them with your passthrough. I can't seem to do that with my pass through code. If you get a chance can you take a look. I tried a similar approach and that didn't work either usin inchar. Probably did it wrong.
    Attached Files Attached Files
    Last edited by mjs513; Yesterday at 12:29 PM.

  6. #456
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    Mike: Not quite a good sleep yet. Using the Threaded at 96 MHz it ran no trouble?: "120355.00==120355 | 0.246000, 61720.800700 ..."

    Filters_V10c is compiled and running now T_3.6 @ 120 MHz.

    Not sure what it showing on output - the GPS Rx isr() seems to be always hitting - but GPS data completion seems to lag or skip one? This is the opposite of what I saw before with GPSrxs now Higher? But that will happen when imu update arrives and the serialDataOut() is called after the GPS msg starts triggering the Rx isr() - but before GPS completes.

    > Made minor changes for debug serial in A_Config.
    > Not seeing any aberrations in print now not Threaded
    > IMU update rate looks odd with 6 or 7 or 20 IMU updates between GPS? At 240 MHz I don't see the runs of 20 -
    > Not sure what this test is looking for: if(timeStamp*0.001 > 235.0 && timeStamp*0.001< 275)

    Here is minor update for now: MPU9250_FiltersGPS_V10c (2).zip

  7. #457
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    Hi Tim. As for sleep - me either, am shot. Anyway back to point.

    > "Using the Threaded at 96 MHz it ran no trouble?: "120355.00==120355 | 0.246000, 61720.800700 ..." - made a few other changes to match what I did in non-threaded. Didn't post that version. Mainly limiting the prints. The no trouble was associated with the ISR. Still had about 5 missed prints for GPS update in about 4500.

    > "Not sure what this test is looking for: if(timeStamp*0.001 > 235.0 && timeStamp*0.001< 275)" -I modified the debug print, to include a test for when serialPrint is not keeping up with the GPS. What is used was the whether the timestamp exceed the normal max timestamp, so hence, the if(timeStamp*0.001 > 235.0 && timeStamp*0.001< 275 test, max timestamp I've seen for each print (just print) was about 200ms between gps updates. the max value was just so the counter wouldn't keep counting on a miss. So in effect what you see in the last column of the debug is the number of times the printout wasn't keeping up with the GPS update. I put it there mainly because I got tired of watching the screen.

    The other thing is that if you look at what I did to your debug print statement - I took the print for the pairs missed out of the "if" statement (was just easier for me to see when it missed).

    > "Not seeing any aberrations in print now not Threaded" - I cheated I put am only printing IMU data every 25ms (put the imu print's in "if(sincePrint > 25)" block. Why 25, because I watching the data print out so much.

    > "IMU update rate looks odd with 6 or 7 or 20 IMU updates between GPS? At 240 MHz I don't see the runs of 20 ", probably the same reason, I put a limit on the printed data.

    The other thing I did, not sure if it made a difference was put a cout.send_now() after each print. I will give your updates when I get home - have to go out and do some errands

  8. #458
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    I saw the one // sincePrint commented - missed the active one

    Modified to better watch GPS on debug - messages are spotty?

    MPU9250_FiltersGPS_V10c (3).zip
    Attached Files Attached Files

  9. #459
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    Just compiled and ran your updated version. Interesting changes you made to serial debug. Shows exactly whats going on. Noticed with the sincePrint there are more missPairs that show up that would be equivalent to missed prints which I didn't catch before.

    It appears that when GPSrxs lags behind (seems to be always by 1) the ISR is when we get missed prints:
    Code:
    1807.00==1808	 |tS=208.68	 - 1.00 - 0 - 
    1807.00==1808	 |tS=248.66	 - 1.00 - 0 - 
    1807.00==1808	 |tS=288.65	 - 1.00 - 0 - 
    1807.00==1808	 |tS=328.63	 - 1.00 - 0 - 
    1807.00==1808	 |tS=368.62	 - 1.00 - 0 - 
    1807.00==1808	 |tS=408.60	 - 1.00 - 0 - 
    1807.00==1808	 |tS=448.59	 - 1.00 - 0 - 
    1807.00==1808	 |tS=488.57	 - 1.00 - 0 - 
    1807.00==1808	 |tS=528.56	 - 1.00 - 0 - 
    1807.00==1808	 |tS=568.54	 - 1.00 - 0 -
    This would probably equate to about two actual misses (say 0.2 and 0.4 gps updates). Not sure what else was changed, don't think anything else, but seems like we are getting a lot more misses than I saw before. Want to check something next.

    UPDATE: Just looking at the debug you know pairMiss never gets updated it always 1.0. Also, you if(pairMiss), isn't that a Boolean test? Never saw that before so incMissed never gets printed. Not sure what you really wanted to do with the changes so just letting you know for now.
    Last edited by mjs513; Yesterday at 08:38 PM. Reason: A little more looking.

  10. #460
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    This shows UTC time when updated.
    MPU9250_FiltersGPS_V10c (4).zip

    It is possible the Filter match and prints are causing loss of GPS data - corrupted string will be tossed until next good one comes in. Since the isr() interrupt is off - it won't restart until a good GPS string completes.

    <EDIT>: GPS strings not LOST/corrupted will just be found out of time and show in the next second.

    This is why I was saying stopping filter updates (prints?) when GPS_newData=1; is set would help.

    As that would also sync the IMU data with that GPS data.

    ALSO - the send_now() assures integrity of THAT string - but can halt the system until it happens - which will slow the flow past the GPS uBlox reading.

    The check for 1000 should be >=:
    Code:
          if ( GPSMon >= 1000 ) {
          GPSHz = 0;

  11. #461
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    "This is why I was saying stopping filter updates (prints?) when GPS_newData=1; is set would help." - Agree that would probably help, i.e., prints.

    "the send_now() assures integrity of THAT string - but can halt the system until it happens - which will slow the flow past the GPS uBlox reading." - thanks for the explanation, didn't get that from what I was reading.

    "if ( GPSMon >= 1000 )" - ok you lost me on this one.

    OK. Missed 2 updates while I was updating my last one. This is almost real-time. Forget what I said, I will try your latest before I say anymore .

    Have to take a break for now and go make my granddaughter something to eat. What can I say

  12. #462
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    I'm breaking too. In the void serialDataOut() code search 1000. That '>' should be '>='. I didn't see until after the zip was packed . . .

    Look for function .availableForWrite() that shows buffer space free to push output. When it is less than written - there will be a wait with send_now().

  13. #463
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    5,322
    Since the Rx is its no longer free running, the count doesn't get ahead at the start, took out the - 1 in it value, and it never misses anymore.

    When right is up 1 then GPS was not read or a message was lost

  14. #464
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    You are right about it never missing anymore. Was just interesting that when it did in the last version you posted was when the data was off. I was looking a the latest version in post #460, compiled and ran fine but had a devil of a time seeing in the debug monitor when the prints went off. I did remove the send_now's based on what you said and I put a test on serialDataOut thus:

    Code:
          if(!rtk.upDated)
              serialDataOut();

    Looking at the data monitor saw lots of loss of sync with the GPS. In the debug monitor the only thing I saw was
    Code:
    2372.00==2372	 |tS=0.04 | 	 @81324.6015625000	 ms196==1 || 
    2373.00==2373	 |tS=0.04 | 	 @81324.7968750000	 ms392==2 || 
    2374.00==2374	 |tS=0.04 | 	 @81325.3984375000	 ms991==3 || 
    2375.00==2375	 |tS=0.04 | 	 @81325.6015625000	 ms1190==4 || --------
    As you said the ISR's never missed a beat, but notice the utc times. Lost data before utc 81325.3984375000. Only indication I saw in the monitor was that count at the end only had 4. this number or less indicated a data miss. again a lot of times that I could see.

    EDIT: are we spending too much time trying to get the timing down on prints just so we can print to tViewer? Do we need to print all that data? Isn't the real question whether the GPS data is avail at the right time,i.e., GPS data isn't being lost?

    EDIT1: Think another reason I may be seeing more misses is increased logic and prints to Serial1. Its going to take more time in the print loop.
    Last edited by mjs513; Yesterday at 11:10 PM.

  15. #465
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    667
    Hi Tim. Sorry about my tirade but getting frustrated with getting to work. I did some more work and ran a couple of test cases. The first was without the !rtk.updated on the imu serialPortOut (figured this would be the fastest print) and the second was with it. I did modify your debug statements to reduce the amount of prints to coutD port. I also moved the missed GPS indicator to outside the test if the gps was updated (all misses occur between updates, I wanted to get a running count. Anyway, in the first case an example is of two misses between tracked updates:
    Code:
    3 **** 102.00==102	 |tS=0.04 | 	 @4847.4003906250
    4 **** 103.00==103	 |tS=0.04 | 	 @4848.0004882812
    5 **** 104.00==104	 |tS=0.04 | 	 @4848.6000976562
    5 **** 105.00==105	 |tS=0.04 | 	 @4848.800292968
    I know its between because I ran a test where I printed the misses as they occurred. You can see, when the rtk.upDated = true, the misses in updates already occurred yet the isr count equals the gps.read count. You can see the impact on utc. 2 misses in the first and 1 in the second.

    The second case, I got:
    Code:
    91 **** 3244.00==3244	 |tS=0.05 | 	 @5716.0000000000
    92 **** 3245.00==3245	 |tS=0.05 | 	 @5716.6000976562
    Same result but the thing I noticed was miss count was less. Right now with about 6200 hits getting about a 2.6% miss rate.

    One other test I ran was using the serialDataOut function modified to only print 3 fields, the first 3 timing fields. All worked as advertised. After about 2000 updates there was 0 misses. What to try something - if imu is updated only print IMU data, if GPS updated only print GPS data. All other fields would be zero. Only problem with this is again it would impact viewing in TViewer.

    So it really boils down to what we really need to viewed and when. Can we speed things up and print all integers and adjust with the scale factor in TViewer?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •