Do you want to correlate bales with their production location in the field? Or just know which field a particular bale came from? Either way, you'll need a way of identifying each bale in order to correlate back to where in the field that bale was produced.
With windrowing and tedding, it may be more difficult to determine which section of a field the hay in a bale came from. You can probably get within 20' feet (depending on width of your tedder/rake), but when the grass gets thin, then the numbers would get a bit sketchy.
I don't think you really want to replace the existing counter; you really just want to count bales and log their production.
The first thing I would consider is all the interface points to existing systems - both mechanical and telecom. And one would need to know what software will be at the other end. The reasoning for this is:
Do you want this to work for many models of balers, or just yours?
Do you want to send the data real-time or accumulate it on a SD card? (How the information will be used on the receiving end can answer this question.)
However, knowing how most balers work (for small square bales), I would look at attaching a reed switch to the trip arm that runs the counter. Put a door sensor at some point in its travel path, and then count the number of pulses using a Beaglebone/Ardinuo/RaspPi/... (By "count", I mean generate a data item for each pulse - that data item could include GPS location, date/time, and a count.)
Do you mean cellular wireless, 802.14.* wireless, 802.11 wireless, ...?
Otherwise, there's lots of things that could be "connected", but must be connected without a wire. Fields, stock, product, equipment, ... Fields for monitoring soil health, stock for monitoring their health, product for location and maximum sell date, equipment for maintenance records and uses... There's lots of things, and a few tools already on this site - just need more, and its becoming apparent that a method of integrating the info produced by the tools is needed.
One of the biggest ancillary "problems" that goes with wireless, is how to get the power to the device - if only to support the device and its ability to transmit/receive. Batteries go only so far, and are a pain to maintain when they are remote. There needs to be better solutions!
Another thing is recordkeeping - for example, you move goats to another pasture - having that move automatically recorded for you would save a lot of time at the end of (a perhaps hectic) day, and it would be accurate. Same with equipment... I don't know how often I've missed fluid changes because I couldn't remember how often I've use the tractor/truck/... And plants, not only would it be nice to know how wet/fertile/... your soil is - you could save lots of water by not watering it if you didn't need to... Or if you had it automatically watered at night instead of during the day.
Well, I've got 3 base stations and 5 ear tags working. Still waiting for nickel & dime hardware (connectors for batteries, boxes, ...)
The base station software is 95% complete - all that's left is (maybe) coding the failover logic when we lose wi-fi access and including the time-of-flight numbers for each ear-tag (even though it will be wrong).
Also, configuration of the system is non-trivial, so I'll probably have to code some auto-configuration logic into the system - but not before the end of the month.
The ear tags are a lot heavier than I wanted; the batteries are over 2/3 of the weight, but I wanted 1 mile distance between tags, and that consumes a lot of "juice". I may be able to conserve power by setting sleep intervals for the tags, but not in the first release!
Otherwise the base stations and "ear tags" are ready for outdoor testing. I just have to cut holes in the boxes and shrink wrap the ear tags. Then we can do some testing - so probably not until next weekend!
I expect to publish all the code and do presentations in January 2016. And maybe do some documenting...
The images are of a base station (out of the white weather-proof enclosure), and a top view of the base station. The last picture is of the "ear tag" transceivers - left one is a debugging connection hooked up to the computer, and the right one (with battery) will be shrinked-wrapped and applied to an ear tag.
I've got most of the software written, but have run into some design problems (turns out tracking time-of-flight for XBee radios won't work), which will require some software re-writing. But, I'm making lots of progress.
Comments
About the bales
Do you want to correlate bales with their production location in the field? Or just know which field a particular bale came from? Either way, you'll need a way of identifying each bale in order to correlate back to where in the field that bale was produced.
With windrowing and tedding, it may be more difficult to determine which section of a field the hay in a bale came from. You can probably get within 20' feet (depending on width of your tedder/rake), but when the grass gets thin, then the numbers would get a bit sketchy.
How to do this...
I don't think you really want to replace the existing counter; you really just want to count bales and log their production.
The first thing I would consider is all the interface points to existing systems - both mechanical and telecom. And one would need to know what software will be at the other end. The reasoning for this is:
However, knowing how most balers work (for small square bales), I would look at attaching a reed switch to the trip arm that runs the counter. Put a door sensor at some point in its travel path, and then count the number of pulses using a Beaglebone/Ardinuo/RaspPi/... (By "count", I mean generate a data item for each pulse - that data item could include GPS location, date/time, and a count.)
Wireless?!
Do you mean cellular wireless, 802.14.* wireless, 802.11 wireless, ...?
Otherwise, there's lots of things that could be "connected", but must be connected without a wire. Fields, stock, product, equipment, ... Fields for monitoring soil health, stock for monitoring their health, product for location and maximum sell date, equipment for maintenance records and uses... There's lots of things, and a few tools already on this site - just need more, and its becoming apparent that a method of integrating the info produced by the tools is needed.
One of the biggest ancillary "problems" that goes with wireless, is how to get the power to the device - if only to support the device and its ability to transmit/receive. Batteries go only so far, and are a pain to maintain when they are remote. There needs to be better solutions!
Another thing is recordkeeping - for example, you move goats to another pasture - having that move automatically recorded for you would save a lot of time at the end of (a perhaps hectic) day, and it would be accurate. Same with equipment... I don't know how often I've missed fluid changes because I couldn't remember how often I've use the tractor/truck/... And plants, not only would it be nice to know how wet/fertile/... your soil is - you could save lots of water by not watering it if you didn't need to... Or if you had it automatically watered at night instead of during the day.
The list goes on and on...
--Bruce
Now power independent
Well, I've got 3 base stations and 5 ear tags working. Still waiting for nickel & dime hardware (connectors for batteries, boxes, ...)
The base station software is 95% complete - all that's left is (maybe) coding the failover logic when we lose wi-fi access and including the time-of-flight numbers for each ear-tag (even though it will be wrong).
Also, configuration of the system is non-trivial, so I'll probably have to code some auto-configuration logic into the system - but not before the end of the month.
The ear tags are a lot heavier than I wanted; the batteries are over 2/3 of the weight, but I wanted 1 mile distance between tags, and that consumes a lot of "juice". I may be able to conserve power by setting sleep intervals for the tags, but not in the first release!
Otherwise the base stations and "ear tags" are ready for outdoor testing. I just have to cut holes in the boxes and shrink wrap the ear tags. Then we can do some testing - so probably not until next weekend!
I expect to publish all the code and do presentations in January 2016. And maybe do some documenting...
The images are of a base station (out of the white weather-proof enclosure), and a top view of the base station. The last picture is of the "ear tag" transceivers - left one is a debugging connection hooked up to the computer, and the right one (with battery) will be shrinked-wrapped and applied to an ear tag.
Into testing
I've got most of the software written, but have run into some design problems (turns out tracking time-of-flight for XBee radios won't work), which will require some software re-writing. But, I'm making lots of progress.
Goal is to have a demo by the end of December.