A little more detail on White Star Balloon flights for the curious

[stea...@gmail.com]

Hi All,

One question first: can someone find a reference for the rule on HF data telemetry on 10.146MHz from balloons over the US? We didn't do it on SNOX cause we thought it wasn't legal, but now can't find a reference to the regs that say so...

The White Star program is starting from the open-sourced Spirit of Knoxville Transatlantic Balloon system designs and research information and building upon them. ( SNOX data/research available at http://web.me.com/dbowen1/Spirit_of_Knoxville_Published_Information/SNOX_DOCS_Blog/SNOX_DOCS_Blog.html and http://wiki.whitestarballoon.com/doku.php?id=analysis:snox ) There are two member of the old SNOX team participating in White Star, Carl Lyster, WA4ADG, who designed and built all the electronics on SNOX, and myself. Bill Brown, WB8ELK, may also be contributing and flying hardware onboard as well.

We're taking a completely open stance on info sharing right from the start. We'd like to welcome others to compete, poke around our code, spectate, comment, compete or collaborate. All* of our technical details are/will be available at http://wiki.whitestarballoon.com.

Anyone in the balloon community is welcome to listen in on our meetings/work sessions, we will have a speakerphone at all the meetings tied into the conference call number. We have meetings VERY often in this rush to the Jet Stream season, usually 3-5 times per week, plus one scheduled conference call per week. Events calendar: http://www.google.com/calendar/embed?src=d2hpdGVzdGFyYmFsbG9vbkBnbWFpbC5jb20

There are multiple small teams working in parallel on the many mini-projects that are required to do a long duration balloon. We hope that the stuff we put together can be used by others as a starting point to spend time solving the next problems, getting better, going farther, easier. You will find info on the wiki on mini-projects that also still need help, which you're welcome to contribute to.

For the first flight or two we'll be collecting a large amount of scientific data, at a very high data rate. We're aiming to have 1 minute data logging for the duration of the mission, and have all of it relayed down via telemetry, not stored in a data logger. (telemetry may be in bursts though, not every minute) For the first flight the Global Western TA Zero Pressure balloon envelopes will be instrumented to gather data on exactly what happens to a small ZP balloon. Temperature will be measured at three heights in the balloon, and differential air pressure (vs outside) will be measured at the top and bottom of the balloon. The temperature from solar heating is quite important to being able to understand and predict balloon performance, and very little data exists for that on this size of balloon.

There will be a mems barometric altimeter onboard the payload for altitude holding, instead of GPS altitude. The Telemetry is likely going to be a hybrid satellite data/HF system, where satellite uplink commands are used to pause the HF telemetry when no propagation is available. satellite is cheap if you only send about 3KB per month, but gets expensive quick as your data xferred goes up. Telemetry format and data modes are being explored now. Data compression will be used for telemetry data, in a defined method so data can be independently verified if desired. We're looking at ASCII 110 baud, 8 data bits, 1 stop bit, as an easy-to implement method, but also are looking at DominoEX. The problem with DominoEX is that it doesn't appear to allow 8-bit bytes. We'd really like a method that supports 8-bit data bytes to ease the flight computer programming. We'd welcome any suggestions here.

Telemetry is going to be sent at regular intervals over HF during normal propagation. Position-only data will be sent via satellite at all times to ensure ATC knows where we are at all times. After propagation dropouts, however, all the backlogged data will be sent in a CONTINUOUS BURST until caught up with realtime. This will be commanded via satellite uplink.

There will likely be a tip-over cutdown, remotely commandable via satellite.

Ballast will be liquid alcohol, using an identical system to SNOX for the first SpeedBall or two, as we develop improvements to shed more than just 6lbs.

We'll be communicating with every ATC center we pass through via telephone for all phases of the flight. This will be an intensive job, requiring a phone call at least once every 30 minutes, for 24-72 hours while over the ocean. We would like some help on this if anyone is interested, so we can do this in shifts. Training would be provided, but pilots or ATC controllers are preferable.

Background on the names
SpeedBall will be the name of all our Jet Stream flights - a nod to the other trans-atlantic speeder, the Concorde. It's ATC radio callsign was SpeedBird. The HighBall-1 latex flight this weekend is merely to get our launch crew some launch coordination experience, and our local ATC some comfort with us. It's not going to go fast, so no SpeedBall name for it. I know HighBall isn't very original, but it's a pretty typical latex flight anyway!

Thanks,
Dan

*There is a private section of the wiki, but I'll tell you what's in there - service plan data that we had to sign an NDA to get from Orbcomm, passwords to websites like twitter, our personal members contact info, and our money records.

[Daniel Richman]

I'm not 100%  sure what you mean by "allowing 8 bit bytes", but DOMEX as far as I know does let you send any byte from 0 to 255 in 2 to 3 tones. Have a look at these links:

http://www.qsl.net/zl1bpu/MFSK/DominoEX%20Varicode%20Table.pdf

http://github.com/danielrichman/avr/blob/master/xplain-x128a1/dac_domex.c - a draft/proof of concept version adapted off something that CUSF adapted off fldigi (which, by the way, has a bug in it that prevents it decoding 0x7d: https://lists.berlios.de/pipermail/fldigi-devel/2010-June/000322.html).

One of the problems with DOMEX however is that in addition to temperature causing a shift "left" and "right", it will also cause the shift between two tones to get smaller; i.e., squishing it. This is fine for rtty but fldigi atleast gets very upset when that happens to DominoEX.

Daniel

--
You received this message because you are subscribed to the Google Groups "Atlantic_Halo" group.
To post to this group, send email to atlant...@googlegroups.com.
To unsubscribe from this group, send email to atlantic_hal...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/atlantic_halo?hl=en.

[wb8...@aol.com]

Dan,

 

  My DominoEX transmitter will easily do 8-bit ASCII....I just have to expand my lookup table to do it is all....but I'd advise transmitting readable ASCII characters so that the world can decode it easily during flight.

 

  The good news is that DominoEX can tolerage quite some drift in overall frequency (200 hz/min), which is why I chose it over PSK31 (which can tolerate little or no drifting - plus DominoEX is faster)...however as was pointed out you don't want the tone spacing between each tone to compress or expand too much as it doesn't like that. I'm actually using the built-in oscillator on the Cypress PSoC instead of the crystal reference and it does drift with temperature....but I am now compensating for that by adjusting the master clock adjust register depending on the temperature and that seems to work well. I prefer DominoEX over RTTY in a noisy environment...but with good S/N, I prefer 8-bit ASCII RTTY as I can run that at 300 baud on VHF....the DominoEX wins out with weak signals though. The 8-bit ASCII RTTY at 110 baud might be a good compromise but it won't like noise and static. 8-bit ASCII RTTY is very easy to generate since you don't need the cumbersome 5-bit BAUDOT lookup table or the LETTERS/FIGURES shift to worry about....you just parse the 8-bit ASCII character itself to generate the MARK and SPACE tones and bingo that's all you need to do. DominoEX isn't too hard to implement....just need a lookup table for the Varicode nibbles and worry about getting the inter-tone spacing as accurate as possible is all.

 

I'd advise you to listen during the day to the segment between 10.140 and 10.150 and you'll see how the band gets used.....the only quieter segment I found was around 10.142 and perhaps 10.146.

 

 

 

- Bill

 

 

 


There are multiple small teams working in parallel on the many mini-projects 
that are required to do a long duration balloon.  We hope that the stuff we put 
together can be used by others as a starting point to spend time solving the 
next problems, getting better, going farther, easier.  You will find info on the 
wiki on mini-projects that also still need help, which you're welcome to 
contribute to.

For the first flight or two we'll be collecting a large amount of scientific 
data, at a very high data rate.  We're aiming to have 1 minute data logging for 
the duration of the mission, and have all of it relayed down via telemetry, not 
stored in a data logger.  (telemetry may be in bursts though, not every minute)   
For the first flight the Global Western TA Zero Pressure balloon envelopes will 
be instrumented to gather data on exactly what happens to a small ZP balloon.  
Temperature will be measured at three heights in the balloon, and differential 
air pressure (vs outside) will be measured at the top and bottom of the balloon.  
The temperature from solar heating is quite important to being able to 
understand and predict balloon performance, and very little data exists for that 
on this size of balloon.

There will be a mems barometric altimeter onboard the payload for altitude 
holding, instead of GPS altitude.  The Telemetry is likely going to be a hybrid 
satellite data/HF system, where satellite uplink commands are used to pause the 
HF telemetry when no propagation is available.  satellite is cheap if you only 
send about 3KB per month, but gets expensive quick as your data xferred goes up.  
Telemetry format and data modes are being explored now.  Data compression will 
be used for telemetry data, in a defined method so data can be independently 
verified if desired.  We're looking at ASCII 110 baud, 8 data bits, 1 stop bit, 
as an easy-to implement method, but also are looking at DominoEX.  The problem 
with DominoEX is that it doesn't appear to allow 8-bit bytes.   We'd really like 
a method that supports 8-bit data bytes to ease the flight computer programming.  
We'd welcome any suggestions here.

Telemetry is going to be sent at regular intervals over HF during normal 
propagation.  Position-only data will be sent via satellite at all times to 
ensure ATC knows where we are at all times.  After propagation dropouts, 
however, all the backlogged data will be sent in a CONTINUOUS BURST until caught 
up with realtime.  This will be commanded via satellite uplink.

There will likely be a tip-over cutdown, remotely commandable via satellite.

Ballast will be liquid alcohol, using an identical system to SNOX for the first 
SpeedBall or two, as we develop improvements to shed more than just 6lbs.

We'll be communicating with every ATC center we pass through via telephone for 
all phases of the flight.  This will be an intensive job, requiring a phone call 
at least once every 30 minutes, for 24-72 hours while over the ocean.  We would 
like some help on this if anyone is interested, so we can do this in shifts. 
Training would be provided, but pilots or ATC controllers are preferable.


Background on the names
SpeedBall will be the name of all our Jet Stream flights - a nod to the other 
trans-atlantic speeder, the Concorde.  It's ATC radio callsign was SpeedBird.  
The HighBall-1 latex flight this weekend is merely to get our launch crew some 
launch coordination experience, and our local ATC some comfort with us.  It's 
not going to go fast, so no SpeedBall name for it.  I know HighBall isn't very 
original, but it's a pretty typical latex flight anyway! 

Thanks,
Dan



*There is a private section of the wiki, but I'll tell you what's in there - 
service plan data that we had to sign an NDA to get from Orbcomm, passwords to 
websites like twitter, our personal members contact info, and our money records. 


-- 
You received this message because you are subscribed to the Google Groups 
"Atlantic_Halo" group.
To post to this group, send email to atlant...@googlegroups.com.
To unsubscribe from this group, send email to atlantic_hal...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/atlantic_halo?hl=en.