AbeAnd Log

From Open Source Ecology
Jump to: navigation, search

HintLightbulb.png Status - Done: PC v18.01 frame To Do: Finalize all PC docs and generate cut files Blocks: Time

HintLightbulb.png 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 17, 2019

Looking at possible menu libs and this one looks simpler than most, but still more complex than I expect. However, it may be more universally useable across devices and that would save time. The licenses look ok. https://github.com/DavidAndrews/Arduino_LCD_Menu

Also, I was just noticing from [Talk:Freezer to Refrigerator Conversion] that the price of the MKR1000 with wifi is much lower than I recall. That could be a more integrated solution for getting wifi. The only added issue I think is level shifting to 3.3V.

Tues Jan 15, 2019

I was late for the group discussion, but it was long and interesting anyway. I've been thinking the Scale Model's Chas brought up would be great sale items as toys if they are functional enough. They could also be model kits for learning by doing the assembly. It creates the possibility of open source hardware maker like projects for younger children. Maybe functionality of something like a scale model CEB Press could be advanced enough such that it could make blocks of playdough to build open building models. Just thoughts.

I've reviewed most of the new work on CEB Press 2019. Changed my mind a couple times after reading further. The analog pot should be easier than I thought to code with delay()'s since it can map() a voltage to some calculated time to move with sufficient accuracy. One thing I'm still unsure of is recovery from an error in an unknown position and calibration from that in position one. Without a manual control mode to set the 2nd cyl if it gets to far off it may be hard to reset. The further hardware simplification concepts and code layout look good overall though. But, I need to review and think more. https://docs.google.com/presentation/d/1YLo7e6RW4SUq7v5NFQ2WoX2ZFHsnoa3wI9m8Oc5-24g/edit?ts=5c3e6821#slide=id.g4d84192e63_0_180

I need to review the logs from the GH monitor, which has now run through a daily loop again on my desk. I think the memory addressing logic can be simplified more, but I'm unsure the ideal way to do so. Also the menu system needs work. I don't think it is immediately relevant to the CEB Press, but putting a good simple menu system in a separate library will be useful. I still need to review more menu libs. Ruslan also mentioned a climate sensing system maybe on his log or OSE Germany wiki I should look at.

Mon Jan 14, 2019

I think I made some more progress on the climate monitor code. FRAM management still needs more thorough testing and ideally some more functions if possible. Not ready for a class. The complexities of menu's and button logic are making me think it needs its own class.


Sat Jan 12, 2019

I've suspected for some time there could be bugs in the underlying hardware/software setup I'm testing, but I keep finding mistakes in my code changing it and therefore making and finding more. With excess conditional logic checks and serial output added I'm now seeing a change in a FRAM data that I can not explain from my code even though it seems somewhat consistent across resets. I find it hard to believe it is i2c bus issue, but I'm reviewing code deeper for any nearby calls in other libs.


There may be an issue with the way I've connected the devices or their addressing over i2c.

It looks like adding a Write Protection control line has fixed the FRAM glitch, but it will need more work to refine since I assumed it needs delays for timing. I also fixed some precompiler warnings, but one strange one remains.


Fri Jan 11, 2019

I think I'm close to finally hacking through the mess made by using FRAM memory usage to store machine state between reboots due to previous coding mistakes. Using the FRAM to store the state technically can throw data averages off because without an RTC the timers are relative, but I think it is an ideal feature so that power loss doesn't cause existing data to be overwritten. Especially since I do not have wireless integrated yet. Looking at the ESP8266 closer it has an Arduino compatible MC in itself and runs at 80Mhz, but I'm not sure it is a good idea to think it should be used by itself. Mainly it lacks I/O pins compared to the Uno or Mega. Most of the instructions show hooking it to an Arduino via the serial RX/TX. I'm also making some progress testing and thinking about the menu's and button states. I'd still like to review more existing menu libs in case something can be more easily used by removing excess functions etc. than trying to write a whole new system myself.

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.


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.


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.


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.





Old Logs