🚴 Improve duty cycling (and its analysis)#9
Conversation
…ake) + necessary changes in upper layers - optimized timing allignement in VCO sdk for sleep/wakup and HW latching rate of the counter + created script vcd_timing_rms for timing measurements
| # | ||
| # File: vcd_gsr_timing_rms.py | ||
| # Description: Extract GSR reference/computed samples from VCD/FST waveforms and | ||
| # compute RMS timing error around VCOp enable edges. |
There was a problem hiding this comment.
I guess this only works with some particular app being run. Which one?
Is the result expected to change?
There was a problem hiding this comment.
I added a README and clarified the description.
| #define VCO_DECODER_PHASES 62u | ||
| #define VCO_READOUT_DELAY_CC 3u | ||
|
|
||
| // clock cycles compensations |
There was a problem hiding this comment.
I am guessing this is due to the timer and its interrupt attention routine?
What happens if you use the VCO's refresh? This is done in HW and shouldnt have any offset.
There was a problem hiding this comment.
Fixed it in the next PR. Still have some magic compensation numbers though because we still need to align the ON cycles to have 2 REFRESH updates inside it. I made sure the values are tuned to be resilient and pass a lot of tests I tried
|
|
||
| ## Ground Truth Definition | ||
|
|
||
| The RMS script compares each debug-written conductance sample against the |
There was a problem hiding this comment.
If i understand properly, the G_ref is what you use to compute the quantization error.
If you want to be precise, you should take the average over the integration time. Taking the first value alone would negatively (and unfairly) impact the longer integration times / larger duty-cycles, right?
There was a problem hiding this comment.
Yes completely right I forgot to add that !
There was a problem hiding this comment.
Here you are computing the power consumed by the iDAC alone, but its not the power consumed by "the process of injecting current". i.e. the proper computation should be 0.8 V * i_dc (the power dissipated through both the iDAC and the skin, which is what will drain the battery in the end).
I feel we already discussed this, maybe we concluded something i forgot about?
Doing this makes the power a beautiful trade-off between the power consumed by the iDAC and that consumed by the VCO, but it breaks the "target search"
If this is right, then probably you cannot just relate power to range. Research/report-wise this is great, because you have one more trade-off to discuss =)
There was a problem hiding this comment.
Aiie missed that comment ! Corrected that now with the latest push. Actually changes some things about my range adjustment but it's fine. Thank you for noticing it !
- Deleted the duty cycling RMS nonsense :/ RIP. Kept the RMS and vcd decoder as it might be useful for other validation - Corrected the vcd parser: G_ref is the average of the G_nS values inside the ON cycle time
JuanSapriza
left a comment
There was a problem hiding this comment.
Will finish reviewing after a few meetings
There was a problem hiding this comment.
Is this folder still relevant? I understand that the shell script was to generate different duty cycles and then evaluate them, but since that part is gone, maybe the shell script and this analysis are not longer used?
Maybe i misunderstood, sorry if that's the case
There was a problem hiding this comment.
It is not VCO_duty_cycling folder anymore but I will keep the evaluation script that analyzes the vcd files and shell script if mainly for automating any evaluation I might do in the future. I will change the names
There was a problem hiding this comment.
Also I can keep them locally (add in the gitignore if that's better) because I kept them mainly for my validation and testing process
There was a problem hiding this comment.
I think that would make more sense for now
There was a problem hiding this comment.
If the script is no longer used, this can be moved into the main.c for clarity
Fix duty-cycled conductance reconstruction and VCO timing alignment