But OH SO SLOWLY!!!!
I am still really having problems wrapping my head around position and text formatting being an important part of the actual code rather than just space.
Handwritten functional spec is done but only I can decipher my handwriting and so it’s not yet up for review. Next month maybe.
Tkinter or more properly tkinter (for Python 3.7) is built in but not very intuitive. I’ve been coding a lot of test things to see how it all works to get and display data from a database since that’s a big part of what LambTracker needs to do. Making slow but steady progress.
There have been a number of requests to expand LambTracker into handling species other than sheep. I am slowly working through the tablet code to allow for use with cattle, goats, pigs and horses in addition to sheep.
Work is progressing on the desktop addition to LambTracker. After numerous aborted attempts at including the reporting functions within the Android program it’s become clear that LambTracker requires a much more robust desktop addition to read the same database from the tablet and do more complex reporting and updates.
I did several test programs trying out various languages and user interface systems. The goal is to write one program that can run on Macintosh, Linux and Windows operating systems with little to no modifications. The winner, after much gnashing of teeth and hassle is Python 3 with Tkinter for the UI output. That seems to provide the most consistent interface across all 3 major operating systems with the same code. There are a number of problems to be solved with the transport of the database file to and from the handheld. I do it routinely now but I use the command line and for the average user that is difficult. Synchronization is not going to be provided at least initially so it will be a manual replacement of the database from the tablet to the desktop and vice versa.
A detailed functional spec is being worked on now that will describe the operation of the desktop system in excruciating detail including screen designs and detailed UI notes. My best guess right now is that the functional spec won’t be completed until the end of the year and coding will primarily happen this coming winter.
As soon as the spec is in a more stable format I will be posting it up in GitLab for comments and ideas before I start major coding.
LambTracker has always been focused on providing inexpensive options for shepherds wanting detailed individual records using automated systems and including the ability to use EID tags. We’ve changed hardware several times and I thought it would be useful to look at the history.
Initially our field use handheld was a Nabi Jr. This small relatively inexpensive for the time, Android handheld was designed for kids and had a nice fairly robust case. This worked for a while but the small screen size became an issue especially as we started tracking and collecting data on drugs given, toe trimming and many other management tasks. It was very hard to read the information on a given sheep as the lists could get long and scrolling was not the easiest way to navigate the data.
Our next device was a Kindle Fire table. These worked really well. We were able to source a nice tough case that was great for outdoor use and had a great handle too. They are very inexpensive at about $50.00 each and had a large enough screen so that we could easily fit the new features onto the system. Some things were getting harder to read but overall they have worked well.
Sadly they have suffered from a severe problem with the USB connector. It breaks. Ken repaired them but that is a one time per tablet fix. The design itself is a bad design. Over time the simple case of plugging the USB connector in and out many times will eventually break the connections on the board. When that happens the tablets cannot connect via USB anymore. Sometimes they cannot even be charged up. Amazon has been unwilling to do any sort of redesign to improve the USB connection.
The newer Kindle fire devices would be perfect, except they suffer from the same USB connector problem for one thing and more importantly, they cannot be rooted so that we can actually run LambTracker on them anymore.
We started on a search for a suitable inexpensive tablet computer that we could use for the next generation of LambTracker handhelds. Most of the tablet manufacturers have gone to having many more features than we need with a resulting high price. Our target is a tablet for less than $100 including at least some sort of semi-rugged case. We need a tablet with a 7-8 inch screen to handle display of critical sheep information in the field.
Right now we are testing the new Onn 8 inch Android tablet available at Walmart. So far the only issue is that the battery life appears to be a bit shorter than we’d like. They are reasonably priced at $64 each and have all the features we need for LambTracker. We have not yet used it in the field so there may be issued we are as yet unaware of but it’s working on the bench.
If you know of an inexpensive Android tablet please, let us know.
I’ve been working behind the scenes to prepare for a major update to LambTracker that will introduce many new features.
The biggest changes include full tracking of feeds, ownership and locations.
As a result of these changes the first step has been to add a number of new tables in the database structure. Designing that structure and getting it working has taken far longer than I expected.
Unfortunately, the additions and changes will effectively break all existing LambTracker code.
I am making a new development branch that will use the new database structure. I have started documenting what I need to do and have over 200 individual areas identified that need updates or changes to work with the new structure. To see the new structure in the code you can check out the blank lambtracker db file that is in the assets section. Once code changes are made I can merge things back into the main develop branch.
Of course complicating this all is that we are just weeks away from shearing and vaccinating which will be followed by lambing. I need LambTracker to be working to collect data and document all these procedures but it is unlikely that I can get all the code changes made before we start.
I have updated the blank spreadsheet files that are used to fill the new database structure when you first start using LambTracker and need to add in the historical data. That repository is now up to date.
It’s been a long time since I posted. For the last couple of years we’ve been using LambTracker for all of our sheep tracking and data gathering. Lots of things need improvement and my list of enhancements I want to implement is getting longer every time we use it but overall it works well. Other projects took priority so nothing much was done on LambTracker to change the basic functions. I developed some workflow workarounds to cover the major bugs that impacted us and the enhancements, while nice, were not critical.
Well that has changed now.
First major change is that I’ve moved the development system off of GitHub to GitLab. With Microsoft buying GitHub I could not stay there. So all new work is on my GitLab account.
The latest big feature addition is that we now have a bluetooth scale and can send weight data directly to LambTracker. It’s still in work, today is the first time the new code will encounter the sheep as part of the yearly evaluations but it worked well during routhine sheep management tasks.
Got a few minor bug fixes done. Corrected calculation of the age of the sheep when putting in a carcass weight. The sequence is you must first remove the sheep and then do the evaluation with carcass as the only item being evaluated.
Working to get the test database populated with sheep.
Annual flock inspection went well. Discussed a bunch of potential user interface and use case options with our veterinarian. I still did all the queries to produce the reports by hand but developed some new query code that provides more of the information in a better format. Trying to decide on a system for using GitHub to store/update Query code so haven’t pushed any of the new queries up yet. I don’t want todo all individual files but that is easier to update on GitHub. DEVONThink is easier for me to use while I am developing and testing code but almost impossible to put on GitHub. Scrivener seems like a decent compromise but is more difficult both to use in development and to update GitHub. So still looking for a better option before I spend too much time on implementation.
We used LambTracker during shearing to print labels for both wool samples and fleeces I saved for sale. Found a few bugs and worked on them. Now trying to clean up stuff for the Federal Scrapie Flock Inspection.
All lambing is done now. I’ve got a lot of work to do to finish my Masters Degree so LambTracker is going to take a back seat until early 2016.
We are nearing the end of lambing season, we only have 6 more ewes to lamb, and this year we uncovered a few more lambing bugs. Most have been fairly minor, things like forgetting to update the sheep record for new lambs with some of the new fields for management group and location. Others are on hold until lambing is done since it’s working fairly well as is and I don’t want to break anything until I don’t need it for real data.
I am also entering in historical lambing data and have developed a workflow to get the information in. I am going back to my original paper lambing books and crossreferencing with my calendar and my original spreadsheep records. I have the database up on another computer looking at all the sheep sorted by dam and then by birth date. I have a spreadsheet I created to insert lambing history records and I have a copy of the database that I am working on on a second computer.
The procedure is I look up a lambing record in the paper book, start creating the insert record in the update spreadsheet. Look to find the sheep_id for the dam then use that to look at the other copy of the database to find all her lambs. Verify that the number of lambs in the database matches the paper record. Add the lamb numbers to the lambing_history_table record. Go to my calendar and pull any notes about that lambing and add those. Go into the sheep_table and add the reference to the soon to be adde4d lambing_history record to each lamb’s sheep record. When I have a batch of maybe 10 or so done, I save the update spreadsheet as a .CSV file and then run the CSV to SQL converter to create insert statement. Copy and paste the code into the database and execute it. Then I save a copy of the database as a backup. I continue tis until all lambing records are entered for the year. Then I go to my population history records and figure out all the ewes who failed to lamb in that year and enter in a record with them listed as barren for that year. This step is necessary to allow for more accurate reporting of percentages of lambs born and weaned each year.
My final verification step takes place after I have entered in an entire year from the paper and calendar records. I pull up all my old spreadsheet records on the entire flock and look at the lambing notes for that year and make sure I have the right lambs and the right data in the lambing_history record. I do this final step at least a day after I have finished the original data entry. This is my final chance to catch any data entry errors.
So far I’ve managed to enter in 10 years worth of lambing records and only have 7 more years to go. It’s slow and tedious but necessary.