data write speeds and broken SD cards
Re: data write speeds and broken SD cards
Yes, you have the most straightforward use case here - read bytes from sensors, write bytes to file, optimize to collect as much data as you can and take all the time you need to analyze offline.
Cool project, looking forward to hearing more!
-Bryan
Cool project, looking forward to hearing more!
-Bryan
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: data write speeds and broken SD cards
A little preview ...
Re: data write speeds and broken SD cards
Cool - What software are you using to produce the plots?
Re: data write speeds and broken SD cards
Looks like you could use an accelerometer with a little more dynamic range - your acceleration plot appears to show a_x saturated for several readings at -16g (is that the maximum reading the pyboard accelerometer is capable of?)
Thanks for sharing!
-Bryan
Thanks for sharing!
-Bryan
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: data write speeds and broken SD cards
@dhylands: matplotlib
@blmorris: The onboard accelerometer (shown in 'uaccelerations') of the pyboard has a range of +-1.5g, the MPU9150 ('accelerations') has +-16g.
The ADXL377 does +-200g and I guess I will try that. The actual accelerations of the launch are probably going up to 25, maybe 30g. In addition to that you have shocks, with insane g-loads.
@blmorris: The onboard accelerometer (shown in 'uaccelerations') of the pyboard has a range of +-1.5g, the MPU9150 ('accelerations') has +-16g.
The ADXL377 does +-200g and I guess I will try that. The actual accelerations of the launch are probably going up to 25, maybe 30g. In addition to that you have shocks, with insane g-loads.
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: data write speeds and broken SD cards
Have any of you experienced 'hangs'?
In my loop, I call gc.collect() on every iteration. Most of the time it runs at constant 200Hz, but sometimes it would hang for about 5s. If I only call gc.collect() on every n-th iteration, it happens more often. At the moment, I collect on every second iteration (using i%2==0), it runs at 400Hz and the hangs are very seldom.
It seems connected to the garbage collector, but it is strange. Usually, collecting regularly avoids those long collections.
In my loop, I call gc.collect() on every iteration. Most of the time it runs at constant 200Hz, but sometimes it would hang for about 5s. If I only call gc.collect() on every n-th iteration, it happens more often. At the moment, I collect on every second iteration (using i%2==0), it runs at 400Hz and the hangs are very seldom.
It seems connected to the garbage collector, but it is strange. Usually, collecting regularly avoids those long collections.
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: data write speeds and broken SD cards
I nailed that down to the file.write(). It usually takes 5ms, but then suddenly 5000ms for one time. closing and reopening doesn't help. flushing also doesn't help.
/edit: nopes. it's not the file.write(). happens even if i comment that out.
//edit: adding a 1ms delay seems to fix that. still no idea what's happening. sample rate now at 900 Hz.
/edit: nopes. it's not the file.write(). happens even if i comment that out.
//edit: adding a 1ms delay seems to fix that. still no idea what's happening. sample rate now at 900 Hz.
-
- Posts: 288
- Joined: Sun May 04, 2014 8:54 am
Re: data write speeds and broken SD cards
The board survived rocket crashes, but not me dropping it from half a meter heigth.
Any ideas? I have some µSD card breakout boards - maybe I will figure out how to use them with the pyboard.
https://drive.google.com/file/d/0B2UZjB ... sp=sharing
Any ideas? I have some µSD card breakout boards - maybe I will figure out how to use them with the pyboard.
https://drive.google.com/file/d/0B2UZjB ... sp=sharing
Last edited by Turbinenreiter on Mon Oct 27, 2014 5:30 pm, edited 1 time in total.
Re: data write speeds and broken SD cards
Can't see the picture that you posted - even tried to cut and paste the link and got a message about not having permission to access it.Turbinenreiter wrote:The board survived rocket crashes, but not me dropping it from half a meter heigth.
Any ideas? I have some µSD card breakout boards - maybe I will figure out how to use them with the pyboard.
-Bryan
Edited to add:
I see that the solder pads came off with the micro-SD connector. That's a drag, certainly complicates things when you can't access the pins for the removable storage (RSI) interface.
Have you considered trying to write to an SD card in 1-bit SPI compatible mode? You would probably need to write your own driver to make it work in micropython though.
Last edited by blmorris on Thu Oct 30, 2014 2:14 pm, edited 1 time in total.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: data write speeds and broken SD cards
@Turbinenreiter
Have you considered running your code from the internal flash and storing your data on an external FRAM module like this
http://proto-pic.co.uk/adafruit-i2c-non ... t-32kbyte/? Of course it may be too small or too slow.
It's a credit to the Micropython board that it can survive these G loadings. More years ago than I care to remember I worked on the development of telemetry for guided missiles. We went to extraordinary lengths to ensure the kit survived the launches. It used radio to transmit its readings so it didn't have to survive the landings
Regards, Pete
Have you considered running your code from the internal flash and storing your data on an external FRAM module like this
http://proto-pic.co.uk/adafruit-i2c-non ... t-32kbyte/? Of course it may be too small or too slow.
It's a credit to the Micropython board that it can survive these G loadings. More years ago than I care to remember I worked on the development of telemetry for guided missiles. We went to extraordinary lengths to ensure the kit survived the launches. It used radio to transmit its readings so it didn't have to survive the landings
Regards, Pete
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.