search

FaradayRF / Faraday-Software

Faraday node software
https://www.faradayrf.com
Other
48 stars 19 forks source link

Standardize ADC Scaling #102

Open kb1lqc opened 7 years ago

kb1lqc commented 7 years ago

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:

Cons:

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

kb1lqc commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/FaradayRF/Faraday-Software/issues/102#issuecomment-284653810, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUsyL9P9nD6W2ayTeT8IzbTrZ5iFgouks5rjRQzgaJpZM4MIMQA .

kb1lqc commented 7 years ago

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 commented 6 years ago

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