LowPowerLab Forum

Hardware support => Moteino => Topic started by: OSBSS on March 11, 2016, 01:16:12 AM

Title: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on March 11, 2016, 01:16:12 AM
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.
Title: Re: Moteinos require hard reset each time?
Post by: TomWS on March 11, 2016, 07:32:43 AM
Yes: https://lowpowerlab.com/forum/index.php/topic,1349.msg11229.html#msg11229
Title: Re: Moteinos require hard reset each time?
Post by: WhiteHare 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.
Title: Re: Moteinos require hard reset each time?
Post by: WhiteHare 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.
Title: Re: Moteinos require hard reset each time?
Post by: OSBSS 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?


Title: Re: Moteinos require hard reset each time?
Post by: WhiteHare 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...
Title: Re: Moteinos require hard reset each time?
Post by: OSBSS 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):
(http://i.imgur.com/eHeNJHf.jpg)

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:
(http://i.imgur.com/lXbSMkg.jpg)

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:
(http://i.imgur.com/VhlgAf4.jpg)

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:
(http://i.imgur.com/UgUTJM7.jpg)

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.
Title: Re: Moteinos require hard reset each time?
Post by: OSBSS 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.
Title: Re: Moteinos require hard reset each time?
Post by: TomWS 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
Title: Re: Moteinos require hard reset each time?
Post by: WhiteHare 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).
Title: Re: Moteinos require hard reset each time?
Post by: OSBSS 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.
Title: Re: Moteinos require hard reset each time?
Post by: OSBSS 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.
Title: Re: Moteinos require hard reset each time?
Post by: WhiteHare 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).
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS 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.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS 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.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 08, 2016, 02:32:19 AM
Also, a follow up on previous hanging up issue on SPI:

Ensuring the Moteino doesn't go into slave mode doesn't always work with Arduino IDE 1.6.7 apparently. I realized that even after adding that extra line of code in the beginning, one of the nodes still got hanged and was consuming 16mA continuously for a week till the battery died and only realized it later when the gateway wasn't receiving any data from it. When I switched back to IDE v1.0.5 and re-uploaded the code, it appears to works fine, going into sleep mode without any issue. Not sure why or what the new IDE does or if that's an issue at all, but just thought I'd add it here.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: Felix on April 08, 2016, 07:53:06 AM
Yup we are getting repeated reports of 1.6.x not performing.
I am still on IDE 1.0.6 which works great for everything.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 08, 2016, 08:22:25 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.
I use the node ID to shift a node's transmit time by a small amount based on its node id multiplied by (how long a transmission takes and how much variability there is in the timing - ie, some RTC's can only be set to within 1 second which gives you 2 second variability).

Quote
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.
A third approach is a hybrid of the first two.  The gateway knows when all the reports are to come in.  It provides a window large enough for all the reports, accumulating the data that does come in, and then sends the bulk.  Anything that comes in after this, but before the next window, is going to need some time correction anyway.
Quote
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.
The WDT is horribly inaccurate and shouldn't be used for tight timing applications.

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 13, 2016, 06:25:42 AM
@Tom - thanks for the tip. I implemented a similar approach, and it works well, as long as correct time is maintained. Working on syncing time on each node with server time (dwelling into wireless programming - keep getting impressed by Felix's work)

I'm wondering though, like you said, the minimum variability in timing with the RTC I use is 1 second. This method works well for 5-7 nodes, but my logging interval can be as small as 10 seconds, depending on the application (some are used in research - decay of gases, quick environmental changes in a controlled chamber, some are used around an academic building to monitor building activity, etc.) I can see this method to be a problem in scalability when I add more nodes in the network, and if number of nodes exceeds 10, then the setup reaches its limit. If I increase the logging interval to 30 or 60 seconds, I am able to add more nodes, but anything beyond that, I would be compromising on the quality of data collected. I currently have 8 nodes, so the method works fine for now, but will be increasing the number soon, so just thinking ahead.

Another approach would be to use more than one gateway and allocate a different network ID to it and the few nodes it serves. I haven't tried this yet as most of my nodes are currently in use, but since they would be operating in the same frequency but just have a different network ID, I'm wondering how that would affect congestion and data loss. If I have 30 nodes and 3 gateways inside a building (10 nodes per gateway) for example, how would they behave when working in tandem? I would assume there would be some type of interaction by a node to all three gateways till it figures out which one has the correct network ID, and during this interaction, other nodes that are supposed to be sending data to their gateways might not be able to do so.

Is this a proper way to look at it? Maybe I'm confusing the principles on how the modules work.

Edit: Just reading up on network IDs and hardware filtering. Nevermind that.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: joelucid on April 13, 2016, 06:50:59 AM
If you measure the offset of your rtc against the correct second using the moteino's resonator, calibrate the wdt by measuring it against the rtc and then sleep when the rtc wakes you using the calibrated wdt to pass the time until the real second hits you should be able to get down to around 15ms resolution.

Some Rtcs also can be restarted so that they start their second counter when you tell them to. That would make it even easier.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 13, 2016, 09:36:39 AM
I concur with Joe on this one, especially since your RTC is accurate.  Use it to determine to calibrate both millis() and WDT loops it takes between 1.000 second interrupts (do the measurements at two different times so millis() isn't affected by WDT) and then use that as a scale factor for LowPower Sleep timings and finish up using millis() to zero in on the correct post time.

I use the AB18X5 RTC, which has resolution to 10 milliseconds (including its alarm) function, but the crystal needs to be calibrated (ie, each board using it) and that can be a PITA if you don't have the equipment.

Tom
EDIT: You'll have to do calibration cycles periodically as temperature alone will cause the WDT and probably processor clock to drift.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 13, 2016, 11:45:26 PM
Joe and Tom - that's an interesting idea. Yeah, my first thought was that wide swings in temperature would create more drifts.

Just to clarify: currently the RTC is programmed to generate interrupts exactly when its time reaches 00 seconds for example, so I offset this by node ID like you suggested, and it will wake each node at 01 second, 02, 03, etc respectively. So if my logging interval is 30 seconds, it will automatically wake up at 31, 32, 33rd second of the minute (RTC's time) every time. So instead of this, do I wake all nodes at exactly 00, but offset that by immediately going to sleep and then relying on WDT to wake up after a very short duration which varies based on node ID?

Or should I actually measure the difference in the actual "second" measured by RTC (interrupt every second) and what WDT or millis() report as their value at that instant? I recall doing a simple test with millis() couple of years ago and found it to drift significantly - by a minute or two over the course of a day (granted it was the internal oscillator, but even Uno doesn't fair too well). Never really measured the amount, as it always varied. Still not sure how using this difference as a scale factor in the sleep timings helps. Perhaps I didn't fully understand the implementation.

Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: joelucid on April 14, 2016, 12:46:59 AM
I just looked at the data sheet in the rtc does have a way to synchronize the time:

Quote
The countdown chain is reset whenever the seconds register is written.

So what you do is periodically your node sends a ping to the server and the server responds with the exact time in ms. It can do that since it can record how many millis() have passed since the last second increment from the RTC occurred. Then the client knows how long to wait until the next second increment happens. Wait and then set the seconds at the RTC which causes the counter chain to restart that instance.

The RTC also supports square wave output. So if you then want to report a measurement at 1:30:44:50 you let the RTC wake you at 1:30:44 and then count 50 * 1000 / 1024 interrupts from the square wave output. You can powerDown between the interrupts. You could also use this sleep method when you wait for the next second increment during synchronization.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 14, 2016, 03:24:58 PM
You can do better than that using the Time-sync Protocol for Sensor Networks (TPSN). The trick involves the node sending a timestamp (copy of it's counter) to the server, and the server sending back its timestamp (a copy of it's counter). By making an assumption that the propagation delays in both directions are equal you can get a more accurate synchronzation.
Mark.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: WhiteHare on April 14, 2016, 05:04:32 PM
You can do better than that using the Time-sync Protocol for Sensor Networks (TPSN). The trick involves the node sending a timestamp (copy of it's counter) to the server, and the server sending back its timestamp (a copy of it's counter). By making an assumption that the propagation delays in both directions are equal you can get a more accurate synchronzation.
Mark.

Is the idea of having the node send its counter to the server just to have the same size packet as the one it's receiving?  i.e. Could the node just as easily fill the packet with a payload of the same length with but with other data  (such as data it might have been sending anyway) and/or padding?  Provided the node records its counter in the same way it would have anyway, then (if I get the gist of the idea), all it has to do is wait for the server's return packet, note the time of it's arrival, cut the roundtrip time in half to calculate what its counter should have read at the time the server received its packet, and then change its counter with a correction offset so that they would have been the same?  Sounds promising.  Alternatively, I suppose it could do much the same thing just by receiving two time-stamped packets in a row from the server.

Cool.  That sounds simple enough that I think I'll actually try it!  I never did like the idea of just "spraying and praying" packets for lengthy periods just to have a chance that one of them might hit the Listen window.  Having the server send a relatively few synchronized packets would be far more preferable, even if the tradeoff requires a bit of extra work by the node.  If one can accept the RFM69's counter in place of an RTC, then it would be great if one could maybe (?) even do it using non-modified Moteino's that lack an RTC....  Offhand I don't recall whether the RFM69's counter can be directly changed to a particular value for an instantaneous time correction like perhaps an RTC could be, but  I do remember  JoeLucid has demonstrated on another thread that it can be gradually modified using recalibration to satisfy a similar objective.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 15, 2016, 09:03:22 AM
I looked at this some time ago for my project, it was OTT for what I needed but I wanted to understand the principle. I was wrong in the above post about the node having to send its counter value, it just needs to sample it.

Reference the attached diagram. The top horizontal line represents the server's RTC counter (maybe a 16 bit 32.768kHz timer counter). The bottom horizontal line is the node's counter. The goal is to adjust the node's counter at time T5 to be exactly the same as the server's counter at time T6. I've seen this diagram and the final equations stated several times in documents, but no real explanation of how the equations were derived, so here it is:

The node samples it's counter at T1 and saves it. It then sends a packet to the server. The server samples it's counter immediately it receives the packet at T2 and saves it. When it is able to send a reply, the server samples it's counter at T3, and sends its T3 and previously stored T2 values back to the node. The node samples its counter at T4. The node now has 4 counter values, it's own counts of T1 and T4, and the server's counts T2 and T3.

A few assumptions:
1) Transfers to/from the radio are done with SPI in the MHz frequency range, so can be ignored for time.
2) The time for the node to sample its counter at time T1, send the packet, and the server to sample its counter at time T2 is d.
3) The time for the server to sample its counter at time T3, send the packet and the receiver to sample its counter at T4 is also d.
4) The packet sizes sent by the node and by the server are the same size.

Now the logic. Let's assume the node's counter is behind the server's counter by a value Tdelta (in counter units). We need to calculate that and add it to the node's counter so that the node's counter at time T5 is the same as the server's counter at time T6.

We can write some equations.
A:  T2 = T1 + Tdelta + d
B:  T4 = T3 + Tdelta + d
C:  T4 - T1 = T3 - T2 + 2d

We can now find out what Tdelta is in terms of the other known values.

Re-arrange C:
D:  d = (T4 - T1 - T3 + T2)/2

Re-arrange A:
E:  Tdelta = T2 - T1 - d

Substitute D:
Tdelta = T2 - T1 - (T4 - T1 - T3 + T2)/2

Therefore:
F: Tdelta = ( T2 - T1 -T4 + T3)/2

Re-writing these we get:

d = ((T2 - T1) + (T4 - T3))/2, and

Tdelta = ((T2 - T1) - (T4 -T3))/2.

All the node needs to do is add Tdelta to it's current counter value to be in sync with the server. The beauty of this is it is independent of how long it takes the server to get round to sending the reply packet, it may for example be using listen before talk. Also the calculations are independent of bit rate, as long as the packet is the same size.

Mark.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: SadE54 on April 15, 2016, 09:20:01 AM
Also , Time flooding syncronization protocol (TFSP)could be used :
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/ftsp-sensys04.pdf

The timestamp on the first payload byte from the gateway is regularly broadcasted and the frame is timestamped too on the node at the reception.
You can compare the 2 because at the reception of the propagation time , all other timing can be determined.
A linear regression on several couple of timestamps is then used to set the node clock.
It seems it could be very precise (1us)

I would implement that someday , but some specs seem blur to me :-/ concerning the computation of some times
And I guess a 32 bit timer could be welcome  ::)


Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: snorp on April 27, 2016, 01:02:56 PM
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.

It seems to me that you really don't want the nodes themselves deciding when to send data. Instead, you should poll each one of them from the gateway. That way you can fully orchestrate the collection of data and ensure that you don't have collisions. If the timing of the collection on each node is critical, you can still use your RTC on the nodes to determine when to do that -- just don't send it until you are asked by the gateway.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 27, 2016, 02:51:43 PM
I've been experimenting with various setups as mentioned here by others (thanks a lot for the feedback guys)

I agree with you snorp. Been reading up on listen mode on the radio and trying to understand how it works. I'm not overly concerned about the node gaining a few uAs in sleep mode, so it seems like this approach would work well. I think WhiteHare's suggestion of using a GPS module to maintain exact time on the gateway is ideal for maintaining exact time. If not, I can use my RTC and just sync it to server time either on every upload or at the end of the day, so it always stays accurate. This way I can also eliminate the RTC on the nodes, save a few bucks, and avoid all these SPI issues.

I'm still not entirely familiar with listen mode though and wondering about time delays. For my application, if I have a logging interval of, say 5 mins, the node remains in listen mode indefinitely until the clock on the gateway strikes the exact 00 second of the interval, or whatever the interval is, and sends a "wake" command. The node can then wake up, take whatever measurements, send it, wait for ACK. Then the gateway receives data, sends the ACK, and the node goes back to sleep in listen mode. What would the duration of this entire cycle be? If it's short enough, there's a good chance I can place over 20-30 nodes and still get data on exact time intervals from each one. And since the gateway is only requesting from one node at a time, congestion and collisions are less of an issue. If I'm mistaken on the basics of listen mode, do let me know. I've occasionally seen nodes to have some timeout issues where it gets stuck in RX mode indefinitely on basic setup - still unsure what causes this, probably SPI issues with the clock. Will debug more if it happens in listen mode as well.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 05:44:56 AM
Depending on bit rate and packet length I'm sure you can get something like 20ms total for the request packet and the ACK back. There's a bit of uncertainty at the beginning, so maybe allow 10ms or so for that.

I can see a system that uses 32.768kHz 10ppm watch crystals on both the gateway and the node. The gateway would transmit request packets regularly with an incrementing node address in one of the fields. The node would initally listen for a packet, when it get's one it then knows from the address field where in the sequence it is, and then go to sleep so that it wakes up when the gateway sends the request packet that is addressed specifically to that node. It'll then go back to sleep and wait for it's next 'time slot'. If we say 32 nodes, with 5 mins between uploads, the gateway would be transmitting a request packet once every 9.4 seconds. The 32.768kHz crystal would drive the timer/counter of the micro and permanently run even when asleep (for about 1uA current), so it can be used to generate a wakeup interrupt. The drift difference would be in total 20ppm over 5 mins (about 6ms) , that would set the initial uncertainty window size, but you'd want a node to re-calculate it's next slot if a packet isn't received when it expected one so the uncertainty window can grow until after n packets are lost it tries to re-aquire lock again (which is a battery-thirsty operation, you'll want to do that rarely).

You could get more adventurous with this and use a pseudo-random sequence for the time slots, that would allow multiple systems to co-exist in the same rf neighbourhood.
Mark.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: WhiteHare on April 28, 2016, 09:40:08 AM
Excerpted directly from the RFM69 library:
Code: [Select]
    virtual bool sendWithRetry(uint8_t toAddress, const void* buffer, uint8_t bufferSize, uint8_t retries=2, uint8_t retryWaitTime=40); // 40ms roundtrip req for 61byte packets
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 28, 2016, 03:57:31 PM
@WhiteHare thanks, looks good enough actually.
@perky I have a similar setup when I first created this post.. since I'm using an accurate clock anyway (~2ppm), it should work fine. But now I'm questioning the need of putting a crystal on the node at all. If the idea is to check where in the sequence a node is and go to sleep till its time slot, then it becomes dependent on the accuracy of the crystal on the node itself. Then you end up adding extra logic to account for drift or constantly adjust the time. Instead, might as well just put all nodes permanently in listen mode and wait till the gateway sends a wake packet to each node individually. Not sure yet how the nodes react to "sniffing" for packets and find one that's meant for them, but will see.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 28, 2016, 04:06:19 PM
Just thought I'd share my current setup:

I made two shields for each node: An RTC shield (with a DS3234 clock) and a sensor shield that measures temp, RH, light intensity and can attach a thermistor probe for measuring air stream temps in an HVAC duct or surface temps or wherever needed. Here are the individual shields:

(http://i.imgur.com/15ckI7Z.jpg)

And here's one node:

(http://i.imgur.com/OHs0ivI.jpg)

I have two gateways, but I'll just share the one with WiFi:

(http://i.imgur.com/trIG0S2.jpg)

(http://i.imgur.com/Pg0exNx.jpg)

Not the best, but all these were initial prototypes that I assembled a couple of months back. The gateway I use now has an RTC, uses Ethernet as opposed to shitty WiFi and I'm experimenting with listen mode on each node. I would be able to save $10 on each node if I can get rid of that clock and just leave it on the gateway instead.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 04:23:57 PM
Nice kit! Do you fit the the battery on the RTC? I guess there's not much need with a LiPo.

Actually there's a fundamental misunderstanding of listen mode I think. You can't just send a packet to wake it up, listen mode is basically a sleep mode with an internal timer that wakes it up periodically, so it's a question of whether you use the radio's internal timer, or the MCU or RTC as the timer. I think you'd get better accuracy with the MCU than the radio, and potentially even better with an external RTC with temperature compensated oscillator on board.
Mark.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 28, 2016, 04:42:11 PM
@perky - Thanks! Yeah, the LiPo was supposed to be the main power source. I was using CR1225 coin cells for time-keeping only, since I didn't want the clocks to die because of any error in code that would make the node stay on till I realized they're all dead. But these are early prototypes and I am constantly upgrading the design and components each time I learn something new.

Ah - that was what I was looking for. I am not really well-versed on the listen mode yet. I think that makes sense - so the radio is made to periodically "pulse" in RX mode for a very short duration and sleeping in between. Then when it actually receives anything, it wakes the MCU up with an interrupt. Am I saying that correctly? If that's the case, then how would you make the radio rely on an external oscillator rather than its internal timer? Sounds like that setup won't work even with my temp. compensated oscillator as the timing precision can only go down to 1 second. It does have 32 kHz SQW output as well though, so might be able to use that.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 05:21:28 PM
Unfortunately whenever the radio is in receive mode it consumes 16mA, so yes - the radio in listen mode periodically wakes up, if it get a packet within a timeout priod will receive it and interrupt the MCU with a payloadready interrupt otherwise it goes back to sleep until the next wakeup time. That in turn wakes up the MCU which can then read the received packet out of the radio via SPI. With the MCU as the timer it gets a wakeup interrupt from it's on-board, constantly running, timer and wakes up the radio by putting it into RX mode via the SPI interface. An external RTC has 2 options, generate an interrupt at a known time (better for power as the MCU can be put into deep sleep mode), or generate a clock out. If you want resolution you'll either need to find a RTC with the ability to program an interrupt time to that resolution, or use its square wave output and drive your MCU's internal timer clock from that. The RTC's oscillator could be much more accurate than a crystal on the MCU.

Mark.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 05:29:29 PM
Actually there's a fundamental misunderstanding of listen mode I think. You can't just send a packet to wake it up, listen mode is basically a sleep mode with an internal timer that wakes it up periodically, so it's a question of whether you use the radio's internal timer, or the MCU or RTC as the timer. I think you'd get better accuracy with the MCU than the radio, and potentially even better with an external RTC with temperature compensated oscillator on board.
Mark.
Actually, you can send a packet and wake up a listen mode node IFF the packet arrives when the listen mode cycle is in RX Mode, not Idle mode.  That is why Joe's ListenMode code sends a burst of packets that it slightly longer than the full listen mode cycle (IDLE+RX times).

You can use it as a low power timer, but you can also use it for wake on demand.

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 05:36:33 PM
@OSBSS, I'll echo perky's comment.  Very nice job!  Good work!

I do have one question, I didn't realize that you were using SD card along with the DS3234, Radio, and display(?) all on the same SPI link.  I have had problems using SD card with other SPI devices, where I had an open SD file that contained a log and I'd alternate between device and SD card access.  I haven't had a problem sharing when the IO operation was 'atomic', ie, open the file, write, close it  and then use SPI on a different device.  Have you had any issues?  What SD library are you using?

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 05:46:07 PM
Quote
Actually, you can send a packet and wake up a listen mode node IFF the packet arrives when the listen mode cycle is in RX Mode, not Idle mode.  That is why Joe's ListenMode code sends a burst of packets that it slightly longer than the full listen mode cycle (IDLE+RX times)

Not sure that works well for longer cycle times. If it's 5 mins per cycle, do you transmit constantly for the full 5 minutes?

Just had a thought, in theory you could use listen mode as a wakeup timer by programming the RSSI threshold register to 0xFF. the MCU would wake up (on noise), send a packet, and it's ACK it gets back could contain the next timeslot time for that node. The gateway would be in receive mode constantly during that initial phase, then go into receive on just the timeslots if power was an issue. Is that how it works?
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: OSBSS on April 28, 2016, 05:59:30 PM
@Tom thanks!

Yes, all of them share the same SPI bus. I'm using SdFat by William Greiman: https://github.com/greiman/SdFat (https://github.com/greiman/SdFat). I've noticed SPI issues with the latest version of the library along with latest IDE. I'm using a late 2014 commit of the library, which for all intents and purposes isn't recommended by Greiman himself, but it works for my setup. It's not necessary, but if you add external 10K pullups to the data lines, you can force the SD card into sleep mode between communications. I get time from the DS3234 while the file is open on the SD card, so I don't see why it wouldn't work.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 06:05:34 PM
Quote
Actually, you can send a packet and wake up a listen mode node IFF the packet arrives when the listen mode cycle is in RX Mode, not Idle mode.  That is why Joe's ListenMode code sends a burst of packets that it slightly longer than the full listen mode cycle (IDLE+RX times)

Not sure that works well for longer cycle times. If it's 5 mins per cycle, do you transmit constantly for the full 5 minutes?
The implementation included in the ATC library is 2.882 seconds total time with a sendBurst method that sends packets for 3 seconds.  The RX window is very narrow (256uS) giving a duty cycle of around 0.089%.  The RX power is not terribly burdensome in this case  ;)

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 06:10:25 PM
That is short! I wasn't expecting such a short RX time. OK, maybe it's usable then ;-)
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 06:15:11 PM
Yes, all of them share the same SPI bus. I'm using SdFat by William Greiman: https://github.com/greiman/SdFat (https://github.com/greiman/SdFat). I've noticed SPI issues with the latest version of the library along with latest IDE. I'm using a late 2014 commit of the library, which for all intents and purposes isn't recommended by Greiman himself, but it works for my setup. It's not necessary, but if you add external 10K pullups to the data lines, you can force the SD card into sleep mode between communications. I get time from the DS3234 while the file is open on the SD card, so I don't see why it wouldn't work.
The SD card breakout board I'm using does have 10K pullups.  I haven't mounted my own socket yet (although I need to for the project I'm working on).  This was one of the reasons I'm thinking about the 328PB with its two SPI channels so I can totally isolate the SD card, but I'm not sure I want to enter the quicksand of trying to build 328PB support for the IDE and port the libraries I need.  I just might switch over to ARM for this project...  OTOH, the SD Fat library I'm using is the Feb 2016 version so maybe I should try to go back to an older one...

Thanks for the info.

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 06:18:59 PM
That is short! I wasn't expecting such a short RX time. OK, maybe it's usable then ;-)
We can move this to another thread if you want to continue this, but the short answer is that the data rate is stepped up to 200Kb with the original thought being there didn't need to be 'useful' content.  As it turned out the content is pretty reliable and I use it for signalling the purpose of the wake up burst.

Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 06:20:32 PM
I was just curious, OT for this thread as you say.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 28, 2016, 06:25:24 PM
I'll mention it again, but I had trouble getting SD cards to release the MISO line when de-selected on a previous project. The 'scope showed a clear over-driving waveform even though the SD card was de-selected. Solution was a 470R resistor on the MISO output of the SD card so other slaves could over-drive it. Something to look for if you have a 'scope handy.
Mark.
Edit: That was despite giving dummy clocks at the end of the cycle, it steadfastly refused to release MISO.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: WhiteHare on April 28, 2016, 06:26:36 PM
@Perky It's worth your knowing, if you're not already aware, that if the node has an RTC, then the RFM69's Listen Mode is obsolete.  You can get much higher energy efficiency using the RTC to wake the mcu (which, if properly configured, can take as little as 4us) and having the mcu then manage a similar kind of Listen Mode.  That's because, using Joes method, the initial Rx listen window (which simply checks for high RSSI) can be as little as 7us.  So, the cumulative energy savings really can be quite significant.

It's for that and related reasons that the new upcoming Moteino, if it happens, pretty much needs to have an energy efficient RTC, or similar standalone timer, if it is to harvest the full value of the recent energy related software developments by folks like Joe and Tom and others.
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: TomWS on April 28, 2016, 10:57:21 PM
I'll mention it again, but I had trouble getting SD cards to release the MISO line when de-selected on a previous project. The 'scope showed a clear over-driving waveform even though the SD card was de-selected. Solution was a 470R resistor on the MISO output of the SD card so other slaves could over-drive it. Something to look for if you have a 'scope handy.
Mark.
Edit: That was despite giving dummy clocks at the end of the cycle, it steadfastly refused to release MISO.
Fascinating.  I'll poke on it.  Thanks for the edit, that was important piece of data.
Tom
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 29, 2016, 03:24:08 AM
@WhiteHare: C
Quote
You can get much higher energy efficiency using the RTC to wake the mcu (which, if properly configured, can take as little as 4us) and having the mcu then manage a similar kind of Listen Mode.  That's because, using Joes method, the initial Rx listen window (which simply checks for high RSSI) can be as little as 7us.  So, the cumulative energy savings really can be quite significant.
Can you explain what you meant by this? Waking the MCU, then waking the radio via SPI to put into RX mode, getting an RSSI interrupt, reading the RSSI value and putting the radio back to sleep via SPI surely takes a lot longer than that! Did you mean uA?
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: joelucid on April 29, 2016, 04:18:32 AM
Quote
Can you explain what you meant by this? Waking the MCU, then waking the radio via SPI to put into RX mode, getting an RSSI interrupt, reading the RSSI value and putting the radio back to sleep via SPI surely takes a lot longer than that! Did you mean uA?

WhiteHare is correct that you can achieve significant savings using an RTC instead of the radio's listen mode. That majority of that comes from the 1.1uA of idle current the radio no longer draws. Switching off AGC, using the max possible bitrate and rxbw provides further gains if you only use the initial testing window to detect RSSI.

But the gains are nowhere enough to get below 7uS. Just on the radio side you have 250uS crystal wakeup + 80 uS PLL lock + 100uS or so to get RX ready and detect RSSI. But <200uS using 16mA is doable on the radio side I think.

Joe
Title: Re: Moteinos + DS3234 RTC sharing SPI - require hard reset each time?
Post by: perky on April 29, 2016, 05:42:02 AM
I'll mention it again, but I had trouble getting SD cards to release the MISO line when de-selected on a previous project. The 'scope showed a clear over-driving waveform even though the SD card was de-selected. Solution was a 470R resistor on the MISO output of the SD card so other slaves could over-drive it. Something to look for if you have a 'scope handy.
Mark.
Edit: That was despite giving dummy clocks at the end of the cycle, it steadfastly refused to release MISO.
Fascinating.  I'll poke on it.  Thanks for the edit, that was important piece of data.
Tom
This might not of course be the issue. However I've read some reports that adding a pullup to MISO appears to improve the situation. There's often an asymmetry in drive strengths between low and high (low usually being stronger), so an SD card driving MISO high when the other slave tries to drive it low might be OK, but the other way round may not result in a level that gets above the logic 1 threshold. Adding a pullup, which otherwise should have no effect, adds to the other slaves high driving capability and may well push it above the threshold. Adding the pull-up also reduces the low driving capability, but that is often significantly stronger so has no detrimental effect.
Mark.