Arduino.ru

Большая просьба не комментировать этот пост, так как возможны дополнение и актуализация сведений, приведенных в нем.

 

Датчик не без проблем.

 

Первая: питание датчика +5V (для работы вентилятора), а TTL-уровень UART - 3.3V. Эта неприятная особенность частично нивелируется тем, что для получения данных достаточно только одного выхода TX, который, полагаю, может быть подключен напрямую к микроконтроллеру с 5V TTL при условии, что соответствующий вывод МК будет всегда находится в состоянии INPUT.  Однако, я не рискнул и применил преобразователь логических уровней такого типа (на борту стоит стабилизатор 3.3V, что избавляет от необходимости искать это напряжение на стороне) https://ru.aliexpress.com/item/5pcs-free-shipping-IIC-I2C-5-3v-level-shifter-module-Conversion-sensor-system-compatible-for-Arduino/32624528143.html

 

Вторая: интерфейсный разъём специфический и имеет шаг (pitch) 1.27мм.

Расследование показало, что внутри установлен разъем Harwin M50-4910545R , ответной частью к нему служит Harwin M50-4300545. Продавец положил в комплект отдельное гнездо типа Minitek 1.27 / PBD1.27-10 (2x5, DIP) и готовый переходник с такого гнезда на не менее дурацкий однорядный разъем с тем же шагом - 1.27мм.

Анализ сложившейся ситуации показал, что выходом из нее могут быть:

1) Комплект из дешевого переходника SOP-14 и PBD1.27-10S (SMT модификация);

2) Сверление переходника SOP-14 -> DIP под PBD1.27-10 из комплекта;

3) Отрезание одного из разъемов на шлейфе из комплекта;

4) Использование кабеля/переходника для SWD-программатора;

5) Изготовление переходника методом ЛУТ;

 

В соответствии с англоязычной документации (или оригинальной китайской), датчик после включения переходит в так называемый "активный" режим и не требует подачи дополнительных команд для начала передачи метрик. Интервал передачи (не обновления!) значений метрик происходит каждые 800...200мс. При незначительном изменении концентрации регистрируемых частиц, актуализация данных происходит в "стабильном" подрежиме - каждые ~2.3 сек. Таким образом - в течении ~2.3 секунд трижды передаётся одно и то же значение. Резкое изменение концентрации (уровень не выяснен) приводит к переключению датчика в "быстрый" подрежим - время актуализации и передачи данных начинает снижаться до 200мс, таким образом каждый раз происходит передача обновлённых значений метрик.   

 

Собственную программную реализацию работы с сенсором приведу чуть ниже. Так же можно посмотреть на скетч от Adafruit. Те модели, по которым я нашел описания, имеют одинаковый протокол обмена (PMS-5003, PMS-7003), так что можно брать любой доступный скетч для PMS-x003.

 

Моя версия кода. Вырезана из более объемного прожекта, поэтому некоторые приемы экономии на спичках могут показаться странными.

#include <SoftwareSerial.h>

#define PLANTOWER_UART_TX_PIN                                   (3)
#define PLANTOWER_UART_SPEED                                    (9600)
#define PLANTOWER_DEFAULT_READ_TIMEOUT                          (2500UL)

// Store all metric's value in the pretty struct
typedef struct {
  uint16_t frameLength;
  uint16_t standartPM10, standartPM25, standartPM100;
  uint16_t environmentPM10, environmentPM25, environmentPM100;
  uint16_t particles03um, particles05um, particles10um, particles25um, particles50um, particles100um;
  uint16_t unused;
  uint16_t checkCode;
} plantowerData_t;

// Get all metrics at once
uint8_t getPlantowerPMSMetrics(const uint8_t _rxPin, const uint8_t _txPin, plantowerData_t* _ptrPlantowerData) {
  uint8_t rc = false, headerDetected = false,
          writePos = 0x00;
  uint16_t checkCode;
  uint32_t readStartTime;

  // Reuse struct cells as work array
  uint8_t* ptrRawBuffer = (uint8_t*) _ptrPlantowerData;
  uint16_t* ptrConvertedBuffer = (uint16_t*) _ptrPlantowerData;

  SoftwareSerial swSerial(_rxPin, _txPin);
  swSerial.begin(PLANTOWER_UART_SPEED);

  readStartTime = millis();
  // Wait for all bytes for structure readed until time is not out
  while ((sizeof(plantowerData_t) > writePos) && (PLANTOWER_DEFAULT_READ_TIMEOUT > millis() - readStartTime)) {
    if (!swSerial.available()) {
      continue;
    }

    ptrRawBuffer[writePos] = swSerial.read();
    //Serial.print("currentChar (# "); Serial.print(writePos);  Serial.print(") => 0x"); Serial.println((byte) ptrRawBuffer[writePos], HEX);

    // Header of packet: 0x42 0x4D
    // On header waiting test first two byte every time when its in buffer (writePos == 0x01)
    // if signature is detected - write real data from the start of buffer
    // if not - just move second byte to first position and continue writing to the next cell of buffer
    if (!headerDetected) {
      if (0x01 == writePos) {
        headerDetected = (0x4D == ptrRawBuffer[0x01] && 0x42 == ptrRawBuffer[0x00]);
        if (headerDetected) {
          continue;
        } else {
          ptrRawBuffer[0x00] = ptrRawBuffer[0x01];
        }
      }
    }
    writePos++;
  }
  // Reading is not finished sucessfully
  if (writePos < sizeof(plantowerData_t)) {
    goto finish;
  }

  // Checkcode is sum of all bytes except packet's "check code" value (2 bytes). Two first byte always is 0x42 & 0x4D and can be precalculated
  checkCode = 0x42 + 0x4D;
  for (uint8_t i = 0; i < (sizeof(plantowerData_t) - 2); i++) {
    checkCode += ptrRawBuffer[i];
  }

  // Convert bytes to uint16_t
  for (uint8_t i = 0; i < (sizeof(plantowerData_t) / 2); i++) {
    //    uint16_t tmpValue = (ptrRawBuffer[0x00] << 8) | ptrRawBuffer[0x01];
    //    *ptrConvertedBuffer = tmpValue;
    // It's safe ?
    *ptrConvertedBuffer = (ptrRawBuffer[0x00] << 8) | ptrRawBuffer[0x01];
    ptrRawBuffer += 2;
    ptrConvertedBuffer += 1;
  }

  //Serial.print("checkCode (calc): "); Serial.println(checkCode, HEX); Serial.print("checkCode (read): "); Serial.println(_ptrPlantowerData->checkCode, HEX);

  rc = (checkCode == _ptrPlantowerData->checkCode);

finish:
  swSerial.~SoftwareSerial();
  return rc;
}

/***********************************************************************************************/
void setup() {
  Serial.begin(115200);
  Serial.println("Let's read!");

}

void loop() {
  uint8_t rc;
  plantowerData_t plantowerData;

  while (true) {
    Serial.print("\n\nTimestamp: "); Serial.print(millis());

    // RX pin does not used anyway
    rc = getPlantowerPMSMetrics(PLANTOWER_UART_TX_PIN, PLANTOWER_UART_TX_PIN, &plantowerData);
    if (rc) {
      Serial.println("\n---------------------------------------");
      Serial.println("Concentration Units (standard)");
      Serial.print("PM 1.0: "); Serial.print(plantowerData.standartPM10);
      Serial.print("\t\tPM 2.5: "); Serial.print(plantowerData.standartPM25);
      Serial.print("\t\tPM 10: "); Serial.println(plantowerData.standartPM100);
      Serial.println("---------------------------------------");
      Serial.println("Concentration Units (environmental)");
      Serial.print("PM 1.0: "); Serial.print(plantowerData.environmentPM10);
      Serial.print("\t\tPM 2.5: "); Serial.print(plantowerData.environmentPM25);
      Serial.print("\t\tPM 10: "); Serial.println(plantowerData.environmentPM100);
      Serial.println("---------------------------------------");
      Serial.print("Particles > 0.3um / 0.1L air:"); Serial.println(plantowerData.particles03um);
      Serial.print("Particles > 0.5um / 0.1L air:"); Serial.println(plantowerData.particles05um);
      Serial.print("Particles > 1.0um / 0.1L air:"); Serial.println(plantowerData.particles10um);
      Serial.print("Particles > 2.5um / 0.1L air:"); Serial.println(plantowerData.particles25um);
      Serial.print("Particles > 5.0um / 0.1L air:"); Serial.println(plantowerData.particles50um);
      Serial.print("Particles > 10.0 um / 0.1L air:"); Serial.println(plantowerData.particles100um);
      Serial.println("---------------------------------------");
    }
    delay(1000);
  }
}

Интерпретация значений

Сразу интересный факт: заголовок пакета схож с заголовком BMP-файла.

В пакете, получаемом от сенсора, можно увидеть следующие подвиды метрик: "Concentration unit (CF=1, standard particle)" , "Concentration unit (under atmospheric environment)", "The number of particles with diameter". 

На данный момент однозначно понятна только последняя, представляющая собой RAW-данные - количество частиц разных диаметров (в штуках), пролетевших мимо фотоэлемента за известный только одному производителю период. 

По поводу первых двух, полагаю, стоит опираться на "Note: CF=1 should be used in the factory environment". Т.е. в производственных условиях учитывать значения "CF=1" метрик, а в домашних - "under atmospheric environment". Хотя, на мой субъективных взгляд, большого разброса в них нет.

Я нашёл небольшую дискуссию по этому поводу: https://publiclab.org/questions/samr/04-07-2019/how-to-interpret-pms5003-sensor-values#c23772 , но вынужден констатировать, что приведённый ответ носит лишь предположительный характер.

Ben Kinh Tan в своей работе "Laboratory Evaluation of Low to Medium Cost Particle Sensors" пишет следующее: "Number concentrations are divided into six size channels. For mass concentration, the sensor reports readings for a ”standard” and ”atmospheric” type particle. The “standard” reading refers to industrial metal particle densities used for mass calculations and is suitable for environments such as an industrial production workshop. The “atmospheric” reading refers to pollutants commonly found in the atmosphere, and suitable for use in an indoor environment."