Permament change of resolution only once
Closed this issue · 21 comments
Hi,
I have five DS18B20s hooked up to my RPi via w1 (yes, I know some of these codes don´t work with w1 but hear me out) with a resolution of 12 bits. Since reading all the Sensors takes a while and the measurements don´t have to be too precise I wanted to reduce the resolution in the hopes of accelerating the whole process.
I did so using the configDS18B20.c code and changed the resolution to 11 bits. It stayed at 11 bits when I turned the RPi off and on again, however every time I tried changing the resolution since it got changed back to 11 after a reboot. Which seems weird to me since the first time I didi it the change was permanent. Additionally I only get the code to work some of the time, when I execute sudo ./configDS18B20 most of the time I only get:
GPIO 4
BCM GPIO BASE= 3f000000
. . . . . .50 05 FF FF F FF 5F 10 09
. . . . . .50 05 FF FF F FF 5F 10 09
. . . . . .50 05 FF FF F FF 5F 10 09
. . . . . .10 01 FF FF F FF 5F 10 21
. . . . . .10 01 FF FF F FF 5F 10 21
Only very rarely do I get the option to set the resolution and as mentioned beforehand that change isn´t permanent.
Does anybody have an idea where my mistake is or how I can once again change the resolution permanently?
Thank you and best regards
Paul
Paul:
What kind of speed are you trying to achieve? I have been running an instrumentation / collection system for over a year that has 8 DS18B20's. It uses Dan's code to read the sensors and it takes me less than 1 second to read the complete set of 8 sensors.
-Tom
I think you are trying to mix apples and oranges. If you are using the RPi built in w1 drivers (w1-therm & w1-gpio) to read your sensors, changing the resolution on your sensors via Dan's code is not going to help you get any faster speed. The w1 drivers are hard coded to only read one sensor at a time (in series) with a 750ms delay between each. So for 5 sensors it will take a minimum of 3.75 seconds for it to loop around and update any one individual sensor. You can try changing the resolution all day long on the individual sensors, but the w1 drivers will still only read them one at a time every 750ms in series.
Thanks for the quick replies.
My current setup only has five sensors so right now, so the time it takes to read all the sensors isn't a big issue. The idea is however to rig up a lot more sensors to a test stand at my college.
I'm relatively new to the RPi-and-sensor-scene so I might not know what the best setup for my case is.
If I understood correctly Dans code allows me to read multiple DS18B20s much faster than the built in w1-drivers, so in theory all I have to do is to use the DS18B20Scan.c code and I should be golden. Is it really that simple?
Yes, Dan's BitBanging code works great. No need to reduce the resolution to get the good performance.
Using "Dan's code" is the solution to faster read times. But you must use it 100% and according to all his instructions. You have to disable the built-in w1 drivers (or at least put your sensors on a different GPIO other than 4).
Wow nothing to add. Thanks guys.
Daniel
B.T.W. I made a protoboard with 35 sensors and I was able to read them in ~1 second interval.
The thing to do is to stabilize the power using capacitor coupling, start a conversion for all of them and then read each sensor individually with their serial number. If you have to many on one pin then split them an use another pin.
Daniel
Okay, thanks again for all the replies. I had a week off and am now back to face all of my problems.
So, as I said before I really don't know a lot about this sort of stuff. I'm a bit overwhelmed by all the code and since I know almost no C its difficult for me to understand the DS18B20Scan.c file. Is there any documentation on how to use all of the codes provided by Dan for fools like me? :)
I wasn't able to find any.
Thanks
Paul
What is your preferred language?
I used Dan's drivers in Python.
If you explain a little more about what you are doing, I may be able to send some relevant example code.
So in the end the idea is quite simple (I think), we have a test stand at our college which is already rigged up with a couple of sensors but we are planning on upgrading to at least 20 DS18B20s. At the moment I'm trying to figure out how to best do this with a small test build (5 Sensors rigged up to one Pi). It's working out quite well over the integrated W1 drivers. However it would be cool if it would take less time, right now its about 750ms plus a little more per Sensor. The Sensors are rigged up in "non-parasite" mode. Since my first idea of simply turning down the resolution doesn't work I would now like to try to disable the integrated W1 drivers and to star using Dans code. My problem now is that I'm new to the whole RPi-thing and just don't know where to begin, i.e. I have the drivers but don't know where to implement them.
PS my preferred language would also be Python.
The best way to understand the DS18B20 is to read the datasheet provided by the manufacturer.
Check the commands flow chart. it explained exactly the behavior of the system.
https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf
The python code has documentation. Follow the procedure on how to install it for python
git clone https://github.com/danjperron/BitBangingDS18B20
cd BitBangingDS18B20/python
sudo python3 setup.py install
and then start python and for the help document.
python3
help('DS18B20')
Basically there is two modes of operation. The first one is using the serial number of the DS18B20 and the other is by the "skip rom" command which skip the serial number ID process. This mode allows the command to be execute on all sensors at the same times. This is very handy to start conversion on all sensors at once. You could use a combination of serial number Id and skip rom. Start the conversion using "skip rom" and then read each sensor individually using their serial number.
I added an example in the python folder on how to read 10 sensors in python
Be aware that this example start the conversion on all sensors at the same time. Then you need to add some capacitors coupling between ground and VCC to limit the current surge when you have more than 10 sensors. Even with 10 sensors I put a capacitor (0.1uF) between gnd and vcc every 5 sensors.
And the result should be something like
pi@Pi3Plus:~ $ time python3 read10.py
Scan sensors on pin 20 ... 0.196933 second. Found 10 sensors.
Send start of conversion commands for all sensors on pin 20. ... 0.004432 second
wait 0.75 seconds
Read all sensors ... 0.170169 second
[28-0117C19740FF] : 18.7'C [28-0217C1129CFF] : 18.6'C [28-0117C19E86FF] : 18.9'C [28-0217C10009FF] : 19.6'C
[28-0217C13A79FF] : 19.0'C [28-0117C17A75FF] : 19.6'C [28-0217C1B8CDFF] : 18.9'C [28-0117C17B2DFF] : 19.1'C
[28-0217C0FB8BFF] : 19.3'C [28-0217C1146FFF] : 19.1'C
real 0m1,622s
user 0m0,561s
sys 0m0,020s
pi@Pi3Plus:~ $
Thanks a lot for the advice and example code Dan. It works great and I can write the data into a .csv file which is exactly what I need.
A new problem has come up however where sometimes (I couldn't figure out when) some sensors won't be detected. I have written my code so that the value from the last measurement is returned which does work but it would obviously be better if all sensors would always get detected properly.
I don't know if this problem fits into this kind of thread, if not feel free to tell me, and i´ll ask somewhere else.
Anyway thanks again for the help so far.
This system is not inside the kernel but in user space then sometimes the timing is wrong. If the Pi is loaded with a lot of applications it is possible that one of them get the time slice instead.
The best thing to do for the sensor is to register in a table all the sensors ID and use that table to read each sensor. You don't need to scan it every time since the serial ID will be always the same.
On readout it is simple to re-scan the invalid sensor if the value is wrong.
A Raspberry PI3B(+) has more cpu speed then it is less prone to that issue.
B.T.W. Don't forget the decoupling cap between the gnd and VCC directly on sensor. Starting a conversion at the same time on each sensor create a current spike that could destabilize the bus.
Thanks again for the advice.
I managed to get my program working to my satisfaction on my testbuild with five Sensors.
Today I tried to run it in our teststand, it managed to scan all the sensor IDs but it couldn't read the temperatures, it only returned a humiliating list of 'None's. I also wasn't able to set any resolutions.
The Raspberry Pi in the teststand is the same I used in my test configuration (Pi 3 Model B) and even the sensors are mostly from the same batch. I also tried swapping the SD cards of the Pis with the same result.
If anybody has any idea why this might be happening I would be very grateful.
Maybe the first step is to see if the standard 1 wire protocol see your sensor.
What is the difference between this setup and the previous one ? is the pull up resistor there?
The standart 1 wire protocol is working, at the moment the temperature is read over the standard w1 drivers and the w1 slave file. The pullup resistor is in place and as far as I can see there is no difference between the two systems except the number of sensors.
Some pressure sensors are installed on pins 8 and 10 (UART0 TX/RX), but that shouldn't influence the GPIO4 right?
Interesting new Fact: The setResolution does work getResolution however does not.
So my code tells me the resolution is 12 bits and not the 11 bits I wanted to set, but when I check the w1 files the resolution was changed to 11.
I don't know if this helps me or anyone else to get to the bottom of this problem but who knows.
Ok what is your model of raspberry pi ?
On a pi3 could you check i a fix cpu clock work.
https://starfishmedical.com/blog/raspberry-pi-clock-conundrum/
The new PI3 models have cpu clock variable and this could cause clock Problem. I did check the timing on those PI. I will check if the timing on PI3 and Pi3+ is accurates. I know by a fact that SPI clock is wrong on the PI3. I do have both. I will plug my scope and check the timing on them.
Both of them are PI3Bs and as far I as I can tell no modifications to any clock speeds were made.
I made a small changes in the python code.
-
The reset is now 500us long instead of 480us. Sometimes the reset delay wasn't enough for some sensors.
-
the bit detection delay is called MICROSECONDA, and the bit left time delay is called MICROSECONDB
MICROSECONDA + MICROSECONDB = 60 microsecond.
This way you could change the ratio between MICROSECONDA and MICROSECONDB.
They are now set to be 3 and 57. Maybe this won't be good for the max31850 but I got less error in scan mode using 3 and 57.