Shop OBEX P1 Docs P2 Docs Learn Events
Help with data recorder — Parallax Forums

Help with data recorder

max21max21 Posts: 6
edited 2009-11-16 23:56 in Propeller 1
***New subject title and zip folder attachment as requested. I apologize if this is still not what is desired as I am not fluent in forum protocol yet. Please let me know if I need to make further changes, and/or feel free to modify this thread as one would see fit.

From; Looking for a Propeller Programmer:

Many thanks for the replys.

We are currently trying to get the 2nd·version of the Flight Data Recorder to operate properly.

Attached is the code that has been tried to date with limited sucess. We are·updating the schematics to reflect the latest changes to the design and will post them asap.

We·are recording the data from 5 instruments·to on-board memory, and then transferring it to a memory stick via the Parallax memory dataloger.·This process·is currently giving us the most trouble. It seems to·run fine for a short while and then it slows to a crawl. The·baud rate seems to·influence the·condition. We are monitoring the data with a two·channel oscilloscope. The data waves look good when it is communicating, it just won’t work consistently.
·
Another issue·we are·having is, if the speed of the ADC·changes (sample rate and/or the clock delay), the bit value of the·analog sensors·change·greatly.
·
We are using·an·15lb absolute pressure sensor for altitude (MPX4115A), the air speed is sensor is (1Mbar-D-4V), the ADC we are·using is a (MAX1416EPE), the 3 axis accelerometer is (LIS3LV02DQ) on a brake out board from sparkfun.com, the tilt compensated compass is (HMC6343) also from SparkFun,·finally a·Temp/Humid sensor (SHT-15) from sensirion.com.· The Parallax Memory stick dataloger is (#27937). The analog instruments have a dedicated power supply as well.
·
Spin is a new language for us (I say us as I am not the programmer). Any guidance, comments, etc would be greatly appreciated.

Comments

  • T ChapT Chap Posts: 4,223
    edited 2009-11-15 22:16
    Somebody said...
    The data waves look good when it is communicating, it just won’t work consistently.

    So are you suggesting that the data waves look bad at some point that coincides with the slowness and inconsistent behavior?

    Have you tried isolating sensors for datalogging to see how one each sensor performs alone? I would start by logging one sensor at a time to see if you can get that far then start adding in one at time to see if you can spot something.

    That file is too long to follow or test without a lot of time to sort it out. Are you opening and closing different files or simply appending data to the same file with some ID for what sensor the data came from? If so are you opening and closing the same file per write, or leaving it open the whole time?
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-11-16 08:27
    Just had a quick look on your code ... *puh*

    That code is hard to read for others ... and propably for you as well ;o)

    Analysis will take a while.
    Just 2 points:
    You should not use coginit! With coginit you will never recognize that a COG has already been started by an object before. You simply replace it with a COGINIT and wonder why your code does not run. And you'd never detect that you run out of COGs.

    Your function that logs the values is not synchronized with any reader. For example your accelerometer measure is done, then comes the writer to log X value, meanwhile accelerometer measures again. Then Y value is written. In this case you would log 3 values of 2 different measures. Depending on how fast accelerometer values change, you might get a completely wrong impression on what's going on.
  • T ChapT Chap Posts: 4,223
    edited 2009-11-16 17:49
    I tried looking at it again since I always want to learn about Vinculum stuff... but your code is almost impossible to read, mainly because you have ALL of your code hard left, no indention whatsoever unless it is required by the code. In other words, with indention you can take a quick glance at the code and scan down to see where each pub/pri starts and ends. In your case you cannot tell where anything starts and stops.

    First get your code cleaned up, especially with such a large program like that you MUST have easy 'eye scan-ability'.

    Then, as Magi02 stated, you need to get your sync very neatly organized.

    A very over simplified loop that reads and writes would look like, minus any open file to write or read requirements:


    Pub ScanAndLog 
          ReadSensor1
          AppendToDrive
          ReadSensor2
          AppendToDrive
          ReadSensor3
          AppendToDrive
          ReadSensor4
          AppendToDrive
          ReadSensor5
          AppendToDrive
    
    



    The other option that may get you some speed is to set a cog that reads sensors and stores the data in a buffer, then waits until instructed to read that sensor again. Set another cog that is managing the writes, and have them communicate with a variable that gets set for OK to read the sensor. This way while you are appending one value to the drive, the other cog can be already reading the next sensor and having the value ready to append when the current append is done. In other words the whole process is synchronized, even though different cogs are working.

    Another option is to read all senors, then append, then read all sensors, then append etc.

    Post Edited (Todd Chapman) : 11/16/2009 7:21:24 PM GMT
  • max21max21 Posts: 6
    edited 2009-11-16 23:56
    FANTASTIC STUFF !!!
    ·
    Please keep it coming. I will tell the programmer to review the comments and make the suggested alterations for further review.
    ·
    Many thank in advance. I feel helpless at this stage of the project as I·the idea of the code makes my head spin (no pun intended).·The basic comments so far gives me hope that we might be able to pull this off.
Sign In or Register to comment.