<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 7/30/18 20:46, Gary E. Miller via devel wrote:<br>
<blockquote type="cite"
cite="mid:20180730204625.41bc3a6a@spidey.rellim.com">We found a
lot of people that wanted a cheap stratum 1 had not clue
<pre class="moz-quote-pre" wrap="">how to get a RasPi to work. Thus the completer instructions.
</pre>
</blockquote>
...<br>
<blockquote type="cite"
cite="mid:20180730204625.41bc3a6a@spidey.rellim.com">
<pre class="moz-quote-pre" wrap="">Please do. Especialy with a fresh eye. We dont know what newbies
don't know.
</pre>
</blockquote>
...<br>
<blockquote type="cite"
cite="mid:20180730204625.41bc3a6a@spidey.rellim.com">
<pre class="moz-quote-pre" wrap="">I like to think of that as the engineering and software worlds, but
some people that need a Stratum-1 are not of our world(s).
</pre>
</blockquote>
So, I've spent a pretty fair bit of time poring over the stratum one
howto off and on over the last year, have pushed a lot of fixes,
changes, suggestions to ESR who kindly reviews and publishes as time
permits.<br>
<br>
Overall though, the howto is in need of TLC. As it stands, it's in a
sort of a stream-of-consciousness form - understandably so, writing
a very thorough howto as you go along the process yourself winds up
that way, been down that road many times.<br>
<br>
As I look at it, I think it needs some bigger changes, that require
some web development expertise (and I only have the barest of web
development skills - I edit everything in emacs!). <br>
<br>
1. It needs a linked table of contents at the top. It's really easy
to lose your way, because the content digresses to address many
variances in the build process. Maybe that's not a 'big' thing, but
more of an organizational nicenety.<br>
<br>
2. I think the whole document needs branching - breaking it into
multiple sub-pages, with the ability to self-direct to the next
appropriate section.<br>
<br>
For example, I think it should have a specific Hardware
page/subpages, for each of our 'known' GPS boards, and SBC's.
Dealing with pinouts, traces, etc etc etc. Sort out the physical
aspects into their own 'realm' within the overall schema.<br>
<br>
Simplify the micro sd image creation process. I ran across a lovely
application - <a class="moz-txt-link-freetext" href="https://etcher.io/">https://etcher.io/</a> - that makes it drop dead simple to
create your micro-sd on the linux desktop, windows, macOS. Obviously
CLI needs its own specific instructions - which belong on a separate
page, for the more courageous/inquisitive users.<br>
<br>
Then separate pages for the software builds - a GPSD page, top to
bottom, an NTPD page, top to bottom, then both pages dovetailing to
the pages for the integration process.<br>
<br>
Then at the bottom the tweaking/performance tuning/FAQs. For
example, rather early in the howto is a section 'optimize system
performance', which is absolutely useful, but doesn't need to be
detailed so early in the process. Tweak that governor *after* you've
got the howto completed. Likewise, the 'Adequate power is important'
section is near the very end - but it really belongs up in the
hardware section, so people start out right.<br>
<br>
As you can see, I'm full of suggestions - that's the easy part!
Implementation is a whole nuther can of bits, which largely hinges
on finding the spare time and resources, which are always in high
demand and short supply. Myself, I'm more of a
grammar/syntax/readability realm, which is where most of my
contributions have been. One thing I am always happy to do is act as
a proofreader, anyone is welcome to throw changes at my inbox for
vetting....<br>
<br>
<pre class="moz-signature" cols="72">--
Paul Theodoropoulos
<a class="moz-txt-link-abbreviated" href="http://www.anastrophe.com">www.anastrophe.com</a></pre>
</body>
</html>