<div dir="auto">Carl, <div dir="auto">I asked one of my old-time DFW Makers who taught HAM classes for us & he suggests starting here <a href="https://www.aredn.org">https://www.aredn.org</a></div><div dir="auto">for packet radio and mesh networking over ham frequencies.</div><div dir="auto">~Mary</div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 13, 2018 1:26 PM, "Carl Ott via DPRGlist" <<a href="mailto:dprglist@lists.dprg.org">dprglist@lists.dprg.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks to everybody who came to RoboRama yesterday - it seems that everybody had a good time, we met new visitors & old friends, and we had a well received contest!<div><br></div><div>We also had Wi-Fi issues - leading to questions...</div><div><br></div><div>Can anybody offer suggestions for the Wi-Fi issue some of us observed yesterday?</div><div><br></div><div>The issue was that as the day went on, and more people surfaced in the Makerspace, the Wi-Fi environment went from almost tolerable to ***difficult for some - won't work at all for others***.</div><div><br></div><div>This forced several of us to use personal access points - which definitely helped - at least for those using the connection more for telemetry than 'in the loop communication'.  However, I was not able to run at all due to apparently tight latency/jitter requirements, which became unmet as the makerspace filled up.  This becomes apparent for my robot when one video stream receiver (whatever Chrome uses) behaves much better and more consistently as the environment degrades (still ultimately failing), but another codec viewing the same stream (ffmpeg + whatever plug-in adapter RoboRealm uses for RTSP) fails much sooner - 'at the drop of a hat / network-packet' - completely breaking my control loop, yielding grumpy scowls and a very still and boring robot...</div><div><br></div><div>My question is this - what options should I consider beyond the obvious?</div><div><br></div><div><b>The obvious options are</b></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>a) keep processing local, get the network out of the loop</div><div><br></div><div>b) flip the personal access point an unused Wi-Fi channel</div><div>---> e.g. on 5 GHz</div><div>---> ie. requiring adding a 5 GHz dongle to R-Pi Zero W (depends on finding one with compatible driver)</div><div>---> or requiring swapping R-Pi Zero for e.g.R-Pi 3 B+ (with built-in 5 GHz, entails considerably more hardware rework to existing robot platform)</div><div><br></div><div>c) find an alternate radio strategy</div><div><br></div><div>d) give up</div></blockquote><div><br></div><div>Currently, options a and d are off the table, and next steps focus on option b.</div><div><br></div><div><b>So my questions for DPRG land:</b></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><b>1. for option b:</b> can anybody recommend an R-Pi Zero W compatible Wi-Fi dongle with 5 GHz?   If no better out there, I'm gonna try an older / slightly larger version of this: <a href="https://www.amazon.com/gp/product/B01MY7PL10/ref=ox_sc_mini_detail?ie=UTF8&psc=1&smid=ATVPDKIKX0DER" target="_blank" rel="noreferrer">https://www.amazon.com/gp/product/B01MY7PL10/ref=ox_sc_mini_detail?ie=UTF8&psc=1&smid=ATVPDKIKX0DER</a>, with what appears to be a R-Pi compatible open source driver recommended by the vendor...</div><div><br></div><div><b>2. 

</b><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><b>for option c:</b><span style="font-weight:400"> </span></span>

can anybody recommend something small other than Wi-Fi that can carry low jitter / low latency /

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>low video resolution (e.g. 160 x 120)</span>  network packets, and interface cleanly to both R-Pi Zero and Windows?</div><div><br></div><div><b>3. 

</b><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><b>for option c:</b><span style="font-weight:400"> </span></span>

has anybody dabbled with network packet data over HAM frequencies?</div></blockquote><div><br></div><div>Thanks!</div><div><br></div><div>Carl</div><div><br></div><div><a href="mailto:carl.ott.jr@gmail.com" target="_blank" rel="noreferrer">carl.ott.jr@gmail.com</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank" rel="noreferrer">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div><br></div>