Teensy 3.5 sd logging HELP!

Status
Not open for further replies.
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.
 
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.
 
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
}
 
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?
 
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.
 
defragster said:
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?
Click to expand...

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?
 
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 ...
 
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 and it gave me all for values 10 times per sec. What's wrong with the timer logic?
 
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.
 
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.
 
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?)
 
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
 
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.
 
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.
 
tonton81 said:
your using what for the data, obd/canbus would be more accurate without noise
Click to expand...

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.

20180602_160408_2.jpg
 
defragster said:
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.
Click to expand...

The low latency logger. I've looked over it. Do you think that is something I could implement into this project?
 
Status
Not open for further replies.
Back
Top