Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
OK I jumped the gun a bit there, different application of pifm. I had issues initially with only a single tone playing and together we fixed it. If that doesn't solve youe issue I'll remove my answer
At the end of that adafruit tutorial it has the other device modes listed with the disclaimer that this is all experimental learn.adafruit.com/… Am I missing something here? These would all be USB gadget mode (i.e. not host) correct? and not serial / ethernet only? Personally, I've only used the serial and ethernet modes for the zero, I'll try out some others this weekend perhaps Further thought process on the details going in the tutorial seem to be here: github.com/raspberrypi/linux/issues/1212
@goldilocks thanks for that tip - I did not realize you could only run serial over USB OTG. Thanks for clearing that up for me. I have to imagine in the near future someone will have HID and MSD figured out - isn't is just software configurations? But for OP, this might be too late in development for your project.
I have actually used a raspberry pi for remote monitoring and verification of an offsite piece of equipment (at a manufacturing site). It is outside the scope of this site but message me and I'd be happy to point you in the right direction with regards to staying FDA compliant with your system
I wouldn't go with anything but the latest model to ensure you have the most horsepower for your application. If that doesn't suit your needs (performance-wise) you might be better off going with an actual computer with the proper app-spec'd hardware.
Having that known stable value (per the table I provided) can give you confidence that the reading really should be X so you can adjust your calibration value with confidence. Then confirm you get the proper reading. I'd do a 2 or 3 point calibration curve so really be sure. Also, verify your temperature readings are correct as well. I believe all those DHT sensors have a thermal sensor on board as well - this could be contributing to your problem.
I don't think they will recalibrate themselves. If that was an option, there would be some sort of code to send with "the reference value is X rH% so recalibrate" type command. Most industrial sensors would have an eeprom on the board used for calibration purposes. Hard coding would be the quickest option, but I would suggest a more robust solution would be to put an eeprom on the board with a specific sensor and store your calibration data there. That way you can swap out sensors (if they go bad for example after a year) later without modifying your code.
Also, as @goldilocks mentioned, this software was more of a gimmick and cool one-off project then something well supported. I did find this transmitting software for the raspberry pi that has a lot more capabilities and is being kept up to date github.com/F5OEO/rpitx
sorry, I missed there were 2 posters there - thanks @goobering for the article link. Best case here, at least we are centralizing access here to all of the available information on pifm.
Thanks @goldilocks , I did see that article previously and not much help there. Just to be sure I ran through it this AM with the same results. One difference at this point is I'm using a newer pizero (1.3) vs the original. I have one of those at home, I'll try out. What you've said basically confirms my suspicions regarding support for pifm. No info out there really and nothing from devs in over 3 years. I'll check out the I2C devices and try my luck with those. I'll leave this post open for now to document the pizero 1.0 vs 1.3 and if anyone else has had success.