[MVMA] Vandalia: I guess the single mesh node at that site.

William Curtice william.curtice at gmail.com
Wed Nov 28 23:44:17 EST 2018


Moe:

Perhaps that is why the question of "who is served" is important.

If Ken's link were moved to the Vandalia Tank,  DARA and Vandalia Tank 2.4
nodes would have 1 customer each.  I expect that operating them co-channel
with different SSIDs would yield performance at least as good as trying to
force both customers to connect with DARA 2.4, especially since the two
customers can't see each other, and we have a hidden transmitter situation
again.

Bill

William Curtice
937-287-0871
Please reply to: william.curtice at ieee.org

On Wed, Nov 28, 2018, 10:21 PM Moe <ab8xa at arrl.net wrote:

>
> On 11/28/18 9:46 PM, William Curtice wrote:
>
> Another approach might be to provide a 5GHz link between DARA and Vandalia
> tank,  disable the 2.4 link between Ken/AE8I and DARA, and enable Ken to
> take advantage of the 2.4 connectivity he has with Vandalia tank.
>
> SSID change could be done to route Ken through Vandalia to DARA (via
> 5.8)... but it would not stop the 2.4 RF from Vandalia from degrading
> signals received at DARA, i.e. from W8GUC. ...and vice versa for that
> matter.
>
> That would "open up" the Vandalia/Tipp City area, establish the Vandalia
> tank as a neighborhood flooding site, and do the same for  DARA as a Huber
> Heights neighborhood flooding site.
>
> If we could neighborhood flood with omnis that could not receive each
> other, that might work... i.e 2.4 omnis with so severe a value of down tilt
> that they wouldn't transmit toward the horizon... or more commonly, omnis
> on different bands.
>
> That should improve system access for both Reuben and Ken.  It would also
> set the stage for high speed 5.8 or 3.4 links to neighborhood flooding
> nodes in Englewood and Troy/Miami County.
>
> As long as there are two omnis there on the same channel, particularly
> with high-gain/no-downtilt antennas, they will interfere with each other,
> regardless of SSID. It helps, but isn't the cure.
>
>
> But  again, guess we need to ask .... why should we do it, who would it
> benefit, and who cares if we do it or not?
>
> The only 2.4 "flooding" that might work without interfering with DARA is a
> single sector panel not aimed at DARA.
>
>
>
> Bill
>
> William Curtice
> 937-287-0871
> Please reply to: william.curtice at ieee.org
>
> On Wed, Nov 28, 2018, 2:54 PM Moe <ab8xa at arrl.net wrote:
>
>> I think when Vandalia and Helke were deployed in hopes of improving links
>> to Tipp City north, it wasn't understood that as long as OLSR had a one hop
>> route direct to DARA those nodes would never be used as two-hops to DARA.
>> All they do is degrade DARA's LQ of W8GUC and AE8I. I have them in AREDN-V
>> SSID but their RF still impacts DARA.
>>
>> I can move them to Channel 5 at minimum power. They might even still be
>> able to link. That will keep a foot in the door at those sites (as opposed
>> to shutting them down remotely).
>>
>> Let me know if that's what you want to do.
>>
>> --
>> Moe
>>
>> 73 de AB8XA
>>
>>
>> On 11/28/18 9:19 AM, Chuck Gelm wrote:
>>
>> On 11/28/2018 08:58 AM, Reuben Meeks wrote:
>>
>> Chuck, we can start conversations, but I believe we await some one to
>> initiate a topic for discussion. As president of this group, please start
>> where the priorities are.
>>
>>
>> *I believe we either need to fix Vandalia, or give it up as a lost cause.
>> *
>>
>>
>> What say you Chuck?
>> Best Regards
>>
>>
>> Hi, Reuben:
>>
>>  The node at the Vandalia water tank is working fine.
>> I see nothing that needs to be 'fix'ed.
>>
>> I do see, however, that it serves nobody and, likely, interferes with the
>> AE8I, W8GUC, W8BI links.
>>
>> Shall we move the Vandalia-wt node to channel 5 and QRP?
>>
>> Shall we move the Helke Road node to channel 5 and QRP?
>>
>> Should we wish to use them in the future, someone could
>> drive near with a mesh node and a laptop or
>> visit Helke Road with a laptop
>> and reconfigure them.
>>
>> Chuck
>>
>>
>>
>>
>> _______________________________________________
>> MVMA mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/mvma
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:MVMA at mailman.qth.net <MVMA at mailman.qth.net>
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>
>>
>> _______________________________________________
>> MVMA mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/mvma
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:MVMA at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>
>
>
> _______________________________________________
> MVMA mailing list
> Home: http://mailman.qth.net/mailman/listinfo/mvma
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:MVMA at mailman.qth.net <MVMA at mailman.qth.net>
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>
>
> _______________________________________________
> MVMA mailing list
> Home: http://mailman.qth.net/mailman/listinfo/mvma
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:MVMA at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qth.net/pipermail/mvma/attachments/20181128/b6e4b73d/attachment.html>


More information about the MVMA mailing list