So my final question is can we assume that we just divide 16g / (sensor value) and this gives us the value in g for each axis. 16000 mg is 16 g
Also the max and min values are only an indicator of the max and min values recorded at each 500 ms interval during the sample period right they don’t have any impact on using this value for the calculation above right?
So for testing I shook the sensor and I think am getting correct values now, I got this value at the sensor:
rms_x: rms_x: 15490.55
So if we do the calculation we get:
16000/15490.55 = 1.03 g
This makes sense to me but I am not 100% sure as I don’t know what the actual scaling factor is I am assuming 16 g or 16000 mg?
Hi,
I think @TravisE_NCD_Technica released a new firmware which will fix the high values issue in micro gateways. Travis i think sensor type 40 will also need vibration calculation update if you havent done it already.
After updating the firmware gateway will send correct data.
No, the vibration values doesn’t need to be divided by 16g.
The values are calculated for that 500 msec period.
Thanks
The issue is that we are getting massive values from the sensors … this could be 16000-250000 and I dont know what these values mean? Can you clarify this?
I have a megamodem which Jacob created a new flash for and loaded the MQTT gateway onto it … dont know if this is causing an issue?
This just happened without me changing any settings in the gateway was working perfectly and then this …
I also have another issue now the gateway is a SOLID BLUE and I did not change any settings or anything just happened to do that for a while and then I it just goes RED? Then it goes no color(BLUE/RED dim) and then BLUE again I tried flashing it again with the MQTT but it fails with fail cu? Is there anything I can do to fix this?
I tried loading the Megamodem firmware it loads but does nothing? Then I tried loading the MQTT firmware again but it fails cu message. Now I just get red/blue dim led nothing else?
It has a weird wireless network ESP_9600A5 and now works kind of normally with BLUE flashing but I think its doing something strange?
@Anil_Bhaskar the update I released applies to all sensors that calculate a 24bit reading so it applies to sensor type 40 as well. I released this update for The MQTT Gateway so if the Python flash script is used to flash the gateway to MQTT Gateway firmware this should fix the incorrect vibration readings.
I will attempt testing with a type 40 sensor today.
@corptek what you are describing almost sounds like a hardware error of some sort on the Gateway. can you post a screen shot of the flash error you get when trying to flash The MQTT Gateway or just paste here the output of the log?
I apologize. This flash script is only a few days old. I made a correction to the Python script. Please re download and try running the script again, it should work now.
Yes it appears to be working now the values are normal in mg I think at rest I am getting:
{“Gateway ID”:{“transmission_count”:225,“battery_level”:2.85936,“type”:40,“node_id”:1,“rssi”:100,“rms_x”:29.86,“rms_y”:48.22,“rms_z”:240.35,“max_x”:133.36,“max_y”:124.37,“max_z”:0,“min_x”:-109.2,“min_y”:-199.5,“min_z”:-392.28,“temperature”:20}}
It seems that the sensor is not resetting to a lower value when we run it for a while and then stop it doesnt seem to be dropping values down to almost zero?
As you can see here there is absolutely no movement but we are still recording these value coming from the gateway? Can you tell us what is happening here?
I also checked the gateway as well directly in case we made some error:
I basically just moved it to the drop drill and just ran it. What is the exact process to calibrate when putting on a new motor can you go through it for me please as its not clearly documented?