Impossible DNMS Values on https://api-rrd.madavi.de/

[terraformer]

Values on https://api-rrd.madavi.de/grafana/d/BYsfp-xGz/dnms?var-chipID=esp8266-9757414&orgId=1 are way off. On the Sensors Web interface everything looks good:

GET r: 200
output debug text to displays...
No newer version available.
.
WiFi connected, IP is: <confidential>
Starting Webserver... <confidential>

ChipId: 9757414

MAC Id: <confidential>
Read DNMS...
Trying DNMS sensor on 0x55ws: debug level ...
R/ DNMS
LAeq: 49.47
LA_MIN: 47.26
LA_MAX: 59.18
----
/R DNMS
## Sending to madavi.de: 
Succeeded - api-rrd.madavi.de
Time for Sending (ms): 241
R/ DNMS
LAeq: 49.14
LA_MIN: 46.96
LA_MAX: 60.33
----

Current Firmware: NRZ-2020-134-B3/DE (Apr 8 2021) Board: DNMS-T4.0+NodeMCU-V1.5 Teensy4.0 Firmware: DNMS_V2.0.5

Any ideas how to fix this? Sensor seems ok but the values in grafana are impossible and do not match with the sensor log.

[pjgueno]

Explained in the forum: https://forum.sensor.community/t/dnms-la-max-high-peaks/228

The graphs at api-rrd.madavi.de 3 aren’t finished yet. So please don’t use them.

Should be the reason.

Please use: https://maps.sensor.community/grafana/d/000000004/single-sensor-view?orgId=1&var-node=42250

[ricki-z]

We use graphana for the graphs. The math functions there are very limited. But for the average values we need the logarithmic average of the dBA values. So we are including the exponential values to the Influx database. In theory we could then take the logarithm of the average of these values to get the right average values. But at the moment there is no logarithm function in grafana. We hope they will implement it in a future release.

[BasvanDrunen]

Also i noticed very high value's in the LAmax, initial though was that this was caused by the DNMS, but i have modified the code to never report value's over 140 dB.

But still i have sometimes the stange high value's, I suspect the I2C bus to have some "problems" and that causes very strange value's to be read by the ESP32. (I'm going to be using a shielded twised pair cable as possible solution.)

My proposal would be that the software reading the DNMS value's ignores all value's over 140 dB.

rgds, Bas

[BasvanDrunen]

Add in dnms_i2c.h:

#define DNMS_MAX_DB_ALLOWED 140

Add in dnms_i2c.cpp, in the function int16_t dnms_read_leq(struct dnms_measurements *leq):

if ((leq->leq_a >= DNMS_MAX_DB_ALLOWED) || (leq->leq_a_max >= DNMS_MAX_DB_ALLOWED)) return STATUS_FAIL;

before return 0;

[pjgueno]

But still i have sometimes the stange high value's, I suspect the I2C bus to have some "problems" and that causes very strange value's to be read by the ESP32.

Where is the ESP32? There is no ESP32 in the instruction (or for the ESP8266?)

[BasvanDrunen]

Excuses, where i wrote ESP32, it must be ESP8266.

[pjgueno]

Do you have a legit DNMS? I am quite sure @hbitter have already made sure that no value above 140 dB appear under normal conditions. It could be some interferences in the I2C bus (did you implement the bus extension?). I have already heard of that with some exotical boards.

[hbitter]

Hi Bas,

could you give a bit more information about your setup. What boards are you using and also what DNMS firmware version? Regards, Helmut

[BasvanDrunen]

I'm using the following setup: Airrohr-PCB-V1.5 with node mcu v3

teensy 4.0 with DNMS_V1.0.4

both pcb's have the I2c extender. Initial setup i have connected the board using the RJ11/12 cable, now i connected both boards using a flatcable and the i2c-EX pins on both boards. Cable length is approx 10 cm, no long cables used. Reason for testing different connections and cables is that i also suspect interference in i2C. In my final setup i might use shielded network cables.

The spikes happen very rarely, and ignoring those value's would be no problem. Last 24 hours it happened three times. The change i suggest is a "safety net", a sound level over 140dB should alway be ignored. now the spikes make the graph unusable because the scale will

change once the spike happens.

[hbitter]

Hi Bas, you should upgrade the Teensy firmware to DNMS_V2.1.4 gives 2 improvments:

• from 2.04 to 2.1.4 a glitch filter for the I²C connection was enabled - hope that helps
• firmware 2 uses full resolution of the microphone, so the measurement range goes now down to 29 dBA

The I²C extension can work up to 5m cable length, what can be more a problem, if the NodeMCU and the Teensy are located close to each other. Let me know if the firmware upgrade helps. Regards, Helmut

[BasvanDrunen]

Many thanks for yout help Helmut. The new software is now running for 24 hours without any problems so far.

For other people having this problem, i have connected the dmns board with a 4 wire flat cable from the pins on the dnms board to the extra I2C pins (5v) on the airRohr board and that works!

Still i think it would be wise to exclude very high and impossible noise levels e.g. Over 140 dB.

Best regards, Bas

[hbitter]

Hi Bas, good to hear that it works now as it should.

The question whether to suppress the transmission of wrong values (a value above 140 dBA would be wrong value anyway) or not is not that easy. It would be necessary if transmission is suppressed that some sort of information about the erroneous state is transmitted. Otherwise you wouldn't be aware of the problems at all. So yes, if error handling would exist, it would be good to use it and signal an error instead of a wrong value.

Regards, Helmut

[bertrik]

I think it could make sense to try and implement the transfer protocol as serial instead of I2C.

With I2C, you basically have two bidirectional lines (SDA and SCL) where a sender can only pull the signal level to 0, to create a 1 it has to rely on a pull-up, which represents a high impedance and is therefore susceptible to interference. You also don't really have a well-defined interfacing speed, the I2C master device dictates it and the I2C slave device has to adjust.

With a serial protocol, you have two unidirectional lines, making things more robust with respect to interference and a bit simpler in hardware since there's no more need for pull-up resistors. You can also define an interfacing speed, say 9600 bps. This is a bit slower than the typical 100 kbit/s for I2C but still fast enough. Slower signals are less critical w.r.t. interference and noise.

I would also use a different checksum scheme: use a stronger checksum (say 16-bit instead of 8-bit) and use it to protect the whole command/response message, not apply it to individual data items.

I think this could be made to work with minimal changes: use the same command/response structure, but wrap it in a serial framing protocol that defines the start-of-packet, end-of-packet and uses a stronger checksum. In hardware this means just omitting the pull-up resistors. The sensor.community airrohr-firmware will have to be updated to support the serial protocol, but I can imagine the code actually getting easier when changing from I2C to serial.

[mullercomms]

Hello terraformer,

as explained by ricki-z: due to the lack of logarithm functions in grafana the values displayed show the measurements not in dB but in pW/m2. So it is just a matter of the wrong unit shown in the graph. Maybe someone could correct this.

You can convert it back:

L = 10 log(value) db(A)

Hope this helps.