Hello dear SI-Labs community,

I'm currently working on the si7210 and have some questions, which keep me struggling. Would be amazing if anyone could help me out.

1. My sampling frequency is about 5kHz, even though the bits [3:0] in 0xc4 are set to 0. The datasheet says a sampling rate of about 113kHz can be reached but even turning of every filter didn't help. (0xCD is also set to 0)

2.  The datasheet says that the sensor has a minimum operate point of 0.6 mT. What happens, if those are not reached? I'm getting really high values if no magnet is near the sensor?

Thank you in advance and kind regards

Hello dear SI-Labs community,

I'm currently working on the si7210 and have some questions, which keep me struggling. Would be amazing if anyone could help me out.

1. My sampling frequency is about 5kHz, even though the bits [3:0] in 0xc4 are set to 0. The datasheet says a sampling rate of about 113kHz can be reached but even turning of every filter didn't help. (0xCD is also set to 0)

2.  The datasheet says that the sensor has a minimum operate point of 0.6 mT. What happens, if those are not reached? I'm getting really high values if no magnet is near the sensor?

Thank you in advance and kind regards

Hello dear SI-Labs community,

I'm currently working on the si7210 and have some questions, which keep me struggling. Would be amazing if anyone could help me out.

1. My sampling frequency is about 5kHz, even though the bits [3:0] in 0xc4 are set to 0. The datasheet says a sampling rate of about 113kHz can be reached but even turning of every filter didn't help. (0xCD is also set to 0)

2.  The datasheet says that the sensor has a minimum operate point of 0.6 mT. What happens, if those are not reached? I'm getting really high values if no magnet is near the sensor?

Thank you in advance and kind regards

I am using the chip "EFR32MG1P132F256GM48" in a customized pcb and "EmberZNet 6.7.6.0 GA SoC".

I need to read the "Si7021" sensor through I2c communication and send the information via ZigBee. However, I couldn't find any example/document showing how to enable and test the I2c using an "AppBuilder project".

I enabled the plugins "Temperature Si7021", "Relative Humidity Si7021" and "I2C Driver". In Hardware Configurator (.hwconf file), I configured it as follows:

However, when sending the reset command to the temperature sensor through the plugin, debugging I noticed that the callback: "halI2cWriteBytes(SI_7021_ADDR, & resetMsg, SEND_COMMAND_SIZE)" is returning "0xFF" (I2C_DRIVER_ERR_UNKOWN).

I don't know what may be happening to have this behavior. Does anyone have any assumptions or examples to suggest for me?

Considerations:

• As I am using my own pcb, I do not need to use the "Sensor enable pin" in the "I2CSENSOR" on Hardware Configurator.
• I suspect that the problem may be with my Bootloader. If someone finds this option plausible, I can send the settings I used to generate it.

Hey there!
I am exploring an option to replace a tactile button with a sensor Si1153.

Would it work to use the CP2110 circuit together with Si1153?
Would that be compatible?

https://www.silabs.com/sensors/optical/si115x/device.si1153-00-gm

https://www.silabs.com/interface/usb-bridges/classic/device.cp2110-f01-gm

Many thanks in advance
Cheers,
Tom

I am working with a niche application where I create my own field and try to measure when objects are measuring through it, rather than the field itself moving. In doing so and the distance my object is away from the field, when graphing raw data I can physically see the change in measurement when the device enters and exists the field, though due to general background field, temperatures and measurement errors at  roughly 2.8V (battery powered application), the single shot measurements done in sleep mode don't yield consistent results. Is there any of the ICs in the series that allow for setting the burst/averaging bits in the register by the user, or even any pre-programmed variants that have this value > 0.

From what I can tell in the datasheet, this value is set in factory in the OTP (One-Time-Program) bits and cannot be adjusted. Though it goes further to say that if it WERE set, it would do all the averaging required, though no parts currently exist with this set, does this mean I would need to do a customer order with a minimum supply quantity from Si Sales team?

Looking at the datasheet section 4.1.3 states that when Userstore bit is set, that only 4 registers are actually reloaded from user area, the rest are loaded from OTP?

I guess my question really is, can I set the IC to read more than 1 sample at a time, average it, make a decision on the output pin and go back to sleep automatically and continuously without an external MCU reconfiguring the IC every sleep cycle?

The amount of power required to run in IDLE would kill the battery too quick.

I'm testing the ADC overflow conditions in the si1133 and I'm getting a weird behavior when changing the Channel setup right after an overflow condition. Here's the setup:

• Configured three channels (0, 1 and 2) with the sensors LARGE_IR, LARGE_WHITE and UV respectively, sw_gain=N (let's say initially 1), hw_gain=0, decimation normal, 24-bit output. 
• Issue a FORCE command, wait until the command finishes, then read the 24-bit values back.
• Repeat the last step in a loop.

Here's what happens:

1. If all sensor values are below the limit, all is fine. I eventually get the CMMND_CTR value incremented and can send another FORCE command. Read values make sense and change accordingly when shining a light at the sensor.
2. If one of the sensor hits the overflow limit (0x7fffff), the RESPONSE0 will have the CMD_ERR bit set and CMMND_CTR will be 0x2 (Saturation of the ADC or overflow accumulation) which is expected. All the other channels read back reasonable values even if one of the sensors is saturated.
   1. To reset this CMD_ERR condition I then send RESET_CMD_CTR which executes normally. If I don't change anything else the next FORCE command continues reading without problems (showing overflow for the channels that are overflowed until I remove the light pointing at the sensor). So far, all is good.
   2. However, if after this overflow condition I send RESET_CMD_CTR, wait for the cmd to finish, and then reconfigure all channels to use sw_gain=0 instead of 1 then the sensor misbehaves:
      • The read values are off by one: the LARGE_WHITE sensor value would be in HOSTOUT3-5 normally, but after changing the config to sw_gain=0 and issuing a new FORCE command I see that the value that would make sense for LARGE_WHITE (about half of the previous) is now in HOSTOUT6-8; while the first two 24-bit channels are both 0x7fffff.
      • Moreover, if I continue repeating this process of changing the sw_gain, FORCE, RESET_CMD_CTR, the values keep shifting and after a few times the FORCE command fails with error 0x13 in RESPONSE0 ("Output buffer overflow"). My understanding is that a FORCE command should never fail with "Output buffer overflow" since there are only 6 channels max of 3 bytes output each (18 bytes) but 26 bytes of output. This is most obvious if after an overflow with sw_gain==1 you then change to sw_gain=2, then =3, then =4, since larger sw_gain will continue showing the overflow condition.

My suspicion without knowing how is the controller of this chip implemented, is that this is a bug in the chip in the error handling case: when there's an ADC overflow or SW_GAIN accumulation overflow the internal pointer to the output buffer (HOSTOUTx) is not reset when a PARAM_SET (0x82, 0x83 ....) command is send before the next FORCE; but it is reset when the next command is directly FORCE. To be clear:

• FORCE, RESET_CMD_CTR, FORCE, RESET_CMD_CTR, .... works fine
• FORCE, RESET_CMD_CTR, PARAM_SET ..., FORCE --> doesn't work, with 6 channels configured it fails with 0x13 on the second call.

HW_ID is 0x03

REV_ID is 0x10 

Are you aware of this issue? Is there a workaround? I didn't find any errata on the topic. The only way I have found to work is to issue a RESET_SW but that requires to wait additional 25ms for the device to exit the "Initialization Mode" again and reconfigure everything. Arguably one should be able to change the sw_gain to a lower value when an accumulation error is detected.

Would you be able to kindly clarify the temperature/moistness condition in the Si7021 Humidity and Temperature sensor 

the condition is as per the following: 

%RH= (125*RH_Code)/65536 - 6 

furthermore, temp temperature(Degree Celsius)= (175.72*Temp_Code)/65536 - 46.85 

.All things considered, I need to understand what 125(175.72) and 6(46.85) shows in the dampness bazoocam bazoocam bazoocam and temperature condition

My application is: detect day versus night, indoors, in a room with south facing windows.  I am exploring the Si1133 to measure UVA.  I can put the detector within 10 feet of the windows, high and facing down so the detector gets reflected UV, and never gets direct sunlight, and gets only reflected artificial lights from typical room lighting of about 400 lux white, fluorescent light.  My understanding is the window glass will transmit about 50% of UVA,  that the sky will scatter significant UVA,  that night sky has no UVA, and that artificial lights produce negligible UVA.

Might that work?  Do you have any suggestions re diffuser, physical filters, parameters of the Si1133, and which set of diodes to use?  My plan is to read only the UV diode.

I want to estimate sun time by detecting sundown and sunset, despite noise from artificial lights.  I don't need accuracy.  I plan to take samples over many days.   I understand that the weather and season will have an effect. 

the time between measurements with the Si7210 in idle mode ( continuous mode ) is supposed to be around 20us in worst case; but with the following settings:

sltimeean = 0, stop = 0 ,  sleep =0,  slTime =0,

and using a small Arduino sketch  i measured 24ms for each measurement which is supposed to take few microseconds!.

is the idle time in Si7210 factory programmed? or is there a specific sequence of instructions to enter idle mode?

Hello,
I am using thunderboards sense 2  in SS5, and I am trying to send orientation data to another board.
I have already enabled the components needed and I have no problem with that. Also I followed https://docs.silabs.com/gecko-platform/3.0/hardware-driver/api/group-imu#ga85e06f8cc966bae988423bca3d094282

But I don't know what is the " Three dimensional orientation vector "  I send. Before I send, I convert the data I measure to uint8_t and I print them :

     ovec_1[0] = (ovec[0] & 0x000000ff);
     ovec_1[1] = (ovec[0] & 0x0000ff00) >> 8;

     ovec_1[2] = (ovec[1] & 0x000000ff);
     ovec_1[3] = (ovec[1] & 0x0000ff00) >> 8;

     ovec_1[4] = (ovec[2] & 0x000000ff);
     ovec_1[5] = (ovec[2] & 0x0000ff00) >> 8;

But I move thunderboard so I change the three axis and I observe narrow differences. I want to tell me what type of metric ovec[0],ovec[1],ovec[2] are and if I miss something or that's normal.

Thanks in advance,
Thanos

What impedance will the LED pins have when the circuit is shut down? 

All the more decisively, if Si115x is fueled from a managed power space (which could be killed) while the IR-LED is controlled straightforwardly from the battery. 

What occurs with the LED contribution on the Si115x if the force supply to the circuit is closed of when the IR-LED actually is fueled by the battery. Is there a danger for current spillage through the LED that ultimately could deplete the battery, if so how huge would that spillage be. Or then again is the plan of the current sink controller done so a high impedance is ensured? In the present circumstance is it prescribed to have the draw up ome tv omegle tv dirtyroulette resistors associated with the controlled force area from which Si115x is fueled from or is there any motivation to have the resistors associated straightforwardly to the battery together vid the LED? 

Best Regard

Can you explain the notation in the datasheet in the "operation" column of the ADCMUX row of the table for the ADCCONFIGx parameter?  The notation uses for example "D + 10" for the UV "optical function."  But the term "D" has no antecedent anywhere in the datasheet, as far as I know.

I assume "D" refers to a separate diode for UV. 

Does the "+10" mean that the mcu on the chip adds ten to some raw result?

Also, what is the interpretation of a negative result?  That the dark current is less than the light current (where you are measuring the diode in two ways, dark current and light current, and taking the difference) ?

Related to my other post about detecting daylight using UV indoors.

Hi, 

We are seeing the issue on I2C bus where the sensor communication is failing. I2C bus error. 

There are many functions in driver like SI1133_paramSet() which are calling I2C read() back to back. These calls are failing. If we add some delay between calls it works fine. Finally we resorted to add delay in the I2C_Read() and I2C_Write() functions in the beginning. It resolved the issue. 

I think, si1133 has some issue if host MCU runs fast and sends commands quickly one after the other.