Kepler

Have we decided changes like adding and removing a sensor, things that require changing the program itself, are something we the user to be able to do through kepler? Maybe not for the initial release of sensor view?

After discussion with Dan changing to an ER.
It would be nice to be able to see the entire program on the logger, and upload a modified version that you've likely prepared using the e.g. campbell's editor, but this would mainly be added functionality not commonly used and for expert users.

changing bugs from REAP to Kepler product

I've been playing with sensor-view and thinking through various usecases, and I think at least being able to see/read the program that's actually running on the logger would be of enormous benefit, e.g. from a site layout archival point of view. It's invaluable when looking at past measurements to be able to look at exactly what program was running on the logger at that time. When monitoring, it's also valuable for measurement context.
It's unclear if this is currently possible through SPAN, we may consider looking into it and trying to add this feature.
Also if we're able to view the program, ideally an advanced user could also edit it (uploading the new version to the logger).

Adding dependency - the solution to bug#5321 will likely add capability to get the program from logger, and then this bug just becomes making a gui display for this program which could be an attribute to the logger actor.

r55 adds a GetFileFromLogger method and associated get-file-from-logger command. E.g.

telnet gpp.msi.ucsb.edu 55055
get-file-from-logger CR800 CPU:conf.CR8

I've used the method to fetch ("upload from the logger") and write to gumstix disk the .TDF, .DIR, and CPU:conf.CR8 files. I've also tested the command on the cmd port. It only gives sensible results for all ascii files, like the CR8.

However there's currently a big caveat - one can currently only make 1 set of calls to cmdFileUpload. A 2nd set of calls gives an error. Since GetFileFromLogger uses cmdFileUpload, and since one of the first things cr1k_d does on startup is to use cmdFileUpload to fetch the .TDF, you won't be able to use this command until we fix this bug (or you temporarily comment out the initial .TDF fetch).

After a long fruitless struggle trying to determine why upload transactions from SPAN for the CR800 always returned the Invalid file name response (0x0d) on upload attempts after the first file upload, I took the plunge and updated my logger's OS from CR800.Std.09 to CR800.Std.22. I was aware of upload-related fixes in their revision history (http://www.campbellsci.com/70_121), but wasn't very confident they were relevant, and have been putting off the update until SPAN was more stable. Well, the update seems to have mostly done the trick! Instead of uploads never working after the first, they now usually work. I'll keep trying to track down why they occasionally fail as I start working on the kepler gui to show the program. Hopefully worst case scenario is Kepler will just have to retry a few times.

So far I haven't seen any problems related to the OS update - monitoring, changing sensor sampling rates, and spanTodt still work. But as I don't see the older OSes being offered as downloads, it may be good for Dan to stay on the older OS for awhile until I've tested this more extensively.

At r27575, on Site Import and site layout execution, the span-default active program is fetched from the logger, and is put into a Datalogger actor parameter as Fixed (read-only) text. The issue with the span fileUpload process not always working remains, and so for now a couple tries are made before giving up. Site import is now slower because of program retrieval (esp. if retries occur), but I think it's worth it.

This new feature can sometimes crash cr1k_d, so I've temporarily disabled it at r27619.

• glibc detected * ./cr1k_d: realloc(): invalid next size: 0x412031a0 *

Changing target, this feature will probably have to stay disabled for the first sensor-view release.

The g++ I'm using on Lion gives some good warning messages that I don't think I've seen before, including about the method that gets the logger program. Look into these

Original Bugzilla ID was 4763