| T O P I C R E V I E W |
| ullix |
Posted - 01/13/2022 : 02:41:17
I am neither interested in fake passports, nor in fake Drone attacks, but beyond Geiger counts I am interested in measuring environmental variables, including CO2.
This had been discussed in this forum some long time ago, with no result, at least with respect to any GQ device. But what can you do when you have no sensor?
This situation may have changed only recently, when a miniaturized sensor for the I2C bus became available. This will be supported in upcoming GeigerLog 1.3.0.
For now I went through a thorough assessment of I2C devices and dongles (which you need to connect I2C devices to your computer) and published this as "Review of USB-To-I2C Dongles as used by GeigerLog" downloadable from my Articles page: https://sourceforge.net/projects/geigerlog/files/Articles/ Some surprise: "Grand-daddy runs circles around hip youngster".
The CO2 device SCD41 is small enough to easily integrate into a Geiger counter. However, it would have an impact on the bill of materials: single unit pricing is around $50.
|
| 10 L A T E S T R E P L I E S (Newest First) |
| ullix |
Posted - 01/22/2022 : 05:06:15
I have just completed my assessment of devices capable of measuring CO2 with connection to GeigerLog, which are the devices SCD30, SCD41, and MiniMon.
In short, they all work for the intended purposes.
Download: "Measuring CO2 with SCD30, SCD41, and MiniMon"
from my articles page: https://sourceforge.net/projects/geigerlog/files/Articles/
For something cross-platform capable and to experiment with, choose the SCD41 on the USB-ISS dongle.
|
| Damien68 |
Posted - 01/16/2022 : 05:02:52
for the FT232H technically in the configuration used (MPSSE), ADBUS7 is just an general purpose IO.
https://ftdichip.com/wp-content/uploads/2020/07/DS_FT232H.pdf
(see chapter 3.2).
everything must be in the implementation made in the source code but I suspect that the clock stretching function only checks the state of the SCL line between sending two bytes, otherwise, it would ask to send at least two or three commands to send each bit, which would be huge.
I also suspect that the SCD30's i2c transceiver is just a software emulation (bit banging), and can do clock stretching at any time, even between two bits of same byte, this depending on IT or others.
it's just speculative
about bit banging:
https://en.wikipedia.org/wiki/Bit_banging
EDIT:
for SCD30, Sensirion specifies the i2c max bus speed of 100kHz but recommends 50kHz.
on the microcontroller I use (CC1352P), the minimum speed is 100kHz, so I couldn't select 50kHz, it works.
EDIT2:
otherwise in 99.9% of cases an i2c device has at least one hardware shift register to transmit by packets of 8 or 16 bits at high speed and without hassle. I suspect that is not the case with SCD30.
EDIT3: what is certain is that the FT232H does not support clock stretching natively, but by a work around.
|
| ullix |
Posted - 01/16/2022 : 00:50:44
The lack of clock stretching is my suspicion too.
However, the FTDI is just a dumb chip which permits to juggle its output pins. It is not supposed to offer clock stretching.
The software would've to take care of it, and the software claims it does support clock stretching, provided some hardware connections are made. And they are made.
https://eblot.github.io/pyftdi/api/i2c.html?highlight=stretching#wiring
There is no reason to question the functionality of other devices, as they all work with the sole exception of the SCD30 on the FT232H dongle.
One is on safe and fast ground using the USB-ISS.
|
| Damien68 |
Posted - 01/15/2022 : 08:23:24
@ullix, you are right, a user thinks that the FT232HQ certainly does not support clock stretching:
https://github.com/adafruit/Adafruit_CircuitPython_SCD30/issues/18
I went through the FT232HQ datasheet
https://ftdichip.com/wp-content/uploads/2020/07/DS_FT232H.pdf
as well as the I2C-specific application note:
h**p://www.ftdichip.com/Support/Documents/AppNotes/AN_113_FTDI_Hi_Speed_USB_To_I2C_Example.pdf
nowhere it talk about clock stretching, if it was supported it would be indicated, so thats must be the cause.
otherwise the SCD30 works very well coupled with a microcontroller and ultimately is very reliable (several months with incidents that are logged but restored automatically). to achieve this, it requires manual access to the SCL output to possibly clear the i2c bus when it stucked.
for the SCD4x it may be different. |
| ullix |
Posted - 01/15/2022 : 05:33:20
@Damien: thanks for the link. It turned out I looked online at a datasheet from 2018, while my local copy is the most recent from 2020. The latter is the basis for my program, and the little differences to the old sheet are already incorporated in GeigerLog.
Putting a delay between the commands is actually a pretty trivial task.
GeigerLog handles all NACK issues (knock on wood ...), and, as I said, so far it is running for days without problems.
It is just this one dongle (Adafruit FT232H) which is making problems, and only with one sensor (SCD30). Looking at the Adafruit forum I see there are already plenty of posts reporting problems with the SCD30.
If you wanted to measure CO2 at home, you wouldn't use this sensor anyway. You'd use the SCD41. And on a USB-ISS dongle.
|
| Damien68 |
Posted - 01/14/2022 : 07:29:27
indeed the SCD41 is very small 10.1 x 10.1 x 6.3mm |
| Damien68 |
Posted - 01/14/2022 : 02:29:44
quote:
Originally posted by ullix
You did not notice that this is already done in the review?
Ok you are right, indeed sorry I had not read the middle pages |
| Damien68 |
Posted - 01/14/2022 : 01:21:34
The document is the following one:
https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/9.5_CO2/Sensirion_CO2_Sensors_SCD30_Interface_Description.pdf
|
| ullix |
Posted - 01/14/2022 : 01:14:36
@Damien: good to see that I am not the only one scratching his head over the SCD30 sensor!
But if you read my review completely you will have noticed that 3 out of 4 dongles can interact with that device perfectly well over multi-day runs. It is the 4th dongle, the modern, FTDI chip bases one, which makes problems.
I can't tell whether there are any once-per-week glitches. Any such communication failures also occur e.g. with the GMC counters - only more often ;-) - and GeigerLog takes care to gracefully recover, both itself and the device. Do not crash is the main concern. I have not seen an unrecoverable stuck bus.
I have several documents on the SCD30, but none even has a chapter 1.4.4. Would you mind sending me the doc you referred to?
quote:
do you compare the performance of the two sensors SCD30/SCD41?
You did not notice that this is already done in the review?
The SCD30 is of interest for technical curiosity, but if one were to put a CO2 sensor into a consumer device, one would use the SCD41. Their price is about the same, and the SCD41 is quite a bit smaller. Though still too big to fit into a smartphone, it would fit into a Geiger counter, as its width is about the diameter of a M4011 tube. |
| Damien68 |
Posted - 01/13/2022 : 08:12:08
Hi ullix,
I just see your review on sourceforge, it is very concise, I also use the SCD30 so I wanted to share my experience:
it is not easy to implement, there are several delicate points including one that I am not sure you can handle because you are using a dongle USB <-> I2C
the first problem that I had is that there are wait states to place in a lot of places (it's not easy to see). but for example on chapter 1.4.4 of the document "Sensirion_CO2_Sensors_SCD30_Interface_Description.pdf" it is necessary to read:
"Note that the read header should be send with a delay of> 3ms following the write sequence"
in I2C to read a register, in general the host microcontroller uses a single transaction which initially sends a write sequence (containing an OPCODE and / or the address of a register to read), then instantly after sends a reading sequence to read the response.
with the SCD30 between these two sequences its necessary to insert a delay of 3mS
also it is necessary to divide the transaction in 2 basic transactions spaced by a delay of 3mS. the first one is only a writing sequence the second one is only a reading sequence.
a second point is that at times I find myself with NACK addresses or NACK data, that is to say that the sensor does not respond to commands.
by polling the sensor every second it happens once a day on average.
I never have that with other devices. This must be due to the slave implementation made on the sensor CPU. in this case it is necessary to monitor and manage the error codes received.
the third point is more delicate and is that sometimes (once a week on average) I end up with a stucked bus, that is to say that the sensor maintains the SDA output at '0' indefinitely, which means that the master CPU can no longer send start conditions or stop conditions in fact it can no longer control the bus, at this time it is necessary to reset the bus, i.e. deactivate the i2c tranceiver of the master CPU, send manually 21 cycles on the SCL output and reactivate the i2c transceiver of the master CPU, I'm not sure this is feasible with a dongle, but it's still a classic problem with i2c buses so maybe there is a function accessible on the usb<->i2c dongle driver.
below is an example about same probleme:
https://www.forward.com.au/pfod/ArduinoProgramming/I2C_ClearBus/
(see I2C_ClearBus() method)
do you compare the performance of the two sensors SCD30/SCD41?
|
|
|
