Become a Citizen Scientist for NASA During US Total Eclipse

JonM

So, NASA has sent out a call for help with collecting data during the total Solar Eclipse specifically in the US for the Aug 21st, 2017 event.

This might be a good opportunity to use some Parallax products to collect the data and pass it on to NASA. Something that could periodically collect temp data during the Eclipse and send it to a central location would be a cool thing to try.

Here be the link from NASA:

https://www.nasa.gov/feature/goddard/2017/nasa-invites-you-to-become-a-citizen-scientist-during-us-total-solar-eclipse

Jeff Haas

This sounds like a lot of fun! Intro is here:
https://observer.globe.gov/science-connections/eclipse2017

I think what we need is a program that fulfills their temperature measurement requirements:

You can also collect and report data about air temperature on a special page that will be available in the GLOBE Observer app on the days surrounding the eclipse. Whatever type of thermometer you use, make sure you are taking your measurements in the shade, even if that is just the shadow of your body with the thermometer held at arm's length. Here's the preferred schedule for air temperature measurements:

- For two hours before and after maximum eclipse, take a measurement every ten minutes.
- If you can, increase that to every five minutes for the half hour before and after totality or the maximum eclipse at your location.
- You can also take measurements the day before the eclipse. Ideally, these would be near the time maximum eclipse will occur the following day. For example, if the time of totality for your location is 10:15 am on August 21st, make measurements at about 10:15 on August 20th.

I would suggest the following automated temperature measuring station, that will allow you to upload the data after the eclipse:
- Parallax Propeller!
- Use a DHT11 or DHT22 sensor. Walt Mosscrop has an object in OBEX that I helped test:
http://obex.parallax.com/object/837
- Save the data automatically to an SD card as each measurement is taken
- Keep accurate track of time with a RTC module.

This allows you to assemble it and then put it outside in the shade, so it will run automaticall. I have to get to bed right now, I have a business trip tomorrow, but we have two weeks to code, test and post.

Bonus points: Can this be done in BlocklyProp? (I don't know.)

DavidZemon

Jeff Haas wrote: »

This sounds like a lot of fun! Intro is here:
https://observer.globe.gov/science-connections/eclipse2017

I think what we need is a program that fulfills their temperature measurement requirements:

You can also collect and report data about air temperature on a special page that will be available in the GLOBE Observer app on the days surrounding the eclipse. Whatever type of thermometer you use, make sure you are taking your measurements in the shade, even if that is just the shadow of your body with the thermometer held at arm's length. Here's the preferred schedule for air temperature measurements:

- For two hours before and after maximum eclipse, take a measurement every ten minutes.
- If you can, increase that to every five minutes for the half hour before and after totality or the maximum eclipse at your location.
- You can also take measurements the day before the eclipse. Ideally, these would be near the time maximum eclipse will occur the following day. For example, if the time of totality for your location is 10:15 am on August 21st, make measurements at about 10:15 on August 20th.

I would suggest the following automated temperature measuring station, that will allow you to upload the data after the eclipse:
- Parallax Propeller!
- Use a DHT11 or DHT22 sensor. Walt Mosscrop has an object in OBEX that I helped test:
http://obex.parallax.com/object/837
- Save the data automatically to an SD card as each measurement is taken
- Keep accurate track of time with a RTC module.

This allows you to assemble it and then put it outside in the shade, so it will run automaticall. I have to get to bed right now, I have a business trip tomorrow, but we have two weeks to code, test and post.

Bonus points: Can this be done in BlocklyProp? (I don't know.)

Cool! I have a DNA board with RTC & SD card socket already. I'll need to pick up a DHT11/DHT22 but that should be it. Could be fun!

erco

Pretty cool. This sounds like something Forrest Mims would endorse.

JonM

Nice. Adding something like a Parallax WX ESP8266 Wi-Fi Module or XBee connection the data could be pushed to a cloud location and saved to something like a Google Spreadsheet. Currently I'm working with a TI CC3220 so this could be a good use of that by collecting data from the Parallax node.

I'm not sure how to interface directly to the mobile app but that would be cool as well.

A project like this would make for a nice School Challange for educators and see who can come up with the most innovative use of Parallax products to collect the Eclipse data. Just a thought.

tomcrawford

Quick put together a DS1620, GPS, and BoE.

msrobots

@tomcrawford,

well done. Except on the picture the wires exactly prevent me from seeing how cool it is in Cool, CA

Enjoy!

Mike

tomcrawford

It think it was 28 or 29. C. And that's inside which the AC going. It got to 101F here yesterday.

I have to say that sending the data in is going to be a whole lot more time consuming than gathering it. There are a couple of on-line courses you have to take to get qualified.

Dave Hein

I was guessing 23 or 29 C based on the lower portion of the number that can be seen. So it must have been 29 C.

MikeDYur

You guy's are attracting some attention to this thread.

Could there be job applicants for this position?

http://www.cbsnews.com/news/alien-headlines-aside-nasa-is-serious-about-planetary-protection

Jeff Haas

Tom - Is your code in a state that you feel you can share it?

tomcrawford

Jeff Haas wrote: »

Tom - Is your code in a state that you feel you can share it?

I need to show all four digits of the Lat/long fraction, and think they want local time not UTC. I'll undertake to do that by Monday and then post without attribution (it's kinda clunky).

Jeff Haas

Great, I'll be back home by then and will be able to pull out my Prop and other stuff and get crackin'!

Jeff Haas

My flight was delayed and I was able to complete the first module (Introduction to GLOBE) sitting in the airport. Don't sweat the certification, if you can program you will certainly be able to pass!

tomcrawford

Jeff Haas wrote: »

Great, I'll be back home by then and will be able to pull out my Prop and other stuff and get crackin'!

Okay but note I am doing BS-2. Actually BS-2p or px since I am using the WAIT formatter at 9600 baud.

Edit: Here is a pointer to a spin GPS parser.

tomcrawford

This is a data capture program written for BS-2p, BS-2px specifically for Globe for the 2017 eclipse. Fast BS's because I use the WAIT formatter at 9600 baud.

This needs a DS1620 thermometer, a 4 x 20 LCD, and a 9600 baud GPS that does RMC sentences.

I plan to view the eclipse in Nebraska and then report the data when I return home. So the data are stored in the EEPROM of the BS. It captures 51 data points, every five minutes beginning 2 hours 5 minutes prior to totality, ending 2 hours 5 minutes following totality (nominally 1300 hrs CDT).

The program begins by displaying the latitude and longitude of a putative prior run and the data from that run.
It then loops waiting for valid GPS data. When it sees good data, it says Press to Continue (GPSGood.jgp).
When you press the button, it records and current lat and long and awaits the start time (waiting.jgp).
Beginning with the StartTime, it collects 51 samples at five minutes intervals ( AFew, MidWay, Done.jgp).

A photo of the set is appended. I did not use a servo connector for the GPS 'cause the pinout doesn't match.
The code is attached. It can easily be configured as to Time Zone, Start Time, and NumberOf Samples.

This is better than an instant read kitchen thermometer and a piece of paper only because it requires less attention during the eclipse.

MikeDYur

I downloaded the app, and may get into this fun even though I'm not in the direct path. I do hope the weather cooperates.
I usually have good luck viewing the ISS, hope it hold out for this one time event.

https://eclipse.gsfc.nasa.gov/SEmono/TSE2017/TSE2017.html

http://www.cbsnews.com/news/solar-eclipse-august-21-2017-viewing-weather/

Jeff Haas

I've made progress on the Propeller version. So far I've got the RTC triggering events on a schedule, temperature can be measured and displayed via LCD, and I've got the SD card set up via fsrw. Had some hair-pulling moments when I discovered that my DHT22 sensor has stopped reading humidity, but the temperature is still OK.

Main thing left to do is to translate Walt's temperature readings into a format that can be written to the SD card with date & time, in an Excel-friendly format. Then to put all the pieces together.

Jeff Haas

I am nearly done, but I've run into something I can't figure out.

I can read the temperature and write it to the SD card using fsrw, but I am having trouble reading the RTC and converting it into a format that will write to the SD card.

Current code uses a button to take a temperature reading and save it. Later that will be converted to events triggered by the RTC, which I've got working elsewhere.

Any suggestions? Please look in the rtc_save method. The part commented out is not working.

tomcrawford

Which file is it in? I couldn't find it.

Jeff Haas

Top object is lcd DHT SD RTC.spin (I will rename the whole thing when it's done, I promise!)

Scroll down to "pub rtc_save" for where I'm displaying the time on the LCD. Below that is the SD card writing code, commented out because it's not working.

The RTC is via jm_ds3231.spin, trying to use the byte in the long to save to the SD; if I do this I get an error:

SDFat.pputs(tc.byte[2], 2)

Pressing F9 results in the [2] highlighted, with

Expected ")".

There must be a way to grab the data from the RTC and save it to the SD, but late last night I couldn't crack it.


Thanks for helping!

Jeff Haas

I've isolated my issue to the following...

Take the return value from this method (and a couple of others like it in jm_ds3231.spin), and write it to the SD card:

pub time_hhmmss(p_src) | work 

'' Returns pointer to formatted time string
'' -- formatted string of registers at p_src
'' -- user -1 for internal RTC registers

  if (p_src < 0)
    read(3, @work, R_SCS)                                       ' internal clock 
  else
    bytemove(@work, p_src, 3)                                   ' external values

  StrLong[0] := work.byte[2] >>   4 + "0"                       ' convert to ASCII
  StrLong[1] := work.byte[2] &  $0F + "0" 
  StrLong[2] := ":"                        
  StrLong[3] := work.byte[1] >>   4 + "0" 
  StrLong[4] := work.byte[1] &  $0F + "0"
  StrLong[5] := ":"
  StrLong[6] := work.byte[0] >>   4 + "0" 
  StrLong[7] := work.byte[0] &  $0F + "0" 

  return @StrLong

Here's what I'm doing but the file on the SD card is incorrect:

pub rtc_save | last, dc, tc, day, StrLong

    SDFat.popen(string("TimeA.txt"), "a") ' Open output.txt, a text file, to receive your line of text.

    SDFat.pputs(rtc.time_hhmmss(@StrLong))   ' Now, we actually put the line of text into the file we opened on the card.         
    SDFat.pputc(",")

    SDFat.pclose   

What I just got on the SD card is this:
=0:00:11,

??

tomcrawford

StrLong IS defined as bytes?
What happens when you lcd.str StrLong?

Jeff Haas

JM has StrLong defined in his DAT section:

dat

  Unknown               byte    "???", 0

  StrShort              byte    "00:00", 0
  StrLong               byte    "00:00:00", 0              

  TimeStr               byte    "hh:mm:ss xM", 0

lcd.str StrLong gives same result as what ends up on the SD card:

:<:00:11

Jeff Haas

Found it! This works, both for the LCD and the SD:

lcd.str(rtc.time_hhmmss(-1)) 
SDFat.pputs((rtc.time_hhmmss(-1))) 

Jeff Haas

Got the software done and tweaked to my satisfaction. Had a bit of a scare when I was testing it with one of those Best Buy blue cell phone battery backups we got a while back...those have an auto shut-off and the Quickstart doesn't draw enough power to keep it on! But I have other 18560 packs that don't do that.

I have to go out of town for a conference but will be back later this week. I'll clean up the code and post it then.

Looking forward to doing a Forrest Mims-type citizen science experiment!

Jeff Haas

Here's my code. It's set up for Northern California but it's easy to change the table to different date/times for other regions.

Hardware:
Parallax Quickstart
DHT22 Temperature/Humidity sensor (DHT11 can also be used)
SD card reader
DS3231 Real Time Clock module
LCD display, I2C type, 2 lines

JonM

Jeff,

Awesome! I had seen the Spin module for the DHT11/22 however I was not able to locate one for Prop 'C'. I've been trying to port over an Arduino version for the OSEPP HUMI-01/DHT11 to work with the Propeller FLiP, and although close, I have not been able to get a temp value from it. The OSEPP HUMI-01 seems to work fine with the "DHTnn_Test for DHT11_Object " so the circuit appears to be working, but no go with the Prop 'C' HUMI-01 port.
Do you know if there is Prop 'C' code for the DHT11/22?

Jeff Haas

Jon,

Thanks!

I don't know if there's C code for the DHT sensors, I have not used C on the Prop. When Walt was working on his Spin code for the sensors last year, I remember there was a lot of careful tweaking needed at the end to lock it down. All I can suggest is that you go over his code to see what you might be missing in your port.