Forum Sensor.Community

Sensor Kit #2 : why is it not available?

There is a blurred image of Sensor Kit 2 and it’s description on the https://sensor.community/en/sensors/: Sensor Kit #2 ESP32 SDS011
There is also code support but without binary builds.

What are the reasons Sensor Kit2 is still not available?

Lets check the status!

Sensor Kit 2 is like a Yeti. Everyone heard about it, but no one actually saw one :slight_smile:

To be honest, ESP32 comes in many different modules and chips revisions. That sometime complicates codebase a lot. Theoretically it should not matter beacause ESPIDK should translate everything. But in practice, code can be unstable without apparent reason - and requires more testing and fine tuning.

I am sure that in near future we will find reasonable good and cost efficient module and try to make official Kit 2 with stable firmware. I was thinking about using ESP32 D1 mini (MH-ET LIVE ESP32 MiniKit) module based on ESP32-WROOM-32. It’s cheap, small and got components only on one side - so we could solder it in like SMD part to PCB with connectors to avoid using dupont wires.

Why D1 mini instead of soldering esp32-wroom module?

We are planning to use the Heltec WiFi LoRa 32 (V2) for this. This would also allow to use LoRaWAN (TheThiungsNetwork) instead of WiFi network.
And using sockets would allow to replace faulty esp modules. So a PCB should be with as less a possible directly soldered components.

Do you want to make diy solution or device for sale?

We want to make a diy solution. For a device for sale we would need to give warranty (2 years in most european countries). But as you may have seen is Sensor.Community a project completely organized by volunteers.

From my observation it’s cheaper to take ready to use ESP32 D1 mini instead of soldering USB-UART converter, LDO, boot/upload logic and micro USB port. Also ESP32 D1 may be use as THT module with wires.

Although we do sell Heltec modules in Nettigo, I am not sure it’s the best choice for the job. It’s THT only. It has OLED which in most cases will be not used. It doesn’t have build in STEP-UP converter, so powering SDS011 from battery requires additional parts. And the question is do we really need LoRa radio in every sensor? Please notice the LoRaWAN radio in this module (Semtech SX1276) is also quite old. For LoRaWAN application I would pick dedicated solution like Heltec HTTC-AB01 - ultra low power in sleep (3.5µA).

From my perspective mix of both worlds is the best solution. Open hardware solution which can be manufactured and assembled by every capable company around the globe. This way final solution is scalable, price is fair and carbon footprint may be optimized by producing sensors near end user.

We give 2 year warranty for S.C kits we sell. I don’t think it’s a problem if you account that in KIT price. The same goes for customer support, answering countless emails, etc.

Any difference between DIY kit and fully assembled device is FCC certification and CE compliance.

I may be wrong, but lorawan is software level protocol over hardware lora modulation and coding.

LoRaWAN is a protocol. LoRa is chirp modulation (similar to FSK). LoRa technology is patented by Semtech. So it’s produced and licensed by Semtech.

There is LoRaWAN stack implementation made by IBM called LMIC (LoraWAN-MAC-in-C).

To uses LoRaWAN you need infrastructure like gateways, nodes, app servers, etc. This is provided by TheThingsNetwork but you also can do it on your own.

The Heltec LoRaWAN board with the display is for development. The pinout for the versions w/o display or LoRa module should be nearly the same. But to decide which pins can be used we should use the board with all options. Otherwise we would need to develop different firmware versions for each and every possible board.

I know, but I cant understand your thoughts about old sx12xx. All *WAN operations provided by external mcu or not?

No need to support ALL possible boards! On the other hand supporting only single board is also not the best idea as there might appear cheaper and more advanced boards.
If PINs can be redefined in the program what is the reason not to use the board?!
Of course, if supporting the board will requite much effort then it will be other story…

More than 90 percent of our users are building the sensor themselves from individual parts. So we try to use as few parts as possible (and without soldering if possible).
DYI is one of the factors why people are part of the project for a long time. Buying a device ready to use isn’t motivating as much as building it by yourself.

I am talking about similar boards but with different wiring. The only difference would be to connect sensor cables to the proper pins of the board. On one board it would be pin 1 and 6 on another 2 and 3.

Anyway, in the world of FOSS one cannot dictate the rules. If there will be enough users to support specific board they can do it on their own. If their initiative will be sustainable it can be merged upstream. I think this is the good way for FOSS project.

LoRaWAN evolves all the time. Newer radios support newer versions of standard.

As an example. I bought TTGO (a brand name of LilyGO) with Lora. It has almost the same pinout with slight differences from Helltec. Why not to support TTGO then?!
TTGO:

WiFi LoRa 32 (V2)

Could you provide an example of update in modulation or coding Or other feature update where old modem not supported??

You can use whatever board you want to use. You may only have to compile your own firmware for this (i.e. with a modified version of our firmware). Or you may have to look for the right pins.
But sensor.community is organized by volunteers. So we have to “optimize” some things to get things done.
Even if we have developed the actual firmware for the NodeMCU v3 ESP8266 board there are users that use WeMOS D1 mini, NodeMCU v2 boards or others.

But what is missing for making Sensor Kit 2 public? Is it the guide or something more?
Maybe Kit2 is not yet production ready, but it is for sure in beta stage!

We weren’t able to test the firmware with the supported sensor types until now. It’s compiling, but we don’t know if it’s working as expected. (TTN support is completely missing at the moment)