Ok,
a friend have the same problem, but we have not the same source code.
If you want to narrwow down the problem there is no other way than printing to the serial.output all details of your nested structure and to manually check if the values are right
.
I mean print out arPdtDeviceList.DEV[i].HW_TEMP_ADRESS
print out i
print out HW_TEMP_ADRESS
You can stand there for hours weeks day month shaking your head saying I don't understand
or you can start analysing it
If the other code works and your code works not this means the hardware is OK
the ideal line-topology would be you cut away 5mm of plastic from a wire and solder there your sensor and after some meters you do the same for the second,, third ... sensor
a star-topolgy is you would you solder 1 meter of wire at this "connection point" and then solder the sensor at the other end of this additional wire.
the shorter the "connection-length" to the sensor is the better
Another thing is to use a 2 kOhm resistor instead of 4,7 kOhm as a pullup-resistor and to use full-powering mode instead of parasitic mode.
And as a general hint:
start with a small code and then test it
expand the small code a little bit and test it
repeat
if you write a big code including this double.nesting you have now and then start to test
there are exponential more possible cases where the bug is.
So trying to save time through leaving out tests after a small expansion costs you looooong testing of a lot of different things inside a big code.
It is up to you to make a decision which way makes more fun to you
best regards Stefan
Hello,
I found the problem, but that does not explain why the call to analogWrite (PIN PWM, PWM PROZ) applies. If I did not use this call, the result from the DS18B20 is correct.
If I use this method again, the problems reappear.
Can someone maybe take a look at the passage in my source code?
In the INO file the method call analogWrite in the function FN_controlFanSpeed
greeting
is not a valid call of the function analog-write
analogwrite has only two parameters not four
I rather would write everything new from scratch than analysing your code
Why the second parameter PWM_PROZ of your analogWrite () is of type float?
The Arduino reference says:
value: the duty cycle: between 0 (always off) and 255 (always on). Allowed data types: int.
@StefanL38
What is this stupid statement about now. !!! Then be so nice and stay out of the subject. I really don't understand your reaction. !!!
And if you had been so nice, and had looked for exactly this one function, then you would have seen that the underscores in the name of the variable were missing in the post and if you received the sketch is played on the controller !!!
So your statement cannot be correct that four parameters are passed there!
@Boffin
Oh no, I didn't see that.
Oh no, oh no, oh no, oh no
Indeed, I adjusted the data type and it works.
Which absolutely does not explain to me what kind of influence this has on my temperature value, which is stored in my global structure.
I can't understand that like that.
Now everything works, the sketch runs, the scaling etc. to the PWM also works. Now I can continue to implement MQTT / WebServer a few filters etc.
Many Thanks
Can someone explain that.
Of course, a good compiler should issue a warning or error when you pass the wrong parameter type to a function (or did it?). In order to answer the question "Why?", You need a good step-by-step debugger and knowledge of the AVR assembler, but in the case of a microcontroller, this is not easy.
The int type occupies 2 bytes in memory, and the float type occupies 4 bytes. Maybe if you were able to pass a larger parameter to analogWrite (), it could take up more memory space and destroy other data. But that's just a guess.
P.S. A couple of tips.
- Do not write very long lines in the code, it is hard to read. 80 characters are enough.
- Your data structures are slightly complex and nested multiple times, it's hard to debug.
Hi,
yes I almost thought so. But then the question arises why the method allows that at all. This implicit check of data types can be carried out and either output an error via the method or, quite simply, actually only copy two bytes as a permissible size.
I almost felt like scales fell from my eyes when I heard you said that the wrong data type was being transferred.
But that exactly the storage area of the temperature sensor is reached is actually a stroke of luck or Pesch.
Ok, since yesterday I have recorded the values over many hours over the night. In fact, it still happens.
But we're talking about one or two values that are wrong for many minutes.
I have the feeling that somehow I still have problems with the timing, or perhaps the handling of the global data structure is wrong.
As a precaution, I have even declared the global data structure static. I'm not sure if this is the right way, but it can't hurt.
Can I cause a timing problem with my functions etc., or is it actually due to the quality of the sensors or ESP just as it actually occurs.
I didn't record a simple example over night, maybe I should.
Again the question, can I cause a timing problem myself. In terms of project, my application is really not complex.
greeting
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.