Hi Steve,
my fault! I was searching for -contrib on googlecode as well, because i
thought the sourceforge version was outdated.
Some few first test with the recompiled JustFatLogging worked very
reliable! Cool, now we are able to have our subjects dock the shimmer
and have the data automatically copied and forwarded while the battery
is loading.
Thanks again for finding the bug that we would have never found with a
decent amount of work. It was a pleasure to help improve the project
with some simple tests.
Best regards,
Klaus Hendrik
Am 01.03.2012 16:14, schrieb steve ayer:
hi klaus,
let's see...find googlecode tinyos (yep, i used google), click on
source, we see that you can check out the main repository with:
svn checkout http://tinyos-main.googlecode.com/svn/trunk/ tinyos-main
then, you'll need the -contrib tree too, which lives at sourceforge:
cvs -z3 -d:pserver:[email protected]:/cvsroot/tinyos
checkout -P tinyos-2.x-contrib
naturally, shimmer stuff is under shimmer.
you can also find some useful info about developing on the platform in
the user manual, which should be in the possession of whoever bought the
shimmers; there should also be a ubuntu distro somewhere with
pre-configured account so that you can just login and all of tools are
there (update the source trees instead of checking them out).
i hope that this helps,
steve
On 03/01/2012 09:55 AM, Klaus-Hendrik Wolf wrote:
Hi Steve,
could you point me to the repository on google code?
I am at a new computer and googeling around did get me nowhere!
Sorry for bugging you!
Best regards,
Klaus Hendrik
Am 29.02.2012 18:08, schrieb steve ayer:
klaus,
you might want to try playing with the powercycle timeout in the sd
driver, which is in tinyos-main/tos/platforms/shimmer/chips/sd/SDP.nc
looking at the code now, i see that the TOSH_uwait(60000) statement is
passed a value that might cause type overflow to break the expected
pause interval. while 60ms is three times the spec, if the call isn't
working, then, well, this kind of thing could happen.
either way, i just fixed this and checked it into googlecode. please
update the file, thus:
cd ~/tinyos-main/tos/platforms/ (might as well make sure you're really
up to date, eh?)
svn update
then re-build your app and see if that fixes this problem.
if it does, then thanks for finding this bug. if not, then please adjust
the (what is now) 6000 u-second value passed upwards to see if that
cures the problem.
please let me know...
best,
steve
On 02/29/2012 11:57 AM, Klaus-Hendrik Wolf wrote:
Hi Benjamin,
powering off really does the trick!
Thank you, so at least we have a work around.
Could something similar be done via software?
As the Shimmer is docked, i could even send him some command via the
serial port...
Best regards,
Klaus Hendrik
Am 29.02.2012 15:13, schrieb steve ayer:
yeah,
true. but the sd driver power cycles the card, waiting twice as
long as
the sd-spec's power down timing. determined empirically, sandisk
always
meets the spec (20 ms), and a couple of other brands come close (don't
remember which ones).
but still, usually this problem has to do with host drivers.
-steve
On 02/29/2012 09:08 AM, Benjamin Kuris wrote:
There is power timing variability in sd card brands- try sandisk
You could also try a power cycle (wait 10 seconds in off state) on
your shimmers vs removing cards which is giving a definite power down
to reset media from spi to sd mode
On Feb 29, 2012, at 7:57 AM, steve ayer<[email protected]> wrote:
hi klaus,
this is a host-side issue, with different drivers and operating
systems/environments giving varying results.
"do not adjust your set. the trouble is not in your set."
i wish i had better news,
steve
On 02/29/2012 06:02 AM, Klaus-Hendrik Wolf wrote:
Dear all,
For one of our new settings we would like to use the shimmer as a
recording device only and have the subjects collect the data from
the SD
card via an USB connected dock.
During our testing we came across a problem which hopefully you
know
how
to solve or work around.
Inserting the shimmer into the dock *sometimes* results in it being
discovered by the connected computer as a new medium in the
corresponding block device (monitored with udevadm monitor).
With my latest tests this *sometimes* unfortunately means: not very
often.
We first discovered this behavior with our own firmware, but it is
reproducible with the justfatlogging app as well. I have tested at
least
four different shimmers (2r), so it should not be a hardware
problem.
I tried different combinations of resetting the shimmer (in and
out of
the dock), disconnecting and reconnecting the dock (shimmer in and
out),
but found no combination that is working in most cases.
A work-around for justfatlogging i have found is to remove the SD
card,
reset the shimmer, insert the card and after that put it in the
dock.
But disassembling and removing the SD card is not really an option
for
our study.
Does anyone of you have an idea how to make docking more reliable?
If it is only one out of three it would still be OK.
Even a workaround would be welcome! (As long as it does not involve
opening the shimmer)
Best regards,
Klaus Hendrik
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
