[amsat-bb] Re: ARRISSat Reception 14.45 UTC
At 10:49 PM 4/11/2011 +0530, vu3...@amsatindia.org wrote: >Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from >http://spaceflight.nasa.gov looks like the crew is working on addressing the >issue, the last comment I heard is recharging the batteries ( Please excuse >if I am wrong J ). > > > >73's > >Nitin [VU3TYG] That's what I was thinking because someone should have heard it by now. Maybe in two months pass the time since it should launched, even though it was off there might have been a small drain on the batteries and now they're in a discharge state. KB7ADL ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Hi Phil, You are just forgetting. Remember that we needed it in a "pull" rather than "push" interface? That makes it easy to sync everything up. Low power mode works something like this (my memory isn't great either) When it is time to send a frame, the next data frame gets created and encoded. Then the Tx is turned on and bits start coming out. When the encoder is ready for the next frame, we don't send anymore and the encoder is fed fill characters. Since we know that the interleaver is still full, a timer is started to clear the interleaver. After the interleave is cleared, the Tx can be turned off. So, the actual Tx ON time depends upon the size of the frame but it is always ON at least ~30 seconds to have time to finish the voice announcements or SSTV on the FM downlink. This worked flawlessly in lab testing of the satellite including tests with significant fading of the BPSK link. 73, Tony AA2TX --- At 06:21 AM 4/12/2011, Phil Karn wrote: >In low power mode, the transmission is started clean >every time. A single telemetry data frame is only 256 >bytes so about 4 seconds of data. After the 1 frame, the >transmitter is left on until the interleaver is emptied. > >Â >Excellent. I don't think anybody ever told me >this. I'm glad somebody noticed the problem. >Â >Let's see...256 bytes is 2K bits. At rate 1/2, >that encodes to 4K channel symbols that take >4.096 sec to send, just as you said. > >The very first symbol of the frame hits the >modulator right away at T=0, but the last symbol >from the front of the frame won't come out until >about T = 16.384 sec, the interleaver span. > >4.096 sec after that (at T=20.48 sec elapsed >time) the last symbol from the end of the frame >emerges. So you take 20.48 sec, start to finish, >to transmit 2k bits of user data for an >effective data rate of 100 bps (vs 500 bps in >continuous mode). And that's only counting the time the transmitter is on. > >Does the transmitter then go off at 20.48 sec, >or does another frame start? Where does the 40-60 sec interval come from? > >During that 20.48 sec, 20,480 BPSK channel >symbols are sent. But only 4K of them actually >represent FEC-encoded user data; the other 16K >symbols represent known (i.e., idle flag) bits >and do not help decode the user data. > >10*log10(4096/20480) is about -7 dB. I.e., a >system that can operate at an Eb/No of about 5.5 >dB now requires an overall Eb/No of 12.5 dB. >That's about 3 dB worse than uncoded BPSK... > >On the other hand, it should still be somewhat >more fade-resistant than that... > >Other than the obvious use of block >interleaving, it is possible to improve the >efficiency of convolutional interleaving (and >coding) on short transmissions with "tail >biting". You arrange the encoded symbols in a >ring and walk around it once. Then you pick an >arbitrary point in the receive buffer to start >the Viterbi decoder, run it a few constraint >lengths to get it synchronized, and then run it >around the ring once to actually decode the >packet. The tail of the packet gets interleaved >with the head so you don't have to fill and >drain it with padding. It's actually just a way >to construct a block code (or interleaver) out of a convolutional structure. > >You see why I wanted a command to turn interleaving on and off? > > > > ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
> In low power mode, the transmission is started clean > every time. A single telemetry data frame is only 256 > bytes so about 4 seconds of data. After the 1 frame, the > transmitter is left on until the interleaver is emptied. > Excellent. I don't think anybody ever told me this. I'm glad somebody noticed the problem. Let's see...256 bytes is 2K bits. At rate 1/2, that encodes to 4K channel symbols that take 4.096 sec to send, just as you said. The very first symbol of the frame hits the modulator right away at T=0, but the last symbol from the front of the frame won't come out until about T = 16.384 sec, the interleaver span. 4.096 sec after that (at T=20.48 sec elapsed time) the last symbol from the end of the frame emerges. So you take 20.48 sec, start to finish, to transmit 2k bits of user data for an effective data rate of 100 bps (vs 500 bps in continuous mode). And that's only counting the time the transmitter is on. Does the transmitter then go off at 20.48 sec, or does another frame start? Where does the 40-60 sec interval come from? During that 20.48 sec, 20,480 BPSK channel symbols are sent. But only 4K of them actually represent FEC-encoded user data; the other 16K symbols represent known (i.e., idle flag) bits and do not help decode the user data. 10*log10(4096/20480) is about -7 dB. I.e., a system that can operate at an Eb/No of about 5.5 dB now requires an overall Eb/No of 12.5 dB. That's about 3 dB worse than uncoded BPSK... On the other hand, it should still be somewhat more fade-resistant than that... Other than the obvious use of block interleaving, it is possible to improve the efficiency of convolutional interleaving (and coding) on short transmissions with "tail biting". You arrange the encoded symbols in a ring and walk around it once. Then you pick an arbitrary point in the receive buffer to start the Viterbi decoder, run it a few constraint lengths to get it synchronized, and then run it around the ring once to actually decode the packet. The tail of the packet gets interleaved with the head so you don't have to fill and drain it with padding. It's actually just a way to construct a block code (or interleaver) out of a convolutional structure. You see why I wanted a command to turn interleaving on and off? ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
At 02:50 AM 4/12/2011, Phil Karn wrote: >To elaborate: >... >As I recall, ARISSat-1 data frames can be up to 512 bytes long. Ignoring >HDLC flags, bit stuffing, CRC, etc, that's 4K bits. At a data rate of 500 >bps (the FEC is rate 1/2), 512 bytes will take 4096/500 = 8.192 seconds to >transmit. > >8.192 seconds is longer than 7.232 seconds. > >Ooops. > >But wait, there's more. If the satellite sends a series of back-to-back 512 >byte frames, and the transmitter comes on too late after one has already >started, you'll have to wait for it to end before you can begin decoding the >next one. Meanwhile, the clock is quickly ticking down until the transmitter >goes OFF again... > >Double oops. Hi Phil, That's why it doesn't work that way. In low power mode, the transmission is started clean every time. A single telemetry data frame is only 256 bytes so about 4 seconds of data. After the 1 frame, the transmitter is left on until the interleaver is emptied. 73, Tony AA2TX ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
To elaborate: BPSK-1000 uses "convolutional interleaving" with a depth of 16,384 symbols. The symbol rate is 1 kHz (1,000 symbols/sec) so it takes 16.384 seconds for a data symbol to pass through both the transmit and receive interleave buffers. The transmitter delay changes a lot from one symbol to the next, but every symbol experiences the same *total* (transmitter + receiver) delay: 16,384 symbol times or 16.384 seconds. The idea of any interleaver is to chop up (short) fades and spread them out in time so that they can be easily corrected by the Viterbi error correction algorithm (which deals well with random thermal noise but not with burst errors). The usual rule of thumb is that an interleaver can easily handle a complete fade lasting up to 10% of its length, as long as you give it time to recover between fades. That would be 1.6 seconds, which seemed plenty long for a continuously transmitting LEO spacecraft on 2 meters. Of course, you pay a price in delay -- there's no way around it. I have Sirius Satellite Radio in my car, and it always cuts out 4 seconds *after* I drive into the parking garage at work. It doesn't come back until (at least) 4 seconds *after* I drive out and it sees the satellite(s) again. The reason is exactly the same -- an interleaver that takes care of brief fades but not the really long ones caused by driving into a parking garage. I chose convolutional interleaving for BPSK-1000 because it has half the delay of block interleaving for the same fade performance. Convolutional interleavers also operate continuously, a good match to ARISSat-1's continuous transmitter. At AOS, your deinterleaver is still full of noise received earlier; it takes 16.384 seconds to flush it all out and feed "solid" data to the decoder. During that time, it ramps from pure noise to pure signal, and at some point it starts correcting what it sees. Depending on how strong the signal is, that may happen before the flushing is complete. I.e., it might reconstruct some of the missing symbols sent before your AOS. Similarly there is a slow ramp from solid signal down to pure noise over 16.384 seconds at LOS. See how this helps handle fading? Even an abrupt, complete fade starts the same, slow 16-second ramp down from signal to noise. If the fade ends only a second or two later, the rampdown won't have progressed very far and the decoder will still see mostly signal when the trend reverses and ramps back up to pure signal. That takes a few extra seconds, but the error correction can easily handle it all -- as long as the fade isn't *too* long. Interleaving takes a signal that may be solid one moment and gone the next and smooths it out so that the signal-to-noise ratio changes only slowly. It literally averages the signal-to-noise ratio. Since even a short LEO pass is usually several minutes long, these 16 second fill/drain intervals didn't seem like a big deal. Besides, we've already had a similar problem since the old days of the uncoded Phase III block telemetry format. You might have AOS in the middle of a frame and have to wait for the next one to start before you can decode anything. Interleaving isn't really any worse. The problem is that I didn't count on having the transmitter turned on for only 40-60 seconds at a time. Soif the transmissions are only 40 sec, and if you have to wait 16.384 seconds for the interleaver to fill, and you can't rely on the last 16.384 seconds as the interleaver drains, that leaves 40 - 2*16.384 = 7.232 seconds of solid, noise-free "middle" to work with. As I recall, ARISSat-1 data frames can be up to 512 bytes long. Ignoring HDLC flags, bit stuffing, CRC, etc, that's 4K bits. At a data rate of 500 bps (the FEC is rate 1/2), 512 bytes will take 4096/500 = 8.192 seconds to transmit. 8.192 seconds is longer than 7.232 seconds. Ooops. But wait, there's more. If the satellite sends a series of back-to-back 512 byte frames, and the transmitter comes on too late after one has already started, you'll have to wait for it to end before you can begin decoding the next one. Meanwhile, the clock is quickly ticking down until the transmitter goes OFF again... Double oops. Now this probably overstates the problem a bit. Being the engineer that I am, this is a very conservative analysis -- I made the most pessimistic assumption at each step. After all, I was stunned when somebody streamed BPSK-1000 over the net with a lossy MP3 encoder and it *decoded*; I never thought that would work. Error correction can fill in for a remarkable variety of ills. In reality, the satellite won't send a continuous stream of 512 byte frames. In reality, the key-down intervals may be more than 40 seconds. So I actually won't be too terribly surprised if the thing actually works. But it won't perform anything like it will when the satellite is eventually operated in its intended 100% duty cycle mode. ___ Sent via AMSAT-BB@amsat.org. Opinions
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Well its 421 am they will be awake around 0600 am utc.. 2 hours from now, then we will see if they flippa da switcha Kf1buz -Original Message- From: amsat-bb-boun...@amsat.org [mailto:amsat-bb-boun...@amsat.org] On Behalf Of Phil Karn Sent: Monday, April 11, 2011 8:59 PM To: Joe Fitzgerald Cc: amsat-bb@amsat.org Subject: [amsat-bb] Re: ARRISSat Reception 14.45 UTC On Mon, Apr 11, 2011 at 5:47 PM, Joe Fitzgerald wrote: > > I am curious to see how your BPSK1000 fares on a rapidly tumbling > platform. Let's hope ISS doesn't start tumbling more than once per orbit! > It's a pretty sensitive mode, but it still won't work with a zero-watt transmitter. > > If you do convince them to leave the ISS powered up on board ISS, we > could evaluate rapit deep fades in the channel by putting middle > school students in charge of holding an arrow antenna. > > My concern is that the on/off cycling won't play well with my convolutional interleaver. It takes 16.384 seconds to fill the interleaver at AOS. You might get decoded data up to 8 seconds earlier than that if what you do get is very clean, but there's little margin for additional error correction. And when the transmitter switches off, the interleaver will drain over 16.384 seconds as it fills with noise. If the signal in the last 16.384 seconds before switch-off is unusually strong, you may be able to decode data up to 8 seconds before LOS. But anywhere from 8 to 16 seconds will be chopped off *each end* of each already very short 40-60 second transmission. I designed this signal to deal well with occasional deep fades lasting up to 1-1.5 seconds -- not for total "fades" lasting 2 minutes at a time. Had I known that this "emergency low power mode" was actually going to be used, I would have designed the whole mode completely differently, with block interleaving aligned to the transmit on/off times. The golden rule of the modem designer: "know your channel". Optimizing for one impairment usually pessimizes it for something else. ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
On Mon, Apr 11, 2011 at 5:47 PM, Joe Fitzgerald wrote: > > I am curious to see how your BPSK1000 fares on a rapidly tumbling > platform. Let's hope ISS doesn't start tumbling more than once per orbit! > It's a pretty sensitive mode, but it still won't work with a zero-watt transmitter. > > If you do convince them to leave the ISS powered up on board ISS, we > could evaluate rapit deep fades in the channel by putting middle school > students in charge of holding an arrow antenna. > > My concern is that the on/off cycling won't play well with my convolutional interleaver. It takes 16.384 seconds to fill the interleaver at AOS. You might get decoded data up to 8 seconds earlier than that if what you do get is very clean, but there's little margin for additional error correction. And when the transmitter switches off, the interleaver will drain over 16.384 seconds as it fills with noise. If the signal in the last 16.384 seconds before switch-off is unusually strong, you may be able to decode data up to 8 seconds before LOS. But anywhere from 8 to 16 seconds will be chopped off *each end* of each already very short 40-60 second transmission. I designed this signal to deal well with occasional deep fades lasting up to 1-1.5 seconds -- not for total "fades" lasting 2 minutes at a time. Had I known that this "emergency low power mode" was actually going to be used, I would have designed the whole mode completely differently, with block interleaving aligned to the transmit on/off times. The golden rule of the modem designer: "know your channel". Optimizing for one impairment usually pessimizes it for something else. ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
On 4/11/2011 1:44 PM, Phil Karn wrote: > Since it's already connected to the station antenna, it sure would be nice > if they could just plug it directly into the ISS power supply, switch it on > full duty cycle, and just *leave* it for a couple of, oh, years. Phil, I am curious to see how your BPSK1000 fares on a rapidly tumbling platform. Let's hope ISS doesn't start tumbling more than once per orbit! If you do convince them to leave the ISS powered up on board ISS, we could evaluate rapit deep fades in the channel by putting middle school students in charge of holding an arrow antenna. -Joe KM1P ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Not wanting to be a naysayer, but this was discussed a few weeks ago on Amsat-bb with the word from the mission staff that no external power connection was provided. In other words it runs on solar-charged batteries. Of course, we know they had some sort of "bench power connection" for testing. I hope the "folks" on the ISS are good technicians and can "rig up" something. There was a concern the batteries might drop off in storage until this summer when the "Main Show" is to happen. Of course maybe they can "duck tape" it outside and let it run on the panels/batteries? OK that was in jest (humor). I only have operational is a 2m Lindenblad CP omni directional antenna that is probably not good enough to hear ARISSat when down at the horizon and at max range. Just luck that my 2m-eme system is out of commission at present else I would had a excellent receiver. GL and 73's Ed - KL7UW At 09:19 AM 4/11/2011, Nitin Muttin wrote: >Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from >http://spaceflight.nasa.gov looks like the crew is working on addressing the >issue, the last comment I heard is recharging the batteries ( Please excuse >if I am wrong J ). > > > >73's > >Nitin [VU3TYG] > > > >From: Nitin Muttin [mailto:vu3...@amsatindia.org] >Sent: Monday, April 11, 2011 8:24 PM >To: 'amsat-bb@amsat.org' >Cc: 'amsatin...@yahoogroups.com' >Subject: ARRISSat Reception 14.45 UTC > > > >All, > > > >Nothing heard from the ARRISSat-1 on 145.950 / 437.550 and 145.919 during >the 14.42 UTC pass over India. > > > >73's > >Nitin [VU3TYG] > > _ > >No virus found in this message. >Checked by AVG - www.avg.com >Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > > _ > >No virus found in this message. >Checked by AVG - www.avg.com >Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > >___ >Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. >Not an AMSAT-NA member? Join now to support the amateur satellite program! >Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb 73, Ed - KL7UW, WD2XSH/45 == BP40IQ 500 KHz - 10-GHz www.kl7uw.com EME: 144-1.4kw, 432-100w, 1296-testing*, 3400-winter? DUBUS Magazine USA Rep dubus...@hotmail.com == ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Something fun and completely different to listen to while waiting for Arissat-1!! http://www.nasa.gov/multimedia/videogallery/index.html?media_id=79119001 73, Mark N8MH On Mon, Apr 11, 2011 at 1:19 PM, Nitin Muttin wrote: > Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from > http://spaceflight.nasa.gov looks like the crew is working on addressing the > issue, the last comment I heard is recharging the batteries ( Please excuse > if I am wrong J ). > > > > 73's > > Nitin [VU3TYG] > > > > From: Nitin Muttin [mailto:vu3...@amsatindia.org] > Sent: Monday, April 11, 2011 8:24 PM > To: 'amsat-bb@amsat.org' > Cc: 'amsatin...@yahoogroups.com' > Subject: ARRISSat Reception 14.45 UTC > > > > All, > > > > Nothing heard from the ARRISSat-1 on 145.950 / 437.550 and 145.919 during > the 14.42 UTC pass over India. > > > > 73's > > Nitin [VU3TYG] > > _ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > > _ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > > ___ > Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. > Not an AMSAT-NA member? Join now to support the amateur satellite program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb > -- Mark L. Hammond [N8MH] ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
I am sure it should be if there is an external capability available on the ARRISSat to recharge the batteries and looking at the the live video from ISS (NASA TV) looks like the crew is trying on the same, retiring for the night now and will listen tomorrow at 18.37 UTC 81 degree pass . Appreciate all the efforts from the crew on the ISS to get this going and the ARRISSat-1 Project team who I am sure are working closely to make this happen. 73's Nitin [VU3TYG] From: Rocky Jones [mailto:orbit...@hotmail.com] Sent: Monday, April 11, 2011 11:50 PM To: k...@ka9q.net; vu3...@amsatindia.org Cc: Amsat BB Subject: RE: [amsat-bb] Re: ARRISSat Reception 14.45 UTC You would think that this would be possible...Robert G. Oler WB5MZO life member AMSAT ARRL NARL > From: k...@philkarn.net > Date: Mon, 11 Apr 2011 10:44:44 -0700 > To: vu3...@amsatindia.org > CC: amsat-bb@amsat.org > Subject: [amsat-bb] Re: ARRISSat Reception 14.45 UTC > > Since it's already connected to the station antenna, it sure would be nice > if they could just plug it directly into the ISS power supply, switch it on > full duty cycle, and just *leave* it for a couple of, oh, years. > ___ > Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. > Not an AMSAT-NA member? Join now to support the amateur satellite program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
*Nothing heard at 145.950 MHZ 18:20 till 18:34 UTC * * * *KM73UV* * * *Riri OD5RI * On Mon, Apr 11, 2011 at 9:16 PM, Alan P. Biddle wrote: > No pressure with everybody looking over your shoulder. ;) > > Alan > WA4SCA > > > > -Original Message- > From: amsat-bb-boun...@amsat.org [mailto:amsat-bb-boun...@amsat.org] On > Behalf Of Nitin Muttin > Sent: Monday, April 11, 2011 12:19 PM > To: 'Nitin Muttin'; amsat-bb@amsat.org > Cc: amsatin...@yahoogroups.com > Subject: [amsat-bb] Re: ARRISSat Reception 14.45 UTC > > Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from > http://spaceflight.nasa.gov looks like the crew is working on addressing > the > issue, the last comment I heard is recharging the batteries ( Please excuse > if I am wrong J ). > > > > 73's > > Nitin [VU3TYG] > > > > From: Nitin Muttin [mailto:vu3...@amsatindia.org] > Sent: Monday, April 11, 2011 8:24 PM > To: 'amsat-bb@amsat.org' > Cc: 'amsatin...@yahoogroups.com' > Subject: ARRISSat Reception 14.45 UTC > > > > All, > > > > Nothing heard from the ARRISSat-1 on 145.950 / 437.550 and 145.919 during > the 14.42 UTC pass over India. > > > > 73's > > Nitin [VU3TYG] > > _ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > > _ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 > > ___ > Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. > Not an AMSAT-NA member? Join now to support the amateur satellite program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb > > > ___ > Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. > Not an AMSAT-NA member? Join now to support the amateur satellite program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb > -- * * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * *IN GOD WE TRUST ALL OTHERS WE MONITOR* * Intruder Watch System* *Skype:OD5RIRI* * Track me: http://ri.od5.org Lebanon Amateur Radio Station RIRI - OD5RI* ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
No pressure with everybody looking over your shoulder. ;) Alan WA4SCA -Original Message- From: amsat-bb-boun...@amsat.org [mailto:amsat-bb-boun...@amsat.org] On Behalf Of Nitin Muttin Sent: Monday, April 11, 2011 12:19 PM To: 'Nitin Muttin'; amsat-bb@amsat.org Cc: amsatin...@yahoogroups.com Subject: [amsat-bb] Re: ARRISSat Reception 14.45 UTC Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from http://spaceflight.nasa.gov looks like the crew is working on addressing the issue, the last comment I heard is recharging the batteries ( Please excuse if I am wrong J ). 73's Nitin [VU3TYG] From: Nitin Muttin [mailto:vu3...@amsatindia.org] Sent: Monday, April 11, 2011 8:24 PM To: 'amsat-bb@amsat.org' Cc: 'amsatin...@yahoogroups.com' Subject: ARRISSat Reception 14.45 UTC All, Nothing heard from the ARRISSat-1 on 145.950 / 437.550 and 145.919 during the 14.42 UTC pass over India. 73's Nitin [VU3TYG] _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Since it's already connected to the station antenna, it sure would be nice if they could just plug it directly into the ISS power supply, switch it on full duty cycle, and just *leave* it for a couple of, oh, years. ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
[amsat-bb] Re: ARRISSat Reception 14.45 UTC
Nothing heard on the 16.20 UTC pass, watch the live feed from ISS from http://spaceflight.nasa.gov looks like the crew is working on addressing the issue, the last comment I heard is recharging the batteries ( Please excuse if I am wrong J ). 73's Nitin [VU3TYG] From: Nitin Muttin [mailto:vu3...@amsatindia.org] Sent: Monday, April 11, 2011 8:24 PM To: 'amsat-bb@amsat.org' Cc: 'amsatin...@yahoogroups.com' Subject: ARRISSat Reception 14.45 UTC All, Nothing heard from the ARRISSat-1 on 145.950 / 437.550 and 145.919 during the 14.42 UTC pass over India. 73's Nitin [VU3TYG] _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3564 - Release Date: 04/10/11 ___ Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
