Author Topic: Mesh / Battery / Germany  (Read 4051 times)

rocsta

  • NewMember
  • *
  • Posts: 32
Mesh / Battery / Germany
« on: March 13, 2015, 08:29:46 AM »
Hi all,

I'm planning a private project (perhaps) using Moteino.

Some words to the project:
It's a "hunting project"  ;D. I live in Germany and here only fox traps are allowed, when they catch the fox without killing him. I think they are called in English "live traps" (as in German). And: these live traps have to been checked two times a day.

Now I would like to use Moteino for the surveillance and the catch mechnism. Catch mechanism is no problem, but I see some problems concerning the surveillance.

The traps are in the field, between 500 Meters and 2 Kilometers from my house. We have in Germany strict regulation concerning the waves to be emitted, and we have an authority, which also checks, if there are some complaints. The fine, if you does not  keep the regulations is between 1.000 and 5.000 Euro - quite expensive.

Therefore I can only use the Moteinos in the allowed range (that means 10dB).

So I can only use Moteinos, if I'm using a mesh Network and I have to put some routers in the filed to cover the possible gaps.


And here are my questions:

1. I have learned, that the routers in a mesh network have to be online all the time. This might bring some problems for me, concerning the runtime on battery (with or without solarpanel) (the runtime should be at least 2 or three months). For me it is not important, that the endnodes deliver their catch Messages the whole day. It also would be sufficient, if they were asked two or three times a day, if there was anything happen.
Would it be possible to make the following scenario:
1. I set the Routers (and the Endnodes) to sleep mode.
2. The "Concentrator" (in my house) sends a "wake-up-call" to all nodes (and waits some time).
3. The "Concentrator" aks the end nodes for their status (something trapped or no, battery Level, etc.)

2. Are there any experiences concerning the usage of Moteino in Germany?

3. Are there any experiences with the RFM69W concerning the range using "only" 10 dbm, with the smallest transfer rate possible (the states to be transmitted can be reduced to some Bytes)?

Thanks a lot,

and sorry for my bad, school english, which has been sleepen since some years,

Kind regards from Germany,
rocsta




Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Mesh / Battery / Germany
« Reply #1 on: March 13, 2015, 08:43:58 AM »
rocsta,
Welcome and interesting project!
To receive a packet a node has to be in RX mode. There is a sleep mode that tries to save battery life by quickly cycling between sleep and RX, but it reduces the chance of receiving, or your transmitter would have to retry until it hits a RX slot in that cycle. THe RFM69 lib does not impllement this mode but there's this thread where I shared some code and some others have discussed this mode, if it's something you want to try out.

However I think with a rechargeable battery charged by solar, you can implement some mode where the node is in RX for some time then sleeps. The receiver could "catch" and "synchronize" with the nodes when it finds them. Then everybody would sleep and RX at ~ the same time. That could be a 1-5-10-60 minute window, whatever makes sense, with an equivalent for sleep. This is just another idea.

You can reduce the output with setPowerLevel(). For W this is linear, for HW it's intermediary (0-15 is the same as 16-31 (repeat)). Ensure you check the power so you don't get fined.
There are a few threads discussing altering/reducing  the bandwidth, bitrate to extend the range. This is essential to start having a long range. If this is in the forest with a lot of trees in between that will of course be a factor that reduces range. Any obstacles depending on penetration will reduce range on any radio.

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #2 on: March 13, 2015, 09:36:21 AM »
Hi Felix,

thanks a lot for your answer.

If I understood you, you would propose to define a "communication window", in which all endpoints and routers have to be online. And in this window I collect all the date from the endnodes?
I think, this may be a good idea.

Just two additional questions:
- the Moteino Mega (I planned to use in the project) does'nt have a RTC? Seems to be interessting to ensure that all have the same communication window.
- the Moteino Mega has three Interrupts, one of them ist used for RF? So I can use two for my trap control?

Kind regards,
rocsta



edesio

  • NewMember
  • *
  • Posts: 5
Re: Mesh / Battery / Germany
« Reply #3 on: March 13, 2015, 12:23:36 PM »
Interesting project!

Just an idea but you can hardwire the moteino at the trap to be only energized when the trap is full. This should save lots of energy.

Take a look at MQTT-SN (http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf) for some ideas on communications with low power and intermittent connections. The protocol is probably an overkill in this case but the ideas are sound.

Edesio

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #4 on: March 13, 2015, 02:21:20 PM »
Just an idea but you can hardwire the moteino at the trap to be only energized when the trap is full. This should save lots of energy.

Basically a good idea, because it would save lots of energy indeed, but one important feature in my project should be have the possibility to deactivate the traps "from the desk" sometimes. For example, when I plan to go on business travel: We plan around 10 or maybe 20 traps and i would like to avoide to run 2 hours  from one trap to another for deactivating them, when I'm only one day out of office/home (and naturally the same run one day later coming back for activating.


Take a look at MQTT-SN (http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf) for some ideas on communications with low power and intermittent connections. The protocol is probably an overkill in this case but the ideas are sound.

Thank you für sharing.
That's interesting, because it gives me some hints what I have to consider for my "command module". First of all, that I have to store commands somewhere, if they were launched out of the mentioned communication window (what will be the standard), so they can be send to the traps in the communication window.

ohoh, I see, this will be more and more complicated, but a nice challenge.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Mesh / Battery / Germany
« Reply #5 on: March 13, 2015, 03:16:42 PM »
Hi Felix,

thanks a lot for your answer.

If I understood you, you would propose to define a "communication window", in which all endpoints and routers have to be online. And in this window I collect all the date from the endnodes?
I think, this may be a good idea.

Just two additional questions:
- the Moteino Mega (I planned to use in the project) does'nt have a RTC? Seems to be interessting to ensure that all have the same communication window.
- the Moteino Mega has three Interrupts, one of them ist used for RF? So I can use two for my trap control?

Kind regards,
rocsta
I agree with the others, you have an interesting project.  Felix's advice is good and it's good that you realize that an RTC will help immensely in coordinating scheduling.  If you search for 'Arduino RTC breakout' you should find plenty of choices that should interface easily to either Moteino or Moteino Mega.  Using I2C interface for the RTC (or Two Wire, TWI, as it's sometimes called) will help avoid conflicts with the SPI interface.

Regarding interrupts, you can use pinChangeInterrupt on most of the digital I/O pins on either Moteino or Mega.

Good luck,
Tom

edesio

  • NewMember
  • *
  • Posts: 5
Re: Mesh / Battery / Germany
« Reply #6 on: March 13, 2015, 07:00:51 PM »
Quote
Thank you für sharing.
That's interesting, because it gives me some hints what I have to consider for my "command module". First of all, that I have to store commands somewhere, if they were launched out of the mentioned communication window (what will be the standard), so they can be send to the traps in the communication window.

You only have to store commands if you want to send commands TO the trap node.

You can simplify the protocol to something like this:

  (trap -> gateway) I will go to sleep for 10000 seconds. I will contact you after that. And node goes to sleep.
  (optional) gateway goes to sleep for 10000 - 10% seconds.
  (gateway) waits for communication from 10000 -10% to 10000 + 10% seconds.
  (trap -> gateway) I am awake. Send status. Is there anything for me? (probably not or at most one command -- can be a simple array indexed by trap number)
  (trap -> gateway) I will go to sleep...

This "10%" is some measurement of the trap/gateway clock drift. And it should not accumulate from one transaction to another.

 

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #7 on: March 13, 2015, 07:37:34 PM »
You only have to store commands if you want to send commands TO the trap node.

Yes, thats the point. I would like send to the nodes a command like "do not catch anything until I give you another command" or (new idea :-)) "do not catch anything in the next 48 hours"

You can simplify the protocol to something like this:

  (trap -> gateway) I will go to sleep for 10000 seconds. I will contact you after that. And node goes to sleep.
  (optional) gateway goes to sleep for 10000 - 10% seconds.
  (gateway) waits for communication from 10000 -10% to 10000 + 10% seconds.
  (trap -> gateway) I am awake. Send status. Is there anything for me? (probably not or at most one command -- can be a simple array indexed by trap number)
  (trap -> gateway) I will go to sleep...

This "10%" is some measurement of the trap/gateway clock drift. And it should not accumulate from one transaction to another.

Yes, theoretically. But (I really don't like the EU-Regulation-mania), there is another regulation, beside the maximum wave power, the german word is "Tastgrad", the dictionary proposes "(pulse?) duty factor" maybe also "duty cycle" (I'm not sure, if this is correct). It means, that you can use this frequence only at 0,1 % of the total time, that means 0,1 %  of the hours (or the day ? - I have to check this). Other sources speak about "< 10 %", which would be sufficient.

Yes, here in Germany, some things are more complicated then in other regions of the world, but we have still the "Autobahn" :-D.

BTW: I don't not, if I wrote this already - I really hate the EU-Regulation-mania.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Mesh / Battery / Germany
« Reply #8 on: March 13, 2015, 07:40:48 PM »
Quote
Thank you für sharing.
That's interesting, because it gives me some hints what I have to consider for my "command module". First of all, that I have to store commands somewhere, if they were launched out of the mentioned communication window (what will be the standard), so they can be send to the traps in the communication window.

You only have to store commands if you want to send commands TO the trap node.

You can simplify the protocol to something like this:

  (trap -> gateway) I will go to sleep for 10000 seconds. I will contact you after that. And node goes to sleep.
  (optional) gateway goes to sleep for 10000 - 10% seconds.
  (gateway) waits for communication from 10000 -10% to 10000 + 10% seconds.
  (trap -> gateway) I am awake. Send status. Is there anything for me? (probably not or at most one command -- can be a simple array indexed by trap number)
  (trap -> gateway) I will go to sleep...

This "10%" is some measurement of the trap/gateway clock drift. And it should not accumulate from one transaction to another.
Assuming the gateway is always powered, there is no reason for it to sleep and it can be listening constantly.  The real problem is with the repeaters, which have to propagate the status of the traps to the gateway, but are, themselves battery powered.  Given that the requirement is only 'checking' on the traps twice a day, it's not unreasonable to set it up, in a conservative fashion, to have a reporting window every 6 hours, where, if there is an RTC at each trap and repeater, it is very feasible to set a very narrow window of time in which all the battery operated nodes wake up at a specific time, pass on their information, and then go back to sleep until the next 6 hour window. 

Given that there are only 20 traps and presumably half as many repeaters, and with repeaters, by their nature, having 2x traffic, means that you might have a burst of 40 packets.  If you geographically schedule these, so the gateway isn't totally swamped with 20+ packets within a narrow time window, it's reasonable to be able to set up a sub-minute window for each 'branch' of the network.  That's a very low duty cycle ( <1 : 360)  and would easily meet the battery life goals with 1000mAH or less batteries...

Further, the gateway's reports could be logged to provide legal verification of the requirement to check the traps at least twice a day.

Finally, if the traps need to be disabled for any reason, the gateway can simply queue these state changes for the next time the traps report in.  The gateway can return the state change in the Ack to the 'branch'.

Tom

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #9 on: March 14, 2015, 05:24:29 AM »
Thanks a lot, TomWS, really good ideas:
So, to make it more understandble for all of you, please find enclosed an attachment with a map (sorry for the white boxes, there are a lot of hunting opponents out there, and sorry, that I will delete the attachment in some days):

- I split the nodes in branches / blocks (see attachment)
- the different branches / blocks will report to different times
- the acknowledgement of the gateway/concentrator will contain the desired commands
- and also the logging is a really good idea!

Generally the idea of the time/communication windows (and the resulting reduced power consumption) brings a lot of Advantages. So I can put at least one of the routers somewhere on the hill (in the north of the village), these will probably bring some more range for me.

Really, really good ideas!

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Mesh / Battery / Germany
« Reply #10 on: March 14, 2015, 09:10:28 AM »
Danka!  The map is very helpful in understanding the application.  Given the buildings in the path between your eastern branches and the gateway/controller, I'd say at least one of the 'possible routers' (I'd use the term 'repeater', but router works as well) would be necessary.  The one on the hill would be ideal, but it's forested and, as Felix pointed out, you could get a lot of attenuation from the trees.  It looks like very good placement of the intermediate routers.

There has been a lot of discussion regarding repeaters but, as far as I know, no solution has been posted.  I'd really like to see your implementation when its finished and, I'm sure you can rely on this forum for help.  I think your application is good in the sense that RTCs can be used effectively to allow synchronized scheduling.

What do you have in mind for antenna (or is that too far away to think about yet)?  Depending on the frequency you've chosen, the metal grid on the top of your traps might be an effective ground plane for the antenna (lower frequencies would be better).

And, speaking for myself, I think it is entirely appropriate to keep the map on the forum for others to see in the future (unless the location of the traps is a 'secret'...  :D

Tom

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #11 on: March 14, 2015, 11:54:50 AM »
Danka!  The map is very helpful in understanding the application.  Given the buildings in the path between your eastern branches and the gateway/controller, I'd say at least one of the 'possible routers' (I'd use the term 'repeater', but router works as well) would be necessary.  The one on the hill would be ideal, but it's forested and, as Felix pointed out, you could get a lot of attenuation from the trees.  It looks like very good placement of the intermediate routers.

On this map, it looks like trees, but it's more grassland with some (low) agriculture on it, and it's quite "cliffy". The position of the router is well chosen, because from this point I have a line of direct sight to the roof of my house (in which the central point/coordinator will be placed) and also a direct sight to the eastern block, but this is quite far away...

Quote
There has been a lot of discussion regarding repeaters but, as far as I know, no solution has been posted.  I'd really like to see your implementation when its finished and, I'm sure you can rely on this forum for help. 

After I received my hardware, I will start a first range test (in the german law restrictions). I think the main challenge will be to build up a reliable transmission between the eastern / the southern block and the cental point (gateway). For the western part I'm quite optimistic.
One reason is, that I will put the repeater in a heigh of around 4 meters over ground, so I will have a nearly line of sight.


Quote
What do you have in mind for antenna (or is that too far away to think about yet)?  Depending on the frequency you've chosen, the metal grid on the top of your traps might be an effective ground plane for the antenna (lower frequencies would be better).

Concerning the antenna, I will do some tests first. First with the 1/4 wavelength monopole wire antenna and a very low baudrate (I really don't need a high Baudrate) to get a first impression about the range. Then I will see...


Quote
And, speaking for myself, I think it is entirely appropriate to keep the map on the forum for others to see in the future (unless the location of the traps is a 'secret'...  :D

It's not a sceret, but I'm a little afraid of persons, who don't like hunting. Perhaps we will find a compromise, some kind of block diagramm (traps, village, hill, etc.).
« Last Edit: March 14, 2015, 01:43:39 PM by rocsta »

rocsta

  • NewMember
  • *
  • Posts: 32
Re: Mesh / Battery / Germany
« Reply #12 on: May 05, 2015, 05:31:36 PM »
So, I will report a little bit:

I'm a litlte bit afraid - it works too easy.

What I have done:
- I defined a struct for the configuration of a trap (trap_id, trap_activated, gateway_adress) named "tc_configuration"
- I defined a struct for the reply of the gateway (trap_id, trap_activated, trap_time) named "tc_reply"
- I defined on the gateway an Array storing, if a trap should be active or not.

I just send the struct tc_configuration to the gateway. The gateway sends back in the acknowledgement the struct "tc_reply", which I can use for the activation / deactivation and the time_sync of the trap. And it works fine, surprisingly.

And I bought an raspberry pi 2, where I installed "openhab".
I already implemented an Interface using the Serial Interface to synchronize the states of the traps, so I can check and administrate my traps.

Good or bad ideas / way?



TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Mesh / Battery / Germany
« Reply #13 on: May 05, 2015, 06:36:12 PM »
So, I will report a little bit:

I'm a litlte bit afraid - it works too easy.

What I have done:
- I defined a struct for the configuration of a trap (trap_id, trap_activated, gateway_adress) named "tc_configuration"
- I defined a struct for the reply of the gateway (trap_id, trap_activated, trap_time) named "tc_reply"
- I defined on the gateway an Array storing, if a trap should be active or not.

I just send the struct tc_configuration to the gateway. The gateway sends back in the acknowledgement the struct "tc_reply", which I can use for the activation / deactivation and the time_sync of the trap. And it works fine, surprisingly.

And I bought an raspberry pi 2, where I installed "openhab".
I already implemented an Interface using the Serial Interface to synchronize the states of the traps, so I can check and administrate my traps.

Good or bad ideas / way?
Well, that's what you get when you do it right!  It works!  Congratulations! 

Now to the tough question, does it work in your backyard or does it work with your traps deployed throughout the town?

Tom