[aprssig] Dual-use on APRS A/D channels

[Lynn W Deffenbaugh (Mr)]

Ok, that's a cool hack for a web-based display service, but how is that 
communicated to lowly APRS client applications that receive the 
telemetry and (hopefully) the specified parameter definitions?  Such 
APRS-using, telemetry-observing applications would have absolutely no 
indication that the 2nd value of the 5 actually has dual definitions 
depending on some knowledge (the "pivot" value of 500 coded into the URL 
in this case) that is completely outside the communications bandwidth 
from the station.  Not to mention the fact that different a, b, and c 
parameters should be applied depending on that very unknown value.

So this doesn't so much provide for a generic dual-use of APRS telemetry 
channels, but allows for an end-user customized view of APRS telemetry 
using out-of-band knowledge which can be communicated to a custom 
telemetry viewer at findu.com.

Or is there something I missed in Bob's description and example?  Like 
maybe a new telemetry definitions packet that describes the ranges and 
alternate equations to use?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32



On 5/7/2020 12:53 PM, Robert Bruninga wrote:
> Steve Dimse has now made it possible for you to make your 5 channels of APRS
> telemetry dual use (up to 10 channels (or more)) and FINDU will properly
> graph the two (or more) different uses of each channel.
>
> I did this on PSAT3 because the current sensor always outputs a positive
> count between 000-999 but changes a digital bit to show if it is positive or
> negative (Charging or discharging).  So I put in a transistor switch on that
> bit and used it to shift the analog output to be 000-500 for load current
> and 500 to 999 for charge current.  And now I can get separate plots for
> each on FINDU.com.
>
> Thus, by using a toggle on all 5 channels, you could extend your APRS
> Telemetry from 5 sensors to ten and still have at least 0.2% accuracy.
>
> Here is the example of the raw data where values below 500 are to be
> interpreted with one equation (load current) and values above 500 are to be
> for charge current and use a different equation...:
>
> http://www1.findu.com/cgi-bin/tele1.cgi?call=psat3,psat3-1&last=36&param=2&b=1&c=0&label=Current&units=Milliamps&autorange=1
>
> When I add "&below=500" to the URLand  use the right equation,  you get the
> bottom LOAD data for values below 500:
> http://www1.findu.com/cgi-bin/tele1.cgi?call=psat3,psat3-1&last=36&param=2&b=1.67&c=-22.5&label=Load%20(only%20bottom%20points)&units=Milliamps&autorange=1&below=500
>
> When I add "&below=-500" (with a minus) to the URL and the right equation
> for this situation, then I get the data points for above 500.
> http://www1.findu.com/cgi-bin/tele1.cgi?call=psat3,psat3-1&last=36&param=2&b=1.635&c=-776&label=Charge%20(only%20top%20points)&units=Milliamps&autorange=1&below=-500
>
> The use of a minus sign to switch "below" to "above" was apparently easier
> to implement than adding a whole new CGI just for "above".
>
> The above plots are on the http://aprs.org/psat3.html  telemetry.
>
> A good example of such use might be the monitoring a battery voltage (that
> rarely changes much) so say it uses values from 000 to 999 to represent
> voltage from 000 to 9.99 volts but never goes below say 6 volts when the
> battry is fully discharged, then that same telemetry channel can also be
> used for another sensor that never goes above 600 by using the "&below=600"
> CGI parameter.
>
> You can see that you could also add a third sensor for example that never
> goes above 300 (or any other lesser value) by adding another plot using
> "&below=300" (as long as the below 600 sensor never goes below 300), etc
>
> Bob, Wb4APR
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org