Who tried to read such BLE modules ?
Any info about the temperature, pressure, acceleration interpretation from the received bytes ?
I see that the digits depend on the exact model's firmware, but any some variant...
Any info about the temperature, pressure, acceleration interpretation from the received bytes ?
I see that the digits depend on the exact model's firmware, but any some variant...
Hello after execution in the console I get Complete list of 128-bit service UUIDs: K-UNIT TPMS, FE:50:BF:EA:0F:32, RSSI = -65, (MyMap) {1=[B@13006656, 9=[B@32ddf6d7, 7=[B@b01cbc4, 0=[B@1971aaad} LEN: 1: 06 LEN: 9: 54595245444F47 LEN: 7: 9ECADC240EE5A9E093F3A3B50100406E LEN: 0...
www.b4x.com
What module nRF51 do you have?
Edit, you probably already did it Also you can start with this:
This library replaces the previous BLE library. It is simpler to use and it is more powerful. Its API is based on B4i iBLE library which makes it easy to reuse B4i code. See the iBLE tutorial: https://www.b4x.com/android/forum/threads/ble-bluetooth-low-energy-library.46099/#content Tips &...
Thanks, i have already started
Now it's interesting the very important thing - see the parameters in degrees and g-acceleration.
CN seller gives the PDF description of wrong model, on CN and even if to translate it - no description how to interprete the HEX data from this model...
Espesially about the acceleration, for temperature, seems, i have "hacked" something, below.
And general question - how to use\interpret the advertizment data ?
Already finished: this round sensor PCBs are very interesting, but its firmware is buggy - it cannot work all the time, accelerometer data got zero after 4-6 hours of work, temperature sensor works OK, and the main BLE connection is OK all the time (20-40 hours of test). But without accelerometer data it's useless.
But the CN seller sent me 700+ MB of developing software, including sch diagram, PCB, seems some FW source codes, but ..... it's huge materials qty to develop myself after payment for the ready product.
"accelerometer data got zero after 4-6 hours of work"
So it works ok for 4-to-6 hours, and then the accelerometer data freezes at zero, but the temperature reading still works? Or is it that both readings stop being updated, and instead continually return the last value, which would be probably zero acceleration and a reasonable-looking temperature.
From a battery-preservation point-of-view, having a timeout on powering the sensors is a reasonable safety-net, although you'd think it'd be documented.
If you disconnect and connect again, do the readings become live again? Or perhaps there is some other way to "wake up" the sensor.
Yes! No hangs and freezes, just zero bytes of the acceleration after hours. Tested during a week, 3 examples. I needed them for the industrial control system. I even prepared the PCB of Li-ON battery charger controllers, batteries, wireless QI-chargers that allow to use these sensors for long time, but .... not stable sensor's result. Re-powering by the switch helps to reset, but ... it's a bug.
1/ you get no acceleration reading at all ie no bytes, or
2/ you still get acceleration readings, but they have value of 0
But you still get a temperature reading? Is the temperature reading still alive, like... if you stick the sensor in a fridge, or aim a heater at it, does the reading change?
I hope i explained clear, added video of 2 sensors among 3 (there is first video about the first sensor), dispute is won, adapters are on the way to the seller.
Nothing more to say. Just - no warranty to order these interesting sensors to get them ready to use. I have found 4 PCB versions of the exactly same sensors, just different PCB texts and colors.
Hi everyone,
I'm struggling to get my ble sensor tag to work properly. Did you manage to convert the 8-bytes that sensor produces for temperature and pressure from BMP180 sensor ?
From nRFConnect I got this for BMP data : 0x00-01-80-F4-00-00-00-1C which is supposed to be both temperature and pressure. I've compared to BMP180 datasheet but couldn't find how to calculate temperature and pressure from that.
I saw on several forums that people modified the firmware of nRF51822 to get it working as desired but I'm not an expert in that field. I'm just trying to monitor temperature from an Android device.
Before I even look at the datasheet, your 8 bytes of data look like two 4 byte (32 bit) numbers, the first one around 100000 which could well be air pressure in Pascals and the second is 28 which could plausibly be temperature in Celsius. Or that could all be a complete coincidence. ? Hang on a moment while I check out your doc.
but I think you've already got that far. The simpler solution might be to raise or lower the ambient temperature a couple of degrees, and see if the 1C (hex = 16 + 12 = 28 decimal) changes accordingly. You could try putting the device in the fridge for a while... not sure if BLE will make it through the metal outer, but a few minutes of cooldown should be enough to see a change even after it's removed from the fridge.
Also try raising and lowering the height of the sensor from the floor. Each metre should be around 11 Pascals.
Before I even look at the datasheet, your 8 bytes of data look like two 4 byte (32 bit) numbers, the first one around 100000 which could well be air pressure in Pascals and the second is 28 which could plausibly be temperature in Celsius. Or that could all be a complete coincidence. ? Hang on a moment while I check out your doc.
Here's what I found based on your (most probably correct) interpretation : I put the sensor in the freezer and waited to get down to negative values.
Here's what happened : indeed the last 4 bytes changed and decreased down to zero (00-00-00-00) then got negative (FF-FF-FF-FB) so I guess I can calculate temperature this way :
if [ hexString > 100 or anything high enough]
then
temperature = 255 - last byte
else
temperature = last byte
That will work, provided that you're operating within -155 to 100 degrees, and you change "255 - last byte" to "last byte - 256".
If the temperature is ambient and you're in it, then if it's outside of that range, presumably you'll be distracted by more pressing problems than integer wraparound. ?
That 99.99% confirms that it is a 32-bit integer. If it was 8-bit it would have changed to 00-00-00-FF, and if 16-bit then 00-00-FF-FF.
Did the previous value of 28 (decimal = hex 1C) match with your ambient air temperature? It is entirely possible that the temperature integer might be in 0.5 degC and that your ambient temperature was more around 14 degC, or in 0.25 degC (which I think is the scale used by OBDII) and ambient was around 7 degC.
edit: nope, OBDII temperature is in unit steps; it is RPM which is in 0.25 steps