Hello Luc,

Please use the values on the website, there’s a post processing on the server side, compensating for some temperature and humidity aberrations caused by the metal enclosure. Also, as you know, the sensor for these is the Bosch BME680. Bosch has an Air-Quality library that we just received, and we are in the process of integrating it on the server side. Its purpose is similar to what we have already, but designed specifically for their hardware. This will impact VOC readings too, returning Air Quality scores instead of sensor resistance.

For the Noise sensor, I will get back to you later. Please keep the feedback coming! This only helps improve things. Thanks! Radu

currently there’s a macro in the firmware that if set will mute the device, but you’re right , we need a config option instead! Added to todo list, thanks.
use the server API to retrieve and store data (www.uradmonitor.com/dashboard).

This one?
https://hackaday.io/project/12066-uradmonitor-a3/log/59583-hw105-succes

These were two units placed on the outdoors one next to the other, very close to a moderate traffic road. Daytime traffic became visible due to elevated noise levels.

Reading high values without the mic connected is normal in some circumstances. The middle point of the PCM signal would produce a 0 on noise level, but that is not the case with the mic removed we can sometimes be situated at the bottom of the PCM signal, approaching us to a maximum noise value.
Even so, your noise level data doesn’t seem right. It might be a problem with the microphone, it might be a problem with the amplifier, I can’t tell. We would need to arrange shipping the unit back so I can have a look at it.

The noise sensor feature is currently experimental and got a bit too much exposure, also thanks to the forum community here (https://www.uradmonitor.com/topic/voice-sensor/). We got to roll it out a bit too soon, and there are major two issues:

1.Apparently, the issue is with the builtin fan, that creates too much noise in the same enclosure with the noise sensor. What happens is sounds below 45dBA cannot be detected.
2.Then the first boards was using an amplifier gain configuration of 100, a bit too much. This created some saturation, that we can see on the data from the various units.

The fix for 2 involves only changing a resistor on the PCB (R28 from 100K to 39K) and updating the firmware. The fix for 1 doesn’t have a solution with the current design.

Attached please see noise-1.jpg illustrating the first issue. 82000071 and 82000088 are assembled and PCB is in the enclosure, while the 82000089 PCB is at first left unassembled.
Probably the best solution is to do the fix with the resistor+firmware, and install the microphone via a longer cable, away from the FAN.

I think the cost of the A3 is above what most people feel they can afford, so I guess most will choose the lowest cost option.

Could it be an idea to remove the sound sensor from the A3 unit and try to reduce the cost further by maby removing more sensors from it? Then add a connection that let you add an external module to the A3, so it it possible to upgrade it.

With a sound sensor in this external module the problem would be solved, and the entry cost for the A3 would be cheeper.
Tho it would be more costly to buy a complete set, I guess more people would upgrade over time.

Or maby add the sound sensor and connection option to the uRADMonitor model A, and have an upgrade that give what the A3 provides today? I think maby fewer models, but with upgrade option, would be easier to handle in the future.

Absolutely, a modular design could be very useful here, exactly as per your remarks. The issue is that initially the first product, the model A, was rainproof, and there any modularity would overcomplicate the design.

Now that so many hardware variants became available, it makes sense to reconsider modularity.