Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Robo-Tank v5.13 is Ready
#41
Sorry everyone, I feel horrible for the trouble I'm putting you through. I'm thinking there are two possible issues related to many.

One possible issue for some of you could be related to controller hardware. Controllers Rev-D and previous have a different circuit for communications between display and controller. With those boards there's a lower limit on the amount of data that can be sent through the serial port at once, if large strings of data is sent there's a good chance it's not all making. Back in the day I tried putting all the sensor data in a single variable so it could all be sent in one chunk but it was too much and it chocked. This is why I had you do that modification to some files in the Arduino IDE, it increased the buffer size for the serial ports, if that wasn't done the buffer would overfill before all data was sent.

On Rev-E controller boards I changed the communication circuit which improved it 10 fold and at that point a lot more data could be sent at once. Now in v5 all sensor data is assembled together and sent in one chuck which is likely too much for the older boards. I had to do that as sensors can now be disabled and sending one piece at a time was too slow for the display to update every second. I know Dom has Rev-D and I'm pretty sure that's why your temp sensors are freezing. Dom can you try disabling all the ports on the hardware connected screen so only one temp sensor is enabled. This will shorted the data to an amount that should be no issue. If you still have v5 installed try that. If you went back to v4.2 it's ok.

I'm not sure about the version of boards others have, I think your ok fietssnrex as I just gave you some updated boards and I don't think I would have given you old ones with the iffy communication circuit.

Now for the other issue which is probably affecting most of you and again seems related to older hardware. Back in the day when Nixu added power monitoring to his power bar he had lots of issues with the I2C hanging. We couldn't figure out why as it was quite random so Nixu found some code that reset the I2C if it quite working, basically like a watchdog but different. That seemed to keep it working but it was still a mystery why. Well now I've been playing with I2C a lot more I know it was happening because the I2C was on the limit and required a buffer which would have been the correct fix as the I2C should never quit working.

Well I forgot about all this until about a week ago as for the last year almost I've been loading 4.2 with that reset commented out as I always ran my controller without it and never had an issue. When I did v5 I didn't add it as I figured it shouldn't be needed but looks like a lot of you depend on it as you have these extra I2C devices attached and no buffer so I2C is right on the edge. Before I figured this out some have gotten a buffer and the problem was solved so I will add that back which should get those pH and other Atlas circuits working again.

Now as for v5 alone, it is working not to bad but there does appear to be a possible issues in the schedules, someone discovered if they setup an always on schedule, then deleted it, that outlet couldn't be scheduled again. If more schedules were created after this point it caused all the others to not function any more so maybe stay away from always on schedules till I can look more. I have to get a new computer this week so I can't do anything until then.

Going back to the first issue for Rev-D and before I'm thinking I will add a variable in the sketch to set for users with these boards. However for this to happen I need someone to test as I don't have any old boards. All schedules, custom rules and alerts are also sent in a large chuck of data so it's likely these things won't function properly either and has to be changed to a slower method so that older circuit can keep up.
Reply to top
#42
Switching off sensors is 100% safe?
In previous versions i got some wierd errors So left everything on this time.
But if switching off some stuff is safe and prevents chocking of the I2C is the way to go for me then so be it
Reply to top
#43
PH probe I don't use, I wanted to v5 but I know small problems ...
Reply to top
#44
It should be safe to turn off some sensors but that won't be related to I2C, that's an issue for older controller boards. I'll have a sketch in a day or two.
Reply to top
#45
Wäre klasse , obwohl ich am gen 2 version d den i2c verstärker habe fällt es jetzt wieder aus , habe atlas orp/ec/ robotank ph sonde
Reply to top
#46
I’ll have to open up my stand to check the revision on the boards but it should be in one of my posts here or in a conversation with you.

Anyhow, the dataword which is send is always the same amount of bits? Regardless of the amount of sensors enabled.

I disabled all the unused sensors and went to 29*** checks per second :)
Reply to top
#47
It will be a bigger problem on my board
I have gen 2 Rev-B
Reply to top
#48
(05-13-2019, 10:29 AM)Addi Wrote: Wäre klasse , obwohl ich am gen 2 version d den i2c  verstärker habe fällt es jetzt wieder aus , habe atlas orp/ec/ robotank ph sonde

Oh wow, it still drops out on you? How close did you connect the buffer and did you put the RTC on the output as well?

(05-13-2019, 11:32 AM)fietsenrex Wrote: I’ll have to open up my stand to check the revision on the boards but it should be in one of my posts here or in a conversation with you.

Anyhow, the dataword which is send is always the same amount of bits? Regardless of the amount of sensors enabled.

I disabled all the unused sensors and went to 29*** checks per second :)

I'm thinking you have Rev E, F or G, all ok. The number of bits sent is decreased with less sensors enabled so this will help older boards but won't affect yours, but still less bits is better and quicker. 

(05-13-2019, 11:49 AM)Irass Wrote: It will be a bigger problem on my board
I have gen 2 Rev-B

Yeah Rev-B has the slower circuit, that's probably why you had a lot of trouble. If you setup a schedule or custom rule all the data for it probably isn't making it to the controller so they don't work properly. Unfortunately at this time you'll have to stick with 4.2 but I will be making changes so you can update soon.
Reply to top
#49
Der i2c Puffer hat 5cm Leitung zum Controller , die RTC ist hinter dem I2c Puffer angeschlossen.
Reply to top
#50
I just sent you some updated sketches Addi and fietsenrex, this should fix the I2C.
Reply to top
#51
Thanks, i’ll give it a try in the upcoming days ;)
Reply to top
#52
So ich hab es installiert , mal sehen ob es stabiler läuft
Reply to top
#53
Sounds good
Reply to top
#54
Läuft bis jetzt ohne fehler , klasse Rob
Reply to top
#55
That's good to hear, I can sleep well tonight. :)
Reply to top
#56
I currently have 5.13 on gen 3 hardware running and it has been fairly stable. I have noticed that the time drifts ever so slightly and eventually will be about a half hour or more off from the correct time. I don’t have anything but an EC PH and power bar connected with 2 12 inch USB cables. I think it would be good to have the option to have the controller sync with an internet time server daily.  Not sure if this is something you can make happen or not. Other than the time drift. Things seem to be working well.
Reply to top
#57
Glad to hear things are working ok but I'm surprised to hear about the time. Back in the day when I used the DS1307 there was definite drift but since using the DS3231 it's been quite accurate, definitely no reason to adjust by the time day light savings comes around, by that time it might be out by 30 seconds but not into the minutes. The time is generated on the DS3231 IC so it wouldn't matter how much is connected as the controller only reads the IC via I2C to grab what it thinks the time is.

I'm thinking the DS3231 has issues internally with the crystal. They have a temperature compensated crystal which gives the DS3231 it's accuracy. The DS1307 is typically driven with a regular crystal and why they aren't as accurate so it seems the crystal has shifted or something like that. Unfortunately the IC is integrated in the controller board so you would have to do some soldering to change it or another option is cut a couple traces on the PCB and connect a DS3231 on a breakout board. If you like that option better I can explain.

As for adding a sync with the web that's possible but I haven't done it yet because the RTC is stable and I don't want to many web based features on the Arduino. Once I have the full web based addon I was going to add it.
Reply to top
#58
Go ahead and give me some details on the use of a breakout board and cutting the traces. If the drift gets any worse I may go ahead and replace the clock.
Reply to top
#59
I have a feeling it will get worse as it's pretty bad right now, I can't even imagine it drifting 30 minutes. Adding another won't be too difficult though. Here's an image with the 2 traces highlighted where its safe to cut. There is one trace close to it so you'll have to be steady. 

[Image: RTC_traces.jpg]

These are the SCL/SDA lines to it so once cut the controller won't find it obviously. With the RTC module connect it to +5v, GND, SCL and SDA headers on controller board and you should be good.
Reply to top


Possibly Related Threads...
Thread Author Replies Views Last Post
  Robo-Tank v5.12 is Ready Rob F 34 655 04-30-2019, 12:35 PM
Last Post: fietsenrex
  Robo-Tank v5.10 is Ready Rob F 157 2,215 04-18-2019, 10:43 PM
Last Post: Rob F
  Robo-Tank Isolated PH Circuit Rob F 49 1,893 04-12-2019, 05:47 PM
Last Post: Rob F
  Robo-Tank v5.0 is Ready Rob F 206 7,576 04-03-2019, 09:18 AM
Last Post: Rob F

Forum Jump:

Current time: 05-26-2019, 08:27 AM