I noticed the nRF52840 (in the Boron and perhaps other Particle devices) has a comparator function for the analog (ADC) inputs. But I don’t see the comparator features are exposed in the Particle OS. I’m working on a new product that has need for a comparator input. Comparator support in firmware would save me having to add some electronic components.
1 Like
Hi @KanyonKris Thanks for suggestion- we don’t currently offer Comparator Support but hope to offer it in the future. What sort of project are you working on?
1 Like
I created a library to use the LPCOMP (low-power comparator) hardware in user firmware. It seems to work properly but is a brand new library.
The documentation is here. It’s in the community libraries under ComparatorGen3_RK as well.
4 Likes
@Colleen I’d like to connect a TI LMT01 2-pin temperature sensor (datasheet) to a Boron. This TI device sends data back to the host by changing the current draw. Page 16 of the datasheet shows that when the LMT01 is connected to a MCU with a comparator input only a pull-down resistor is needed. Page 19 shows that without a comparator input, 2 resistors and a transistor are needed. In addition to only needing 2 wires, the LMT01 also allows a long wire run between the host and sensor since it uses changes in current to send data. I am working on a product that requires the features of the LMT01 and would prefer to save a little money by only needing a pull-down resistor.
@rickkas7 I will try the LPCOMP library. Thank you.
The comparator will results may be inaccurate for a different reason. The pulse frequency of the LMT01 is ~90 kHz, and that’s the upper bound of reliable interrupts on the nRF52. You will likely lose interrupts, possibly as many as 1/10 of them, at that rate, which will cause a lower temperature reading than actual.
It’s possible that using the comparator with a very high interrupt priority may help, especially since all you need to do is increment a counter since all you care about is the number of pulses. That may be sufficient to get it to work reliably enough and is worth a try.
The way I would do it is use the transistor circuit to create a digital bit stream instead of analog, then read the entire pulse train using the I2S (sound interface, not I2C) peripheral. The advantage of the I2S peripheral is that that you can run it to sample an arbitrary digital signals at high rates. Because the data is captured in hardware and written to a buffer in RAM by DMA it’s not affected by interrupt latency and higher priority interrupts.
Unfortunately the nRF52 does not have a hardware pulse counter, which is what would be ideal for the LMT01.
4 Likes
@rickkas7 good points.
I2S is a good idea. Your DHT22/11 library is a good example. I see I2S has a max sample rate of 48kHz, will that work for counting a 90kHz pulse train? If not then I’ll need to rethink my design.
48 kHz is the stereo sample rate at 16 bits, so the bit clock is actually 1.5 mHz, which is way higher than you need. I’d try to aim for 400 kHz or so, but the actual rate isn’t that important.
1 Like
@rickkas7 ah, yes, that’s right. I’ll order the parts and start coding. Your DHT library will be very helpful, thanks for that.
1 Like
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.