AbeAnd Log
Status - Done: PC v18.01 frame To Do: Finalize all PC docs and generate cut files Blocks: Time
Status - Done: more D3D Mini PVC clamp designs To Do: clamp part details & frame assembly Blocks: part details & time
General links Critical Path Roadmap mediawiki formatting help Development Team Log OSE Hangout OSE Jitsi Meet Abe's Links Abe's OSE Google Drive Folder Abe's OSE Google Calendar Abe's YouTube channel
Current Logs
Thurs Jan 10, 2019
Code fixes continue to be messy, but seem effective for fixing the over complex fram memory access without more modular classes/methods. Getting access to the data once it writes it correctly may require even more cludgy code or more vars for memory management. I should have it semi functional soon and will start thinking about a box to put it in for live testing.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Tues Jan 8, 2019
I tried a quick fix for the FRAM address issues and left the controller running overnight. I doubt that fixed the address math, which really needs it's own library to manage FRAM more dynamically. I still haven't found the cause of the 'E' in the pressure lcd print and the 0 in humy2 because the values serial print fine. I don't think its a conversion or type error at this point, but I'm not sure how it may be related to FRAM address math errors. With a little more time I should be able to get the basic sensor records working good enough and de-prioritize the modular libs for later to focus on CAD again.
meeting prep.
I tried to record our semi-organized discussion and it seemed ok at first, but there must be some internal software issues with vokoscreen or ubuntu because the recording later has severe audio noise similar to what we were hearing from Marcin's videos as well. I think that clarifies that it is a software issue not a hardware mic issue. Possibly an ubuntu or pulse audio issue.
Looking at GH controller code the hard thing to debug is the FRAM addressing even though I've done it before besides needing it's own library part of the lack of modularity or granularity is the custom data strucure I chose to make it easier at first, but really array(s) would make things easier for granular access. One 16bit int type could be used instead of 8bits for all or maybe two types of arrays could be made for each. This unfortunately would require a lot of code rewrite. In the end this seems the most modular route and would carry over to the eventual class libs better as well.
Mon Jan 7, 2019
After starting a new branch for the GH controller with the intent of modularizing the code into multiple useful libraries I'm still thinking basic climate monitoring would be useful. The timer class changes I made while trying to get the LCD menus working better made the existing loop logic different. I was fairly sure last year I had the FRAM access sorted out, but currently, there is some data type confusion or disorder in the logic. Leaving the classes for later may add confusion, but getting something useful now and going back to working on CAD seems a better priority.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station/tree/sensors
Sun Jan 6, 2019
I've been thinking about GH Monitor/Controller because I figure there are better ways to encapsulate code more, but I finally got around to plugging the old hardware back in and as I expected it doesn't quite work how I wrote the code since I don't recall how the LCD write works exactly.
Fixed some obvious mistakes, but still more significant issues. Some likely caused by changes to the main loop using the Timer class. Trying to think of ways to add more of it to functions and classes.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
Tue Jan 1, 2019
Continued some code updates to the greenhouse monitor and control station. Tryin to modularize the code better so it is more useful for other projects as well. I finally got it to compile in the Arduino IDE v1.05 with all the previous libraries. From some prior more recent research, I found there are likely better libs available since most of the design is more than a few years old. I continue to prefer writing my own simpler code in many cases because many of the optional libs with needed functions were also excessively larger and as complexity and options grow it may become too large. There are newer faster hardware options enabling the use of circuit python, which is probably easier to code, but they are more expensive and less efficient. If required I think the C++ code can be easily run on more advanced hardware though. The code may need updates to generalize the types for cross-platform though. I also do not expect the code to work the way I'm assuming currently.
I have yet to reconnect the hardware on breadboards for actual testing and code remains far from complete. I think more restructuring and OOP classes will improve code usability. I'd like to test the basic sensors for greenhouse use this winter-spring, but I don't have a plan for packaging the hardware yet either. I recently added some temporary, but water resistant safe electrical to the greenhouse. I don't think the greenhouse is large enough to warrant complex systems, but so far small changes have helped.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
https://docs.google.com/drawings/d/1gjtrbWVbxtNjfkAmB7RW-BoM72ZRPpgSUTgVxkS9IvY/edit
https://docs.google.com/drawings/d/15V_-4Y2CEDsFE0q8cFWSfc_9qI3jPTPOZ3HXsDCZ9JE/edit
https://docs.google.com/spreadsheets/d/1PM3yYz9tTfzzj9uBumbAGERmuzl01O4XbtE-WeyNf-c/edit#gid=0
Old Logs
2018
2017
- AbeAnd Logs December
- AbeAnd Logs November
- AbeAnd Logs October
- AbeAnd Logs September
- AbeAnd Logs August
- AbeAnd Logs July
- AbeAnd Logs June
- AbeAnd Logs May
- AbeAnd Logs April
- AbeAnd Logs March
- AbeAnd Logs February