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
Sun Jan 20, 2019
BSD licensed lib should be compatible with sunfounder LCD. I can't tell the hardware is open source and the other software libs are not licensed. https://github.com/mathertel/LiquidCrystal_PCF8574
Looks like there are a few wear leveling libs for Arduino, but one looks to simple. How it encodes the number matters more because of wear leveling. Storing a single byte or 255 bricks is obviously not enough. An unsigned long (32 bit) will store 4M brick count, but erases 4 bytes each update. 65K from using 16 bit is reasonable. Users can understand it rolled over. I'm sure there are other complex binary encoding schemes to consider as well. If it writes a brick value based on time (hourly) and is wear leveled in a series of addresses they could all be added, except that it would need to incorporate a way to tell which, addresses to add or not.
https://duckduckgo.com/?q=arduino+EEPROM+wear+leveling&t=h_&ia=web
There are multiple ways to get a brick count without an integrated screen that don't necessarily require using EEPROM.
- Serial I/O to computer/cell phone over USB
- Wireless - wifi/BLE to device(s)
- Use the SD card slot available on a reprap LCD kit. Likely more useful in conjunction with the above output methods.
With likely many oversimplified assumptions:
For simple series wear leveling and 2 byte unsigned longs that halves the 4096 bytes of EEPROM on the Mega2560 to 2048 records. If hourly writes are made on a machine making 7 bricks per min. Thats 420 BpHr. * 2048 hrs = 860160 brick count / 65536 = 13.125 rollovers. 65536/420 = ~156 hrs.
More research on the wear leveling algorithms in the available libraries is needed... https://forum.arduino.cc/index.php?topic=85047.0 https://forum.arduino.cc/index.php?topic=385419.0
Sat Jan 19, 2019
Still looking at menu library options and thinking we could use some more software devs for creating and maintaining the big picture software API's for arduino/RISC V microcontrollers. Even if there are universally used libs for everything if they are designed right code that isn't used won't add any excess to the sketch sizes. Simple C/C++/Python libraries can also be coded so that they are not standardized to a specific platform like Arduino. I'm curious what existing open source code is used in the 3d printer reprap etc. It does not look like the reprap screen is necessarily ideal for the CEB Press, but if it can be adapted that would be great.
I now see there are reprap kits that include the lcd, mega, rambo and they are much cheaper than the plain RepRap LCD's kits. The Marlin code is what needs to be adjusted to exclude almost everything except the HD44780 LCD controller code, the ULCDST7920 LCD code, digipot mcp4451 and maybe the DAC_MCP4728 for i2c? There is a bunch of custom font/language related code and I'm not sure what should be saved or cut. A programmer familiar with marlin should be able to cut out what is unneeded quickly.
Reviewing CEB Press code and LCD options.
Scanner for 16x2 LCD with LCM1602 module http://henrysbench.capnfatz.com/henrys-bench/arduino-displays/ywrobot-lcm1602-iic-v1-lcd-arduino-tutorial/
PDF for chip it uses. http://wiki.sunfounder.cc/images/1/18/PCF8574T_datasheet.pdf
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.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
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.
https://stackoverflow.com/questions/37035186/multiple-i2c-cant-work-with-arduino-uno
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.
https://github.com/Witz0/Climate-Monitoring-and-Control-Station
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.
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