I suppose that if there are many sensor nodes, there is a significant chance of collisions. Are these detected and will the emonTH retry the transmission?
Suppose you want to cover a 6-storey building with emonTH, say 2 sensor nodes per storey, so a total of 12 sensor nodes. And suppose that we find that 2 base stations are required to receive transmissions from all the 12 sensors. The layout might be like this:
L6 - 2 x emonTH: n27 & n28 L5 - 2 x emonTH: n25 & n26 , and a RPi with baseid=16 L4 - 2 x emonTH: n23 & n24 L3 - 2 x emonTH: n21 & n22 L2 - 2 x emonTH: n19 & n20 , and a RPi with baseid=15 L1 - 2 x emonTH: n17 & n18
Does this look OK?
Can both RPi send readings to the same emoncms.org account?
What happens if both RPi's "hear" the same transmission from n21 for example? I suppose both basestations might send the same data to emoncms.org there should be no bad effects right?
Or should I split them into 2 different network groups? Say group 210 for the lower 3 floors, and 211 for the upper 3 floors?
Also, do I understand correctly that there is no feature for privacy and excluding unwanted neighbors' transmissions? We simply have to choose different group id's if we ever encounter unwanted readings from neighbors?
Re: Questions about the radio link between EmonTH and RFM12Pi.
You can send from multiple base stations to one emoncms.org account no problem, the default max number of nodes is 32, which can only be overridden if you have your own emoncms server.
The 2 Pi approach should work ok to get the network spread you need although that will depend a lot on positioning and obstacles (walls and floors).
Depending on where you are in the world you may be able to consider 2 different frequencies for the 2 networks to avoid cross network collisions altogether,
It is difficult to know whether 2 distinct networks or 1 network with 2 base stations would give better coverage. 2 networks on the same frequency could reduce workload for each receiver but wouldn't reduce collisions, where as the single network may give better coverage to the overlapping area since the same packet can be received by either Pi.
To avoid collisions the best practice would be to use the time transmission facility used for setting the glcd's time to trigger the very first transmission from each node and also include a small delay to stagger the transmissions across the repeated interval. Doing this could be more complex with just one network as 2 time signals will be confusing and one time signal is unlikely to reach all nodes.
If legislation allows, the 2 frequency approach is probably easiest to implement with minimal fuss, but personally I would probably opt for a single frequency for flexibility, add the synchronization code and then experiment with 1 verses 2 groups and positioning.
The network transmissions are very simple, the 200+ group ids and fairly short range is usually adequate to get an exclusive network.
The transmissions from the nodes are not acknowledged or retransmitted so synchronizing the transmissions is highly recommended if there is a lot of traffic.
Paul
Re: Questions about the radio link between EmonTH and RFM12Pi.
May I know approx how many microseconds or milliseconds does the transmission of an emonTH last? If it is short enough, I probably can live with the tiny percentage of collisions.
What is the "time transmission facility" that you mention? Which box can transmit time?
Speaking of time, I do not remember setting up the real time clocks or NTP in the emonTH's or the RaspberryPi's, am I right that they data times I see on emoncms.org must be stamped by emoncms.org? The emonTH's transmissions do not include time stamp, and the basestations also don't include timestamps when inputting to emoncms.org right?
Thank you pb66 for the info.
Re: Questions about the radio link between EmonTH and RFM12Pi.
"May I know approx how many microseconds or milliseconds does the transmission of an emonTH last"
I think knowledge of the size of the payload and this page gives you that: http://jeelabs.org/2011/06/09/rf12-packet-format-and-design/
Time is normally broadcast by the Base node following interrogation of the server, which can be the RPi, emoncms.org or another server running emonCMS.
Re: Questions about the radio link between EmonTH and RFM12Pi.
I was referring to the time packet transmitted via the rfm2pi by emonHub, it is intended to keep the emonGLCD's time updated but could easily be used as a trigger for synchronizing the transmissions from the nodes.
The nodes are not time aware as they do not have an rtc or an internet connection for ntp so emonHub allocates a timestamp upon receipt of each packet. The Pi uses NTP by default if running Raspbian.
As Robert points out the duration of the payload will dependent on the size, the thing to bear in mind is although the collisions maybe reduced if the payloads are shorter, as the intervals are intended to be regular any collisions could be repeated in a cycle and/or if not controlled the pattern could shift slightly resulting in more (or less) lost packets.
Re: Questions about the radio link between EmonTH and RFM12Pi.
Thanks, according to the jeelabs packet description page, he said the no-payload minimal packet is 9 bytes = 72 bits ~ 1.5ms at 50 kbits / s.
I believe the payload of the emonTH is 4 ints = 8 bytes = 64 bits. So the packet is 64 + 72 = 136. So that takes about 2.72 ms to send.
I understand what pd66 means about the regular intervals though. Would be nice to add a random fudge of say 1% of the interval, to prevent long runs of bad packets.
Re: Questions about the radio link between EmonTH and RFM12Pi.
When we were having big problems with collisions and the emonGLCD, which turned out to be a problem in the library, one suggestion was that the conflicting transmitting nodes should transmit at intervals that were all prime multiples of the time unit, so that the possibility of a slowly creeping overlap (which I imagine your 1% dither is intended to alleviate) would be largely avoided. That and Paul's are two completely opposite approaches to the same problem, Paul is suggesting synchronising and the other relies on probability.
Bu there's a problem with Paul's suggestion: if the emonTH (or any node) is battery powered, it can't continuously listen for a time transmission in order to synchronise, on account of battery life. The best it can do, which will still be expensive in terms of power consumption, would be to turn on the receiver just before it expects a time packet; and when it sees it, send its packet immediately, or sleep until its slot comes round or whatever; and then sleep. If it doesn't hear it after a suitable interval, it must give up and wait for the next - and there obviously needs to be a strategy there to allow it to synchronise after a reasonable period if the transmissions are there. If the node is mains powered, listening continuously isn't a problem, so if there's only one battery-powered sensor node in the system, it makes sense for that to be the master clock and it will then never need to listen - the rest of the system will synchronise to that.
Re: Questions about the radio link between EmonTH and RFM12Pi.
oops! yeah sorry I overlooked the fact they were all battery powered emonTH's, I had a similar discussion some time ago about 30 emonTx's and just continued that thought process.
I think I would still favor synchronization over chance, but agree it's not such an easy task when considering sleep functions and power consumption.