MicroMesh - IoT Mesh Network

Low cost mesh network, using cheap and readily available components

Similar projects worth following
Networks of IoT sensors are great but to really get them to take off they need to be easy to use, cheap to buy, and have a long battery life. This project aims to create a mesh network of low powered devices that are able to communicate to the internet.

The ultimate goal will be to have a simple to join meshed network of devices that can be easily programmed with new sensors and purposes to make an advanced network of connected devices using components that most hackers already own.

There are three main components to this project:
• Node – This will have all available pins broken out to enable sensors and many uses around the house (temperature sensor, light switch, etc)
• Gateway node - This routes packets to and from a server (see below) that is attached to the internet
• Server – A server that will act as a gateway to the internet, handling security between the internal mesh network and the outside world

System Design

The design document below shows generically how the whole system will work:

The idea is that there will be a new 'internal network' running on the nRF24L01 wireless chips that are connected to the outside world via a gateway node (converts nRF24L01 into Serial) which is connected to an internet enabled server (Raspberry Pi). This combination will allow for enhanced security and easier development of web based interfaces without requiring expensive and awkward to use Ethernet shields or WiFi modules for the Arduino platform.


  • Should be simple but flexible enough to allow for a variable payload length
  • Multiple sequence of packets (will allow for large packets to be chunked)
  • Allow for encryption (payload encryption)
  • Packet failed to reach (resend count/delay)
  • Auto discovery (easy to join network)



  • All pins broken out (breadboard friendly)
  • Low power draw (sleep states)
  • On board charging (power monitoring and charging IC)
  • Battery monitoring (alert on low power)
  • LEDs (status)
  • Button (reset/join)


  • USB serial integrated (will look like a USB stick)
  • On-board sensors (potentially temp sensor)
  • High gain antenna (to give this node the best possible chance of packet collection)


  • Web enabled (https)
  • Database of interactions (historical graphing/logs/etc.)
  • Map of devices (similar to 'mesh diagrams' above)

Use Cases

  • Temperate monitoring (temp/humidity)
  • Plant/soil sensors
  • Repeaters (increase range)
  • Door opening/closing
  • Heating system
  • Lights/plugs
  • Local GPS tracking (e.g. dog in garden)
  • Position triangulation (limited by lack of RSSI on chip)
  • Proximity sensors
  • Alarms
  • Enabling internet content to embedded devices

Openness and Connectivity

Hardware and software are developed using open source and free tools. The project will be open source including schematics.

  • PCBs designed in Eagle CAD (not open source but is free for size of board)
  • Software for AVR developed using Arduino and Notepad++
  • Software for server developed using Eclipse (Java, C++)
  • All files will be uploaded to GitHub when complete

Connectivity is a very core part of this project:

  • All nodes are connected by a mesh network topology
  • Gateway node utilises an internet connect server for internet connectivity
  • Configuration of the network can be done via any https enabled device
  • Framework for web GUI will be open and allow for 'plugins'

External dependencies

The RF24 library is used as a starting point for wireless communication, the protocol will sit on top of the RF24 stack to sort and deliver messages to the correct nodes and handle encryption and allow for callback functions to make development simple and easy.

  • 1 × ATMEGA 328p Node and Gateway processor
  • 1 × nRF24L01+ 2.4GHz ISM wireless chip
  • 1 × CP210x USB to Serial chip
  • 1 × Passives Misc caps, resistors, crystals, regulators, etc.

  • Prototype V1.1J

    Giles Burgess12/31/2014 at 14:46 5 comments

    I have finally got round to building and testing what I hope to be nearly the final prototype of the hardware.

    Changes since previous version:

    • Footprint for nRF24L01+ on board! No more SMD daughterboards..
      • This has the added benefit of allowing for a u.FL connector for antenna (I have just used a ~3cm wire instead for the time being
      • The antenna pad has a via going through it so in my above example there is no worry of the pad 'breaking' but I would advise not to use a solid antenna (copper wire) but to use something flexible and plastic coated
    • Buttons moved back to original location for compactness
    • Added another capacitor to 3.3v line to avoid brownouts on nRF
    • Added capacitor to the switched VBAT charging side (C6) to stop the charge indicator flickering
    • Vias on the USB to make the socket stronger
    • Easy ability to cut PWR led to save more power
    • Changed CE and CSN order to better fit with other libraries (CE=D9, CSN=D10)
    • The above image I have only populated the minimum parts to prove it worked, which meant I used a 0 (Zero) Ohm resistor across the transistor pins (Q1) to allow VUSB to power the circuit (doing this means you CANNOT have a battery AND USB at the same time (would require unplugging the battery to avoid charging it with 5v (which would kill it or burst into flames..))

    Further thoughts:

    • Still a small amount of space to the right, ideas:
      • RTC chip
      • Flash memory
      • Integrated antenna
      • RGB LED (why not!?)
    • Board is two sided populated, would be ideal if only one side populated but that increase board size a fair bit.. however it would make mounting a battery to the other side a lot easier
    • Change the charge chip for one with integrated buck converter with fixed 3.3v
      • More efficient everything running on 3.3v
        • Potentially less compatible with peripherals
    • Extend board to the right to include an integrated antenna
    • Include current sense resistor (up to 200ma?)
      • Alternatively include a 'powermeter' IC
    • Add support for 'iPhone 4 battery' pinout
      • To use existing powermeter from that, also 1800mAh battery is a good size
    • Put the charge indicator output to an input pin so software can monitoring charge state (rather than guessing on voltage)
    • Change processor for ARM (STM32F103XX)
      • More processing power
      • Less power draw (when down-clocked)
      • More pins available
      • Could potentially remote USB-TTL (can be emulated)
      • Probably won't fit current footprint

    Next steps:

    Next steps for this project is to build a few more of these (all improvements to current design don't really affect it too much unlike previous designs where there have been some large flaws or so) and get working on the software side (arguably the most interesting bit, but I really wanted the hardware pretty locked down before I got to this stage to make it easier to test).

    To make testing and programming easier, I will make a 'jig' that will basically be an AVR programmer to make it very easy to upload code to all the 'nodes' at once (I can remove USB-TTL on most of the nodes which will bring costs down).

    Software is going to be based initially on the MySensors library/architecture but I will be making some specific examples for my hardware and most importantly for me will be power conservation and the 'gateway' software to link everything together!

    • Second batch of prototypes

      Giles Burgess11/07/2014 at 18:04 3 comments

      The V1.1H have arrived and I have tested them out

      The main changes are the use of a SMD version of the nRF24L01+ breakout board, and the 'load sharing' circuit to both charge and balance the voltage load to the board, as well as fixing all the other bits in the previous post. Ignore flux residue, need to clean that up..

      Power usage:

      • Radio off: 12mA
      • Radio on: 24mA
      • Arduino power down: <1mA

      In the worst case that the radio was always busy (no power downs) a 500mAh batter would last just over 21Hrs. If this were a sensor transmitting once a second (assume 100ms awake time at 24mA, power down at 1mA, so averaging 3.3mA) the 500mAh battery would last 6.3 days!

      Things to fix:

      • This SMD version has TERRIBLE range, I'm talking <4M - DO NOT BUY!!
        • It does not have as many passives as the green version, also very small antenna, I think it is a combination of the two (datasheet for this is non-existent!)
        • Possible options are to cut trace and solder antenna (painful)
        • or to actually include the footprint of chip on my PCB with an antenna pad to allow a 3cm wire or a u.FL connector for a dipole antenna - theres lots of space on board so should be possible to have an integrated antenna
      • The charging LED flickers rapidly when battery not connected, need to put a capacitor on that line to prevent noise from the chip detecting battery presence
      • Add some vias to the USB tabs, accidentally snapped the USB off because all that is holding the pads is the glue holding the copper to board.. some vias will make this a lot stronger!
      • The extra button is right over the nRF meaning you pretty much have to place fingers on the nRF in order to press it, could do with moving back to where it was before
      • Ability to cut power LED trace to further reduce power
      • The ON/OFF labels were from the previous version, they are backwards in this one
      • Put the TX/RX LEDs VCC source as same as ATMEGA, currently attached to USB in
        • This would mean when running on battery power, the TX/RX LEDs will light up on activity without a USB power source (required at the moment)
      • Make a 2nd version that has an FTDI header instead of USB-TTL chip?
        • Probably not needed as all pins are broken out anyway, just don't populate the USB-TTL chip and USB connector. 'RAW' pin would allow battery charging

    • Prototype Arrived

      Giles Burgess10/12/2014 at 13:35 0 comments

      The version 1.1D prototypes have arrived! There were a number of issues with the design, some of which I discovered during the time they were being shipped, and others when trying to populate and debug.




      Issues to solve:

      • Used the CP2102 chip reset (that is the CP2102's) line. Use DTR and NOT RST
      • The button footprints were difficult to solder, needed more pad space
      • Battery charging circuit worked fine, however I want to redesign it
      • nRF24L01+ overhangs the PCB almost doubling its length!
      • Rushed soldering job (Micro USB is difficult to hand solder, re-flow it next time)

      Reworked design:

      • Fixed RST/DTR issue
      • Shrunk board length slightly (could be shortened a fair bit more)
      • Removed old nRF24L01 module and replaced for an SMD version (link). Not quite as cheap but a lot smaller, only overhang on PCB is the antenna!
      • Moved LED and button to board edge
      • Changed charge circuit to 'load balancing' so that when on USB output is 5V (no load on battery so charging can reach 100%) and when not on USB output is VBATT. Maintained the switch to be able to fully disconnect battery from circuit

      Possible improvements:

      • There is some blank space so possibly either SPI memory, or an RTC to add
      • Reduce size of board (maybe change to MEGA32U4)
      • Change buttons to more standard ones
      • Change charging IC to one with an inbuilt regulator and run off 3.3V
      • Change ATMEL for ARM (STM32)
      • Integration shunt + sense IC to determine mA draw to estimate battery life
      • Integration battery 'fuel gauge' IC to estimate battery life and %

    • Prototype and LiPo charging

      Giles Burgess08/23/2014 at 18:30 0 comments

      This is the nearly complete prototype! There are a couple of things still to do and notes about my design:

      • Micro USB connector - Nice and small
      • On-board USB-Serial IC - Makes code upload and debug a lot easier
      • Input power switch - Choose between VUSB (RAW pin) or VBAT
      • On-board charging IC - Will charge by USB (more notes below)
      • Follows same pinout as the 'Arduino Pro Mini' however is 0.1" wider
      • nRF24L01 (green board) header used (better range with the green vs black) on SPI + D10 + D9 + D2 - Antenna points away from PCB which I may change so that it points over the board to use less space?
      • 3.3V regulator for nRF24L01 only (will include header for any 3.3V devices)
      • D8 as LED and A7 for button (pull-up resistor included)
      • ~40mm x ~20mm

      There are two options I can do for the charging IC:

      1) Have a switch to control which VCC is used (VUSB or VBAT), USB always charges battery and battery is always connected to the battery charging IC
      2) Use a transistor for 'load balancing', when USB plugged VCC switches to VUSB and VBAT charges without powering board

      Option #1 is used on the LilyPad so it is tried and tested, but load balancing would allow for USB to be plugged and unplugged whenever as automatic switching will happen, the switch would just act as on 'on/off' switch for the battery only (allowing it to be completely disconnected from the circuit to remove phantom drain from the charging IC.

      There is still a little board space left so I will modify the design to use the following charging circuit:

      This diagram came from:

    • Board layout and design

      Giles Burgess08/20/2014 at 18:24 0 comments

      Trying to work out what form factor to design the node for. I have toyed with the idea of making it the same footprint as the 'Arduino Pro Mini', which could be possible but would definitely be a squeeze! I've enlarged the width by 1 pin header (0.1") to make a little more room for the wireless chip, but I think for this version I should not worry about making it so compact as it may make debugging difficult.

      The layout above on the right is the battery charging circuit (that also allows power from 5V without constantly charging or wearing out the battery (once tested will post schematics as this may be useful for many other projects!)) and this as well as a 3.3v regular, a number of caps/resistors and a button aren't going to entirely fit on the board so will most likely need to increase the board length! If I am doing this then I will probably also include a USB port and a USB to UART chip to avoid the need for the FTDI header.

    • Concept video

      Giles Burgess08/19/2014 at 16:42 0 comments

      This is a concept video where I talk through the project and explain things in more detail in a more visual medium:

      This is the first time I have really done a serious video, learnt a lot from doing it so the next one should be even better! Either way I think my idea has come across :)

    • Populating prototype hardware

      Giles Burgess08/17/2014 at 14:58 0 comments

      When designing the PCB, I thought I had done everything right however there were a number of flaws with my design which I only realised after populating and uploading code to the nodes

      • TX and RX lines wrong way round (had to use breadboard and jumpers to flash)
      • nRF24L01 interrupt pin not attached to D2/D3 (had to keep polling nRF24L01 for activity)
      • 2 LEDs using one digital pin (to get 3 states) did not work as expected ('floating' state would turn both on, forward voltages were too high on LEDs)
      • Modifying nRF24L01 to use an SMA connector was not easy
      • Needed pull up resistors on transistors so they were not in 'floating' state during flashing (buzzer would sound when uploading code as pin was neither LOW nor HIGH)
      • Not all pins were broken out in an easy to get at location (not breadboard friendly)
      • No 6 pin ISCP connector (burnt the firmware using a device that sits ontop of the m328p chip)

      Despite all of these problems I did get them built!

      Here is an example of a simple menu system showing some statuses:

      The back shows the modifications I did to the nRF24L01 module; it used to have a PCB antenna which I removed and soldered in place an SMA connector. The transplant was not too difficult but quite fiddly!

      While not perfect, protocol development is underway and time to design the real node PCBs instead of these prototypes! By doing these prototypes I have learnt a log about do's and don'ts of PCB design, look out for my next post about the changes and some general rules of thumb I have learnt so far :)

    • Prototype hardware PCB design

      Giles Burgess08/17/2014 at 14:39 0 comments

      Building circuits on a breadboard is great way to prove that something works, but only as a temporary solution. This is especially true of trying to test and develop something that requires multiple devices (nodes) such as this project! The best thing to do is prove that the hardware works and meets all requirements and then design and fabricate a PCB.

      For my first version of the PCB I have tried to make the hardware with many options so I can explore what would be useful in an IoT device.

      The above image shows a serial node prototype and an LCD Monitor prototype. The node features an ATMEGA 328p, 2x leds, 1x button, nRF24L01, and an FTDI compatible header (more on this later). The Monitor features all of the items on the node but includes a buzzer, 5 way direction pad, a Nokia 5110 LCD, and a compass.

      The serial node is as bare as it gets and I am going to use it with an FDTI adapter to allow quick development of the wireless protocol. In its current state it could be used to relay serial data over the network to any serial device (e.g. connect two Arduino Unos over the mesh network without requiring any libraries, just plug the TX and RX into the node and configure the destination address for serial data to send to)

      The Monitor will be a way of controlling all IoT devices within the network by using a series of menus to send commands to other nodes. It can also be used to show the status of all nodes and various alarms can be set (e.g. low battery alarm, doorbell ringing, etc).

      As with anything, I expected there to be mistakes and I valued quick prototyping over spending a huge amount of time trying to design something perfectly only to find a small error in it! This was no different as after I got the confirmation email of the boards shipped I noticed that the TX and RX lines were reversed! (the images above show the 'fixed' revisions). This must be similar to the "when do you notice a spelling mistake in your email? Right after you've clicked send!" type of thing!

    • Adding to the Internet of Things

      Giles Burgess08/17/2014 at 14:26 0 comments

      I have become very interested in microcontrollers and especially communication between two (or more!) devices, and while working on another project I was looking for a library that would solve the 'mesh' network using the nRF24L01 chips, but one doesn't seem to exist! So what better way to solve this problem than design and make my own, and make it available for anyway to use.

      By using OpenSource and OpenHardware this project allows for anyone to use and contribute to a growing army of networked sensors, and enabling others to learn about the IoT without starting from square one.

      What is so special about this project? The concept of a mesh network really fascinates me and what this project will aim to deliver is a reliable mesh network that will enable any minion to communicate with the gateway or another minion on the network, even if it is not within range of each other!

      Why another IoT project? For the Internet of Things to really be useful it requires good core networking, as without a reliable network the information will not be all that useful. This project aims to tackle this while being as cheap as possible, easy to develop for, and be able to run from batteries for a long time.

      I have been working on some of these things slowly over the last few months and it was only recently pointed out to me that I should document it and publish it here on hackaday :)

    View all 9 project logs

    Enjoy this project?



    Wassim wrote 12/24/2017 at 19:59 point

    I read in your project logs further thoughts would be to take this mesh to the STM32, well that's what I added to the #Home Smart Mesh , project. Actually, the HW is not limited to the nodes I made myself, as I even connected readily available nRF51822 beacons to the mesh. Same as here, the idea is that RF nodes can communicate with each other independently from the server, and the whole thing is connected to IoT SW running on Raspberry pi (MQTT, InfluxDB, Grafana, React,...)

      Are you sure? yes | no

    Valent Turkovic wrote 05/24/2017 at 20:57 point

    Has there been any progress or news?

      Are you sure? yes | no

    Jorge SAER wrote 09/09/2016 at 12:41 point

    Amazing work. However I have a question. 

    What is roughly, the maximum number of nodes this mesh network can handle?

    Thanks for your support

      Are you sure? yes | no

    Cheney-Xu wrote 11/10/2015 at 08:23 point

    HI,whear is  the source code ?

      Are you sure? yes | no

    Rob Steele wrote 07/08/2015 at 13:42 point

    Awesome job so far Giles ! How is everything coming along ?

      Are you sure? yes | no

    slawson1990 wrote 06/13/2015 at 12:30 point

    Hi! This is exactly what I have been seeking for my home automation project. The battery monitor and charger is an excellent inclusion - really hammers down the size of required nodes. Just wondering how you are getting on and if you have any intentions to distribute your hardware through any outlet? You mentioned the use of the MySensors project for testing thus far, I am also using this as the backbone for my sensor network. Have you considered some of the other hardware they propose to include such as the hardware security chip ATSHA204A and EEPROM for OTA updates? Could be perfect for that extra space you have left over on the board?

    Can't wait to see what your gonna do with the porject, the hardware is looking fantastic so far!

      Are you sure? yes | no

    sureshmali wrote 06/12/2015 at 04:24 point

    I came across this post which implements security between nodes. It has the option of using HW signing as well as Software signing.

      Are you sure? yes | no

    Giovanni De Rosa wrote 04/08/2015 at 08:17 point

    Very good job!

    ... what kind of mesh protocol have you got in mind? Modified AODV?

      Are you sure? yes | no

    Joao Ribeiro wrote 03/09/2015 at 15:40 point

    I think something like this should be definitively included in a space launch! Actually, a few of these should be launched, and everybody else sending stuff to space would then be able to use these devices as a mesh network backbone.

    So, for this to become space worthy along the lines I've specified it will need at least two transceivers for in space comms, which I suppose the current nrf24 would do just fine, and a third one intended for the downlink, which I think would be feasible with a ESP8266 coupled with some sort or bidirectional radio amplifier and nifty antenna :) Or you can use another nrf24 modded in the same way, but working as a gateway to the mesh, instead of a node...

    Anyway, such a mesh network deployed in space would be a seriously interesting and powerful resource that would enable many many things that would be impossible otherwise.  

      Are you sure? yes | no

    Giles Burgess wrote 03/11/2015 at 12:26 point

    Great comment, a small low powered mesh network in space would be great, a benefit to this would be that each 'node' would have sensors for whatever you wanted to put in space, but you'd also have a 'gateway' IN space that would just be relaying the mesh network back to earth! I don't think an 2.4GHz will make it down to earth, but something like a 433mhz module and some buffering of data would be feasible :) The main thing i am focusing on at the moment is getting the mesh backbone and hardware reliable enough! But what you suggest sounds a great real use for it

      Are you sure? yes | no

    e.papet wrote 01/09/2015 at 13:20 point

    Hello evryone, i am a french developer.

    Thank 's for this talk.

    My Open Source Project ( Assistance to the preservation of people dependent at home) share the same Use Cases (WIRELESS CONNECTED OBJECTS GATEWAY).

    My node is a Tennsy 3.1 board with nRF24L01+ shield.

    My gateway is the same as node but write in serial port, the serial port is connected with my server serial port.

    My server is Media processor with debian and node.js ( Olimex A20 Board).

    Evry source are in GPL Licence.

    best regard's

      Are you sure? yes | no

    adlard.matthew wrote 01/03/2015 at 14:34 point

    Curious if you have thought about these issues,

    > Real time updates. Secure sockets allow the remote interface to receive real time updates from the Gateway Nodes. No boring browser refreshes.

    > Automatic recharging capacity, via miniature wind turbine, or solar, with discharge and overcharge capicity monitoring.

    > Wireless over-the-air programming of critical devices or those enclosed in difficult locations (especially the Gateway/nodes which is wired in remote locations).

    Can see these being useful with remote access Usb weather stations and the Open Map scheme.

    The IoT mesh network you have could be useful here as you can have these linked through out a town/ city/ island and help with weather mapping.

      Are you sure? yes | no

    Giles Burgess wrote 03/11/2015 at 12:22 point

    Great comments!

    1. Real time updates should be a must, some kind of push infrastructure. Certainly the very least would be email alerts (e.g. a node is running low on power)

    2. The circuit has built in charging circuit, so as long as ~5v is applied they will start charging. There is also load balance switching happening meaning that if you supplied 5v input, that will be what is powering the ATMEGA etc, rather than the battery (it would just be put into charging) .. One thing I have not yet done is tied the ENABLE or STATUS pins to the ATMEGA which may be able to help for this kind of stuff ('smart' charging kinda thing)

    3. Great point, I think i have seen bootloaders that will allow this, seeing as this is basically just a nRF24L01+ connected to an ATMEGA I don't see why this shouldn't be possible!

    One thing I think that needs mentioning is security. Currently there is no form of encryption or anything and if remote FW flashing were made it would require some form of security considerations because you wouldn't want your devices to be programmed with rogue code, especially if used for anything that could cause harm (garage door openers, or switched plugs etc)

      Are you sure? yes | no

    adlard.matthew wrote 03/11/2015 at 12:56 point

    Glad you mentioned the security angle as been talkijg quiet a bit about this via Twitter wityh other open source Hardware grouos, and curious if these will inlcude software/hardware encription options.

      Are you sure? yes | no

    Giles Burgess wrote 03/11/2015 at 13:08 point

    For the time being to reduce complexity I'm not doing anything more than IDs in the message packet to identify devices, and I think for most things (e.g. weather station) encryption is not required, however when the communications become two way (e.g. open a door, do this, turn that on etc) then authentication and encryption IS needed, therefore in future both types of messages will need to be supported.

      Are you sure? yes | no

    adlard.matthew wrote 12/26/2014 at 18:23 point

    Think this project and these, , would be really interested in seeing what you guys all come with together as each raise interesting ideas in separate aspects of the same project.

      Are you sure? yes | no

    Squint wrote 11/20/2014 at 06:32 point
    Question.. You say the power draw of the Nrf24L01 is 12mA when the radio is off..

    How can you turn the radio off and still maintain a link within the mesh?.. Do you have a way of waking the radio when messages are received and require re-broadcasting? Even 24mA is very good..

    Have you got the Nrf24L01 able to wake up the arduino? I played with this a bit but never successfully managed to get it working correctly.

    Have you tried Chip Antenna's ? I believe they offer better range, You may also need to perhaps move the antenna of the smd modules, I have found they are quite sensitive to other electronics and need to be shielded very well from other components..

    Have you thought of building a single board with both the Nrf24L01 components and the 328p together?

    Sorry for all the questions, Im investigating doing this exact same project.. so i'd love to assist you with your work or learn from your doing. :)


      Are you sure? yes | no

    Giles Burgess wrote 11/20/2014 at 08:13 point
    'Radio off' is by doing a powerDown on the radio (its probably using a tiny bit of power) but the 12mA is basically the 328p in NON sleep mode. It is not possible to be in power down AND be part of the mesh. Possible solutions are to have 'always on' repeaters (or for example a mesh device inside something that always has power). My plan has always to have devices that will communicate infrequently (to increase battery life) but still requires other devices to be always on. The 'Radio on' is with 328p in NON sleep and the radio in receive mode, I really should do a test with 328p IN sleep and the radio in receive, as thats the case it will be in for longest

    Yes I have, the IRQ pin is tied to the Arduino 'D2' pin which allows me to 'attachInterrupt'. I think it depends to what level you put the Arduino to sleep, I'll do some experimenting.

    Chip antennas due to their small size I have always dismissed and alyways tried to opt for a ~30mm wire instead.

    Yep I have already designed that and sent for PCB :) designed it with a u.FL connector, so a wifi antenna can be use, or a ~30mm piece of wire can be soldered to the pad (+via for strength) to be a little more compact and have better range! Will post when they arrive

      Are you sure? yes | no

    Squint wrote 12/30/2014 at 07:49 point

    Any luck with the custom boards?

      Are you sure? yes | no

    Giles Burgess wrote 12/31/2014 at 15:12 point

    Yep check my latest project post, looking to getting a small batch built to save me hand soldering all of these!

      Are you sure? yes | no

    Squint wrote 01/01/2015 at 06:57 point

    Wow, looks great!.

    I like the idea of removing the USB, adding the ability to connect a battery with monitoring abilities. I would prefer the battery meter were built into the hardware or a separate module though and not reliant on a specific battery/pinout. Also, if you have sensors that are mostly asleep, you don't really need that big of a battery..

    Cant wait for the next update!

      Are you sure? yes | no

    jetpax wrote 10/12/2014 at 10:11 point
    Apart from the different radio module, how is this different from the Moteino project?

    Couldn't you use that as a base?

      Are you sure? yes | no

    Giles Burgess wrote 10/12/2014 at 11:17 point
    Yep of course. Just because there is another similar project doesn't mean that I shouldn't spend time on this one.. Doing it partly for myself to get more PCB design, first try at battery charging circuits, making a real mesh library for nRF24L01 (where currently one does not exist, which is the MAIN part of this project anyway, I just wanted to make my own dev board for it (as I can get these made for a fraction of the cost of the Moteino))

    The trouble with Moteino is that using 434/868/915MHz can be problematic, whereas 2.4GHz is license free and the chips are way cheaper than those used on Moteino. nRF has very low power down modes and is probably better suited for battery operation

      Are you sure? yes | no

    josephchrzempiec wrote 10/09/2014 at 09:43 point
    Hello i can across your youtube video page and think this would be a awesome project I'm also doing something like this my self my question is how many connections can you do with this repeater node setup? i mean how many can talk like a 1 on 1 or maybe a group of users at once?

    The project I'm trying to work on is between me and my friends and family 20 of us problem is between all of us is a 5 miles total. is there a way to hold that many people talking to each other at once without using a internet connection just using the NRF24L01 modules talking to each other say i make some kind of repeater system with extend antennas and booster pack for long rang for 2.4g wireless? my problem is how can i make that repeater along the way there are 4 locations i can put a repeater at my 3 family hour and then my place for a forth location can something like this be done?

      Are you sure? yes | no

    Giles Burgess wrote 11/07/2014 at 17:42 point
    The number should probably be 255 as that's how many IDs I plan, but there is no technical reason why not more. You will need many 'repeaters' to relay the message, a boosted nRF will do about 1Km. The problem you will find is power, as the repeaters will need to be 'always on' and with a microcontroller and a boosted version you're looking at about 50-80mA constantly. With a 1000mAh battery that is 12.5Hrs, if you wanted it to last 1 week you would need a 14,000mAh battery (this is all assuming thats a 1 cell (3.7V battery), using a regulator will reduce efficiency

    You are probably better off using a 433MHz based system, with a 'base' node at each location with a good antenna should cover that distance without needing a repeater inbetween

      Are you sure? yes | no

    Jasurbek wrote 08/25/2014 at 03:49 point
    Very nice idea, very cheap solution.
    Do you know the nRF24L01+ communication range in an indoor environment?

      Are you sure? yes | no

    Giles Burgess wrote 08/25/2014 at 09:23 point
    With the '+' version set to 250Kbps this increases range a fair bit, the biggest variables are the antennas and thickness of walls/objects. For example using the prototype boards I made first with their 'WiFi' style antennas (they are 1/2 wave dipoles) they would cover the entire (average 3 bedroom) house plus the garden, and would only drop the occasional packet, but the same at another location (2ft stone walls throughout) would make it through 2 walls but very reliable after that (majority packet loss). I have yet to do tests with the 'PCB antenna', others on the internet have quoted between 50-80m line of sight, but one of my tests when the PCBs arrive will be to get some real figures :)

    The version of PCB after the prototypes will have the nRF24L01+ integrated into the PCB (making it smaller, allowing for SMA antenna connection, not requiring the nRF as a daughter-board)

    The main point of my project is the 'mesh' aspect of it, so one of the devices can be placed in each room and act as a repeater (automatically, no special hard coding of jobs required). This should make the range issues less problematic, it will just now affect the separation distance between each node (again another test to do!)

      Are you sure? yes | no

    Similar Projects

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates