Conversation
GSR_UNCAL_LIMIT_RANGE3_SR68 raises range-3 codes below it to it before calibration so that an open circuit reads as open. It was 1134. That is below the 0.4986 V this API divides by for the SR68, which is code 1134.3 at the 1.8 V full scale. So 1134, and every code clamped up to it, decoded to a negative resistance. In auto-range NudgeGSRResistance floored that at 8 kOhm, so an open circuit read 125 uS, and the LIMIT_FOR_MINIMUM_VALID_GSR_CONDUCTANCE_US check reported it as Connected. On fixed range 3 it was pinned to 680 kOhm. An SR68-9 with its electrodes open (DEV-793 dataset B6) reads range-3 codes peaking at 1126-1136, so most of such a recording hits this. The limit is now 1138, the first code above 0.5 V, which clears 0.4986 V as well. The Java driver divides by 0.5 V for the same front end, so one value is right under both. The Java driver and the web SDK get the same change under DEV-1067. SensorGSROpenCircuitTest decodes codes 1134-1138 on range 3 in auto-range (also asserting Disconnected) and on fixed range 3, and pins the limit to the first code above 0.5 V. At 1134 all three fail (8.0 and 680.0 kOhm). At 1138 all three pass, as does the rest of ShimmerBLETests (121). Built with Visual Studio's MSBuild. Under the dotnet CLI, PropertyChanged.Fody 2.6.0 crashes in ShimmerBLEAPI, and Realm's weaver needs SolutionDir. Not changed here: an SR61-5/6 reports HardwareIdentifier VERISENSE_IMU, so it gets neither the gen-2 resistors nor this clamp. That is the gap that DEV-874 closed in the web SDK and DEV-793 closed in the Java driver. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DEV-1067
Problem
SensorGSR.GSR_UNCAL_LIMIT_RANGE3_SR68raises every range-3 code below it to it before calibration, so that an open circuit reads as open. It was 1134, which is below the 0.4986 V thatCalibrateGsrDataToKOhmsUsingAmplifierEqdivides by for the SR68 (code 1134.3 at the 1.8 V full scale). So 1134, and every code clamped up to it, decodes to a negative resistance:NudgeGSRResistancefloors it at 8 kOhm, so an open circuit reads 125 µS, and theLIMIT_FOR_MINIMUM_VALID_GSR_CONDUCTANCE_UScheck reports it as ConnectedAn SR68-9 with its electrodes open (DEV-793 dataset B6) reads range-3 codes peaking at 1126–1136, so most of such a recording hits this.
Fix
The limit is now 1138, the first code above 0.5 V, so it clears 0.4986 V as well. The Java driver divides by 0.5 V for the same front end, and one value is right under both. It is the same value as the Java driver and web SDK PRs below.
Tests
ShimmerBLETests/Sensors/SensorGSROpenCircuitTestdecodes codes 1134–1138 on range 3:DisconnectedShimmerBLETestspasses (121)How it was built: the dotnet CLI cannot build
ShimmerBLEAPIhere — PropertyChanged.Fody 2.6.0 crashes, and Realm's weaver needsSolutionDir. So the tests were built with Visual Studio 2022's MSBuild with-p:SolutionDir=...\ShimmerBLE\, and the DLL was run withDOTNET_ROLL_FORWARD=Major, since no 5.0 runtime is installed.Not changed here
An SR61-5/6 reports
HardwareIdentifier.VERISENSE_IMU, so it gets neither the gen-2 resistors nor this clamp: GSR reads ~1.9× high, and an open circuit still reads 125 µS. That is the gap DEV-874 closed in the web SDK and DEV-793 closed in the Java driver. It needs its own change.Sibling PRs (same constant, same ticket)
🤖 Generated with Claude Code