Re: os_time issues
no one using sntp?
Am 18.07.2018 um 18:54 schrieb Jan Clement:
Hello All,
i tried to get sntp client from lwip stack up and running today and
stumbled over some little problems and questions i would like to share
with you:
To start the sntp service I wrote:
sntp_setoperatingmode(SNTP_OPMODE_POLL);
ip_addr_t ntp_server;
IP4_ADDR(_server.u_addr.ip4, 94, 16, 116, 137);//0.de.pool.ntp.org
sntp_setserver(0, _server);
sntp_init();
But the callback function, called by the stack upon receive of the
packet is defined as follows in lwip/apps/sntp_ops.h:
#if !defined SNTP_SET_SYSTEM_TIME || defined __DOXYGEN__
#define SNTP_SET_SYSTEM_TIME(sec) LWIP_UNUSED_ARG(sec)
#endif
And nothing happens.
So I commented this out, and added
extern void SNTP_SET_SYSTEM_TIME(uint32_t t);
to sntp.c.
in my code i defined
void SNTP_SET_SYSTEM_TIME(uint32_t t) {
ntptime.tv_sec = t * 1000;
ntptime.tv_usec = 0;
console_printf("SNTP time from server: %ld \r\n", t);
os_settimeofday(, NULL);
}
And this works as expected and I get the correct ntp time stamp!
What would be a good and proper way to implement the callback function?
Another problem is, that os_gettimeofday(, NULL); gives weird
results:
005104 Time = 21474836480
006104 Time = 25769803776
007104 Time = 30064771072
008104 Time = 34359738368
009104 Time = 38654705664
010104 Time = 42949672960
010134 SNTP time from server: 1531932280
(** syncronization happened)
010136 Date: 18.6.2018 16:44:40
after the sync this is the ouput:
011104 Time = 6579599043818647160
012104 Time = 6579599048113614456
013104 Time = 6579599052408581752
014104 Time = 6579599056703549048
any ideas?
regards
j
Re: SENSOR_TYPE definition for a gas sensor
So, I do not feel strongly about one approach Vs another but I think if we are measuring resistance with a sensor, the units need to be in OHMS. Obviously, the kind of resistance might matter. For example: Gas resistance Vs Fluid resistance, etc. So, SENSOR_TYPE_GAS_RESISTANCE with OHMS as the unit makes sense for me. Regards, Vipul Rahane > On Jul 19, 2018, at 8:47 AM, Andrey Serdtsev > wrote: > > Extending ppb to uint64_t definitely doesn't make sense since maximum value > for it is 10^6, which is 32bit value. > > Sincerely yours, CO :) > > BR, > Andrey > > On 19.07.2018 18:41, Kevin Townsend wrote: >> >>> Thanks for your comments @Kevin and @Andrey. I think for the BME680, >>> I'll stick with USER_DEFINED for now until we can come up with a more >>> general system. Ultimately, the gas sensor resistance is not really a >>> final value to be used and so I think it's OK for it to fall under the >>> USER_DEFINED category. >> We should only define values based on standard and repeatable units, I agree, >> so USER_DEFINED makes sense here, though you might want to make which >> USER_DEFINED entry (1-6) selectable via syscfg.yml. >> >> This does still bring up a valid discussion about important sensor groups >> like 'gas', >> though. >> >> I was thinking, for example, we could define 1-bit for 'gas' and then hijack >> the >> triplet value type, where the first 32-bit value could define the gas type, >> and then >> the second value could contain the value in ppb (which could possibly be >> extended >> to a uint64_t, though I don't know if that's useful in the real world)? >> >> K. >
Re: SENSOR_TYPE definition for a gas sensor
Extending ppb to uint64_t definitely doesn't make sense since maximum value for it is 10^6, which is 32bit value. Sincerely yours, CO :) BR, Andrey On 19.07.2018 18:41, Kevin Townsend wrote: Thanks for your comments @Kevin and @Andrey. I think for the BME680, I'll stick with USER_DEFINED for now until we can come up with a more general system. Ultimately, the gas sensor resistance is not really a final value to be used and so I think it's OK for it to fall under the USER_DEFINED category. We should only define values based on standard and repeatable units, I agree, so USER_DEFINED makes sense here, though you might want to make which USER_DEFINED entry (1-6) selectable via syscfg.yml. This does still bring up a valid discussion about important sensor groups like 'gas', though. I was thinking, for example, we could define 1-bit for 'gas' and then hijack the triplet value type, where the first 32-bit value could define the gas type, and then the second value could contain the value in ppb (which could possibly be extended to a uint64_t, though I don't know if that's useful in the real world)? K.
Re: SENSOR_TYPE definition for a gas sensor
Thanks for your comments @Kevin and @Andrey. I think for the BME680, I'll stick with USER_DEFINED for now until we can come up with a more general system. Ultimately, the gas sensor resistance is not really a final value to be used and so I think it's OK for it to fall under the USER_DEFINED category. We should only define values based on standard and repeatable units, I agree, so USER_DEFINED makes sense here, though you might want to make which USER_DEFINED entry (1-6) selectable via syscfg.yml. This does still bring up a valid discussion about important sensor groups like 'gas', though. I was thinking, for example, we could define 1-bit for 'gas' and then hijack the triplet value type, where the first 32-bit value could define the gas type, and then the second value could contain the value in ppb (which could possibly be extended to a uint64_t, though I don't know if that's useful in the real world)? K.
Re: SENSOR_TYPE definition for a gas sensor
@Abderrezak > My question is: does Bosch allow the "re-distribution" of their > proprietary library? There are two parts to the Bosch library - the first it the BME680 driver, which, according to the license agreement can be redistributed in both source and compiled forms no problem. The other is the precompiled binary which forms the core of the BSEC library. I've integerated the BME680 library into the mynewt sensor framework. I've implemented the BSEC library as a separate mynewt module that you can optionally include into your project. This would either be commited into the main mynewt code, or available as a separate third party repository on github. The compiled library however, will not be distributed with the code and must be downloaded by the user and placed into the relevant folder in order for the project to compile. Thanks for your comments @Kevin and @Andrey. I think for the BME680, I'll stick with USER_DEFINED for now until we can come up with a more general system. Ultimately, the gas sensor resistance is not really a final value to be used and so I think it's OK for it to fall under the USER_DEFINED category.
Re: SENSOR_TYPE definition for a gas sensor
ppm and/or ppb make the most sense to me for units/scale, yes, but it
seems like we might need to define a fairly wide set of gas values for this.
Would a mechanism to indicate 'gas' with 1 bit in sensor_type_t (ex. "1
<< 16"), and then a follow-up 32-bit gas measurement type value
somewhere make sense, where you define one or more values such as eCO2,
TVOC, or other common values?
typedef enum {
SENSOR_GAS_TYPE_ECO2 = (1 << 0),
SENSOR_GAS_TYPE_TVOC = (1 << 1),
SENSOR_GAS_TYPE_USER_DEFINED_1 = (1 << 26),
SENSOR_GAS_TYPE_USER_DEFINED_2 = (1 << 27),
SENSOR_GAS_TYPE_USER_DEFINED_3 = (1 << 28),
SENSOR_GAS_TYPE_USER_DEFINED_4 = (1 << 29),
SENSOR_GAS_TYPE_USER_DEFINED_5 = (1 << 30),
SENSOR_GAS_TYPE_USER_DEFINED_6 = (1 << 31),
SENSOR_GAS_TYPE_ALL = 0x
} sensor_gas_type_t;
The question of course is where to store the secondary 32-bit value in
an way that doesn't break the reset of the API where sensor data values
are all compatible.
There may be other sensors types that would benefit from a second 32-bit
value to differentiate data types, such as IR, UV, specific wavelength,
etc., light in the case of spectographic sensors.
K.
On 19/07/2018 16:32, Andrey Serdtsev wrote:
Hi all,
Suggest to look at CCS811 digital gas sensor.
It outputs two parameters: eCO2 (equivalent CO2, in units of ppm) and
TVOC (total volatile organic compound, in units of ppb).
IMO, this is a good starting point.
BR,
Andrey
On 19.07.2018 17:18, Kevin Townsend wrote:
Hi Amr,
I think gas is a common enough value that it should be added, but the
difficulty is what standard/SI type unit and scale should we use for
that
since 'gas' is pretty generic. For light it's easy (lux), or
acceleration
(m/s^2), but do you have any proposition for what value would be an
acceptable fit in the instance of 'gas'?
Thanks for taking the time to put some drivers together and submitting
them, though. I think sensor drivers have a significant influence on
platform
adoption, and it puts some extra weight behind Mynewt to have things
that
work well out of the box.
Kevin
On 19/07/2018 15:18, Amr Bekhit wrote:
Hello,
I'm preparing to commit my library for the Bosch BME680 Environmental
Sensor and have a question. In sensor.h, there are a sensor_type_t
enum that contains definitions for the various values that can be
read. The BME680 contains a gas sensor that reports a resistance. This
is not listed in the sensor_type_t. I have been using
SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a
SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry
on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance
is not in an of itself a final value - further processing is required
by the application to convert it to something more meaningful (in this
case, the resistance is converted to an Indoor Air Quality Index,
which is calculated by a separate third party module - the Bosch BSEC
library - which I intend to commit soon).
Amr
Re: SENSOR_TYPE definition for a gas sensor
Hi all, Suggest to look at CCS811 digital gas sensor. It outputs two parameters: eCO2 (equivalent CO2, in units of ppm) and TVOC (total volatile organic compound, in units of ppb). IMO, this is a good starting point. BR, Andrey On 19.07.2018 17:18, Kevin Townsend wrote: Hi Amr, I think gas is a common enough value that it should be added, but the difficulty is what standard/SI type unit and scale should we use for that since 'gas' is pretty generic. For light it's easy (lux), or acceleration (m/s^2), but do you have any proposition for what value would be an acceptable fit in the instance of 'gas'? Thanks for taking the time to put some drivers together and submitting them, though. I think sensor drivers have a significant influence on platform adoption, and it puts some extra weight behind Mynewt to have things that work well out of the box. Kevin On 19/07/2018 15:18, Amr Bekhit wrote: Hello, I'm preparing to commit my library for the Bosch BME680 Environmental Sensor and have a question. In sensor.h, there are a sensor_type_t enum that contains definitions for the various values that can be read. The BME680 contains a gas sensor that reports a resistance. This is not listed in the sensor_type_t. I have been using SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance is not in an of itself a final value - further processing is required by the application to convert it to something more meaningful (in this case, the resistance is converted to an Indoor Air Quality Index, which is calculated by a separate third party module - the Bosch BSEC library - which I intend to commit soon). Amr
Re: SENSOR_TYPE definition for a gas sensor
Hi Amr, I am myself using the bme680. I am looking forward to trying your implementation. My question is: does Bosch allow the "re-distribution" of their proprietary library? Thanks for the effort. Abderrezak On 7/19/2018 9:18 AM, Amr Bekhit wrote: Hello, I'm preparing to commit my library for the Bosch BME680 Environmental Sensor and have a question. In sensor.h, there are a sensor_type_t enum that contains definitions for the various values that can be read. The BME680 contains a gas sensor that reports a resistance. This is not listed in the sensor_type_t. I have been using SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance is not in an of itself a final value - further processing is required by the application to convert it to something more meaningful (in this case, the resistance is converted to an Indoor Air Quality Index, which is calculated by a separate third party module - the Bosch BSEC library - which I intend to commit soon). Amr
Re: SENSOR_TYPE definition for a gas sensor
Hi Amr, I think gas is a common enough value that it should be added, but the difficulty is what standard/SI type unit and scale should we use for that since 'gas' is pretty generic. For light it's easy (lux), or acceleration (m/s^2), but do you have any proposition for what value would be an acceptable fit in the instance of 'gas'? Thanks for taking the time to put some drivers together and submitting them, though. I think sensor drivers have a significant influence on platform adoption, and it puts some extra weight behind Mynewt to have things that work well out of the box. Kevin On 19/07/2018 15:18, Amr Bekhit wrote: Hello, I'm preparing to commit my library for the Bosch BME680 Environmental Sensor and have a question. In sensor.h, there are a sensor_type_t enum that contains definitions for the various values that can be read. The BME680 contains a gas sensor that reports a resistance. This is not listed in the sensor_type_t. I have been using SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance is not in an of itself a final value - further processing is required by the application to convert it to something more meaningful (in this case, the resistance is converted to an Indoor Air Quality Index, which is calculated by a separate third party module - the Bosch BSEC library - which I intend to commit soon). Amr
SENSOR_TYPE definition for a gas sensor
Hello, I'm preparing to commit my library for the Bosch BME680 Environmental Sensor and have a question. In sensor.h, there are a sensor_type_t enum that contains definitions for the various values that can be read. The BME680 contains a gas sensor that reports a resistance. This is not listed in the sensor_type_t. I have been using SENSOR_TYPE_USER_DEFINED_1 for the time being. Is it worth adding a SENSOR_TYPE_GAS or SENSOR_TYPE_GAS_RESISTANCE to the typedef or carry on using SENSOR_TYPE_USER_DEFINED_1? Bear in mind that the resistance is not in an of itself a final value - further processing is required by the application to convert it to something more meaningful (in this case, the resistance is converted to an Indoor Air Quality Index, which is calculated by a separate third party module - the Bosch BSEC library - which I intend to commit soon). Amr
