Help with data recorder
max21
Posts: 6
***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.
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
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?
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.
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:
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
·
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.