A lot of Arduino toys keep arriving in the Asia to USA transit pipeline. Because of the 20 to 25 shipping time I have been trained to put stuffs that I anticipate I can use way ahead of time. I also tend to buy 2 if I anticipate the item would be good because I need to keep one copy of the system for continue code development and maintenance. I however buy 1 if the item is unknown or expensive. Most of these stuff cost between $1.50 to $6 so it is not like I am going poor house doing shopping spree.
The development of this multi-function display for Vanagon has progress faster than I can blog. I have been up against the wall because the code has gotten too big to fit into the flash memory of the AtMega328 uC. The most recent problem was due to the use of another type of temperature sensor in addition to the DHT11. This necessitate adding the big libraries that support this second sensor, and immediately adds about 2.5k byte when I was already maxed out. I also added a dumb speaker for tone and the function for that is also a memory hog. Because of these the code was 2k bytes over the 32k flash memory available for use.
I spent a lot of time trimming the code, and also forgo the tone beep function to get it to fit. At one point I was just 8 bytes under. That is 8 out of 32,256 bytes! Of course since the code is far from shipshape something has to be done. I should have at least 2k byte of spare at this point of the software development. In case you wonder, why not just switch to a iC board with higher capacity? If you have to ask, you grossly missed the point...
the new DS18D20 temperature sensor (left) with OneWire interface in addition to the DHT11 (right)
the dumb speaker that I use for been tone - to acknowledge UI command entry
this speaker cost me a lot of software debug time - it turned out the polarity of the speaker pins were installed reversed
I added a blinking dot to the display's lower right to indicate logging in progress. Here are the screens with two types of temperature sensors. One with humidity, and one without.
here is the normal Vanagon gauge screen
the same screen with the blinking dot to the lower right corner indicating logging is in progress
here is the logging command page - the user make choices to start or stop of logging, or exit without making change of the choice already in progress
yesterday is the first time that I break out the oscilloscope to so some signal integrity check; i just want to look for gross signal integrity problem with the various interface signals
Isolde has developed this intermittent failure to start problem; I am now debugging into the ECU in situ
The arrival of two additional DHT11 brings the much needed flash memory relief that I sorely need. I removed the DS18D20 temperature sensor from the system even though it is a very nice sensor in favor of the less accurate DHT11 because the latter also measures humidity. I regained 2.5k bytes of flash memory back. The code is now at 91% of the flash memory capacity, and the variables are at 71% of the 2k RAM capacity. While I am not home free I feel fairly comfortable that I can achieve all the design goals I set.
I am head over heels over these DIY microcontrollers. Everyday I look forward to the USPS delivery of packages from Asia of cheap thrills costing $2.5 of these technology and economic wonders on average.
Making changes to the temperature sensors is a lot of work. After a few hours I got it to work with stability.
A few words about the data logger function. From the outset I envision that the logger functions and the sensors would be changed or customize as the need arrives. New code would be downloaded from a notebook computer to the uC module that is installed in the Vanagon. I would keep an identical system at home for ongoing code development, debug, and enhancements.
here is the gauge screen with 2 DHT11 temperature and humidity sensors
I really like this miniature OLED screen. Its resolution is 128x64 and can display a lot more information than what I have chosen. I chose a font that is about 100% larger than for legibility reason. I chose to use a RAM efficient library for it which requires a loop to paint the screen in 4 iteration, the price of the efficiency is more difficulty in programming with anything that writes to the screen.
here is the data logger command screen
I should mentioned one of the most challenging part of the software is to writing the joystick UI codes. The joystick mimics one that has discrete switches at up, down, left, right, and neutral positions. I use timer interrupt to poll the analog potentiometers and the push button switch of the joystick in order to keep the UI responsive.
here is the addition of the very nice ADS1115 4 channel ADC
As to the final choice of the Vanagon oil temperature and pressure sensor, the choices are still in flux. I have been dissatisfy the legacy VDO types that are commonly available. I prefer the newer solid state designs but they are more expensive and hard to find the ones in 1/8" NPT male.
I have planned a small enclosure for the Uno uC board, the data logger shield that piggybacks on top of the Uno, which would also accommodate the ADS1115 module and all the discrete electronic parts. I bought this $3.50 one from China based only the rough external dimensions and it is looking very promising that it will serve my needs. I want access to changing the SD card as well as the access of the USB and power connectors.
here are all the current system components including the engine oil temperature and pressure for the Vanagon
The reason the "system" are mostly still are on the solderless breadboard is I am deferring the final construction of the pieces onto the data logger shield (the board that is backpacked onto the Uno in the photo). I would only start to do that once I am sure about the final configuration. As some of the analog input would potentially be exposed to 12V I would add over voltage protections to these inputs. I am aiming to place all the components (excluding the sensors) onto the prototyping area of the data logger board. As things look right now, all would be a tight fit at best.
On the software front. I just finished decoupling the update rate of the gauges from that of the data logging cadence. The logging cadence can be changed from seconds to minutes. For the time being it is fixed by the software build. I want to be able to change the data logging frequency to a number of discrete user selectable steps, but that will requires more time invested. I am quite please of having chosen to use this little joystick for user inputs. I like the idea it is like an airplane control yoke.
The cadences of the different tasks are always a compromise. For the oil and pressure gauges, 1 Hz is just about ideal. For the logging in progress indicator, the on/off blinking of once a second is just about ideal without being distracting. That is actually 2 Hz. The data logging intervals, however is another different matter, depends on the type of sensor and what the motivation of the data logging is for. It can vary from once a minute to once a few milliseconds. The data logger can get very complex very fast depends on the application. That is the reason that I plan to made the changes base upon new code upload to the Arduino Uno with a notebook computer. There are simply too many different scenario that can be accomplished with a fixed code into the very limited 32k byte of the AtMega328 uC that is on the Arduino Uno.
I am extremely pleased with the progress of this project. It has given me most entertainment for the little money spent. I already have a number of data logging that I like to do. One is to log the ambient temperature against inside temperature the dc refrigerator as well as the on/off duty cycle.
Aside from this project, there would be dividends from the time I have invested. I plan to make a battery compact and self-contained portable data logger. It can be mounted near a, say acceleronmeter sensor for rapid data logging of drivetrain vibrations to hunt down vehicle ride quality - shake, vibration, or hashness (SVH)
every time one of my vehicles develops a bad case of SVR I cannot shake this tune off my head
Update:
Wow. That was a close call. I nearly sacrificed one of my Arduino Uno because I got cocky and reckless. I thought I would add the feature to put the uC into sleep mode, and wake it by pin state change. I got the pin wrong. Once the code is compiled and upload, the code worked. In the main loop I put the uC into sleep mode. Works too is the joystick switch button that wakes the uC from sleep. The big problem is as soon as the uC is awake, it goes on its merry way, do a few simple tasks, and back to the main loop and went into sleep again. Because it spends most of the time sleeping, I could no longer upload any new code that I revised. In the other words, it is bricked for good. Asserting reset did not help as it just do the same thing.
I try rapid succession of pulsing the joystick button and move the yoke to steer to a longer execution path hoping it would keep the uC awake long enough for the uploading of the new code but no luck. I then realize if I just unplug the USB cable, and time it just right to plug it back in just shortly before the uploading take place I might stand a chance before the bootloader passes control to the bad code. That did the trick and I recovered by using a very short and simple code.
While when buying in quantity of 3, the Uno costs a mere $3.3. Still I hate to waste one.
No comments:
Post a Comment