Balloon Collaboration
September 21, 2019, 01:47:21 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: DaddyB, Larry and Dan are your administrators...Private message for any problems or issues with the Forum//barntekadmin
 
   Home   Help Search gallery Calendar Login Register  
Pages: [1]
  Print  
Author Topic: Consolidated Telemetry  (Read 3993 times)
Dan
Administrator
Full Member
*****
Posts: 175



View Profile
« on: September 13, 2009, 07:46:03 PM »

We should probalby put our brains to a consolidated telemetry stream that we can download...GPS, accelerometer and weather data all at the same go...Some ideas:

We could go small with one of those 'on-board' (as in on the circuit board) xmitters like we use on the current tracker module...we can order those to xmit at just about any freq we want...downside to that is folks with a standard APRS setup probably won't be able to track, unless we do some serious research and write it so that it's compatible...

We could do away with the tracking module by integrating the tracker into the experiment pod altogether...At this point there's plenty of room...

We already have proof of concept with Daddy's accelerometer, which sent good data until the outboard antenna got ripped off (we could use that little wire whip that we use for the tracker...

I'm suggesting this in anticipation of a up-haul request <see my post: Science Project Request>
Logged
Larry
Administrator
Hero Member
*****
Posts: 1167



View Profile
« Reply #1 on: September 13, 2009, 08:05:34 PM »

Even though I didn't get any usable data from my weather station, I did prove out the concepts of eeprom storage and RTC usage to sync the data.  I think, even though we bradcast the info, we should also store the data via eeprom, in case we lose contact.

Me and daddy had talked about it a little and thought we could still xmit the lat/lon via APRS so others could track it, but the REAL data we could keep on a separate freq to reduce others from talking on top of it.

BTW, the only reason I had unusable data was that I forgot to include code to prevent the data from wrapping.  Since it sat in a tree for a week, the eeprom filled and started writing over itself.
Logged
Dan
Administrator
Full Member
*****
Posts: 175



View Profile
« Reply #2 on: September 13, 2009, 10:22:29 PM »

Right, that wasn't a bash on your project...it obviously worked and worked quite well and I can't wait to see it work on the next launch...I was just talking about proving the concept of collecting data (which both of yours did) and transmitting it in real time to the ground...

That's a good thought about having the tracking separate because of the possibility of someone stepping on top of it...with no receiver onboard, the balloon package doesn't know when it needs to retrans because someone was xmitting on top of it... I was also thinking of timing so that all the components are using the same clock for data analysis afterward...maybe we can split the output on the gps and get timing from it as well... Dunno, just throwing out ideas...
Logged
Larry
Administrator
Hero Member
*****
Posts: 1167



View Profile
« Reply #3 on: September 13, 2009, 10:50:10 PM »

Yeah, I knew it wasn't a bash on my project...  I just wasn't sure if you had heard what the final result of it was.  As for central timing,  The RTC (Real Time Clock) I had on mine would output a 1Hz signal that I used to sync my data readings to every 30 seconds (it was adjustable to any increment you wanted).  I thought maybe have a central PIC that would track the time and monitor the RTC and when it was time, it could interrigate the other projects.  As each project reported what it had to report, this PIC would write everything to the eeprom with a time stamp, then send the data to the xmitter for broadcast. 

Just thinking out loud...

One problem is that I was never able to read the whole GPS string with a PIC.  I don't think my code was fast enuff.  I am thinking of buying a 20MHz Oscillator and drive the PIC at 20 MHz, that will make the code run a little faster, but I think I really need to learn how to streamling it.
Logged
DaddyB
Administrator
Full Member
*****
Posts: 144



View Profile
« Reply #4 on: September 15, 2009, 02:03:52 AM »

Sounds like we're expanding.
I like the idea of a centralized processor to run things.  That has a realtime clock.  This processor would output a pulse to the different port pins to activate various experiments.  These experiments could have their own stand alone processors and when they received the pulse from the command processor, output their data.  I don't know if it's possible, but if we could have a common rs-232 bus, then each experiment could send its data and it would be passed on to the TNC and radio to the ground.

I am just brainstorming.  Think I'll read up on some of the stuff I have and see how they did it with the Basic Stamp.
Logged
Dan
Administrator
Full Member
*****
Posts: 175



View Profile
« Reply #5 on: October 27, 2009, 12:59:15 AM »

Larry, you said that you were never able to read the whole GPS sentence...could we do it with the RS-232 chip?  The GPS that I use is programmable for speed and if we set the RS-232 to receive at the same speed we program the GPS to, then you should be able to buffer the sentence...We're still thinking out loud I know...It could xmit on the common rs232 bus that daddy was talking about for storage and inclusion in the telemetry packet... I think you're right about a separate transmission though for APRS...The more we got tracking it, the better our chances of finding it later...
Logged
Larry
Administrator
Hero Member
*****
Posts: 1167



View Profile
« Reply #6 on: October 27, 2009, 12:10:43 PM »

If I remember right, the problem I was having was that I was never able to set the buffer on the PIC large enough to capture the whole GPS sentance.  I think 20 characters was as big as I could go.  That is probably a limit in the compiler I was using instead of a limit on the chip.  I have found a project someone else built where he reads the hole sentance and parses it, so it can be done, I just have to figure out how.  I may have to delve into assembly to get it done.
Logged
Larry
Administrator
Hero Member
*****
Posts: 1167



View Profile
« Reply #7 on: November 02, 2009, 03:01:18 AM »

GPS Statement Capture resolved...  refer to Balloon Collaboration > Projects > Balloon Projects > GPS Data Collecting Grin
Logged
DaddyB
Administrator
Full Member
*****
Posts: 144



View Profile
« Reply #8 on: January 16, 2010, 02:46:17 AM »

I have been mulling over how best to record the ZIG data for broad cast.
The only way I can see to do it would be to first decide how often to read the Accelerometer and then how to store it whilst we await the polling pulse.
It seems that we can create a table (array) to hold the data and when polled, to dump the data to rs-232.  There would be a gap in the data but this way we could record once per second or once per 2 seconds for about 25 seconds and then hold for poll.
I think last year we used every 5 seconds but we were not storing anything, just every 5 seconds, read and transmit. The display can be 2 characters per data point, ie. 12 would be 1.2g.   We never showed negative g's last year so we wouldn't even have to calculate that part.

I haven't started writing the software yet, but at least I have started thinking about it.    Wink
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!