dd-firmware / firmware / App / Drivers

ConductivitySensors.h

Clone Tools

Stats

Commits this week: 2
Total Committers: 4
Last Commit: 05 Feb
Commits this week: 2

Lines of code count not available

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Tuesday 03 Feb
5:32 pm

Sean Nash

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task...

I think cal data and count should be retrieved by same function and possibly needs some interrupt protection to ensure data and count stick together. If these functions are called from general task, we could have situation where data is retrieved, then priority task updates fpga, and then counter is retrieved with wrong (incremented) counter.
If these two functions are being called from a driver that is executed in priority task, then we don't need to worry about this situation, but still ought to add a constraint/warning comment in function headers noting that these functions should only be called from priority task.

5:16 pm

Sean Nash

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

I think Dialin will need get (or UI proxy) commands to have us send cal, s/n, and versions.

5:15 pm

Sean Nash

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function...

Do FP sensors have to be treated separately? I realize there needs to be separate messages as they will be coming from different Dialin classes, but can't we handle both messages with same function (assuming shared enum to index)?

5:14 pm

Sean Nash

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler wher...

General Dialin question - does it make sense to override temperatures at driver level where they are spread out over several drivers? I would think overriding at monitor level would be simpler where they are all in one place and could be indexed by enum with single command.

5:09 pm

Sean Nash

Do we need to say Value?

Do we need to say Value?

5:08 pm

Sean Nash

Add a blank line after public defs banner. Add a dox comment to the right. I believe they reserve space for 12 bytes, not 10. Not really for calibration - it's for s/n and versions.

Add a blank line after public defs banner.
Add a dox comment to the right.
I believe they reserve space for 12 bytes, not 10.
Not really for calibration - it's for s/n and versions.

5:06 pm

Sean Nash

Are these really going to be different types? I assumed they would all be floats.

Are these really going to be different types? I assumed they would all be floats.

5:05 pm

Sean Nash

Structures need a top level dox comment.

Structures need a top level dox comment.

5:05 pm

Sean Nash

enums need a top level dox comment.

enums need a top level dox comment.

4:56 pm

Sean Nash

I believe conductivity and temperature data will be F32s.

I believe conductivity and temperature data will be F32s.

4:52 pm

Sean Nash

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

Do we not need this anymore? I still see it in code all over the place and I don't think we're done w/ Teensy until Beta 1.9 units are obsolete.

Monday 02 Feb
11:37 am

Michael Garthwaite

11:01 am

Sean Nash

10:37 am

Michael Garthwaite

LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
Tuesday 27 Jan
1:03 pm

Michael Garthwaite

fixed. Removed ifdef as well as it is no longer applies here since we are retrieving the data from the monitor which has the #ifdefs for teensy.

fixed. Removed ifdef as well as it is no longer applies here since we are retrieving the data from the monitor which has the #ifdefs for teensy.

12:34 pm

Sean Nash

I think using filtered values for alarms makes sense.

I think using filtered values for alarms makes sense.

10:25 am

Michael Garthwaite

we need filtered values for various applications in the system. My question is should we be checking dialysate temperature using a filtered value or a sample point? This version showed that we want...

we need filtered values for various applications in the system. My question is should we be checking dialysate temperature using a filtered value or a sample point? This version showed that we want a sample point.

in Denali, looks like the HD got the filtered temperature value from the DG for checking dialysate temp alarms. Are we upholding that same design of using a filtered value for leahi dialysate temp?

10:19 am

Sean Nash

I don't see fix. Did you push fwcommon?

I don't see fix. Did you push fwcommon?

10:15 am

Sean Nash

Restore this blank line.

Restore this blank line.

10:15 am

Sean Nash

Remove all of these blank lines please.

Remove all of these blank lines please.

10:03 am

Michael Garthwaite

Removed the ifdef here as these overrides still be used without breaking the teensy driver. I can add it on request. Unsure if teensy will be tested long enough for them to use those overrides. In...

Removed the ifdef here as these overrides still be used without breaking the teensy driver.
I can add it on request. Unsure if teensy will be tested long enough for them to use those overrides.

In the meantime,

MSG_ID_DD_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST and MSG_ID_FP_FILTERED_COND_SENSOR_READINGS_OVERRIDE_REQUEST are still available to override the monitor/filtered data.

9:57 am

Michael Garthwaite

fixed.

fixed.

9:57 am

Michael Garthwaite

fixed.

fixed.

9:57 am

Michael Garthwaite

Not here. This include was not in the right spot as we want the two drivers to be separated. the include is in the monitor

Not here. This include was not in the right spot as we want the two drivers to be separated. the include is in the monitor

9:50 am

Michael Garthwaite

Temperature monitor only has getter's for d4 and d50 at the moment. It looks like that hasnt been refactored to consider all temp sensors.

Temperature monitor only has getter's for d4 and d50 at the moment. It looks like that hasnt been refactored to consider all temp sensors.

9:38 am

Michael Garthwaite

for Teensy it is done at the driver as it is a part of the initialization sequence. See TEENSY_CMD_GET_EEPROM_DATA cmd.

for Teensy it is done at the driver as it is a part of the initialization sequence. See TEENSY_CMD_GET_EEPROM_DATA cmd.

9:30 am

Michael Garthwaite

Not at the moment. This feature isnt expected to on the V2's. The v2's arent going to have ALY_LINEAR as that is one specific to the teensy sensors.

Not at the moment. This feature isnt expected to on the V2's. The v2's arent going to have ALY_LINEAR as that is one specific to the teensy sensors.

Monday 26 Jan
10:31 pm

Sean Nash

#ifdef TEENSY for these new functions.

#ifdef TEENSY for these new functions.

10:31 pm

Sean Nash

Only needed for TEENSY, right? So #ifdef should be applied.

Only needed for TEENSY, right? So #ifdef should be applied.

10:30 pm

Sean Nash

No model selection for V2 sensor?

No model selection for V2 sensor?