Author Topic: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?  (Read 17285 times)

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Hi all,

I've been using and exploring Moteinos using the RFM69HW modules since over a year now and while I've learned a lot about these FSK modules, there's one problem which I just can't seem to understand. When I have several nodes (or even just one) and when I upload a sketch to it and it is STILL connected to the FTDI and I'm displaying serial output on the screen, it works fine. But, when I disconnect the FTDI and just plug in a LiPo battery, it sometimes doesn't work. I have to manually hard reset by triggering the RST pin to 'jump start' the node and then it starts working and continues to works fine. Not sure if this is just my setup or I need to initialize SPI devices properly (something might be causing a bus issue), but the weird part is that it does work as intended after a hard reset. I don't want to add WDT code to check for hangups in the beginning and let it do a system reset on its own without first knowing what is causing this issue.

My node setup is as follows:

1. Moteino + RFM69HW 915MHz + Winbond SPI Flash
2. DS3234 RTC sharing SPI pins 11,12,13 with CS on pin 7, VCC on pin 3 (it has a battery backup) and SQW on pin 4.
3. The node is set to go into power-down mode.
3. The clock will generate an interrupt at a specified interval in the code to wake up the Moteino which is set to detect pin-change interrupts at pin 4.
4. After the node does its thing (sensor measurements or even just wake up and send a '1'), I put everything back to sleep, including the flash, the radio and disable the power to the RTC by setting pin 3 to LOW. I also disable ADC, TWI, WDT, BOD, SPI, etc. - basically all necessary peripherals required to maintain the lowest current draw of an ATmega328P. The same exact code on a bare chip (without the radio and flash) gives a current draw of 0.2uA during sleep. On the Moteino, it gives a current draw of around 19uA during sleep (I expected lower, but I think the LDO's previous version - the MCP1700 - gives better performance, or some timed peripherals aren't being disabled, or maybe I need to explicitly enable pullups on all GPIOs or something).

This setup works perfectly on an Arduino Pro Mini or Uno (with way higher current draw, of course). It also works well with a Moteino, but occasionally requires a hard reset in the beginning to force it to work, after which it continues to work fine. I noticed this even with the example sketches that come with the RFM69 library - as long as the FTDI is connected - all example codes work fine. But if I disconnect FTDI and power it on by plugging in a battery - it appears to boot properly, but somewhere after bootup it either gets hanged or stuck in code. Then I manually trigger the RST pin and it reboots and suddenly works as if nothing happened. Used several Moteinos - ran into this issue many times.

Also - Used Arduino IDE 1.0.6, 1.6.7 and all the others in between over the times it got updated - issue still persisted at times.

If anyone has seen this issue or knows what's going on, please do let me know.
« Last Edit: March 21, 2016, 01:07:10 PM by Felix »

TomWS

  • Hero Member
  • *****
  • Posts: 1930

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Moteinos require hard reset each time?
« Reply #2 on: March 11, 2016, 10:21:49 AM »
Welcome OSBSS.  Thank you for your for your very thorough and  thoughtful post.  The current workaround I'm using for the the issue is
1. Connect DTR to ground (as I posted in the link provided by Tom above), and
2. Connect a 1 Megaohm resistor between D12 (MISO) and Ground.  Lower values will also work, but I found that some of the lower values I tried were more likely to cripple the RFM69.  So, it's a goldilocks resistance value: low enough to make the flash memory work but high enough that RFM69 still works.  So far, on the Moteino's that I've tried it on, one megaohm seems to be "just right."

Without #2,  I couldn't wake up flash memory after putting flash memory to sleep.  If you never put flash memory to sleep (to save power while on battery), then maybe you don't need it.

As you said, the issue only manifests when running on battery and not connected to an FTDI. 

Disclaimer: these are both just band-aids arrived at experimentally, and I have no idea what the underlying cause is or why they work.  For that reason, there's no guarantee they'll work for you, or anyone else. 

It would help if you (and anyone else reading this) can post whether or not they work for you, so please do post if you try them.  That way there's more datapoints on what works and what doesn't for different Moteinos.  With enough datapoints, perhaps a more complete picture will emerge as to what might be going on fundamentally.
« Last Edit: March 11, 2016, 10:44:51 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Moteinos require hard reset each time?
« Reply #3 on: March 11, 2016, 11:52:49 AM »
By the way, something in your post reminded me of something I observed but haven't posted about, and which  is probably another clue as to what may be going on: even when the Moteino was FTDI connected, I noticed there was a frequent tendency for the Moteino to self-reboot either during or shortly after its first attempt at flash initialization.  I don't know what triggered the self-reboot, or even how it happened (BOD?  What other possibilities are there?).  It didn't always happen, but I frequently did notice it happening because I had debug code that was printing  to the serial console in an effort to solve the more serious problem (the OP of this thread).  Also, after the first reboot, it would just move ahead and not do any more reboots (similar to your experience of doing the manual reboot).  I don't recollect for sure whether or not it was also  happening while in a battery configuration with DTR grounded, but I vaguely recollect that it may have (in that configuration I was using distinctive blinking LED patterns to track progress in the code while debugging).  Anyhow, anyone wanting to get to the bottom of the problem may want to look into that.  I didn't pursue it because it's relatively benign provided it happens automatically and doesn't require user intervention.
« Last Edit: March 11, 2016, 12:08:29 PM by WhiteHare »

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos require hard reset each time?
« Reply #4 on: March 11, 2016, 06:50:14 PM »
Thanks for the replies.

I've only recently got some Moteinos with flash memories on them, but I've seen this problem on those without flash as well. Even removing all code associated with flash, the problem still occurred. I thought maybe the DS3234 is causing an issue since it's an SPI device, but even running a bare Moteino with nothing connected (except the RFM69 that is) produces this problem that somehow goes away when you ground the reset pin.

Another thing to note: I also tried powering the Moteino via a battery and connecting the FTDI without connecting the VCC so it's still giving serial output, but is powered completely by the battery and I do not notice this issue. It's when I completely disconnect the FTDI altogether is when I see this issue.

And yeah - I noticed the occasional reboot issue as well. This happens shortly after radio initialization for me and even when there's no flash on board. I'll connect an oscilloscope and see what's going on - it's possible that the radio has a large current demand on initialization and the internal resistance and inductance of the circuit pulls it way below 3.3V or just hovering around the safe voltage? I know the RFM69 has bypass caps but maybe we need more on the board itself?



WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Moteinos require hard reset each time?
« Reply #5 on: March 11, 2016, 07:31:36 PM »
Thanks for the update, as that adds a helpful new perspective.  All my moteino's have flash, so in my case maybe it was just coincidence that one type of failure just happened to occur during flash initialization.  Sounds as though perhaps it might have happened anyway without the flash.  Anyhow, I don't feel like unsoldering the flash just to find out...

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos require hard reset each time?
« Reply #6 on: March 11, 2016, 11:13:41 PM »
I did some tests with an oscilloscope. Connected a 1Ω resistor in series with power supply and captured the voltage across it to give a current consumption profile (Ohm's Law - 1Ω resistor means current will be equal to voltage). Unfortunately the oscilloscope that I have is very old and the software that comes with it is equivalent to comic sans of fonts. So I took some pics with my phone instead.

1. This is what happens when the Moteino boots up from a battery (without FTDI connected):


This is where it hangs up. Horizontal divisions in this capture is 20mV and the current reaches to about 16mA and gets stuck there permanently. So something is consuming about 16mA when it gets hanged.

2. This is when you manually trigger the reset pin and you see it boot up properly again:


This is interesting, because you can see that the ATmega328P chip consumes about 4-6mA after boot and the radio initializing consumes 16mA. Then my setup is programmed to go to sleep right after and wait for an interrupt, so you see the current consumption go down to 0 (well, almost 0, but this noisy scope probably won't know the difference between 0 and 0.019). This tells us that the radio isn't being initialized properly when first powered by the battery due to some reason. Not sure if this is because of the library or the hardware.

3. Here's when an interrupt wakes the moteino up and it transmits a packet and goes back to sleep:


The current consumption of the radio can jump up to 120mA, as we can see here, and as we already know regarding the HW radios.

4. Here are interrupts generated at 5 second intervals:


I'm curious to see what would happen if I add a decoupling cap between the power supply and the Moteino. In theory it should charge the cap first and then power on the Mote, and if the radio demands some extra current, the cap should supply it, but again, this would be better for long term use and it already performs quite well there. It's just the first boot without FTDI that's not working.

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos require hard reset each time?
« Reply #7 on: March 19, 2016, 06:06:19 AM »
I've been trying to bust my head over this and I can't for the life of me figure out why the Moteinos get stuck and require a manual hard reset, and if I'm using several of them, they sometimes require hard reset several times to force them to run together, otherwise some of them are stuck. This is so weird.

My issue also goes along with some others' that I've seen in the forum, but I noticed this issue with or without the SPI flash, so I can say it probably doesn't have much to do with the flash not being initialized on battery.

I am thinking it's either one of two issues - Arduino IDE version (the problem kept getting worse as the version number incremented - I noticed it happening rarely last year, but now I have to jump start almost every node to force them to work. It's possible that they kept updating some SPI library stuff, but I don't know how that would affect the performance of the RFM69 in anyway.

The second issue seems more likely though - I'm using a DS3234 clock to wake the Mote from power-down mode (instead of the usual low power library which relies on WDT, since I can have more control that way). The clock communicates via SPI, so it's likely that there are some bus issues. The one thing different about the way I'm using my clock as opposed to one on a typical DS3234 RTC breakout from SparkFun (https://www.sparkfun.com/products/10160) is that I unsoldered the pullup resistor on that breakout board (which was tying SQW pin to VCC, keeping the clock always powered on and thus consuming significant amount of current). Instead, I enable internal pullup on the ATmega328P on the pin that connects to SQW and make it detect pin-change interrupts just on that one. Like I mentioned before, I had no issues with this particular setup. Perhaps when the RFM69 is added to this mix, it is causing some issue? Maybe the interrupts are misbehaving somehow? Again, I've used the Moteino as a normal Arduino (ignoring the RFM69 chip and not using any of its code) and with the same clock, and that setup worked fine as well. It's just that when I try to use them both together and have the Moteino configured to have pin change interrupts is when it has these intermittent issues of requiring a jump start.

I will try this setup with another clock that runs in I2C instead and see if that changes anything.  Will also hook up a logic analyzer to see what's going on.

If anyone ever figures out what's going on or has any updates regarding this, please do let me know.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteinos require hard reset each time?
« Reply #8 on: March 19, 2016, 08:13:59 AM »
When I saw your original post, it was my understanding that your problem was that your Moteinos did not reset when you first applied power, or, as has also happened to me, they were AC powered and would not alway restart after a power outage.

This latest post tells me that I totally misunderstood your other post and that your problem is really the Moteinos appear to stop working after a period of time.  Is this correct?

Tom

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Moteinos require hard reset each time?
« Reply #9 on: March 19, 2016, 12:23:27 PM »
I will try this setup with another clock that runs in I2C instead and see if that changes anything. 

Good idea.

I presume that if you have no flash and no RTC connected at all, and you run one of the generic LPL example sketches, then the problem (the need to manually reboot once after first powerup) does not manifest?  I presume that, because otherwise we probably all would be having the same issue.  Still, it might still be worth confirming that.  As a troubleshooting strategy, I find that it's helpful to strip everything down to a defined baseline where everything is known to work the way it's supposed to, and then very slowly add back until the problem first starts to manifest.  Most of the time that tends to localize the source of the problem, or at least a trigger you can follow that will lead you to the source of the problem.

The other approach I would take is to try to find just exactly where in the code (either your code or the library code) that it's hanging before you initiate the reboot.  There are a number of busy-wait whlie-loops in the library code where things can hang.  Knowing exactly where the failure occurs can also help pinpoint the source of the problem, or at least the trigger.

You may also want to see whether the problem happens after you compile using Arduino IDE 1.0.6 (see https://lowpowerlab.com/forum/index.php/topic,1714.msg12436.html#msg12436).  It may be a long-shot, but at least it's quick and easy to check.  Arriving at that discovery using the usual troubleshooting techniques probably would have taken a very long time.

Please do keep us posted as to what you find out.  As I said in an earlier post, the best way to leverage our individual work is to pool our datapoints, and from that a recognizable pattern may emerge (classic forest vs.the trees).
« Last Edit: March 19, 2016, 12:34:48 PM by WhiteHare »

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos require hard reset each time?
« Reply #10 on: March 19, 2016, 07:59:37 PM »
@Tom: There are two different errors here. The first is they sometimes don't reset on first boot and just stuck in code (but on DC power, not AC). I did some testing - I think I know what's causing this and I'll post below on the what I found. The second one is that they appear to get stuck at random times in the same exact manner when there are several nodes in the network. This may have more to do with proper implementation of the RFM69 library. Felix has many nodes and one gateway and all of them work without fail or getting stuck, so there's clearly something on my end. The only difference is, my application is for long-term datalogging, so I want it to wake at set intervals from external source and sleep with low power, while his is more of home automation, so he uses watchdog timer instead. I think that is the root cause of the problem

@WhiteHare: Yes. You're correct. I did some tests and the problem doesn't occur when there's no RTC connected. I did strip down to everything, I'll post it below. I didn't test 1.0.6, but I do remember seeing the problem, although it was extremely rare, happened once a month maybe.

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos require hard reset each time?
« Reply #11 on: March 19, 2016, 09:10:51 PM »
So I did some basic tests:

1. Moteino (with radio, and flash) running a baseline code that blinks LED every second:

Code: [Select]
void setup()
{
  pinMode(9, OUTPUT);
}

void loop()
{
  digitalWrite(9, HIGH);
  delay(1000);
  digitalWrite(9, LOW);
  delay(1000);
}

Result: No problem on FTDI or battery power - works fine.

2. Moteino waking up every second using watchdog timer interrupts and blinking LED and then going into power-down mode between each blink. I didn't use any library, but used bare AVR commands and bit manipulation instead, to avoid potential errors in any library.

Code: [Select]
ISR(WDT_vect)  // Interrupt service routine for WatchDog Timer
{
  asm("nop"); // do nothing
}

void setup()
{
  pinMode(9, OUTPUT);
 
  cli();  // disable global interrupts
  MCUSR &= ~(1<<WDRF);  // Clear WDRF in MCUSR
  WDTCSR |= (1<<WDCE) | (1<<WDE);    // Write logical one to WDCE and WDE
  WDTCSR = (1<<WDIE) | (1<<WDP2) | (1<<WDP1);  // Turn on WDT interrupt and set prescale at 1.0s
  sei();  // enable global interrupts
 
  SMCR = (1<<SE) | (1<<SM1);  // enable power-down mode

  asm("wdr");    // Reset Watchdog Timer
}

void loop()
{
  asm("sleep"); // put processor in sleep mode
 
  digitalWrite(9, HIGH);
  delay(1000);
  digitalWrite(9, LOW);
  delay(1000);
}

Result: No problem on FTDI or battery power - works fine.

3. Moteino going into power-down mode, configured to wake up on external interrupt generated by the DS3234 clock every 5 seconds and then blink the LED for a sec. I used my own library to interface with the clock and set interrupts. Library available here: https://github.com/OSBSS/DS3234lib3 (only difference is that I changed the CS pin of the clock to pin 7 on the Moteino)

Code: [Select]
#include <DS3234lib3.h> 

DS3234 RTC; // declare object for DS3234 class

long interval = 5; // set interval in seconds. Example: 300 seconds = 5 min logging interval
//int dayStart = 25, hourStart = 22, minStart = 51; // set start date/time

ISR(PCINT2_vect) // Interrupt service routine for PCINT2
{
  asm("nop"); // do nothing
}

void setup()
{
  pinMode(9, OUTPUT);
  pinMode(3, OUTPUT);  // DS3234 is pin powered
  digitalWrite(3, HIGH);  // enable the RTC

  cli();  // disable global interrupts
  PORTD |= (1<<PORTD4); //Activate pullup on pin 4
  PCICR |= (1<<PCIE2);  // enable pin change interrupts
  PCMSK2 |= (1<<PCINT20); // set pin change interrupt mask on pin 4
  sei();  // enable global interrupts

  SMCR = (1<<SE) | (1<<SM1);  // enable power-down mode

  RTC.setNewAlarm(interval);  // set next alarm after specified interval (in seconds)
}


void loop()
{
  asm("sleep"); // go to sleep. code pauses here

  // code resumes from here after clock generates interrupt on pin 4
  RTC.alarmFlagClear();    // clear alarm flag

  digitalWrite(9, HIGH);
  delay(1000);
  digitalWrite(9, LOW);
  delay(1000);
 
  RTC.setNextAlarm();  // set next alarm
}


Result: THIS is where the code fails to run after the first boot on battery. When I manually reset it, it runs fine after that, generating interrupts as programmed. The first boot on battery makes it stuck somewhere where it's not entirely in sleep mode or fully awake either. Running the exact same code on Arduino Pro Mini or even bare ATmega328P works fine without problems. Oh, and also, on FTDI it runs fine, since the DTR pin is pulled low and opening serial monitor resets the Mote anyway. Same thing even if I don't open Serial monitor, but have the FTDI plugged in either powering the device via USB or a battery and connecting the remaning 5 pins of FTDI - still works as long as FTDI is connected.

Note that all three code samples above do not use any code related to the radio or the flash. We're talking pure Moteino here. I'm curious to see if this happens on a Moteino without the flash or radio soldered on (but I don't want to desolder one of my Motes to try that out). Oh and another thing - I do have Moteino cores defined in the hardware folder. I see the same issue even if I upload the code as Arduino Uno instead. Using Arduino IDE 1.6.8.

Looks like pin-change interrupts aren't handled that well when the RFM69 is included in the circuit? No idea why, since the exact same code works on another arduino without the radio.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Moteinos require hard reset each time?
« Reply #12 on: March 19, 2016, 11:43:13 PM »
3. Moteino going into power-down mode, configured to wake up on external interrupt generated by the DS3234 clock every 5 seconds and then blink the LED for a sec. I used my own library to interface with the clock and set interrupts. Library available here: https://github.com/OSBSS/DS3234lib3 (only difference is that I changed the CS pin of the clock to pin 7 on the Moteino)

Code: [Select]
#include <DS3234lib3.h> 

DS3234 RTC; // declare object for DS3234 class

long interval = 5; // set interval in seconds. Example: 300 seconds = 5 min logging interval
//int dayStart = 25, hourStart = 22, minStart = 51; // set start date/time

ISR(PCINT2_vect) // Interrupt service routine for PCINT2
{
  asm("nop"); // do nothing
}

void setup()
{
  pinMode(9, OUTPUT);
  pinMode(3, OUTPUT);  // DS3234 is pin powered
  digitalWrite(3, HIGH);  // enable the RTC

  cli();  // disable global interrupts
  PORTD |= (1<<PORTD4); //Activate pullup on pin 4
  PCICR |= (1<<PCIE2);  // enable pin change interrupts
  PCMSK2 |= (1<<PCINT20); // set pin change interrupt mask on pin 4
  sei();  // enable global interrupts

  SMCR = (1<<SE) | (1<<SM1);  // enable power-down mode

  RTC.setNewAlarm(interval);  // set next alarm after specified interval (in seconds)
}


void loop()
{
  asm("sleep"); // go to sleep. code pauses here

  // code resumes from here after clock generates interrupt on pin 4
  RTC.alarmFlagClear();    // clear alarm flag

  digitalWrite(9, HIGH);
  delay(1000);
  digitalWrite(9, LOW);
  delay(1000);
 
  RTC.setNextAlarm();  // set next alarm
}


Result: THIS is where the code fails to run after the first boot on battery. When I manually reset it, it runs fine after that, generating interrupts as programmed. The first boot on battery makes it stuck somewhere where it's not entirely in sleep mode or fully awake either. Running the exact same code on Arduino Pro Mini or even bare ATmega328P works fine without problems. Oh, and also, on FTDI it runs fine, since the DTR pin is pulled low and opening serial monitor resets the Mote anyway. Same thing even if I don't open Serial monitor, but have the FTDI plugged in either powering the device via USB or a battery and connecting the remaning 5 pins of FTDI - still works as long as FTDI is connected.

@OSBSS:  This may or may not be your issue--and apologies if you already know this--but in reference to your #3 code above, a conservative approach would be to  put
Code: [Select]
pinMode(10,OUTPUT);
as the first line in your setup().  That's because on the atmega328p, pin 10 is the default slave select for the Moteino itself (https://www.arduino.cc/en/Reference/SPI).  If pin 10 is set as OUTPUT, then it prevents the Moteino from becoming an SPI slave.  If SPI is active and pin 10 isn't set to OUTPUT, then if pin 10 were to go high for any reason, it would make the Moteino into an SPI slave, and since there would be no master, it would/might effectively hang your moteino if it were to stay high.  If you read the entire link that I posted earlier in reply #9 above, you will see where it turned out that was actually happening to me and it was hanging my system (thanks again to Tom for pointing it out).
« Last Edit: March 20, 2016, 12:03:30 AM by WhiteHare »

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
« Reply #13 on: March 23, 2016, 10:32:03 PM »
I just got around checking your reply. Doh! That was such an obvious thing that I overlooked. No apologies necessary - that was a really good catch by you and Tom. I went back and read the entire link that you posted earlier and when I tested it, it was indeed causing the mote to become an SPI slave. I actually did have it as an output in my earlier codes from a year ago and that's when it was working, but somehow totally skipped that one line in this code. Thanks for your patience. Interesting to see what happens when it is in slave mode - it just hangs up and sips battery at 16mA until the end of time (or battery).

Not sure if that also explains why it used to hang up randomly if the gateway node isn't active or if the network is busy with several nodes sending data all at approximately the same time, but if it's waiting for an ACK and doesn't receive one in the given time, it should have nothing to do with the SPI bus hanging up. Often I found that if you can afford to add a millisecond of delay here and there after some operations, it kind of helps to make the code more stable. I'll test this out for a few days and follow up if I find some issue.

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
« Reply #14 on: April 08, 2016, 02:24:33 AM »
Following up on this:

I've been working with several Moteino nodes that rely on the DS3234 RTC to wake them up from sleep mode and I chose this over the WatchDog Timer because my application requires precise time-keeping over a long period of time. I realize that WDT method can be scalable to a reasonably large number of nodes in the same network, since they don't necessarily send data all at the same time (i.e., depends on when they were powered on and when the timer was initiated). However, in my network, since all the clocks are maintaining relatively accurate time, I expect all of them to transmit data at around the same time (+/- 0.5 seconds or so).

This starts becoming an issue when I have more than 5 or 6 nodes in the network, as it appears that the network may get busy and I start to lose some data packets from a few nodes that were further away from the gateway. While I do use sendWithRetry(), specify a wait time of 40ms (even tried with 100ms) and 5 retries, I still end up with one or two nodes dropping some packets occasionally. Is there a specific way to ensure a more robust data transfer or perhaps a retry method so this doesn't happen when I have to add more Moteinos in my network? I do realize that while the node ID can theoretically go up to 255, it doesn't mean that I expect it to work with over 200 nodes with my current setup, but I expected at least 20-30 nodes to be able to work reliably with one gateway.

The other problem I observe with my setup, which can also be a side-effect of using a precise clock to maintain time on all nodes, is the method of uploading data through my gateway. I have two approaches:

1. Wait till the gateway receives data from all nodes, and then upload all the data online at the same time. The obvious problem with this is if data packets from one of the nodes fails to transmit due to network congestion (or whatever the issue is, I'm assuming it's a congested network), the gateway is now stuck waiting for that node and no data is uploaded online till the packet actually goes through from that one node.

2. Upload as soon as the gateway receives data from ANY node. This is fine, but again, due to the precise time-keeping, all data is expected to be received at about the same time. If the gateway is busy uploading instead of listening for data from the next node, then a few packets tend to get lost yet again.

While switching to WDT may solve some of these issues by letting the nodes send the data at different times, I would prefer to maintain accurate timing with my setup.

Any ideas, comments, criticisms or suggestions regarding this setup are appreciated.