Standardize ADC Scaling

[kb1lqc]

It's unclear if we should keep ADC data unscaled so scaling can be applied later or if we should always scale to volts at the ADC pin using the internal voltage reference.

Pros:

• Simple and easy to convert from volts to engineering units
• Standardizes on ADC configuration as-built hardware.

Cons:

• If anyone uses an external reference things get tricky i.e. they become special snowflakes on the entire system unless we proactively account for this.
• Possibly requiring two conversions to account for standardized scaling. First from ADC volts with on-board reference into ADC bits and secondly from ADC bits into volts using external reference voltage.

It might be better to just assume everyone uses the internal voltage reference and perform the two scaling required to get to another voltage reference. These stations should be far and few between which means they will not be common. This allows more plug and play operation with the ADC functionality.

[kb1lqd]

I vote for default scaling to internal reference, if you're switch to external references you know what you're doing and we can also jump that bridge when it get's here. Let's do easy/simple/clean versus bloating for the 0.1% use cases.

[kb1lqc]

OK I agree for the most part. However we do want to make sure we make it not too painful to use a different voltage scaling than the internal CC430 2.41V reference. We are open source and we should expect someone down the line to put a 4.096V design online.

I don't want to bend over backwards right now for this @kb1lqd but is there any way we can approach this differently and achieve a flexible result?

[kb1lqd]

@kb1lqc I believe the proper way to handle this situation is to use APRS's formating/scaling like telemetry frames (and like other telemetry protocols out there) that send a frame with scaling data. This could be middle-roaded by just placing a few bytes in the existing packet for reference voltage.

See page 69-70 http://www.aprs.org/doc/APRS101.PDF

This could be a location in flash memory save with the scaling voltage saved. It's not a trivial update (but not impossible) and would require firmware update.

I'm not sure I see another obvious way to send out to general audiance telemetry and indicate non-default scalings. Ultimately this is a problem for not just voltage scaling but scaling for all end-adc applications, units, names, etc... I think we should implement this full functionality of packets rather than a one off solution for VREF.

[kb1lqc]

OK @kb1lqd does that mean we actually should leave the ADC data as raw bits right now and prepare to implement the telemetry scaling frame as you suggest?

A middle of the road solution could be to use some configuration file values to scale and down the road use the telemetry scaling frames to update the scaling values. This way they could scale with internal reference by default and be updated per station later?

Example scaling.ini

[KB1LQC-1]
[ADC0]=0.00058837890625
[ADC1]=0.00058837890625
[ADC2]=0.00058837890625
.
.
.

[KB1LQD-25]
[ADC0]=0.00058837890625
[ADC1]=0.00058837890625
[ADC2]=0.00058837890625
.
.
.

This would be a static file until firmware/software is updated to place latest received scaling values in the appropriate spot.

[kb1lqd]

Yes the middle of the road is OK for short/medium term. It lacks general transparency through the network so others out of the "know" of this file will convert to default. The file should be Callsign specific for scaling. This should only affect software.

Long term solution should be automatic from the transmissions itself. I think that would be a major update to telemetry protocol and out of scope of our short/medium goals.

[kb1lqc]

Hmm we could have a [DEFAULT] section that all new stations are scaled to unless they then transmit the scaling values. If they never do then they could be assumed to want the default. This would reduce RF bandwidth.

[kb1lqd]

@kb1lqc Maybe this is important to bring higher in the IT list for alpha release?

[kb1lqc]

I'd be up for that. It involves planning a little ahead about the fact that maybe not all Faraday radios will use the same scaling. If there is a way to tell what the scaling is (bit in RF?) then that would work well in the future.

For now I guess we could assume one scaling and that could be captured in a configuration document in telemetry and used to save to the database scaled data. It would be advantageous to maybe make an IT for future additions to account for that while this one remains simple?

[kb1lqd]

Is this really worth days if my time right now? The correct way to handle this is with new firmware as well...

…

On Tue, Mar 7, 2017 at 12:24 AM Bryce Salmi ***@***.***> wrote: I'd be up for that. It involves planning a little ahead about the fact that maybe not all Faraday radios will use the same scaling. If there is a way to tell what the scaling is (bit in RF?) then that would work well in the future. For now I guess we could assume one scaling and that could be captured in a configuration document in telemetry and used to save to the database scaled data. It would be advantageous to maybe make an IT for future additions to account for that while this one remains simple? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUsyL9P9nD6W2ayTeT8IzbTrZ5iFgouks5rjRQzgaJpZM4MIMQA> .

[kb1lqc]

It's probably not. I would make a note on this one in the summary to create an IT at the end of it to do the firmware + software update for different scaling and then just solved this one for our own 2.41V that we use right now.

[kb1lqc]

Thinking about this one right now so far later and I have a few thoughts:

• Now using APRS scaling we need to be careful that the raw bits are converted in the APRS application and sent as scaled values there. So we must be careful about breaking this.
• It's probably best to scale in Telemetry and then just adjust the APRS application to not perform any additional scaling. However, one could scale from there if wanted for some reason.