Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 44 of 44

Thread: Teensy 3.5 sd logging HELP!

  1. #26
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    That whole structure is 224 bytes. It would take ~90KB to save 20 of those each second for 20 seconds - which would work for a first pass if desired.

    To reduce that make a second (copy of that) Struct with only the 20 desired values. Then make an array of 400 ( or more ) of those structs and then index through them 20/sec for 20 seconds and transfer the then current values to the array for storage.

    Then figure out how to start the sampling and to stop it. When stopped loop through those elements with sample data and do Serial.printf() of the values in the desired CSV format for review.

    Once that is working store then on the SD card as well in groups of 512 bytes.

    With that working you can perhaps evolve the logging to work out the SD writing during the sampling in some fashion.

  2. #27
    Yea I can't even get this working the way I want. I really need some guidance here. And I think we have our sizes wrong too. I need to get 20 real time values 10 to 15 times per sec for at least 20 sec. I actually succeeded in getting 4 values stored in an array of 800 bytes. It's not pretty! but it worked
    Code:
    void sdStatuses()
    {
    
     if ( i < 800){ 
      BIT_SET(currentStatus.Status2, BIT_STATUS2_DATA_SAVE);
      DataBuff[0] = currentStatus.secl;
      DataBuff[1] = currentStatus.MAP;
      DataBuff[2] = currentStatus.battery10;
      DataBuff[3] = currentStatus.RPM;
    
    
      for(byte x=0; x<4; x++)
      {
        Storage[i] = DataBuff[x];   
        i++;
        if (x == 4){
          x = 0;   
        }
      }
     }else{
      BIT_CLEAR(currentStatus.Status2, BIT_STATUS2_DATA_SAVE);
      
    
     }
    It ran this every 100 milliseconds.

  3. #28
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    Looks like the beginning of something that should be a start.

    Would need to see the whole set of code to know how sdStatuses() was called. If called from loop without restraint that would explain 100 ms.

    Code:
    elapsedMillis  LogTimer;
    #define MillisToWait 50
    setup() {
      // setup code
      LogTimer = 0;
    }
    
    loop() {
      // some code perhaps
      if ( MillisToWait <= LogTimer ) {
        LogTimer -= MillisToWait;
        sdStatuses();
      }
      // perhaps more code
    }

  4. #29
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    That would get 10 seconds worth at 20 times per second with #define MillisToWait 50 - for 10 times per second use :: #define MillisToWait 100

    The "if (x == 4)" will never trigger in that for loop - if it did it would never leave the loop?

  5. #30
    Wish I could post the whole code here but there is about 20 pages of code. I'm just adding stuff to it. There are several timers set up and I have the sdlogger being called in the 100ms timer. Then I have a pin that I pull to ground to start logging. Would be more than happy to send you the code to look over.

  6. #31
    Quote Originally Posted by defragster View Post
    That would get 10 seconds worth at 20 times per second with #define MillisToWait 50 - for 10 times per second use :: #define MillisToWait 100

    The "if (x == 4)" will never trigger in that for loop - if it did it would never leave the loop?
    It leaves the whole function when i > 800. Which fills the Storage[800] buffer. It does reset itself to keep filling the storage buffer array correct?

  7. #32
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    I see it exiting sdStatuses() after logging those 4 values, unless i >= 800 - then it leaves without logging - but clears a bit.

    But that if case luckily will always be ignored, and should be removed - unless it was to do something else.

    Not anxious to look at 20 pages of code - perhaps model just this part simply - then incorporate it back in. Something is wrong with the timer logic ...

  8. #33
    Oh ok. So does a for loop reset it's self? In other words you don't have to set x back to 0? I had a Serial.println in the for loop to see the values that where going into Storage[i] and it gave me all for values 10 times per sec. What's wrong with the timer logic?

  9. #34
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    for ( A; B; C ) For loop has to do all setup on entry "A", exits on "B" and uses "C" to get between the two until it drops out from "B" - and never enters when "B" fails to be true.

  10. #35
    I've been thinking too. Is there any way to write these logs to the actual flash memory to be written to the card later? Just so there is no chance of loosing the log before the bike is cut off.

  11. #36
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,710
    you could have it constant powered (teensy) and have the ACC line monitored to a gpio via appropriate optocoupler setup

    thAt way when your bike is off, teensy can write remaining data to uSD card then have teensy goto low power sleep state (snooze library?)

  12. #37
    Or would it be better to add an external eeprom?

  13. #38
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,710
    you could add external flash, eeprom is slower than flash

  14. #39
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,710
    either way if you turn the bike off you still have a chance of writing corrupt data to either media, at least if teensy monitors the ACC line, it can handle the final write before it shuts down

  15. #40
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,758
    PJRC's prop shield has 8MB of Flash for storage - but the SD card should be able to be used. I've not done it yet - but there is a 'low latency logger' thread.

  16. #41
    I would think the sd card could be used to. But any writes to the card while the injectors and coils are firing. ie: engine running. Everything goes crazy. The tach input jumps around and the pulse with on the injectors jump as well. Like it's not calculating the write values. Very frustrating! And I'm no "programmer" by far. I know enough to work around things. This is kicking my tail.

  17. #42
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,710
    your using what for the data, obd/canbus would be more accurate without noise

  18. #43
    Quote Originally Posted by tonton81 View Post
    your using what for the data, obd/canbus would be more accurate without noise
    Not using the teensy for just logging. It is the processor for the ecu. So the variables are updating internally. Just need to get them on the sd card.

    Click image for larger version. 

Name:	20180602_160408_2.jpg 
Views:	12 
Size:	161.6 KB 
ID:	13941

  19. #44
    Quote Originally Posted by defragster View Post
    PJRC's prop shield has 8MB of Flash for storage - but the SD card should be able to be used. I've not done it yet - but there is a 'low latency logger' thread.
    The low latency logger. I've looked over it. Do you think that is something I could implement into this project?

Posting Permissions

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