bobveringa / hscdtd008a-library Goto Github PK
View Code? Open in Web Editor NEWA library for the HSCDTD008A Sensor and CJMCU-008 Module
License: MIT License
A library for the HSCDTD008A Sensor and CJMCU-008 Module
License: MIT License
Dear Bob
I am intending to add another magnetic sensor to the i2c-bus (hmc5883l) and use both magentic sensors, i.e. the hmc5883l as well as the HSCDTD008A to count impulses from 2 gas meters.
How can I implement that with the library? I mean the library never calls t_close, hence I can not access the i2c device for a second sensor with a 2nd library. And it is also not efficient to constantly open and close the i2c device.. I was thinking of adding the support for the hmc5883l as separate class. For the access to the i2c-bus I need to link to src/driver/platform_rpi.cpp or src/driver/hscdtd008a_driver.c (depending on the platfrom). The data type for handles (hscdtd_device_t *p_dev) are however specific to the HSCDTD008A driver.
Should you have any ideas how to do this conceptually, please kindly let me know.
Thanks
Tilman
As @tilman1 pointed out in #9 the address for the chip is hard-coded in the platform file. Given that this are cheap chips, they are likely to have addresses that are all over the place.
This means a modification is needed to allow other platforms to set up all required components for I2C functionality.
Summary:
The order of temperature compensation and offset calibration seems to be order dependent in the latest build.
A HSCDTD_STAT_NO_DATA
error is triggered if temperature compensation is done before offset calibration. Validation is needed if this is also the case for the C driver layer, or if this only happens in the Wrapper layer. I have no reason to believe the wrapper layer causes any of this behavior, but validating it seems a good first step.
Initial code analysis shows no obvious reason why the order of these operations should matter, so more investigation is needed.
Workaround
The workaround is to do offset calibration before temperature compensation.
Additional details:
A logic analyzer clearly shows the driver attempting to check the status register, but only 0x00
is returned from it.
If both temperature compensation and offset calibration are disabled, only 2 attempts are needed before data is available.
If only offset calibration is enabled, it takes ~26 attempts:
if only temperature compensation is enabled, it takes ~29 attempts:
If both are enabled in the "wrong" order, and the number of max-attempts is increased from 50 to 100, data is available within 32 attempts. This does not make any sense to me.
It could have something to do with these functions explicitly setting the device in the FORCE state.
Because the DRDY (white) pin is high about 93ms after starting a reading.
In any case, something goes wrong when using TCS or OCL (or a combination of the 2) as the number of attempts is just way to high.
Code snippet to test:
void setup() {
hscdtd_status_t status;
Serial.begin(9600);
geomag.begin();
// If you know the I2C address is different than in the provided
// data sheet. Uncomment the line below, and configure the address.
geomag.begin(0x0F);
// Initialize the hardware.
status = geomag.initialize();
if (status != HSCDTD_STAT_OK) {
Serial.println("Failed to initialize sensor. Check wiring.");
// Halt program here.
while (true) { delay(1); }
}
// Compensate for temperature.
geomag.temperatureCompensation();
geomag.offsetCalibration();
}
Currently, the driver supports the Force State for reading data from the sensor. The HSCDTD008A also supports configuring the sensor to a specific frequency and reading sensor data without explicitly starting a read operation.
The goal is to research how Normal State can be properly supported on an Arduino. In addition, some examples should be created that clearly show how it should be used.
Add support for the Data Ready Pin Support to the Arduino Layer. Including some examples.
Add support for the Offset Drift feature of the HSCDTD008A sensor.
This allows the user to apply a static offset to all the values.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.