Shop OBEX P1 Docs P2 Docs Learn Events
Sample Rate Much Lower Than Expected - Help? — Parallax Forums

Sample Rate Much Lower Than Expected - Help?

Matt LeBlancMatt LeBlanc Posts: 9
edited 2009-04-07 04:11 in BASIC Stamp
Hi all,

I've been working on a term project using a BASIC stamp, which involves taking data from a HITACHI 3-axis accelerometer and storing it on a flash drive via the parallax datalogger. I've run into a bit of a snag - my sampling rate is much slower than it should be (and needs to be), but I can't determine the cause of it: as far as I understand, I've removed all pauses from the bits of my program in question and it's still far too low to actually be useful for anything. Any help you could give me would be greatly appriciated...

This is the section of my code which involves the datalogger and accelerometer, it's essentially just a fusion of the sample code for each device that I've tweaked in order to meet my needs (it calls on a couple subroutines, but there aren't any pauses there either so I don't believe they're the cause. I'll post them if need be. Baud should be 9600 bps):

dumb = 0

DO WHILE(dumb < 25)

  FOR current_axis = x_axis TO z_axis           ' for each axis...
    GOSUB Data_Collect                          ' get the raw count value for conversion, and the reference voltage...

    IF (axis_count >= reference_count) THEN
      gforce = (axis_count - reference_count) ** gforce_constant     ' determine whether gforce is positive
    ELSE                                                             ' or negative, and make appropriate adjustments...
      gforce = -((reference_count - axis_count) ** gforce_constant)
    ENDIF
     DEBUG DEC1 (ABS(gforce) / 100), ".",             ' display gforce value on console!
           DEC2 ABS(gforce), " "

     gforce_array(current_axis) = gforce

   IF (current_axis = z_axis) THEN 'Write a return to the screen after every 3rd value
        DEBUG CR
     ELSE
     ENDIF

  NEXT

  i=0

  DO WHILE i < 3
  ' Write acceleration value to data.txt
  'PAUSE 100 '250
  SEROUT Transmit\Clear, Baud, [noparse][[/noparse]"WRF ", $00, $00, $00, $06, CR,
                                   SDEC4 gforce_array(i), ",", CR]
  GOSUB Get_Serial_Bytes
  GOSUB Purge

  'Write carriage return between every 3 values...
   IF (i = 2) THEN
     ' PAUSE 100 '250
      SEROUT Transmit\Clear, Baud, [noparse][[/noparse]"WRF ", $00, $00, $00, $02, CR, LF, CR]
      GOSUB Get_Serial_Bytes
      GOSUB Purge
      ELSE
   ENDIF
  i=i+1
  LOOP

Comments

  • rixterrixter Posts: 95
    edited 2009-04-06 21:48
    Matt,

    Did you try omitting the datalogger portion (isolation), to see if that portion of the program is bogging things down? You didn't mention what sampling rate you are trying to achieve, but I think you may find that the logging to the thumb drive will tie up some time. Depending on how many samples you require and which BASIC Stamp you are using, you could write to EEPROM, then dump to the data logger as a separate process when you are not concerned with the rate of output to that device.

    Rick
  • Matt LeBlancMatt LeBlanc Posts: 9
    edited 2009-04-06 22:06
    Hi Rick,

    I commented out the datalogging portion, and it did indeed go much faster - easily within the range I need. I'm hoping to achieve somewhere between 10-20sps, but the more the better in reality. It was incredibly slow before - less than one.

    I'm a bit of a newcomer to this sort of programming and to microprocessors in general, and the idea of writing to the EEPROM seems like the best bet - take some samples, leave them there, then write them later like you said. I'm having some issues in practice actually achieving this: I'm using a BS2pe, and I'd be working with batches of 25-50 samples at a time. Should I be using the WRITE and READ commands, starting from eeprom location 0?

    Thank you for the help, I appreciate it. =)
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2009-04-07 01:06
    Matt , if you did away with the DO WHILE-LOOP and·transmitted the three axis·as one continuous string of data you would see a significant increase in speed
    ' Write acceleration value to data.txt
      
      SEROUT Transmit\Clear, Baud, [noparse][[/noparse]"WRF ", $00, $00, $00, $11, CR,SDEC4 gforce_array(0), ",",SDEC4 gforce_array(1), 
                                     ",",SDEC4 gforce_array(2), ",", CR, LF, CR] 
     
      GOSUB Get_Serial_Bytes
      GOSUB Purge
    
    

    increasing the baudrate if possible would give you some more.

    The current code you have has a typo , the first·SEROUT is commanding 6 bytes but only sending 5 .

    Jeff T.·
  • rixterrixter Posts: 95
    edited 2009-04-07 04:11
    Matt,

    As you can see from Jeff's comments, there are often more ways than one to make things perk up a bit.

    The BS2pe should have plenty of EEPROM to write to for your purposes as it utilizes memory across several slots. To simplify matters, you could start your data saving in slot #1, the second of the 16 2K slots you have to work with... leaving the first slot (slot 0) for your program. Yes, you'll use the WRITE and READ statements to do this, preceded by a STORE command to indicate which slot you are working in for the READ and WRITE commands. Of course if you are accessing EEPROM in the current slot, a STORE command is not required. All READs and WRITEs assume the current slot unless told otherwise. Don't confuse this concept with moving back and forth between these same slots for program use, which requires the RUN command to switch slots. No matter which slot your program is running from, you can access the various memory slots. That is to say that the STORE command tells the Stamp "look over in that slot's memory locations", where the RUN command for program control actually jumps control over to that slot... giving up whatever code it may have been running in the slot it was previously operating in. Memory locations within each slot will be addressed as locations 0 thru 2047. If you need to view the memory across the separate slots as one contiguous block of memory, there are schemes to simplify this programmatically.

    Rick
Sign In or Register to comment.