Good morning,
I have read through the mesh network, promiscuous and broadcast threads on the forum in an effort to work out the best way to build a repeater simply.
Firstly my situation. We live on many acres, and even the buildings are a good distance apart, not counting other things we would like to add a node to (water tanks for example). In the past I have used ASK 433Mhz transmitters (cheap, short range) and converted to TCP/IP UDP packets to allow remote connections of a network of sensors. Our sensors are low bandwidth and low speed. Mostly only sending updates once per minute (e.g. temperature).
I am now looking at Moteino as a better all round solution. I have already built a 433Mhz Relay node which converts the old ASK 433Mhz sensors into a Moteino packet. I am using 915Mhz Moteinos.
Now I am looking at how to extend my larger network. The simplest solution I could think of is a combination of the following:
- Assume a single Gateway - Node ID 1
- Assume a single Network ID
- Node ID is included in the Struct being sent (to allow forwarding)
- Repeater - sends again every packet it sees (promiscuous dumb mode)
- OR Repeater - sends only packets with no ACK (promiscuous, far more coding required)
- OR Repeater - listens as Node ID 1 and sends to Node ID 1 (dumb mode, but not promiscuous)
- Gateway is responsible for ignoring duplicate messages
My struct looks a bit like this
typedef struct {
uint8_t version; // Protocol version
uint8_t networkId; // Network ID - in case of forwarding across networks
uint8_t nodeId; // Node ID - unique this device
uint16_t runId; // Run ID - New ID each time device is booted
uint32_t uptime; // Devices' uptime (e.g. milli seconds, anything really)
char data[32]; // Value - string - if required
} MOTESNODE;
As it includes the newtorkId and nodeId I am able to forward it from one node to another (ignoring the actual node origin or destination) and even across networks.
The other radios I have experience with (RFD900) can't do this as they are frequency hoping radios and all require access to the base node to sync their signals.
There are two other methods I can think of to do a repeater: Use multiple networks; Have multiple Gateways (Node 1).
Thoughts? Will this approach work ok? What are the negatives of such a simple approach? Can I have multiple gateways as Node 1 if they are not acknowledging (or even if they are)?
Thanks
Scott
I'm not sure what value 'runId' and 'upTime' have in your network. I'd think that once you've established a nodeId for that node, why would it change? I do think that having a 'length' parameter in a packet containing data gives more flexibility with a single byte cost - you can't have more than 64 bytes in a packet, therefore length can't be more than 8 bits.
In my case, I start up a remote node with a default Id of 250 (totally arbitrary) and it broadcasts a message effectively saying, I need the closest gateway. Gateways respond with their own 'descriptor' giving the node a chance to decide which gateway to use based on the gateway's rssi (all other nodes ignore the broadcast). Once the node decides on a gateway, it tells the gateway, "give me a device Id", something truly unique within that 'network'. Once assigned, it needn't change. I also include deviceClass in the transaction so that the node can tell the network what kind of device it is, eg temperature/humidity Mote, etc.
In any case, I think you've chosen a good device for the kind of network you have. Have fun and this is the right place to get ALL kinds of advice. ;D
Tom
Awesome Tom... I love the idea of broadcasting for a Gateway. I assume you can then change the Node ID - thus automatically allocated? - re-read first :-)
Yes length - good idea. All my current devices are just a long (signed or not depending on device). Having longer data is a good idea though. Are all packets 64 bytes? In which case may as well still use a fixed struct?
Run ID and Uptime is for the individual node. Each time I restart any device, I increment a RunID and store in EEPROM, and uptime is simply how long the device has been operating (I am going to use seconds). This gives you some useful information on your nodes, e.g. that they have rebooted. EEPROM is good for more writes than I can fit in a 16 bit number anyway, so that is safe :-)
Self discovery - love it. Ta.
Do you know if there is any down side though (in a simple case) to having multiple Node ID 1? (other than ACK).
Quote from: scottpenrose on January 07, 2015, 09:46:30 PM
<...snip>
Do you know if there is any down side though (in a simple case) to having multiple Node ID 1? (other than ACK).
I'm not sure I understand your question. In my case, where I start with a default ID (ie 250), the id is VERY temporary when the node is first deployed and replaced with a fixed ID soon after. Since I'm too old (and slow) to deploy more than one node at a time, it's not a problem and there is no conflict ;)
Tom
Sorry for the confusion Tom. It wasn't about your code, I just meant in general, if you put two Moteino setup as NodeID 1 - won't they both get the packets without any conflict or issue - so you can just run multiple Gateways? (logic aside, obviously even the acknowledgement would get confusing). My understanding is the nodeId is only a filter in the radio, so should be no issue.
I have written an implementation of hello - what I called it. Transmit hello and device type, wait for response. Currently selects any response (later will wait for a period and choose best RSSI etc). The gateway is assigning the next free NodeID based on the oldest message first. I keep a table of NodeID and the last access time (started as MAXINT) and allocate the first to match MAXINT, or the largest number (oldest entry) - therefore it can reuse old entries.
My limitation (well in todays code) is that only the master gateway has this list - if the other gateways have the list then you could have overlaps. My simplest solution to that is to allocate a block of IDs to each gateway. How did you resolve that problem?
Thanks. Scott
Quote from: scottpenrose on January 08, 2015, 07:15:20 AM
Sorry for the confusion Tom. It wasn't about your code, I just meant in general, if you put two Moteino setup as NodeID 1 - won't they both get the packets without any conflict or issue - so you can just run multiple Gateways? (logic aside, obviously even the acknowledgement would get confusing). My understanding is the nodeId is only a filter in the radio, so should be no issue.
Yes, both nodes will receive the packet (actually ALL nodes 'receive' the packet but the interrupt handler discards anything that is not the node's ID, BROADCAST, or, if promiscuous is on, anything else). As you say, you can't Ack in the case where two nodes have the same Id - they will surely collide.
How does each node with Id==1 'know' that the Gateway is telling IT to change it's address? Unless you have some other distinguishing content in the command, won't both nodes use the new ID, perpetuating the problem? By the way, I didn't think you were talking about my code, I was just giving an example of what I was doing...
Quote from: scottpenrose on January 08, 2015, 07:15:20 AM
I have written an implementation of hello - what I called it. Transmit hello and device type, wait for response. Currently selects any response (later will wait for a period and choose best RSSI etc). The gateway is assigning the next free NodeID based on the oldest message first. I keep a table of NodeID and the last access time (started as MAXINT) and allocate the first to match MAXINT, or the largest number (oldest entry) - therefore it can reuse old entries.
My limitation (well in todays code) is that only the master gateway has this list - if the other gateways have the list then you could have overlaps. My simplest solution to that is to allocate a block of IDs to each gateway. How did you resolve that problem?
Thanks. Scott
In my case the Gateway is truly a gateway and forwards practically everything to my server, including DeviceId requests. The server processes the request and assigns an id that is unique for that Network (I use 4 different Network Ids and at least 4 gateways, one or more for each network). Hence, the id, being centrally managed, won't conflict. In fact, the Gateway, while currently keeping a list of each new deviceId it is 'connected' with, so far, I haven't had a reason to use the information from that list...
Tom
Thanks Tom. Scott