[Space] Audio

[Mikolaj Habryn]

The OpenTracker has no other source. It can only get time from GPS. As
for the Android, it's entirely up to us, since all the software we're
running is what Nils and Andrew have written. This should be
relatively straightforward to enforce, and if you look at the raw
sensor data that we got from the first launch, the GPS keeps giving us
a good time signal even when it zeros out the position when we cross
60,000 feet.

So, in short, time sync needs testing and maybe a little programming,
but it shouldn't be an issue.

m.

On Fri, Mar 19, 2010 at 9:07 PM, Christie Dudley <longobord at gmail.com> wrote:
> We're arguably "synchronized", but there's still a bit up in the air.  Does
> the OpenTracker get it's clock from the GPS or some other source?  Can we
> count on the android using it's (GPS synced?) clock or some other way of
> deciding exactly when to send?  I wouldn't want to have to bet all our data
> on that.  I suppose to deal with the sync problem we could test on site if
> they're talking over each other and just cycle one until they stop.
> Christie
> _______
> "We also briefly discussed having officers replaced by very small shell
> scripts." -- Noisebridge meeting notes 2008-06-17
>
> The outer bounds is only the beginning.
> http://www.flickr.com/photos/genriel/sets/72157623376093724/
>
>
> On Fri, Mar 19, 2010 at 10:59 AM, Mikolaj Habryn <dichro at rcpt.to> wrote:
>>
>> Both devices have GPSes. They're already synchronized* :) OT+ can be
>> configured to send at a particular interval, plus an offset (eg, every
>> minute, but offset by 30 seconds into the minute) - which implies to
>> me that it triggers sending at a particular time, not that it delays
>> for a specific amount of time, but we can test that fairly easily.
>>
>> m.
>>
>> *: except, possibly, for the bit above 60k feet - haven't checked to
>> see if we still get a reliable time signal when the position goes
>> wonky.
>>
>> On Fri, Mar 19, 2010 at 10:43 AM, Greg Stramback <grog at piratelabs.com>
>> wrote:
>> > Good point Nils.  It's kind of a shame we don't have the weight
>> > allowance
>> > that would allow for a centralized GPS based timing platform that could
>> > synchronize the clocks.  Eh, weight alone wouldn't be the problem
>> > anyways.
>> >  The expense is nothing to sneeze at.
>> > Besides, we're only using one device's data as a reference to compare
>> > the
>> > other with.  A reference packet every 4 mins will fit in nicely with the
>> > regular 30sec interval packet.
>> > -g-
>> >
>> > On Fri, Mar 19, 2010 at 8:51 AM, <nils at shkoo.com> wrote:
>> >>
>> >> I think it'll be tough to avoid them interfering with each other except
>> >> if
>> >> we have some kind of synchronization mechanism.
>> >>
>> >> I think that if we try to configure the clocks to be at the same rate,
>> >> we'll get pretty close but not exact. Then when they start interfering
>> >> with each other it will take longer for them to stop.
>> >>
>> >> I think the best thing to do would be to set the intervals as follows:
>> >>
>> >> opentracker: 31 seconds
>> >>
>> >> g1: 127 seconds
>> >>
>> >> Guestimating the transmit time as 1 second, that way they will only
>> >> line
>> >> up on the same second once every 3937 seconds, so most of the beacons
>> >> should be fine even if the timing isn't exact.
>> >>
>> >> If we tried to line them up on 30 seconds and it ended up with the
>> >> following intervals:
>> >>
>> >> opentracker: 30 seconds
>> >> g1: 30.1 seconds
>> >>
>> >> Then when they line up, they would transmit on the same second for 10
>> >> beacons in a row, so we could lose a whole 5 minutes of transmitted
>> >> data.
>> >>
>> >> Ideally, the thing to do would be to make them able to listen to telle
>> >> when the other is transmitting. I'm pretty sure the opentracker can do
>> >> collision avoidance of some sort, but the android code not so much
>> >> right
>> >> now.
>> >>
>> >> -nils
>> >>
>> >> On Thu, 18 Mar 2010, Albert Alexander wrote:
>> >>
>> >> > Sounds right to me, but I'll defer to Nils. I know they do not
>> >> > transmit
>> >> > simultaneously.
>> >> >
>> >> > On Thu, Mar 18, 2010 at 8:44 PM, Christie Dudley
>> >> > <longobord at gmail.com>wrote:
>> >> >
>> >> >> I think the idea we had was that they were each sending at the same
>> >> >> interval.  If they maintain even reasonably good clocks and aren't
>> >> >> aligned,
>> >> >> they shouldn't ever overlap.  I think their duty cycle is low enough
>> >> >> that
>> >> >> this wouldn't be a problem.
>> >> >>
>> >> >> (I'm assuming that you mean amateur radio, not an actual
>> >> >> walkie-talkie,
>> >> >> here?)
>> >> >>
>> >> >> Christie
>> >> >> _______
>> >> >> "We also briefly discussed having officers replaced by very small
>> >> >> shell
>> >> >> scripts." -- Noisebridge meeting notes 2008-06-17
>> >> >>
>> >> >> The outer bounds is only the beginning.
>> >> >> http://www.flickr.com/photos/genriel/sets/72157623376093724/
>> >> >>
>> >> >>
>> >> >> On Thu, Mar 18, 2010 at 6:24 PM, Albert Alexander <
>> >> >> albert.alexander at gmail.com> wrote:
>> >> >>
>> >> >>> Nope, they transmit at separate times. We could use a fet to switch
>> >> >>> sources but that's more parts and wires.
>> >> >>>
>> >> >>>
>> >> >>> On Thu, Mar 18, 2010 at 6:10 PM, Greg Stramback
>> >> >>> <grog at piratelabs.com>wrote:
>> >> >>>
>> >> >>>> I'm making the assumption that we're expecting a certain
>> >> >>>> percentage
>> >> >>>> of
>> >> >>>> garbled / unreadable packets due to two audio sources being
>> >> >>>> combined?
>> >> >>>>
>> >> >>>> -g-
>> >> >>>>
>> >> >>>> On Thu, Mar 18, 2010 at 5:56 PM, Albert Alexander <
>> >> >>>> albert.alexander at gmail.com> wrote:
>> >> >>>>
>> >> >>>>> The walkie-talkie is getting audio from two sources. I suggested
>> >> >>>>> using a
>> >> >>>>> splitter to combine the sources, but this will load down the
>> >> >>>>> output
>> >> >>>>> transistors unless we add two resistors in series before the
>> >> >>>>> splitter. 10k
>> >> >>>>> is fine. This will attenuate the current of each signal. We could
>> >> >>>>> use a
>> >> >>>>> summing amp if we want to avoid the attenuation, or we could just
>> >> >>>>> turn up
>> >> >>>>> the volume.
>> >> >>>>>
>> >> >>>>> Will test G1 audio out AC coupling tonight after 5moF
>> >> >>>>>
>> >> >>>>> _______________________________________________
>> >> >>>>> Space mailing list
>> >> >>>>> Space at lists.noisebridge.net
>> >> >>>>> https://www.noisebridge.net/mailman/listinfo/space
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Space mailing list
>> >> >>> Space at lists.noisebridge.net
>> >> >>> https://www.noisebridge.net/mailman/listinfo/space
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> _______________________________________________
>> >> Space mailing list
>> >> Space at lists.noisebridge.net
>> >> https://www.noisebridge.net/mailman/listinfo/space
>> >
>> >
>> > _______________________________________________
>> > Space mailing list
>> > Space at lists.noisebridge.net
>> > https://www.noisebridge.net/mailman/listinfo/space
>> >
>> >
>> _______________________________________________
>> Space mailing list
>> Space at lists.noisebridge.net
>> https://www.noisebridge.net/mailman/listinfo/space
>
>