MCF88-LW12TERWP Payload Decoder

robputt796 · July 22, 2020, 9:32pm

Hello,

I have recently been lent a MCF88-LW12TERWP to play with, hardware-wise its a nice device and I like the NFC config capability however I cannot work out how to decode the payloads…

The “data sheet” from the manufacturers’ website is next to useless at describing anything other than the very high-level features of the device - https://www.mcf88.it/prodotto/mcf-lw12terwp/

I was hoping somebody may already have a JS decoder I can use for this device that plugs directly into the Payload Decoder in TTN console.

Here is an example of the payload spat out by the device… 048DB1F62883095EA38C01CFB2F62880095FA28C0112B4F628770961A58C0164

Many thanks in advanced.

Best Regards,

Rob

arjanvanb · July 22, 2020, 10:04pm

Did you try the decoder from Mcf-lw12terwp?

robputt796 · July 23, 2020, 7:06am

Hi,

Yep that seems to work fine, I am not a great JS guy so my conversion will probably be less elegant than others could achieve, I’ll probably shove my attempts on Github as it seems nobody else has a decoder for the TTN decoder yet.

Best Regards,

Rob

robputt796 · August 2, 2020, 8:37pm

Hi,

I made some progress on porting the Python stuff linked to JS so it can be used in TTN Payload Decoder however I can’t get the minutes working…

Here is what I have so far - https://gist.github.com/robputt796/02e54443811f0f8a1e9ccdb7fa16d3a1

Here is an example input - 04 E4 A5 02 29 56 09 66 22 8B 01 26 A7 02 29 56 09 68 27 8B 01 E9 A8 02 29 54 09 67 2D 8B 01 64

Which gets decoded to - https://gist.github.com/robputt796/f80909a9bef0ce5589a1b7b9ede5e147

The time is the first 4 bytes of each measurement and then the minutes is the last 3 bits of the 3rd byte and the first 3 bits of the 4th byte. I am successfully decoding the day/month/hours etc… it’s just the minutes that I can’t decode, the minutes in the output gist are incorrect. I tried doing what I did for the month as that also straddles two bytes, but I couldn’t get it working .

Any help to get this up and running would be greatly appreciated. It’s probably something simple/dumb that I am missing.

Best Regards,

Rob

robputt796 · August 2, 2020, 8:48pm

Alright, all fixed with help from @TonySmith

Here is the decoder if anyone else has one of these… https://gist.github.com/robputt796/04f30942b1c596b0e32f3762f48eb45f

arjanvanb · August 9, 2020, 10:11am

Just to be sure: did you see the remarks I left 5 days ago? You may not need support for negative temperatures, but I’m quite sure the bug with the date handling will bite you in 2021, if you rely on that.

(Aside: in case you did not know, you can edit gists; no need to create a new one for fixes.)

robputt796 · September 29, 2020, 11:22am

Hi @arjanvanb,

Thank you very much for your contribution, I have now updated the decoder to include the correct year handling and also negative temperatures. Here is the latest for anyone who is also trying to decode this sensor.

gist.github.com

https://gist.github.com/robputt796/7115eb4f74fa2ab290e4ef996af2da02

gistfile1.txt

function decode_measurement(bytes) {
  date_time = bytes.splice(0,4).reverse();
  temperature = bytes.splice(0,2).reverse();
  humidity = bytes.splice(0,1);
  pressure = bytes.reverse();

  payload = {
    year: (date_time[0] >> 1) + 2000,
    month: (date_time[0] & 1) << 3 | date_time[1] >> 5,
    day: date_time[1] & 0x1f,

This file has been truncated. show original

Best Regards,

Rob

valdigfi · January 21, 2021, 3:23pm

Thank you for this. I have similar MCF-LW12VOC sensor that is giving bit shorter output. Could this script be somehow customised for it?

Example payload: 0C7373352AE5092E2389012C0027000674352ADD092E2189012A0023005A

(should include date 21.1.2021)

Thank you for your help!

Best,
Valtteri

cslorabox · January 21, 2021, 7:11pm

This is a very unfortunate design - it’s quite pointlessly burning a lot of airtime sending information that might as well just be taken from the receive metadata. On TTN that means you’ll probably need to reduce the transmission rate (at least when operating at slower spreading factors) to comply with the usage policy; in some jurisdictions this packet wouldn’t even be legal unless running at SF9 or faster.

As such this is a reminder why off the shelf nodes with fixed firmware are probably not a good idea; rather you want off-the-shelf hardware where you can (either with or without support of the manufacturer) make the firmware behave in a way optimal for actual use.

alexfritz · January 25, 2021, 2:58pm

Hi

have you tried this: GitHub - SensationalSystems/MCF88_LW12CO2_Decoder: Decoder for the MCF88 LW12CO2 LoRaWAN Indoor Environmental Sensor with VOC, LUX and CO2

Regards
Alex

robputt796 · January 25, 2021, 7:11pm

@cslorabox

Yes, I can agree with this, you could just offset these date / times from the receive time meta data, normally with my own nodes I use the bare minimum data for the payload. I did a tear down of these and found under the hood its a BME280 sensor so this could be replicated fairly cheaply (<£30, TTGO ESP32 + BME280 and a lithium battery, probably get a decent duration out of it at SF7 and deep sleep) which makes me wonder how on earth MCF88 got to a £240 price point, I guess they use a really expensive test house or their volumes are not high enough to achieve cheaper pricing. In this case I had to use off the shelf nodes due to compliance reasons. But yes 12 bytes could be saved per transmission which is quite some air time at higher spread factors, for completeness they could make this optional in the firmware I guess…