Louis

Primary tabs

Louis's picture

History

Member for
7 years 8 months

Contributions

Stream of Forum Topics

In 50 characters or less... Posted by Post date Last comment Number of Comments # of Comments new to you
Anybody find a green jacket Hard Wear at the Essex Grange? Louis Monday, April 30, 2012 - 11:50am Sunday, November 4, 2012 - 10:02pm 4
Local Zigbee Network on a Farm Louis Saturday, April 28, 2012 - 3:06pm Sunday, September 2, 2012 - 10:29pm 12
Pushing Arduino Memory Louis Friday, April 6, 2012 - 12:04am Sunday, April 8, 2012 - 8:07pm 1
[Solved] Running out of Pins Louis Wednesday, March 28, 2012 - 3:16pm Thursday, March 29, 2012 - 10:52am 5
Guide to Posting Louis Friday, March 16, 2012 - 10:13pm Friday, March 16, 2012 - 10:13pm 0
Done: No clear way to browse wiki Louis Sunday, March 4, 2012 - 11:59pm Thursday, March 29, 2012 - 10:45pm 12
Syncing Excel with Google Calendar Louis Sunday, March 4, 2012 - 11:42pm Friday, December 28, 2012 - 5:55pm 1
Done: Can I edit my posts on the forum retroactively? Louis Sunday, March 4, 2012 - 11:13pm Thursday, March 29, 2012 - 9:49pm 4
Smart Farm Wireless Network Louis Thursday, November 24, 2011 - 12:00am Thursday, May 3, 2018 - 3:31am 2

Stream of Forum Comments

Louis's picture

My 5 passenger car will be leaving around 6pm in an effort to meet Ithaca, NY before midnight. Entertainment for the driver, gas, and a lack of farting are expected of passengers.

0. Louis
1. RJ
2.
3.
4.

Louis's picture

Hi Andy,

This sounds very interesting to me. I'm currently developing a general purpose long-range, weather-proofed, sensing and automation board. The communication options will include Zigbee (local wireless protocol, longer range, lower bandwith than WiFi) and 3G. The idea is to have real-time monitoring as well as user-determined logic (if sensor A reads above threshold X, do action 1) and schedules.

I would love to hear about this application and any others you may think up. Initially, I was actually thinking more along the lines of your post below which talks about the motorized flaps.

--Louis

Louis's picture

Thanks for bringing this up. The component [you mention](https://www.adafruit.com/products/735) is the same that I used and it will do the trick! I edited the tool page to include this.

Louis's picture

Thanks for the feedback, Josh! I've fixed up the tool page to try to make things more clear. Here is the section that I think is relevant to your question:

Download the libraries above and unzip them. There should be three individual folders, each containing at least two files, one with a .h suffix and one with a .cpp suffix. Open your Arduino sketchbook folder. If there is already a folder there called libraries, place the library folder in there. If not, create a folder called libraries in the sketchbook folder, and drop the library folder in there. Then re-start the Arduino programming environment, and you should see your new library in the Sketch > Import Library menu.

Once your libraries are properly installed, you should have access to all the relevant code from your Arduino IDE. Please let me know if that *doesn't* clear things up - I'd like to do everything I can to make it easier for folks to build these things!

Louis's picture

Good find! To save on anchor costs, I reckon at most three need GPS.

Louis's picture

But turn-around does eliminate the need for synchronization at least...

Synchronization won't be too bad since distance will be easier to calculate (even without GPS) since both sides have good & identical clocks. Actually, it would be neat to do this without GPS which makes this system entirely relative until you take some global references from GPS!

Louis's picture

Hey guys,

Sorry I'm probably late to the game but I have been tied up moving into a new apartment and office last week. This discussion has made great reading material though!

Just to make sure I've understood, it's settled that a good clock is only needed on the anchor station? Seems like this turn-around technique is a nice solution and will yield an absolute answer for each individual anchor (ie: it will tell you node 32 is 50m away).

I just wanted to offer another idea which I thought came up in one of the discussion threads but I can't seem to find and that's to use ratios:
If you have 3 anchors and they all receive the SAME signal from a node, they will have three different times when they clocked in the message (let's say, 00:01, 00:02, 00:03). The differential in time received will help determine the relative difference of the node (that is, if the node is distance X away from node 3, then it is 2x/3 from node 2, and x/3 from node 1 - a unique point satisfies that relation). I like the turn-around method better since it immediately yields absolute distance and doesn't require synchronization but if that becomes a problem for technical reasons, this could be another approach.

Louis's picture

That is an interesting idea... I kind of like the idea of figuring out manufacturing myself but maybe this could definitely be a good option if/when I find out I've bitten off more than I can chew!

Louis's picture

Look forward to those. I might have interest in that rain barrel supplied automatic irrigation system for my home!

Louis's picture

The datalogging shield from Adafruit includes an integrated circuit that provides a Real-Time Clock (RTC). It gets the current time when you upload code. It will use the coin battery to maintain accurate time when the shield is not getting powered.

If you notice that the time isn't being kept properly, it may be the coin battery that doesn't have a decent contact. I had that problem because I didn't put a significant enough blob on the circuit board. Let me know if you are having any issues and I can help you troubleshoot!

Louis's picture

The datalogging shield from Adafruit includes an integrated circuit that provides a Real-Time Clock (RTC). It gets the current time when you upload code. It will use the coin battery to maintain accurate time when the shield is not getting powered.

If you notice that the time isn't being kept properly, it may be the coin battery that doesn't have a decent contact. I had that problem because I didn't put a significant enough blob on the circuit board. Let me know if you are having any issues and I can help you troubleshoot!

Louis's picture

Indeed! Seems like a good design alternative for those that don't have easy cell phone access. I think also warrants a spot in the documentation at least as a note for now. Perhaps somebody will implement it and provide a little tutorial!

Louis's picture

Good point!

I think that would be nice to include in the tutorial. I can write it up when I have a minute unless you'd like to.

PS: Welcome to the community!

Louis's picture

I believe LiDAR would be used in this context to generate a topological map. It would be interesting to convert the 3D displays in topological maps and see how they match LiDAR.

LiDAR is kind of expensive - last time I checked the most affordable ones were about $800 but those didn't have a huge range... In the practice of topology mapping I believe they fly over with LiDAR so I would guess you need a decent range.

Louis's picture

If you have wiring for LED indicators then tapping into that with an Arduino would be a breeze and there wouldn't need to be much repurposing of Fido software for this. It wouldn't take too much time for me to hack something together for you...

Just a few questions: what's the power situation out there? I take it that the power for the fence could also power this alert system. Also, how many miles is it from your internet? I'm antsy to start building Zigbee nodes rather than making different permutations of the Fido design although the remoteness and the generality of the on/off signal could still merit an independent cell phone node design.

Louis's picture

Processor speed is a concern not for computational reasons but for timing - we need the difference in time of flight for the radio waves which travel at the speed of light so we need a fast enough clock for whatever accuracy we want. I think that once this type of system is established, it will give much more accurate and reliable readings then the other method we discussed.

The other method, which I believe you are referring to, is to simply read the signal strength (already built into Zigbee) and extrapolate from there but as we discussed the other weekend, analog signals are noisy and this one in particular has many different variables affecting it other than distance. I think that it would be a quick and easy way to get ball park estimates but would be difficult to get very precise.

Louis's picture

What if you just had a 12v solar panel hooked up to the wench directly? That way you save the expense of a battery assuming you don't mind it not running at a constant rate.

Louis's picture

Hey Andy, Is there a tutorial or bill of materials or pictures of that portable micro-hydro unit?

Louis's picture

Hey Eric,

Can't tell you how excited I am to hear about your progress! I've uploaded the current Fido library to Github but I have a few caveats based on what your post.

If you remember a post I made a few weeks ago, Fido was getting strapped for memory. In response to that, I switched to an analog temperature sensor (see new BoM) instead of the DS18B20. It won't be difficult for you to change the getTemp() function such that it will work with the DS again but you'll probably run out of flash memory, especially if you also have the LCD. Thus, if you want to keep all those components, you might have to strip down some of the things from the Fido library I've uploaded; a good place to start is to play around with those char arrays in the beginning of the code. They're written in PROGMEM but I think you'll catch on quickly if you read this post on my site.

Anyway, let me know if you have any questions! Oh and I actually have a question for you: is that voltage divider giving you fairly reliable reads? I changed mine out for a logic shifter and it's been more consistent for me; I ordered quite a few and I'd be happy to send you one if you PM me your address (they cost 40 cents but if you go about trying to buy just one you'll end up spending 5 dollars).

Louis's picture

Would you pair each one of these with an Arduino? If so, that seems like a hassle and you might be better off using Xbee chips since they would be able to take your readings and send them without an Arduino and you would be saving some money and development time.

It might be a fun project to buy the RF transmitter/receive modules and pair them with AVR chips yourself (ie: buying the chip and not the Arduino) and you might finagle something cheaper than an Xbee chip but otherwise I'd recommend Xbee with an analog sensor.

Louis's picture

Thank you for the semantic check there! Trilateration is indeed the correct term.

I imagine that triangulation might be able to get figured out but I have a hunch that we may sacrifice range by doing that.

Insofar as the clock limits, let's say we want to be accurate within 1m. Since the speed of light is 3x10^8 m/s, we need a clock of 3x10^8 Hz, or 300 Mhz (I think?).

The Beaglebone has a 720Mhz processor and that should work and hopefully we'll be able to utilize the full accuracy of that clock (I've never tried measuring how fast radio signals travel and haven't done all my research yet). I imagine that there will be some constants involved with sending and receiving a message before we can put a time stamp on it but I think that they can be calibrated those out since those will always be the same with the same hardware.

Louis's picture

Glad it's been found! Things are pretty warm down here in Boston so I won't need it for a few months but pass it onto Severine if you get a chance (I'll be going to Hudson at some point). Otherwise, the Adirondacks were beautiful and I may just get up in your parts again this summer - maybe I could pick it up then?

If we get around to winter and we still haven't passed it back maybe I'll humbly request a mailing!

Louis's picture

There are still some logistical questions that need to be resolved but, insofar as I can tell, the general theory works. Let me know if you foresee any problems.

You have three reference nodes which GPS transmitters, thus you know their distance and direction from each other. Each of these reference nodes is also ZigBee enabled up to a certain range; the overlap of these three ranges is where we can accurately triangulate trilaterate.

Any slave node roaming within the overlap of three node ranges emits a message and the distance can be calculated based on Time Difference of Arrival; that is, the difference in arrive time to the three nodes can uniquely determine a location.

I'm not sure where direction may become an issue...

Louis's picture

@Ben: I've included some extra explanations in the preparation steps of our build process. Feel free to write any critiques here or edit/reword as you see fit. And let me know if you have more questions or ideas of things that could still need explaining (just make sure it's not already on the to-do list at the bottom of the page)

Also, I've running Fido with a logic shifter currently and the communication runs a lot more reliably now. I will be running Fido all week and will hopefully have a fairly stable program ready for this weekend!

Louis's picture

Awesome RJ - I like the questions!

What is the biggest challenge you are currently facing with the current Fido design?

Now that the code has been slimmed down to actually fit onto the Arduino, my biggest challenge is the cell phone. The Arduino and the cellphone talk at different voltages and I think that that is the origin of the current inconsistencies in behavior.

What do you think your next two steps will be developing the design for Fido?

Currently, a voltage divider brings the Arduino's 5V down to 3.3V. This does the trick but I think makes the device very fickle. I am going to try to do the same connection with a chip called a logic shifter instead and see if that resolves the issue. If it fails, then I'll know that there is a fundamental issue in the library I wrote for the cell phone and I will try tweaking that again
Louis's picture

Hey Eric,

It's great to hear that this device interests you! I'm tweaking the code of our first prototype and we'll hopefully have some sort of walk through within the month. On the wiki, I've linked to to where you can get most the parts but you'll have no trouble finding an Uno!

I've never used them myself but I hear great things about Adafruit's Arduino tutorials. If those don't suit you, you'll easily others floating around online!

Louis's picture

I am Louis Thiery and I like to play with electronics. My first exposure to farming was this summer when I spent 3 months WWOOF'ing in Colorado – I loved the work and the lifestyle but wanted to find a way to integrate my specialized interests and skills.

As I paged through catalogues for farm electronics, I was a little surprised how expensive the devices were. In addition, all the technology was closed and standardized which didn't make sense for small farmers who run idiosyncratic farms and like to tinker with their devices. Thus I decided I'd start working on open-source electronics for farmers, giving myself an opportunity to further my skill set while also attempting to make these technologies more accessible and individualized.

I'm currently living in Milford, NH and working from the Gardenbot.

[this comment was migrated from the old Farm Hack Forum, it was originally posted on 11/24/2011]

Louis's picture

I think it ties the name and concept together perfectly.

Louis's picture

Spent all day working on the user list management, their user groups, and can now program via text message! I'm starting to run low on memory though...

Right now, you can definitely program and reprogram it with text messages and other users can join by text message too. Once I have the whole program consolidated (I'm working on two different programs that I will merge soon), I will work on adding some bells and whistles like human readable commands like RJ was saying. However, I think that we will run out of space very fast that way so I will first start on user management commands, like seeing if a user exists and removing users.

Insofar as programming FOR people via web service, it would definitely be neat! I don't think it will even take any extra code to make Fido run with it.

Louis's picture

Nope - I think I came up with it around the same time that you did!

Anyway, I've been thinking about the protocol and how this could work and have the following proposal:

Fido will be programmable and reprogrammable by text message. You can text a bunch of different numbers separated by commas to program it all in one text (in some predetermined sequence so Fido knows what to do with it) or you can write some keyword followed by a number to change only a certain preference as RJ specified above.

I also think that I will implement some basic "usergroups". First off, Fido will answer any text message not started with '#' by telling the person the current time, UNLESS privacy is turned on (owner will be told that someone unauthorized is texting in this case). When privacy is on, only known numbers can ask for current.

Fido can remember up to 16 numbers plus the owner. Anybody can text '#' followed by the 4 number PIN determined by owner, followed by: - nothing or '0': they will be allowed to text for current even if privacy is on and they will get emergency text messages - '1': above, plus they will get daily summaries - '2': above, plus they will get updates throughout the day (ie: they get all the communications that owner gets)

Only owner can reprogram and remove users.

Anyway, I thought that incrementing of permissions made practical sense but let me know what you guys think. Also, let me know if you think anything is unclear or could be simplified!