<div dir="ltr"><div><div><div dir="ltr">I haved ignored the 0-255 telemetry spec ever since Kantronics and other TNC's allowed 0-999 for over a decade.  The limit in the spec was simply to keep the field to 3 digits each and since up to 999 still fits Im just fine with that.<br></div><br></div>Not easy to chage SSID from an external circuit.  Whereas a simple 555 timer chip oronebit output from a processor can toggle back and forth the extra bank of inputs.  Anyway, just a useful kludge that is backwards compatible.  <br></div>Bob<br><br><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 4:35 PM spam8mybrain <<a href="mailto:spam8mybrain@yahoo.com">spam8mybrain@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Isn't that a violation of the original spec saying the values have to be in the range 0 to 255 (and be integers)? Or are you talking about the values after applying the quadratic coefficients? If so, you still only have one set of coefficients for the overloaded channel. 
    
<div><br></div><div>Wouldn't it be easier to use a second SSID value for the port, so you could transmit a completely separate set of values, coefficients, labels, etc., under the callsign and second SSID?</div><div><br></div><div>Alternatively, use the !DAO! encoded telemetry in the position report as independent of the original format telemetry message.</div><div><br></div><div>Just an idea.</div><div><br></div><div>Andrew, KA2DDO</div><br><br>-------- Original message --------<br>From: Robert Bruninga <<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</a>> <br>Date: 4/2/20  14:37  (GMT-05:00) <br>To: TAPR APRS Mailing List <<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a>> <br>Subject: [aprssig] Expanded APRS telemetry to 10 or 15 channels? <br><br><div dir="ltr"><div><div><div><div>Expanding APRS telemetry from 5 to ten, 15 or 20 channels and still remaining within the protocol...<br><br>On PSAT3, I needed 6 A/D inputs instead of the standard 5, so I used two inputs on channel 2.  If the count is above 500 then it means one thing, and if it is below 500 it means another.  On receipt, I can choose one telemetry equation or the other depending on the value above or below 500.<br><br></div>This means you could double the 5 channels to 10 if you used 500 as the dividing line.  Or you could have 15 channels if you restricted one input from 0 to 333 and the next between 333 and 666 and the last between 666 and 999.  You can make the transition points be anything that matches the resolution of your sensors, because the thresholds would be part of the decoding equation.  Even if you used four ranges, your precision (from 0-250) is still better than a half percent!<br><br></div>Wow, I wish I had thought of this on my earlier PSATs. Having ten or 15 channels of A/D telemetry while still using the standard APRS protocol would have been useful.<br><br></div>On the sensor side, you simply switch in bias resistors on each of the two, three, or four sensors per input channel.  Think of it as bank switching the 5 channels...<br><br></div><div>If anyone has use for this trick, let me know.  Steve Dimse is looking at building it into FINDU for trivial plotting... if/when he finds he time...<br><br></div>bob<br></div>
</div></blockquote></div></div></div></div>