Primary tabs

jbd's picture


Member for
8 years 1 month


Stream of Forum Topics

In 50 characters or less... Posted by Post date Last comment Number of Comments # of Comments new to you
XBee Communications jbd Friday, November 23, 2012 - 12:01pm Friday, November 23, 2012 - 12:01pm 0
BeagleBone vs. Real-time scheduling jbd Monday, November 19, 2012 - 1:29pm Monday, November 19, 2012 - 1:29pm 0
Have to turn off mesh-networking in XBees. jbd Sunday, September 9, 2012 - 6:01pm Sunday, September 9, 2012 - 6:16pm 1
Determining Distance jbd Monday, September 3, 2012 - 10:14pm Monday, September 3, 2012 - 10:26pm 1
Current State jbd Monday, September 3, 2012 - 10:02pm Thursday, December 17, 2015 - 8:07pm 8
I was sorta expecting "Add Tool" to... jbd Monday, September 3, 2012 - 9:28pm Saturday, December 1, 2012 - 3:04pm 1
"Handy Farm Devices and How to Make Them" jbd Monday, September 3, 2012 - 8:26pm Thursday, December 20, 2012 - 10:31am 1

Stream of Forum Comments

jbd's picture

Water weighs about 8lbs/gallon, so a full 250 gallon container would weigh at least a ton, and a lot of roofs can't support that kind of weight in a small area.

Another thing to consider is surface area - the more surface area you expose the water to, the more heat loss there'll be. So on a cold night, you may lose all of your heat by midnight instead of 6am! Using a variable number of bladders that can be easily filled from a larger water mass (tank) is probably best. Good idea Louis!

jbd's picture

There are several revenue streams created by Open Source projects that don't require licensing, although the revenue stream itself is frequently protected with a license:

  • Support - offering support/modifications/customization for a fee.
  • Training - offering training and "How To" information for a fee.
  • Customization/modification - although in the software world, modification has to fit within the license, it can still be done at a fee.

Also note that a significant revenue stream is consulting - especially for productization. Note that the rights holder of a copyright and/or patent can offer their IP under multiple licenses - a free "Open Source" license, as well as a "commercial supported" license.

jbd's picture

After discovering that the real-time scheduler was not in the Angstrom distribution shipped with the Beaglebone, I've decided to pursue the statistical method of determining position. There are several other reasons for this:

  • It allows for better portability between platforms.
  • Removes the need for a fast processor.

Note that I'm still planing on using the tri-lateralization method of determining exact position (versus the triangulation method frequently mentioned in this project), but the various legs will be measured using statistical methods instead of direct time-of-flight.

The downside(s):

  • Coding time will be longer for the anchor points.
  • Testing time will be longer.
  • It will take a lot of additional testing to establish reasonable baselines for statistical measurements.
  • It will require more "samples", which will probably adversely impact battery life on the remote sensors (ear tags).
jbd's picture

Everything in the bag was intact and operating. Now back to work for me!

jbd's picture

The http://farmhack.net/forums/tool-wiki-template link above results in a "Page not found" error.

Feel free to delete this comment when/if the above is fixed!

jbd's picture

Evidently, the bag never left Boston! The prototype unit is now in my possession. I'm not sure if it works yet or not, but will find out in a few days.

jbd's picture

The prototype "anchor point" (and one "ear tag") was in a bag lost by American Airlines on 1 Nov 2012. Its been 3 days since the loss, and the bag has not been located yet. This is a setback for the project (well, at least for my involvement), as it will take a while to find the funds to get replacement hardware.

Up to now I was working on the software: testing the real-time scheduler, latency tests, looking at the serial device driver,... I can continue this work to a limited extent, but I really need the hardware for real answers.

jbd's picture

I did some more calculations, and it looks like we'll need about a 2GHz chip to get resolution less than 1 foot. Probably faster. I just want to get the proof-of-concept working, then we can attach the radio to an ASIC or something for higher resolution.

jbd's picture

I believe Louis was indicating that we could do positioning without GPS; which is technically correct but not necessarily desirable, and assumes we know exactly where the anchor points (aka base stations) are located.

Synchronization of the end points (ear tags) with the anchor point is no longer required since the anchor point will be sending the signal to the end points (ear tags), which will just echo it back; and all timing (with a 700 MHz clock) occurs on the anchor point. However, synchronization of the anchor points will be required for the reasons you pointed out. Since all the anchor points will have GPS's on them, this can be done with reasonable accuracy, and be checked/re-done frequently.

Latency in the radio, GPS, and CPU (deterministic and non-deterministic) will have to be empirically determined. And we'll have to re-run the tests with every new batch of processors, CPUs, GPSs and XBees. Sigh.

jbd's picture

The differential times are all that's needed from the anchor points to calculate the distances, so it would make the logic/coding a lot easier.

jbd's picture

I like the two way transmission idea. The anchor point doesn't have to be quite as fast - but still needs to be able to sense the departure and return times within 300 microseconds. And we can "fake" a signal by wiring the TX to the RX on the ear tag.

I too am making the assumption that turn-around time is constant - at least between the XBees. We'll need to empirically test how much latency the mesh network adds too.

I'll start looking at a device driver to do this (because it needs to be done at interrupt level to keep the OS from introducing latency). Once I get the driver done and tested, we'll need more beaglebones and XBees to test/write the trilateralization logic.

Oh, I guess we'll be needing the GPS interface logic written too. That is critical for translating the "local" positioning info into global positions.

So, I guess the real next step is software architecture planning.

jbd's picture

RFID requires close proximity to read the tags (the military has a system that can read tags up to 300' away - but it requires a comparatively large tag and a high powered reader - neither of which are suitable for our application.) EZ-Pass uses a high powered reader, but even its range is about 30'. Most marathon RFID systems need a proximity of 7' or less.

Our application needs a "proximity" that's a MINIMUM of 300' (outdoor; line-of-site), which our prototype XBee's meet - and are a lot cheaper than RFID tags with equivalent range; better proximity (for farms) would be in terms of thousands of feet or miles, which the XBee Pros give - but they consume more power. Rangeland would require ranges in miles to tens of miles. But simply adding anchor points may accomplish the same purpose.

Unfortunately, cell phones don't provide sub-meter accuracy. There are several systems in use by the cell manufacturers, Wikipedia has a good description of the various techniques. Of course, most farms are located in rural areas - notorious for lack of cell towers.

I originally wanted to have "inch" accuracy, but I'm willing to be a little sloppy on that. I do need identification of the tag, and get as close as possible; which is why I wanted a very high resolution clock on the radios. With synchronized high resolution clocks on both sides of the signal, we can calculate a rather precise distance between the endpoints, and not have to worry about software/interfacing latencies. (Although I believe the XBee's mesh networking may complicate or render that approach impossible. Without further testing, we can't be sure.)

I should point out that the XBee's provide a received signal strength metric, but its only accurate to 2 decimal places (-40db to current gain setting). But I don't believe this will provide sufficient accuracy in determining distance.

jbd's picture

You'll need something to convert the sensor signal to serial data so it could be sent over the XBee's modem.

Unless you're just sending 1 bit of info, in which case you can use the DTR pin on the XBee. This would probably work for preset alarm info.

jbd's picture

The original plan has us capturing the time the packet arrives (which we can do on the beaglebone because the clock is 700MHz), but we can't capture the time of departure from the tag.

Hmmm. Do we really need the departure time?

jbd's picture

I really like the idea of having classifieds. Although I think it would be best to exclude companies from submitting things for sell, just let it be individuals.

jbd's picture

Finally found some specs, and it looks like the oscillator on the Chronodot is only 23.768KHz. I believe we'll need at least 300MHz for 1 meter accuracy. So, even if the SQW on the Chronodot (a.k.a. Maxim DS3232) rises at the start of a second, it won't be accurate enough for us. Sigh.

jbd's picture

The GPS has arrived and I verified its operation on the beaglebone.

Also, Ben Smith (from CCOM at UNH, and an old sailing buddy) has joined the project and briefed me on the PPS (Pulse Per Second) signal provided by most GPS's. Since, to keep cost of the "roving radios" down, we won't have much computational ability on the rovers (if any); rovers == cattle ear tags.

I've noted that the chronodot has something similar to the PPS, but I don't know if it is tied to the "start of the second" like it is on most GPS devices. Iif it is, and if it gives us sufficient accuracy, then we can use it for sub-meter accuracy. (I'd really like to have 1-inch accuracy, but I'm willing to give up on that somewhat.) The chronodot is low power and relatively temperature insensitive, and we can probably get it to shut down every few seconds to improve the power consumption.

I think the next steps are: 1. Prototype an "ear tag" rover with an XBee, battery, and chronodot. 2. Verify the rover can talk, over the XBee, to an anchor (Beaglebone with GPS and XBee).

jbd's picture

I purchased two XBee's, a beaglebone and their various accessories for development. Two XBee's are required to check the timing algorithm between a "cow" and one of the anchor points, one of the XBee's will be on the beaglebone (acting as an anchor point with a GPS), and another will be on my laptop/workstation (acting as a cow).

At this stage of development, we're only concerned with getting the various components checked out and writing any low-end software required to interact with the hardware components.

I've looked at the XBee specs, and although the power requirements for the Series 2 are in line with our needs, I suspect we'll need to add a high-resolution clock to the XBee to get sufficient accuracy in distance measurement. And I'm really concerned about weight and power draw - don't forget, these things have to be small enough to fit on an ear tag or (at most) a collar.

I've got the GPS on backorder.

jbd's picture

This appears to be http://www.farmshow.com/

jbd's picture

Something that has been used with some success in the Open Source world is bounties... One would offer a bounty for a solution to a problem.

I know its not much different from an "X Prize", but tends to attract those with the knowledge and time to perform "one off" projects. But things like explanation and documentation could be a problem.

Of course, in all cases, patent/royalty-free would be required. And this brings up an ugly potential issue that would need a lawyer. Groan.

jbd's picture

We can always transmit the data we get from the radios on the mobile units, upload it to the anchor points, and let a server do the computations. Supposedly the anchors are fixed positions (and may be GPS enabled).

However, as I remember my radio theory, we will need a number of samples to get a reasonable approximation to use in differential distance computation to the anchor points. Each radio will have to be calibrated to determine what its "reasonable sample rate" would be. Or does the Zigbee already do this? (does it provide a signal strength, or do we have to get the analog strengths in real-time)? Or am I thinking too deeply?

jbd's picture

There should be a minimum of 3 anchor points; more are allowed for scaling up. The three anchor points provide for triangulation to determine the location of "slaves". The radio technology being used is likely to be Zigbee (because it is more tolerant of errors; albeit with lower bandwidth than wifi or cellular).

The "slaves" (need a better word) are also zigbee enabled and can communicate with the anchor points to transfer data (such as location, attached peripherals, internal data).

The anchor points can be BeagleBone devices, which can use an Internet connection to communicate with and "optional" central server. That Internet connection can be (for example) Wifi, LAN, 4G, ...