I can indeed see your point on the overlap time, Nils. It was my understanding that the clocks in all these things could only be off by microseconds, at best. Nevertheless, your scheme makes a lot of sense, as it alleviates the need to coordinate start times. Not to mention, that includes very little accounting for odd behavior with the cold conditions. And if clocks are off by microseconds and there is interference, we could get only garbage out the entire flight.<div>
<br></div><div>Christie<br><div>_______<br>"We also briefly discussed having officers replaced by very small shell scripts." -- Noisebridge meeting notes 2008-06-17<br><br>The outer bounds is only the beginning. <a href="http://www.flickr.com/photos/genriel/sets/72157623376093724/">http://www.flickr.com/photos/genriel/sets/72157623376093724/</a><br>
<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 8:51 AM, <span dir="ltr"><<a href="mailto:nils@shkoo.com">nils@shkoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I think it'll be tough to avoid them interfering with each other except if we have some kind of synchronization mechanism.<br>
<br>
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.<br>
<br>
I think the best thing to do would be to set the intervals as follows:<br>
<br>
opentracker: 31 seconds<br>
<br>
g1: 127 seconds<br>
<br>
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.<br>
<br>
If we tried to line them up on 30 seconds and it ended up with the following intervals:<br>
<br>
opentracker: 30 seconds<br>
g1: 30.1 seconds<br>
<br>
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.<br>
<br>
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.<br>
<br>
-nils<div><div></div><div class="h5"><br>
<br>
On Thu, 18 Mar 2010, Albert Alexander wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sounds right to me, but I'll defer to Nils. I know they do not transmit<br>
simultaneously.<br>
<br>
On Thu, Mar 18, 2010 at 8:44 PM, Christie Dudley <<a href="mailto:longobord@gmail.com" target="_blank">longobord@gmail.com</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the idea we had was that they were each sending at the same<br>
interval. If they maintain even reasonably good clocks and aren't aligned,<br>
they shouldn't ever overlap. I think their duty cycle is low enough that<br>
this wouldn't be a problem.<br>
<br>
(I'm assuming that you mean amateur radio, not an actual walkie-talkie,<br>
here?)<br>
<br>
Christie<br>
_______<br>
"We also briefly discussed having officers replaced by very small shell<br>
scripts." -- Noisebridge meeting notes 2008-06-17<br>
<br>
The outer bounds is only the beginning.<br>
<a href="http://www.flickr.com/photos/genriel/sets/72157623376093724/" target="_blank">http://www.flickr.com/photos/genriel/sets/72157623376093724/</a><br>
<br>
<br>
On Thu, Mar 18, 2010 at 6:24 PM, Albert Alexander <<br>
<a href="mailto:albert.alexander@gmail.com" target="_blank">albert.alexander@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nope, they transmit at separate times. We could use a fet to switch<br>
sources but that's more parts and wires.<br>
<br>
<br>
On Thu, Mar 18, 2010 at 6:10 PM, Greg Stramback <<a href="mailto:grog@piratelabs.com" target="_blank">grog@piratelabs.com</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm making the assumption that we're expecting a certain percentage of<br>
garbled / unreadable packets due to two audio sources being combined?<br>
<br>
-g-<br>
<br>
On Thu, Mar 18, 2010 at 5:56 PM, Albert Alexander <<br>
<a href="mailto:albert.alexander@gmail.com" target="_blank">albert.alexander@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The walkie-talkie is getting audio from two sources. I suggested using a<br>
splitter to combine the sources, but this will load down the output<br>
transistors unless we add two resistors in series before the splitter. 10k<br>
is fine. This will attenuate the current of each signal. We could use a<br>
summing amp if we want to avoid the attenuation, or we could just turn up<br>
the volume.<br>
<br>
Will test G1 audio out AC coupling tonight after 5moF<br>
<br>
_______________________________________________<br>
Space mailing list<br>
<a href="mailto:Space@lists.noisebridge.net" target="_blank">Space@lists.noisebridge.net</a><br>
<a href="https://www.noisebridge.net/mailman/listinfo/space" target="_blank">https://www.noisebridge.net/mailman/listinfo/space</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________<br>
Space mailing list<br>
<a href="mailto:Space@lists.noisebridge.net" target="_blank">Space@lists.noisebridge.net</a><br>
<a href="https://www.noisebridge.net/mailman/listinfo/space" target="_blank">https://www.noisebridge.net/mailman/listinfo/space</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>